This is the mail archive of the gcc@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]
Other format: [Raw text]

Re: g++.old-deja/g++.mike/p7325.C - suspected bogus test case


Mark Mitchell <mark@codesourcery.com> writes:

> The point I was trying to make is that the alias analysis code
> should be taught about object lifetimes, if it has the behavior you
> describe.  In other words, if we already did the optimization the
> test is (trying to) test for, then introducing the optimization
> behavior you describe would be a regression.  I think my reaction to
> your insight is "we should make sure the optimizer guys know about
> this issue so they get this right" rather than "we should expect
> this test to fail when the optimizer gets smarter."

Ah.  I get it now.  Agreed.

...
> So, I agree -- the compiler could reasonably fail this test either
> with optimization enabled or disabled, on plausible architectures.
> Therefore, it's OK to remove this test for 3.4.1 and on the mainline.

Done.

> (By the way, given this analysis, your stack-frame dumping switch
> wouldn't help; the problem is that we don't really have a good method
> for saying when the compiler must reuse stack slots and when it must
> not.  Probably best to measure the total stack usage of some
> representative program(s) -- of which this might be one.)

Good point.  I know this is a critical issue for Linux kernel
development, and I would expect it to be the same for embedded
environments - both are places where the total available stack 
for a thread is very small.  Perhaps we could get some input
from people in those domains on how to measure this?

zw


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