This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Help debugging middle-end crash (SSA inlining)
- From: Andre Vehreschild <vehre at gmx dot de>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>,Fortran List <fortran at gcc dot gnu dot org>,GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 04 Dec 2016 22:46:21 +0100
- Subject: Re: Help debugging middle-end crash (SSA inlining)
- Authentication-results: sourceware.org; auth=none
- References: <CAO9iq9GDhr8KD93sPeDWOx-X5hvjaeKUJ7kMvOoxYOV6O00RwQ@mail.gmail.com>
Hi Janne,
Don't know whether that helps, but I had a similar crash in make_ssa_name but with every level of optimization. In my case I had to typedef the type once and all went well from then on. Grep for TYPE_DECL in trans_type.c so see how that was done. May this hint gives you a clue.
Humbly,
Andre
Am 4. Dezember 2016 22:38:24 MEZ, schrieb Janne Blomqvist <blomqvist.janne@gmail.com>:
>Hi,
>
>I'm working on a patch to change the type that GFortran uses for
>string lengths from a C int to a C size_t. I'm at a point where it
>does regtest successfully, with the exception of
>gfortran.dg/char_result_8.f90 with -O1 where it ICE's. Unfortunately
>I'm a bit stuck here, and haven't been able to figure out what causes
>the error.
>
>The latest version of the patch is attached to PR 78534.
>
>It does work with -O0, -O2, -O3, -Og, -Ofast as well as "-O1
>-fno-inline-functions-called-once". Which suggests that the problem is
>in the inliner (why it doesn't trigger with higher optimization level,
>I don't know).
>
>The backtrace of the crash is
>
>char_result_8.f90:14:0:
>
> call indirect (100)
>
>internal compiler error: Segmentation fault
>0xcda61e crash_signal
> ../../trunk-git/gcc/toplev.c:333
>0xfa99e4 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
> ../../trunk-git/gcc/tree-ssanames.c:265
>0xd7e26a make_ssa_name
> ../../trunk-git/gcc/tree-ssanames.h:113
>0xd7e26a remap_ssa_name
> ../../trunk-git/gcc/tree-inline.c:238
>0xd84ee2 copy_tree_body_r(tree_node**, int*, void*)
> ../../trunk-git/gcc/tree-inline.c:1082
>0x108c7a4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
>void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*>
>>*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**,
>int*, void*), void*, hash_set<tree_node*,
>default_hash_traits<tree_node*> >*))
> ../../trunk-git/gcc/tree.c:11795
>0x108da12 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
>void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*>
>>*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**,
>int*, void*), void*, hash_set<tree_node*,
>default_hash_traits<tree_node*> >*))
> ../../trunk-git/gcc/tree.c:12112
>0xd7c41a remap_type_1
> ../../trunk-git/gcc/tree-inline.c:493
>0xd7d2cc remap_type(tree_node*, copy_body_data*)
> ../../trunk-git/gcc/tree-inline.c:593
>0xd7cbc5 remap_type_1
> ../../trunk-git/gcc/tree-inline.c:523
>0xd7d2cc remap_type(tree_node*, copy_body_data*)
> ../../trunk-git/gcc/tree-inline.c:593
>0xd7b721 remap_type_1
> ../../trunk-git/gcc/tree-inline.c:418
>0xd7d2cc remap_type(tree_node*, copy_body_data*)
> ../../trunk-git/gcc/tree-inline.c:593
>0xd7b1c9 remap_decl(tree_node*, copy_body_data*)
> ../../trunk-git/gcc/tree-inline.c:370
>0xd7d849 add_local_variables
> ../../trunk-git/gcc/tree-inline.c:4321
>0xd8973a expand_call_inline
> ../../trunk-git/gcc/tree-inline.c:4733
>0xd8a4b8 gimple_expand_calls_inline
> ../../trunk-git/gcc/tree-inline.c:4896
>0xd8a6cf optimize_inline_calls(tree_node*)
> ../../trunk-git/gcc/tree-inline.c:5036
>0x164c339 inline_transform(cgraph_node*)
> ../../trunk-git/gcc/ipa-inline-transform.c:655
>0xbe121c execute_one_ipa_transform_pass
> ../../trunk-git/gcc/passes.c:2206
>
>
>Where it crashes is the assertion "VAR_P (var)", because var is a null
>pointer. Running this via gdb I have found that in this case "var" is
>the type node for one of the variables that it apparently is copying
>from the callee into the caller during the inlining.
>
>So I guess I'm asking how can it happen that the type node of a
>variable disappears?
>
>I have compared the -fdump-tree original dumps of trunk and
>trunk+patch, and they look perfectly Ok; except for character length
>types being different and a few typecasts in some appropriate places,
>they are identical.
>
>Can anybody offer some clues?
>
>TIA,
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 929 10 18 * vehre@gmx.de