https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #7)
> I don't think that the middle-end converts pow(, int-valued) to powi anywhere
> as generally the result can be off too far (maybe we could for some known
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #7 from Richard Biener ---
Note that absence of flags such as -ffast-math only libstdc++ knows whether
the standard allows pow(, int) to be implemented with more than a single
rounding.
I don't think that the middle-end converts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #6 from Vadim Zeitlin ---
> One might complain that it only does this transformation when the second
> argument is a constant, not for casts of integer variables to long double.
Yes, in the light of new information, this is what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #5 from Marc Glisse ---
(In reply to Vadim Zeitlin from comment #4)
> Thanks for the explanation! I didn't realize the template function below was
> smart enough to select __builtin_powil() automatically,
The template selects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #4 from Vadim Zeitlin ---
Thanks for the explanation! I didn't realize the template function below was
smart enough to select __builtin_powil() automatically, this is quite
impressive (although it doesn't happen in my particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #3 from Marc Glisse ---
On linux with glibc, both versions output the same number, so your libm is to
blame. Normally, the int version, implemented with multiplications, may be less
accurate than the general version. And gcc does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #2 from Vadim Zeitlin ---
Sorry if I misunderstood but what exactly am I misinterpreting? Looking at the
code (and comment) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #1 from Marc Glisse ---
You are misinterpreting Howard's answer. Please show code that currently
doesn't compile and you would like to be able to compile, or code that compiles
(specify the flags used) to asm that isn't as fast as
