[Bug middle-end/26374] Compile failure on long double

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Mar 8 20:22:13 GMT 2022


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #15)
> (In reply to beebe from comment #14)
> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
> > 
> > That is a really old one, from early 2006; I would have hoped that it
> > had long since been repaired in gcc.
> > 
> > However, I just checked my VM for CentOS 7 on PowerPC, and found this:
> 
> Well powerpc currently uses what is called double double for 128bit long
> double. GCC does not know how to constant fold that nicely. But powerpc
> linux targets are moving over to use standard 128bit IEEE long double and
> IIRC for GCC 12 (or is it 13) will default to IEEE long double so this will
> be less of an issue.

Will not default to unless configured so, but e.g. in Fedora 36 GCC 12 is
configured to default to long double being IEEE quad on powerpc64 little
endian.
As for constant folding, even with double double gcc is able to fold some
constant arithmetics in that format, but because the emulation is only
approximate (it pretends it is 106-bit precision format while in reality it is
variable precision up to some thousands depending on the exact values).
As has been said elsewhere, the emulation would be implementable if gcc handled
double double in all the arithmetics as a pair of doubles with all the rules
for it.  But e.g. mpfr/libmpc isn't able to do something like that, so we'd
need to compute everything with much bigger precision etc.
In any case, I think nobody is going to work on it now that ppc64le is
switching to IEEE quad.


More information about the Gcc-bugs mailing list