I just tried to compile Suse Linux package lsvpd-0.16.0-35 with the GNU C compiler version 4.3 snapshot 20070119. The compiler said cc -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-unit-at-a-time -I../lib -c -o node_handler.o node_handler.c node_handler.c:213: error: inlined_to pointer is set but no predecessors found call_inits/151(-1): (inline copy in main/144) availability:available(93) 19 insns tree finalized inlinable called by: calls: node_handler.c:213: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flags -O2 -fno-unit-at-a-time required.
Created attachment 12940 [details] C source code
I get ./cc1 -quiet t.i -O -fno-unit-at-a-time t.i: In function ‘atof’: t.i:1156: internal compiler error: in optimize_inline_calls, at tree-inline.c:2674 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
This is most likely a dup of bug 30537.
(In reply to comment #2) Reduced testcase for that ICE: extern __inline double strtod (void) { } strtol (void) { return strtod (); }
*** Bug 30772 has been marked as a duplicate of this bug. ***
This was introduced (or the effect came up) with the inline rewriting at r120835.
This bug is extremely common (seen while compiling the Debian archive). Honza, can you take a look soon?
Subject: Re: [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time > This bug is extremely common (seen while compiling the Debian archive). > Honza, can you take a look soon? I will check it tomorrow. However why users use -fno-unit-at-a-time at all? Do you have some idea what packages, except for kernel, use it? Honza
It is a dup. *** This bug has been marked as a duplicate of 30537 ***
(In reply to comment #8) > > This bug is extremely common (seen while compiling the Debian archive). > > Honza, can you take a look soon? > > I will check it tomorrow. However why users use -fno-unit-at-a-time at > all? Do you have some idea what packages, except for kernel, use it? Haskell
Subject: Re: [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time > > I will check it tomorrow. However why users use -fno-unit-at-a-time at > > all? Do you have some idea what packages, except for kernel, use it? > > Haskell Hmm, I wonder why they need it: [Use -fno-strict-aliasing for *all* C files in the runtime Simon Marlow <simonmar@microsoft.com>**20060629082902 as a precautionary measure. It is definitely required for GC.c, but it may well become necessary for other files in the future due to our (mis-)use of the C "type system". ] Are there any other packages or the "important portion" referred to haskell? Anyway, I am testing the attached fix, it was simple ordering problem triggering hack checking analyzed flag someone added into tree-inline. extern __inline double strtod (void) { } strtol (void) { return strtod (); } PR middle-end/30563 * cgraphunit.c (cgraph_analyze_function): Fix ordering problem. Index: cgraphunit.c =================================================================== --- cgraphunit.c (revision 125970) +++ cgraphunit.c (working copy) @@ -760,6 +760,7 @@ cgraph_analyze_function (struct cgraph_n current_function_decl = decl; push_cfun (DECL_STRUCT_FUNCTION (decl)); cgraph_lower_function (node); + node->analyzed = true; if (!flag_unit_at_a_time) { @@ -771,7 +772,6 @@ cgraph_analyze_function (struct cgraph_n bitmap_obstack_release (NULL); } - node->analyzed = true; pop_cfun (); current_function_decl = NULL; }
No, I don't think anything else important shows this problem, except of the kernel and the Haskell stuff. Thanks for the patch!
Subject: Bug 30563 Author: hubicka Date: Sun Jun 24 23:24:10 2007 New Revision: 125991 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125991 Log: PR middle-end/30563 * cgraphunit.c (cgraph_analyze_function): Fix ordering problem. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
wrong bug marked as duplicate... reopening...
*** Bug 30537 has been marked as a duplicate of this bug. ***
... to close as fixed