[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81376 --- Comment #15 from Andrew Pinski --- (In reply to Andrew Pinski from comment #14) > So the original case we do handle since r9-3447. I should say the cases where integer type does not fit into float/double is not handled and I cannot find it this was discussed when the patch was submitted or not. See PR 81376 also.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #14 from Andrew Pinski --- So the original case we do handle since r9-3447.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #13 from Andrew Pinski --- *** Bug 95697 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Oleg Endo changed: What|Removed |Added Target|sh*-*-* | --- Comment #12 from Oleg Endo --- (In reply to Rich Felker from comment #8) > This issue report is specific to target sh*-*-* I put that in the target field of the PR initially, but I also wrote in the description above that this looks like a target independent issue. So removing the target field now, to be clear. I don't think anybody should have to deal with that on any target in the backend. It should be handled by earlier stages of compilation, if at all. The prerequisite for this optimization is that the integer variable type can be represented by the floating point type of the comparison exactly. If that's the case, there should be no need to touch anything in fenv. If the floating point constant can't be represented exactly as specified by the code (e.g. comment #3 -- 16777216 becomes 16777217), would that still require setting the inexact flag in fenv? (I don't think so)
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #11 from Harald van Dijk --- (In reply to Rich Felker from comment #10) > On this particular target, and on every target of any modern > relevance, (float)16777217 has well-defined behavior. That was exactly the point of my original comment. I do not understand why you took issue with it.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #10 from Rich Felker --- GCC can choose the behavior for any undefined behavior it wants, and GCC absolutely can make transformations based on behaviors it guarantees or that Annex F guarantees on targets for which it implements the requirements of Annex F. On this particular target, and on every target of any modern relevance, (float)16777217 has well-defined behavior. On ones with floating point environment (most/all hardfloat), it has side effects (inexact), so can't be elided without the flags to make gcc ignore those side effects.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #9 from Harald van Dijk --- (In reply to Rich Felker from comment #8) > So arguments about generality to non-Annex-F C > environments are not relevant to the topic here. The comment it was a reply to suggested (possibly unintentionally) that evaluating (float)16777217 would have undefined behaviour if 16777217 could not be represented by float. A clarification that no, the standard says it only has undefined behaviour if it is out of float's range, so GCC cannot optimise on the assumption that such conversions do not happen, is absolutely relevant to the topic here.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #8 from Rich Felker --- > Floating point types are not guaranteed to support infinity by the C standard Annex F (IEEE 754 alignment) does guarantee it, and GCC aims to implement this. This issue report is specific to target sh*-*-* which uses either softfloat with IEEE types and semantics or SH4 hardfloat which has IEEE types and semantics. So arguments about generality to non-Annex-F C environments are not relevant to the topic here.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #7 from Harald van Dijk --- (In reply to Rich Felker from comment #6) > > Only if the int is out of float's range. > > float's range is [-INF,INF] (endpoints included). There is no such thing as > "out of float's range". Floating point types are not guaranteed to support infinity by the C standard, and checking GCC sources, it appears to support at least one representation without infinities (VAX).
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #6 from Rich Felker --- > Only if the int is out of float's range. float's range is [-INF,INF] (endpoints included). There is no such thing as "out of float's range".
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-17 Component|middle-end |tree-optimization Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- .
