public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/64678] New: Expected association error on dependent associate statements
@ 2015-01-20 0:09 antony at cosmologist dot info
2015-01-20 1:45 ` [Bug fortran/64678] " kargl at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: antony at cosmologist dot info @ 2015-01-20 0:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/64678] Expected association error on dependent associate statements
2015-01-20 0:09 [Bug fortran/64678] New: Expected association error on dependent associate statements antony at cosmologist dot info
@ 2015-01-20 1:45 ` kargl at gcc dot gnu.org
2015-01-20 2:11 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: kargl at gcc dot gnu.org @ 2015-01-20 1:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/64678] Expected association error on dependent associate statements
2015-01-20 0:09 [Bug fortran/64678] New: Expected association error on dependent associate statements antony at cosmologist dot info
2015-01-20 1:45 ` [Bug fortran/64678] " kargl at gcc dot gnu.org
@ 2015-01-20 2:11 ` dominiq at lps dot ens.fr
2015-01-24 12:00 ` antony at cosmologist dot info
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-01-20 2:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/64678] Expected association error on dependent associate statements
2015-01-20 0:09 [Bug fortran/64678] New: Expected association error on dependent associate statements antony at cosmologist dot info
2015-01-20 1:45 ` [Bug fortran/64678] " kargl at gcc dot gnu.org
2015-01-20 2:11 ` dominiq at lps dot ens.fr
@ 2015-01-24 12:00 ` antony at cosmologist dot info
2015-01-24 12:15 ` dominiq at lps dot ens.fr
2015-01-24 14:05 ` anlauf at gmx dot de
4 siblings, 0 replies; 6+ messages in thread
From: antony at cosmologist dot info @ 2015-01-24 12:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/64678] Expected association error on dependent associate statements
2015-01-20 0:09 [Bug fortran/64678] New: Expected association error on dependent associate statements antony at cosmologist dot info
` (2 preceding siblings ...)
2015-01-24 12:00 ` antony at cosmologist dot info
@ 2015-01-24 12:15 ` dominiq at lps dot ens.fr
2015-01-24 14:05 ` anlauf at gmx dot de
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-01-24 12:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/64678] Expected association error on dependent associate statements
2015-01-20 0:09 [Bug fortran/64678] New: Expected association error on dependent associate statements antony at cosmologist dot info
` (3 preceding siblings ...)
2015-01-24 12:15 ` dominiq at lps dot ens.fr
@ 2015-01-24 14:05 ` anlauf at gmx dot de
4 siblings, 0 replies; 6+ messages in thread
From: anlauf at gmx dot de @ 2015-01-24 14:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-01-24 14:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-20 0:09 [Bug fortran/64678] New: Expected association error on dependent associate statements antony at cosmologist dot info
2015-01-20 1:45 ` [Bug fortran/64678] " kargl at gcc dot gnu.org
2015-01-20 2:11 ` dominiq at lps dot ens.fr
2015-01-24 12:00 ` antony at cosmologist dot info
2015-01-24 12:15 ` dominiq at lps dot ens.fr
2015-01-24 14:05 ` anlauf at gmx dot de
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).