[Bug fortran/64678] New: Expected association error on dependent associate statements

[Bug fortran/64678] New: Expected association error on dependent associate statements

[antony at cosmologist dot info]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678

            Bug ID: 64678
           Summary: Expected association error on dependent associate
                    statements
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: antony at cosmologist dot info

In trunk

module X
  Type T
   integer :: map
  end Type T
contains

subroutine DoBug
Type(T) TT

 associate(A=>TT, B=>A%map)
 end associate

end subroutine
end module X

gives:

testbug.f90:10:17:

  associate(A=>TT, B=>A%map)
                 1
Error: Expected association at (1)
testbug.f90:11:4:

  end associate
    1

It's not entirely clear to me from the standard if this is allowed, but I don't
see why not (useful when you are breaking up complicated array/class structures
into associate names, where the second name refers to the first). It compiles
in ifort. Obviously low priority as can be worked around easily enough

[Bug fortran/64678] Expected association error on dependent associate statements

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Antony Lewis from comment #0)
> In trunk
> 
> module X
>   Type T
>    integer :: map
>   end Type T
> contains
> 
> subroutine DoBug
> Type(T) TT
>   
>  associate(A=>TT, B=>A%map)
>  end associate
>   
> end subroutine
> end module X
> 
> gives:
> 
> testbug.f90:10:17:
> 
>   associate(A=>TT, B=>A%map)
>                  1
> Error: Expected association at (1)
> testbug.f90:11:4:
> 
>   end associate
>     1
> 
> It's not entirely clear to me from the standard if this is allowed, but I
> don't see why not (useful when you are breaking up complicated array/class
> structures into associate names, where the second name refers to the first).
> It compiles in ifort. Obviously low priority as can be worked around easily
> enough

I believe gfortran is correct in issuing an error; although I admit
it seems to be a subtle distinction in language.  For F2003 standard

  8.1.4  ASSOCIATE construct

  The ASSOCIATE construct associates named entities with expressions
  or variables during the execution of its block. These named construct
  entities (16.3) are associating entities (16.4.1.5).  The names are
  associate names.

The BNF shows

  R818   association   is   associate-name => selector
  R819   selector      is   expr
                       or   variable


In your code, 'A' and 'B' are associate-names.  The target
of an associate-name is a selector, which is an expr or variable.
The target for 'B' is 'A%map'.  So, the question becomes whether 'A%map'
is now a variable or expression even though 'A' is an associate-name.

The BNF for 'variable is

  R601 variable                  is designator
  C601 (R601) designator shall not be a constant or a subobject of a constant.
  R602 variable-name             is  name
  C602 (R602) A variable-name shall be the name of a variable.
  R603 designator                is object-name
                                 or array-element
                                 or array-section
                                 or structure-component
                                 or substring

  R505 object-name     is   name
  C505 (R505) The object-name shall be the name of a data object.

  A data object (often abbreviated to object) is a constant (4.1.2),
  a variable (6), or a subobject of a constant. The type and type
  parameters of a named data object may be specified explicitly (5.1)
  or implicitly (5.3).

'A%map' as a data object is certainly not a constant or subobject of
a constant, so it must be a variable.  But, we've already established
that 'A' is an associate-name not a variable-name.  So, 'A%map' is
not an object-name.

array-element, array-section, and substring are of no consequence here.

So, now, structure-component

  R614 structure-component is data-ref

  R612 data-ref is part-ref [ % part-ref ] ...
  R613 part-ref is part-name [ ( section-subscript-list ) ]

  C612 (R612) The leftmost part-name shall be the name of a data object.

We've already established 'A' is not a data object.  So, now we
are left with 'expr'.  I have no interest in reproducing Section 7
of Fortran 2003 standard.  I suspect you'll find that 'A%map' is not
an 'expr'.

Note, I could be wrong.  You may want to post to comp.lang.fortran.
There are numerous people, who contribute to c.l.f, that are much
more in-tune with the nuances of the Fortran standard.

[Bug fortran/64678] Expected association error on dependent associate statements

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-20
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I am not sure to understand the standard legaleses, but

 associate(A=>TT)
 associate(B=>A%map)
 end associate
 end associate

is accepted.

[Bug fortran/64678] Expected association error on dependent associate statements

[antony at cosmologist dot info]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678

--- Comment #3 from Antony Lewis <antony at cosmologist dot info> ---
Indeed, that's the easy workaround. I'd have thought the obvious definition for
the single multi-associate statement would be to be a shortcut exactly
equivalent to nested associates.

[Bug fortran/64678] Expected association error on dependent associate statements

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Indeed, that's the easy workaround. I'd have thought the obvious definition
> for the single multi-associate statement would be to be a shortcut exactly
> equivalent to nested associates.

In my mind it was not a workaround. From what I understand (little) of the
Kargl's comment 1, the two forms should be either rejected or accepted.

[Bug fortran/64678] Expected association error on dependent associate statements

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #5 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Dominique d'Humieres from comment #4)
> > Indeed, that's the easy workaround. I'd have thought the obvious definition
> > for the single multi-associate statement would be to be a shortcut exactly
> > equivalent to nested associates.
> 
> In my mind it was not a workaround. From what I understand (little) of the
> Kargl's comment 1, the two forms should be either rejected or accepted.

I tried NAG, PGI and xlf.  All of them accept the 'nested' version,
but only PGI accepts the original code.

xlf 14:

"pr64678.f90", line 10.22: 1514-091 (S) Invalid structure component reference. 
The object name and all component names (except the rightmost) must be of type
derived.

NAG 6:

NAG Fortran Compiler Release 6.0(Hibiya) Build 1032
Product NPL6A60NA for x86-64 Linux
Copyright 1990-2014 The Numerical Algorithms Group Ltd., Oxford, U.K.
f95comp version is Hibiya(6.0) Build 1032
Error: pr64678.f90, line 10: A is not of derived type
       detected at %@MAP

So I think Steve has pointed into the right direction.
Nevertheless, consider posting your code on c.l.f.