Mainline GCC for powerpc-linux gets an ICE compiling 176.gcc from SPEC CPU2000 with -O2, as shown with this minimized test case: elm3b149% /home/janis/tools/gcc-mline-20050414/bin/gcc -O2 -c bug.c bug.c: In function ‘schedule_unit’: bug.c:5: internal compiler error: in set_value_range, at tree-vrp.c:124 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. That abort is in checking code added on 2005-04-09 by dnovillo.
Created attachment 8633 [details] minimized test case
Confirmed, also happens on i686-pc-linux-gnu.
Reduced down to: void foo (int unit) { int i; for (i = 0; unit; i++, unit--) { if (i >= 0) { int j = i; while (j) j--; } } }
Created attachment 8638 [details] patch
A comment in the patch says "Tested on i686-pc-linux-gnu", but it just means that it will have been tested by the time I post this patch. :-)
Proposed patch (in #4) work fine at FreeBSD 5.1 And fix my tescase variant: __inline void f(int a) { int i; if (a < 0) { for (i = 0, a = ~a; a; i++) { if ((a & 1) != 0) { f(i); } } } } void g(void) { f(0); } Without proposed patch i can't bootstrap LLVM using gcc CVS mainline. bootstrap die at build of gcc version 3.4-llvm 20030924 (part of LLVM distribution): gcc/haifa-sched.c:737: internal compiler error: in set_value_range, at tree- vrp.c:124 Note: haifa-sched.c isn't modified.
I observe the same ICE when bootstrapping with Ada on i386-pc-solaris2.10: stage1/xgcc -Bstage1/ -B/vol/gcc/share/i386-pc-solaris2.10/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada /vol/gnu/src/gcc/gcc-dist/gcc/ada/sem_intr.adb -o ada/sem_intr.o +===========================GNAT BUG DETECTED==============================+ | 4.1.0 20050419 (experimental) (i386-pc-solaris2.10) GCC error: | | in set_value_range, at tree-vrp.c:124 | | Error detected at sem_intr.adb:437:1 | Unfortunately, the proposed patch doesn't fix this.
Another testcase for something which looks like the same bug, this time in Fortran (reduced from LAPACK by Steve Kargl): SUBROUTINE CHER2K(N, BETA, C, LDC) INTEGER I, J, N, LDC REAL BETA COMPLEX C(LDC,*), ZERO PARAMETER (ZERO = (0.0E+0, 0.0E+0)) IF (BETA .EQ. REAL(ZERO)) THEN DO 20, J = 1, N DO 10, I = 1, J C(I,J) = ZERO 10 CONTINUE 20 CONTINUE ELSE DO 40, J = 1, N DO 30, I = 1, J - 1 C(I,J) = BETA * C(I,J) 30 CONTINUE 40 CONTINUE END IF END
This is a shorter version of the Fortran code. The bug is now critical to gfortran because almost all Fortran codes contain nested do loops. SUBROUTINE CHER2K(N, C, LDC) INTEGER I, J, N, LDC COMPLEX C(LDC,*) DO 20, J = 1, N DO 10, I = 1, J C(I,J) = (0.0E+0, 0.0E+0) 10 CONTINUE 20 CONTINUE END
Kazu, I just tried the patch, pr21030-vrp-ice.patch. It seems to fix the problems with gfortran and -O2.
(In reply to comment #10) > Kazu, I just tried the patch, pr21030-vrp-ice.patch. > It seems to fix the problems with gfortran and -O2. Kazu, could you propose your patch on gcc-patches or ping it ? Without this patch I won't be able to do any testing for my GCC Summit paper (deadline 1st of May). Thanks in advance.
(In reply to comment #5) > A comment in the patch says "Tested on i686-pc-linux-gnu", but > it just means that it will have been tested by the time I post this patch. :-) > Patch looks fine. OK to install if it passes the usual testing. It's odd that I don't seem to have received this patch. Did you ever post it? Diego.
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 Hi Toon, > > Kazu, I just tried the patch, pr21030-vrp-ice.patch. > > It seems to fix the problems with gfortran and -O2. > > Kazu, could you propose your patch on gcc-patches or ping it ? Without this > patch I won't be able to do any testing for my GCC Summit paper (deadline 1st of > May). I would like to, but currently my patch causes a regression in one of the VRP testcases. I have not checked if the failure is a real one or not. That is, it's plausible that we are looking for an optimization that should not happen. Kazu Hirata
(In reply to comment #13) > > I would like to, but currently my patch causes a regression in one of > the VRP testcases. > Not to sound like an idiot, but how likely is this one VRP testcase to show up in real world code. Because without this patch, gfortran is pretty much useless on most real world code. I haven't checked 4.0.0 against my Fortran testsuite; hopefully, this problem isn't present in gfortran's first exposure to the world.
(In reply to comment #14) > I haven't checked 4.0.0 against my Fortran > testsuite; hopefully, this problem isn't present in > gfortran's first exposure to the world. It cannot be in 4.0.0 as the VRP code was just added in the last couple weeks.
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Sat, Apr 23, 2005 at 03:11:52PM -0000, kargl at gcc dot gnu dot org wrote: > > ------- Additional Comments From kargl at gcc dot gnu dot org 2005-04-23 15:11 ------- > (In reply to comment #13) > > > > I would like to, but currently my patch causes a regression in one of > > the VRP testcases. > > Kazu, which test case is this? Send me details? I'll look at this next week. In the meantime, I would rather have sub-optimal code than a broken FE. > I haven't checked 4.0.0 against my Fortran > testsuite; hopefully, this problem isn't present in > gfortran's first exposure to the world. > No. VRP is a 4.1 feature. Diego.
I just went through the regression testing. I get FAIL: g++.dg/tree-ssa/pr18178.C scan-tree-dump-times if 1 It may be a good idea to check in this patch with the above testcase XFAILed.
Diego, I think it's OK to have contradictory information from an ASSERT_EXPR and SCEV. Let's say we have a loop counting from i = 0 upward. It's possible that we "if (i < 0)" in the loop and see something like i_10 = ASSERT_EXPR <i_1, i_1 < 0>; on the "then" arm of the conditional. In this case, we know we are counting upward, so SCEV tells us that the minimum value of i_10 should be 0, but the ASSERT_EXPR tells us that the range should be [-INF, -1]. They are completely disjoint! This weird situation comes from the fact that the "then" branch of the conditional is dead. In this case, probably the safest and simplest thing to do is to ignoring what SCEV says. Kazu Hirata
This breaks BLAS (optimzation >= -O2), the major Fortran library. The whole fortran front-end is useless in this state.
Working on it today. Kazu, I hope you don't mind if I take it?
Diego, no, I don't mind. But I have a patch whose bootstrap is almost over and regression testing is about to start. This patch does not break g++dg/tree-ssa/pr18178.C unlike my previous patch. Let me attach my patch (and some analysis) just FWIW.
Created attachment 8764 [details] an updated patch that does not break g++.dg/tree-ssa/pr18178.C
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 02:37:18PM -0000, kazu at cs dot umass dot edu wrote: > > ------- Additional Comments From kazu at cs dot umass dot edu 2005-04-29 14:37 ------- > Created an attachment (id=8764) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8764&action=view) > an updated patch that does not break g++.dg/tree-ssa/pr18178.C > Kazu, did you mail your patch before attaching it to bugzilla? I haven't received it. The same thing happened to your previous patch for this PR and I missed it the first time. Diego.
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 Hi Diego, > Kazu, did you mail your patch before attaching it to bugzilla? I > haven't received it. The same thing happened to your previous > patch for this PR and I missed it the first time. No, I did not send my previous to gcc-patches@ because I was not fully satified with it. Although I tested the patch, it broke pr18178.C, and I did not analyze the failure at that time. I have not sent my current patch to gcc-patches@ yet because I have not finished testing it. This time I will unless you beat me to it. Kazu Hirata
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 02:55:58PM -0000, kazu at cs dot umass dot edu wrote: > I have not sent my current patch to gcc-patches@ yet because I have > not finished testing it. This time I will unless you beat me to it. > Oh, OK. No, that's fine. I'm now analyzing the test case. I'll check out your patch in a little while, if it matches what I found, then it's OK to go in. Diego.
(In reply to comment #22) > Created an attachment (id=8764) > an updated patch that does not break g++.dg/tree-ssa/pr18178.C > Kazu, your analysis is correct. If this patch fixes the problem and passes testing please commit it. Diego.
Just checked in a patch.
Subject: Bug 21030 CVSROOT: /cvs/gcc Module name: gcc Changes by: kazu@gcc.gnu.org 2005-04-29 16:23:20 Modified files: gcc : ChangeLog tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr21030.c Log message: gcc/ PR tree-optimization/21030 * tree-vrp.c (adjust_range_with_scev): Do not create invalid ranges where VR->MAX is smaller than VR->MIN. testsuite/ PR tree-optimization/21030 * gcc.dg/tree-ssa/pr21030.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8530&r2=2.8531 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.13&r2=2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5417&r2=1.5418 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21030.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 Unfortunately, even with the patch applied, the Ada bootstrap failure on i386-pc-solaris2.10 remains unchanged, a regression from 4.0: stage1/xgcc -Bstage1/ -B/vol/gcc/share/i386-pc-solaris2.10/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada /vol/gnu/src/gcc/gcc-dist/gcc/ada/sem_intr.adb -o ada/sem_intr.o +===========================GNAT BUG DETECTED==============================+ | 4.1.0 20050429 (experimental) (i386-pc-solaris2.10) GCC error: | | in set_value_range, at tree-vrp.c:124 | | Error detected at sem_intr.adb:437:1 | Rainer
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 07:57:43PM -0000, ro at techfak dot uni-bielefeld dot de wrote: > > ------- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-04-29 19:57 ------- > Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 > > Unfortunately, even with the patch applied, the Ada bootstrap failure on > i386-pc-solaris2.10 remains unchanged, a regression from 4.0: > > stage1/xgcc -Bstage1/ -B/vol/gcc/share/i386-pc-solaris2.10/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada /vol/gnu/src/gcc/gcc-dist/gcc/ada/sem_intr.adb -o ada/sem_intr.o > +===========================GNAT BUG DETECTED==============================+ > | 4.1.0 20050429 (experimental) (i386-pc-solaris2.10) GCC error: | > | in set_value_range, at tree-vrp.c:124 | > | Error detected at sem_intr.adb:437:1 | > > Rainer > Huh. Odd. I just finished a bootstrap with $ configure --enable-languages=c,ada $ make bootstrap on i686-pc-linux-gnu. Diego.
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 09:11:12PM -0000, dnovillo at redhat dot com wrote: > Huh. Odd. I just finished a bootstrap with > > $ configure --enable-languages=c,ada > $ make bootstrap > > on i686-pc-linux-gnu. > Just reproduced it with --target=i386-pc-linux-gnu. Thanks Andrew P. for pointing it out. Will take a look. Diego.
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 07:57:43PM -0000, ro at techfak dot uni-bielefeld dot de wrote: > Unfortunately, even with the patch applied, the Ada bootstrap failure on > i386-pc-solaris2.10 remains unchanged, a regression from 4.0: > Would you mind filing a separate PR? This is a different problem. The Ada FE is emitting a seemingly always-false predicate that is causing VRP to create an invalid range (http://gcc.gnu.org/ml/gcc/2005-05/msg00049.html). Thanks. Diego.
*** Bug 21381 has been marked as a duplicate of this bug. ***