https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Segher Boessenkool from comment #21) > (In reply to Hongtao.liu from comment #19) > > (In reply to H.J. Lu from comment #18) > > > (In reply to Segher Boessenkool from comment #16) > > > > Hi Roger, > > > > > > > > (In reply to Roger Sayle from comment #15) > > > > > Yes, a COMPARE rtx can be used to set various flags on x86, but many > > > > > other > > > > > operations also legitimately set and/or use MODE_CC, often in a > > > > > parallel > > > > > with the primary operation. > > > > > > > > *Any* MODE_CC setter sets the flags as-if from a compare. This is what > > > > MODE_CC *is*. > > > > > > > > Setting something as ne:CC and then using it as somethingelse:CC has no > > > > defined meaning. > > > > > > This > > > > > > (parallel [ > > > (set (reg:SI 97) > > > (neg:SI (ltu:SI (reg:CCC 17 flags) > > > (const_int 0 [0])))) > > > (clobber (reg:CC 17 flags)) > > > ]) > > > > > > still won't work correctly if reg:CCC 17 flags is set by a compare of > > > 2 known values. > > > > I guess Segher means it should be NE instead of LTU in the > > x86_mov<mode>cc_0_m1_neg, since the setters is NE to const 0. > > Yes. So the issue is with the consumer: (insn 50 49 51 2 (parallel [ (set (reg:SI 93) (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0])))) (clobber (reg:CC 17 flags)) ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg} (expr_list:REG_DEAD (reg:CCC 17 flags) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil)))) There are many similar patterns in different backends. They work as long as the flags register isn't a known constant since simplify-rtx.cc leaves them alone. They become a problem only when the flags register is a known constant.