Re: Fwd: gcc internal failure during optimization delete_trivially_dead_insns

[ftwilliam <ftwilliam at gmail dot com>]

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@redhat.com> 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