This is the mail archive of the
mailing list for the GCC project.
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
- From: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Tue, 18 Mar 2014 16:08:51 +0800
- Subject: RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
- Authentication-results: sourceware.org; auth=none
- References: <873b32b6c5ab5233abff5083d7e7f57a at celest dot fr> <6D39441BF12EF246A7ABCE6654B023534B53F7 at LEMAIL01 dot le dot imgtec dot org> <93929e2462c9db9ad544a5fa33f91388 at celest dot fr> <Pine dot LNX dot 4 dot 64 dot 1403041804560 dot 5296 at digraph dot polyomino dot org dot uk> <000101cf3886$d2ce43e0$786acba0$ at arm dot com> <Pine dot LNX dot 4 dot 64 dot 1403051802530 dot 23869 at digraph dot polyomino dot org dot uk>
> From: email@example.com [mailto:firstname.lastname@example.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)
> 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).