Bug 20282 - [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
Summary: [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: build, ice-on-valid-code, patch, rejects-valid, wrong-code
: 20305 (view as bug list)
Depends on:
Blocks: 20305
  Show dependency treegraph
 
Reported: 2005-03-02 12:36 UTC by olh
Modified: 2005-03-04 18:31 UTC (History)
3 users (show)

See Also:
Host: powerpc64-linux
Target: powerpc64-linux
Build: powerpc64-linux
Known to work:
Known to fail:
Last reconfirmed: 2005-03-04 14:26:17


Attachments
The 2 routines (20.24 KB, application/octet-stream)
2005-03-03 23:57 UTC, Jakub Jelinek
Details
Patch I'm testing (437 bytes, patch)
2005-03-04 09:07 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description olh 2005-03-02 12:36:31 UTC
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
Comment 1 olh 2005-03-03 14:48:40 UTC
the breakage appeared between 20041027 and 20041101.
Comment 2 Andrew Pinski 2005-03-03 19:24:51 UTC
PR 20305 is the bootstrap failure for s390x and it looks like the same problem.
Comment 3 olh 2005-03-03 23:17:46 UTC
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);


Comment 4 olh 2005-03-03 23:31:21 UTC
the change above allowed a bootstrap of gcc-4.0.0-20050228 with itself.
Comment 5 Andrew Pinski 2005-03-03 23:32:50 UTC
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.
Comment 6 Jakub Jelinek 2005-03-03 23:57:45 UTC
Created attachment 8323 [details]
The 2 routines

Yes, it does.  Attaching the 2 routines which are miscompiled on s390x
at -O2.
Comment 7 Jakub Jelinek 2005-03-04 00:01:52 UTC
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
Comment 8 Jakub Jelinek 2005-03-04 00:29:30 UTC
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.
Comment 9 Jakub Jelinek 2005-03-04 09:07:01 UTC
Created attachment 8326 [details]
Patch I'm testing
Comment 10 olh 2005-03-04 13:30:32 UTC
thanks Jakub, this patch fixes bootstrap for me.
tested on mainline and gcc-4_0-branch.
Comment 11 Andrew Pinski 2005-03-04 14:26:17 UTC
Confirmed.
Patch posted here: <http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00326.html>.
Comment 12 Andrew Pinski 2005-03-04 14:27:21 UTC
*** Bug 20305 has been marked as a duplicate of this bug. ***
Comment 13 Jakub Jelinek 2005-03-04 15:28:00 UTC
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.
Comment 14 CVS Commits 2005-03-04 15:33:49 UTC
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

Comment 15 Andrew Pinski 2005-03-04 15:35:36 UTC
(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.
Comment 16 CVS Commits 2005-03-04 15:39:45 UTC
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

Comment 17 Jakub Jelinek 2005-03-04 15:43:25 UTC
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.
Comment 18 Andrew Pinski 2005-03-04 18:31:49 UTC
Fixed. thanks Jakub for looking into this.