Re: Fwd: gcc internal failure during optimization delete_trivially_dead_insns

[Jeff Law <law at redhat dot com>]

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