[Bug fortran/34805] New: defined assignment not allowed to vector subscripted array

[Bug fortran/34805] New: defined assignment not allowed to vector subscripted array

[dick dot hendrickson at gmail dot com]

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


-- 
           Summary: defined assignment not allowed to vector subscripted
                    array
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug fortran/34805] defined assignment not allowed to vector subscripted array

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2008-01-16 07:23 -------
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
------^


-- 


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

[Bug fortran/34805] defined assignment not allowed to vector subscripted array

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/34805] defined assignment not allowed to vector subscripted array

[dick dot hendrickson at gmail dot com]

------- Comment #3 from dick dot hendrickson at gmail dot com  2008-01-16 20:07 -------
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.
>


-- 


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

[Bug fortran/34805] defined assignment not allowed to vector subscripted array

[dfranke at gcc dot gnu dot org]

-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |WAITING


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

[Bug fortran/34805] defined assignment not allowed to vector subscripted array

[pault at gcc dot gnu dot org]

------- Comment #4 from pault at gcc dot gnu dot org  2008-03-31 19:22 -------


> "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


-- 


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

[Bug fortran/34805] defined assignment not allowed to vector subscripted array

[jv244 at cam dot ac dot uk]

------- Comment #5 from jv244 at cam dot ac dot uk  2008-08-08 20:39 -------
has J3 judged the testcase ?


-- 


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

[Bug fortran/34805] defined assignment not allowed to vector subscripted array

[dick dot hendrickson at gmail dot com]

------- Comment #6 from dick dot hendrickson at gmail dot com  2008-08-12 18:27 -------
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.
>


-- 


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

[Bug fortran/34805] Better error message for: defined assignment not allowed to vector subscripted array

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2008-09-10 12:09 -------
> 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.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2008-09-10 12:09:19
               date|                            |
            Summary|defined assignment not      |Better error message for:
                   |allowed to vector           |defined assignment not
                   |subscripted array           |allowed to vector
                   |                            |subscripted array


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