Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29004 Discussions

relative ordering of LOGICAL and LOGICAL*1 in common blocks

jayb
Beginner
340 Views

As I've started several posts:  "I've got this legacy application . . ."

Among its many "remarkable" features is the use of LOGICAL*1 to store characters on occasion.  I will change those to CHARACTER as soon as the original author is ready is make that jump.  But for now, here is my puzzle.

The code does not pay much attention to alignment of common blocks, and Intel Fortran warns about this.   But it looks like the compiler wants LOGICAL to be placed before LOGICAL*1 even though (I think) the former takes up a bit, and the latter a byte.  A small example:

The following generates warnings:

      SUBROUTINE SOMETHING

      INTEGER INT1

      LOGICAL*1 BYTE1

      LOGICAL LOG1,LOG2

      COMMON /MY_COMMON/ INT1,BYTE1,LOG1,LOG2

      END

 

ddtest.for(4): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact.   [LOG1]

      LOGICAL LOG1,LOG2

--------------^

ddtest.for(4): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact.   [LOG2]

      LOGICAL LOG1,LOG2

-------------------^

 

while the following is accepted:

      SUBROUTINE SOMETHING

      INTEGER INT1

      LOGICAL*1 BYTE1

      LOGICAL LOG1,LOG2

      COMMON /MY_COMMON/ INT1,LOG1,LOG2,BYTE1

      END

 

JayB

 

0 Kudos
1 Reply
Steven_L_Intel1
Employee
340 Views

LOGICAL is 4 bytes, LOGICAL*1 is 1 byte. Fortran has no bit types.

The alignment warnings are for performance - you can disable them if they bother you by bracketing the COMMON with:

!DIR$ OPTIONS /WARN=NOALIGNMENT
...
!DIR$ END OPTIONS

In your second case, BYTE1 is at the end and therefore nothing is misaligned. The other variables in the COMMON are 4-bytes each.

0 Kudos
Reply