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.

Reply via email to