V3 patch causes EH failures in ILP32 mode

[Mark Mitchell]

Benjamin Kosnik wrote:

>>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 just did this audit. 
>
Great, thanks!

>I'm assuming you mean, definitions of copy
>constructors and destructors, and that private declarations w/o
>definitions are still fine.
>  
>
That would still trigger the ABI change -- except that now nobody can 
copy the objects, so it should not matter.  In other words, this is an 
API change, not an ABI change.  Clearly you intended that change, and 
knew that some programs that used to compile will no longer do so, so I 
think we're OK.

>I see, 
>
>__gnu_debug::_Error_formatter
>
>as the only possible issue. Since this is in the debug mode, eh, I'm not worried.
>If you feel otherwise, lemme know, and I'll remove this bit.
>  
>
I'm willing to trust your judgement.  If you don't think that changing 
the ABI for this class matters, that's OK with me.

>I'm trying to figure out how to machine-check this. So, you're saying that
>
>
>class nonpod
>{
>	int a;
>}
>
>will be different than
>
>class nonpod
>{
>	public:
>	int a;
>nonpod(const nonpod& o) : a(o) {}
>}
>
>for:
>
>void foo(nonpod a) // not by ref?
>{ }
>  
>
Correct.  Adding either a copy constructor a destructor will trigger the 
change.  This does not only apply to PODs, however; it applies to any 
class whose copy constructor and destructor would otherwise be trivial.  
(That includes, for example, classes with base classes, but with no 
members that themselves have non-trivial constructors.)  It also applies 
to by-value returns as well as by-value parameters.

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