Bug 16586 - [3.4 Regression] -O3 -fno-gcse ICE verify_local_live_at_start flow.c:575
Summary: [3.4 Regression] -O3 -fno-gcse ICE verify_local_live_at_start flow.c:575
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.3.4
: P2 normal
Target Milestone: 3.4.6
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, monitored
Depends on:
Blocks: 15023
  Show dependency treegraph
 
Reported: 2004-07-16 07:10 UTC by Ned Konz
Modified: 2006-02-28 09:36 UTC (History)
6 users (show)

See Also:
Host: i686-pc-linux
Target: i686-pc-linux
Build: i686-pc-linux
Known to work: 4.0.0 3.0.4
Known to fail: 3.1 3.2.3 3.3.3 3.4.0 3.4.2
Last reconfirmed: 2006-01-06 15:26:38


Attachments
preprocessed source (1.23 KB, application/x-bzip2)
2004-07-16 07:11 UTC, Ned Konz
Details
simplified c++ testcase that appears to trigger the same ICE. (835 bytes, text/plain)
2005-03-24 12:56 UTC, Lennert Buytenhek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ned Konz 2004-07-16 07:10:06 UTC
This also happens on
gcc 3.3.3 i686-pc-mingw32
gcc 3.3.4 i686-pc-linux

On Linux 3.3.4:

$ gcc -v --save-temps -O3 -fno-gcse buggy2.c
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.4 (Debian 1:3.3.4-2)
 /usr/lib/gcc-lib/i486-linux/3.3.4/cc1 -E -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 buggy2.c -fno-gcse -O3 buggy2.i
ignoring nonexistent directory "/usr/i486-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i486-linux/3.3.4/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i486-linux/3.3.4/cc1 -fpreprocessed buggy2.i -quiet -dumpbase
buggy2.c -auxbase buggy2 -O3 -version -fno-gcse -o buggy2.s
GNU C version 3.3.4 (Debian 1:3.3.4-2) (i486-linux)
        compiled by GNU C version 3.3.4 (Debian 1:3.3.4-2).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129568
buggy2.c: In function `loadObjectsFrom':
buggy2.c:74: internal compiler error: in verify_local_live_at_start, at flow.c:575


On Mingw32 3.3.3:
$ gcc -v --save-temps -O3 -fno-gcse buggy2.c
Reading specs from c:/GNUTools/bin/../lib/gcc-lib/mingw32/3.3.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization
Thread model: win32
gcc version 3.3.3 (mingw special)
 c:\GNUTools\bin\..\lib\gcc-lib\mingw32\3.3.3\cc1.exe -E -quiet -v -iprefix
c:\GNUTools\bin\../lib/gcc-lib/mingw32/3.3.3/ -D__GNUC__=3 -D__GNUC_MINOR__=3
-D__GNUC_PATCHLEVEL__=3 buggy2.c -fno-gcse -O3 buggy2.i
ignoring nonexistent directory "c:/GNUTools/mingw32/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.3.3/include"
ignoring nonexistent directory "/mingw/mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 c:/GNUTools/include
 c:/GNUTools/lib/gcc-lib/mingw32/3.3.3/include
End of search list.
 c:\GNUTools\bin\..\lib\gcc-lib\mingw32\3.3.3\cc1.exe -fpreprocessed buggy2.i
-quiet -dumpbase buggy2.c -auxbase buggy2 -O3 -version -fno-gcse -o buggy2.s
GNU C version 3.3.3 (mingw special) (mingw32)
        compiled by GNU C version 3.3.3 (mingw special).
GGC heuristics: --param ggc-min-expand=58 --param ggc-min-heapsize=52670
buggy2.c: In function `loadObjectsFrom':
buggy2.c:74: internal compiler error: in verify_local_live_at_start, at flow.c:575
Comment 1 Ned Konz 2004-07-16 07:11:54 UTC
Created attachment 6764 [details]
preprocessed source

produced with Linux 3.3.4 compiler.
Comment 2 Andrew Pinski 2004-07-16 07:32:12 UTC
It is fixed in 3.4.0 but worked in 3.0.4 so this is a regression.
I have not reduced the testcase yet.
Comment 3 Wolfgang Bangerth 2004-07-16 13:38:18 UTC
Confirmed. In fact, with the following snippet I can also crash 3.4, so 
it doesn't seem to be fixed there but only papered over: 
---------------- 
struct Ptrs { 
    int (*ptr1)(int offset); 
    int (*ptr2)(); 
} * ptrs; 
static int ** state; 
 
int foo(int stackIndex) { 
  int *p; 
  int sz; 
  int objOop; 
  int i; 
  int **pp; 
  ptrs->ptr1(stackIndex); 
  if (ptrs->ptr2()) { 
    return 0; 
  } 
  if (!((ptrs->ptr2()) == 0)) { 
    return 0; 
  } 
  sz = ptrs->ptr2(); 
  if (sz > 1)  
    return 0; 
        
  pp = state; 
  for (i = 0; i <= sz-1; ++i) { 
    objOop = ptrs->ptr1(0); 
    if (!ptrs->ptr2()) 
      return 0;	 
                
    *p = objOop; 
    pp[i] = p; 
  } 
} 
-------------------------- 
 
g/x> /home/bangerth/bin/gcc-3.3.4-pre/bin/gcc -O3 -c -fno-gcse x.i  
x.i: In function `foo': 
x.i:33: internal compiler error: in verify_local_live_at_start, at flow.c:575 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See <URL:http://gcc.gnu.org/bugs.html> for instructions. 
g/x>  
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/gcc -O3 -c -fno-gcse x.i  
x.i: In function `foo': 
x.i:33: internal compiler error: in verify_local_live_at_start, at flow.c:546 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See <URL:http://gcc.gnu.org/bugs.html> for instructions. 
 
W. 
Comment 4 Andrew Pinski 2004-07-28 20:43:42 UTC
: Test is the same (pass) at both endpoints (2004-02-01-3.4,
: 2004-07-27-3.4), so there's nothing for me to do.

Broken on the mainline:
: Search converges between 2001-06-03-trunk (#22) and 2001-06-10-trunk (#23).

Fixed on the mainline:
: Search converges between 2003-06-04-trunk (#254) and 2003-06-05-trunk (#255).
So in my testing (on Phil's regression hunter) this is only a 3.3 regression but this was without -
march=pentiumpro which is what fixed it without using the driver (or something like that)

With using -march=pentiumpro:
: Search converges between 2004-04-20-trunk (#449) and 2004-05-01-trunk (#450).
This might still a bug on the mainline also but harder to get to as we get rid of some code before 
going into the RTL.

Moving the target to 3.4.2 per what Gaby said about regressions that are on both 3.3.x and 3.4.x.
Comment 5 Volker Reichelt 2004-08-16 14:23:36 UTC
Here's a slightly shorter testcase. It crashes everything from 3.1 until
3.4 branch.

======================================
int (**foo)(int);

int bar()
{
    static int **s;
    int i, j, k=i, **p;

    (*foo)(**s);
    if ((*foo)(0)) return 0;
    if (k > 0) return 0;

    p = s;
    for (i = 0; i <= k-1; ++i)
    {
        j = (*foo)(0);
        if ((*foo)(0)) return 0;
        **p = j;
    }
}
======================================
Comment 6 Mark Mitchell 2004-08-29 18:11:48 UTC
Postponed until GCC 3.4.3.
Comment 7 Mark Mitchell 2004-08-29 18:14:39 UTC
Postponed until GCC 3.4.3.
Comment 8 Volker Reichelt 2004-09-10 15:08:50 UTC
The testcases in comment #3 and #5 got fixed on the 3.4 branch by
Richard's patch for PR 17186:
http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg00357.html

Richard, do you think a backport to the 3.3 branch is feasible?
Comment 9 Richard Henderson 2004-09-10 19:18:27 UTC
It wouldn't be hard to backport to 3.3, no.
Comment 10 Volker Reichelt 2004-09-16 14:11:59 UTC
Since Richard reverted his patch for PR 17186 on the 3.4 branch,
this PR fails on the 3.4 branch again, too.
In addition, comment #9 is moot now.
Comment 11 Mark Mitchell 2004-11-01 00:46:00 UTC
Postponed until GCC 3.4.4.
Comment 12 Eric Botcazou 2004-12-02 07:11:12 UTC
This one is really tricky to fix: this is the classical case in which the return
value register's liveness propagates backwards until an unrelated use/clobber of
the register is encountered.  This works more or less until the regrename pass,
which locally renames the register in the latter def/use/clobber chain; so the
return value register's liveness is not masked anymore and propagates back to
the start of the basic block.  But, after reload, register liveness information
is not allowed to change at basic block boundaries so the compiler aborts on a
sanity check.

The easy workaround is to make sure that every code path in a function returning
a value really returns a value.
Comment 13 Eric Botcazou 2004-12-05 09:38:59 UTC
Downgrading to 'normal', this is an ICE whose workaround is obvious.
Comment 14 Lennert Buytenhek 2005-03-24 12:56:52 UTC
Created attachment 8448 [details]
simplified c++ testcase that appears to trigger the same ICE.

Attached is a simplified c++ testcase from the xorg-x11 6.8.1 distribution that
_appears_ to trigger the same ICE.  It needs gcc 3.3 or 3.4, -O3, and any ARM
target.  (It doesn't trigger when building for x86, when using -O2, or when
using gcc 2.95.3 or 4.0-20050305.  Didn't test other gcc versions.)
Comment 15 Gabriel Dos Reis 2006-02-28 09:36:42 UTC
won't fix for 3.4.6.