https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- I was not attempting to confirm that GCC had a particular bug. In this case: as I said, no excess precision support is hooked up for decimal floating point (i.e., whatever the back end does, the front end behaves as if DEC_EVAL_METHOD is 0; but the back end could still do things like x87 excess precision where it hides that from the front end, although that doesn't apply in this case). The problem in the case of this bug looks like it's actually in convert_to_real_1 where it attempts to optimize conversions applied to the results of arithmetic (e.g. changing (float)((double)float + (double)float into plain float arithmetic). See <https://gcc.gnu.org/ml/gcc-patches/2008-10/msg01221.html>, point (a), where I fixed cases involving loss of precision for DFP and left it to the DFP maintainers to deal with getting it completely correct for DFP.