Programming Languages on Power

 View Only
  • 1.  XL Fortran, Linker Error 0711-583 EVERE ERROR: Symbol ... (entry ...) in object ....o:

    Posted Tue September 05, 2023 12:40 PM
    Good day, 
    We have a legacy Fortran program running with XL Fortran 15.1.3, AIX 7.2 on a Power 8 with 32gb.
    When ported to a Power 9, Open Fortran 17.1.1, AIX 7.3, with 32gb the following linker error is produced : 
    ld: 0711-583 SEVERE ERROR: Symbol ifrs5d (entry 489) in object maria.o:
    Ld flags are 
    LDFLAGS= -b64 -bbigtls -bbigtoc -L. -lmaria -lave
    The symbol is a COMMON
    829|      common /ifrs5d/xbel,xra,xbela,xt0ru,xt0rp,xt0pad,xpdlp,xpdqx,
    830|     $        xpdex,xpdin,xchgra,xrneg,xrcvd,xvolt,xpolt 
    All the variable with the common a defined the same as this one
     814|      double precision xbel(9,5,KLEMAX,0:KLEMAX,NMAXP)
    Where KLEMAX, and NMAXP are both defined as 100. 
    If we lower the value of KLEMAX to 10, compile is successful. 
    The limits are mostly unlimited : 
    eowyn:~> ulimit -a
    address space limit (Kibytes)  (-M)  unlimited
    core file size (blocks)        (-c)  unlimited
    cpu time (seconds)             (-t)  unlimited
    data size (Kibytes)            (-d)  unlimited
    file size (blocks)             (-f)  unlimited
    locks                          (-x)  not supported
    locked address space (Kibytes) (-l)  not supported
    message queue size (Kibytes)   (-q)  not supported
    nice                           (-e)  not supported
    nofile                         (-n)  unlimited
    nproc                          (-u)  unlimited
    pipe buffer size (bytes)       (-p)  32768
    max memory size (Kibytes)      (-m)  unlimited
    rtprio                         (-r)  not supported
    socket buffer size (bytes)     (-b)  32768
    sigpend                        (-i)  32
    stack size (Kibytes)           (-s)  unlimited
    swap size (Kibytes)            (-w)  not supported
    threads                        (-T)  not supported
    process size (Kibytes)         (-v)  unlimited
    After much searching, I cannot find reference to the link error. 
    Is there anyone who could shed some light on this. 
    Thanks in advance 
    Bob



    ------------------------------
    Robert Gervais
    ------------------------------



  • 2.  RE: XL Fortran, Linker Error 0711-583 EVERE ERROR: Symbol ... (entry ...) in object ....o:

    Posted Wed September 06, 2023 11:37 AM
    Edited by Rafik Zurob Wed September 06, 2023 01:47 PM

    Hi Bob.  Thanks for reporting this.  Do you mind opening a support ticket?  We'll probably need more information such as the object file or a reproducer.  We also ship a tool called opt/IBM/openxlf/17.1.1/tools/ibm-bugpoint that can help in generating a small reproducer.  (doc link)

    I've tried to reproduce the error over here using:


    implicit double precision (a-z)
    integer, parameter :: KLEMAX = 100
    integer, parameter :: NMAXP = 100
    common /ifrs5d/xbel,xra,xbela,xt0ru,xt0rp,xt0pad,xpdlp,xpdqx, &
          xpdex,xpdin,xchgra,xrneg,xrcvd,xvolt,xpolt
    double precision xbel(9,5,KLEMAX,0:KLEMAX,NMAXP)

    but it didn't crash for me.  I suspect the sizes of the other common block members are relevant.

    • What's the total size of the common block? (sum of the sizes of all members)
    • Are you building in 64-bit mode?
    • What compiler invocation command are you using to compile?  xlf, xlf_r, or something else?
    • What's the output from "dump -X64 -t489 -v maria.o"
    • What's the output from "dump -hv -X64 maria.o"

    Thanks

    Rafik



    ------------------------------
    Rafik Zurob
    ------------------------------



  • 3.  RE: XL Fortran, Linker Error 0711-583 EVERE ERROR: Symbol ... (entry ...) in object ....o:

    Posted Fri October 27, 2023 01:30 PM
    Thanks Rafik, 
    We don't seem to have opt/IBM/openxlf/17.1.1/tools/ibm-bugpoint. In fact, I incorrectly specified the version, ours is 17.1.0
    However I was able come with with very little code, that would produce same error. See below
    There are four commons 
    Name    Elements          Bytes
    ifrs5d      271 350 000    2 170 800 000
    ifrs5e1      32 160 000       257 280 000
    ifrs6a      313 560 000    2 508 480 000
    ifrs5e2      14 070 000       112 560 000
    We are compiling in 64bit
    xlf -q64 -g -qfixed=132 maria2.f
    ** maria2   === End of Compilation 1 ===
    1501-510  Compilation successful for file maria2.f.
    ld: 0711-583 SEVERE ERROR: Symbol ifrs5d (entry 35) in object /tmp/xlf.QyU7ea/maria2.o:
            The symbol is not entirely contained within its section.
    ld: 0711-583 SEVERE ERROR: Symbol ifrs5e1 (entry 37) in object /tmp/xlf.QyU7ea/maria2.o:
            The symbol is not entirely contained within its section.
    ld: 0711-583 SEVERE ERROR: Symbol ifrs5e2 (entry 39) in object /tmp/xlf.QyU7ea/maria2.o:
            The symbol is not entirely contained within its section.
    ld: 0711-583 SEVERE ERROR: Symbol ifrs6a (entry 41) in object /tmp/xlf.QyU7ea/maria2.o:
            The symbol is not entirely contained within its section.
    The result is the same if I complle with any O option other than 5. 5 works.  
    xlf -q64 -O5 -qfixed=132 maria2.f
    ** maria   === End of Compilation 1 ===
    1501-510  Compilation successful for file maria2.f.
    What follows is the dump info. 
    eowyn:/mounts/a/CompileTesting/STEST> xlf -q64 -g -qfixed=132 -c maria2.f
    ** maria   === End of Compilation 1 ===
    1501-510  Compilation successful for file maria2.f.
    eowyn:/mounts/a/CompileTesting/STEST> dump -X64 -t489 -v maria2.o
    maria2.o:
                            ***Symbol Table Information***
    [Index] m        Value       Scn   Aux  Sclass    Type            Name
    [Index] a0                                                        Fname
    [Index] a1      Tagndx      Lnno  Size  Lnoptr    Endndx
    [Index] a2      Tagndx            Fsiz  Lnoptr    Endndx
    [Index] a3      Tagndx      Lnno  Size  Dimensions
    [Index] a4   CSlen     PARMhsh SNhash SMtype SMclass Stab SNstab
    [Index] a5      SECTlen    #RELent    #LINnums
    eowyn:/mounts/a/CompileTesting/STEST> dump -hv -X64 maria2.o
    maria2.o:
                            ***Section Header Information***
                             Section Header for .text
    PHYaddr      VTRaddr     SCTsiz      RAWptr      RELptr
    0x00000000  0x00000000  0x000000e0  0x000001c8  0x0000106c
    LN#ptr       #RELent     #LINent     Flags
    0x00000000  0x00000003  0x00000000  0x00000020
                             Section Header for .data
    PHYaddr      VTRaddr     SCTsiz      RAWptr      RELptr
    0x000000e0  0x000000e0  0x00000020  0x000002a8  0x00001096
    LN#ptr       #RELent     #LINent     Flags
    0x00000000  0x00000003  0x00000000  0x00000040
                             Section Header for .bss
    PHYaddr      VTRaddr     SCTsiz      RAWptr      RELptr
    0x00000100  0x00000100  0x2cf37500  0x00000000  0x00000000
    LN#ptr       #RELent     #LINent     Flags
    0x00000000  0x00000000  0x00000000  0x00000080
                             Section Header for .dwline
    PHYaddr      VTRaddr     SCTsiz      RAWptr      RELptr
    0x00000000  0x00000000  0x00000070  0x000002c8  0x000010c0
    LN#ptr       #RELent     #LINent     Flags
    0x00000000  0x00000004  0x00000000  0x00020010
                             Section Header for .dwinfo
    PHYaddr      VTRaddr     SCTsiz      RAWptr      RELptr
    0x00000000  0x00000000  0x00000ca0  0x00000338  0x000010f8
    LN#ptr       #RELent     #LINent     Flags
    0x00000000  0x0000003b  0x00000000  0x00010010
                             Section Header for .dwabrev
    PHYaddr      VTRaddr     SCTsiz      RAWptr      RELptr
    0x00000000  0x00000000  0x00000093  0x00000fd8  0x00000000
    LN#ptr       #RELent     #LINent     Flags
    0x00000000  0x00000000  0x00000000  0x00060010
    The code is very old, and there is lots of it. I would entertain the idea of downgrading 7.3 on our power9 to 7.2, with xlf 15.1.3 which is what we have on the server where this all works, if I thought it would work. To me it seems easier than getting the developers to modernize their code. 
    Thanks in advance
    Bob
    c=========================================================
           program maria2
    c=========================================================
    c      implicit double precision (a-h,o-z)
    c      xlf -q64 -O5 -qfixed=132 maria2.f
    c      xlf -q64 -g -qfixed=132 maria2.f
           Parameter(200=200) 
           Parameter(10=10) 
           double precision xbel(9,5,200,0:200,10)     
           double precision xra(9,5,200,0:200,10)      
           double precision xbela(9,5,200,0:200,10)    
           double precision xt0ru(9,5,200,0:200,10)    
           double precision xt0rp(9,5,200,0:200,10)    
           double precision xt0pad(9,5,200,0:200,10)   
           double precision xpdlp(9,5,200,0:200,10)    
           double precision xpdqx(9,5,200,0:200,10)    
           double precision xpdex(9,5,200,0:200,10)    
           double precision xpdin(9,5,200,0:200,10)    
           double precision xchgra(9,5,200,0:200,10)   
           double precision xrneg(9,5,200,0:200,10)    
           double precision xrcvd(9,5,200,0:200,10)    
           double precision xvolt(9,5,200,0:200,10)    
           double precision xpolt(9,5,200,0:200,10)    
           common /ifrs5d/ xbel,xra,xbela,xt0ru,xt0rp,xt0pad,xpdlp,xpdqx,xpdex,xpdin,xchgra,xrneg,xrcvd,xvolt,xpolt
           double precision xchgifc_i(5,200,0:200,2,10)      
           double precision xchgifi_sh(5,200,0:200,2,10)     
           double precision xchgifsh_bc(5,200,0:200,2,10)    
           double precision xchgifbc_c(5,200,0:200,2,10)     
           double precision xchgnbc_i(5,200,0:200,2,10)      
           double precision xchgnbi_sh(5,200,0:200,2,10)     
           double precision xchgnbsh_bc(5,200,0:200,2,10)    
           double precision xchgnbbc_c(5,200,0:200,2,10)     
           common /ifrs5e1/ xchgifc_i,xchgifi_sh,xchgifsh_bc,xchgifbc_c
           common /ifrs5e2/ xchgnbc_i,xchgnbi_sh,xchgnbsh_bc,xchgnbbc_c
           double precision xbelmth(5,200,0:200,10,12)
           double precision xbelintm(5,200,0:200,10,12)
           double precision xramth(5,200,0:200,10,12)
           double precision xraintm(5,200,0:200,10,12)
           double precision xcsmmth(5,200,0:200,10,12)
           double precision xcsmintm(5,200,0:200,10,12)
           double precision xcsmint2m(5,200,0:200,10,12)
           double precision xlcpvmth(5,200,0:200,10,12)
           double precision xlcpvintm(5,200,0:200,10,12)
           double precision xacqmth(5,200,0:200,10,12)
           double precision xacqintm(5,200,0:200,10,12)
           double precision xacqdmth(5,200,0:200,10,12)
           double precision xacqdintm(5,200,0:200,10,12)
           common /ifrs6a/ xbelmth,xbelintm,xramth,xraintm,xcsmmth,xcsmintm,xcsmint2m,xlcpvmth,xlcpvintm,xacqmth,xacqintm,xacqdmth,
         $ xacqdintm
           double precision xbelint(5,200,0:200,10)
           double precision xraint(5,200,0:200,10)
           double precision xcsmint(5,200,0:200,10)
           double precision xcsmint2(5,200,0:200,10)
           double precision xlcpvint(5,200,0:200,10)
           double precision xacqint(5,200,0:200,10)
           double precision xacqdint(5,200,0:200,10)
           common /ifrs6b/ xbelint,xraint,xcsmint,xcsmint2,xlcpvint,xacqint,xacqdint
           stop 'normal'
           end 



    ------------------------------
    Robert Gervais
    ------------------------------



  • 4.  RE: XL Fortran, Linker Error 0711-583 EVERE ERROR: Symbol ... (entry ...) in object ....o:

    Posted Fri October 27, 2023 01:33 PM

    Not sure what I did there to get the text all squeezed in like that, but apologies for the difficult read.



    ------------------------------
    Robert Gervais
    ------------------------------



  • 5.  RE: XL Fortran, Linker Error 0711-583 EVERE ERROR: Symbol ... (entry ...) in object ....o:

    Posted Mon October 30, 2023 07:09 AM

    This problem seems to be resolved by replacing the common vars with global vars via a module. The challenge will be to get the developers to convert all their code.



    ------------------------------
    Robert Gervais
    ------------------------------



  • 6.  RE: XL Fortran, Linker Error 0711-583 EVERE ERROR: Symbol ... (entry ...) in object ....o:

    Posted Mon October 30, 2023 10:31 AM
    Edited by Rafik Zurob Mon October 30, 2023 11:11 AM

    Hi Robert.  The problem appears to be fixed in the latest version of the compiler, 17.1.2, which was released on October 27th.  You can get it from the usual distribution channels.  The upgrade is free.  Note that this is an upgrade to a newer version, not a PTF.

    $ /opt/IBM/openxlf/17.1.2/bin/xlf -qversion
    IBM Open XL Fortran for AIX 17.1.2 (5725-C74, 5765-J19)
    Version: 17.01.0002.0000
    $


    $ rm -f a.out; /opt/IBM/openxlf/17.1.2/bin/xlf -qfixed=132 -O -q64 comm.f && ./a.out
    ** maria2   === End of Compilation 1 ===
    1501-510  Compilation successful for file comm.f.
    STOP normal
    $ rm -f a.out; /opt/IBM/openxlf/17.1.2/bin/xlf -qfixed=132 -O5 -q64 comm.f && ./a.out
    ** maria2   === End of Compilation 1 ===
    1501-510  Compilation successful for file comm.f.
    STOP normal
    $ rm -f a.out; /opt/IBM/openxlf/17.1.2/bin/xlf -qfixed=132 -g -q64 comm.f && ./a.out
    ** maria2   === End of Compilation 1 ===
    1501-510  Compilation successful for file comm.f.
    STOP normal
    $

    Open XL Fortran 17.1.0 and 17.1.1 compile programs to assembly and then use the system assembler to generate the object code.  This presents scalability problems for very large programs because of system assembler limitations.  So in Open XL Fortran 17.1.2, we changed to emitting object code directly from the compiler backend by default.  I confirmed that the errors above are still reproducible if I force the compiler to go through the assembler path.  I know the OS team are looking at addressing assembler scalability limitations.  (For example, the assembler is currently a 32-bit program and it's being moved to a 64-bit program.)

    ------------------------------
    Rafik Zurob
    ------------------------------