In encode_ieee_double/quad, the assignment
unsigned long WORD = r->sign << 31;
is intended to set the 31st bit of WORD whenever the sign bit is set.
But on LP64 hosts it also unintentionally sets the upper 32 bits of WORD,
because r->sign gets promoted from unsigned:1 to int and then the result
of the shift (equal to INT_MIN) gets sign extended from int to long.
In the C++ frontend, this bug causes incorrect mangling of negative
floating point values because the output of real_to_target called from
write_real_cst unexpectedly has the upper 32 bits of this word set,
which the caller doesn't mask out.
This patch fixes this by avoiding the unwanted sign extension. Note
that r0-53976 fixed the same bug in encode_ieee_single long ago.
PR c++/98216
PR c++/91292
gcc/ChangeLog:
* real.c (encode_ieee_double): Avoid unwanted sign extension.
(encode_ieee_quad): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-float2.C: New test.
(cherry picked from commit
34947d4e97ee72b26491cfe5ff4fa8258fadbe95)
const REAL_VALUE_TYPE *r)
{
unsigned long image_lo, image_hi, sig_lo, sig_hi, exp;
+ unsigned long sign = r->sign;
bool denormal = (r->sig[SIGSZ-1] & SIG_MSB) == 0;
- image_hi = r->sign << 31;
+ image_hi = sign << 31;
image_lo = 0;
if (HOST_BITS_PER_LONG == 64)
const REAL_VALUE_TYPE *r)
{
unsigned long image3, image2, image1, image0, exp;
+ unsigned long sign = r->sign;
bool denormal = (r->sig[SIGSZ-1] & SIG_MSB) == 0;
REAL_VALUE_TYPE u;
- image3 = r->sign << 31;
+ image3 = sign << 31;
image2 = 0;
image1 = 0;
image0 = 0;
--- /dev/null
+// PR c++/98216
+// PR c++/91292
+// { dg-do compile { target c++20 } }
+
+template<auto> void f() { }
+
+template void f<-1.0f>();
+template void f<-2.0f>();
+
+template void f<-1.0>();
+template void f<-2.0>();
+
+template void f<-1.0L>();
+template void f<-2.0L>();