#6375: Because of COMMON, the alignment of object is inconsistent with its type

[PRADEEP_KUMAR_P_]

I have one of a very common issue. But I am not sure why it happens this time. 

Warning #6375: Because of COMMON, the alignment of object is inconsistent with its type

THE DECLARATION IS DONE WITH CARE. BUT STILL THE PROBLEM PERSISTS. I KINDLY SEEK EXPERTS AND FRIENDS ADVICE ON THIS REGARD. 

-PRADEEP

[TimP]

Apparently, you didn't follow the traditional rule of placing all 64 bit data types ahead of 32 bit data, followed by smaller types.

[LRaim]

the compiler tells you the misaligned variable. consider the first one and go through the list

[Steven_L_Intel1]

If you show us the declarations of the variables in your COMMON, we can give more detailed advice.  Alignment is a performance issue - your program will still run correctly but will be slower than if the variables were correctly aligned. Alignment means that the byte offset from the start of the COMMON is a multiple of the data type size. For example, single precision real at a multiple of 4, double precision at a multiple of 8, etc.

For example, if I assume that KK is INTEGER(4) and P is REAL(8), the compiler would give you this warning because P starts at an offset of 4.

The general advice is to put your largest datatype variables first in the COMMON, followed by the smaller ones. CHARACTER variables should go at the end. If you don't want to do this, rearrange the variables so that the alignment comes out right (for example, two INTEGER(4) variables is 8 bytes, so a REAL(8) could follow those.)

[PRADEEP_KUMAR_P_]

Steve, 
In Main : 
           COMMON /PARAM2/  KK, P, RU, WT(50), WDOT(50), H(50)

In SubRoutine :
            COMMON /PARAM2/  KK, P, RU, WT(50), WDOT(50), H(50)
and by placing in separate lines worked. 
 

[Steven_L_Intel1]

What are the declarations of the individual variables? Or are you using implicit typing? If so, what is your IMPLICIT statement?

Your COMMON declaration should be identical in all routines - typically one puts them in an INCLUDE file. The two lines you showed are identical (except for spacing). What do you mean by "placing in separate lines"?

[Steven_L_Intel1]

I have expanded our online documentation of this diagnostic.

[jimdempseyatthecove]

Consider using:  COMMON /PARAM2/  P, RU, WT(50), WDOT(50), H(50), KK

In all places where you declare COMMON /PARAM2/.

A header file would be best. Do NOT forget to define the types in the header file. Using IMPLICIT and compiling one file with default real(4) and a different file with default real(8) would cause the commons to differ (though having the same name).

Jim Dempsey

[dboggs]

Because of the modern practice of replacing COMMON blocks with modules, it would be useful to extend this discussion even more to include that context. Does the order of the variables declared in a module matter? Does alignment apply there as well? I suspect not because, as I understand it, the order you get may not even be the order you "asked" for. Are there performance issues, or does the compiler automatically move things around to yield good performance?

There are cases where I DO need the variables to be in a particular order, such as the old technique of writing all of the COMMON variables to a file quickly by specifying only the first element and writing the next X-many bytes. This I can do by specifying ALIGN. But if I do this am I at risk of introducing bad alignment--and thus possible performance hits--throughout my program?

[Steven_L_Intel1]

Module variable declaration order has no effect. You have no control over the storage order of module variables and should make no assumptions about relative layout.

[John_Campbell]

Another quick patch for all declarations of /param2/ could be the following, providing a packing integer to make up the 8 bytes.

 COMMON /PARAM2/  KK, KKK, P, RU, WT(50), WDOT(50), H(50)

what if integer(2) KK ? although the warning is fairly clear if you know the byte length of all variables.

[PRADEEP_KUMAR_P_]

@All : Thanks All for your kind support. It worked. 
Ii have declared integer and real common variables into two different sections and it worked after that.