https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
Tijl Coosemans <tijl at coosemans dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tijl at coosemans dot org
--- Comment #15 from Tijl Coosemans <tijl at coosemans dot org> ---
(In reply to Jakub Jelinek from comment #8)
> That said, I'd say that every conversion to double that would change the
> sign looks wrong to me, no matter of what the rounding mode is, except
> perhaps for NaN canonicalization and that sNaN could be signalled. So IMHO
> this is mostly an optimization thing, not correctness.
I do think this is a correctness problem for long double. Consider the
following C code:
int test( long double x ) {
return( __builtin_signbit( x ));
}
With "gcc49 -O2 -S test.c" on x86_64 this compiles to:
fldt 8(%rsp)
fstpl -16(%rsp)
movsd -16(%rsp), %xmm0
movmskpd %xmm0, %eax
andl $1, %eax
ret
The fstpl instruction converts long double to double and may generate all kinds
of floating point exceptions if the value can't be converted exactly and I
don't think signbit(x) is allowed to generate FP exceptions. So it would be
best to fix the c_std version too.
