A recent regression: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/altreturn_1.f90 ../../gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist' #0 0xeb78e3 in get_formal_from_actual_arglist ../../gcc/fortran/trans-types.c:3015 #1 0xeb82d5 in gfc_get_function_type(gfc_symbol*, gfc_actual_arglist*) ../../gcc/fortran/trans-types.c:3081 #2 0xd0d1de in gfc_get_extern_function_decl(gfc_symbol*, gfc_actual_arglist*) ../../gcc/fortran/trans-decl.c:2152 #3 0xd6e804 in conv_function_val ../../gcc/fortran/trans-expr.c:3920 #4 0xd8fa14 in gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec<tree_node*, va_gc, vl_embed>*) ../../gcc/fortran/trans-expr.c:6626 #5 0xe65236 in gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:406 #6 0xc7680b in trans_code ../../gcc/fortran/trans.c:1890 #7 0xc76efa in gfc_trans_code(gfc_code*) ../../gcc/fortran/trans.c:2149 #8 0xd3dfce in gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6568 #9 0xc76f85 in gfc_generate_code(gfc_namespace*) ../../gcc/fortran/trans.c:2166 #10 0xad0181 in translate_all_program_units ../../gcc/fortran/parse.c:6134 #11 0xad0d8e in gfc_parse_file() ../../gcc/fortran/parse.c:6337 #12 0xc379c6 in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 #13 0x2307a40 in compile_file ../../gcc/toplev.c:456 #14 0x230f68d in do_compile ../../gcc/toplev.c:2204 #15 0x230fcbb in toplev::main(int, char**) ../../gcc/toplev.c:2339 #16 0x469a7c8 in main ../../gcc/main.c:39 #17 0x7ffff6e7bb7a in __libc_start_main ../csu/libc-start.c:308 #18 0x86dbe9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/f951+0x86dbe9)
Likely due to r268992 (the ICE occurs in the added block). The PR requires an instrumented compiler.
This looks pretty obvious to me, at least looking at the -fdump-fortran-original dump. I will try to come up with a test case. Would it be possible to check that this also fixes the nullpointer offset access? Index: trans-types.c =================================================================== --- trans-types.c (Revision 269161) +++ trans-types.c (Arbeitskopie) @@ -2988,9 +2988,9 @@ f = &sym->formal; for (a = actual_args; a != NULL; a = a->next) { + (*f) = gfc_get_formal_arglist (); if (a->expr) { - (*f) = gfc_get_formal_arglist (); snprintf (name, GFC_MAX_SYMBOL_LEN, "_formal_%d", var_num ++); gfc_get_symbol (name, NULL, &s); if (a->expr->ts.type == BT_PROCEDURE) @@ -3012,6 +3012,9 @@ s->attr.intent = INTENT_UNKNOWN; (*f)->sym = s; } + else + (*f)->sym = NULL; + f = &((*f)->next); } }
This test case also segfaults with a non-instrumeted compiler: program main call sub(10, *10, 20) stop 1 10 continue end program main
(In reply to Thomas Koenig from comment #2) > This looks pretty obvious to me, at least looking at the > -fdump-fortran-original dump. I will try to come up with > a test case. > > Would it be possible to check that this also fixes the > nullpointer offset access? > > Index: trans-types.c > =================================================================== > --- trans-types.c (Revision 269161) > +++ trans-types.c (Arbeitskopie) > @@ -2988,9 +2988,9 @@ > f = &sym->formal; > for (a = actual_args; a != NULL; a = a->next) > { > + (*f) = gfc_get_formal_arglist (); > if (a->expr) > { > - (*f) = gfc_get_formal_arglist (); > snprintf (name, GFC_MAX_SYMBOL_LEN, "_formal_%d", var_num ++); > gfc_get_symbol (name, NULL, &s); > if (a->expr->ts.type == BT_PROCEDURE) > @@ -3012,6 +3012,9 @@ > s->attr.intent = INTENT_UNKNOWN; > (*f)->sym = s; > } > + else > + (*f)->sym = NULL; > + > f = &((*f)->next); > } > } I can confirm this works fine for the test-case as well as for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496#c3 Thanks for the fix.
Author: tkoenig Date: Tue Feb 26 19:10:00 2019 New Revision: 269226 URL: https://gcc.gnu.org/viewcvs?rev=269226&root=gcc&view=rev Log: 2019-02-26 Thomas Koenig <tkoenig@gcc.gnu.org> PR fortran/89496 * trans-types.c (get_formal_from_actual_arglist): If the actual arglist has no expression, the corresponding formal arglist is an alternate return. 2019-02-26 Thomas Koenig <tkoenig@gcc.gnu.org> PR fortran/89496 * gfortran.dg/altreturn_9_0.f90: New file. * gfortran.dg/altreturn_9_1.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/altreturn_9_0.f90 trunk/gcc/testsuite/gfortran.dg/altreturn_9_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
Fixed, closing.
Thanks for fixing this! It eliminates an ICE in a legacy code I'm currently modernizing.