Re: libffi trunk: new regressions on x86_64-linux-gnu, some test failures left on i686-linux-gnu

["Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>]

On 2018-05-05 06:51, Anthony Green wrote:
> These failures are showing up because we're testing the microsoft ABI 
> now.
> 
> This looks like a bug in GCC.  It's not returning small structures with
> floating point values in the right registers when following the 
> Microsoft
> ABI.  I'm going to figure out how to 'xfail' those tests and open a bug
> against GCC.   Clang appears to get it right.

When would this be an actual issue?

What function in what Windows DLL returns a structure with 
floating-point values, and is that Windows DLL compiled with GCC so that 
the return representation is wrong? Cygwin code, maybe?

It the situation broken, or is it consistent? I mean, can a test case be 
written for GCC which shows that the structure return is corrupted, when 
both the caller and callee are compiled with the same GCC and same ABI? 
Or does the calling code match the return conventions?

If things are consistent, then fixing it in GCC requires versioning of 
some sort. If someone upgrades GCC to the fix and then recompiles only 
the caller of such a function, or only the callee, the now mismatching 
call will misbehave.

In a distro, if program P depends on library L, usually we can update P 
independently of L. If the compiler used for P has changed, this is no 
longer the case; the new P has an ABI change which has to pull in a new 
L. (At least, if the ABI change is relevant to P-L; who is going to 
check that for all packages?)