[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|alias, wrong-code           |
             Status|NEW                         |WAITING

--- Comment #9 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-03-15 18:36:33 UTC ---
So, I'm sort of skeptical of this problem.  Please engineer a test case that
shows bad code.  I think you'll find it is a rather bit harder than you expect.
 I think most dynamic things happen at the end of a function call, that you
can't see into (the Object-C run-time), and those things that happen before
that point, must happen before that point, and those things that happen after
that point, can't come before it.  Objective-C adds a ton of these type of
calls all over the place, which controls just how far the optimizer can move
anything.  Escape analysis should quickly realize that it doesn't own much of
anything, which further prevents almost anything from happening.  As for an
individual pointer, statically, the type should always be reasonable, though,
we do expect to up-cast and downcast pointers.  Some on the C side of things
might disagree, but, once the C people realize that up-casting and down-casting
are both valid, then even this is fine.  Once you combine all these factors,
there is no wiggle room left for the optimizer to do anything.  If you can find
any, test case please.  We can then address the specific concern.

Until then, we'll wait for a testcase.

As far as missing language definition bits, please describe a missing bit, be
specific.  I can't think of any off the top of my head.