[Bug optimization/12799] cmov is confused by a intervening inc that bashes flags.

["pratap at vmware dot com" <gcc-bugzilla 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


pratap at vmware dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3


------- Additional Comments From pratap at vmware dot com  2003-10-29 17:42 -------
Eric: 

Thanks for validating that the assembly code produced by all these
versions: CC 3.1.1, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.3, 3.3.1, 3.3.2 and 3.3.3pre
are correct. I too had verified that 3.3. produces the correct code 
sequence. 

This problem warrants slightly deeper probing. Which phase of the compiler
had the problem in it? I can see the following possibilities:
    - a local peep hole optimizer that did not do proper local data 
      flow analysis
    - a phase that replaces large instructions with smaller ones may have
      decided that inc was a better deal than an add, w/o realising the 
      data flow implications
    - more scarily, this could be a bug in the local/global data flow 
      analysis module. 
    - others? 

Given this wide spectra of possible culprits, and the general attractiveness 
for folks to want to use cmov'es, I would prefer if GCC could give a more
assurance that the bug has infact been fixed either by pointing out a 
specific patch, or at least explaining by way of reasoning about the current
source base. 

The product that we at VMWare release compiled using GCC goes out to several
million users, so if there is a bug, it is likely to get exposed soon.