gcc forgets to decrease esp after function call

[Vladimir Simonov]

Andrew Haley wrote:
> Vladimir Simonov writes:
>  > Andrew Haley wrote:
>  > > Vladimir Simonov writes:
>  > >  > The attached test case can be built by compile.sh.
>  > >  > It produces two binaries - test_bin_bad & test_bin_good.
>  > >  > 
>  > >  > test_bin_good prints "Hello word" before exit.
>  > >  > test_bin_bad crashes.
>  > >  > 
>  > >  > The difference is the only -O2 used while test_bin_bad build.
>  > >  > 
>  > >  > The symptoms are the same - incorrect esp usage in caller
>  > >  > after call function returning object.
>  > >  > 
>  > >  > We reproduced the bug in gcc 4.1.0/4.1.1/4.1.2
>  > >  > gcc 3.x can't compile the sources.
>  > > 
>  > > OK, we're getting closer. 
>  > 
>  > Hi
>  > 
>  > Are you capable to reproduce the bug?
> 
> Yes.
> 
>  > > Unfortunately, your test case includes a
>  > > ton of system headers for one particular system/version of gcc, 
>  > But it doesn't contain any #include directive.
>  > It is self consistent.
>  > 
>  > Do you mean that I should
>  > add "#include" for system headers?
> 
> Yes.  Otherwise it's not possible to compile it with any other version
> of gcc than the one you built it on.  A test case should be
> standalone and not depend on a particulat gcc version.

Sending you the test without inlined standard includes.
But the source is still very large - ~1Mb.

> 
>  > I think this way we may made the bug less obvious.
> 
>  > > and it
>  > > also includes a lot of library code not used in your test case.
>  > 
>  > I understood it from the start of discussion :)
>  > I hoped:
> 
>  > 1. GCC delelopers have some tools or methods to automatically
>  > remove text which does not affect codegeneration. Or some compile
>  > stage which contans intermediate data without unused by
>  > codegeneration prototypes, classes, etc.
> 
>  > 2. GCC developers are smart enough to localize and try to fix gcc
>  > having such obvious indication as this - codegenerator "forgets"
>  > that it called function returning object. Is it impossible to find
>  > thin place/places taking into account above, fix it and check by
>  > our test?
> 
> It's up to you, really.  The more self-contained a test case you
> provide, the more likely someone is to fix your problem.  Remember
> that they are, in this case, volunteers, and not highly motivated to
> spend a lot of time to try to remove all the extraneous code.
> 
>  > In such a case the test size has no defference in my opinion.
>  > 
>  > 
>  > > 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?

Regards
Vladimir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc_bug.tgz
Type: application/x-gzip
Size: 81859 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20070315/62af00b5/attachment.bin>