https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |ktkachov at gcc dot gnu.org,
| |rearnsha at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This happens during combine. If whether the comparison raises exception or not
is distinguished on aarch64 with CCFPEmode vs. CCFPmode, then guess the problem
is when that distinction gets ignored (unless in fast-math mode) or when it
goes away completely.
So, either the
Trying 11 -> 12:
11: r102:SI=cc:CCFP>0
REG_DEAD cc:CCFP
12: r98:SI=-r102:SI
REG_DEAD r102:SI
Successfully matched this instruction:
(set (reg:SI 98)
(neg:SI (gt:SI (reg:CCFP 66 cc)
(const_int 0 [0]))))
transformation is wrong (at least I don't see the new insn doing something
different for CCFP vs. CCFPE modes), or the further one:
Trying 7 -> 12:
7: cc:CCFP=cmp(r103:SF,r104:SF)
REG_DEAD r104:SF
REG_DEAD r103:SF
12: r98:SI=-cc:CCFP>0
REG_DEAD cc:CCFP
Successfully matched this instruction:
(set (reg:SI 98)
(neg:SI (gt:SI (reg:SF 103)
(reg:SF 104))))
where the CCFP vs. CCFPE mode goes away completely and is signalling always? in
that case.
