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).