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

size of symbol changed

Jon_D_2
New Contributor I
2,381 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
2,381 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

0 Kudos
5 Replies
Lorri_M_Intel
Employee
2,382 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

 

0 Kudos
mecej4
Honored Contributor III
2,381 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.

0 Kudos
TimP
Honored Contributor III
2,381 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.
0 Kudos
Jon_D_2
New Contributor I
2,381 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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
2,381 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

0 Kudos
Reply