> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Joseph S. Myers > > 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.
Thanks for the input Joseph and sorry for taking so long to reply. So I checked for the case of __mul* function and I believe there shouldn't be a problem as ARM backend never generate any call to these functions (at least according to my grep). Therefore, the only way these functions could end up being used is if a programmer explicitely call it after declaring its prototype and in such a case the call would appear in gcc as a normal function call and would thus be catched by the checks for normal (non libcall) inter compilation unit function call. I need to check however that all functions defined by libgcc fall in the same category as __mul* functions. With regards to TARGET_LIBCALL_VALUE, I will only have to consider it if there exist some libcall function where the calling convention is decided by the compiler. If all libgcc functions not in the ARM runtime ABI are like __mul, it shouldn't be a problem. Of course, all this is only true for ARM, things would be different for avr for instance (backend generates call to __mul* functions). Best regards, Thomas Preud'homme
