[pgfortran] equivalence error

I am trying to implement PGI support for the ALaDyn GitHub - ALaDyn/ALaDyn: A High-Accuracy PIC Code for the Maxwell-Vlasov Equations particle-in-cell code, using this branch: https://github.com/cenit/ALaDyn/tree/dev/cenit/pgi

Unfortunately I am stuck with this error:

PGF90-S-0310-Cannot EQUIVALENCE non-character and character in the specification part of a MODULE (ALaDyn\src\precision_def.F90)

The code builds and runs since a long time and without any problem with Intel compiler and also with Gfortran. I tried to move the code after the contains keyword, without any luck because it started complaining about variables not being in a COMMON module…
Is there any hint to fix the code without big rework?

Here is what Intel says about the equivalence data descriptor.

Note the behavior under ‘strict’ standard adherence is to not
allow the equivalence of character and non-character types.


Intel® Fortran lets you associate character and noncharacter entities, for example:
CHARACTER*1 char1(10)
REAL reala, realb
EQUIVALENCE (reala, char1(1))
EQUIVALENCE (realb, char1(2))

EQUIVALENCE statements require only the first subscript of a multidimensional array (unless the STRICT compiler directive is in effect). For example, the array declaration var(3,3), var(4) could appear in an EQUIVALENCE statement. The reference is to the fourth element of the array (var(1,2)), not to the beginning of the fourth row or column.

If you use the STRICT directive, the following rules apply to the kinds of variables and arrays that you can associate:

•If an EQUIVALENCE object is default integer, default real, double-precision real, default complex, default logical, or a sequenced derived type of all numeric or logical components, all objects in the EQUIVALENCE statement must be one of these types, though it is not necessary that they be the same type.

•If an EQUIVALENCE object is default character or a sequenced derived type of all character components, all objects in the EQUIVALENCE statement must be one of these types. The lengths do not need to be the same.

•If an EQUIVALENCE object is a sequenced derived type that is not purely numeric or purely character, all objects in the EQUIVALENCE statement must be the same derived type.

•If an EQUIVALENCE object is an intrinsic type other than the default (for example, INTEGER(1)), all objects in the EQUIVALENCE statement must be the same type and kind.


So you have a choice. Restrict yourself to the compilers that support
this extension, or choose to code in a manner that works on all compilers. Our experience is that restricting the compilers you use
is not a good idea, and the amount of time to rework the code to
adhere to a standard is not as much as you think.


totally agree with you regarding best practices and not restricting to few compilers.

As a side note, you were totally right also regarding the way to fix it. I still have some tests to do, but it looks like replacing




did the trick.