V3 patch causes EH failures in ILP32 mode

[Mark Mitchell]

Gabriel Dos Reis wrote:

>You Wrote
>
>  
>
>>>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 haven't yet seen a reply  to my concern that adding copy constructors 
and/or destructors may have changed the V3 ABI between 3.4.0 and 3.4.1.  
Has anybody on the V3 side done an audit to make sure that nothing was 
affected?  If nobody has done this audit, then would one of the V3 
people please do the audit ASAP? 

I'd be very disappointed if the V3 ABI changed between 3.4.0 and 3.4.1.

This audit cannot be done by looking at exported symbols; you have to 
check all classes that are visible to users.  A user might have a 
function taking a parameter of class type that is affected by this 
change.  If the class now has a copy constructor or destructor and had 
neither before, then the ABI was broken.  Is there someone who will 
check that, please?

Also, I've now verified that change to add "this != &r" test to 
"opterator=" in "__upcast_result" results in inferior code; the test is 
not optimized away by the compiler, but it turns out that the only user 
of "operator=" the test is true, so we execute the guarded code anyhow.  
I do not expect that in this particular case there will be any noticable 
performance degredation, but I think that the V3 maintainers should be 
aware that this style of change is going to cause the compiler to 
generate inferior code.  If it's decided that these kinds of changes are 
useful, I would recommend that the test not be included.  It cannot be a 
correctness issue if the code was OK before since the implicit version 
does not have the test, and it will almost never be a performance 
advantage; the compiler will eliminate the copies anyhow if it can show 
that the two sides are the same.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com