https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Michael Meissner from comment #6)
> Unless -ffast-math or -fno-honor-nans is used, you cannot invert < to >=,
> because you will get a different result if either operand is a NaN.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
--- Comment #6 from Michael Meissner ---
Unless -ffast-math or -fno-honor-nans is used, you cannot invert < to >=,
because you will get a different result if either operand is a NaN. However,
the basic code for vector compares hasn't changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
Bill Schmidt changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to amker from comment #3)
> For function sign_lt and uns_lt, the change causes worse code generation
> unfortunately. Take uns_lt as example, the difference in optimized dump is
> So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
--- Comment #3 from amker at gcc dot gnu.org ---
For function sign_lt and uns_lt, the change causes worse code generation
unfortunately. Take uns_lt as example, the difference in optimized dump is as
like:
529,530c529,530
< vect_cst__32 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> So, is what gcc trunk generates less efficient than what it used to generate
> before, or is just different? If the latter, surely the test should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
