To my understanding, the interface declaration is valid (Fortran 2003, ignoring
VOLATILE valid Fortran 95). However, gfortran rejects it with:
END SUBROUTINE
1
Error: Assignment operator interface at (1) must not redefine an INTRINSIC type
assignment
NAG f95, ifort and openf95 accept it.
* * *
>From the F2003 interpretations comes also the part below. Here, gfortran fails
to diagnose the violation of the constrain
"C1233 (R1221) If an actual argument is a pointer array, and the corresponding
dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy
argument shall be an assumed-shape array or a pointer array."
(see below).
Example (see N1711.txt / F03/0088):
INTERFACE ASSIGNMENT(=)
SUBROUTINE s(a,b)
REAL,INTENT(OUT),VOLATILE :: a(1,*)
REAL,INTENT(IN) :: b(:)
END SUBROUTINE
END Interface
REAL,POINTER :: p(:,:),q(:)
CALL s(p,q) ! Violation of constraint C1233 [271:9-11],
! associating P with A
p = q ! No constraint violation because <actual-arg>
! syntax is not being used
end
>From the interpretation request (F03/0088, passed by J3, to be voted on by W5):
QUESTION:
Did Fortran 2003 intend to enforce constraints on <actual-arg> in
defined assignment?
ANSWER:
Yes, the <actual-arg> constraints and restrictions should be enforced
in defined assignment and in defined operator evaluation.
Edits are provided below to do this.
EDITS:
[262:16] add at the end of the paragraph
"All restrictions and constraints that apply to actual arguments
in a reference to the function also apply to the corresponding
operands in the expression as if they were used as actual arguments."
[263:12] insert after "the second argument."
"All restrictions and constraints that apply to actual arguments
in a reference to the subroutine also apply to the left-hand-side
and to the right-hand-side enclosed in parentheses as if they were
--
Summary: Valid ASSIGNMENT(=) rejected
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35033
