conflicting equivalence

This snippet of code:

integer :: ntime, na, nb, nc, nd, ne, nf, ng
integer :: dimlens(8)
equivalence (dimlens(1),ntime), (dimlens(2)),na), (dimlens(3),nb), &
(dimlens(4),nc), (dimlens(5),nd), (dimlens(6),ne), &
(dimlens(7),nf), (dimlens(8),ng)

compiles and runs just fine in a test code I am working on. But when I put it into the real code I need to run, compilation fails with the error:

Conflicting equivalence between dimlens and ntime.

Other variations of this code produce similar but different errors.

You’re probably wanting me to say what the difference is between the test code and the real code. Suffice it to say there are no added equivalences, so there can’t be any conflict introduced in that way. (This is for work, and there are only so many details I can give.)

So, what might the problem be, and why would it be a problem for one code but not for all?

Thanks.

Hi Cablesb,

We do see a typo in your code that might be causing the problem:

equivalence (dimlens(1),ntime), (dimlens(2)),na), (dimlens(3),nb), &
                                          ^^ extra )

Maybe the typo only appears in the production version of the code?

  • Mat

Good eye! Thanks for checking. Upon review, that typo was only in my post to the forum, not in the original code. So that’s not it. Much obliged anyway. Any other ideas are most welcome!

The only other thing we could think of is maybe where the data is being stored. In one case on the stack (default if -mp is used) and in the other in BSS. Can you try adding the “SAVE” attribute to these variables?

Unfortunately, without a reproducing example, it’s very difficult to know what’s going on.

  • Mat

Well, added the SAVE attribute to all the individual variables and to the dimlens array. Sorry, but the result is the same. Thanks for the idea. Appreciate any more you might have. This is not critical. There are workarounds that don’t use EQUIVALENCE, but it would have been nice.