On Tue, 18 Mar 2014, Thomas Preud'homme wrote: > > 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
It's not the backend that generates calls to most libgcc functions, but the core compiler (when the optabs don't define a way of expanding some operation inline), which will happily generate calls to __muldc3 on ARM for multiplication of double _Complex values. -- Joseph S. Myers jos...@codesourcery.com
