[Bug optimization/12799] [3.4 regression] faulty mov->add change clobbers the CC register

[ebotcazou at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12799


ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
           Priority|P3                          |P2
            Summary|incl does not mark it self  |[3.4 regression] faulty mov-
                   |as clobbers flags           |>add change clobbers the CC
                   |                            |register
   Target Milestone|---                         |3.4


------- Additional Comments From ebotcazou at gcc dot gnu dot org  2003-10-30 12:47 -------
Well, it turns out that we should probably buy you some beers for your perseverance!

The culprit is the "post-reload" pass which is run right after (global) register
allocation, more precisely its "reload CSE" sub-pass and, even more precisely,
the reload_cse_move2add pass (see reload1.c:9050 and below in the 3.3.x tree).
What it does matches exactly your item #2 ("a phase that replaces large
instructions with...") except that it's a "mov $1024, %eax" -> "incl %eax"
replacement.

Now a good news and a bad news. The good news: the bug can't occur in the 3.3.x
series because reload_cse_move2add is effectively disabled. It was not updated
when a far-reaching change was made; as a consequence, the transformation that
triggered the bug in the 3.0.x series is always rejected (the calls to
validate_change() line 9173 and 9225 always fail).

The bad news: reload_cse_move2add was updated on mainline (which will become GCC
3.4) by

   http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00595.html

so I think the latent bug is now exposed again there.

I'll submit a patch for mainline.