Bug 44970 - [4.6 regression] Revision 162270 failed to bootstrap
Summary: [4.6 regression] Revision 162270 failed to bootstrap
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.6.0
: P1 normal
Target Milestone: 4.6.0
Assignee: Paolo Bonzini
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-17 02:37 UTC by H.J. Lu
Modified: 2010-11-22 17:18 UTC (History)
11 users (show)

See Also:
Host:
Target: hppa64-*-* arm-linux
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-09-04 16:46:13


Attachments
Potential fix (1.05 KB, patch)
2010-07-17 22:36 UTC, Bernd Schmidt
Details | Diff
Better patch. (1.05 KB, patch)
2010-07-17 23:29 UTC, Bernd Schmidt
Details | Diff
Another patch (1.38 KB, patch)
2010-07-18 18:38 UTC, Bernd Schmidt
Details | Diff
Patch v4 (1.78 KB, patch)
2010-07-18 20:39 UTC, Bernd Schmidt
Details | Diff
Minimally tested patch for the hppa problem (560 bytes, patch)
2010-07-18 21:15 UTC, Bernd Schmidt
Details | Diff
Another attempt to fix the pa64 problem (712 bytes, patch)
2010-07-20 14:21 UTC, Bernd Schmidt
Details | Diff
cfg.i.gz (155.95 KB, application/x-gunzip)
2010-07-29 15:05 UTC, dave
Details
cfg.s.gz (101.35 KB, application/x-gunzip)
2010-07-29 15:05 UTC, dave
Details
yy.sh (405 bytes, application/x-sh)
2010-07-29 15:05 UTC, dave
Details
A patch to aid debugging (461 bytes, patch)
2010-08-05 11:31 UTC, Bernd Schmidt
Details | Diff
cfg.s.0.gz (17.94 KB, application/x-gunzip)
2010-08-05 19:26 UTC, dave
Details
cfg.c.146r.expand.0.gz (313.05 KB, application/x-gunzip)
2010-08-05 19:26 UTC, dave
Details
cfg.c.181r.combine.0.gz (329.31 KB, application/x-gunzip)
2010-08-05 19:26 UTC, dave
Details
cfg.c.193r.ira.0.gz (433.30 KB, application/x-gunzip)
2010-08-05 19:26 UTC, dave
Details
cfg.s.1.gz (17.95 KB, application/x-gunzip)
2010-08-05 19:26 UTC, dave
Details
cfg.c.146r.expand.1.gz (313.12 KB, application/x-gunzip)
2010-08-05 19:26 UTC, dave
Details
cfg.c.181r.combine.1.gz (329.00 KB, application/x-gunzip)
2010-08-05 19:26 UTC, dave
Details
cfg.c.193r.ira.1.gz (433.37 KB, application/x-gunzip)
2010-08-05 19:26 UTC, dave
Details
incomplete patch (4.14 KB, patch)
2010-09-04 16:49 UTC, Paolo Bonzini
Details | Diff
patch (4.26 KB, patch)
2010-10-18 17:20 UTC, Paolo Bonzini
Details | Diff
ioctl.i.gz (125.51 KB, application/x-gunzip)
2010-11-08 17:00 UTC, dave
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2010-07-17 02:37:30 UTC
On Linux/ia32, revision 162270:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00624.html

caused:

make[6]: Leaving directory `/export/gnu/import/svn/gcc-test/bld'
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/dwarf2out.o differs
gcc/i386.o differs
gcc/java/expr.o differs
gcc/reload.o differs
gcc/reg-stack.o differs
gcc/recog.o differs
libiberty/hashtab.o differs
make[5]: *** [compare] Error 1

On Linux/x86-64, it caused:

FAIL: gcc.c-torture/execute/nest-stdar-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/nest-stdar-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O1
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O2
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O2 -fwhopr
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O3 -fomit-frame-pointer -funroll-loops
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/pr44575.c execution,  -Os
FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O1
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O2
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O2 -fwhopr
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O3 -fomit-frame-pointer -funroll-loops
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -Os
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O1
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O2
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O2 -fwhopr
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -Os
FAIL: gcc.c-torture/execute/va-arg-26.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/va-arg-26.c execution,  -O3 -g
FAIL: gcc.target/i386/amd64-abi-5.c execution test
FAIL: gcc.target/i386/vararg-3.c execution test
FAIL: gcc.target/i386/vararg-7.c execution test
Comment 1 H.J. Lu 2010-07-17 15:28:34 UTC
On Linux/ia64, I got

Bootstrap comparison failure!
gcc/fortran/trans-openmp.o differs
gcc/dwarf2out.o differs
make[5]: *** [compare] Error 1
Comment 2 Dominique d'Humieres 2010-07-17 15:49:10 UTC
On x86_64-apple-darwin10.4 bootstrap fails with

/bin/sh: line 1: 55341 Illegal instruction     build/genattrtab ../../work/gcc/config/i386/
Comment 3 Bernd Schmidt 2010-07-17 15:53:31 UTC
x86_64 failures are expected due to a backend bug, see the patch I sent today.

HJ, any chance you could run make check on the stage1 compiler on ia64 to find a testcase?
Comment 4 H.J. Lu 2010-07-17 16:12:33 UTC
(In reply to comment #0)
> On Linux/ia32, revision 162270:
> 
> http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00624.html
> 
> caused:
> 
> make[6]: Leaving directory `/export/gnu/import/svn/gcc-test/bld'
> Comparing stages 2 and 3
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap comparison failure!
> gcc/dwarf2out.o differs
> gcc/i386.o differs
> gcc/java/expr.o differs
> gcc/reload.o differs
> gcc/reg-stack.o differs
> gcc/recog.o differs
> libiberty/hashtab.o differs
> make[5]: *** [compare] Error 1

The full configure option on Fedora 12/ia32 is

         ../src-trunk/configure \
                 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld -with-plugin-ld=ld.gold --enable-gold --with-fpmath=sse
Comment 5 Dominique d'Humieres 2010-07-17 16:15:01 UTC
> x86_64 failures are expected due to a backend bug, see the patch I sent today.

With the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt bootstrap fails at stage 1 with:


/bin/sh ./libtool --tag=CC   --mode=compile /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/lib/ -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/include -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/sys-include    -DHAVE_CONFIG_H -I. -I../../../work/libgomp  -I../../../work/libgomp/config/bsd -I../../../work/libgomp/config/posix -I../../../work/libgomp  -Wall -Werror -Wc,-pthread -g -O2 -MT error.lo -MD -MP -MF .deps/error.Tpo -c -o error.lo ../../../work/libgomp/error.c
libtool: compile:  /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/lib/ -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/include -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/sys-include -DHAVE_CONFIG_H -I. -I../../../work/libgomp -I../../../work/libgomp/config/bsd -I../../../work/libgomp/config/posix -I../../../work/libgomp -Wall -pthread -Werror -g -O2 -MT error.lo -MD -MP -MF .deps/error.Tpo -c ../../../work/libgomp/error.c  -fno-common -DPIC -o .libs/error.o
../../../work/libgomp/error.c: In function 'gomp_error':
../../../work/libgomp/error.c:54:1: error: unrecognizable insn:
(insn 32 31 11 2 ../../../work/libgomp/error.c:48 (parallel [
            (set (mem/c:BLK (plus:DI (reg/f:DI 6 bp)
                        (const_int -128 [0xffffffffffffff80])) [0 A64])
                (unspec:BLK [
                        (reg:DI 21 xmm0)
                        (reg:DI 22 xmm1)
                        (reg:DI 23 xmm2)
                        (reg:DI 24 xmm3)
                        (reg:DI 25 xmm4)
                        (reg:DI 26 xmm5)
                        (reg:DI 27 xmm6)
                        (reg:DI 28 xmm7)
                    ] UNSPEC_SSE_PROLOGUE_SAVE_LOW))
            (use (reg:DI 0 ax [58]))
            (use (const_int 0 [0]))
            (use (label_ref:DI 0))
            (use (const_int 4 [0x4]))
        ]) -1 (nil))
../../../work/libgomp/error.c:54:1: internal compiler error: in extract_insn, at recog.c:2127
Comment 6 Bernd Schmidt 2010-07-17 16:41:58 UTC
(In reply to comment #5)
> > x86_64 failures are expected due to a backend bug, see the patch I sent today.
> 
> With the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt
> bootstrap fails at stage 1 with:

Hmm, doesn't happen here, but doesn't surprise me terribly either.  As I said, I'll let the x86 maintainers fix this pattern.
Comment 7 H.J. Lu 2010-07-17 16:56:16 UTC
It also miscompiled 450.soplex in SPEC CPU 2006 on
Linux/i386 with

-m32 -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops
Comment 8 H.J. Lu 2010-07-17 17:35:38 UTC
The difference in recog.o is in peep2_find_free_register:

@@ -5271,8 +5271,8 @@ Disassembly of section .text:
     4884:	74 5e                	je     48e4 <peep2_find_free_register+0x
d4>
     4886:	8d 74 24 30          	lea    0x30(%esp),%esi
     488a:	8d b6 00 00 00 00    	lea    0x0(%esi),%esi
-    4890:	83 c3 01             	add    $0x1,%ebx
-    4893:	8d 43 fb             	lea    -0x5(%ebx),%eax
+    4890:	8d 43 fc             	lea    -0x4(%ebx),%eax
+    4893:	83 c3 01             	add    $0x1,%ebx
     4896:	83 fb 05             	cmp    $0x5,%ebx
     4899:	0f 4d d8             	cmovge %eax,%ebx
     489c:	8b 04 dd 80 57 00 00 	mov    0x5780(,%ebx,8),%eax

It makes no difference in results. But the code sequences are different.
Comment 9 H.J. Lu 2010-07-17 17:39:56 UTC
The patch uses uid of the insn. Will DEBUG_INSN affect
uid processing?
Comment 10 H.J. Lu 2010-07-17 17:42:21 UTC
With stage3 gcc, I got

[hjl@gnu-29 stage3-gcc]$ ./xgcc -B./ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include    -c   -g -O2 -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src-trunk/gcc -I../../src-trunk/gcc/. -I../../src-trunk/gcc/../include -I../../src-trunk/gcc/../libcpp/include  -I../../src-trunk/gcc/../libdecnumber -I../../src-trunk/gcc/../libdecnumber/bid -I../libdecnumber  -DCLOOG_PPL_BACKEND  -I/usr/include/libelf  ../../src-trunk/gcc/recog.c -S -fcompare-debug
xgcc: error: ../../src-trunk/gcc/recog.c: -fcompare-debug failure
[hjl@gnu-29 stage3-gcc]$ 

Bernd, can you duplicate it?
Comment 11 Bernd Schmidt 2010-07-17 22:36:15 UTC
Created attachment 21238 [details]
Potential fix

Yeah, I think it trips over DEBUG_INSNs.  I'm testing this fix, does it help in any way?
Comment 12 Bernd Schmidt 2010-07-17 23:29:01 UTC
Created attachment 21239 [details]
Better patch.

Here's something that's a little more likely to work.
Comment 13 H.J. Lu 2010-07-18 00:32:25 UTC
(In reply to comment #12)
> Created an attachment (id=21239) [edit]
> Better patch.
> 
> Here's something that's a little more likely to work.
> 

I still got

Bootstrap comparison failure!
gcc/varasm.o differs
gcc/fortran/simplify.o differs
libiberty/regex.o differs
libiberty/pic/regex.o differs
make[4]: *** [compare] Error 1
Comment 14 Mikael Pettersson 2010-07-18 09:57:33 UTC
gcc-4.6 r162277 bootstrap failure on i686-linux:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/dwarf2out.o differs
gcc/reg-stack.o differs
gcc/reload.o differs
gcc/recog.o differs
gcc/i386.o differs
libiberty/hashtab.o differs
make[2]: *** [compare] Error 1

Configured just with --enable-languages=c and --with-gmp/mpfr/mpc paths.

Reverting r162270 fixes it.
Comment 15 Mikael Pettersson 2010-07-18 11:55:57 UTC
And on powerpc64-linux with gcc-4.6 r162277:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/tree-ssa.o differs
libiberty/regex.o differs
make[2]: *** [compare] Error 1

Configured just with --with-cpu=default32 --enable-languages=c
Comment 16 Mikael Pettersson 2010-07-18 12:31:04 UTC
And on sparc64-linux with gcc-4.6 r162277:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
libdecnumber/decimal32.o differs
libdecnumber/decimal64.o differs
libdecnumber/decimal128.o differs
make[2]: *** [compare] Error 1

Configured just --with-cpu=v8 --enable-languages=c
Comment 17 John David Anglin 2010-07-18 15:20:20 UTC
And on hppa64-hp-hpux11.11 gcc-4.6 162277 in stage2:

/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/g
cc-4.6.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11
/lib/ -isystem /opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/include -isystem /op
t/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/sys-include    -g -O2 -O2  -g -O2 -DIN
_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-protot
ypes -Wold-style-definition  -isystem ./include  -fPIC -Dpa64=1 -DELF=1 -mlong-c
alls -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I..
/.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/..
/gcc -I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o _popcountdi
2.o -MT _popcountdi2.o -MD -MP -MF _popcountdi2.dep -DL_popcountdi2 -c ../../../
gcc/libgcc/../gcc/libgcc2.c \
          -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/../gcc/libgcc2.c: In function '__popcountsi2':../../../gcc/l
ibgcc/../gcc/libgcc2.c: In function '__popcountdi2':

../../../gcc/libgcc/../gcc/libgcc2.c:791:1: internal compiler error: Segmentatio
n fault
Comment 18 H.J. Lu 2010-07-18 15:22:44 UTC
(In reply to comment #3)
> x86_64 failures are expected due to a backend bug, see the patch I sent today.
> 
> HJ, any chance you could run make check on the stage1 compiler on ia64 to find
> a testcase?
> 

New failures from revision 162264 to 162270 are:

FAIL: gcc.dg/20020425-1.c (internal compiler error)
FAIL: gcc.dg/20020425-1.c (test for excess errors)
Comment 19 Bernd Schmidt 2010-07-18 18:38:17 UTC
Created attachment 21242 [details]
Another patch

I've managed to reproduce some differences with -g vs. no-debug builds.  This patch fixes them for me.  I still didn't see it during bootstrap - do I need to do anything unusual (other than configure/make?)

There's one fix in there that may also help with miscompilations, although I still haven't managed to reproduce any of those either.  The ia64 crash HJ reported also doesn't happen here with a cross compiler.
Comment 20 H.J. Lu 2010-07-18 18:52:41 UTC
(In reply to comment #19)
> Created an attachment (id=21242) [edit]
> Another patch

I am testing it now.

> I've managed to reproduce some differences with -g vs. no-debug builds.  This
> patch fixes them for me.  I still didn't see it during bootstrap - do I need to
> do anything unusual (other than configure/make?)

What is your glibc version? I can reproduce it with glibc 2.11 and 2.12.

Comment 21 H.J. Lu 2010-07-18 19:03:46 UTC
(In reply to comment #19)
> Created an attachment (id=21242) [edit]
> Another patch
> 

This patch passed the last failure. I will report any regressions
in testsuite.
Comment 22 Mikael Pettersson 2010-07-18 19:53:22 UTC
And on armv5tel-linux-gnueabi with gcc-4.6 r162277:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/tree-ssa.o differs
gcc/sel-sched-ir.o differs
make[2]: *** [compare] Error 1

Configured just with --enable-languages=c --with-arch=armv5te --with-tune=xscale 
Comment 23 H.J. Lu 2010-07-18 20:34:47 UTC
(In reply to comment #19)
> Created an attachment (id=21242) [edit]
> Another patch
> 
> I've managed to reproduce some differences with -g vs. no-debug builds.  This
> patch fixes them for me.  I still didn't see it during bootstrap - do I need to
> do anything unusual (other than configure/make?)

This fixed bootstrap on Linux/ia32. There are no regressions in
gcc testsuite.

> 
> There's one fix in there that may also help with miscompilations, although I
> still haven't managed to reproduce any of those either.  The ia64 crash HJ
> reported also doesn't happen here with a cross compiler.

This still miscompiles 450.soplex.
Comment 24 Bernd Schmidt 2010-07-18 20:39:17 UTC
Created attachment 21243 [details]
Patch v4

I found another potential bug in the interaction between the existing code and the new one.  Fixing this doesn't seem to cause any code generation differences in any of the testcases I looked at, but maybe it could help with some of the bootstrap failures on other targets or with Spec2k6?
Comment 25 Bernd Schmidt 2010-07-18 20:40:19 UTC
(In reply to comment #17)
> And on hppa64-hp-hpux11.11 gcc-4.6 162277 in stage2:

> ../../../gcc/libgcc/../gcc/libgcc2.c:791:1: internal compiler error:
> Segmentatio
> n fault

If the latest patch does not fix this, could you run the testsuite on the stage1 compiler (i.e. make check in stage1-gcc or prev-gcc if the former doesn't exist)?

Comment 26 dave 2010-07-18 20:43:02 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap

Doing a non bootstrap build, I see the following new fail:
FAIL: gcc.c-torture/execute/950605-1.c execution,  -O1

f:
        .PROC
	.CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3
	.ENTRY
	std %r2,-16(%r30)
	ldi 255,%r28
	cmpb,= %r28,%r26,L$0003


The least significant byte of the argument passed in register %r26
is no longer extracted, causing compare to fail.  The is what I see
with gcc-4.4:

f:
        .PROC
	.CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3
	.ENTRY
	std %r2,-16(%r30)
	extrd,u %r26,63,8,%r26
	ldi 255,%r28
	cmpb,= %r28,%r26,L$0004

Dave
Comment 27 Bernd Schmidt 2010-07-18 21:00:38 UTC
(In reply to comment #26)
> Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap
> 
> Doing a non bootstrap build, I see the following new fail:
> FAIL: gcc.c-torture/execute/950605-1.c execution,  -O1

David, this seems to be caused by a different revision.  The postreload pass we're discussing here makes no changes to RTL on that testcase.  Please ensure you find the right revision that introduces a problem.

In this case, it probably was another of my changes that caused this failure, although I can't tell what's wrong.  The extend insn disappears during fwprop1:

-(insn 3 5 4 2 950605-1.c:3 (set (reg/v:DI 68 [ c+-7 ])
-        (zero_extend:DI (reg:SI 26 %r26 [ c+-3 ]))) 133 {*pa.md:4633} (nil))
+(note 5 0 4 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
 
-(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
+(note 4 5 7 2 NOTE_INSN_FUNCTION_BEG)
 
 (insn 7 4 8 2 950605-1.c:4 (set (reg:SI 69)
         (const_int 255 [0xff])) 71 {*pa.md:2130} (nil))
 
 (jump_insn 8 7 9 2 950605-1.c:4 (set (pc)
-        (if_then_else (eq (subreg/s/u:SI (reg/v:DI 68 [ c+-7 ]) 4)
+        (if_then_else (eq (reg:SI 26 %r26 [ c+-3 ])
                 (reg:SI 69))
             (label_ref:DI 23)
-            (pc))) 46 {*pa.md:1330} (expr_list:REG_BR_PROB (const_int 9996 [0x270c])
-        (nil))
+            (pc))) 46 {*pa.md:1330} (expr_list:REG_DEAD (reg:SI 69)
+        (expr_list:REG_DEAD (reg/v:DI 68 [ c+-7 ])
+            (expr_list:REG_BR_PROB (const_int 9996 [0x270c])
+                (nil))))

I can't find anything wrong with this, as it's a SImode comparison.  Is the backend emitting the correct compare instruction?

Comment 28 Bernd Schmidt 2010-07-18 21:15:13 UTC
Created attachment 21247 [details]
Minimally tested patch for the hppa problem

Seems like we're extending from the wrong mode.  Does this fix it?
Comment 29 dave 2010-07-18 21:15:37 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap

> David, this seems to be caused by a different revision.  The postreload pass
> we're discussing here makes no changes to RTL on that testcase.  Please ensure
> you find the right revision that introduces a problem.

Possibly, that is true.  The title of this PR was quite general.  Anyway,
I will start a new PR if there are multiple unrelated issues.  I will
determine the exact revision.  Last successful bootstrap on this target
was 162195.

> -(insn 3 5 4 2 950605-1.c:3 (set (reg/v:DI 68 [ c+-7 ])
> -        (zero_extend:DI (reg:SI 26 %r26 [ c+-3 ]))) 133 {*pa.md:4633} (nil))
> +(note 5 0 4 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

It looks to me like the extend insn is wrong.  With 4.4, we had

(insn 4 3 5 2 /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/950605-1.c:3
 (set (reg/v:DI 68 [ c+-7 ])
	 (zero_extend:DI (subreg:QI (reg:SI 69) 3))) -1 (nil))

> I can't find anything wrong with this, as it's a SImode comparison.  Is the
> backend emitting the correct compare instruction?

The backend has only SImode and DImode comparisons.

Dave
Comment 30 H.J. Lu 2010-07-18 22:22:40 UTC
(In reply to comment #24)
> Created an attachment (id=21243) [edit]
> Patch v4
> 
> I found another potential bug in the interaction between the existing code and
> the new one.  Fixing this doesn't seem to cause any code generation differences
> in any of the testcases I looked at, but maybe it could help with some of the
> bootstrap failures on other targets or with Spec2k6?
> 

This doesn't fix SPEC CPU 2006.
Comment 31 Dominique d'Humieres 2010-07-19 07:53:56 UTC
(In reply to comment #24)
> Created an attachment (id=21243) [edit]
> Patch v4

This patch (with/without the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt) does not fix the bootstrap failure on x86_64-apple-darwin10.4.
Comment 32 Jack Howarth 2010-07-19 13:25:44 UTC
On x86_64-apple-darwin10, the bootstrap failure at r162303 is exhibited as a miscompiled build/genattrtab...


/Users/howarth/darwin_objdir/./prev-gcc/xgcc -B/Users/howarth/darwin_objdir/./prev-gcc/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/bin/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/bin/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/lib/ -isystem /Users/howarth/dist/x86_64-apple-darwin10.4.0/include -isystem /Users/howarth/dist/x86_64-apple-darwin10.4.0/sys-include      -g -O2 -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc  \
		build/gcov-iov.o -o build/gcov-iov
build/gcov-iov '4.6.0' 'experimental' \
	    > tmp-gcov-iov.h
/bin/sh ../../gcc/gcc/../move-if-change tmp-gcov-iov.h gcov-iov.h
/bin/sh: line 1: 30108 Illegal instruction     build/genattrtab ../../gcc/gcc/config/i386/i386.md insn-conditions.md > tmp-attrtab.c


gdb ./build/genattrtab

(gdb) r ../../gcc/gcc/config/i386/i386.md insn-conditions.md > tmp-attrtab.c
Starting program: /Users/howarth/darwin_objdir/gcc/build/genattrtab ../../gcc/gcc/config/i386/i386.md insn-conditions.md > tmp-attrtab.c
Reading symbols for shared libraries +. done

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x00000001000025f7 in attr_rtx ()
(gdb) bt
#0  0x00000001000025f7 in attr_rtx ()
#1  0x0000000100004a8c in check_attr_test ()
#2  0x000000010000482b in check_attr_test ()
#3  0x000000010000483e in check_attr_test ()
#4  0x0000000100004edd in check_attr_value ()
#5  0x0000000100008985 in main ()
(gdb) 
Comment 33 dave 2010-07-19 14:31:19 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap

> This patch (with/without the patch in
> http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt) does not fix the
> bootstrap failure on x86_64-apple-darwin10.4.

Same on hppa64-hp-hpux11.11.  With the rc-fix4.diff and entrymode.diff
patches, we still fail compiling libgcc in stage2, although at a slightly
different spot:

/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/g
cc-4.6.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11
/lib/ -isystem /opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/include -isystem /op
t/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/sys-include    -g -O2 -O2  -g -O2 -DIN
_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-protot
ypes -Wold-style-definition  -isystem ./include  -fPIC -Dpa64=1 -DELF=1 -mlong-c
alls -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I..
/.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/..
/gcc -I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o __gcc_bcmp.
o -MT __gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c ../../../gcc/libg
cc/../gcc/libgcc2.c \
          -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/../gcc/libgcc2.c: In function '__gcc_bcmp':
../../../gcc/libgcc/../gcc/libgcc2.c:1979:1: internal compiler error: Segmentati

Dave
Comment 34 Dominique d'Humieres 2010-07-20 06:46:14 UTC
At revision 162313, bootstrap failed on powerpc-apple-darwin9 
Configured with: ../gcc-4.6-work/configure --prefix=/opt/gcc/gcc4.6w --build=powerpc-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-cloog=/sw --enable-lto

...
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/java/expr.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [all] Error 2
Comment 35 Bernd Schmidt 2010-07-20 14:21:45 UTC
Created attachment 21264 [details]
Another attempt to fix the pa64 problem

David, here's a new patch which might fix the PA problem.  Please apply it to current trunk.  I don't have access to a hppa64 machine unfortunately.
Comment 36 Bernd Schmidt 2010-07-20 15:35:10 UTC
I've committed another fix for the (not only) powerpc problem as r162342.
Comment 37 dave 2010-07-21 01:37:32 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
	to bootstrap

On Tue, 20 Jul 2010, bernds at gcc dot gnu dot org wrote:

> David, here's a new patch which might fix the PA problem.  Please apply it to
> current trunk.  I don't have access to a hppa64 machine unfortunately.

Unforunately, it doesn't fix the last bootstap issue.

With the previous change, the testsuite error was fixed.  There were
no testsuite regressions with it.

Dave
Comment 38 Bernd Schmidt 2010-07-21 22:48:36 UTC
Subject: Bug 44970

Author: bernds
Date: Wed Jul 21 22:48:14 2010
New Revision: 162390

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162390
Log:
	PR bootstrap/44970
	PR middle-end/45009
	* postreload.c: Include "target.h".
	(reload_combine_closest_single_use): Don't take DEBUG_INSNs
	into account.
	(fixup_debug_insns): Don't copy the rtx.
	(reload_combine_recognize_const_pattern): DEBUG_INSNs can't
	have uses.  Don't copy when replacing.  Call fixup_debug_insns
	in the case where we merged one add with another.
	(reload_combine_recognize_pattern): Fail if there aren't any
	uses.  Try harder to determine whether we're picking a valid
	index register.  Don't set store_ruid for an insn we're going
	to scan in the next iteration.
	(reload_combine): Remove unused code.
	(reload_combine_note_use): When updating use information for
	an old insn, ignore a use that occurs after store_ruid.
	* Makefile.in (postreload.o): Update dependencies.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/postreload.c

Comment 39 Bernd Schmidt 2010-07-22 11:48:44 UTC
HJ, Dave, can you retest with mainline?
Comment 40 H.J. Lu 2010-07-22 14:07:31 UTC
(In reply to comment #39)
> HJ, Dave, can you retest with mainline?
> 

Mainline bootstrap is OK on ia32 and Intel64
as of revision 162408. Test is in progress
on ia64.
Comment 41 dave 2010-07-22 14:26:30 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap

> HJ, Dave, can you retest with mainline?

Testing.

With the previous versions, hash table lookups were somehow broken,
resulting in NULL being returned by the call to htab_find in get_bb_copy.
Don't know why.

Dave
Comment 42 H.J. Lu 2010-07-22 16:47:44 UTC
(In reply to comment #40)
> (In reply to comment #39)
> > HJ, Dave, can you retest with mainline?
> > 
> 
> Mainline bootstrap is OK on ia32 and Intel64
> as of revision 162408. Test is in progress
> on ia64.
> 

Revision 162399 bootstraps OK on Linux/ia64.
Comment 43 dave 2010-07-22 18:16:15 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap

> HJ, Dave, can you retest with mainline?

Still same problem.  I'm trying with function.c reverted to 162239.

Dave
Comment 44 dave 2010-07-22 22:46:46 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap

> > HJ, Dave, can you retest with mainline?
> 
> Still same problem.  I'm trying with function.c reverted to 162239.

I had a success bootstrap with revision 162414 and function.c reverted
to 162239.

Dave
Comment 45 Bernd Schmidt 2010-07-22 22:54:32 UTC
(In reply to comment #44)

> I had a success bootstrap with revision 162414 and function.c reverted
> to 162239.

Did the failing bootstrap include the function.c fix in r162391, or was it an earlier revision?
Comment 46 dave 2010-07-22 22:57:46 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap

> Did the failing bootstrap include the function.c fix in r162391, or was it an
> earlier revision?

I believe that it did.  It was done after you requested HJ and myself to
retest mainline.

Dave
Comment 47 dave 2010-07-29 15:05:08 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
	to bootstrap

On Mon, 19 Jul 2010, dave at hiauly1 dot hia dot nrc dot ca wrote:

> 
> 
> ------- Comment #33 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-19 14:31 -------
> Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap
> 
> > This patch (with/without the patch in
> > http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt) does not fix the
> > bootstrap failure on x86_64-apple-darwin10.4.
> 
> Same on hppa64-hp-hpux11.11.  With the rc-fix4.diff and entrymode.diff
> patches, we still fail compiling libgcc in stage2, although at a slightly
> different spot:
> 
> /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
> -B/opt/gnu64/gcc/g
> cc-4.6.0/hppa64-hp-hpux11.11/bin/
> -B/opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11
> /lib/ -isystem /opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/include -isystem
> /op
> t/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/sys-include    -g -O2 -O2  -g -O2
> -DIN
> _GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
> -Wmissing-protot
> ypes -Wold-style-definition  -isystem ./include  -fPIC -Dpa64=1 -DELF=1
> -mlong-c
> alls -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
> -I..
> /.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
> -I../../../gcc/libgcc/..
> /gcc -I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
> __gcc_bcmp.
> o -MT __gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c
> ../../../gcc/libg
> cc/../gcc/libgcc2.c \
>           -fvisibility=hidden -DHIDE_EXPORTS
> ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__gcc_bcmp':
> ../../../gcc/libgcc/../gcc/libgcc2.c:1979:1: internal compiler error:
> Segmentati

It appears cfg.c is being miscompiled.  Replacing stage2 version with
stage1 version results in the above compilation completing successfully.

This is the backtrace as much as can be trusted:

Program received signal SIGSEGV, Segmentation fault.
find_edge (pred=0x800003fffdf8e750, succ=0x0) at ../../gcc/gcc/cfganal.c:492
492       if (EDGE_COUNT (pred->succs) <= EDGE_COUNT (succ->preds))
(gdb) bt
#0  find_edge (pred=0x800003fffdf8e750, succ=0x0)
    at ../../gcc/gcc/cfganal.c:492
#1  0x40000000002ba014 in redirect_edge_succ_nodup (e=0x800003fffdcd1f00, 
    new_succ=0x0) at ../../gcc/gcc/cfg.c:398
#2  0x4000000000749f1c in ssa_redirect_edge (e=0x800003fffdcd1f00, dest=0x0)
    at ../../gcc/gcc/tree-ssa.c:207
#3  0x40000000005f2330 in gimple_redirect_edge_and_branch (
    e=0x800003fffdcd1f00, dest=0x0) at ../../gcc/gcc/tree-cfg.c:4951
#4  0x40000000005f29d4 in gimple_redirect_edge_and_branch_force (
    e=<value optimized out>, dest=<value optimized out>)
    at ../../gcc/gcc/tree-cfg.c:4973
#5  0x40000000002cf08c in redirect_edge_and_branch_force (
    e=0x800003fffdcd1f00, dest=0x0) at ../../gcc/gcc/cfghooks.c:400
#6  0x40000000002d3aa4 in copy_bbs (bbs=0x800000010014f820, 
    n=<value optimized out>, new_bbs=<value optimized out>, 
    edges=0x800003fffdff1578, num_edges=1, new_edges=0x800003fffdff15e8, 
    base=<value optimized out>, after=<value optimized out>)
    at ../../gcc/gcc/cfglayout.c:1452

Attached cfg.i and cfg.s from stage2, and cc1 command.

Dave
Comment 48 dave 2010-07-29 15:05:09 UTC
Created attachment 21352 [details]
cfg.i.gz
Comment 49 dave 2010-07-29 15:05:09 UTC
Created attachment 21353 [details]
cfg.s.gz
Comment 50 dave 2010-07-29 15:05:09 UTC
Created attachment 21354 [details]
yy.sh
Comment 51 Bernd Schmidt 2010-07-29 19:46:36 UTC
Thanks.  I can more-or-less produce the same assembly with a cross compiler, but just from looking at the assembly and the debugging dumps I can't quite figure out which function is being miscompiled.  Can you produce a good (not miscompiled) .s file with a working cc1 and attach that as well for comparison?  It would help massively if you could do a search similar to that for the miscompiled .o file, this time to find the miscompiled function.  That can be done by replacing those functions that differ in the assembly files one by one and then compiling the modified assembly file to .o and producing a cc1 binary as previously.
Comment 52 dave 2010-07-30 02:27:42 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
	to bootstrap

On Thu, 29 Jul 2010, bernds at gcc dot gnu dot org wrote:

> ------- Comment #51 from bernds at gcc dot gnu dot org  2010-07-29 19:46 -------
> Thanks.  I can more-or-less produce the same assembly with a cross compiler,
> but just from looking at the assembly and the debugging dumps I can't quite
> figure out which function is being miscompiled.  Can you produce a good (not
> miscompiled) .s file with a working cc1 and attach that as well for comparison?

It probably will be several days before I can look at this again.  My
daughter is getting married this Saturday.

Dave
Comment 53 dave 2010-07-30 15:09:37 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
	to bootstrap

On Thu, 29 Jul 2010, bernds at gcc dot gnu dot org wrote:

> ------- Comment #51 from bernds at gcc dot gnu dot org  2010-07-29 19:46 -------
> Thanks.  I can more-or-less produce the same assembly with a cross compiler,
> but just from looking at the assembly and the debugging dumps I can't quite
> figure out which function is being miscompiled.  Can you produce a good (not
> miscompiled) .s file with a working cc1 and attach that as well for comparison?

Just one further point, I know that the problem is related to

2010-07-16  Bernd Schmidt  <bernds@codesourcery.com>

        PR target/42235
	* function.c (record_hard_reg_sets): New static function.
	(assign_parm_setup_reg): If an optab for extending exists and the
	generated code clobbbers no hard regs, emit the insn directly and
	create a REG_EQUIV note.

At least at one time, reverting this change restored bootstrap.  It probably
would be useful to compare .s files with and without this change.

Dave
Comment 54 Bernd Schmidt 2010-07-30 15:12:49 UTC
Yeah, that's what I did.  I if (0)ed the newly added code block to produce comparisons, but I haven't found anything yet that looks wrong in the dumps (and I can't read PA assembly very well).  So it would be useful to pinpoint the problem further.
Comment 55 dave 2010-08-04 19:52:23 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
	to bootstrap

The exception is caused by get_bb_copy returning NULL.  However, get_bb_copy
is not miscompiled.

The change to function.c changes various copies to extracts for
zero/sign extension.  These might cause a functional difference.
For example,

-       copy %r26,%r23
+       extrd,u %r26,63,32,%r23

It won't be easy to substitute functions in the .s file because
there are a many label changes.

Dave
Comment 56 Bernd Schmidt 2010-08-05 11:31:04 UTC
Created attachment 21400 [details]
A patch to aid debugging

This patch should help pinpoint exactly what went wrong.  It adds a dbg-cnt to the code in question.

If you could experiment with passing -fdbg-cnt=bug:N to the compiler, where N is an integer value, using a binary search you should arrive relatively quickly at a value of N where the generated code is OK for N but fails for N + 1.  Then, could you attach good/bad assembly files and debug dumps?  Just the .expand, .combine and .ira dumps initially would be helpful if we want to save disk space here.
Comment 57 dave 2010-08-05 19:26:00 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
	to bootstrap

On Thu, 05 Aug 2010, bernds at gcc dot gnu dot org wrote:

> If you could experiment with passing -fdbg-cnt=bug:N to the compiler, where N
> is an integer value, using a binary search you should arrive relatively quickly
> at a value of N where the generated code is OK for N but fails for N + 1. 
> Then, could you attach good/bad assembly files and debug dumps?  Just the
> .expand, .combine and .ira dumps initially would be helpful if we want to save
> disk space here.

Failure occurs for N = 0.  N = 1 compiles successfully.  Attached files.

Dave
Comment 58 dave 2010-08-05 19:26:00 UTC
Created attachment 21403 [details]
cfg.s.0.gz
Comment 59 dave 2010-08-05 19:26:00 UTC
Created attachment 21404 [details]
cfg.c.146r.expand.0.gz
Comment 60 dave 2010-08-05 19:26:01 UTC
Created attachment 21405 [details]
cfg.c.181r.combine.0.gz
Comment 61 dave 2010-08-05 19:26:01 UTC
Created attachment 21406 [details]
cfg.c.193r.ira.0.gz
Comment 62 dave 2010-08-05 19:26:01 UTC
Created attachment 21407 [details]
cfg.s.1.gz
Comment 63 dave 2010-08-05 19:26:01 UTC
Created attachment 21408 [details]
cfg.c.146r.expand.1.gz
Comment 64 dave 2010-08-05 19:26:01 UTC
Created attachment 21409 [details]
cfg.c.181r.combine.1.gz
Comment 65 dave 2010-08-05 19:26:01 UTC
Created attachment 21410 [details]
cfg.c.193r.ira.1.gz
Comment 66 Bernd Schmidt 2010-08-05 19:56:15 UTC
(In reply to comment #57)

> Failure occurs for N = 0.  N = 1 compiles successfully.  Attached files.

Argh.  I seem to have swapped the logic of the dbg_cnt test.  Still, this result appears useful.

I think initial RTL generation is fine, so it looks like my change has exposed a latent bug.  What seems to happen is that some pass between expand and combine lengthens the lifetime of register %r25, which holds an incoming argument, so that it now crosses another call, which clobbers it.

This seems to happen in fwprop1, Cc Paolo.  I can't find any code in that pass which tries to handle the situation.
Comment 67 dave 2010-08-05 20:54:02 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed to bootstrap

> I think initial RTL generation is fine, so it looks like my change has exposed
> a latent bug.  What seems to happen is that some pass between expand and
> combine lengthens the lifetime of register %r25, which holds an incoming
> argument, so that it now crosses another call, which clobbers it.
> 
> This seems to happen in fwprop1, Cc Paolo.  I can't find any code in that pass
> which tries to handle the situation.

Yes, the rtl generated by fwprop1 is wrong as r25 is clobbered by the call
to pool_alloc.

Dave
Comment 68 Paolo Bonzini 2010-08-06 07:07:29 UTC
fwprop.c doesn't handle it directly, but local_ref_killed_between_p should see defs created by df-scan.c for each hard register in regs_invalidated_by_call (see df_get_call_refs).

Also, since fwprop can lengthen lifetimes arbitrarily (though this wouldn't happen often) propagate_rtx actually forbids copy propagation of hard registers:

  if (REG_P (new_rtx) && REGNO (new_rtx) < FIRST_PSEUDO_REGISTER)
    return NULL_RTX;
Comment 69 Bernd Schmidt 2010-08-06 09:29:39 UTC
(In reply to comment #68)

> Also, since fwprop can lengthen lifetimes arbitrarily (though this wouldn't
> happen often) propagate_rtx actually forbids copy propagation of hard
> registers:
> 
>   if (REG_P (new_rtx) && REGNO (new_rtx) < FIRST_PSEUDO_REGISTER)
>     return NULL_RTX;

Clearly that isn't working.  Maybe it's because we have (zero_extend (hardreg))?
Comment 70 Paolo Bonzini 2010-08-06 09:54:18 UTC
The real reason is the first: why is there no def for r25?
Comment 71 Bernd Schmidt 2010-08-06 09:57:46 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
 to bootstrap

On 08/06/2010 11:54 AM, bonzini at gnu dot org wrote:
> ------- Comment #70 from bonzini at gnu dot org  2010-08-06 09:54 -------
> The real reason is the first: why is there no def for r25?

Because it's an incoming argument.
Comment 72 Paolo Bonzini 2010-08-06 10:00:45 UTC
No, why is there no def for r25 _where it is clobbered_?
Comment 73 Bernd Schmidt 2010-08-06 10:27:15 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
 to bootstrap

On 08/06/2010 12:00 PM, bonzini at gnu dot org wrote:
> ------- Comment #72 from bonzini at gnu dot org  2010-08-06 10:00 -------
> No, why is there no def for r25 _where it is clobbered_?

There is.  The problem seems to be that we first propagate into insn 15,
which then looks like

(insn 15 14 16 3 (set (reg:DI 67 [ obj.8+-4 ])
        (sign_extend:DI (reg:SI 25 %r25 [ obj ])))
../../gcc/gcc/cfg.c:1211 139 {extendsidi2}
     (expr_list:REG_DEAD (reg/v:DI 74 [ obj+-4 ])
        (nil)))

and from there, we propagate into another insn.  However, at this point,
insn 15 has no uses associated with it, so all_uses_available_at returns
true without doing anything.
Comment 74 Paolo Bonzini 2010-08-06 13:38:40 UTC
Thanks for the help.  I'll look at it tomorrow/next week.
Comment 75 Steve Ellcey 2010-08-23 20:49:18 UTC
Paolo, are you looking at this?  The hppa64-*-* bootstrap is still broken.
Comment 76 Paolo Bonzini 2010-08-24 06:50:36 UTC
Subject: Re:  [4.6 regression] Revision 162270 failed
 to bootstrap

On 08/23/2010 10:49 PM, sje at cup dot hp dot com wrote:
> ------- Comment #75 from sje at cup dot hp dot com  2010-08-23 20:49 -------
> Paolo, are you looking at this?  The hppa64-*-* bootstrap is still broken.

Yes, I'll submit a patch this week.
Comment 77 Bernd Schmidt 2010-08-24 13:13:58 UTC
We might also want to throttle back the change in function.c so that it's only enabled when extending from a memory location.  But it still would be good to know and fix what exactly is going wrong in fwprop.
Comment 78 Paolo Bonzini 2010-08-24 13:44:08 UTC
My plan for fwprop is to replace the whole update_df machinery with a call to df_uses_record.  The use-def links can be kept up to date by looking at the original uses of both the propagated-from and propagated-into instructions.
Comment 79 Paolo Bonzini 2010-09-04 16:49:58 UTC
Created attachment 21699 [details]
incomplete patch

This shows what I plan to do.  It doesn't even compile stage2, so it is more or less useless.  Still here it is.
Comment 80 Laurent GUERBY 2010-09-25 06:31:12 UTC
On arm-linux as of r164594

/home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/ -B/n/57/guerby/install-trunk-164594/armv5tel-unknown-linux-gnueabi/bin/ -B/n/57/guerby/install-trunk-164594/armv5tel-unknown-linux-gnueabi/lib/ -isystem /n/57/guerby/install-t\
runk-164594/armv5tel-unknown-linux-gnueabi/include -isystem /n/57/guerby/install-trunk-164594/armv5tel-unknown-linux-gnueabi/sys-include    -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmiss\
ing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I../../../trunk/libgcc -I../../../trunk/libgcc/. -I../../.\
./trunk/libgcc/../gcc -I../../../trunk/libgcc/../include  -DHAVE_CC_TLS  -o _popcountsi2.o -MT _popcountsi2.o -MD -MP -MF _popcountsi2.dep -DL_popcountsi2 -c ../../../trunk/libgcc/../gcc/libgcc2.c \
          -fvisibility=hidden -DHIDE_EXPORTS
../../../trunk/libgcc/../gcc/libgcc2.c: In function '__popcountsi2':
../../../trunk/libgcc/../gcc/libgcc2.c:783:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [_popcountsi2.o] Error 1
make[3]: Leaving directory `/home/guerby/build/armv5tel-unknown-linux-gnueabi/libgcc'
make[2]: *** [all-stage2-target-libgcc] Error 2
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
Comment 81 Laurent GUERBY 2010-10-12 17:43:19 UTC
Now testing r165387 + Paolo patch as this seems to be the last PR preventing bootstrap on arm-linux.
Comment 82 Paolo Bonzini 2010-10-13 07:36:45 UTC
My patch is not finished and doesn't bootstrap, I'll look at it (promised) next weekend.  I suggest just using BOOT_CFLAGS="-O2 -fno-forward-propagate".
Comment 83 dave 2010-10-13 11:42:45 UTC
> My patch is not finished and doesn't bootstrap, I'll look at it (promised) next
> weekend.  I suggest just using BOOT_CFLAGS="-O2 -fno-forward-propagate".

I'll give it a try.  Currently, I have Bernd's change reverted.

Dave
Comment 84 Steve Ellcey 2010-10-13 17:36:15 UTC
> > My patch is not finished and doesn't bootstrap, I'll look at it (promised) next
> > weekend.  I suggest just using BOOT_CFLAGS="-O2 -fno-forward-propagate".
> 
> I'll give it a try.  Currently, I have Bernd's change reverted.
> 
> Dave

I have done this on hppa64-hp-hpux11.11 and it worked for me.  (Actually, I tweaked the code to turn off the forward propogate pass.)
Comment 85 Paolo Bonzini 2010-10-18 17:20:05 UTC
Created attachment 22079 [details]
patch

I haven't yet tested this on a cross-compiler, but it bootstrapped and regtested fine on x86_64-pc-linux-gnu.
Comment 86 Steve Ellcey 2010-10-18 19:52:39 UTC
I was able to bootstrap the 32 bit PA compiler using the latest patch. I haven't done a full test run yet but I will do that overnight.
Comment 87 Steve Ellcey 2010-10-19 16:09:57 UTC
My testing on 32 bit and 64 bit PA boxes went fine.  The patch looks good to me.
Comment 88 John David Anglin 2010-10-20 13:41:38 UTC
(In reply to comment #85)
> Created attachment 22079 [details]
> patch
> I haven't yet tested this on a cross-compiler, but it bootstrapped and
> regtested fine on x86_64-pc-linux-gnu.

I also tested the patch on armv5tejl-unknown-linux-gnueabi.  The ICE in
function '__popcountsi2' is still there, so this must be a separate issue.
Comment 89 Paolo Bonzini 2010-10-20 14:09:33 UTC
The armv5 failure is a stage2 miscompilation.  Is it caused by Bernd's patch too?  Or by fwprop?

According to comment 22, previously it was not bootstrapping but the failure was elsewhere.  But we don't know if it is one or two bugs, and we don't know how it relates with the fwprop problem (which was latent all the time even before Bernd's patch).  The only good news is that a stage2 libgcc crash is slightly simpler to debug than a stage3 comparison failure.  In any case, the next thing to do is to bisect to find where the crash appeared, then go to the previous revision, try applying my patch and see if it fixes the failure of comment 22.
Comment 90 dave 2010-10-20 14:39:26 UTC
> The armv5 failure is a stage2 miscompilation.  Is it caused by Bernd's patch
> too?  Or by fwprop?

Actually, the ICE I saw this morning was in stage3.  This box is only
accessible at my contractor's site, so my access to it is limited.

Dave
Comment 91 Steve Ellcey 2010-10-29 22:29:10 UTC
I just noticed that the latest patch is causing a failure of gfortran.dg/large_real_kind_2.F90 with -O1 on my ia64-hp-hpux11.23 platform.

Note that the original bug we were fixing was on hppa, not ia64, and this test doesn't fail on hppa.

On IA64 I am getting a segfault in fwprop:


#0  0x496a5c0:0 in VEC_df_mw_hardreg_ptr_stack_reserve (vec_=0xc, alloc_=1, 
    file_=0x41ac338 "/proj/opensrc/sje/reg/src/trunk/gcc/df-scan.c", 
    line_=2881, function_=0x41aca48 "df_ref_record")
#1  0x496a810:0 in VEC_df_mw_hardreg_ptr_stack_safe_push (vec_=0xc, 
    obj_=0x40936f30, 
    file_=0x41ac338 "/proj/opensrc/sje/reg/src/trunk/gcc/df-scan.c", 
    line_=2881, function_=0x41aca48 "df_ref_record")
#2  0x4984470:0 in df_ref_record (cl=DF_REF_REGULAR, collection_rec=0x0, 
    reg=0x65436df8, loc=0x6543b18c, bb=0x653da048, insn_info=0x40416b80, 
    ref_type=DF_REF_REG_USE, ref_flags=4096)
#3  0x49858f0:0 in df_uses_record (collection_rec=0x0, loc=0x6543b18c, 
    ref_type=DF_REF_REG_USE, bb=0x653da048, insn_info=0x40416b80, flags=0)
#4  0x4985bc0:0 in df_uses_record (collection_rec=0x0, loc=0x65438b08, 
    ref_type=DF_REF_REG_USE, bb=0x653da048, insn_info=0x40416b80, flags=0)
#5  0x496fd40:0 in df_uses_create (loc=0x65438b08, insn=0x65438af0, 
    ref_flags=0)
#6  0x6217f60:0 in try_fwprop_subst (use=0x4044b910, loc=0x6543b1a8, 
    new_rtx=0x652d0050, def_insn=0x65438a28, set_reg_equal=0 '\000')
#7  0x621afd0:0 in forward_propagate_and_simplify (use=0x4044b910, 
    def_insn=0x65438a28, def_set=0x65439ef0)
#8  0x621b780:0 in forward_propagate_into (use=0x4044b910)
#9  0x621bff0:0 in fwprop ()
Comment 92 Paolo Bonzini 2010-10-29 22:33:04 UTC
See followup here: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01636.html
Comment 93 Steve Ellcey 2010-10-29 22:39:00 UTC
(In reply to comment #92)
> See followup here: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01636.html

Ah yes, that's better.
Comment 94 John David Anglin 2010-11-08 16:39:09 UTC
Created attachment 22330 [details]
ioctl.i.gz

In doing a 2.6.36 kernel build with

dave@mx3210:~/opt/gnu/gcc64/bin$ ./hppa64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=./hppa64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/dave/opt/gnu/gcc64/libexec/gcc/hppa64-linux-gnu/4.6.0/lto-wrapper
Target: hppa64-linux-gnu
Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/bin/hppa64-linux-gnu-as --with-gnu-ld --with-ld=/usr/bin/hppa64-linux-gnu-ld --disable-shared --disable-nls --prefix=/home/dave/opt/gnu/gcc64 --disable-threads --disable-target-libiberty --disable-libmudflap --disable-libssp --build=hppa-linux-gnu --host=hppa-linux-gnu --target=hppa64-linux-gnu --enable-languages=c --disable-bootstrap
Thread model: single
gcc version 4.6.0 20101108 (experimental) [trunk revision 166433] (GCC)

I get the following assertion failure:

  CC      fs/ioctl.o
fs/ioctl.c: In function 'do_vfs_ioctl':
fs/ioctl.c:601:1: internal compiler error: in update_df, at fwprop.c:877
Please submit a full bug report,
Comment 95 dave 2010-11-08 17:00:41 UTC
>   CC      fs/ioctl.o
> fs/ioctl.c: In function 'do_vfs_ioctl':
> fs/ioctl.c:601:1: internal compiler error: in update_df, at fwprop.c:877
> Please submit a full bug report,

Here is full compile command:

hppa64-linux-gnu-gcc -Wp,-MD,fs/.ioctl.o.d  -nostdinc -isystem /home/dave/opt/gnu/gcc64/lib/gcc/hppa64-linux-gnu/4.6.0/include -I/home/dave/linux/linux-2.6.36.y/arch/parisc/include -Iinclude  -include include/generated/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -pipe -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000 -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ioctl)"  -D"KBUILD_MODNAME=KBUILD_STR(ioctl)"  -c -o fs/ioctl.o fs/ioctl.c

Attached preprocessed source.
Comment 96 Mikael Pettersson 2010-11-08 17:24:29 UTC
(In reply to comment #88)
> I also tested the patch on armv5tejl-unknown-linux-gnueabi.  The ICE in
> function '__popcountsi2' is still there, so this must be a separate issue.

I have bisected the __popcountsi2 ICE on arm, and it's caused by the infamous r164552.  That revision has recently been reverted, so current trunk should hopefully be better.
Comment 97 H.J. Lu 2010-11-08 17:30:36 UTC
(In reply to comment #96)
> (In reply to comment #88)
> > I also tested the patch on armv5tejl-unknown-linux-gnueabi.  The ICE in
> > function '__popcountsi2' is still there, so this must be a separate issue.
> 
> I have bisected the __popcountsi2 ICE on arm, and it's caused by the infamous
> r164552.  That revision has recently been reverted, so current trunk should
> hopefully be better.

I suggest you open a bug report, if there isn't one already, and make it
depend on PR 46257 so that Bernds can double check it when he works on
the proper fix.
Comment 98 Paolo Bonzini 2010-11-14 22:35:54 UTC
Minimized testcase:

int f (unsigned long arg, int *cr)
{
  int *p = (int *) arg;
  int x = *cr;
  long pu_err = 0;
  if (x)
    asm volatile ("stw %2,0(%1)": "=r" (pu_err): "r" (p), "r" (x));

  asm volatile ("stw %2,0(%%sr3,%1)": "=r" (pu_err): "r" (p), "r" (x));
  return pu_err;
}

Fails at -O2.
Comment 99 dave 2010-11-14 23:12:25 UTC
On Sun, 14 Nov 2010, bonzini at gnu dot org wrote:

> Minimized testcase:
> 
> int f (unsigned long arg, int *cr)
> {
>   int *p = (int *) arg;
>   int x = *cr;
>   long pu_err = 0;
>   if (x)
>     asm volatile ("stw %2,0(%1)": "=r" (pu_err): "r" (p), "r" (x));
> 
>   asm volatile ("stw %2,0(%%sr3,%1)": "=r" (pu_err): "r" (p), "r" (x));
>   return pu_err;
> }
> 
> Fails at -O2.

Cool!  The reduced code no longer makes any sense but it should compile.
I'm sure this was a fair bit of work.

Dave
Comment 100 Paolo Bonzini 2010-11-14 23:34:28 UTC
> Cool!  The reduced code no longer makes any sense but it should compile.
> I'm sure this was a fair bit of work.

Actually delta made all the work down to 31 lines of typedefs/structs and 35 lines of mostly-dead code.  All I did manually was remove the remaining Linux structs (replacing them with multiple scalars), propagate constants, and little more.

Anyway, I have a new patch that I'm bootstrapping; forward_propagate_asm wasn't adjusting use->def info properly, and the new stricter checking caught that.  To avoid code duplication the patch is a bit different from the other.  It's more aesthetic differences than practical differences in behavior, but still I prefer to test it first on x86_64 before posting it.  It should take only a day or two.
Comment 102 Paolo Bonzini 2010-11-22 16:20:26 UTC
Author: bonzini
Date: Mon Nov 22 16:20:16 2010
New Revision: 167038

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167038
Log:
2010-11-22  Paolo Bonzini<bonzini@gnu.org>

	PR bootstrap/44970
	* Makefile.in (fwprop.o) Add sparseset.h.
	* fwprop.c: Include sparseset.h
	(struct find_occurrence_data, find_occurrence_callback,
	find_occurrence): Remove.
	(active_defs, active_defs_check, register_active_defs,
	update_df_init, update_uses): New.
	(update_df): Rewrite.
	(try_fwprop_subst, forward_propagate_asm): Add calls to
	update_df_init and update_df.
	(fwprop_init): Allocate active_defs and active_defs_check.
	(fwprop_done): Free them.
	(fwprop, fwprop_addr): Adjust comments.
	* df.h (df_uses_create): Declare.
	* df-scan.c (df_install_ref_incremental): Break out of df_ref_create.
	(df_ref_create): Return result of df_ref_create_structure directly.
	(df_ref_create_structure): Call df_install_ref_incremental when
	no collection_rec is passed.
	(df_ref_record): Do not create multiword hard reg info when no
	collection_rec is passed.
	(df_uses_create): New. 


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/df-scan.c
    trunk/gcc/df.h
    trunk/gcc/fwprop.c
Comment 103 Jakub Jelinek 2010-11-22 17:18:07 UTC
Fixed.