This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/12799] cmov is confused by a intervening inc that bashes flags.
- From: "pratap at vmware dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Oct 2003 17:42:51 -0000
- Subject: [Bug optimization/12799] cmov is confused by a intervening inc that bashes flags.
- References: <20031027231944.12799.pratap@vmware.com>
- Reply-to: 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.