User account creation filtered due to spam.

Bug 34805 - Better error message for: defined assignment not allowed to vector subscripted array
Summary: Better error message for: defined assignment not allowed to vector subscripte...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2008-01-15 21:54 UTC by Dick Hendrickson
Modified: 2010-12-29 03:06 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-09-10 12:09:19


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2008-01-15 21:54:43 UTC
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
Comment 1 Tobias Burnus 2008-01-16 07:23:49 UTC
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
------^
Comment 2 Tobias Burnus 2008-01-16 16:34:46 UTC
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;
)
Comment 3 Dick Hendrickson 2008-01-16 20:07:29 UTC
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.
>
Comment 4 Paul Thomas 2008-03-31 19:22:32 UTC

> "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
Comment 5 Joost VandeVondele 2008-08-08 20:39:44 UTC
has J3 judged the testcase ?
Comment 6 Dick Hendrickson 2008-08-12 18:27:43 UTC
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.
>
Comment 7 Tobias Burnus 2008-09-10 12:09:18 UTC
> 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.
Comment 8 Daniel Franke 2010-12-29 03:06:28 UTC
(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.