- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear experts,
I noticed this minor issue on module declaration in relation to ifort version 17.0.2 (I'll soon upgrade to version 19, so I don't know, if the problem is fixed in the head version). The following declaration is accepted:
module test2
integer, parameter :: namelen = 999 ! string buffer length
type derived_type
character(len=namelen) :: fname
end type derived_type
end module
whereas the following declaration is rejected
module test3
type derived_type
character(len=namelen) :: fname
end type derived_type
integer, parameter :: namelen = 999 ! string buffer length
end module
... with the error message :
test3.f90(5): error #6406: Conflicting attributes or multiple declaration of name. [NAMELEN]
integer, parameter :: namelen = 999 ! string buffer length
------------------------^
test3.f90(3): error #6219: This variable, used in a specification expression, must be a dummy argument, a COMMON block object, or an object accessible through host or use association. [NAMELEN]
character(len=namelen) :: fname
-------------------^
compilation aborted for test3.f90 (code 1)
... as far as I can read the Fortran standard, no requirement exist on the order of statements in the module specification section.
Best wishes, Asbjørn
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Asbjørn,
indeed, I can also not spot (in a quick glance on the module part of the standard) anything that would enforce an ordering, however, it is rather natural and makes life a lot easier for the front-end parser I suppose. All compilers that I can get my hands on (gfortran, ifort, PGI, NAG) flag your first example as an error.
Cheers,
Jürgen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There absolutely is an ordering in the standard! (emphasis mine):
A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. (F2018 10.1.11p6 (Specification expression)
This has nothing to do with modules - it's a restriction on declaration ordering that has been in the standard "forever".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Asbjørn,
From a draft version of the 2003 standard at https://wg5-fortran.org/N1601-N1650/N1601.pdf page 14 Table 2.1 it does state that parameter statements must come before derived type statements. Presumably I'm not misreading that!
Thanks,
Ben
Edit: looks like Steve beat me by a minute.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There isn't an ordering of the statements themselves. But in looking closer, the wording I quoted doesn't seem to apply, since it says "variables". In the context here, namelen is required to be a constant expression, which it is, but I'm not yet finding wording that requires a previous declaration of a named constant (PARAMETER). Still looking...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you looking for this?
Page 83 Section 5.1.2.10 of https://wg5-fortran.org/N1601-N1650/N1601.pdf
A named constant shall not be referenced unless it has been defined previously in the same statement, defined in a prior statement, or made accessible by use or host association
Apologies for not using the 2018 standard I do not have access- pretty sure this requirement has always been true.
Edit: Section 8.5.13 in 2018 draft from http://fortranwiki.org/fortran/show/Fortran+2018
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep - that will do it! The one place I didn't look! Thanks!

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page