Incorrect padding added for SEQUENCE or BIND(C) type with UNION


Reference Number : DPD200138527


Version : 11.1


Product : Intel® Fortran Compiler


Operating System : All

Problem Description : If a derived type is declared containing a UNION, and the type is a SEQUENCE type or is interoperable (BIND(C)), and the UNION contains a misaligned field, the compiler incorrectly adds padding bytes before each misaligned field.

UNION is an extension to the Fortran standard, supported by Intel Fortran, that allows the declaration of overlapping sets of derived type components. A SEQUENCE type is a derived type containing the SEQUENCE keyword. The Fortran standard specifies that components of a SEQUENCE type may not be rearranged by the compiler; in Intel Fortran, SEQUENCE types do not, by default, have alignment padding added before misaligned components. (This can be overridden with the "align sequence" option.) Lastly, an interoperable derived type, declared with the BIND(C) specifier, is required to have its components laid out exactly as the companion C processor would do it - this may involve padding if the C processor would pad by default.

Consider the following declaration:

type :: mytype
  sequence
  integer(2) f1
  union
   map
     integer(2) xa1
     integer(4) xa2
     integer(2) xa3
     integer(4) xa4
   end map
   map
     integer(4) xb1
     integer(2) xb2
     integer(4) xb3
     integer(2) xb4
   end map
  end union
end type mytype

Because the first component, f1, is two bytes long, the UNION starts at offset 2. (Remember that SEQUENCE disables padding in Intel Fortran.) This would make components xa1 and xb1 begin at offset 2, causing xb1 to be misaligned, since 2 is not an integral multiple of its size, 4. Components xa2 and xa3 are naturally aligned and should begin at offsets 4 and 8.  xb2 is misaligned at offset 6.

Because of a defect, the compiler incorrectly inserts padding before each misaligned variable inside the UNION.  The following table shows the offsets for each component, with and without the defect:

ComponentWith DefectCorrect
f100
xa142
xa284
xa3128
xa41610
xb142
xb286
xb3128
xb41612
f22014

Note that f2 is (correctly) misaligned in both cases, and that xb4 received an additional two bytes of padding - the inappropriate padding happens only within the UNION.

Resolution Status : This error is corrected in compiler updates 11.1 Update 5 or later release. As a workaround in older releases enclose the TYPE declaration in the following directives:

 

!DEC$ OPTIONS /NOALIGN /NOWARN
... TYPE goes here
!DEC$ END OPTIONS
You can also compile with the "noalign" compiler option.

 

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

For more complete information about compiler optimizations, see our Optimization Notice.