------- Comment #6 from hp at gcc dot gnu dot org 2010-09-08 02:13 -------
Created an attachment (id=21731)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21731&action=view)
Somewhat simplified test-case
I'm having a look at this.
I simplified the test-case somewhat, eliminating some loops and a print-call.
First appearing in the .ce2 dump of r150588 at -O3 -funroll-loops, we see:
...
IF-THEN-ELSE-JOIN block found, pass 1, test 15, then 37, else 36, join 38
scanning new insn with uid = 1223.
scanning new insn with uid = 1224.
scanning new insn with uid = 1225.
deleting insn with uid = 344.
deleting insn with uid = 332.
deleting insn with uid = 331.
deleting block 36
Removing jump 328.
deleting insn with uid = 328.
deleting insn with uid = 335.
deleting insn with uid = 334.
deleting block 37
merging block 38 into block 15
verify found no changes in insn with uid = 337.
verify found no changes in insn with uid = 338.
verify found no changes in insn with uid = 339.
verify found no changes in insn with uid = 340.
deleting insn with uid = 341.
Merged blocks 15 and 38.
Conversion succeeded on pass 1.
...
with a part of the simplified blocks having the somewhat suspicious instruction
sequence:
...
(note 324 1220 327 15 NOTE_INSN_DELETED)
(insn 327 324 1223 15 /n/slask/hp_tmp/zs3a.f90:14 (set (cc0)
(compare (mem/s:SI (post_inc:SI (reg:SI 241 [ ivtmp.23 ])) [3 S4 A8])
(const_int 0 [0x0]))) 0 {*tstsi} (expr_list:REG_INC (reg:SI 241 [
ivtmp.23 ])
(nil)))
(insn 1223 327 1224 15 /n/slask/hp_tmp/zs3a.f90:14 (set (cc0)
(compare (mem/s:SI (post_inc:SI (reg:SI 241 [ ivtmp.23 ])) [3 S4 A8])
(const_int 0 [0x0]))) 0 {*tstsi} (nil))
(insn 1224 1223 1225 15 /n/slask/hp_tmp/zs3a.f90:14 (set (reg:SI 324)
(ne:SI (cc0)
(const_int 0 [0x0]))) 210 {sne} (nil))
(insn 1225 1224 337 15 /n/slask/hp_tmp/zs3a.f90:14 (set (reg:SI 252 [ j ])
(reg:SI 324)) 36 {*movsi_internal} (nil))
...
In the .combine dump, it's not apparent why this should be correct; note the
first cc0 setter not having a user; with the only effect of the insn being the
memory access (not volatile, so it doesn't count) and the post-increment.
This smells like a bug.
Whether in the post-combine ifcvt pass or in the input is unknown at this time.
--
hp at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41087
