[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Calling convention for "Routines for floating point emulation"
From:       Yichao Yu <yyc1992 () gmail ! com>
Date:       2016-10-22 14:34:08
Message-ID: CAMvDr+TGAsdLgrjT2vqL5xhJnXeaoD8VFAoaX-pmQDT41AnGpA () mail ! gmail ! com
[Download RAW message or body]

Ref https://llvm.org/bugs/show_bug.cgi?id=30543#c10

> > That should not be the case, for libgcc functions that are not in RTABI.
> > They should use the ABI of the multilib they are compiled for, which may
> > be base ABI or VFP ABI depending on the options used for compiling that
> > multilib.
> 
> Interesting, I wonder how multiple people came to the same conclusion (that they \
> use the base ABI) given the behavior of libgcc.

(See link above) I've confirmed that the first version of gcc that
supports vfp abi (4.5.0) and also the 4.6.3 shipped with debian 7 both
use the vfp ABI for these functions.

> > Functions such as __powidf2 and __mulsc3 are not part of the software
> > floating-point library.  They use the same ABI as any other C functions
> > with their type.
> 
> The fact that they are listed under "4.2.4 Other floating-point functions" of the \
> "Routines for floating point emulation" makes this rather confusing. 
> Is there some other resource other than libgcc.texi that can be used to determine \
> the calling convention requirements?

So I assume the convention is that

> Except where an external ABI defines things like that, the normal
> expectation for libgcc functions is that they have the same ABI as for an
> ordinary C function with the same prototype.  That is, since libgcc.texi
> gives a prototype for __powidf2 without saying anything special about its
> ABI, and since it is not a function defined in RTABI, it can be taken to
> use the VFP ABI when compiling for that ABI.

? This seems to be at least self consistent. However, since it is
apparently confusing for people who knows that some functions should
use the base ABI, maybe it'll be helpful for future readers to
explicitly state this in the doc?


[prev in list] [next in list] [prev in thread] [next in thread]