Bug 39929

Summary: [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix
Product: gcc Reporter: Dominique d'Humieres <dominiq>
Component: bootstrapAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: dje, fang, gcc-bugs, jules, matz
Priority: P1 Keywords: assemble-failure, build, wrong-code
Version: 4.5.0   
Target Milestone: 4.5.0   
Host: powerpc-apple-darwin9,powerpc-ibm-aix Target: powerpc-apple-darwin9,powerpc-ibm-aix
Build: powerpc-apple-darwin9,powerpc-ibm-aix Known to work:
Known to fail: Last reconfirmed: 2009-04-27 13:54:23

Description Dominique d'Humieres 2009-04-27 13:08:02 UTC
Bootstrapping revision 146838 fails at stage 1 on powerpc-apple-darwin9 with:

...
/opt/gcc/darwin_buildw/./gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.5w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.5w/powerpc-apple-darwin9/sys-include -g -O2 -m64 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include  -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc -I../../../../gcc-4.5-work/libgcc -I../../../../gcc-4.5-work/libgcc/. -I../../../../gcc-4.5-work/libgcc/../gcc -I../../../../gcc-4.5-work/libgcc/../include  -DHAVE_CC_TLS -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep -DL_floatdisf -c ../../../../gcc-4.5-work/libgcc/../gcc/libgcc2.c \
	  -fvisibility=hidden -DHIDE_EXPORTS
{standard input}:194:non-relocatable subtraction expression, "LC1" minus "L00000000001$pb"
{standard input}:194:symbol: "L00000000001$pb" can't be undefined in a subtraction expression
{standard input}:193:non-relocatable subtraction expression, "LC1" minus "L00000000001$pb"
{standard input}:193:symbol: "L00000000001$pb" can't be undefined in a subtraction expression
{standard input}:175:non-relocatable subtraction expression, "LC0" minus "L00000000001$pb"
{standard input}:175:symbol: "L00000000001$pb" can't be undefined in a subtraction expression
{standard input}:174:non-relocatable subtraction expression, "LC0" minus "L00000000001$pb"
{standard input}:174:symbol: "L00000000001$pb" can't be undefined in a subtraction expression
{standard input}:135:non-relocatable subtraction expression, "LC2" minus "L00000000001$pb"
{standard input}:135:symbol: "L00000000001$pb" can't be undefined in a subtraction expression
{standard input}:131:non-relocatable subtraction expression, "LC2" minus "L00000000001$pb"
{standard input}:131:symbol: "L00000000001$pb" can't be undefined in a subtraction expression
{standard input}:unknown:Undefined local symbol L00000000001$pb
make[5]: *** [_floatdisf.o] Error 1
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
Comment 1 Dominique d'Humieres 2009-04-27 13:11:55 UTC
I have forgotten to add that this is probably the same failure as reported at

http://gcc.gnu.org/ml/gcc-regression/2009-04/msg00196.html

and occurring between revisions 146801 and 146817.
Comment 2 David Edelsohn 2009-04-27 13:54:23 UTC
This also fails on AIX.  On AIX, the error appears as a failure while compiling libobjc/linking.m.

A function in cgraphunit.c is being mis-compiled, possibly build_cdtor().  This causes cgraph_build_static_cdtor() to be called with an invalid priority of "-1", instead of 65535.  The priority should not be negative.  This negative priority value generates an invalid global file function name:

_GLOBAL__I_-00001_0___objc_linking

A function name should not contain a minus sign, which is a syntax error.  Recompiling cgarphunit.c without optimization fixes the miscompilation.  An incorrect priority is calculated from decl_fini_priority_lookup(), but recompiling tree.c does not change the failure.
Comment 3 David Edelsohn 2009-04-27 14:19:41 UTC
This probably is related to the promoted parameter problem that has appeared on other architectures as well.
Comment 4 Andrew Pinski 2009-04-27 19:06:54 UTC
Here is a reduced testcase for the PPC-darwin failure:
float f(int a) { return a ? 1.0f : 2.0f ; }

Comment 5 Andrew Pinski 2009-04-27 19:11:24 UTC
(In reply to comment #4)
> Here is a reduced testcase for the PPC-darwin failure:
> float f(int a) { return a ? 1.0f : 2.0f ; }

This looks like how constants are expanded in PHIs, looking into it further.
Comment 6 Andrew Pinski 2009-04-27 19:24:42 UTC
This patch fixes the ppc-darwin failure:
Index: cfgexpand.c
===================================================================
--- cfgexpand.c (revision 146848)
+++ cfgexpand.c (working copy)
@@ -2503,11 +2503,11 @@ gimple_expand_cfg (void)
       gcc_assert (crtl->parm_stack_boundary <= INCOMING_STACK_BOUNDARY);
     }
 
-  expand_phi_nodes (&SA);
-
   /* Register rtl specific functions for cfg.  */
   rtl_register_cfg_hooks ();
 
+  expand_phi_nodes (&SA);
+
   init_block = construct_init_block ();
 
   /* Clear EDGE_EXECUTABLE on the entry edge(s).  It is cleaned from the

--- CUT ---
expand_phi_nodes can and will create RTL code so we need to register the RTL CFG hooks before calling it.
Comment 7 Andrew Pinski 2009-04-27 19:44:08 UTC
This is the correct fix as in darwin.c we have:
      /* Play games to avoid marking the function as needing pic if we
         are being called as part of the cost-estimation process.  */
      if (current_ir_type () != IR_GIMPLE)
        crtl->uses_pic_offset_table = 1;

 
Comment 8 Michael Matz 2009-04-28 00:37:55 UTC
> expand_phi_nodes can and will create RTL code so we need to register the RTL
> CFG hooks before calling it.

Nope, that won't fly (for the moment).  expand_phi_nodes also split edges
and it's necessary that this is done while the tree hooks are still
registered (only those can redirect EH edges).

This whole pass crossover (tree-ssa -> RTL) is a tough problem, and there's a
variable to say that we're inside of it (currently_expanding_to_rtl).
Obviously it would be nicer to make darwin.c not depend on the current IR
mode to set or not set random flags.  If somebody can explain why it's
necessary to let the generated RTL code depend on the IR mode, we could
possibly find a good way around this limitation.
Comment 9 Andrew Pinski 2009-04-28 01:04:26 UTC
(In reply to comment #8)
>  If somebody can explain why it's
> necessary to let the generated RTL code depend on the IR mode, we could
> possibly find a good way around this limitation.

Because we don't want to mark uses_pic_offset_table as being needed when dealing with IV-opts.
See http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01535.html .  Sounds like the arm back-end does the same thing.

The MIPS back-end does:
      && (current_ir_type () != IR_GIMPLE || currently_expanding_to_rtl))

While the ARM back-end (and darwin.c) does:
          if (current_ir_type () != IR_GIMPLE)


So the MIPS back-end will work but the arm back-end should change to be include || currently_expanding_to_rtl.

Fixing darwin.c that way instead of the other patch.
Comment 10 Andrew Pinski 2009-04-28 14:19:18 UTC
Subject: Bug 39929

Author: pinskia
Date: Tue Apr 28 14:19:00 2009
New Revision: 146894

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146894
Log:
2009-04-28  Andrew Pinski  <pinskia@gmail.com>

        PR target/39929
        * config/darwin.c (machopic_gen_offset): Check
        currently_expanding_to_rtl if current_ir_type returns IR_GIMPLE.
        * config/arm/arm.c (require_pic_register): Likewise.




Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm.c
    trunk/gcc/config/darwin.c

Comment 11 Andrew Pinski 2009-04-28 14:21:38 UTC
The darwin part of this bug report should have been fixed.  The AIX bug was unrelated to the darwin bug.
Comment 12 jules 2009-04-28 22:31:32 UTC
FYI: the above patch seems to have caused ARM Linux (cross) builds to break, e.g.:

/scratch/julian/arm-mainline/src/gcc-mainline/libgcc/../gcc/config/arm/unwind-arm.c:589: internal compiler error: Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x08253611 in emit_insn_after_1 (first=0xf7cd7798, after=0xf7c744f8,
    bb=0xf7c74540)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/emit-rtl.c:4129
4129          if (BB_END (bb) == after)

Backtrace:

#0  0x08253611 in emit_insn_after_1 (first=0xf7cd7798, after=0xf7c744f8,
    bb=0xf7c74540)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/emit-rtl.c:4129
#1  0x082544ac in emit_insn_after (pattern=0x0, after=0xf7c744f8)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/emit-rtl.c:4335
#2  0x0862b3c6 in require_pic_register ()
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/config/arm/arm.c:3590
#3  legitimize_pic_address (orig=0xf7ca2ccc, mode=SImode, reg=0x0)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/config/arm/arm.c:3607
#4  0x086f32ed in gen_movsi (operand0=0x0, operand1=0xf7ca2ccc)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/config/arm/arm.md:4966
#5  0x0828ef94 in emit_move_insn_1 (x=0xf7cca0a0, y=0xf7ca2ccc)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/expr.c:3337
#6  0x0828f282 in emit_move_insn (x=0xf7cca0a0, y=0xf7ca2ccc)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/expr.c:3425
#7  0x0881e7ea in insert_value_copy_on_edge (src=<value optimized out>,
    dest=<value optimized out>, e=<value optimized out>)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/tree-outof-ssa.c:190
#8  eliminate_phi (g=<value optimized out>, e=<value optimized out>)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/tree-outof-ssa.c:594
#9  expand_phi_nodes (sa=0x8d125b4)
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/tree-outof-ssa.c:756
#10 0x08795c2f in gimple_expand_cfg ()
    at /scratch/julian/arm-mainline/src/gcc-mainline/gcc/cfgexpand.c:2506
...

(gdb) print *bb
$1 = {preds = 0xf7e57a8c, succs = 0xf7e2e390, aux = 0x0,
  loop_father = 0xf7e57ab0, dom = {0x0, 0xf7c74558}, prev_bb = 0xf7e2a5b0,
  next_bb = 0x0, il = {gimple = 0x0, rtl = 0x0}, count = -584888453233663636,
  index = -136179944, loop_depth = -137911904, frequency = 0,
  flags = -136126440}

Maybe there's some significant difference between the behaviour of mips16_gp_pseudo_reg() and require_pic_register() which causes this, or maybe MIPS is broken too?
Comment 13 Andrew Pinski 2009-04-28 22:50:12 UTC
(In reply to comment #12)
> Maybe there's some significant difference between the behaviour of
> mips16_gp_pseudo_reg() and require_pic_register() which causes this, or maybe
> MIPS is broken too?

Hmm,
ARM uses emit_insn_after (seq, entry_of_function ()); while mips uses 
push_topmost_sequence/pop_topmost_sequence.

Maybe this is more broken and was broken with SSA to RTL patch after all.

The darwin back-end delays emitting of the branch for the PIC register until the prologue.  Maybe both mips and ARM back-end should do the same thing.  Actually the arm back-end already does most of them.
Comment 14 Michael Matz 2009-04-29 17:37:01 UTC
Subject: Bug 39929

Author: matz
Date: Wed Apr 29 17:36:21 2009
New Revision: 146982

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146982
Log:
        PR middle-end/39927
        PR bootstrap/39929
        * tree-outof-ssa.c (emit_partition_copy): New function.
        (insert_partition_copy_on_edge, insert_rtx_to_part_on_edge,
        insert_part_to_rtx_on_edge): Perform the partition base var
        copy using emit_partition_copy.
        (insert_value_copy_on_edge): Convert constants to the right mode.
        (insert_rtx_to_part_on_edge): Add UNSIGNEDSRCP parameter.
        (elim_create): Pass the sign of the src to insert_rtx_to_part_on_edge.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-outof-ssa.c

Comment 15 Dominique d'Humieres 2009-05-04 11:45:02 UTC
This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #11 to
#13, I don't close it as fixed. If someone wants to keep this PR open, (s)he
should change subject, platform, and priority.
Comment 16 Mark Mitchell 2009-05-05 15:13:43 UTC
Jules, is the ARM GNU/Linux build still broken?

David, how about AIX?

Thanks,

-- Mark
Comment 17 jules 2009-05-05 16:07:07 UTC
This still seems to be broken as of r147126 for ARM Linux.
Comment 18 Andrew Pinski 2009-05-05 19:15:04 UTC
(In reply to comment #16)
> Jules, is the ARM GNU/Linux build still broken?

Yes it is still broken; I filed a seperate bug for that though, see PR 40031.
Comment 19 Paolo Bonzini 2009-05-06 15:33:36 UTC
ARM moved to PR40031 (and PR39978?).

What about AIX?
Comment 20 Michael Matz 2009-05-06 15:48:31 UTC
Bootstrap on AIX was already working on April 29:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02342.html

I just left this open for the other (ARM/Mips) problem.  As that now moved
somewhere else, this here is fixed.