[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-09-08
         Depends on|                            |106811

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  r13-131-gc2a0d2e6f636c6 addressed some issues, but leaves others
such as shifts seen here.  It's not clear if (int)1 << 33 is undefined behavior
in
GIMPLE, see PR106811.  Note that ifcombine doesn't simply transform this to
(x & c) & (x & (1 << b)), thus removing the short-circuiting, instead it
computes tem = c | (1<<b) and checks (x & tem) == tem.  That's probably safe
for arbitrary results of the undefined operation though.

One possibility might be to rewrite 1 << b to (1 << (b&31)) to make it always
defined, but that comes at an extra cost compared to how we treat signed
overflow.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106811
[Bug 106811] GENERIC and GIMPLE IL undefined behavior needs documenting