This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat

> From: [] 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]