Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

size of symbol changed

Jon_D_2
New Contributor I
661 Views

I am getting a warning stating:

ld: Warning: size of symbol `contrl_' changed from 120 in contempt28_tu.o to 1292 in hx1.o
 

Background information:  contempt28 is a legacy f77 code being ported to intel fortran 90. 

Here is the COMMON block named CONTRL in hx1.f

      COMMON/CONTRL/IPSPR,ICPR,IRUNG,IRSTW,IRSTR,IHUW,IPLMAP,IPOUT,            
     1ICOUT,IPLT1,ISUM,IPTSAV,IPTSPK,IPTSMX,IRECIR,IDISCH,IBW,                 
     1IAUXW,IAUXR,INODRB,IFPRAT,ITEREL,ISTW,ISTR,IBATCH,IPAINT,                
     1INPGRP,JNTGRT,ITDLIM,ISORT,IBALAN,IRSBAD,JSAVE,ISAVE,                    
     1IMAX1,IMAX2,IRMAX,JCHMAX,IHUR,INBB,IMXFP1,IMAX3,IMAX4,                   
     2INNODE,INUB,IINX(14),IIN2X(14),IBRKX(14),INSR,ICWRI,IDON(22),            
     3IOUT2X(14),INSMGR,INPHSF(15),JBH,INLOOP,JDC,JUH,JDM,JBB,JUB,JVP,         
     4JZCBL,JZSG,JUP,IDONRB(30),ICWALL(2,12),IMXFP2,ILCM,ILEST,                
     5IUO2,IZR,IZO,ICS,ISO,INSB,INRBC,INFPMX,ITL,                              
     & IPSET1(40),IPSET2(40),IUPLIS(25)                                        

Here is the COMMON block for CONTEMPT28.f

     COMMON /CONTRL/ FILID(10),INDEX(10),FILSIZ(10)

This code has been in production for many many years.   Moving this to fortran 90, do I need to change the name of the COMMON block to fix this?

 

0 Kudos
1 Solution
Lorri_M_Intel
Employee
661 Views

The warning has less to do with Fortran 90 than it does with a more modern loader (ld)

Please note that all COMMON blocks of the same name are overlaid in the same memory. 

Many legacy programs declare shared COMMON blocks as different sizes, which is what you have here.   That's not recommended by the standard, even though it was done that way for many years.

That said, many linkers (or loader on Linux/Unix) would take the largest COMMON block and allocate space based on that size, and that's what it looks like is happening here.

If your program is expecting that code in hx1.f sets (for example) IPSPR so that it can be referenced in contempt28.f as FILID(1), then you should not create a differently named COMMON block.

          Does this help?

                          --Lorri

 

View solution in original post

5 Replies
Lorri_M_Intel
Employee
662 Views

The warning has less to do with Fortran 90 than it does with a more modern loader (ld)

Please note that all COMMON blocks of the same name are overlaid in the same memory. 

Many legacy programs declare shared COMMON blocks as different sizes, which is what you have here.   That's not recommended by the standard, even though it was done that way for many years.

That said, many linkers (or loader on Linux/Unix) would take the largest COMMON block and allocate space based on that size, and that's what it looks like is happening here.

If your program is expecting that code in hx1.f sets (for example) IPSPR so that it can be referenced in contempt28.f as FILID(1), then you should not create a differently named COMMON block.

          Does this help?

                          --Lorri

 

View solution in original post

mecej4
Black Belt
661 Views

The message is only a warning, and that can probably be ignored.

If receiving the warning bothers you, you can pad up the smaller version of the block, e.g., as in

     COMMON /CONTRL/ FILID(10),INDEX(10),FILSIZ(10),DUMMY(293)

and check that DUMMY is not used anywhere in the subprogram containing this block. You my need to choose a different name if DUMMY is already used for something else.

TimP
Black Belt
661 Views
Ifort complains when the first instance of a common block is smaller than a later one. Such violation of the standard becomes fatal in some cases under openmp.
Jon_D_2
New Contributor I
661 Views

Thanks all for your help.  I believe I am going to let this be.   If I change it, I may introduce new errors that may occur later down the road.   Additionally, it's been in production for many years, so I don't see where a fatal error could occur.   Thanks for all your help.

jimdempseyatthecove
Black Belt
661 Views

>>it's been in production for many years, so I don't see where a fatal error could occur

You may have been lucky for many years.

Jim Dempsey

Reply