https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116715
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
This pattern just looks plain wrong:
;; As long as the SImode operand is not a partial subreg, we can use a
;; bseti without postprocessing, as the middle end is smart enough to
;; stay away from the signbit.
(define_insn "*<bit_optab>idisi"
[(set (match_operand:DI 0 "register_operand" "=r")
(any_or:DI (sign_extend:DI (match_operand:SI 1 "register_operand" "r"))
(match_operand 2 "single_bit_mask_operand" "i")))]
"TARGET_ZBS && TARGET_64BIT
&& !partial_subreg_p (operands[1])"
"<bit_optab>i\t%0,%1,%S2"
[(set_attr "type" "bitmanip")])
Let's assume that op1 has the value 0x80000000 and op1 is 0x1. The result
should be 0xffffffff80000001. But we can get 0x0000000080000001 as we lose the
sign extension.
We could probably get away with this prior to the introduction of post-reload
combining since it really wouldn't have had a chance to match anything new
after reload. But even then it's incorrect if we have an SI operand that's not
kept in sign extended form (which is much more likely these days after the
introduction of ext-dce).
I'll need to think about this a bit.
