This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: post_inc mem in parallel rtx

On 11/22/13 09:43, BELBACHIR Selim wrote:

I encountered a bug in cselib.c:2360 using gnat7.1.2 (gcc4.7.3)

         /* The register should have been invalidated.  */
           gcc_assert (REG_VALUES (dreg)->elt == 0);                <<== assert(false)

I investigated the dump and found that the crash occurred during 207r.dse2 pass.

Here is what I saw in the previous dump (206r.pro_and_epilogue) :

(insn 104 47 105 7 (parallel [
             (set (reg:CC_NOOV 56 $CCI)
                 (compare:CC_NOOV (minus:SI (reg/f:SI 22 $R6 [orig:133 D.3274 ] [133])
                         (mem/f:SI (post_inc:SI (reg:SI 2 $R2 [orig:140 ivtmp.363 ] [140])) [0 MEM[base: D.4517_59, offset: 0B]+0 S4 A32]))
                     (const_int 0 [0])))
             (set (reg:SI 16 $R0 [153])
                 (minus:SI (reg/f:SI 22 $R6 [orig:133 D.3274 ] [133])
                     (mem/f:SI (post_inc:SI (reg:SI 2 $R2 [orig:140 ivtmp.363 ] [140])) [0 MEM[base: D.4517_59, offset: 0B]+0 S4 A32])))

Note the post_inc MEM on $R2 appearing twice

This rtl match my pattern (predicate and contraint ok) below :

(define_insn "subsi3_compare0"
   [(set (reg:CC_NOOV CCI_REG)
             (match_operand:SI 1 "general_operand" "g")
             (match_operand:SI 2 " general_operand " " g"))
           (const_int 0)))
    (set (match_operand:SI 0 "register_operand" "=r ")
           (match_dup 1)
           (match_dup 2)))]

But I think It may be an error to authorize post_inc MEM in this parallel rtx in operand 1 & 2.
When I put a more restrictive constraint which forbid the use of post_inc, the crash in cselib.c disappear.

Question : What does GCC understand when the md describes a pattern allowing the same post_inc MEM in 2 slot of a parallel rtx ?
Is it forbidden ? the MEM address is supposed to be incremented twice ?
I think the semantics are defined by the PARALLEL. Namely that the uses are evaluated, then side effects are performed. So both sets use the value before incrementing.

The only question is what is the resulting value, and given the fundamental nature of PARALLEL, I think a single visible side effect is the most obvious answer.

Now having said that, there's a distinct possibility various passes don't handle this properly.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]