[Bug c++/14711] New: ICE in final.c:2117 when compiling a huge source file

[Bug c++/14711] New: ICE in final.c:2117 when compiling a huge source file

[debian-gcc at lists dot debian dot org]

[forwarded from http://bugs.debian.org/234711]

seen with 3.3 CVS 20040322, doesn't compile with 3.4.

not attaching the report, as it's 1.6MB compressed. see
http://www.ldknet.org/~mweitzel/compiler_error.tar.bz2

g++ - compiler crashes when compiling a huge (>30 MB), auto-generated
source file (differential equation system). The reported error message
was:

$ g++ DynamicSystem_PPP_realPool.cxx
DynamicSystem_PPP_realPool.cxx: In function `int main(int, char**)':
DynamicSystem_PPP_realPool.cxx:530334: internal compiler error: in 
   final_scan_insn, at final.c:2117
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

$ wc -l DynamicSystem_PPP_realPool.cxx 
530334 DynamicSystem_PPP_realPool.cxx

-- 
           Summary: ICE in final.c:2117 when compiling a huge source file
           Product: gcc
           Version: 3.3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: debian-gcc at lists dot debian dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug c++/14711] ICE in final.c:2117 when compiling a huge source file

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-03-24 13:57 -------
Confirmed, but reducing this will be a challenge. Can the original submitter 
try to generate a smaller file in the first place? As small as possible.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at libero dot
                   |                            |it
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug c++/14711] ICE in final.c:2117 when compiling a huge source file

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-03-24 15:42 -------
Ugh, I've reduced bug reports with close to 100k lines, but this one has more  
than 500k, and it takes forever to compile even without optimization. 
 
However, it seems like a very good candidate for delta debugging, since it  
consists of huge functions where it is presumably possible to chuck away 
large pieces. Anyone got any experience with that? 
 
A smaller testcase from the submitters would of course be much better... 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug c++/14711] ICE in final.c:2117 when compiling a huge source file

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2004-03-24 16:24 -------
When I tried to reformat it for delta debugging, the problem went away. Therefore,
I think it's purely caused by too large line numbers (limit at 2^19 = 524288?).

Maybe somebody can try to verify this by inserting #line 0 a few times.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] ICE in final.c:2117 when compiling a huge source file

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-24 16:27 -------
  int rtint;
#define XINT(RTX, N)    (RTL_CHECK2 (RTX, N, 'i', 'n').rtint)
#define NOTE_LINE_NUMBER(INSN) XCINT (INSN, 5, NOTE)
          if (NOTE_LINE_NUMBER (insn) <= 0)
            abort ();

So maybe we should using hwint instead?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug preprocessor/14711] ICE in final.c:2117 when compiling a huge source file

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-24 16:50 -------
The problem is that the preprocess is making the line numbers wrong:
# 4294967290 "/Users/pinskia/gcc-3.3/include/c++/3.3.3/cctype" 3
I think the the negative numbers was just fixed on the 3.3 branch (like yesterday), can you try again?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |preprocessor


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-03-24 16:51 -------
Looks like Falk is right, I'll attach a short testcase
which has the following form:

============================
template <int> struct A {};

// lots of empty lines

void foo() { A<0> a; }
============================

If the funtion is in line 524288, I get the ICE, if it is in
line 524287 I don't.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reichelt at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |critical
             Status|WAITING                     |NEW
          Component|preprocessor                |middle-end
     Ever Confirmed|                            |1
      Known to fail|                            |3.3 3.3.1 3.3.2 3.3.3
      Known to work|                            |2.95.3 3.4.0 3.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2004-03-24 16:51:21
               date|                            |
            Summary|ICE in final.c:2117 when    |[3.3 regression] ICE in
                   |compiling a huge source file|final.c:2117 when compiling
                   |                            |a huge source file
   Target Milestone|---                         |3.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-03-24 16:53 -------
Subject: Re:  ICE in final.c:2117 when compiling a huge source file

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

|   int rtint;
| #define XINT(RTX, N)    (RTL_CHECK2 (RTX, N, 'i', 'n').rtint)
| #define NOTE_LINE_NUMBER(INSN) XCINT (INSN, 5, NOTE)
|           if (NOTE_LINE_NUMBER (insn) <= 0)
|             abort ();
| 
| So maybe we should using hwint instead?

He he, someone a long time ago argued that no real programs have such
lines number.  Amusing :-)

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-03-24 17:06 -------
That's very impressive you find it so quickly, guys! 
 
BTW: we get PRs with testcases in the range of 80k lines not infrequently. 
If 500k is getting us into trouble, this is not a huge margin, and we should 
really make sure that we can handle that. In particular, saying that 500k 
is unrealistic is certainly not true. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-03-24 17:08 -------
Well, here's an even shorter testcase:

=======================================
template <int> struct A {};
# line 524288
void foo() { A<0> a; }
=======================================

In the original example it's not the preprocessing that bit us
(like Andrew suggested in comment #5).
The line numbers were really that high.

It's amazing however, that the bug in the preprocessor Andrew
mentioned never causes this kind of trouble.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-03-24 17:09 -------
Notice that the ICE itself can be reproduced with:

---------------------
# 4294967290
void foo(void) { }
---------------------

but only with 3.3, it's gone on 3.4 and mainline. Of course, the real problem 
is that pp shouldn't generate those line numbers in the first place, as noticed 
by Andrew.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-03-24 17:44 -------
A major difference between my example in comment #10 and Giovanni's in
comment #11 is that the former ICEs when the line number exceeds 2^19
and the latter when it exceeds 2^31.

Maybe both bugs have differewnt underlying reasons:
2^31 looks like trouble with signed/unsigned integers
whereas 2^19 looks like trouble with something else.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-03-24 17:47 -------
So given my own comment #9, do we have to expect testcases with 4e9 
lines anytime soon? I hate to think about the implications on my 
private life reducing such testcases might have... 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[roger at eyesopen dot com]

------- Additional Comments From roger at eyesopen dot com  2004-04-04 20:54 -------
I believe that the 2^31 limit is a reasonable hard limit caused by the way
that GCC internally maintains line numbers, for example, in scan.h, we use
"extern int lineno".  It looks like these line numbers must be signed, as
negative values are used as "rogue" values in REG_NOTES, and also occassionally,
but perhaps not intentionally during normal compilation [a gdb watch on
"lineno" reveals it holds the value -70 temporarily during a typical compile].

The 2^19 limit is caused by GCC's representation/encoding of the tree node
EXPR_WITH_FILE_LOCATION.  The EXPR_WFL_LINECOL stores a line and column
number in a single 32-bit integer, "complexity", using the bottom 12 bits for
the column position, and the top 20 bits for the line number.

In the C++ testcase, the line number is temporarily saved/restored during C++
template parsing by push_tinset_level/pop_tinst_level which maintains a stack
of file locations, using a linked list of EXPR_WITH_FILE_LOCATION tree nodes,
current_tinst_level.

Because EXPR_WFL_LINENO uses a right shift of a signed field to extract the
top 20 bits back out of the EXPR_WFL_LINECOL, on many (but not all!) machines
we return a negative value if the msb is set, i.e. the value was greater than
2^19.  This negative value is what eventually causes the ICE in final.c.

The EXPR_WFL_LINECOL representation is unchanged on mainline and in 3.4, so
this problem still exists in current CVS, but is just latent due to other
changes, not to removing the 2^19 line restriction.

Possible solutions include:
[1] Using an unsigned right shift, i.e. (int)((unsigned int)x >> 12), to
extract the top twenty bits for EXPR_WFL_LINECOL.  This requires that we
never need to represent negative values in EXPR_WFL_LINECOL.  The negative
values of the global "lineno" make this fix non-obvious.  It would however
avoid the final.c ICE caused by negative line numbers, and simply truncate
the lineno field, wrapping around a 2^20 relatively harmlessly, except for
debugging information.

[2] Change the division of bits in EXPR_WFL_LINECOL, so that we use less
than 12 bits for column, and more than 20 bits for line number.  This is
a less than ideal work-around.

[3] Change the representation of current_tinst_level to avoid problematic
use of EXPR_WITH_FILE_LOCATION.  A linked list of location structs would
allow more accurate representation/recovery of these fields and probably
save space, avoiding all the unneeded common tree bits.  This wouldn't help
other uses of the EXPR_WITH_FILE_LOCATION though.

[4] Expand EXPR_WITH_FILE_LOCATION's tree node so that it can store a full
integer for line number, perhaps combining column with other fields or just
increasing the size of this node.  I'm a bit confused why its using the
"complexity" field at the moment, and just as confused why we have a complexity
field, why the C front end is using it for C_EXP_ORIGINAL_CODE, and why the
f77 front-end that doesn't even set/use C_EXP_ORIGINAL_CODE tests for it!!

[5] Defensively tweak the middle-end to avoid creating line number notes when
current "lineno < 0".  This would avoid unintentionally creating invalid NOTES,
but again would be papering over the problem, and may cause problems if we
later rely on finding these notes in the insn stream.

I'm currently investigating why lineno is ever negative...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-04-06 16:39 -------
Subject: Re:  [3.3 regression] ICE in final.c:2117 when
 compiling a huge source file

On Sun, 4 Apr 2004, roger at eyesopen dot com wrote:

> [4] Expand EXPR_WITH_FILE_LOCATION's tree node so that it can store a full
> integer for line number, perhaps combining column with other fields or just
> increasing the size of this node.  I'm a bit confused why its using the
> "complexity" field at the moment, and just as confused why we have a complexity
> field, why the C front end is using it for C_EXP_ORIGINAL_CODE, and why the
> f77 front-end that doesn't even set/use C_EXP_ORIGINAL_CODE tests for it!!

I don't know the purpose of having TREE_COMPLEXITY as a general expression
field, but I'd like to replace C_EXP_ORIGINAL_CODE with a more robust
mechanism keeping track of some parser status (which is what this
essentially is - not relevant for code generation, only for warnings) in
separate structures for expressions that are passed around by value and
don't need allocation and garbage collection.  This would also help in
fixing bug 11250 (distinguishing parenthesised and nonparenthesised
strings), and the constant expressions issues (456, 5675, 14649 at least)  
where several flags are needed on expressions and types that are
irrelevant for code generation and don't need to bulk up trees.

At present, for C_EXP_ORIGINAL_CODE to work properly for -Wparentheses
warnings, constants derived from folding are artificially wrapped in
NON_LVALUE_EXPR so that C_EXP_ORIGINAL_CODE can be set.  Whether something
is an lvalue is another parser property that can be tracked as a single
bit outside the trees rather than allocating a NON_LVALUE_EXPR node,
irrelevant for code generation, in various cases.

However, the warning for assignments used as truth values is in code
shared between C and C++, and uses C_EXP_ORIGINAL_CODE, which complicates
getting fix of it.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-04-15 14:42 -------
*** Bug 14833 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hotxiening at hotmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[gdr at gcc dot gnu dot org]

------- Additional Comments From gdr at gcc dot gnu dot org  2004-04-18 19:00 -------
This is a long standing regresssion (since 3.0).  It is fixed in
3.4.0 and 3.5.0.  It will not be fixed in 3.3.x.

-- Gaby


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|3.3.4                       |3.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-05-14 22:57 -------
(As noted in PR 15426) 
 
Actually, this bug isn't fixed. With the testcase in comment #10,  
I still get an ICE when using -g:  
  
g/x> /home/bangerth/bin/gcc-3.5-pre/bin/c++ -c x.cc -g  
x.cc: In function `void foo()':  
x.cc:524288: internal compiler error: in final_scan_insn, at final.c:1847  
Please submit a full bug report,  
with preprocessed source if appropriate.  
See <URL:http://gcc.gnu.org/bugs.html> for instructions.  
  
This is with both 3.4 and mainline from about 2 weeks ago.  
  
W.  

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
      Known to fail|3.0 3.0.1 3.0.2 3.0.3 3.0.4 |3.0 3.0.1 3.0.2 3.0.3 3.0.4
                   |3.1 3.1.1 3.1.2 3.2 3.2.1   |3.1 3.1.1 3.1.2 3.2 3.2.1
                   |3.2.2 3.2.3 3.3 3.3.1 3.3.2 |3.2.2 3.2.3 3.3 3.3.1 3.3.2
                   |3.3.3                       |3.3.3 3.4.0 3.5.0
      Known to work|2.95.3 3.4.0 3.5.0          |2.95.3
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4/3.5 regression] ICE in final.c:2117 when compiling a huge source file

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
           Keywords|                            |ice-on-valid-code
            Summary|[3.3 regression] ICE in     |[3.3/3.4/3.5 regression] ICE
                   |final.c:2117 when compiling |in final.c:2117 when
                   |a huge source file          |compiling a huge source file
   Target Milestone|3.4.0                       |3.4.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4/3.5 regression] ICE in final.c:2117 when compiling a huge source file

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-06-19 00:02 -------
Postponed until GCC 3.4.2.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.1                       |3.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4/3.5 regression] ICE in final.c:2117 when compiling a huge source file

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-29 18:14 -------
Postponed until GCC 3.4.3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.2                       |3.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4/3.5 regression] ICE in final.c:2117 when compiling a huge source file

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-29 18:11 -------
Postponed until GCC 3.4.3.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4/4.0 regression] ICE in final.c:2117 when compiling a huge source file

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-11-01 00:45 -------
Postponed until GCC 3.4.4.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.3                       |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4/4.0 regression] ICE in final.c:2117 when compiling a huge source file

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-05 20:19 -------
*** Bug 15426 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hebisch at math dot uni dot
                   |                            |wroc dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4/4.0 regression] ICE in final.c:2117 when compiling a huge source file

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4/4.0/4.1 regression] ICE in final.c:2117 when compiling a huge source file

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-03-24 18:14 -------
The testcase in Comment 10 does not fail on 4.0 or 4.1

Volker, does this problem still exist?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4 regression] ICE in final.c:2117 when compiling a huge source file

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2005-03-24 20:35 -------
The problem with the 2^19 line-number limit seems to be fixed
in gcc 4.0 and 4.1. The problem disappeared with the merge
of the tree-ssa branch AFAICT.

Strange that I didn't enter the info to the data-base.
Must have slipped through the cracks somehow.

The 2^32 line-number limit still persists, but this is not such
a problem and it's not a regression since this causes trouble
since at least 2.95.3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|3.0 3.0.1 3.0.2 3.0.3 3.0.4 |3.0 3.0.1 3.0.2 3.0.3 3.0.4
                   |3.1 3.1.1 3.1.2 3.2 3.2.1   |3.1 3.1.1 3.1.2 3.2 3.2.1
                   |3.2.2 3.2.3 3.3 3.3.1 3.3.2 |3.2.2 3.2.3 3.3 3.3.1 3.3.2
                   |3.3.3 3.4.0 4.0.0           |3.3.3 3.4.0
            Summary|[3.3/3.4/4.0/4.1 regression]|[3.3/3.4 regression] ICE in
                   |ICE in final.c:2117 when    |final.c:2117 when compiling
                   |compiling a huge source file|a huge source file


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711

[Bug middle-end/14711] [3.3/3.4 regression] ICE in final.c:2117 when compiling a huge source file

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-05-10 01:39 -------
Fixed in 4.0; will not be fixed in 3.4.x.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|3.4.4                       |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711