https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
I don't think there's a reasonable way to "solve" this apart from saying that
complete ABI compatibility is required, and enumerating rare exceptions where
it's not.
Like you say, storage layout must be the same: size/align of all types must
match (note this isn't true today for 'long double' and it's not even
diagnosed), but also endianness, signedness of 'char'. Layout of _Complex
types. Layout of structs that library functions operate on (e.g. div_t). As an
exception, va_list type need not match, because data of this type is not usable
on both host and accel sides.
Typedefs must match, even if underlying types happen to be binary compatible
(e.g. C++ mangled name of '::operator new' differs based on whether size_t is
'unsigned' or 'unsigned long').
Basically I'd say that host compilation environment establishes an ABI baseline
that the accel environment must follow. In your finite-math example, the
problem exists due to an ABI extension in Glibc (note that the custom name
could equally happen to be __glibc_log_finite). You'd see the same issue
trying to run a new binary on old Glibc systems that didn't have that symbol
yet, and now Glibc itself is bound to carry that entrypoint forever. And note
that the issue is not limited to math symbols either: with -D_FORTIFY_SOURCE,
plain 'printf' may become '__printf_chk', which would also fail to link on
Newlib.
Is there any actual issue with Fortran functions? As I understand, they are
provided by libgfortran, so ABI incompatibilities due to source-level
differences, like in Glibc-vs-Newlib above, don't exist. If there are ABI
issues due to other reasons, it should be reasonable to just fix those.
