https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #12 from dmalcolm at gcc dot gnu.org ---
(In reply to dmalcolm from comment #11)
> Running valgrind with vgdb to get the precise location of its
> warnings indicates they are here within get_attr_length_nobnd in
> insn-attrtab.c:19152:
> 
> 19147       if ((((INSN_ADDRESSES_SET_P ()?
> 19148              INSN_ADDRESSES (INSN_UID
> 19149                              (GET_CODE (operands[0]) ==
> 19150                               LABEL_REF ? XEXP (operands[0],
> 19151                                                 0) : operands[0])) : 0) 
> -
> 19152             (insn_current_reference_address (insn))) >= (-126))
> 19153           &&
> 19154           (((INSN_ADDRESSES_SET_P ()?
> 19155              INSN_ADDRESSES (INSN_UID
> 19156                              (GET_CODE (operands[0]) ==
> 
> i.e. at the logical-AND at line 19153.
> 
> Valgrind presumably is noticing the "uninitialized" trait of this
> read, then propagating it through to the result of align_fuzz,
> and thence to insn_current_reference_address, and hence to the whole
> of the first argument of the logical-AND.
> 
> Hence the decision about whether to process the second argument of
> the logical-AND is a jump that relies on an uninitialized value, and
> hence valgrind complains.

i.e. the issue is that evaluating both sides of the (and) expression at line
10931 in:

 10920  (define_insn "*jcc_1"
 10921    [(set (pc)
 10922          (if_then_else (match_operator 1 "ix86_comparison_operator"
 10923                                        [(reg FLAGS_REG) (const_int 0)])
 10924                        (label_ref (match_operand 0))
 10925                        (pc)))]
 10926    ""
 10927    "%!%+j%C1\t%l0"
 10928    [(set_attr "type" "ibr")
 10929     (set_attr "modrm" "0")
 10930     (set (attr "length_nobnd")
>10931             (if_then_else (and (ge (minus (match_dup 0) (pc))
 10932                                    (const_int -126))
 10933                                (lt (minus (match_dup 0) (pc))
 10934                                    (const_int 128)))
 10935               (const_int 2)
 10936               (const_int 6)))])
 10937

for a forward jump, leads to reads of uninitialized items from insn_lengths in
align_fuzz for the uid for the jump target.

Hence we have an (and (UNINITIALIZED_1) (WILL_BE_UNINITIALIZED_2)) and hence
the decision about whether to short-circuit the read of WILL_BE_UNINITIALIZED_2
is a conditional jump that depends on UNINITIALIZED_1.

Reply via email to