This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]