This is a all native powerpc64-linux build enviroment, which itself is compiled with the current hammer-3_3-branch. The script below fails in the last function call. It does work if I compile a gcc-4.0.0-20040913 with itself. A simple 'build_one_try gcc4-1 ~/src/gcc-head ; build_one_try gcc4-2 ~/src/gcc-head' fails as well. A 'export CFLAGS=-O1' does not fix it. Trying the snapshots between September and March now. abuild@tangelo:~/objgcc-gcc4-3/gcc> ./xgcc -B./ -B/home/abuild/install_gcc4-3/powerpc64-unknown-linux-gnu/bin/ -isystem /home/abuild/install_gcc4-3/powerpc64-unknown-linux-gnu/include -isystem /home/abuild/install_gcc4-3/powerpc64-unknown-linux-gnu/sys-include -L/home/abuild/objgcc-gcc4-3/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem /include -I. -I. -I/home/abuild/src/gcc-head/gcc -I/home/abuild/src/gcc-head/gcc/. -I/home/abuild/src/gcc-head/gcc/../include -I/home/abuild/src/gcc-head/gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fPIC -msdata=none -c /home/abuild/src/gcc-head/gcc/crtstuff.c -DCRT_END -DCRTSTUFFS_O -o crtendS.o In file included from /usr/include/stdio.h:830, from /home/abuild/src/gcc-head/gcc/tsystem.h:90, from /home/abuild/src/gcc-head/gcc/crtstuff.c:64: /usr/include/bits/stdio.h: In function 'vprintf': /usr/include/bits/stdio.h:36: error: expected expression before '__restrict__' /usr/include/bits/stdio.h:36: error: too few arguments to function 'vfprintf' /usr/include/bits/stdio.h: In function 'getchar': /usr/include/bits/stdio.h:43: error: expected expression before '__restrict__' /usr/include/bits/stdio.h: In function 'getchar_unlocked': /usr/include/bits/stdio.h:59: internal compiler error: tree check: expected identifier_node, have error_mark in lookup_name, at c-decl.c:2553 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. set -ex mycpus=`grep -c 'cpu[0-9]' /proc/stat || echo 1` cd $HOME cd src/ #tar xfj /usr/src/packages/SOURCES/gcc-4.0.0-20050228.tar.bz2 ### ### ### build_one_try () { # try="$1" gccsrc="$2" # cd $HOME export myprefix=$HOME/install_${try} rm -rf ${myprefix} rm -rf objbin-${try}/ mkdir objbin-${try} cd objbin-${try}/ ~/src/binutils-head/src/configure --prefix=$myprefix --disable-nls /usr/bin/time make -j $mycpus &>log /usr/bin/time make install &>logi export PATH=$myprefix/bin:$PATH # cd $HOME rm -rf objgcc-${try}/ mkdir objgcc-${try} cd objgcc-${try}/ $gccsrc/configure --prefix=$myprefix --enable-threads=posix --enable-languages=c --enable-checking --with-system-zlib --enable-shared --enable-__cxa_atexit --disable-nls /usr/bin/time make bootstrap-lean -j $mycpus &>log /usr/bin/time make install &>logi # } ### ### build_one_try gcc34-1 ~/src/gcc-3_4-branch build_one_try gcc34-2 ~/src/gcc-3_4-branch build_one_try gcc4-1 ~/src/gcc-head build_one_try gcc34-3 ~/src/gcc-3_4-branch build_one_try gcc4-2 ~/src/gcc-head build_one_try gcc4-3 ~/src/gcc-head
the breakage appeared between 20041027 and 20041101.
PR 20305 is the bootstrap failure for s390x and it looks like the same problem.
After this patch, gcc could not boostrap itself anymore: TZ=UTC cvs diff -pu -D '20041031 09:00' -D '20041031 10:00' gcc/ I'm testing this patch currently on mainline: Index: gcc/ChangeLog.12 =================================================================== RCS file: /tmp/gcc-cvs/gcc/gcc/ChangeLog.12,v retrieving revision 2.2 diff -u -p -p -u -r2.2 ChangeLog.12 --- gcc/ChangeLog.12 18 Jan 2005 13:42:43 -0000 2.2 +++ gcc/ChangeLog.12 3 Mar 2005 22:57:01 -0000 @@ -6837,12 +6837,6 @@ * c-common.c: Fix a comment typo. -2004-10-31 Jason Merrill <jason@redhat.com> - - PR middle-end/17526 - * tree-gimple.c (is_gimple_mem_rhs): Also require a val for - aggregate types that are not BLKmode. - 2004-10-30 Ziemowit Laski <zlaski@apple.com> * c-common.h (objc_lookup_ivar): Add second parameter to Index: gcc/tree-gimple.c =================================================================== RCS file: /tmp/gcc-cvs/gcc/gcc/tree-gimple.c,v retrieving revision 2.35 diff -u -p -p -u -r2.35 tree-gimple.c --- gcc/tree-gimple.c 14 Dec 2004 13:41:52 -0000 2.35 +++ gcc/tree-gimple.c 3 Mar 2005 22:57:25 -0000 @@ -111,12 +111,9 @@ is_gimple_reg_rhs (tree t) bool is_gimple_mem_rhs (tree t) { - /* If we're dealing with a renamable type, either source or dest must be - a renamed variable. Also force a temporary if the type doesn't need - to be stored in memory, since it's cheap and prevents erroneous - tailcalls (PR 17526). */ - if (is_gimple_reg_type (TREE_TYPE (t)) - || TYPE_MODE (TREE_TYPE (t)) != BLKmode) + /* If we're dealing with a renamable type, either source or dest + must be a renamed variable. */ + if (is_gimple_reg_type (TREE_TYPE (t))) return is_gimple_val (t); else return is_gimple_formal_tmp_rhs (t);
the change above allowed a bootstrap of gcc-4.0.0-20050228 with itself.
Adding Jakub to the CC so he does not miss the updates from this bug since this and PR 20305 look to be the one and same bug really. Also note olh, has identified the patch which caused it for PPC64, Jakub, you might want to see if reverting the patch which olh found, also fixes the s390x problem.
Created attachment 8323 [details] The 2 routines Yes, it does. Attaching the 2 routines which are miscompiled on s390x at -O2.
Assembly diff between bad and good: diff -pU6 macro1.s.{broken,good} --- macro1.s.broken 2005-03-03 19:00:26.000000000 -0500 +++ macro1.s.good 2005-03-03 19:00:15.000000000 -0500 @@ -159,14 +159,13 @@ replace_args2: lg %r2,160(%r15) tm 0(%r10),8 lg %r1,0(%r2) mvc 4(1,%r3),4(%r1) lg %r1,160(%r15) lg %r2,0(%r1) - mvc 8(4,%r3),8(%r2) - mvc 16(8,%r3),16(%r2) + mvc 8(16,%r3),8(%r2) je .L56 lg %r2,0(%r1) ic %r1,5(%r2) oill %r1,8 stc %r1,5(%r3) .L58: @@ -406,15 +405,14 @@ cpp_get_token: j .L99 .L105: lgr %r2,%r11 brasl %r14,_cpp_temp_token ic %r1,5(%r12) oill %r1,32 - mvc 8(4,%r2),8(%r12) + mvc 8(16,%r2),8(%r12) mvc 4(1,%r2),4(%r12) - mvc 16(8,%r2),16(%r12) stc %r1,5(%r2) lgr %r12,%r2 lgr %r2,%r12 lg %r4,272(%r15) lmg %r11,%r15,248(%r15) br %r4
I'm not sure if it is actually a bug in the compiler that compiles macro.c or in libcpp.c. The code in question is: cpp_token *token = _cpp_temp_token (pfile); token->type = (*paste_flag)->type; token->val.str = (*paste_flag)->val.str; where val is a union of 2 pointers and struct cpp_string that has an uint, 4 bytes of padding and a pointer. The difference between non-working and working libcpp is (as shown e.g. in the assembly below) that the working one for the token->val.str = (*paste_flag)->val.str; assignment copies 16 bytes, i.e. len, 4 bytes of padding and text pointer, while the non-working one copies only 4 bytes of val.str.len and 8 bytes containing the val.str.text pointer, but not the padding. Not sure why the uninitialized bits in the padding matter though, but apparently they do.
Created attachment 8326 [details] Patch I'm testing
thanks Jakub, this patch fixes bootstrap for me. tested on mainline and gcc-4_0-branch.
Confirmed. Patch posted here: <http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00326.html>.
*** Bug 20305 has been marked as a duplicate of this bug. ***
The thing that was stopping me from commiting was that I'm now seeing FAIL: gcc.dg/cpp/arith-3.c (test for bogus messages, line 257) regression on i386 and x86-64 when starting bootstrap from 20050228 gcc-4_0-branch. But I have just verified that this is unrelated to my macro.c fix (which doesn't change the code in any way on i386 even), but it looks like libgcc.a(expr.o) is miscompiled at -O{2,3,s}. So will need to do debugging once again for this, but will commit fix for this PR first.
Subject: Bug 20282 CVSROOT: /cvs/gcc Module name: gcc Changes by: jakub@gcc.gnu.org 2005-03-04 15:33:24 Modified files: libcpp : ChangeLog macro.c Log message: PR bootstrap/20282 PR bootstrap/20305 * macro.c (replace_args, cpp_get_token): Copy whole cpp_token_u instead of just cpp_string field from it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcc&r1=1.57&r2=1.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/macro.c.diff?cvsroot=gcc&r1=1.9&r2=1.10
(In reply to comment #13) > The thing that was stopping me from commiting was that I'm now seeing > FAIL: gcc.dg/cpp/arith-3.c (test for bogus messages, line 257) > regression on i386 and x86-64 when starting bootstrap from 20050228 > gcc-4_0-branch. But I have just verified that this is unrelated to my > macro.c fix (which doesn't change the code in any way on i386 even), > but it looks like libgcc.a(expr.o) is miscompiled at -O{2,3,s}. > So will need to do debugging once again for this, but will commit fix for > this PR first. I have been seeing this for a while now. See <http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg00142.html> for a test results where this happens for an unmodified source.
Subject: Bug 20282 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: jakub@gcc.gnu.org 2005-03-04 15:39:37 Modified files: libcpp : ChangeLog macro.c Log message: PR bootstrap/20282 PR bootstrap/20305 * macro.c (replace_args, cpp_get_token): Copy whole cpp_token_u instead of just cpp_string field from it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.56.2.1&r2=1.56.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/macro.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9&r2=1.9.6.1
I'm using: ./cc1 x.c on #define APPEND2(NUM, SUFF) NUM ## SUFF #define APPEND(NUM, SUFF) APPEND2(NUM, SUFF) # define MAX_INT 9223372036854775807 #define TARG_MIN (-TARG_MAX - 1) #define TARG_MAX APPEND (MAX_INT, L) #if 1 * TARG_MIN != TARG_MIN /* { dg-bogus "overflow" } */ # error /* { dg-bogus "error" } */ #endif as a test.
Fixed. thanks Jakub for looking into this.