This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help debugging middle-end crash (SSA inlining)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]