[Bug c++/11376] [3.3/3.4 regression] mozilla-1.4 miscompiled

["kevin dot hendricks at sympatico dot ca" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From kevin dot hendricks at sympatico dot ca  2003-07-08 19:07 -------
Subject: Re:  [3.3/3.4 regression] mozilla-1.4 miscompiled

Hi,

One question ... if the original mozilla code is not strict-aliasing 
safe
as seems to be the case, why does this problem only impact ppc linux 
gcc 3.3
and not other ppc platforms nor it seems any other platform?

In particular x86 seems to be immune to most strict-aliasing violations
(the JDK,  OpenOffice.,org, and now Mozilla  are not aliasing safe) but 
the
bug always seems to miss x86 but ends up biting ppc.

Does that mean that fewer instructions are actually reschedule-able
based on this optimization under x86?  If so, what benefit actually
occurs from assuming strict-aliasing on most platforms?

Is there any measurable improvement on any platform?

Finding these types of violations is extremely time consuming and
it is hard to convince a non-impacted developer that his/her code is
incorrect (they keep saying it runs fine on x86 so it must be a ppc
specific problem).

It is simply hard at first glance to see that:

  if B's parent is A then
     A* can hold a B* and be completely type legal
     B* can hold an A* (via a downcast)
     Both A* and B* can hold a B*  (and be completely type)

But
*(B**) is not the same as a *(A**) from the point of view of aliasing.

Unfortunately, without some form of warning about when the
optimization is used it is next to impossible to find and fix all
of the occurrences.

Thanks,

Kevin