g++ sucks: internal compiler error???

[Neil Zanella]

Hello,

Allow me to share my frustrations with GNU g++. This is the second
time something similar happens to me: I can't find anything wrong with
my C++ program and yet I get segfaults, and eventually, here is what
happens. Anyone ever experience anything similar. This or similar
untrackable problems happen to me whenever I write a large class...
anyone have had similar experiences???

make
g++ -c matrix.cpp -Wall -g
matrix.cpp: In member function `void
Matrix::computeDistShortest(bool)':
matrix.cpp:189: internal compiler error: in find_function_data, at
function.c:
313
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccf7vSby.out file, please attach
this to your bugreport
make: *** [matrix.o] Error 1

 

[Fred Ma]

Hello,

Allow me to share my frustrations with GNU g++. This is the second
time something similar happens to me: I can't find anything wrong with
my C++ program and yet I get segfaults, and eventually, here is what
happens. Anyone ever experience anything similar. This or similar
untrackable problems happen to me whenever I write a large class...
anyone have had similar experiences???

make
g++ -c matrix.cpp -Wall -g
matrix.cpp: In member function `void
Matrix::computeDistShortest(bool)':
matrix.cpp:189: internal compiler error: in find_function_data, at
function.c:
313
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccf7vSby.out file, please attach
this to your bugreport
make: *** [matrix.o] Error 1

Hey, Neil,

Do a web search on netiquette, especially for usenet.
You might be extremely frustrated, but to say that
g++ sucks when it is a free compiler that serves
many people well is not the best way to present
yourself to the world. Sorry, I don't have an
answer to your problem, but I'm trying to help
out by helping you post in a way that might get
more people to help.

Fred

 

[John Harrison]

Hello,

Allow me to share my frustrations with GNU g++. This is the second
time something similar happens to me: I can't find anything wrong with
my C++ program and yet I get segfaults

Almost certainly bugs in your program. g++ isn't bug free of course, but it
isn't a buggy program either.

What is it they say about tools and bad workmen?

, and eventually, here is what
happens. Anyone ever experience anything similar. This or similar
untrackable problems happen to me whenever I write a large class...

Write smaller classes.

anyone have had similar experiences???

Only on a different compiler. On that compiler an internal compiler error
almost always indicated a syntax error in some complex language construct.
In your case I would guess some syntax error in an extremely large class
might be the cause.

make
g++ -c matrix.cpp -Wall -g
matrix.cpp: In member function `void
Matrix::computeDistShortest(bool)':
matrix.cpp:189: internal compiler error: in find_function_data, at
function.c:
313

Why not share the code. No-one can offer any useful help without it. Before
posting the code however, take the time to cut out the parts that are not
contributing to the error. This sort of methodical approach might help you
figure out the cause of the error in which case you would have learned
something valuable, if it doesn't then you at least will be posting less
code here and are more likely to get help.

john

 

[Jonathan Turkanis]

Hello,

Allow me to share my frustrations with GNU g++. This is the second
time something similar happens to me: I can't find anything wrong with
my C++ program and yet I get segfaults, and eventually, here is what
happens. Anyone ever experience anything similar. This or similar
untrackable problems happen to me whenever I write a large class...
anyone have had similar experiences???

1. Post a code sample.
2. say what version of g++ you are using.

All compilers occasionally give internal errors. If you are using a
recent version, it is likely that there is an error in your code which
g++ doesn't know how to diagnose. Try compiling on at least one other
compiler. When you find out what's tripping up g++, you, or someone in
this group, can probably find a workaround.

Jonathan

 

[Jonathan Turkanis]

compiler. When you find out what's tripping up g++, you, or someone in
this group, can probably find a workaround.

I mean IF it turns out to be a real problems with g++, and not with
your code.

Jonathan

 

[P.J. Plauger]

I mean IF it turns out to be a real problems with g++, and not with
your code.

An internal compiler error is *always* a real problem with the
compiler, not with user code. Perhaps the compiler is just a
sucker for a syntax error, but that still makes it a sucker.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Rolf Magnus]

Hello,

Allow me to share my frustrations with GNU g++.

Why don't you do that in gnu.g++.help?

This is the second time something similar happens to me: I can't find
anything wrong with my C++ program and yet I get segfaults, and
eventually, here is what happens. Anyone ever experience anything
similar. This or similar untrackable problems happen to me whenever I
write a large class...
anyone have had similar experiences???

Until now only with "gcc" 2.96, which is not a gcc release, but rather
an infamous fork by RedHat. The early versions of this one gave me real
headaches, crashing often.

make
g++ -c matrix.cpp -Wall -g
matrix.cpp: In member function `void
Matrix::computeDistShortest(bool)':
matrix.cpp:189: internal compiler error: in find_function_data, at
function.c:
313
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccf7vSby.out file, please attach
this to your bugreport
make: *** [matrix.o] Error 1

And now what? You discovered a bug. Compilers, just like all programs,
are not perfect. Did you consider reporting the bug?

 

[Jacek Dziedzic]

An internal compiler error is *always* a real problem with the
compiler, not with user code.

Well, the OP wrote that he gets segfaults and *eventually*
the compiler gives him the internal error. If the segfaults
are *his* program crashing, he might well have undefined
behaviour by then, which obviously includes having all
subsequent compilatons fail due to mystical internal errors.

Just a possibility, of course.

- J.

 

[Nils Petter Vaskinn]

On Thu, 01 Apr 2004 22:49:47 -0800, Neil Zanella wrote:

OT in c.l.c++ Crossposted and followups set. Leaving all of the original
message for the benefit of the people in gnu.g++.help

Hello,

Allow me to share my frustrations with GNU g++. This is the second
time something similar happens to me: I can't find anything wrong with
my C++ program and yet I get segfaults, and eventually, here is what
happens. Anyone ever experience anything similar. This or similar
untrackable problems happen to me whenever I write a large class...
anyone have had similar experiences???

make
g++ -c matrix.cpp -Wall -g
matrix.cpp: In member function `void
Matrix::computeDistShortest(bool)':
matrix.cpp:189: internal compiler error: in find_function_data, at
function.c:
313
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccf7vSby.out file, please attach
this to your bugreport
make: *** [matrix.o] Error 1

Is the error always at the same place? If yes submit a bug report (after
having searched known bugs) if you can make a minimal example that shows
the problem I'm sure the gcc guys will appreciate it.

If the error happens at different places when compiling identical code I'd
also run checks on the hardware. (eg memcheck86 (correct name?)).
Compilation is pretty heavy on the machine and if you have dodgy memory,
dodgy cpu (overheating?) or other problems that's when they are most
likely to show up.

 

[P.J. Plauger]

Well, the OP wrote that he gets segfaults and *eventually*
the compiler gives him the internal error. If the segfaults
are *his* program crashing, he might well have undefined
behaviour by then, which obviously includes having all
subsequent compilatons fail due to mystical internal errors.

Just a possibility, of course.

Uh, we're talking compile time, long before his program runs.
If the segfaults are *the compiler* crashing, that's a real
problem with the compiler, not with user code. It's a problem
even worse than an ICE.

Why all this effort to apologize for a compiler bug? I've
seen them in all compilers, from time to time. Some compilers
crash more often than others, but all do so. Nothing alters
the fact that a compiler is obliged to survive any kind of
input, without crashing and without reporting an internal
compiler error.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Jeff Schwab]

An internal compiler error is *always* a real problem with the
compiler, not with user code. Perhaps the compiler is just a
sucker for a syntax error, but that still makes it a sucker.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Thank you.

 

[Leor Zolman]

An internal compiler error is *always* a real problem with the
compiler, not with user code. Perhaps the compiler is just a
sucker for a syntax error, but that still makes it a sucker.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Of course, but I get the feeling the poster was trying to say that
erroneous code can "help" a buggy compiler to manifest its bugginess (as I
have no doubt you knew). Sometimes that compiler bugginess can work in a
user's favor (although not in this case, since gcc is free...)

When I was working at CUJ, we used a relatively early version of the
Informix 4GL compiler for SCO Xenix. It was the buggiest compiler I've ever
used, just dumping core left and right when it came across common syntax
errors, and Informix wasn't bothering to fix it because Xenix was fading
into oblivion (although it sure rocked in its day...) So we bitched and
moaned to Informix until, to shut us up, they sent us a free copy of their
debugger-equipped interpretive 4GL system, just so we'd have something
that could diagnose the syntax errors in the code! Once we fixed those
errors, the compiler had a lot less indigestion. And we got a nice debugger
out of it that we couldn't have had otherwise without purchasing that other
package ;-)
-leor

 

[Jonathan Turkanis]

An internal compiler error is *always* a real problem with the
compiler, not with user code. Perhaps the compiler is just a
sucker for a syntax error, but that still makes it a sucker.

Yes, I think that's clear. I didn't mean to imply otherwise.

I realized that I might have lest the impression with my first post
that a workaround would be needed if the code contained an error,
which when corrected, allowed the code to compile successfully.

Jonathan

 

[Jonathan Turkanis]

Of course, but I get the feeling the poster was trying to say that
erroneous code can "help" a buggy compiler to manifest its bugginess (as I
have no doubt you knew). Sometimes that compiler bugginess can work in a
user's favor (although not in this case, since gcc is free...)

I guess I wasn't very clear. I was just trying to make what I thought
was an obvious point, but might not be to someone who has never seen
an internal compiler error: the internal error, which is clearly a
problem with the compiler, usually goes away when an error is
corrected. The error can often be spotted by using a second or third
compiler. If the code turns out to be correct, there is usually a way
to rewrite the code so that the compiler will accept it.

I've never had an ICE on GCC that didn't represent a problem with my
code. VC6, on the other hand, gives me ICEs all the time with
perfectly correct code, even when I use the standard workarounds.

Jonathan

 

[Claudio Puviani]

I've never had an ICE on GCC that didn't represent a problem with my
code. VC6, on the other hand, gives me ICEs all the time with
perfectly correct code, even when I use the standard workarounds.

I'd be careful making up abbreviations. An ICE is an in-circuit emulator,
not an internal compiler error.

Claudio Puviani

 

[Pete]

Jonathan Turkanis wrote:

VC6, on the other hand, gives me ICEs all the time with
perfectly correct code, even when I use the standard workarounds.

Why do you expect VC6 to work with code written to the C++ standard, when it
was released before the standard was?
Yes, VC7.0 is inexcusable, but VC7.1 made up for it nicely.

- Pete

 

[Rolf Magnus]

I'd be careful making up abbreviations. An ICE is an in-circuit
emulator, not an internal compiler error.

I was thinking of a german high speed train ;-)

 

[Jonathan Turkanis]

I'd be careful making up abbreviations. An ICE is an in-circuit emulator,
not an internal compiler error.

Also an integral constant expression. I think its clear from context
;-)

Jonathan

 

[Jonathan Turkanis]

Jonathan Turkanis wrote:


Why do you expect VC6 to work with code written to the C++ standard, when it
was released before the standard was?

I don't. But with a little work i can usually make it work.

Yes, VC7.0 is inexcusable, but VC7.1 made up for it nicely.

VC7.1 is my main compiler. But I like my code to work, whenever
possible, on a number of others, including a couple of antique ones
like Borland 5.x and VC6.

Jonathan

 

[Jonathan Turkanis]

I'd be careful making up abbreviations. An ICE is an in-circuit emulator,
not an internal compiler error.

I just read your post again. I didn't make up ICE -- it's an accepted
abbreviation. See, e.g.,
http://lists.boost.org/MailArchives/boost/msg50047.php

Jonathan