https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to jos...@codesourcery.com from comment #2) > On Mon, 4 Mar 2019, rguenth at gcc dot gnu.org wrote: > > > where the first result is off. The IL looks like > > > > int r = (int) ((long double) log (p) * (long double) inv_log_of_base); > > > > where possibly the missing cast to (double) is elided by bogus optimization > > (didn't try to track down the issue yet). > > What missing cast to double? > > 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. Note the frontend _does_ originally emit (int) (double) ((long double) log (p) * (long double) inv_log_of_base) but the conversion to double is elided by convert_to_real in the code piece I qouted.
