Allocattable and namelist object
in [Fortran]
|
Prev: destructor advice in F2003
Next: How to pass function names as arguments when function returns an array?
From: steve on 14 Feb 2010 15:50 All, 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
From: Richard Maine on 14 Feb 2010 16:34 steve <kargls(a)comcast.net> wrote: > 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
From: steve on 14 Feb 2010 17:55 On Feb 14, 1:34 pm, nos...(a)see.signature (Richard Maine) wrote: > steve <kar...(a)comcast.net> wrote: > > 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, 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
From: Richard Maine on 14 Feb 2010 18:25 steve <kargls(a)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. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: steve on 17 Feb 2010 11:37
On Feb 14, 3:25 pm, nos...(a)see.signature (Richard Maine) wrote: > steve <kar...(a)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. -- |