[Bug optimization/12799] cmov is confused by a intervening inc that bashes flags.
pratap at vmware dot com
gcc-bugzilla@gcc.gnu.org
Wed Oct 29 18:01:00 GMT 2003
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.
More information about the Gcc-bugs
mailing list