Problem of variable redeclaration in ifortran

Problem of variable redeclaration in ifortran

Hallo,
When the following code is compiled:
--- code of bazfoo.f90 ---
MODULE baz
IMPLICIT NONE
PRIVATE
LOGICAL, EXTERNAL :: bar
PUBLIC :: bar
END MODULE baz

MODULE foo
USE baz, ONLY: foobar => bar
IMPLICIT NONE
PRIVATE
PUBLIC :: foobar
END MODULE foo

--- I got errors: ---
ifort -c bazfoo.o bazfoo.f90
bazfoo.f90(12): error #6658: This entity cannot have a PUBLIC/PRIVATE attribute assigned to it. [FOOBAR]
PUBLIC :: foobar
------------^

Can anyone help? Thanks

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I'd have to check the Standard on this, but intuitively I believe the compiler is correct. When you create an alias for a module variable it does not make sense for you to be able to change it's PUBLIC/PRIVATE attribute for the original object. The alias should inherit the attributes of the original object.

I will check the Standard, I'm sure there is something there to back up my intuition.

ron

this is an interesting one.

Why do you declare that variable EXTERNAL ?? Without that, you will not have a problem:

The local identifier of an entity made accessible by a USE statement shall not appear in any other
31 nonexecutable statement that would cause any attribute (5.1.2) of the entity to be specified in the
32 scoping unit that contains the USE statement, except that it may appear in a PUBLIC or PRIVATE
33 statement in the scoping unit of a module and it may be given the ASYNCHRONOUS or VOLATILE
34 attribute.

35 The appearance of such a local identifier in a PUBLIC statement in a module causes the entity accessible
36 by the USE statement to be a public entity of that module. If the identifier appears in a PRIVATE
37 statement in a module, the entity is not a public entity of that module. If the local identifier does not
38 appear in either a PUBLIC or PRIVATE statement, it assumes the default accessibility attribute (5.2.1)

I cannot find anything in the Standard that would prevent this usage. EXTERNAL is the trigger causing the error, but although unusual, there is nothing in the Standard to prevent this attribute.

bug report is DPD200173930

we will inform you when a fix is available.

ron

this bug is fixed in all current 13.x compilers.

closing this issue now.

ron

Leave a Comment

Please sign in to add a comment. Not a member? Join today