On Sun, Dec 4, 2016 at 11:38 PM, Janne Blomqvist <blomqvist.ja...@gmail.com> wrote: > 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?
Dear all, I figured out that this problem wasn't per se caused by my patch, but it existed on trunk previously and was just triggered by my patch. I was able to reproduce it on a pristine trunk and filed it as PR 78757. Subsequently Martin Liška was able to point to r235817 (http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=235817 ) as the culprit. Thanks to Martin and all others who spent time on this so far! -- Janne Blomqvist
