Bug in Intel F95 for Linux?

[postaquestion]

I believe there is a bug in Intel f95 for linux, in the way it treats USE and USE ONLY statements referring to the same module. Your feedback form won't let me give reasons, saying it's too long.

test system: ~ 7 >cat test2uses.f90
module test_mod
real(kind(1d0)) :: x = -666
end module test_mod

program test2uses
call test1
contains
subroutine test1
USE test_mod
USE test_mod, ONLY: xrenamed => x
x = 666 ! line 17
print *,'kind(x) ==kind(1d0)?',kind(x) ==kind(1d0)
print *,'kind(x) ==kind(1.0)?',kind(x) ==kind(1.0)
print *,'kind(xrenamed)==kind(1d0)?',kind(xrenamed)==kind(1d0)
print *,'kind(xrenamed)==kind(1.0)?',kind(xrenamed)==kind(1.0)
end subroutine test1
end program test2uses

[Steven_L_Intel1]

If you really want to report what you think is a bug the correct place to do that is Intel Premier Support, not this forum and not a feedback form.

I don't see anything wrong with the way that our compiler handles your program. What do you think is wrong? What you have created is two local names for the module variable X. the ONLY clause is ignored because you have another use statement without an ONLY.

The standard says:

15 More than one USE statement for a given module may appear in a scoping unit. If one of the USE
16 statements is without an ONLY qualifier, all public entities in the module are accessible. If all the USE
17 statements have ONLY qualifiers, only those entities in one or more of the only-lists are accessible.

[Hirchert__Kurt_W]

I can't speak for the expectaions of the original poster, but I would expect the cummulative effect of those two USE statements to be the same as

USE test_mod, ONLY: xrenamed => x

As I understand it, this makes all the public entities in test_mod accessible in test1, but the variable x is made accessible as xrenamed and not as x. Thus, the references to x in test1 should be to an implicitly declared REAL local variable in test1.

It is possible to make x accessible under both names, but to have that result I believe you have to request that explicitly:

USE test_mod, ONLY: xrenamed => x, x

Disclaimer: Although I helped write these rules back when I was a member of J3, I have not been active in the work of J3 since my retirement, so it is possible that I've missed a recent interpretation or have forgotten some distinction that would make this case different.

[jimdempseyatthecove]

Hirchert,

The sample program had both

USE test_mod
USE test_mod, ONLY: xrenamed => x

The first statement exposes all variables (x in this case)

The second statement creates a symbolic alias (EQUIVALENCE) to a variable in the module without explicitly disclosing variables in the named module. Note, this does not mean permission to hide already disclosed variables.

Assume test_mod contained X, Y, Z. In the above two statements you would not expect the second statement to hide Y and Z. Therefore it should not hide X.

This leaves the question as to if "ONLY: xrenamed => x" isper specificationa rename or an equivalence. If the specification requires ex post facto rename then X would be hidden, if not then both variable names reference the same memory.

The IVF documentation reads:

If more than one USE statement for a given module appears in a scoping unit, the following rules apply:

• If one USE statement does not have the ONLY option, all public entities in the module are accessible, and any rename-lists and only-lists are interpreted as a single, concatenated rename-list.
  ...

Because the implementation issue of how the "ONLY: xrenamed => x" is performed the above rules are ambiguous as to what will happen.

Consider

USE test_mod, ONLY:aTemp => temp
USE test_mod, ONLY: bTemp => temp

If the above is valid and if both names aTemp and bTemp reference the module's temp variable then this implies "ONLY: xrenamed => x" isthe same as an EQUIVALENCE and therefore thefirst example in this post would require that X be visible as well.

Jim Dempsey

[Steven_L_Intel1]

I don't see how the rules are ambiguous. In Jim's example, there would be two local names for the module variable temp. This is allowed by the standard.

[Hirchert__Kurt_W]

Jim Dempsey-

Thank you for looking up the text of some of the rules I was too lazy to find. That text reaffirms the interpretation I provided in my previous post.

The first key to understanding this text is to recognize that the USE statements for a particular module in a particular scoping unit are interpreted collectively, not individually. The text you cited from the IVF documentation is either a direct quote or a close paraphrase of the language in the Fortran standard, and it tells you all of the lists are interpreted together. Thus, our example

USE test_mod
USE test_mod, ONLY: xrenamed => x

is interpreted as though the only-list on the second USE statement were made part of a rename list for the first USE statement, that is,

USE test_mod, xrenamed => x

This statement says that all of public entities of test_mod are to be made accessible in this scoping unit, that any other than x are to be made accessible with same local name (or identifier) as in test_mod, and that x is to be made accessible with the local name xrenamed. The rename does not hide the variable x; it merely changes the local name by which it is accessible.

Although there are other legitimate uses for this renaming feature, the original reason for putting it in the language was to allow a programmer to resolve name conflicts that might occur when using multiple modules. Imagine, for example, that we had a second module test_mod2 that also contained a variable named x, and that both modules were in precompiled libraries somewhere, so we don't have the option of renaming either x in its original module. The renaming feature allows us to write something like

USE test_mod, xrenamed => x
USE test_mod2

so if we later write a statement like

x = xrenamed + 1.0

it is unambiguous that x in this statement refers to the variable named x in module test_mod2. If the rename made the names xrenamed and x both names for x in test_mod, then x in this statement would still be ambiguous.

The reason for interpreting the USE statements collectively rather than individually, was to allow for the possibility that (especially with long descriptive names) this kind of conflict resolution might require a longer list of renames than could be expressed within the allowed number of continuations for a single USE statement.

Lastly, let me point out that although the relation between aTemp and bTemp in your last example is similar to wha t happens if they were EQUIVALENCEd, it is not "the same as" EQUIVALENCE. Storage association and USE association are two different concepts with different rules. The fact that x would have to be visible in order to EQUIVALENCE a local variable xrenamed to it is irrelevant to the rules for making xrenamed a local name for a the variable called x in test_mod. EQUIVALENCE only ensures that two variables have the same starting address in memory. If you want to share values, it is your responsibility to declare both variables with the same attributes (type, type parameters, size, etc.) In contrast, the rename in a USE statement makes the local name a name for the original entity, so it automatically has the same attributes and you aren't allowed to redeclare those attributes.

Does that make things any less ambiguous for you?

-Kurt H

P.S. Steve- Does either this post or my first post give you any insight into what the original poster was complaining about?

[john_harper]

Apology: I had misinterpreted the standard; Intel f95 is behaving correctly here.

John Harper

[Steven_L_Intel1]

Kurt, your explanation is good. John did not realize that the ONLY had no effect when there was another USE without the ONLY, but he does now.

I agree that what we have here is not like EQUIVALENCE ; it is multiple names for the same variable.