- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I saw discussions on this topic already on c.l.f. I am having the following subroutine (and the recursive attribute doesn't play a role)
recursive function constr_quark_loopline(ho,sho) result(cl) integer, dimension(sho), intent(in) :: ho integer, dimension(sho) :: hor integer, intent(in) :: sho [...] end function constr_quark_loopline
Intel gives an error message error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name. [SHO]
in the case this is an external procedure, or a module procedure with or without 'implicit none' in the head of the module.
First of all, I would like to get it confirmed that this is really a contradiction of the standard, and that the order of the declarations matters. In case this is a module procedure without implicit none or an external procedure, implicit typing rules apply and sho would be considered to be a real, such that later specifying it as an integer is a contradiction. gfortran and nagfor complain:
integer, intent(in) :: sho
1
Error: Symbol ‘sho’ at (1) already has basic type of REAL
and
Error: rec.f90, line 8: Symbol SHO has already been implicitly typed
detected at SHO@<end-of-statement>
The strange thing (which seems a compiler bug to me) is that gfortran compiles this code when it is a module procedure with 'implicit none'. This seems a (gfortran) compiler bug to me. Comments are appreciated.
And yes, of course, I know that having the declaration of sho first solves all the problems, but this is 3rd-party code.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is one aspect where compilers are (in my opinion, correctly so) tightening up on enforcing the rules of the standard. The following is a quotation from document 10-027 (F2008), Section 7.1.11, Specification expression:
3 7 A variable in a specification expression shall have its type and type parameters, if any, specified by a previous4 declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use5 association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any6 subsequent type declaration statement shall confirm the implied type and type parameters.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The dimension specifications are specification expressions. There are declaration ordering restrictions on specification expressions (and constant expressions) that are being violated here, that the program must follow, but which may not necessarily be diagnosed by a compiler - see F2008 7.1.11p7.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
gfortran has an extension where it allows you to violate the standard's rules for declaration order in specification expressions. Intel Fortran doesn't have that extension (and the team was adamant that it was not going to add it, which I agreed with.) I am sure that gfortran would give you a complaint if you enabled standards checking.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, you are right. Indeed, with -std=f2008 also gfortran throws an error for a module procedure within implicit none and flags it as a GNU extension.

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