compiler or programmer error?

[YertleTheTurtle]

The two attached files are a simplified example extracted from a larger program. They illustrate a puzzling problem, and I'm not sure if the compiler or the programmer is to blame.

If the second line in file eqtest.f90, notably

use texts, only : third, ler3

is omitted, both subroutines SUB1 and SUB2 run properly and both print out "first, second" as they should.

If that line is present, as in the example, SUB1 prints "first, first" and SUB2 prints "first, second".

SUB2 differs from SUB1 only in that it includes (in the ONLY list of the USE statement) reference to an array to which both printed variables are equivalenced.

So, is it necessary to include an equivalenced array in a USE statement when one needs to refer to a variable that is equivalanced to that array?

And why does the problem appear only when there is an independent reference to that module in the container?

Thanks for any insight.

[Jugoslav_Dujic]

Here lie the dragons (slightly paraphrased for easier reading):

[bash]character(len=ncharlen), dimension(3) :: totmes

equivalence (totmes(3),third)
equivalence (totmes(1),first)
equivalence (totmes(2),second)

character(len=ncharlen) :: first = 'first'
character(len=ncharlen) :: second = 'second'
character(len=ncharlen) :: third = 'third'

[/bash]

You are -- or seem to be -- assuming that EQUIVALENCE works in the order you would like it to. Namely, that the space for TOTMES is reserved first, then storage for FIRST associated with TOTMES(1), storage for SECOND associated with TOTMES(2) and finally storate for THIRD associated with TOTMES(3).

However, there's no guarantee that instantiation is in that order, and that FIRST, SECOND and THIRD are sorted in memory one after another, so that you may equivalence the TOTMES with all of them simultaneously (because array members must follow one another in memory by definition).

Thus, in my opinion, the code is illegal (in a way that compiler is not required to diagnose), and the compiler is "free to start World War III with it". I cannot give you the exact quote of the Standard's constraint though, so my analysis might be wrong.

I did note, though, that the compiler did "the right (i.e. desired) thing" with memory layout of variables in module Texts no matter how I ordered the declarations. The fact that Sub1 provided different answers depending on presence of USE might be of interest to Intel folks. So it might be both "compiler and programmer error".

[YertleTheTurtle]

Unfortunately, while creating the example posted (from a bigger program), I inadvertantly transposed some lines. Suppose that the equivalence statements occur in the order one might logically expect:

equivalence (totmes(1),first), (totmes(2),second), (totmes(3),third)

which is the way t hey appear in the real program.

That slays the dragons, and the original questions remain. You suggest that the presence of the USE statement that refers to "third" might be of interest to Intel folks. What about the reference to "totmes" in the USE statement of SUB2?

Does the standard require that if a variable in the ONLY list of a USE statement is referenced, there must be a separate reference to any variable to which it is equivalenced? That appears to be the conclusion to be drawn from this example. But if that is so, why did the compiler not flag it? If not so, why is that reference required in order for the program to work properly.

[Steven_L_Intel1]

Offhand, I don't see a programmer error here. I think the compiler is doing something wrong and will report it to the developers. What's very interesting is that if you step through sub1 and hover the mouse over "second", you see the value "second", but what gets assigned is "first". We had some issue with equivalenced module variables before but they were fixed. This may be related, however.

As far as the order of allocation goes, I don't think there's any assumption other than the choice of indexes into totmes, which defines the ordering.

Escalated as issue DPD200152021.

[YertleTheTurtle]

Hi:

Time passes and this issue has resurfaced.

When last discussed, this issue was "escalated" to the developers.

But my program still doesn't work, and adding ONLY to the USE statement, which fixed the problem in the
example last March, doesn't fix it in the big program.

Question: Has the "escalation" made it into the build version 650, and if not, when will it be available?

Thank you

[Steven_L_Intel1]

The bug has not yet been fixed - it is complex and not a simple fix. I can't predict when the fix will be availale. When there is news, I will let you know.