[Bug fortran/46991] New: [OOP] polymorphic assumed-size actual arguments

[Bug fortran/46991] New: [OOP] polymorphic assumed-size actual arguments

[burnus at gcc dot gnu.org]

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

           Summary: [OOP] polymorphic assumed-size actual arguments
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: janus@gcc.gnu.org


Found at http://j3-fortran.org/pipermail/j3/2010-December/004084.html

Currently, it is unclear whether the following program is valid, but Robert
Corbett of Oracle (formerly Sun) thinks it is (but does not seem to like it.)

[100% guessing, 90% wrongly]: The main issue he sees is seemingly that SUB2
does not need to have an explicit interface - which only works if the $data of
a CLASS and a TYPE object start at the same offset of the passed pointer
address.

I think that part is OK in gfortran, but gfortran has other issues:


Gfortran rejects the program with:

        CALL SUB2(A, N)
                  1
Warning: Type mismatch in argument 'a' at (1); passed CLASS(rec) to TYPE(rec)

[That's PR 46990.] I also tried SELECT TYPE but with limited success.


Using
        CLASS(REC) A(*)
one gets:
        PRINT *, A(:N)%A
                   1
Error: Syntax error in argument list at (1)


 * * *

       MODULE TYPES
         PRIVATE
         PUBLIC REC, REC2

         TYPE REC
           INTEGER A
         END TYPE

         TYPE, EXTENDS(REC) :: REC2
           INTEGER B
         END TYPE
       END

       SUBROUTINE SUB1(A, N)
         USE TYPES
         CLASS(REC), INTENT(IN) :: A(*)

         CALL SUB2(A, N)
       END

       SUBROUTINE SUB2(A, N)
         USE TYPES
         TYPE(REC) A(*)

         PRINT *, A(:N)%A
       END

       PROGRAM MAIN
         USE TYPES
         CLASS(REC), ALLOCATABLE :: A(:)
         INTERFACE
           SUBROUTINE SUB1(A, N)
             USE TYPES
             CLASS(REC), INTENT(IN) :: A(*)
           END SUBROUTINE
         END INTERFACE

         A = [ (REC2(I, I+1), I = 1, 10) ]
         CALL SUB1(A, 10)
       END

[Bug fortran/46991] [OOP] polymorphic assumed-size actual arguments

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #1 from Harald Anlauf <anlauf at gmx dot de> 2012-12-23 22:17:25 UTC ---
The code is rejected by nagfor:

NAG Fortran Compiler Release 5.3.1(907)
Error: pr46991.f90, line 16: CLASS array A must be a pointer, allocatable or
assumed-shape
Errors in declarations, no further processing for SUB1
Error: pr46991.f90, line 34: CLASS array A must be a pointer, allocatable or
assumed-shape

Changing from assumed size to assumed shape, however, make the
code compilable.

The code modified this way still does not compile with current trunk:

         A = [ (REC2(I, I+1), I = 1, 10) ]
         1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator

It is funny to see that ifort 13 generates a similar message:

pr46991.f90(38): error #6197: An assignment of different structure types is
invalid.
         A = [ (REC2(I, I+1), I = 1, 10) ]
----------------^
pr46991.f90(38): error #8304: In an intrinsic assignment statement, variable
shall not be polymorphic.   [A]
         A = [ (REC2(I, I+1), I = 1, 10) ]
---------^

[Bug fortran/46991] [OOP] polymorphic assumed-size actual arguments

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-23 22:33:24 UTC ---
(In reply to comment #1)
> Error: pr46991.f90, line 16: CLASS array A must be a pointer, allocatable or
> assumed-shape

I think that's a bug in NAG - at least, I cannot find anything in the standard
which prohibits explicit-size or assumed-size polymorphic arrays.


> The code modified this way still does not compile with current trunk:
>          A = [ (REC2(I, I+1), I = 1, 10) ]
>          1
> Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
> that there is a matching specific subroutine for '=' operator

See PR43366. That's a Fortran 2008 feature. Assignment to a polymorphic LHS
variable is allowed, if and only if it is allocatable; it makes use of the
realloc-on-assignment feature.

[Bug fortran/46991] [OOP] polymorphic assumed-size actual arguments

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-19
     Ever confirmed|0                           |1

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compiling the test in comment 0 with gfortran 4.8.2 or trunk r206033 gives

pr46991.f90:16.39:

         CLASS(REC), INTENT(IN) :: A(*)
                                       1
Error: Assumed size polymorphic objects or components, such as that at (1),
have not yet been implemented
pr46991.f90:34.43:

             CLASS(REC), INTENT(IN) :: A(*)
                                           1
Error: Assumed size polymorphic objects or components, such as that at (1),
have not yet been implemented
pr46991.f90:18.19:

         CALL SUB2(A, N)
                   1
Warning: Type mismatch in argument 'a' at (1); passed REAL(4) to TYPE(rec)
pr46991.f90:38.9:

         A = [ (REC2(I, I+1), I = 1, 10) ]
         1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator
pr46991.f90:39.19:

         CALL SUB1(A, 10)
                   1
Error: Type mismatch in argument 'a' at (1); passed CLASS(rec) to REAL(4)

[Bug fortran/46991] [OOP] polymorphic assumed-size actual arguments

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46991

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:7920c05ce0b737da1abf644cf4b3fa862a1b3df1

commit r12-636-g7920c05ce0b737da1abf644cf4b3fa862a1b3df1
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Fri May 7 19:52:40 2021 +0100

    Fortran: Correct PR number from 46691 [PR46991].

    2021-05-07  Paul Thomas  <pault@gcc.gnu.org>

    gcc/testsuite/ChangeLog

            PR fortran/46991
            * gfortran.dg/class_dummy_7.f90: Correct PR number.

[Bug fortran/46991] [OOP] polymorphic assumed-size actual arguments

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46991

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
Pushed the fix by Paul to remaining open branches, but missed that the PR
number
was off due to a typo.  Closing.

Thanks for the report!