Common Block and Local Constant With Same Name

Help
1

I believe I may have found a contradiction in the standard (albeit in an obsolescent feature).

In section 19.3.1 it says:

Identifiers of entities, other than statement or construct entities (19.4), in the classes

  1. named variables, named constants, …
    …

are local identifiers.

Within its scope, a local identifier of an entity of class (1) or class (4) shall not be the same as a global identifier
used in that scope unless the global identifier

  • …
  • is a common block name (19.3.2)
    …

Which would suggest that one can have a local constant with the same name as a common block. However, in Section 19.3.2 it specifically says:

A name that identifies a common block in a scoping unit shall not be used to identify a constant

Two compilers I tried allow a local variable with the same name as a common block, but not a constant. Clearly they have picked up the more explicit statement, but I think the previous statements conflict. Does anyone else have thoughts? Would this be worth an interp?

NOTE: I’m not suggesting anyone should be using common blocks anymore. I was working on some legacy code that had a common block and a local variable with the same name. The local variable could have just been declared as a constant, except that I ran into this restriction.

3

I don’t think it’s a contradiction, but I can see how it can be confusing. The first text you quote allows for a name to be visible for both a COMMON and a named constant. 19.3.2 says that if you do have a duplicate name, it is disambiguated by the syntax /common-name/ in a COMMON, BIND or SAVE statement.

This works in ifort:

integer, parameter :: foo = 3
common /foo/ x,y
print *, foo
end
1 Like
4

It has been suggested to me that neither of the sections I quoted are numbered constraints, and thus compilers are not obligated to diagnose and warn of such problems. Clearly Intel has chose not to, but I think that second statement is pretty clear, and your example violates it. I would be in favor of removing that restriction, if anybody else thinks it’s even worthwhile. As you said, the only other places that common names are allowed they are disambiguated, so the restriction seems unnecessary.

5

Hmm… I note that NAG Fortran doesn’t like my example. I’ll poke at this some more.

1 Like
6

On further review, 19.3.2p1 absolutely forbids a common block and a named constant to share a name. I was distracted by other words nearby, but “A name that identifies a common block in a scoping unit shall not be used to identify a constant or an intrinsic procedure in that scoping unit.” is unambiguous. I have filed a bug report with Intel.

4 Likes
7

Thanks for looking into it @sblionel, and for filing the bug report. However, the question still remains, does the text in 19.3.1 constitute a conflict with the text in 19.3.2?

8

No.19.3.1p1 describes classes of things that are local identifiers. p2 adds a restriction that a class (1) local identifier (includes named constants) can’t be the same as a global identifier, with a carve-out for common blocks (without binding labels), but keep in mind that class (1) has many other kinds of entities. 19.3.2 adds a further restriction that a common block can’t have the same name as a constant or intrinsic procedure.

As is often the case in the standard, you have to keep multiple things in your head at the same time to understand what it really says. You can’t look at text in isolation. Here, there is a progressive narrowing-down of the rules, with selective inclusions and exclusions. I read it wrong at first, hence my earlier reply.

9

I’m not certain I see exactly that interpretation, but as this is a bit complex section I’ll take your word for it. It’s such an unusual corner case, and I’ve already removed the common blocks from the code I encountered it in anyways, so it’s not really worth my time worrying about it. Thanks for the independent investigation.