Bug 89496 - [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
Summary: [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 9.0
: P4 normal
Target Milestone: 9.0
Assignee: Thomas Koenig
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: ubsan
  Show dependency treegraph
 
Reported: 2019-02-25 14:27 UTC by Martin Liška
Modified: 2019-02-28 15:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 8.2.0
Known to fail: 9.0
Last reconfirmed: 2019-02-25 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liška 2019-02-25 14:27:07 UTC
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)
Comment 1 Dominique d'Humieres 2019-02-25 14:38:53 UTC
Likely due to r268992 (the ICE occurs in the added block).

The PR requires an instrumented compiler.
Comment 2 Thomas Koenig 2019-02-25 20:58:19 UTC
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);
     }
 }
Comment 3 Thomas Koenig 2019-02-25 21:04:40 UTC
This test case also segfaults with a non-instrumeted compiler:

program main
  call sub(10, *10, 20)
  stop 1
10 continue
end program main
Comment 4 Martin Liška 2019-02-26 08:22:52 UTC
(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.
Comment 5 Thomas Koenig 2019-02-26 19:10:32 UTC
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
Comment 6 Thomas Koenig 2019-02-26 19:11:05 UTC
Fixed, closing.
Comment 7 Damian Rouson 2019-02-28 15:08:50 UTC
Thanks for fixing this!  It eliminates an ICE in a legacy code I'm currently modernizing.