The test program gives the message: c_tests_cg0018.f:28.20: TLA1L(NFV1) = UDA1R 1 Error: Can't convert TYPE(seq) to TYPE(unseq) at (1) Where NFV1 is an integer scalar array. I believe the error is incorrect. This is from the SHAPE95 test suite. This test was contentious during the suite development and at least one vendor almost submitted an interpretation request. I believe that lines 27 to 30 of page 110 say that elemental defined assignments are processed element-by-element, in any order, so that it's as if things were written TLA1L(3) = UDA1R(3) TLA1L(7) = UDA1R(7) .... and those assignments are perfectly well defined (and gfortran accepts similar ones). Additionally, assignments like real_array(NFV1) = some_other_array are well defined (with a restriction on NFV1's values). That's the gist of the argument as I remember it from 10 years ago. The sample program is MODULE c_TESTS integer, save :: nfv1(10) TYPE UNSEQ REAL R END TYPE UNSEQ TYPE SEQ sequence REAL R END TYPE SEQ INTERFACE ASSIGNMENT(=) MODULE PROCEDURE C_U_TO_T END INTERFACE ASSIGNMENT(=) CONTAINS ELEMENTAL PURE SUBROUTINE C_U_TO_T(T,U) TYPE(SEQ),INTENT(IN) :: U TYPE(UNSEQ), INTENT(OUT) :: T T%R = U%R END SUBROUTINE C_U_TO_T SUBROUTINE CG1018(UDA1R) TYPE(UNSEQ) TLA1L(10) TYPE(SEQ) UDA1R(10) TLA1L(NFV1) = UDA1R END SUBROUTINE END MODULE c_TESTS
The error message is strange, but an error is not necessarily wrong. Other compilers show the following messages: NAG f95 shows the error: Error: line 29: Argument T (no. 1) of C_U_TO_T is OUT or INOUT but is not a variable g95: Error: Actual argument at (1) is a vector subscript associated with an INTENT(OUT)/INTENT(INOUT) argument ifort -stand f95: Warning:line 29: It is non-standard to call an elemental procedure with an array having vector valued subscripts if the dummy argument has intent [IN]OUT. [TLA1L] TLA1L(NFV1) = UDA1R ------^
Found the relevant part in the Fortran standard: Fortran 2003: "12.4.1.2 Actual arguments associated with dummy data objects" "If the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the INTENT (OUT), INTENT (INOUT), VOLATILE, or ASYNCHRONOUS attributes." gfortran has this check - but it is not triggered for assignment(=) - or it happens later than the mismatch. It would helpful, if you could find the interpretation or re-check the test case. (There is a to-be corrected typo: @@ -2001,7 +2025,7 @@ compare_actual_formal (gfc_actual_arglis { if (where) gfc_error ("Array-section actual argument with vector subscripts " - "at %L is incompatible with INTENT(IN), INTENT(INOUT) " + "at %L is incompatible with INTENT(OUT), INTENT(INOUT) " "or VOLATILE attribute of the dummy argument '%s'", &a->expr->where, f->sym->name); return 0; )
Subject: Re: defined assignment not allowed to vector subscripted array Why not put this one on hold for a while. I'll check some more. There never was a formal interpretation request. It's kind of odd, both NAG and DEC have (had for DEC) the SHAPE95 and neither has complained in the last 10 or so years about this test. My reading is that you nheed to read 7.5.1.6 to see how defined assignment is "interpreted". After you've read lines 27 to 30, then you go to chapter 12 to see how subroutines are called on an element-by-element basis. Malcolm Cohen's argument long ago was that we had dueling sections. If you start at chapter 12 you'll come to the conclusion that the example is disallowed. I'll see if I can get J3 to come to a consensus. Dick On 16 Jan 2008 16:34:47 -0000, burnus at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #2 from burnus at gcc dot gnu dot org 2008-01-16 16:34 ------- > Found the relevant part in the Fortran standard: > > Fortran 2003: "12.4.1.2 Actual arguments associated with dummy data objects" > > "If the actual argument is an array section having a vector subscript, the > dummy argument is not definable and shall not have the INTENT (OUT), INTENT > (INOUT), VOLATILE, or ASYNCHRONOUS attributes." > > gfortran has this check - but it is not triggered for assignment(=) - or it > happens later than the mismatch. > > It would helpful, if you could find the interpretation or re-check the test > case. > > > (There is a to-be corrected typo: > @@ -2001,7 +2025,7 @@ compare_actual_formal (gfc_actual_arglis > { > if (where) > gfc_error ("Array-section actual argument with vector subscripts " > - "at %L is incompatible with INTENT(IN), INTENT(INOUT) " > + "at %L is incompatible with INTENT(OUT), INTENT(INOUT) " > "or VOLATILE attribute of the dummy argument '%s'", > &a->expr->where, f->sym->name); > return 0; > > ) > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
> "If the actual argument is an array section having a vector subscript, the > dummy argument is not definable and shall not have the INTENT (OUT), INTENT > (INOUT), VOLATILE, or ASYNCHRONOUS attributes." > > gfortran has this check - but it is not triggered for assignment(=) - or it > happens later than the mismatch. In spite of the message it is the INTENT(OUT) requirement that is being applied. Eliminate the vector subscript or put it on the rhs and the testcase compiles fine. Note well that, in spite of the error, this occurs for an intrinsic type/ derive type assignment too. I happen to think that the testcase is OK since the procedure is elemental. It's interesting that everybody barfs on it, including Lahey.... Cheers Paul
has J3 judged the testcase ?
Subject: Re: defined assignment not allowed to vector subscripted array On Fri, Aug 8, 2008 at 3:39 PM, jv244 at cam dot ac dot uk <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #5 from jv244 at cam dot ac dot uk 2008-08-08 20:39 ------- > has J3 judged the testcase ? Almost. It's interpretation request 111. The status in June was "passed J3", it next needs to be accepted by WG5, although that is likely to be a mere formality. The J3 vote was unanimous and taken at a joint WG5/J3 meeting. It's unlikely to change. Unfortunately, they got it wrong and are rejecting my claim that the test is standard conforming. So, you can mark this bug report as "closed with no action" or "user error" or whatever you use to (politely) tell someone to go away. Dick Hendrickson > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
> Unfortunately, they got it wrong and are rejecting my claim that the > test is standard conforming. See also: http://www.j3-fortran.org/doc/year/08/08-104r1.txt Let's mark it as "diagnostic". I think the error message could be improved and probably the typo patch of comment #2 still needs to be applied.
(In reply to comment #7) > Let's mark it as "diagnostic". I think the error message could be improved and > probably the typo patch of comment #2 still needs to be applied. Patch in comment #2 has been applied at some point. Closing as INVALID as requested by the reporter.