Andrew Haley wrote:
Vladimir Simonov writes:> > > Andrew Haley wrote:> > Vladimir Simonov writes: > > > Andrew Haley wrote: > > > > Vladimir Simonov writes: > > > > > Andrew Haley wrote: > > > > > > Vladimir Simonov writes:> > > > > > > > Fillet that, and you will have a test case that can be submitted. > > > > > > > > > > It requires a lot of mannual work - remove a peace of code, then> > > > > check that the test can be built, the check that the bug did not > > > > > disappear, etc.> > > > > > > > It's your code, so presumably you are familiar with it. I stepped> > > > though the code in gdb, and it seemed that not many routines were > > > > actually involved.> > > > > > We have tried to minimize the test but without significant success.> > > If we try to create simple test case from scratch we can't > > > reproduce the problem. I have a feeling the problem appears > > > if huge templated code involved into codegeneration.> > > > > > If I understand correct it is impossible to file this> > > bug to gcc bugzilla - it does not permit attachements.> > > > > > Do you think I need to post the problem to some another> > > list to get it solved? Or just leave it( and you :) ) alone?> > > > It all depends on what you need. I have this feeling that your> > problem may well be fixed by a more recent g++. It's hard to be sure, > > because your test case does not even compile with a more recent g++. > > This is, I suspect, becasue we have improved g++ to be closer to the > > real ISO C++ standard.> > > > g++ Version 4.3 reports a number of type mismatch errors in the area> > that may be causing problems. It is quite possible that if you fix > > these errors your problem will go away.>
Hi,
Unfortunatelly I had no time to play with gcc 4.3 but we
have some progress.
1. We put the function returning object into "for".
So the test always crashes if generated code in incorrect
("sub $0x4, esp" after function call is missed).
The previous test not always crashed if esp corrupted.
It depended on how esp is used after call(and function
exit method - via "add XXX, esp" or "mov ebp, esp").
Now stack is "eaten" by "for" if "sub $0x4, esp" is missed.
2. Then we found optimization option which leads
to incorrect code generation. It is -ftree-sra.
At the moment our problem is solved.
Probably new test and knowlege about the option
will help somebody to find and to fix the bug.
Thank you.
Regards
Vladimir
Attachment:
gcc_bug.tgz
Description: GNU Zip compressed data
