Hi Jeff, I reran cc1 both under gdb and valgrind, and the result were the same; the backtrace is different after delete_trivially_dead_insns(); Would it help if I sent out a patch against gcc-4.9.2, and all you would need to reproduce the issue would be to run: ../gcc-4.9.2/configure --prefix=/opt/myarchtoolchain --target=myarch-elf --enable-language=c make I would also need to sent out a patch against binutils-2.25 to be built before gcc-4.9.2 using: ../binutils-2.25/configure --prefix=/opt/myarchtoolchain --target=myarch-elf Please, let me know if you can help. On Mon, Apr 6, 2015 at 11:06 PM, Jeff Law <law@xxxxxxxxxx> wrote: > On 04/06/2015 02:05 PM, ftwilliam wrote: >> >> Hi Jeff, >> >> Please see below correct valgrind output corresponding to the error in >> the original message. >> The previous valgrind output accidentally came from a parallel build >> that used an older GCC. > > Thanks. What's interesting here is I expected to see a valgrind error for > an out-of-bounds write of some sort, but the only complaints are for reads. > > But it does show a NULL pointer dereference here: > > >> ==29944== >> ==29944== Invalid read of size 4 >> ==29944== at 0x81E5B21: df_install_ref(df_ref_d*, df_reg_info*, >> df_ref_info*, bool) (df-scan.c:2575) >> ==29944== by 0x81E5C7C: df_install_refs(basic_block_def*, >> vec<df_ref_d*, va_heap, vl_ptr> const*, df_reg_info**, df_ref_info*, >> bool) [clone .isra.17] (df-scan.c:2656) >> ==29944== by 0x81E5DCA: df_refs_add_to_chains(df_collection_rec*, >> basic_block_def*, rtx_def*, unsigned int) (df-scan.c:2715) >> ==29944== by 0x81EAA4C: df_bb_refs_record(int, bool) (df-scan.c:3643) >> ==29944== by 0x81EAC62: df_scan_blocks() (df-scan.c:679) >> ==29944== by 0x81D9323: rest_of_handle_df_initialize() (df-core.c:737) >> ==29944== by 0x838F3E8: execute_one_pass(opt_pass*) (passes.c:2233) >> ==29944== by 0x838F665: execute_pass_list(opt_pass*) (passes.c:2286) >> ==29944== by 0x838F678: execute_pass_list(opt_pass*) (passes.c:2287) >> ==29944== by 0x81C20CE: expand_function(cgraph_node*) >> (cgraphunit.c:1774) >> ==29944== by 0x81C3E47: compile() (cgraphunit.c:2006) >> ==29944== by 0x81C40F9: finalize_compilation_unit() (cgraphunit.c:2329) >> ==29944== Address 0x4 is not stack'd, malloc'd or (recently) free'd >> ==29944== > > But while this is obviously bad, it's significantly different than what I'd > expect from the backtrace in your original message. > > In your original report the backtrace indicates a failure in the allocator > called from delete_trivially_dead_insns. More specifically it indicates > that something has likely written out of the bounds of the "counts" array. > But that's precisely what I would have expected valgrind to be able to > detect for us. > > So I'm at a loss for how best to proceed as these kinds of errors are > usually best analyzed under a debugger. > > jeff
