https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79528
Bug ID: 79528
Summary: DFP double rounding bug
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
r245477 can IMHO double round in certain cases, e.g. I believe
int
main ()
{
// 99999994999999999999999999999999999
_Decimal32 a = (((__int128_t) 0x134261629f6653ULL) << 64) |
0x0c750eb777ffffffULL;
_Decimal32 b = 99999995LL;
_Decimal32 c = 99999995000000LL;
// 99999994499999999999999999999999999
_Decimal32 d = (((__int128_t) 0x1342616101cf34ULL) << 64) |
0xbc8cce9903ffffffULL;
_Decimal32 e = 99999994LL;
if (a != 9.999999E+34DF /* rather than 1.000000E+35DF */
|| b != 1.000000E+8DF
|| c != 1.000000E+14DF
|| d != 9.999999E+34DF
|| e != 9.999999E+7DF)
__builtin_abort ();
return 0;
}
should pass, but it fails (but it failed already before r245477). I don't know
decNumber library enough to fix this (and, I think the double rounding for
integer to _Decimal{32,64} conversions can only happen for 128-bit and larger
types, and the libraries don't really support such conversions anyway).
It seems besides conversion from integer to decimal{32,64} also all the
arithmetics e.g. in real_arithmetics are performed in _Decimal128 precision and
rounded according to that and then rounded again to the corresponding
_Decimal{32,64} type. As the precision in decimal digits of _Decimal64 is just
16 and _Decimal128 is 34 decimal digits, perhaps it is just fine for +/-, but
not sure about multiplication or FMA (if we ever allow that for decimal float).
