[forwarded from https://bugs.debian.org/975219] seen building elkcode-6.3.2 on x86_74-linux-gnu gcc-10 branch, compiler configured with -enable-checking=yes,extra,rtl, didn't check the trunk yet. I can reproduce this locally, replacing mpif90 with gfortran. I'm failing to construct a test case outside the build directory. $ cd src; gfortran -c -fopenmp exxengy.f90 exxengy.f90:6:18: 6 | subroutine exxengy | ^ internal compiler error: in lookup_field_for_decl, at tree-nested.c:288 0x71106d lookup_field_for_decl ../../src/gcc/tree-nested.c:288 0x111523e convert_local_reference_stmt ../../src/gcc/tree-nested.c:2408 0xd82a5a walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:578 0xd82c20 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:51 0xd82b11 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:686 0xd82c20 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:51 0xd82b11 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:686 0xd82c20 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:51 0xd82b51 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:641 0xd82c20 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:51 0xd82b51 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:641 0xd82c20 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:51 0xd82b11 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:686 0xd82c20 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../src/gcc/gimple-walk.c:51 0x110d154 walk_body ../../src/gcc/tree-nested.c:713 0x110d154 walk_function ../../src/gcc/tree-nested.c:724 0x110d154 walk_all_functions ../../src/gcc/tree-nested.c:789 0x111360a lower_nested_functions(tree_node*) ../../src/gcc/tree-nested.c:3580 0xbe8e4c cgraph_node::analyze() ../../src/gcc/cgraphunit.c:676 0xbec017 analyze_functions ../../src/gcc/cgraphunit.c:1227 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
Can you attach the source (or, if it uses modules also sources of the modules it uses)?
Created attachment 49605 [details] test case that's my unsuccessful extraction attempt
Works for me with 10.2.0 and trunk r11-5181.
Dominique, are your compilers configured with --enable-checking=yes,extra,rtl ?
> Dominique, are your compilers configured with --enable-checking=yes,extra,rtl ? Only --enable-checking=yes (the default for experimental). My instrumented compiler r11-5060 also works.
just checked with today's trunk and --enable-checking=yes,extra,rtl working there.
>just checked with today's trunk and --enable-checking=yes,extra,rtl > working there. What was the failing version?
Can't reproduce with 20201005 10 branch or current trunk. The 10 branch changed tree-nested.c e.g. in r10-8663, but I don't really see any linear, lastprivate or reduction clauses in this.
(In reply to Jakub Jelinek from comment #8) > Can't reproduce with 20201005 10 branch or current trunk. Neither I with yesterday's trunk and today's GCC 10 (8c8c5aae6b462d2df38f21f76c01d89d2f79f099) It also does not crash on GCC 10 with ede01bd9adf55f43598036d21d5db3d95dfd24a3 (= Wed Aug 26) nor with c0746a1beb1ba073c7981eb09f55b3d993b32e5c (= Aug 25).
seen again with 20210227
20210227 trunk
(In reply to Matthias Klose from comment #10) > seen again with 20210227 I tried it with the attached file and the build.sh but calling gfortran directly w/o mpif90 wrapper. That's with --enable-checking=yes,extra,rtl and: mainline: 4d66685e49d20e0c7a87c5fa0757c7eb63ffcdaa (Fri Mar 5 05:25:54 2021 -0800) GCC 10: c85c24099b28f7af907466af2c1b73da9455368c (Fri Mar 5 12:45:41 2021 +0100) That's on x86_64-gnu-linux (Ubuntu 14.04.4 LTS). It did compile without any problems; I also tried running it with valgrind and did not spot anything there, either. Looking at the Elk webpage, also no gfortran-related issues are reported threre.
Created attachment 50313 [details] Reduced testcase - run with 'gfortran file.f90' (seems to require --enable-checking=yes) The generated code has: __attribute__((fn spec (". "))) void zrho2 () // <<--- nested in exxengy { return; } __attribute__((fn spec (". "))) void exxengy () { static void zrho2 (void); ierror = {CLOBBER}; mpi_allreduce (&ierror); } ICE: In tree-nested.c's convert_local_reference_stmt, there is: 2524 case GIMPLE_ASSIGN: 2525 if (gimple_clobber_p (stmt)) 2526 { 2527 tree lhs = gimple_assign_lhs (stmt); 2528 if (DECL_P (lhs) 2529 && !use_pointer_in_frame (lhs) 2530 && lookup_field_for_decl (info, lhs, NO_INSERT)) with: (gdb) p debug_gimple_seq(*gsi->seq) ierror = {CLOBBER}; mpi_allreduce (&ierror); and lhs == decl in the following: #0 lookup_field_for_decl (info=0x2f28150, decl=0x7ffff7ffbab0, insert=NO_INSERT) at ../../repos/gcc/gcc/tree-nested.c:385 385 gcc_checking_assert (decl_function_context (decl) == info->context); with (gdb) p debug_tree(info->context) <function_decl 0x7ffff7668200 exxengy and (gdb) p decl_function_context (decl) $3 = (tree_node *) 0x0 (gdb) p debug_tree(decl) <var_decl 0x7ffff7ffbab0 ierror type <integer_type 0x7ffff74a95e8 integer(kind=4) public SI size <integer_cst 0x7ffff7494df8 constant 32> unit-size <integer_cst 0x7ffff7494e10 constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff74a95e8 precision:32 min <integer_cst 0x7ffff7494db0 -2147483648> max <integer_cst 0x7ffff7494dc8 2147483647> pointer_to_this <pointer_type 0x7ffff74b09d8>> addressable used public static SI exxengy4.f90:12:16 size <integer_cst 0x7ffff7494df8 32> unit-size <integer_cst 0x7ffff7494e10 4> align:32 warn_if_not_align:0 context <namespace_decl 0x7ffff7667260 modmpi> chain <function_decl 0x7ffff7668200 exxengy>> I am not quite sure whether the context is right or not: context <namespace_decl 0x7ffff7667260 modmpi> but it does not really look wrong, does it?
(In reply to Tobias Burnus from comment #13) > <var_decl 0x7ffff7ffbab0 ierror ... > align:32 warn_if_not_align:0 context <namespace_decl 0x7ffff7667260 > modmpi> chain <function_decl 0x7ffff7668200 exxengy>> > > > I am not quite sure whether the context is right or not: > context <namespace_decl 0x7ffff7667260 modmpi> > but it does not really look wrong, does it? The following compiles – but I don't know whether it makes sense: --- a/gcc/tree-nested.c +++ b/gcc/tree-nested.c @@ -382,7 +382,8 @@ static tree lookup_field_for_decl (struct nesting_info *info, tree decl, enum insert_option insert) { - gcc_checking_assert (decl_function_context (decl) == info->context); + gcc_checking_assert (TREE_CODE (DECL_CONTEXT (decl)) == NAMESPACE_DECL + || decl_function_context (decl) == info->context); if (insert == NO_INSERT) {
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566366.html
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>: https://gcc.gnu.org/g:8a6a62614a8ae4544770420416d1632d6c3d3f6e commit r11-7551-g8a6a62614a8ae4544770420416d1632d6c3d3f6e Author: Tobias Burnus <tobias@codesourcery.com> Date: Mon Mar 8 13:05:48 2021 +0100 tree-nested: Update assert for Fortran module vars [PR97927] gcc/ChangeLog: PR fortran/97927 * tree-nested.c (convert_local_reference_stmt): Avoid calling lookup_field_for_decl for Fortran module (= namespace context). gcc/testsuite/ChangeLog: PR fortran/97927 * gfortran.dg/module_variable_3.f90: New test.
The releases/gcc-10 branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>: https://gcc.gnu.org/g:a14691e924ea4a8277ea36df08b2f5359082bf62 commit r10-9444-ga14691e924ea4a8277ea36df08b2f5359082bf62 Author: Tobias Burnus <tobias@codesourcery.com> Date: Mon Mar 8 13:05:48 2021 +0100 tree-nested: Update assert for Fortran module vars [PR97927] gcc/ChangeLog: PR fortran/97927 * tree-nested.c (convert_local_reference_stmt): Avoid calling lookup_field_for_decl for Fortran module (= namespace context). gcc/testsuite/ChangeLog: PR fortran/97927 * gfortran.dg/module_variable_3.f90: New test. (cherry picked from commit 8a6a62614a8ae4544770420416d1632d6c3d3f6e)
Finally reduced and, hence, finally FIXED – on mainline (GCC 11) and GCC 10.