[Since I can now send emails without disclaimers, I registered to the mailing list with my work email. Thus no need to CC me anymore.]
My apologize for the line length, the MUA says it all I think. It seems to ignore my word wrap setting > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: Wednesday, March 05, 2014 2:13 AM > > > 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. This should be fine with the current implementation as I did the check inside the hooks TARGET_FUNCTION_ARG, TARGET_FUNCTION_VALUE and INIT_CUMULATIVE_ARG. The two former allow to test whether a parameter or a return value is a float while the latter is used to test whether the float ABI actually matters. INIT_CUMULATIVE_ARG is called when knowing where a parameter ends up matters, so when a function is defined (not declared) or when it is called. Checking whether the function is static or variadic allow to have a complete check. Inlining does not need any additional check since if the function is inlined there is no call and if not there will be a call and the current checks will catch it. However, one thing I did not do is look in function calls if the return value is ignored or not. If it is ignored the float ABI does not matter. > > 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. > > 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.) Yep I took this into consideration. Best regards, Thomas
