https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 13 Mar 2019, joseph at codesourcery dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573 > > --- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery > dot com> --- > On Mon, 11 Mar 2019, rguenth at gcc dot gnu.org wrote: > > > > I wouldn't expect such a cast to be generated on the result of the > > > multiplication; I'd expect long double to be converted directly to int. > > > There is, indeed, a test of that (see test_cast in > > > gcc.target/i386/excess-precision-1.c). > > > > Exactly why? The multiplication result has excess precision here. > > Do you say an extra rounding step to double precision cannot change > > the conversion to integer result or do you say such extra rounding step > > isn't allowed here? IMHO this is exactly the "issue" pointed out by > > the testcase. > > The extra rounding step isn't allowed by the language semantics as I > understand them. The result of the double multiplication is represented > with the range and precision of long double and must be converted directly > to int, not to double and then to int. I see. This means the different cases in the testcase in question are not equivalent (when excess precision is involved) and thus the expectation that they produce the same value is wrong which means the bug is INVALID?
