This is the mail archive of the gcc-bugs@gcc.gnu.org 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]

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md


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

--- Comment #11 from dmalcolm at gcc dot gnu.org ---
Investigating the backtrace at the point of the uninit read shows that
the issue occurs in shorten_branches here:

#5  0x00000000006f3263 in shorten_branches (first=0x7ffff1687700) at
../../src/gcc/final.c:1286
1284          else if (GET_CODE (body) != USE && GET_CODE (body) != CLOBBER)
1285        {
1286          insn_lengths[uid] = length_fun (insn);
1287          varying_length[uid] = insn_variable_length_p (insn);
1288        }

(gdb) p uid
$7 = 10
(gdb) p length_fun
$8 = (int (*)(rtx_insn *)) 0xbeb5d1 <insn_min_length(rtx_insn*)>
(gdb) call debug(insn)
(jump_insn:TI 10 4 16 2 (set (pc)
        (if_then_else (ne (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref:DI 52)
            (pc)))
/home/david/coding-3/gcc-git-jit-valgrind/get-attr-length-i386.c:3 610 {*jcc_1}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (int_list:REG_BR_PROB 3300 (nil)))
 -> 52)

I put insn-attrtab.c through GNU indent to make the conditional easier to read:

(gdb) down
#4  0x0000000000beb7b7 in insn_min_length (insn=0x7ffff1685b40) at
insn-attrtab.c:276
276        (ix86_bnd_prefixed_insn_p (insn)) + get_attr_length_nobnd (insn);
(gdb) list
271        case 611:            /* *jcc_2 */
272        case 610:            /* *jcc_1 */
273          extract_constrain_insn_cached (insn);
274          return
275    /*line 516 "../../src/gcc/config/i386/i386.md"*/
276        (ix86_bnd_prefixed_insn_p (insn)) + get_attr_length_nobnd (insn);
277    
278        case 163:            /* *truncxfdf2_mixed */
279        case 162:            /* *truncxfsf2_mixed */
280        case 160:            /* *truncdfsf_i387 */

(gdb) down
#3  0x0000000000bf73b4 in get_attr_length_nobnd (insn=0x7ffff1685b40) at
insn-attrtab.c:19152
19152            (insn_current_reference_address (insn))) >= (-126))
(gdb) list
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]) ==

(gdb) down
#2  0x00000000006f1e23 in insn_current_reference_address
(branch=0x7ffff1685b40) at ../../src/gcc/final.c:754
754              - align_fuzz (seq, dest, length_unit_log, ~0));
(gdb) list
749         BRANCH also has no INSN_SHUID.  */
750      if (INSN_SHUID (seq) < INSN_SHUID (dest))
751        {
752          /* Forward branch.  */
753          return (insn_last_address + insn_lengths[seq_uid]
754              - align_fuzz (seq, dest, length_unit_log, ~0));
755        }
756      else
757        {
758          /* Backward branch.  */

(gdb) down
#1  0x00000000006f1c4e in align_fuzz (start=0x7ffff1685b40, end=0x7ffff17b8900,
known_align_log=0, growth=4294967295)
    at ../../src/gcc/final.c:703
703          align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];
(gdb) list
698      for (align_label = uid_align[uid]; align_label; align_label =
uid_align[uid])
699        {
700          int align_addr, new_align;
701    
702          uid = INSN_UID (align_label);
703          align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];
704          if (uid_shuid[uid] > end_shuid)
705        break;
706          known_align_log = LABEL_TO_ALIGNMENT (align_label);
707          new_align = 1 << known_align_log;

i.e. the uninitialized read occurs within align_fuzz in "insn_lengths[uid]" in
this expressions:

703          align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];

(gdb) p uid
$10 = 52

handling a forward branch within a "*jcc_2" insn.

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.


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