Mail Archives: djgpp/1997/11/06/05:22:11
On Thu, 6 Nov 1997, Davin Pearson wrote:
> I find it hard to believe that very many people seriously
> use G++.
[snip]
> It therefore seems that "Internal
> compiler error" is a dead-end when it comes to using G++.
IMHO, you are jumping too fast to conclusions which are too extreme.
Correct me if I'm wrong, but I'd guess that you haven't seen this with
too many programs. How many different programs did you try to compile
and how many of them crashed the compiler that way?
> Having just read the DJGPP FAQ on this problem, I can report having no
> joy with -fno-strength-reduce, and "gcc -v" says version 2.7.2.
The FAQ also tells you (section 6.4) that ``internal compiler error''
might be caused by insufficient stack available to cc1plus.exe (the
C++ compiler invoked by gcc and gxx), and explains how to fix that.
Did you try that advice?
You also seem to use an old GCC version, which is known to have
optimization-related bugs. The latest DJGPP-ported version is
2.7.2.1 (v2gnu/gcc2721b.zip and v2gnu/gpp2721b.zip).
> Why is G++ so bad? Is it C++'s fault or something?
Some C++ constructs require gobs of memory to parse and optimize. C++
is evolving fast, and so is the compiler. The next versions might
have some of these problems fixed.
Usually, subdividing your code into smaller functions helps avoid
these problems (and also makes the code more modular).
> Does anyone have experiences of "internal compiler errors" with
> commercial C++ compilers?
The trade magazines are full of such stories. The source code of
large portable applications is full of comments that explain how
certain work-around was required to prevent certain compilers from
crashing. Relax, the bugs are here to stay, and compilers are just
programs, no more, no less. At least judging by the traffic on this
news group and on GNU groups related to compiler bugs, GCC has
relatively small amount of bugs, even when compiling C++ programs.
- Raw text -