This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: libffi trunk: new regressions on x86_64-linux-gnu, some test failures left on i686-linux-gnu
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?)