------- Comment #1 from mkuvyrkov at gcc dot gnu dot org  2007-05-30 14:30 
-------
This is an aliasing issue.

true_dependence () returns '0' on mems from insns 15 and 58.  This is due to
MEM_READONLY_P () flag set on them.

(insn:HI 15 13 16 3 (set (mem/u/f/c/i:DI (symbol_ref:DI ("_ZZ10testMethodvE1s")
[flags 0x2] <var_decl 0x2aaaae171c60 s>) [5 s+0 S8 A64])
        (reg:DI 0 ax [62])) 81 {*movdi_1_rex64} (insn_list:REG_DEP_TRUE 14
(nil))
    (nil))

(insn 58 16 59 3 (set (reg/f:DI 3 bx [orig:59 s.1 ] [59])
        (mem/u/f/c/i:DI (symbol_ref:DI ("_ZZ10testMethodvE1s") [flags 0x2]
<var_decl 0x2aaaae171c60 s>) [5 s+0 S8 A64])) 81 {*movdi_1_rex64} (nil)
    (expr_list:REG_EQUIV (mem/u/f/c/i:DI (symbol_ref:DI ("_ZZ10testMethodvE1s")
[flags 0x2] <var_decl 0x2aaaae171c60 s>) [5 s+0 S8 A64])
        (nil)))

I believe that comment in true_dependence ():
  /* Read-only memory is by definition never modified, and therefore can't
     conflict with anything.  We don't expect to find read-only set on MEM,
     but stupid user tricks can produce them, so don't die.  */
conflicts with comment describing MEM_READONLY_P flag in rtl.h:
  /* 1 in a REG, MEM, or CONCAT if the value is set at most once, anywhere.  */

In mainline this bug is latent because code that initialize static variable and
code that use it are in the separate basic blocks.  As long as scheduling works
on individual basic blocks the bug is hidden.

Confirm with fedora 6 system compiler.


-- 

mkuvyrkov at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkuvyrkov at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-05-30 14:30:30
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806

Reply via email to