https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> --- here is a reduced testcase: ``` [[gnu::noipa]] int f(int b) { int tt1 = ~b; int t = 1 & tt1; int e = -t; int tt = e >= -1; if (tt) return 0; __builtin_trap(); } int main() { for(int i = -1;i < 2; i++) f(i); } ``` Note ` -O1 -fno-tree-fre -fno-tree-forwprop -fno-tree-ccp -fno-tree-dominator-opts` is needed to reproduce it with this one. The generate gimple is the same between GCC 13 and 14 here. But the first difference is in combine: ``` Trying 7 -> 8: 7: {r106:SI=r105:SI&0x1;clobber flags:CC;} REG_DEAD r105:SI REG_UNUSED flags:CC 8: {r107:SI=-r106:SI;clobber flags:CC;} REG_DEAD r106:SI REG_UNUSED flags:CC Successfully matched this instruction: (parallel [ (set (reg:SI 107 [ e_5 ]) (sign_extract:SI (reg:SI 105 [ tt1_3 ]) (const_int 1 [0x1]) (const_int 0 [0]))) (clobber (reg:CC 17 flags)) ]) allowing combination of insns 7 and 8 original costs 4 + 4 = 8 replacement cost 4 deferring deletion of insn with uid = 7. modifying insn i3 8: {r107:SI=sign_extract(r105:SI,0x1,0);clobber flags:CC;} REG_DEAD r105:SI ``` This is correct but it goes down hill after like as I mentioned in comment #2. So it does look like a latent bug after all. If someone does a bisect of this testcase, I am 99% sure you find r14-4810-ge28869670c9879 is where the failure was introduced. For the original testcase and the one in comment #1 might find a different commit due to gimple level being different.