This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 2.95 : internal compiler error with qt 1.44
Am Don, 05 Aug 1999 schrieben Sie:
> On Aug 4, 1999, kthomas@gwdg.de (Philipp Thomas) wrote:
>
> > Why don't you follow that advice?
>
> He said he couldn't post the code because of licensing restrictions.
>
> Which doesn't mean he couldn't have tried to reduce the testcase until
> it is still enough to reproduce the problem, but small enough that it
> can be rewritten from scratch.
>
First I tried to rewrite a very similar method but the compiler bug didn't
occur. Then I tried to delete a method somewhere before the method which is
causing the compiler bug (in the original QT source code) - the bug didn't
occur. At last I cut & pasted the method to the front of the source (after all
the definitions of course) and the source code compiled without problems. I
suppose I had to rewrite almost everything from scratch to find a test case.
Any suggestions? Ask the Trolls for permission to send a .ii file? They might
give permission because anybody can get the source codes anyway. (but you're
not allowed to spread it in modified / partial form)
While I wrote this mail and doing some testing I just found out that even the
building directory has effects. The building directory affects the -I directory
path which is passed to the compiler:
g++ -c -I/home/dreamer/qt-1.44/include -I/usr/X11R6/include -pipe -O2
-fno-strength-reduce -O2 -fno-strength-reduce -fPIC -o widgets/qmenubar.o
widgets/qmenubar.cpp
works without problems.
g++ -c -I/usr/src/redhat/BUILD/qt-1.44/include -I/usr/X11R6/include -pipe -O2
-fno-strength-reduce -O2 -fno-strength-reduce -fPIC -o widgets/qmenubar.o
widgets/qmenubar.cpp
DOESN't work.
I diffed the .ii outputs of both variants and there were only differences in
the path of the included QT headers :( Running the "buggy" .ii file fails. And
it doesn't matter in what directory the .ii file is compiled or what -I
statements are passed to the compiler. Is it possible that The
# line "include" lines
in the .ii output cause some sort of buffer overflow or is there some
uninitalized data which will be "initialized" by include paths?
Greetings
Alexander