On Thu, Feb 24, 2022 at 08:07:28AM +0100, Robin Dapp wrote:
> Hi,
>
> > Robin's patch has the effct making rs6000_emit_int_cmove return false for
> > floating point comparisons, so I marked the bug as being a duplicate of PR
> > target/104335.
>
> Didn't I just return false for MODE_CC? This
Hi,
> Robin's patch has the effct making rs6000_emit_int_cmove return false for
> floating point comparisons, so I marked the bug as being a duplicate of PR
> target/104335.
Didn't I just return false for MODE_CC? This should not affect proper
floating-point comparisons. It looks like the
On Thu, Feb 17, 2022 at 05:38:07PM -0600, Segher Boessenkool wrote:
> Hi!
>
> First, you need to adjust after Robin's patch, and retest.
Robin's patch has the effct making rs6000_emit_int_cmove return false for
floating point comparisons, so I marked the bug as being a duplicate of PR
Hi!
First, you need to adjust after Robin's patch, and retest.
On Thu, Feb 17, 2022 at 01:56:04PM -0500, Michael Meissner wrote:
> Don't do int cmoves for IEEE comparisons, PR target/104256.
> Unfortunately there are some conditions like UNLE that can't easily be
> reversed
> due to NaNs.
Don't do int cmoves for IEEE comparisons, PR target/104256.
Protect int cmove from raising an assertion if it is trying to do an int
conditional move where the test involves floating point comparisons that
can't easily be reversed due to NaNs.
The code used to generate the condition, and
