/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite- strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -DG ENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/ ../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu64/gcc/gcc-4.3.0/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -o build/genconditions.o . ./../gcc/gcc/genconditions.c /test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-str ings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -DGENE RATOR_FILE -o build/genconditions \ build/genconditions.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/er rors.o .././libiberty/libiberty.a build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c /bin/sh: 13354 Memory fault(coredump) make[3]: *** [s-conditions] Error 139 This started about three days ago.
(gdb) r ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c Starting program: /test/gnu/gcc/objdir/gcc/build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c Program received signal SIGSEGV, Segmentation fault. 0x800003fffefb1834 in __doprnt_wide () from /lib/pa20_64/libc.2 (gdb) bt #0 0x800003fffefb1834 in __doprnt_wide () from /lib/pa20_64/libc.2 #1 0x800003fffefae95c in _doprnt () from /lib/pa20_64/libc.2 #2 0x800003fffefbbfa0 in printf () from /lib/pa20_64/libc.2 During symbol reading, unsupported tag: 'DW_TAG_const_type'. #3 0x400000000000d4fc in print_c_condition (cond=0x4000000000005eb0 "(%s)") at ../../gcc/gcc/read-rtl.c:817 During symbol reading, unsupported tag: 'DW_TAG_const_type'. #4 0x4000000000008cf4 in write_one_condition (slot=<value optimized out>, dummy=<value optimized out>) at ../../gcc/gcc/genconditions.c:135 During symbol reading, unsupported tag: 'DW_TAG_const_type'. #5 0x4000000000012a84 in htab_traverse_noresize (htab=<value optimized out>, callback=0x4000000000006ff0 <L$C0002+1072>, info=0x0) at ../../gcc/libiberty/hashtab.c:750 #6 0x4000000000013384 in htab_traverse (htab=0x800000010000e190, callback=0x4000000000006ff0 <L$C0002+1072>, info=0x0) at ../../gcc/libiberty/hashtab.c:765 During symbol reading, unsupported tag: 'DW_TAG_const_type'. #7 0x400000000000e2e4 in traverse_c_tests (callback=0x8000000100103000, info=0x800003fffeeb2fe0) at ../../gcc/gcc/gensupport.c:1225 #8 0x4000000000008b60 in main (argc=<value optimized out>, argv=<value optimized out>) at ../../gcc/gcc/genconditions.c:167
Introduced by r118475. However, it wasn't fixed by Andrew's fwprop.c patch.
In print_c_condition, we have these two calls: print_rtx_ptr_loc (cond); printf ("(%s)", cond); The generated assembly code is: 0x400000000000d4d0 <print_c_condition+216>: ldd -40(ret1),r26 0x400000000000d4d4 <print_c_condition+220>: ldo -30(sp),ret1 0x400000000000d4d8 <print_c_condition+224>: b,l 0x400000000000d3b8 <print_rtx_ptr_loc>,rp 0x400000000000d4dc <print_c_condition+228>: copy dp,r4 0x400000000000d4e0 <print_c_condition+232>: ldd -40(ret1),r25 0x400000000000d4e4 <print_c_condition+236>: copy r4,dp 0x400000000000d4e8 <print_c_condition+240>: addil L%0,dp,r1 0x400000000000d4ec <print_c_condition+244>: ldd 80(r1),r26 0x400000000000d4f0 <print_c_condition+248>: ldo -30(sp),ret1 0x400000000000d4f4 <print_c_condition+252>: b,l 0x400000000000d994 <.stub+60>,rp 0x400000000000d4f8 <print_c_condition+256>: nop The insn at 0x400000000000d4e0 is the problem. Register ret1 is the argument pointer. It's call clobbered, so it must be saved and restored if an argument (in this case cond) needs to be reloaded from the argument block on the stack.
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) Simplified test case attached. Dave
Created attachment 12688 [details] foo.c
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) > Simplified test case attached. This is a bug in fwprop. Attached rtl dumps fro cse1 and fwprop1. Dave
Created attachment 12689 [details] foo.c.112r.cse1
Created attachment 12690 [details] foo.c.113r.fwprop1
Why is this an fwprop bug? You haven't really shown that AFAICS. Could be a latent bug elsewhere that fwprop uncovered. Or can you pin-point the specific insns that fwpwop produces, and which you think is wrong?
From the cse1 dump: Register 72 used 1 times across 0 insns; set 1 time; dies in 0 places; pointer. So there is only a single DEF for reg 72. The set for this DEF is: (insn 112 2 7 2 foo.c:13 (set (reg/f:DI 72) (plus:DI (reg/f:DI 29 %r29) (const_int -64 [0xffffffffffffffc0]))) -1 (nil) (nil)) fwprop replaces occurences of (reg 72) with (plus (reg 29) (const_int -64)). This is the diff between the cse1 and fwprop dump: --- attachment.cse1 2006-11-26 00:13:55.000000000 +0100 +++ attachment.fwprop1 2006-11-26 00:14:06.000000000 +0100 (....) @@ -112,7 +172,8 @@ (const_int -64 [0xffffffffffffffc0]))) -1 (nil) (nil)) -(insn 7 112 8 2 foo.c:13 (set (mem/f/c/i:DI (reg/f:DI 72) [8 cond+0 S8 A64]) +(insn 7 112 8 2 foo.c:13 (set (mem/f/c/i:DI (plus:DI (reg/f:DI 29 %r29) + (const_int -64 [0xffffffffffffffc0])) [8 cond+0 S8 A64]) (reg:DI 26 %r26 [ cond ])) 124 {*pa.md:4480} (nil) (nil)) @@ -397,7 +458,8 @@ (insn 71 70 74 5 foo.c:25 (set (mem:QI (reg/f:DI 68 [ D.1944 ]) [0 S1 A8]) (reg:QI 88)) 104 {*pa.md:3322} (nil) - (nil)) + (expr_list:REG_EQUAL (const_int 10 [0xa]) + (nil))) (insn 74 71 75 5 foo.c:25 (set (reg/f:DI 91) (plus:DI (reg/f:DI 68 [ D.1944 ]) @@ -462,7 +524,8 @@ (note 89 88 91 7 [bb 7] NOTE_INSN_BASIC_BLOCK) (insn 91 89 92 7 foo.c:26 (set (reg/f:DI 26 %r26 [ cond ]) - (mem/f/c/i:DI (reg/f:DI 72) [8 cond+0 S8 A64])) 124 {*pa.md:4480} (nil) + (mem/f/c/i:DI (plus:DI (reg/f:DI 29 %r29) + (const_int -64 [0xffffffffffffffc0])) [8 cond+0 S8 A64])) 124 {*pa.md:4480} (nil) (nil)) (insn 92 91 93 7 foo.c:26 (set (reg/f:DI 29 %r29) @@ -503,7 +566,8 @@ (nil))) (insn 98 97 99 7 foo.c:27 (set (reg/f:DI 25 %r25 [ cond ]) - (mem/f/c/i:DI (reg/f:DI 72) [8 cond+0 S8 A64])) 124 {*pa.md:4480} (nil) + (mem/f/c/i:DI (plus:DI (reg/f:DI 29 %r29) + (const_int -64 [0xffffffffffffffc0])) [8 cond+0 S8 A64])) 124 {*pa.md:4480} (nil) (nil)) (insn 99 98 100 7 foo.c:27 (set (reg/f:DI 29 %r29) Someone care to explain why this is a wrong transformation by fwprop?
Note that (reg 29) is the ret1 reg. Looks more and more like a register allocation problem.
Re. comment #3, "It's call clobbered, so it must be saved and restored": Why is reg 29 not in the call clobbered reg list on the call_insns? I see a USE for reg 29 on every call: (use (reg/f:DI 29 %r29)). But not a CLOBBER. Shouldn't that be a clobber if reg 29 is call clobbered?
The only three instructions fwprop touches are done into: Before: (insn 112 2 7 2 foo.c:13 (set (reg/f:DI 72) (plus:DI (reg/f:DI 29 %r29) (const_int -64 [0xffffffffffffffc0]))) -1 (nil) (nil)) (insn 7 112 8 2 foo.c:13 (set (mem/f/c/i:DI (reg/f:DI 72) [8 cond+0 S8 A64]) (reg:DI 26 %r26 [ cond ])) 124 {*pa.md:4480} (nil) (nil)) .... After: ... (insn 91 89 92 7 foo.c:26 (set (reg/f:DI 26 %r26 [ cond ]) (mem/f/c/i:DI (plus:DI (reg/f:DI 29 %r29) (const_int -64 [0xffffffffffffffc0])) [8 cond+0 S8 A64])) 124 {*pa.md:4480} (nil) (nil)) wait. r29 is clobbered by: (insn 16 15 17 2 foo.c:14 (set (reg/f:DI 29 %r29) (plus:DI (reg/f:DI 30 %r30) (const_int -48 [0xffffffffffffffd0]))) 164 {*pa.md:5309} (nil) (nil))
fwprop says it is r29 invalided by a call: invalidated by call 0, 1, 2, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 31, 32, 33, 34, 35, 36, 37, 38, 39, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60 I think it missed that pseduo register 72 uses r29.
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory faul > (insn 98 97 99 7 foo.c:27 (set (reg/f:DI 25 %r25 [ cond ]) > - (mem/f/c/i:DI (reg/f:DI 72) [8 cond+0 S8 A64])) 124 {*pa.md:4480} > (nil) > + (mem/f/c/i:DI (plus:DI (reg/f:DI 29 %r29) > + (const_int -64 [0xffffffffffffffc0])) [8 cond+0 S8 A64])) 124 > {*pa.md:4480} (nil) > (nil)) > Someone care to explain why this is a wrong transformation by fwprop? This is the transformation that's wrong and the one that causes garbage to get loaded in r25 for the call printf. r29 is called used/clobbered and not preserved across the previous call. It's defined so in the macro CALL_USED_REGISTERS in pa64-regs.h. It's the argument pointer and must set up prior to every call. On most targets, it's a fixed register but not on PA64. Even if it wasn't call clobbered, fwprop seems to have missed the fact that the value in r29 changes at insn 92 and every other call in the preceding insn flow: (insn 92 91 93 7 foo.c:26 (set (reg/f:DI 29 %r29) (plus:DI (reg/f:DI 30 %r30) (const_int -48 [0xffffffffffffffd0]))) 164 {*pa.md:5309} (nil) (nil)) At least in the past, it never was never necessary to have a complete list of call used registers appended to each each call. Dave
Created attachment 12692 [details] Magic with hard regs Paolo Bonzini proably can think of a real fix, but it'll have to look something like this: Make hard register uses available in all_uses_available_at, and don't propagate call clobbered hard regs.
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) I wonder if it is enough to just add DF_HARD_REGS in the df_init call? Paolo
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) Just adding DF_HARD_REGS is not enough. At least this bit: - if (use) + if (use && !HARD_REGISTER_P (use->reg)) is also necessary. You can reproduce the problem with a cross-compiler BTW.
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 MO > Subject: Re: [4.3 Regression] build/genconditions > ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory > fault(coredump) > > Just adding DF_HARD_REGS is not enough. At least this bit: > > - if (use) > + if (use && !HARD_REGISTER_P (use->reg)) > > is also necessary. The proposed patch with the initialization of regno moved forward gets us a lot further into the bootstrap. It now fails with an ICE building the fortran library: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/g cc-4.3.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11 /lib/ -isystem /opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/include -isystem /op t/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I. -I../. ./../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io -I../../../gcc/libgf ortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOUR CE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definit ion -Wextra -Wwrite-strings -ftree-vectorize -funroll-loops -O2 -g -O2 -c ../../ ../gcc/libgfortran/generated/matmul_i4.c -fPIC -DPIC -o .libs/matmul_i4.o ../../../gcc/libgfortran/generated/matmul_i4.c: In function 'matmul_i4': ../../../gcc/libgfortran/generated/matmul_i4.c:337: internal compiler error: Seg mentation fault Dave
This may be a df bug too. I don't know if it is ok to expect, when DF_HARD_REGS is set, that the list of defs include a def for every hard register that is call-clobbered and live at the call?
Dave, is the compiler being miscompiled here? Can you reproduce the failure with "../configure --disable-bootstrap && make"? If so, what is the backtrace? Thanks, Paolo
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 M > ------- Comment #21 from bonzini at gnu dot org 2006-11-30 18:48 ------- > Dave, is the compiler being miscompiled here? Can you reproduce the failure > with "../configure --disable-bootstrap && make"? If so, what is the backtrace? Don't know. I do know that the same error occurs on hppa2.0w-hp-hpux11 with the proposed patch install. I had an unexpected eye operation Tuesday and the vision in my right eye is now half blocked by a gas bubble. The bubble is supposed to slowly decrease in size over a few weeks. Don't know when reasonable visiblity will return and when i'll be able to look at this. Dave
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) > I had an unexpected eye operation Tuesday and the vision in my right > eye is now half blocked by a gas bubble. The bubble is supposed to > slowly decrease in size over a few weeks. Don't know when reasonable > visiblity will return and when i'll be able to look at this. No problem. If the compiler is not being miscompiled, I will be able to look at it with a cross. Good luck! Paolo
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 MRO > No problem. If the compiler is not being miscompiled, I will be able to > look at it with a cross. Good luck! The ICE is here: (gdb) bt #0 forward_propagate_into (use=0x4011b258) at ../../gcc/gcc/fwprop.c:888 #1 0x0038796c in fwprop_addr () at ../../gcc/gcc/fwprop.c:1016 #2 0x0026a704 in execute_one_pass (pass=0x40012bcc) at ../../gcc/gcc/passes.c:871 #3 0x0026a8ac in execute_pass_list (pass=0x40012bcc) at ../../gcc/gcc/passes.c:918 #4 0x0026a8c0 in execute_pass_list (pass=0x40011420) at ../../gcc/gcc/passes.c:919 #5 0x000c73fc in tree_rest_of_compilation (fndecl=0x7ad35070) at ../../gcc/gcc/tree-optimize.c:463 #6 0x00039508 in c_expand_body (fndecl=0x7ad35070) at ../../gcc/gcc/c-decl.c:6855 #7 0x0029622c in cgraph_expand_function (node=0x7ad351c0) at ../../gcc/gcc/cgraphunit.c:1241 #8 0x00299798 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1306 #9 0x00041b50 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7968 #10 0x00236610 in toplev_main (argc=1073924712, argv=0x1) at ../../gcc/gcc/toplev.c:1046 #11 0x000aacfc in main (argc=2059796228, argv=0x7ade4334) at ../../gcc/gcc/main.c:35 DF_REF_INSN (def) is 0. It looks like the ICE can be avoided by a check on def_insn. Dave
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 MRO > DF_REF_INSN (def) is 0. It looks like the ICE can be avoided by > a check on def_insn. The attached patch seems to get by the ICE. Dave
Created attachment 12726 [details] fwprop.c.d.2
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) dave at hiauly1 dot hia dot nrc dot ca wrote: > ------- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-01 22:22 ------- > Subject: Re: [4.3 Regression] build/genconditions > ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 MRO > >> DF_REF_INSN (def) is 0. It looks like the ICE can be avoided by >> a check on def_insn. > > The attached patch seems to get by the ICE. I'm pretty sure that's the same issue as the second and third hunk of http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00891.html Paolo
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 M > I'm pretty sure that's the same issue as the second and third hunk of > http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00891.html I see this was committed to the dataflow branch. What about the trunk? Dave
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) >> I'm pretty sure that's the same issue as the second and third hunk of >> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00891.html > > I see this was committed to the dataflow branch. What about the > trunk? I will test on a cross if it fixes the failure on hppa. It seemed not to be necessary on the trunk (it fixed a very early bootstrapping failure on x86-linux, as soon as building stage1 libgcc). Paolo
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 M > I will test on a cross if it fixes the failure on hppa. Ok, I'll see if it fixes the problem. Dave
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) > I will test on a cross if it fixes the failure on hppa. It seemed not > to be necessary on the trunk (it fixed a very early bootstrapping > failure on x86-linux, as soon as building stage1 libgcc). It fixes the hppa failure. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. I've attached the change tested. Dave
Created attachment 12743 [details] fwprop.c.d.5
I tested Dave's patch from comment #32 and it is fixing the hppa64-* bootstrap failure. Dave are you going to submit that patch for approval or are you looking for someone else to pick this up?
Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 M > ------- Comment #33 from sje at cup dot hp dot com 2006-12-19 18:23 ------- > I tested Dave's patch from comment #32 and it is fixing the hppa64-* bootstrap > failure. Dave are you going to submit that patch for approval or are you > looking for someone else to pick this up? Paolo posted a patch today: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01378.html Dave
Subject: Bug 29840 Author: bonzini Date: Fri Dec 22 12:28:52 2006 New Revision: 120147 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120147 Log: 2006-12-22 Paolo Bonzini <bonzini@gnu.org> PR rtl-optimization/29840 * fwprop.c (forward_propagate_into): Reject artificial uses/defs. (fwprop_init): Add DF_HARD_REGS to df_init call. Modified: trunk/gcc/ChangeLog trunk/gcc/fwprop.c
Should be fixed now (by inspection of the reduced test case). Patch committed is at this URL: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01378.html