Re: [PATCH, take 2]: Suffix for __float128 and __float80 FP constants

["Uros Bizjak" <ubizjak at gmail dot com>]

On 6/27/07, François-Xavier Coudert <fxcoudert@gmail.com> wrote:

> > I believe that this is the last missing piece for full 128bit floats support.
>
> Although I think we're close to that point, I have one more point in
> mind: I think it should be decided whether or not we want to allow the
> "_Complex __float128" syntax or not (PR32187: _Complex is not allowed
> for typedefs, and __float128 is a builtin typedef). My personal
> opinion is that it would really be easier to deal with (otherwise we
> need to use "_Complex float __attribute__((mode(TC)))"), but in any
> case it would be nice if a decision could be reached. What is the
> opinion of C maintainers?

Not speaking as a C maintainer, but as a user I think that "_Complex
__float128" syntax should be allowed. However, IMO this is not a
blocking feature, as we have a fully functional alternative in the
form of __((attribute))__. [Blocking in the sense that any further
develompent should't be blocked by this issue].

OTOH, H.J, Steve - does icc or HPUX compiler allow "_Complex __float128"?

> > BTW: All that remains for a brave hero is to take care that
> > http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/ieee754/ldbl-128/?cvsroot=glibc
> > uses __float128 instead of 'long double' and Q suffix instead of L for x86_64.
>
> Do you mean that it should be included in glibc, or in some GCC subdirectory?

IIRC, glibc maintainers claim that glibc implements all that is
required for standard implementation. So the only way forward is to
reactivate the idea of libgcc-math. Unfortunatelly, this is waiting
for some political decisions for almost a year now.

BTW: Could gcc steering committe help here to move the idea of
libgcc-math forward?

Uros.