On Wed, 5 Mar 2014, Thomas Preudhomme wrote: > Right. It's actually quite simple. As soon as you meet a function which passes > or returns a float then you can mark the whole module as not agnostic and fall > back to the usual behavior. If you arrive at the end of a compiling unit > without encoutering such a case then you are agnostic. You could mark each > function individually but I don't think it's necessary to go that far. If you > want only some functions to be compatible you could put them in a separate > file. My current patch goes a bit beyond than this in that it only care about > public interface. Call withing one module can use whatever calling convention > they want, it does not change the ABI.
If the function is only declared and not called or defined (in a system header etc.), of course you don't want that to affect the ABI (even in the case of an inline function in a system header, unless an out-of-line call is generated to it). But a call to a function not defined in that unit does affect the ABI compatibility, if the call involves affected types. Some libgcc functions on ARM have ABIs that depend on which AAPCS variant is in use - that is, libcalls, not just explicitly defined or called functions, can affect the ABI compatibility. But the RTABI functions don't - if you allow for that, then you increase the number of cases that end up compatible with both ABI variants. On ARM, variadic functions use only the base AAPCS and so don't affect compatibility even if they have floating-point (or vector) arguments. (This is something that's different on some other architectures with similar issues.) -- Joseph S. Myers jos...@codesourcery.com
