[Bug fortran/55850] New: [OOP] SELECT TYPE issues

[Bug fortran/55850] New: [OOP] SELECT TYPE issues

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55850

             Bug #: 55850
           Summary: [OOP] SELECT TYPE issues
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: accepts-invalid, ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: pault@gcc.gnu.org


a) Accepts invalid with coindexed variables. Fortran 2008:

R804  association  is  associate-name => selector
R805  selector  is  expr
                or  variable
C801 (R804) If selector is not a variable or is a variable that has a vector
subscript, associate-name shall not appear in a variable definition context
(16.6.7).
C802 (R804) An associate-name shall not be the same as another associate-name
in the same associate-stmt.
C803 (R805) variable shall not be a coindexed object.
C804 (R805) expr shall not be a variable.


I think that prohibits:
  associate (myname => coarray[i])

For ASSOCIATE, one gets:

associate (x => caf[4])
                      1
Error: Association target at (1) must not be coindexed


But for SELECT TYPE, it is accepted:

module gn
  type :: ncb
  end type ncb
  type, public :: tn
     class(ncb), allocatable :: cb(:)[:]
  end type tn
contains
  integer function name(self)
    implicit none
    class (tn), intent(in) :: self
    select type (component => self%cb(1)[4])  ! INVALID due to the "[4]"
    end select
  end function name
end module gn


Note: The problem is not the coarray, just the coindex (gfc_is_coindexed).



b) ICE with the following:
    select type (t = self%cb)
Note the "=" opposed to "=>". Backtrace:

0x5e32d0 gfc_undo_symbols()
        ../../gcc/fortran/symbol.c:2972
0x5af3aa reject_statement
        ../../gcc/fortran/parse.c:1747
0x5af4dc match_word
        ../../gcc/fortran/parse.c:72


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



c) The following also ICEs:

0x5cd395 resolve_select_type
        ../../gcc/fortran/resolve.c:7791
0x5cd395 resolve_code
        ../../gcc/fortran/resolve.c:9707


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

[Bug fortran/55850] [OOP] SELECT TYPE issues

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55850

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-01-02 22:45:38 UTC ---
See also PR 55172, the coarray issue
(http://gcc.gnu.org/ml/fortran/2013-01/msg00004.html) and PR 54990.

[Bug fortran/55850] [OOP] SELECT TYPE issues

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55850

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-03-22
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
As for r208743, compiling the first test gives the following error

    select type (component => self%cb(1)[4])  ! INVALID due to the "[4]"
                              1
Error: Selector at (1) must not be coindexed

Compiling the second test no longer gives an ICE, but the errors

    select type (t = self%cb)
                   1
Error: parse error in SELECT TYPE statement at (1)
pr55850_1.f90:12.7:

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

Same thing for the third test

    select type (t => self%cb)
                             1
Error: Symbol 't' at (1) has no IMPLICIT type
pr55850_2.f90:11.30:

    select type (t => self%cb)
                              1
Error: Selector shall be polymorphic in SELECT TYPE statement at (1)

although I am not sure about the errors for the later test.

I get the same behavior with 4.8.3. With 4.7.4, I get

pr55850.f90:10.34:

    class (tn), intent(in) :: self
                                  1
Error: Component '_def_init' at (1) with coarray component shall be a
nonpointer, nonallocatable scalar
pr55850.f90:10.34:

    class (tn), intent(in) :: self
                                  1
Error: Variable 'dst' at (1) is INTENT(OUT) and can thus not be an allocatable
coarray or have coarray components
pr55850.f90:10.34:

    class (tn), intent(in) :: self
                                  1
Error: Component '_def_init' at (1) with coarray component shall be a
nonpointer, nonallocatable scalar

pr55850_1.f90:11.4:

    select type (t = self%cb)
    1
Error: Unclassifiable statement at (1)
pr55850_1.f90:12.7:

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

pr55850_2.f90:11.30:

    select type (t => self%cb)
                              1
Error: Selector shall be polymorphic in SELECT TYPE statement at (1)

The first ICE disappeared between r197802 (ICE) and r197969 (errors), and the
second one, between r201916 (ICE) and r202111 (errors). Is this PR fixed or
not?

[Bug fortran/55850] [OOP] SELECT TYPE issues

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55850

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Seems to be fixed with both a recent GCC 4.8.3 and GCC 4.10.
Thus, close as FIXED.