Bug 56386 - [F03] ICE with ASSOCIATE construct and an derived type array component
Summary: [F03] ICE with ASSOCIATE construct and an derived type array component
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 7.1.1
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code, rejects-valid
Depends on:
Blocks: associate
  Show dependency treegraph
 
Reported: 2013-02-18 22:38 UTC by Vladimir Fuka
Modified: 2019-01-27 18:54 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-04-16 00:00:00


Attachments
reproduction case source (168 bytes, text/x-fortran)
2013-02-18 22:38 UTC, Vladimir Fuka
Details
A patch for the original problem (472 bytes, patch)
2018-10-14 13:05 UTC, Paul Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Fuka 2013-02-18 22:38:33 UTC
Created attachment 29489 [details]
reproduction case source

The attached source causes an ICE with GCC-4.6, GCC-4.7 and GCC-4.8

> gfortran ice.f90 -c -v
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8-20130217/configure --enable-languages=c,c++,fortran --prefix=/usr/local/gcc-4.8
Thread model: posix
gcc version 4.8.0 20130217 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951 ice.f90 -quiet -dumpbase ice.f90 -mtune=generic -march=x86-64 -auxbase ice -version -fintrinsic-modules-path /usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/finclude -o /tmp/ccc6FYBT.s
GNU Fortran (GCC) version 4.8.0 20130217 (experimental) (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.8.0 20130217 (experimental), GMP version 5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.8.0 20130217 (experimental) (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.8.0 20130217 (experimental), GMP version 5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ice.f90: In function ‘customsolidbodies’:
ice.f90:15:0: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1574
        PrTer%elev=0
 ^
0x5e5ac3 gfc_conv_component_ref
        ../../gcc-4.8-20130217/gcc/fortran/trans-expr.c:1574
0x5f2721 gfc_conv_variable
        ../../gcc-4.8-20130217/gcc/fortran/trans-expr.c:1817
0x5ef1da gfc_conv_expr(gfc_se*, gfc_expr*)
        ../../gcc-4.8-20130217/gcc/fortran/trans-expr.c:6266
0x5f55cc gfc_trans_assignment_1
        ../../gcc-4.8-20130217/gcc/fortran/trans-expr.c:7754
0x5bc331 trans_code
        ../../gcc-4.8-20130217/gcc/fortran/trans.c:1422
0x619e18 gfc_trans_block_construct(gfc_code*)
        ../../gcc-4.8-20130217/gcc/fortran/trans-stmt.c:1342
0x5bc0e7 trans_code
        ../../gcc-4.8-20130217/gcc/fortran/trans.c:1527
0x5e312e gfc_generate_function_code(gfc_namespace*)
        ../../gcc-4.8-20130217/gcc/fortran/trans-decl.c:5395
0x57c360 translate_all_program_units
        ../../gcc-4.8-20130217/gcc/fortran/parse.c:4468
0x57c360 gfc_parse_file()
        ../../gcc-4.8-20130217/gcc/fortran/parse.c:4682
0x5b79f5 gfc_be_parse_file
        ../../gcc-4.8-20130217/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 janus 2013-02-18 22:46:23 UTC
Confirmed. ICEs with all of 4.6, 4.7 and trunk.
Comment 2 Tobias Burnus 2013-04-16 17:17:52 UTC
Related test case by the bug reporterm https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/UvBX1kfuFqs


This time rejecting the code instead of ICEing:

   print *,x%i
             1
Error: Symbol 'x' at (1) has no IMPLICIT type



program p
  type t
    integer :: i = 0
  end type

  associate (x=>f())
    print *,x%i
  end associate

  contains
    function f()
      type(t) f
      f%i = 5
    end function
end program
Comment 3 Vladimir Fuka 2013-04-16 17:40:04 UTC
Thanks, I didn't realize they might be connected. I even forgotten I have
this bug opened when I asked.

  Vladimir
Dne 16.4.2013 19:17 "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
napsal(a):

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386
>
> Tobias Burnus <burnus at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>            Keywords|                            |rejects-valid
>              Status|UNCONFIRMED                 |NEW
>    Last reconfirmed|                            |2013-04-16
>                  CC|                            |burnus at gcc dot gnu.org
>      Ever Confirmed|0                           |1
>
> --- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-04-16
> 17:17:52 UTC ---
> Related test case by the bug reporterm
>
> https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/UvBX1kfuFqs
>
>
> This time rejecting the code instead of ICEing:
>
>    print *,x%i
>              1
> Error: Symbol 'x' at (1) has no IMPLICIT type
>
>
>
> program p
>   type t
>     integer :: i = 0
>   end type
>
>   associate (x=>f())
>     print *,x%i
>   end associate
>
>   contains
>     function f()
>       type(t) f
>       f%i = 5
>     end function
> end program
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
> You reported the bug.
>
Comment 4 Dominique d'Humieres 2015-02-09 11:14:48 UTC
pr64674 is likely a duplicate of this pr.
Comment 5 Vladimir Fuka 2017-06-07 15:16:02 UTC
Probably not a duplicate of pr64674 because this bug is still present in 7.1.1.
Comment 6 Vladimir Fuka 2017-06-07 15:16:35 UTC
Probably not a duplicate of pr64674 because this bug is still present in 7.1.1.
Comment 7 janus 2018-10-01 18:02:44 UTC
(In reply to Tobias Burnus from comment #2)
> Related test case by the bug reporterm
> https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/
> UvBX1kfuFqs
> 
> 
> This time rejecting the code instead of ICEing:
> 
>    print *,x%i
>              1
> Error: Symbol 'x' at (1) has no IMPLICIT type

One can get past this error via:

diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index 6f45afa86ea..311e3aafc85 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2111,7 +2111,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, bool sub_flag,
          sym->ts = tgt_expr->ts;
        }
 
-      if (sym->ts.type == BT_UNKNOWN)
+      if (sym->ts.type == BT_UNKNOWN && !sym->assoc)
        {
          gfc_error ("Symbol %qs at %C has no IMPLICIT type", sym->name);
          return MATCH_ERROR;

but then one runs into:

7 |     print *,x%i
  |              1
Error: Syntax error in PRINT statement at (1)



> program p
>   type t
>     integer :: i = 0
>   end type
> 
>   associate (x=>f())
>     print *,x%i
>   end associate
> 
>   contains
>     function f()
>       type(t) f
>       f%i = 5
>     end function
> end program


The general problem with this case is that we can not infer the type of 'x' before parsing the print statement. Right now I can not see how to get around this issue.
Comment 8 Paul Thomas 2018-10-14 13:05:49 UTC
Created attachment 44838 [details]
A patch for the original problem

The attached does the job on the original problem. I will wait until the fix for PR87566 is committed before submitting this one.

With respect to the problem in comment #2: This one is really tough because the type of the function f() has not been determined since it is contained. Either we have to change the parsing sequence such that a CONTAINS statement is searched for and the the contained procedures parsed or we look for a derived type with the component name and set the symbol type accordingly. Even if it is a bit desperate, the latter is certainly doable. 

Paul
Comment 9 Paul Thomas 2018-10-17 07:16:48 UTC
Author: pault
Date: Wed Oct 17 07:16:16 2018
New Revision: 265232

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

	PR fortran/56386
	PR fortran/58906
	PR fortran/77385
	PR fortran/80260
	PR fortran/82077
	* resolve.c (resolve_variable): Fix up expressions with array
	associate names, where the parser did not detect that this is
	array and there was no array part_ref in the expression.

2018-10-17  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/56386
	PR fortran/58906
	PR fortran/77385
	* gfortran.dg/associate_44.f90 : New test.

	PR fortran/80260
	* gfortran.dg/select_type_45.f90 : New test.

	PR fortran/82077
	* gfortran.dg/select_type_46.f90 : New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/associate_44.f90
    trunk/gcc/testsuite/gfortran.dg/select_type_45.f90
    trunk/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 10 Jürgen Reuter 2018-10-17 10:30:00 UTC
Paul, I think this "bugfix" introduced an ICE in our code. I will open a new PR.
Comment 11 Tobias Burnus 2018-10-17 11:13:52 UTC
(In reply to Jürgen Reuter from comment #10)
> Paul, I think this "bugfix" introduced an ICE in our code. I will open a new
> PR.

Seemingly, it's PR 87632
Comment 12 Martin Liška 2018-11-19 12:53:51 UTC
Can the bug be marked as resolved?
Comment 13 Paul Thomas 2019-01-13 18:20:37 UTC
Fixed on trunk.

Thanks for the report.

Paul
Comment 14 Paul Thomas 2019-01-27 18:02:49 UTC
Author: pault
Date: Sun Jan 27 18:02:17 2019
New Revision: 268313

URL: https://gcc.gnu.org/viewcvs?rev=268313&root=gcc&view=rev
Log:
2019-01-27  Paul Thomas  <pault@gcc.gnu.org>

	Backport from trunk
	PR fortran/56386
	PR fortran/58906
	PR fortran/77385
	PR fortran/80260
	PR fortran/82077
	* resolve.c (resolve_variable): Fix up expressions with array
	associate names, where the parser did not detect that this is
	array and there was no array part_ref in the expression.
	* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
	should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  <pault@gcc.gnu.org>

	Backport from trunk
	PR fortran/56386
	PR fortran/58906
	PR fortran/77385
	* gfortran.dg/associate_44.f90 : New test.

	PR fortran/80260
	* gfortran.dg/select_type_45.f90 : New test.

	PR fortran/82077
	* gfortran.dg/select_type_46.f90 : New test.


Added:
    branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_44.f90
    branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
    branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
    branches/gcc-8-branch/gcc/fortran/ChangeLog
    branches/gcc-8-branch/gcc/fortran/resolve.c
    branches/gcc-8-branch/gcc/fortran/trans-expr.c
    branches/gcc-8-branch/gcc/testsuite/ChangeLog
Comment 15 Paul Thomas 2019-01-27 18:54:18 UTC
Author: pault
Date: Sun Jan 27 18:53:47 2019
New Revision: 268317

URL: https://gcc.gnu.org/viewcvs?rev=268317&root=gcc&view=rev
Log:
2019-01-27  Paul Thomas  <pault@gcc.gnu.org>

	Backport from trunk
	PR fortran/56386
	PR fortran/58906
	PR fortran/77385
	PR fortran/80260
	PR fortran/82077
	* resolve.c (resolve_variable): Fix up expressions with array
	associate names, where the parser did not detect that this is
	array and there was no array part_ref in the expression.
	* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
	should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  <pault@gcc.gnu.org>

	Backport from trunk
	PR fortran/56386
	PR fortran/58906
	PR fortran/77385
	* gfortran.dg/associate_44.f90 : New test.

	PR fortran/80260
	* gfortran.dg/select_type_45.f90 : New test.

	PR fortran/82077
	* gfortran.dg/select_type_46.f90 : New test.


Added:
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_44.f90
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
    branches/gcc-7-branch/gcc/fortran/ChangeLog
    branches/gcc-7-branch/gcc/fortran/resolve.c
    branches/gcc-7-branch/gcc/fortran/trans-expr.c
    branches/gcc-7-branch/gcc/testsuite/ChangeLog