Bug 83149 - [6- and 7-branches] Missing test for sym->ns->proc_name: crash_signal in toplev.c:325
Summary: [6- and 7-branches] Missing test for sym->ns->proc_name: crash_signal in topl...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 8.0
: P4 normal
Target Milestone: 8.2
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2017-11-25 00:29 UTC by Neil Carlson
Modified: 2018-05-16 11:44 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 6.4.0, 7.2.0
Known to fail: 8.0
Last reconfirmed: 2017-11-25 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Neil Carlson 2017-11-25 00:29:56 UTC
The current 8.0 trunk gives an ICE on the following example, but only when then the program units are in two separate files. Works fine with 7.2.1 and 6.4.1.

module mod
  character(8) string
contains
  function get_string() result(s)
    character(len_trim(string)) s
    s = string
  end function
end module

use mod
string = 'fubar'
select case (get_string())
case default
end select
end

Here's the traceback:

$ gfortran gfortran-20171124e.f90 gfortran-20171124e-main.f90 
gfortran-20171124e-main.f90:3:0:

 select case (get_string())
 
internal compiler error: Segmentation fault
0xd6b98f crash_signal
	../../gcc/toplev.c:325
0x96852e gfc_sym_type(gfc_symbol*)
	../../gcc/fortran/trans-types.c:2207
0x968ab7 gfc_get_function_type(gfc_symbol*)
	../../gcc/fortran/trans-types.c:2969
0x907aed gfc_get_extern_function_decl(gfc_symbol*)
	../../gcc/fortran/trans-decl.c:2126
0x907ffd gfc_get_extern_function_decl(gfc_symbol*)
	../../gcc/fortran/trans-decl.c:1974
0x91bb24 conv_function_val
	../../gcc/fortran/trans-expr.c:3722
0x91bb24 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:6142
0x91c6fa gfc_conv_expr(gfc_se*, gfc_expr*)
	../../gcc/fortran/trans-expr.c:7852
0x923a6a gfc_conv_expr_reference(gfc_se*, gfc_expr*)
	../../gcc/fortran/trans-expr.c:7952
0x957611 gfc_trans_character_select
	../../gcc/fortran/trans-stmt.c:2819
0x95ee1c gfc_trans_select(gfc_code*)
	../../gcc/fortran/trans-stmt.c:3158
0x8e48b7 trans_code
	../../gcc/fortran/trans.c:1940
0x90e7a8 gfc_generate_function_code(gfc_namespace*)
	../../gcc/fortran/trans-decl.c:6437
0x89d036 translate_all_program_units
	../../gcc/fortran/parse.c:6091
0x89d036 gfc_parse_file()
	../../gcc/fortran/parse.c:6294
0x8e0eaf gfc_be_parse_file
	../../gcc/fortran/f95-lang.c:204
Comment 1 Dominique d'Humieres 2017-11-25 00:48:59 UTC
Revision r254940 is OK, r255137 gives the ICE.
Comment 2 Neil Carlson 2017-11-25 04:05:25 UTC
Here's another example.  The ICE is coming at the same place, toplev.c:325, so I think it may be the same underlying problem.  Like the original example, the ICE occurs only when the main program is in a separate file.

module mod1
  integer :: ncells
end module

module mod2
contains
  function get() result(array)
    use mod1
    real array(ncells)
  end function
end module

With this in a separate file:

use mod2
s = sum(get())
end

Note that the ICE goes away if "use mod1" is moved up to the module scope.
Here's the traceback

$ gfortran gfortran-20171124f.f90 gfortran-20171124f-main.f90 
gfortran-20171124f-main.f90:2:0:

 s = sum(get())
 
internal compiler error: Segmentation fault
0xd6b98f crash_signal
	../../gcc/toplev.c:325
0x90aeeb gfc_finish_var_decl
	../../gcc/fortran/trans-decl.c:606
0x90a274 gfc_get_symbol_decl(gfc_symbol*)
	../../gcc/fortran/trans-decl.c:1777
0x920387 gfc_conv_variable
	../../gcc/fortran/trans-expr.c:2505
0x91c71a gfc_conv_expr(gfc_se*, gfc_expr*)
	../../gcc/fortran/trans-expr.c:7860
0x91ea0a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*)
	../../gcc/fortran/trans-expr.c:4355
0x8ebd04 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*)
	../../gcc/fortran/trans-array.c:920
0x91a5b1 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:6024
0x91c6fa gfc_conv_expr(gfc_se*, gfc_expr*)
	../../gcc/fortran/trans-expr.c:7852
0x8fa083 gfc_add_loop_ss_code
	../../gcc/fortran/trans-array.c:2796
0x8faab5 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
	../../gcc/fortran/trans-array.c:5097
0x93ad87 gfc_conv_intrinsic_arith
	../../gcc/fortran/trans-intrinsic.c:4197
0x93fd3f gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
	../../gcc/fortran/trans-intrinsic.c:9146
0x91c6fa gfc_conv_expr(gfc_se*, gfc_expr*)
	../../gcc/fortran/trans-expr.c:7852
0x925065 gfc_trans_assignment_1
	../../gcc/fortran/trans-expr.c:10018
0x8e45cf trans_code
	../../gcc/fortran/trans.c:1828
0x90e7a8 gfc_generate_function_code(gfc_namespace*)
	../../gcc/fortran/trans-decl.c:6437
0x89d036 translate_all_program_units
	../../gcc/fortran/parse.c:6091
0x89d036 gfc_parse_file()
	../../gcc/fortran/parse.c:6294
0x8e0eaf gfc_be_parse_file
	../../gcc/fortran/f95-lang.c:204
Comment 3 Neil Carlson 2017-11-25 04:11:36 UTC
Unlike comment 0 code, comment 2 code also gives an ICE with 7.2.1 and 6.4.1
Comment 4 kargl 2017-12-26 18:45:14 UTC
The code in comment #0 compiles with gfortran 8.0.0 20171224.

The code in comment #2 still causes an ICE.  The code in this
comment is probably invalid as ncells is never set.  It may
also be invalid in that ncells may not be allowed to be 
used in an initialization expression, but I would need to go 
read up on the conditions on initialization expression and
host association.
Comment 5 Neil Carlson 2017-12-26 20:00:29 UTC
I disagree (in part) with comment 4.  Ncells is a valid specification statement (see 7.1.11, par 2 (4), Fortran 2008).  Its value need not be known at compile time; only when the get() function is executed.  If the code successfully compiled then, yes, at run time it is not conforming because ncells was never assigned a value.

Interestingly if the main program is modified to use mod1 (but still not define ncells) then the ICE goes away.

use mod1
use mod2
s = sum(get())
end

So perhaps there is something here about mod1 going out of scope.  I forget how that works, and seem to recall that some new standard was going to drop that feature of the language.

However that aspect can be side stepped by just turning the main program into a subprogram

subroutine sub
use mod2
s = sum(get())
end

This still gives an ICE and I believe is valid.  Both NAG and Intel compile without error, fwtw.
Comment 6 Steve Kargl 2017-12-26 21:17:18 UTC
On Tue, Dec 26, 2017 at 08:00:29PM +0000, neil.n.carlson at gmail dot com wrote:
> 
> I disagree (in part) with comment 4.
>

As you failed to quote the part that is disagreeable, it is
somewhat difficult to pursue.  The code is clearly invalid
in that ncells is reference but is never set.
Comment 7 Neil Carlson 2017-12-26 21:42:54 UTC
Perhaps this modification of comment 2 code is clearer.

Put this in one file:

module mod1
  integer :: ncells
end module

module mod2
contains
  function get() result(array)
    use mod1
    real array(ncells)
    array = 1.0
  end function
end module

And this in another (this is different):

subroutine sub
use mod2
s = sum(get())
end

This gives an ICE when compiled with 8.0.0 (20171222).

NCELLS is a valid specification expression.

A valid full program that calls SUB would have to define NCELLS before doing so. However it is not required that the compiler know the value of NCELLS at compile time.
Comment 8 Steve Kargl 2017-12-26 23:41:01 UTC
On Tue, Dec 26, 2017 at 09:42:54PM +0000, neil.n.carlson at gmail dot com wrote:
>
> Perhaps this modification of comment 2 code is clearer.

ncell is never set.

> Put this in one file:
> 
> module mod1
>   integer :: ncells
> end module
> 
> module mod2
> contains
>   function get() result(array)
>     use mod1
>     real array(ncells)

The reference to ncells is to an undefined entity. 

>     array = 1.0
>   end function
> end module
> 
> And this in another (this is different):
> 
> subroutine sub
> use mod2

You need to have 

  ncells = 1  ! or some other value here.

> s = sum(get())
> end
> 
> This gives an ICE when compiled with 8.0.0 (20171222).

The code with ncells properly defined defined still
hits an ICE.  This probably a result of not walking
mod2's namespace, but I haven't tried to debug the
problem beyond this.
Comment 9 Thomas Koenig 2018-02-21 21:27:58 UTC
I've done a bisection, and r255094 is the first revision that fails.
Comment 10 Paul Thomas 2018-02-23 16:23:00 UTC
Author: pault
Date: Fri Feb 23 16:22:28 2018
New Revision: 257934

URL: https://gcc.gnu.org/viewcvs?rev=257934&root=gcc&view=rev
Log:
2018-02-23  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/83149
	* trans-decl.c (gfc_finish_var_decl): Test sym->ns->proc_name
	before accessing its components.

2018-02-23  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/83149
	* gfortran.dg/pr83149_1.f90: New test.
	* gfortran.dg/pr83149.f90: Additional source for previous.


Added:
    trunk/gcc/testsuite/gfortran.dg/pr83149.f90
    trunk/gcc/testsuite/gfortran.dg/pr83149_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog
Comment 11 Paul Thomas 2018-02-23 17:55:44 UTC
Author: pault
Date: Fri Feb 23 17:55:13 2018
New Revision: 257938

URL: https://gcc.gnu.org/viewcvs?rev=257938&root=gcc&view=rev
Log:
2018-02-23  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/83149
	* trans-types.c (gfc_sym_type): Test sym->ns->proc_name before
	accessing its components.

2018-02-23  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/83149
	* gfortran.dg/pr83149_b.f90: New test.
	* gfortran.dg/pr83149_a.f90: Additional source for previous.


Added:
    trunk/gcc/testsuite/gfortran.dg/pr83149_a.f90
    trunk/gcc/testsuite/gfortran.dg/pr83149_b.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog
Comment 12 Paul Thomas 2018-02-23 18:13:15 UTC
The original regression is now fixed. The testcases of comments 2 and 7 have been fixed on trunk but remain on 6- and 7-branches. I will await advice from the list as to whether to backport or not and so will keep the PR open.

Neil, you were right about the common origin. Thanks for the report.

Paul
Comment 13 Jakub Jelinek 2018-05-02 10:10:39 UTC
GCC 8.1 has been released.
Comment 14 Paul Thomas 2018-05-16 11:17:42 UTC
Author: pault
Date: Wed May 16 11:17:10 2018
New Revision: 260285

URL: https://gcc.gnu.org/viewcvs?rev=260285&root=gcc&view=rev
Log:
2018-05-16  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/83149
	Backport from trunk
	* trans-decl.c (gfc_finish_var_decl): Test sym->ns->proc_name
	before accessing its components.
	* trans-types.c (gfc_sym_type): If a character result has null
	backend_decl, try the procedure symbol..

2018-05-16  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/83149
	Backport from trunk
	* gfortran.dg/pr83149_1.f90: New test.
	* gfortran.dg/pr83149.f90: Additional source for previous.
	* gfortran.dg/pr83149_b.f90: New test.
	* gfortran.dg/pr83149_a.f90: Additional source for previous.


Added:
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83149.f90
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83149_1.f90
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83149_a.f90
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83149_b.f90
Modified:
    branches/gcc-7-branch/gcc/fortran/ChangeLog
    branches/gcc-7-branch/gcc/fortran/trans-decl.c
    branches/gcc-7-branch/gcc/fortran/trans-types.c
    branches/gcc-7-branch/gcc/testsuite/ChangeLog
Comment 15 Paul Thomas 2018-05-16 11:43:18 UTC
Author: pault
Date: Wed May 16 11:42:47 2018
New Revision: 260286

URL: https://gcc.gnu.org/viewcvs?rev=260286&root=gcc&view=rev
Log:
2018-05-16  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/83149
	Backport from trunk
	* trans-decl.c (gfc_finish_var_decl): Test sym->ns->proc_name
	before accessing its components.
	* trans-types.c (gfc_sym_type): If a character result has null
	backend_decl, try the procedure symbol.

2018-05-16  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/83149
	Backport from trunk
	* gfortran.dg/pr83149_1.f90: New test.
	* gfortran.dg/pr83149.f90: Additional source for previous.
	* gfortran.dg/pr83149_b.f90: New test.
	* gfortran.dg/pr83149_a.f90: Additional source for previous.


Added:
    branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83149.f90
    branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83149_1.f90
    branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83149_a.f90
    branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83149_b.f90
Modified:
    branches/gcc-6-branch/gcc/fortran/ChangeLog
    branches/gcc-6-branch/gcc/fortran/trans-decl.c
    branches/gcc-6-branch/gcc/fortran/trans-types.c
    branches/gcc-6-branch/gcc/testsuite/ChangeLog
Comment 16 Paul Thomas 2018-05-16 11:44:45 UTC
Fixed on 6-branch through to trunk

Thanks for the report.

Paul