Compatibility Setting?

[hweisberg]

We have some legacy code in which EQUIVALENCE reorders COMMON:

integer a(1), b(1), c(2)
common a, b
equivalence (a, c)

The CVF compiler assumes that this means that memory should be assigned like this:

---------------
| a(1) | b(1) |
| c(1) | c(2) |
---------------

However the legacy compiler assumed that memory should be assigned like this:

----------------------
| a(1) |      | b(1) |
| c(1) | c(2) |      |
----------------------

In other words the variable b should be moved so it doesn't overlap with c.

Is there a compatibility setting in CVF that would make it follow the latter assumption?

[Steven_L_Intel1]

No, and that would violate the rules of the Fortran standard in a particularly heinous way.

The current Intel Fortran compilers do something almost as bad - if you have:

REAL A
DOUBLE PRECISION B
COMMON A,B

they insert four bytes of padding before B. CVF (and the future ifort) have an option to do this, /align:dcommons, but it's a standards violation to do it by default.

In your case, the variables all have the same natural alignment and are already aligned, so it's improper for a compiler to move b at all.

Steve

[sgongola]

In the example you gave, CVF is doing the correct thing
and the legacy version may not be. At least, no compiler
I know would do this based on:
'variable b should be moved so it doesn't overlap with c'

You haven't given enough information describing the
situation. What is the legacy platform. Do you know the
compiler options used for it.

If your example had been:
integer*4 a(1), b(1)
integer*2 b(2)
then the b(1) offset might be because a(1) would be occupying 4 bytes.

If your compiler maintained hardware word alignment
than the legacy example could be an integer*4 b(1)
being forced to the word boundary position.
If that were the case, than specifying /align:commons
accomplishes this in CVF.

sol

[hweisberg]

You are right.

It's HP 1000 Fortran 77, and it behaves just like other compilers in this respect.

Sorry about that.