On Wed, 5 Mar 2014, Thomas Preud'homme wrote: > > 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. > > Do you have some example of such libgcc functions? Is there any of them > with no link to the use of float in public interface? Without knowing > any such case from the top of my head I would say that the use of any of > these functions make the compilation unit not compatible with both > calling conventions since it requires libgcc for a specific calling > convention but maybe the runtime library can be treated differently than > other libraries.
The functions affected use floating-point in their public interfaces - for example, __muldc3. Note that libcalls have a different hook (TARGET_LIBCALL_VALUE, ending up using arm_libcall_uses_aapcs_base) from the ones you mentioned. But if you use only functions that pass arm_libcall_uses_aapcs_base (i.e. the floating-point operations defined in RTABI) or don't involve floating point, then you can be compatible with both calling conventions. -- Joseph S. Myers jos...@codesourcery.com
