https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122536
--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Not triggering for me. But it seems to me like if the bit position were
variable we could trigger an issue. I *think* the last to CONST_INT_P are
supposed to protect against this, but they're checking the wrong argument.
I'll have to review the internal discussion between Shreya and myself to see if
that provides a clue.
And yes, I do see evidence that we could have a variable bit position:
(insn 13 12 14 3 (parallel [
(set (reg:DI 114 [ _4 ])
(lshiftrt:DI (reg:DI 99 [ _2 ])
(subreg:QI (reg:SI 100 [
intel_uncore_prune_engine_fw_domains_i.1_3 ]) 0)))
(clobber (reg:CC 17 flags))
]) "j.c":5:9 1187 {*lshrdi3_1}
(expr_list:REG_DEAD (reg:SI 100 [
intel_uncore_prune_engine_fw_domains_i.1_3 ])
(expr_list:REG_DEAD (reg:DI 99 [ _2 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))))
That ultimately feeds into the IOR and they we extract the low bit from the
IOR's result. So, yea, in the full context it's a bit extract from a variable
position.
