This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
- From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 02 Dec 2014 16:08:15 +0000
- Subject: [Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
- Auto-submitted: auto-generated
- References: <bug-64003-4 at http dot gcc dot gnu dot org/bugzilla/>
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.