This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH], Add optional IEEE/IBM long double multilib support


On Fri, 5 Jan 2018, Michael Meissner wrote:

> On Fri, Jan 05, 2018 at 05:28:03PM +0000, Joseph Myers wrote:
> > On Thu, 4 Jan 2018, Michael Meissner wrote:
> > 
> > > 	(CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> > > 	accomidate -mabi=ieeelongdouble multilibs.
> > 
> > Why is that correct in the -mabi=ibmlongdouble case?
> 
> The PowerPC TFmode has always been 'special'.  It would mirror the 128-bit long
> double format.  For the one port that actually used IEEE 128-bit floating
> point, TFmode was IEEE.  For the the majority of ports TFmode is IBM extended
> double.

I don't think this answers my question.

CVT_FLOAT128_TO_IBM128 has an argument VALUE that is always of IEEE 
format.  You're doing "TFtype __value = (VALUE);".  In the case where 
TFmode is IBM long double, and so therefore is TFtype, this will do an 
unwanted conversion.  I'd expect it to result in __extendkftf2 recursively 
calling itself, in fact.  If it does not, what's wrong with my reasoning, 
and what exactly does that line do in the case where long double is 
ibm128?

> Yes, in C code _Float128 _Comples works.  The trouble is compiling
> libstdc++-v3.  In C++, we don't have _Float128, and __float128 _Complex does

My comments are about changes to code in libgcc, not about libstdc++-v3.

> > (My understanding is that each of the libgcc functions is meant to have a 
> > particular ABI that does not depend on the format of long double - so the 
> > "tf" and "tc" functions refer to ibm128 format, unconditionally, and the 
> > "kf" and "kc" ones to binary128 format, unconditionally.  I have not 
> > checked whether the libfuncs handling in init_float128_ibm and 
> > init_float128_ieee is sufficient to achieve this in all cases.  In 
> > particular, does complex arithmetic always use the correct one of "kc" and 
> > "tc" depending on the long double format?  What about __builtin_powil - 
> > does that properly use __powitf2 and __powikf2 as appropriate, or do you 
> > have the ABI of __powitf2 depending on the multilib?)
> 
> Libgcc does not need to be multilibed.  It uses separate functions.  What does
> currently need to be multilibed is libstdc++-v3 and possibly GLIBC.

I don't see how you ensure __mulkc3, for example, always uses IEEE format, 
given that you're making it use TFtype (= IBM long double in the default 
case).

I don't see how you ensure that, when IEEE long double is the default, 
__multc3 is still built to use IBM long double, which is the ABI for that 
function name.

Likewise for __divkc3, __divtc3, __powitf2, __powikf2.

For that matter, when building with IEEE long double as the default, how 
do you ensure that libgcc functions such as __fixtfti (built from generic 
libgcc2.c sources, in that case) are built with the proper ABI, meaning 
use of IFmode for the arguments or results corresponding to the "tf" in 
the name?

-- 
Joseph S. Myers
joseph@codesourcery.com


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