This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Bootstrap failure on i686-linux


>  >This one fails when building libiberty after bootstrapping:
> This is clearly PRE's fault.  It fucks up the block statement iterators.  If
> anything needs to be turned off, it is PRE.

In the future, if you could please copy me when you claim PRE is
at fault for something, it would be helpful.

If you give me a patch that i can use to get the tree to see this
bug (IE to revert the current bootstrap failure) expose the testcase
below, i'll happily try to unfuck the block iterators for you, if you are
too busy to do it.


>
> Using my simplified testcase (-O2 -pedantic).  The block #3 exhibits the
> problem:
>
>       # BLOCK 3.  PRED: 2.  SUCC: 4.
>       <UL5380>:;;
>
>       #   VUSE <MT.1_6>;
>       T.1_12 = *p_1;
>       mcnt_13 = (int)T.1_12;
>       goto <UL5150>;;
>       (void)0;
>
>
> If I put a breakpoint just before PRE runs:
>
> (gdb) p basic_block_info.data.bb[3]
> $32 = (struct basic_block_def *) 0x89d9f7c
> (gdb) p bsi_start ($32)
> $33 = {tp = 0xbf1a867c, context = 0x0}
> (gdb) p bsi_stmt ($33)
> $34 = (union tree_node *) 0xbf1861dc
> (gdb) p debug_tree($34)
>  <label_expr 0xbf1861dc
>     type <void_type 0xbf1c78c0 void VOID
>         align 8 symtab 0 alias set -1
>         pointer_to_this <pointer_type 0xbf1c7930>>
>     side-effects
>     arg 0 <label_decl 0xbf185380 VOID file j.c line 23
>         align 1 alias set 1 context <function_decl 0xbf183b60 foo>
>         j.c:23>>
>
> Which looks perfectly reasonable.
>
>
> After PRE is complete:
>
> (gdb) p basic_block_info.data.bb[3]
> $37 = (struct basic_block_def *) 0x89d9f7c
> (gdb) p bsi_start ($37)
> $38 = {tp = 0x0, context = 0x89d9f7c}
> (gdb) p bsi_end_p ($38)
> $39 = true
>
>
> Which looks rather bogus to me.
>

Also note that PRE also doesn't do any code deletion on it's own.
It relies on DCE noticing the now-dead statements.
Thus, this must have been an insertion that bsi_insert now fucks up on.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]