This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: x86-64 XFmode long doubles
> Jan Hubicka <hubicka@ucw.cz> writes:
>
> > Hi,
> > the attached patch regoranize long doubles to use XFmodes and adds
> > TFmode support as disucssed earlier.
>
> Looks good...
Good :)
I guess I can approve it myself, so in case no one will complain and we
get to agreemend wrt the symbol naming, I will commit it.
It would be great if you could take closer look on the interface bits.
Since situation is 100% equivalent to IA-64 I would expect these to be
fine (or broken for both ports), but one never knows :)
>
> > There is no symbol renaming. I found that only symbols exported by
> > libgcc2.c are floattitf/fixtfti/fixunistfti.
>
> Yes, those are the functions I had to redirect (on ia64, also
> __divtf3, but presumably x86-64 has extended floating divide in
> hardware).
>
> > Since TImode arithmetics is available only for ADA size types that
> > are never converted to float, we never emit these calls (I verified
> > it by grepping binaries in SuSE installation), so perhaps we don't
> > need renaminig at all?
>
>
> I would be delighted to remove the __compat stubs from
> ia64/lib1funcs.asm if it is agreed that they are not necessary.
> However, on IA64, I can get a call to __floattixf (which would
> formerly have been __floattitf) generated with a synthetic test case:
>
> __float80 x(int n __attribute__ ((mode(TI)))) { return n; }
>
> so I'm not totally confident that the compatibility stubs are
> unnecessary.
Such a synthetic testcase would produce conversion on x86-64 too, but we
never documented this extension to work and it does not appear to be
used in practice (using TImode integers on x86-64 pretty easilly leads
to compiler crash).
On x86-64 I would not worry about this testcase, however for IA-64 I
guess you need stub at least for divtf3.
Another issue is whether to rename or not rename the the *tf mode
libcalls currently produced for float128. Using current names would
make it easier to match existing glibc represnetation, but if glibc were
linked with old libgcc2.a, we would get two definitions of the same
symbol. Can versioning solve this?
Honza
>
> zw