--- Comment #7 from thomas at coware dot com 2009-08-07 07:37 ---
This is how function func looks after the if conversion (test.c.144r.ce1):
(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 test.c:3 (set (reg/v:SI 63 [ arg ])
(mem/c/i:SI (reg/f:SI 16 argp) [0 arg+0 S4
--- Comment #6 from steven at gcc dot gnu dot org 2009-08-06 22:13 ---
If it turns out to be the RTL if-conversion pass, assign this bug to me please.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from steven at gcc dot gnu dot org 2009-08-06 22:12 ---
Instead of guessing -- why not inspect the dumps you get with -fdump-tree-all
-fdump-rtl-all and see if someone can figure out which pass is the first to
screw up the test case?
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #4 from thomas at coware dot com 2009-08-06 19:25 ---
By the way, I see the same failure also with gcc 4.1.2 and 4.2 without any fno-
options.
I thought it would be a good idea to hunt the problem down to a single
optimization mechanism, which seems to be if-conversion. I gu
--- Comment #3 from mikpe at it dot uu dot se 2009-08-06 15:58 ---
Reproduced on i686-linux with the following compiler versions and minimal sets
of options:
gcc-4.3-20090802: -O1 -fno-tree-dce
gcc-4.4-20090804: -O1 -fno-tree-ccp -fno-tree-dominator-opts
gcc-4.5-20090730: -O1
Note that
--- Comment #2 from thomas at coware dot com 2009-08-06 15:26 ---
I can also build it like this and it fails:
gcc test.c -O1 -fno-tree-dce -o test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40987
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-06 14:57 ---
"Doctor it hurts when I do this!" ...
well, I suggest you don't use this strange combination of options. In
particular
disabling ccp is known to cause interesting side-effects sometimes.
Keeping open in case someo
