Re: V3 patch causes EH failures in ILP32 mode

[Mark Mitchell <mark at codesourcery dot com>]

B. Kosnik wrote:

> > you added seemingly pointless implementations of __upcast_result's
> > copy constructor and assignment operator; these versions are almost
> > identical to the implicit definitions.  On HP-UX in ILP32 mode, this
> > change is causing several G++ testsuite failures relating to upcasts
> > during EH processing.
>
>
> Wow.
>
> Well, I added these so that -Weffc++ could be used in CXXFLAGS while
> building libstdc++.  This was a longstanding issue w/ v3 that was an
> annoyance to several C++ maintainers (myself included, naturally!).

Ugh.  Do you really think this kind of change is worth it?  I'm all for 
Scott Meyers, but now every time we add a data member we've got to 
remember to update these functions...

> I wasn't expecting any issues like this to surface.

It seems to be an interaction between the explicit test in the "operator 
=" (which, as you note, is the major difference from what the compiler 
does) and the use of "__restrict" in several places in that file. 
(Removing either one makes the problem go away.)

This does show, however, how little clean-ups can have serious 
repurcussions.  It's good we're finding the codegen bug, but it may or 
not be worth the effort; the codegen bug is probably pretty rare, and EH 
 is now pretty much busted on this platform, which is going to affect 
lots of programs.

> Just out of curiosity, can't you also change this (AFAICT) textbook C++
> to something that doesn't check for self, and produce equivalent code to
> the implicitly generated functions? If not, is there a way to produce
> equivalent code with explicit definitions? I'm surprised that there's
> such a difference: can you humor me with additional details?

The other difference is that the compiler may use a bitwise copy in many 
situations.  (It certainly could in this case, although I don't know if 
it actually does.)  By writing things out explicitly, you're going to 
make the compiler work hard to figure out that the various reads/writes 
are all contiguous and that any padding in-between can be safely copied 
as well.

Also, the test -- the "this != &r" bit -- is not necessary for 
correctness for this class and is always satisfied; there is exactly one 
use of this operator and it does not copy between things which have the 
same address.  That will therefore be a pessimization, unless the 
compiler can figure out that the test is redundant.

I would advise against making these kinds of functions explicit, except 
when necessary.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com