V3 patch causes EH failures in ILP32 mode

[Benjamin Kosnik]

>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. I'm assuming you mean, definitions of copy
constructors and destructors, and that private declarations w/o
definitions are still fine.

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'd be very disappointed if the V3 ABI changed between 3.4.0 and 3.4.1.

That would be both of us, dude.

>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?

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?
{ }

>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.

This is nice to know thanks.

best,
benjamin