------- 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
<[EMAIL PROTECTED]> 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

Reply via email to