help interprt a Linker warning for alignment

help interprt a Linker warning for alignment

I have some code that runs fine and doesn't give any warnings using parallel studio XE2011 (or under that version on windows). But under parallel studio XE2013 update3 it give this warning:
ld: Warning: alignment 16 of symbol `hshdt_' in /home/steve/Documents/SF5.6/lib/proces.a(blkdat.o) is smaller than 32 in /tmp/ifortpmrpmh.o
ld: Warning: alignment 16 of symbol `flonm6_' in /home/steve/Documents/SF5.6/lib/proces.a(blkdat.o) is smaller than 32 in /tmp/ifortpmrpmh.o

I see under windows and using XE2011 it aligns these using 32 bytes.  But the common blocks are only 16 bytes long.  Under 2011 the map gives

                0x0000000000cdd1f0                droot_find0_
                0x0000000000cd6b80                hstdt8_
                0x0000000000cdd2c0                hpxloc_
                0x0000000000cd6b70                hshdt_
                0x0000000000cdd300                svredb2_

(not sure why they are not ordered sequentially ) where you can see hstdt8 is 16 bytes after hshdt.  I'm not sure what problem this might cause, or what exactly would be the best fix for it (if one is needed).

All compiles use REAL_SIZE and INTEGER_SIZE 64.  We don't declare anything that is 128 bits long. 


8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Check whether you need to rebuild the library process.a from sources using the new compiler to make the alignment warnings go away. If the routines in the library contain the common block, and those were compiled with the old compiler, and your newly compiled code has the same common blocks but with different alignment, the linker could issue the warnings.

Thanks for the input.  But we are trying to maintain compatibility with all customers by using one compiler to build the libraries and allowing customers who do not upgrade to continue to use newer releases of our code.  Libraries have been able to be used by new compilers for quite a few years now (on Windows many still use 11.1) so we don't want to force anyone to upgrade, and we don't really like to have to provide multiple versions.

So my question based on your answer does this mean the users can't use XE2013 to link with XE2011 libraries?  Is this a known change in the compiler that breaks backwards compatibility? 

I also still don't understand what error is likely to occur based on the alignment?

The compiler provides the -align,..,.. option to control the alignment of routines in the code segment and the alignment of common blocks in the data segment. Data alignment affects efficiency, and if the SEQUENCE attribute has not been used, the compiler is allowed to insert padding in order to make the data access more efficient.

With the following program, I found that two versions of the Intel compiler produced slightly different assembler outputs.

program comnalign
integer i,j,k
double precision x,y
common /cmn/i,j,x,k,y


call sub()
write(*,*) x,y
end program comnalign

subroutine sub
integer i,j,k
double precision x,y
common /cmn/i,j,x,k,y

The newer compiler said:

cmn.f90(3): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential  performance impact.   [Y]

You may compile this example or your code with the /align:qcommons switch to see if the option can resolve your issues.

The beginning alignment of COMMON blocks was set to 32-byte alignment in 2013 to be able to interoperate with MIC better.

That will not be affected by the -align:xxx switches.  These switches affect the alignment between entities within a COMMON block.

Are you seeing a failure, or "just" the linker warnings?


We were told well after introduction of composer2013 there was no provision for 32-byte alignment of commons, so this news is interesting. We had been told that an effort was underway to make -align array32byte apply to the start address of common blocks, so we had to remove use of common blocks to achieve alignment. I see the change is confirmed indirectly by the documentation. 

According to the current documentation, -align qcommons inserts padding to achieve 16-byte alignment of data within the common block, and -align zcommons supports padding to 32-byte alignment.  Evidently, the latter would not work if the beginning of common were not 32-byte aligned.  It would not inter-operate with objects compiled by earlier compiler releases, even if the traditional rule about placing objects in common in decreasing KIND order were followed.  Needless to say, options to add padding inside commons would break things if the various declarations of commons were inconsistent even though conforming to standard.

If I understand the documentation, SEQUENCE prevents -align from taking effect in a common block, unless -align sequence is set also, which would cause SEQUENCE to be ignored.

Lorri, I'm only seeing linker warnings. I have not seen a failure, but they can be hard to spot. I have not had a chance yet today to run mecej4 samples on my versions, but then it doesn't really address the issue I have, which is using one compiler to make libraries to be used by all newer compilers.  Is this something that makes using older libraries (from XE2011) with a newer compiler to compile and link the main program no longer function? If it is resolving the address of the beginning of the common blocks okay,  I suspect I don't have a problem. But I would like someone to confirm this by someone who understands how the compiler is working internally, rather than try to deduce the answer with sample programs. 

As far as I can gather from this thread, the Linux linker ld is only giving warnings regarding sub-optimal alignment. It follows that the linker does succeed in linking the common block segments properly, albeit at the expense of slightly degraded performance on certain processors. Your system ld may allow a -w switch, and you could consider whether to use this switch or to tell your users to ignore the specific warning related to alignment.

Leave a Comment

Please sign in to add a comment. Not a member? Join today