https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61203
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2014-12-01
CC| |jason at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail|4.10.0 |5.0
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > same spot. No idea what to do against this though, treating a CLOBBER as a
> > barrier for propagation of addresses to other local variables would penalize
> > stuff way too much.
>
> Conceptually this should be the right thing. The clobber says
> the object doesn't exist anymore, so also forming its address should be
> invalid/implementation defined. Either the clobber should move or it should
> be a barrier also for addresses of the clobbered object. I'm not sure if
> that
> really would penalize much.
But I don't see how it could be easily implemented.
> > And giving up on stack slot sharing because of such an
> > artificial testcase is not useful either.
>
> Perhaps expansion could detect the situation (address of clobbered object
> leaked after the clobber) and disable sharing just for such problematic
> objects.
Likewise. (it would be whether the address escaped the function before
the clobber)
I'd rather say that optimization is permitted to make &a and A(a).get_this ()
equal.
Btw, there is also the missed optimization that get_this, discovered as
'const', passed &decl can only return either NULL or an address based on
&decl and thus the result cannot compare equal to &a. So even without
inlining we could statically compute the comparison.
