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
Attachment:
gcc_bug.tgz
Description: GNU Zip compressed data
