https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
--- Comment #7 from pipcet at gmail dot com --- (In reply to Eric Botcazou from comment #4) > > I'll try, but please consider investigating this without one. It happens > > after a very lengthy compilation process (compiling a buggy gcc with a buggy > > cross-compiler, then compiling JIT code with that, generating a buggy .so, > > then running _that_, to see incorrect behavior rather than a clear crash), > > in C++ code, with an out-of-tree backend. > > Impressive indeed, but not without a precedent. Can you upload the RTL dump > files of the pass preceding .combine and that of .combine itself? Sure. I've tried taking the .i and compiling it with other backends, but they never seem to optimize away the inner (and:HI ...). > > On the other hand, it's been investigated, and it's a clear bug with a > > one-line fix. > > This needs to be double checked though, this code has been there for ages. I agree, of course. While I still believe that the problem is as I described, it's not as severe a bug as I initially thought: it essentially requires the architecture to have WORD_REGISTER_OPERATIONS but also memory compares, a very unusual combination for real hardware. (In reply to Richard Biener from comment #3) > If > > (gtu (subreg:SI (reg:HI 593)) (const_int 1)) > > is incorrect, why is it then recognized? And why should (subreg:SI (and:HI > ..)) > be OK? My understanding is it's valid but essentially meaningless RTL, so it should be okay to recognize. > The way I read WORD_REGISTER_OPERATIONS it's a bad design to make the IL do > something that could have better been explicitely represented. (if it is > a SImode op then please make it an SImode op!) Maybe a first step would be to add a "when in doubt, don't define it" remark to the documentation for WORD_REGISTER_OPERATIONS?
