Bug 55172 - [4.7 Regression] [OOP] gfc_variable_attr(): Bad array reference in SELECT TYPE
Summary: [4.7 Regression] [OOP] gfc_variable_attr(): Bad array reference in SELECT TYPE
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.3
: P4 normal
Target Milestone: 4.7.4
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-invalid-code
Depends on:
Blocks:
 
Reported: 2012-11-01 22:42 UTC by Andrew Benson
Modified: 2014-01-19 12:20 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-11-02 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Benson 2012-11-01 22:42:17 UTC
The following test case produces and ICE with gfortran 4.8 (r193051):

module gn
  type :: ncb
  end type ncb
  type, public :: tn
     class(ncb), allocatable, dimension(:) :: cb
  end type tn
contains
  integer function name(self)
    implicit none
    class (tn), intent(in) :: self
    select type (component => self%cb(i))
    end select
  end function name
end module gn

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-
linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --
prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --
disable-multilib --with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.8.0 20121031 (experimental) (GCC) 

$ gfortran -c bug4.F90 -o bug4.o
bug4.F90:14.13:

end module gn
             1   
Internal Error at (1):
gfc_variable_attr(): Bad array reference


The code is invalid because the "name" function contains "implicit none" but 
the variable "i" used in:

    select type (component => self%cb(i))

is not explicitly defined. If I remove the "implicit none" or explicitly 
define "i" the ICE goes away.


(Reported by Janus at http://gcc.gnu.org/ml/fortran/2012-11/msg00005.html): With 4.7 the ICE also occurs, but only after the correct error message:

    select type (component => self%cb(i))
                                       1
Error: Symbol 'i' at (1) has no IMPLICIT type
Comment 1 janus 2012-11-02 11:07:33 UTC
(In reply to comment #0)
> (Reported by Janus at http://gcc.gnu.org/ml/fortran/2012-11/msg00005.html):
> With 4.7 the ICE also occurs, but only after the correct error message:
> 
>     select type (component => self%cb(i))
>                                        1
> Error: Symbol 'i' at (1) has no IMPLICIT type


Yes, therefore it's a regression in 4.7 (ICE after error) and 4.8 (ICE only).


4.6 of course rejects it ('cleanly') with:

     class(ncb), allocatable, dimension(:) :: cb
                                                1
Fatal Error: Polymorphic array at (1) not yet supported



(Side note: The 'fatal' seems a bit strong here, but that was probably used to suppress further error messages.)
Comment 2 janus 2012-11-02 12:09:50 UTC
I suspect the 4.8-problem of having only the ICE without a prior error message might be due to this commit:

http://gcc.gnu.org/viewcvs?view=revision&revision=187192

I think the function 'copy_ts_from_selector_to_associate' comes too early (namely during parsing). It tries to resolve the target expr, which should rather wait until resolution stage!?!
Comment 3 Paul Thomas 2013-01-02 12:34:35 UTC
(In reply to comment #2)
> I suspect the 4.8-problem of having only the ICE without a prior error message
> might be due to this commit:
> 
> http://gcc.gnu.org/viewcvs?view=revision&revision=187192
> 
> I think the function 'copy_ts_from_selector_to_associate' comes too early
> (namely during parsing). It tries to resolve the target expr, which should
> rather wait until resolution stage!?!

This is partially correct.  Unfortunately, the selector expression comes from the parser with the ar->type == AR_UNKNOWN and it was this that gfc_resolve_expr was putting right.  As long as all the variables were declared or had implicit types, all was well.

Th is fixed by removing the call to gfc_resolve_expr and adding explicit code, copied from resolve_array_ref, to set the correct type.  It is also necessary/advisable to add a call to resolve the selector expression in resolve_select_type.

I will submit a patch later today.

Cheers

Paul

PS If the index 'i' is declared, wrong code results as in pr54990.
Comment 4 Paul Thomas 2013-01-04 20:50:23 UTC
Author: pault
Date: Fri Jan  4 20:50:15 2013
New Revision: 194916

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194916
Log:
2013-01-04  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/55172
	* match.c (copy_ts_from_selector_to_associate): Remove call to
	gfc_resolve_expr and replace it with explicit setting of the
	array reference type.
	* resolve.c (resolve_select_type): It is an error if the
	selector is coindexed.

2013-01-04  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/55172
	* gfortran.dg/select_type_31.f03: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/select_type_31.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 5 Paul Thomas 2013-01-05 07:52:31 UTC
I tried the best I could with 4.7 but there are quite significant divergences with trunk, both around and downstream from the patch.  The best that I could manage was:

/svn/gcc-4_7-branch/gcc/testsuite/gfortran.dg/select_type_31.f03:16.4:

    select type (component => self%cb(i) ! { dg-error "has no IMPLICIT type" }
    1
Error: Unclassifiable statement at (1)
/svn/gcc-4_7-branch/gcc/testsuite/gfortran.dg/select_type_31.f03:17.7:

    end select
       1
Error: Expecting END FUNCTION statement at (1)

which is more opaque than the correct error followed by the internal error!

I decided, therefore, to leave the PR as 4.7 only and have unassigned myself.

In addition, I think that to call it a regression is incorrect since polymorphic arrays were unavailable in 4.6!  I have therefore removed regression from the title.

I might be persuaded to return to this, once 4.8 is released.

Paul
Comment 6 Richard Biener 2013-04-11 07:59:29 UTC
GCC 4.7.3 is being released, adjusting target milestone.
Comment 7 Paul Thomas 2014-01-19 12:20:01 UTC
I think that it is best to leave this unfixed for 4.7 - see comment #5

I have therefore marked the PR as resolved.

Thanks for the report

Paul