Allocattable and namelist object
steve
Someone has reported a bug against gfortran that suggests that
following code is legal Fortran 2003.
PROGRAM MAIN
REAL, DIMENSION(:), ALLOCATABLE :: TAB
NAMELIST/TOTO/TAB
END PROGRAM MAIN
Gfortran currently issues an error in accordance with a
constraint in Fortran 95:
F95, Sec 5.4, p. 66
Constraint:
A namelist-group-object shall not be an array dummy
argument with a nonconstant bound, a variable with
nonconstant character length, an automatic object,
a pointer, a variable of a type that has an ultimate
component that is a pointer, or an allocatable array.
In checking the Fortran 2003 standard, the above constraint
has been removed. Further searching leads to two passages
that appear to be in conflict.
F2003, Sec. 5.4, p. 95
A namelist group object shall either be accessed by use
or host association or shall have its type, type parameters,
and shape specified by previous specification statements or
the procedure heading in the same scoping unit or by the
implicit typing rules in effect for the scoping unit.
F2003, Sec. 9.5.3.6,
Every allocatable namelist-group-object in the namelist group
shall be allocated and every namelist-group-object that is a
pointer shall be associated with a target.
The statement from Sec. 5.4 states that a "namelist group object
... shall have its type, type parameters, and shape specified
by previous specification statements". In the above code, the
shape has not been specified prior to the namelist statement.
However, the statement from Sec. 9.5.3.6 suggests that an allocatable
array can be in a namelist object.
Are these statements in conflict or am I missing some other
part of the Fortran 2003 standard?
--
steve
Richard Maine
> Someone has reported a bug against gfortran that suggests that
> following code is legal Fortran 2003.
>
> PROGRAM MAIN
> REAL, DIMENSION(:), ALLOCATABLE :: TAB
> NAMELIST/TOTO/TAB
> END PROGRAM MAIN
>
> Gfortran currently issues an error in accordance with a
> constraint in Fortran 95:
>
> F95, Sec 5.4, p. 66
>
> Constraint:
> A namelist-group-object shall not be an array dummy
> argument with a nonconstant bound, a variable with
> nonconstant character length, an automatic object,
> a pointer, a variable of a type that has an ultimate
> component that is a pointer, or an allocatable array.
That seems pretty explicit, but I think we all agree on that.
> In checking the Fortran 2003 standard, the above constraint
> has been removed. Further searching leads to two passages
> that appear to be in conflict.
>
> F2003, Sec. 5.4, p. 95
>
> A namelist group object shall either be accessed by use
> or host association or shall have its type, type parameters,
> and shape specified by previous specification statements or
> the procedure heading in the same scoping unit or by the
> implicit typing rules in effect for the scoping unit.
>
> F2003, Sec. 9.5.3.6,
>
> Every allocatable namelist-group-object in the namelist group
> shall be allocated and every namelist-group-object that is a
> pointer shall be associated with a target.
>
> The statement from Sec. 5.4 states that a "namelist group object
> ... shall have its type, type parameters, and shape specified
> by previous specification statements". In the above code, the
> shape has not been specified prior to the namelist statement.
> However, the statement from Sec. 9.5.3.6 suggests that an allocatable
> array can be in a namelist object.
>
> Are these statements in conflict or am I missing some other
> part of the Fortran 2003 standard?
I'd probably interpret it as that the shape was specified prior to the
namelist statement. It was specified to be deferred shape. I'm not sure
that the wording is great; it strikes me as wording from the prior
standard that perhaps didn't get changed to reflect other changes. But I
can at least twist my mind to read it that way. No other reading makes
any sense to me at all, as it is just nonsense to say that any
allocatable arrays have to be allocated, but then also say that you
can't have allocatable arrays. The shape of an allocatable array can
never be specified in a specification statement to be anything other
than deferred.
Which is to say that I'd consider the code to be legal f2003, although
illegal f95, based on th eabove citations. (I was to lazy to actually
check your citations, but they seem plausible.)
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
steve
Richard,
Thanks for the comment. I had not thought about such an
interpretation.
In the definition of a deferred-shaped array one finds:
5.1.2.5.3 Deferred-shape array
A deferred-shape array is an allocatable array or an
array pointer.
An allocatable array is an array that has the ALLOCATABLE
attribute and a specified rank, but its bounds, and hence
shape, are determined by allocation or argument association.
I would interpret this to mean that the deferred-shape array
does not have a specified shape in the code I posted. Hence,
the two statements in F2003 are contradictory.
The current draft of F2008 is even more convincing that there
is a problem. The language from Sec. 5.4 in the F95 and F2003
standards is idenitical to the language in F2008. F2003 however
has revised the definition of deferred-shape array to include
5.3.8.4 Deferred-shape array
3 The size, bounds, and shape of an unallocated allocatable
array or a disassociated array pointer are undefined.
No part of such an array shall be referenced or defined;
however, the array may appear as an argument to an
intrinsic inquiry function as specified in 13.1.
I guess I need to look into getting an official interpretation.
--
steve
Richard Maine
> I guess I need to look into getting an official interpretation.
Possibly so. Though I'm moderately certain that the answer would say
that the code in question was legal f2003. I'm not nearly as certain (in
fact, I hesitate to even guess) whether that answer would be justified
by sufficiently twisted interpretation of the existing words, or whether
it was concluded that the existing words needed to be fixed. But I have
trouble imagining that the answer would involve any variant of "we just
wrote stuff about allocatable arrays in namelist by accident; you can't
really have them." Admitedly, things beyond my imagination have been
known to happen - some of them stranger than that.
steve
> steve <kar...@comcast.net> wrote:
> > I guess I need to look into getting an official interpretation.
>
> Possibly so. Though I'm moderately certain that the answer would say
> that the code in question was legal f2003. I'm not nearly as certain (in
> fact, I hesitate to even guess) whether that answer would be justified
> by sufficiently twisted interpretation of the existing words, or whether
> it was concluded that the existing words needed to be fixed. But I have
> trouble imagining that the answer would involve any variant of "we just
> wrote stuff about allocatable arrays in namelist by accident; you can't
> really have them." Admitedly, things beyond my imagination have been
> known to happen - some of them stranger than that.
Tobias beat me to an interp request. He sent Van email last night.
--