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

["vincent-gcc at vinc17 dot net" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #21 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jakub Jelinek from comment #16)
> 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.

Well, the C standard does not require correct rounding, and while correct
rounding is important for the IEEE formats, it is rather useless for the
double-double format, whose goal was just to provide more precision than
double, but still be rather fast (compared to quad emulation). The main
drawback would be that results could be different whether a FP expression is
evaluated at run time or at compile time, but unless users seek to control
everything (e.g. with IEEE formats), they should get use to that (FYI, you can
have the same kind of issues with the contraction of FP expressions, such as
FMA generation from mul-add, which GCC enable by default). So, in short, doing
the compile-time evaluation at a 106-bit precision or more would be acceptable
IMHO, at least better than a compiler error.

Note: Even though double-double can be very interesting as a compromise between
performance and accuracy, there exist various algorithms and which algorithm
should be chosen depends on the context, which only the author of the program
can know in general. Thus it was a bad idea to implement double-double as a
native FP type (here, long double); instead, the selection of the algorithms
should be left to the developer. So the switch to IEEE quad is a good thing.
But for how long will old ABIs be around?