Bug in IFX - Standalone BLOCK DATA Source File in Library

[Stuart-McDonald]

I'm seeing what I think may be a bug in the IFX compiler. I have a common block variable initialized in BLOCK DATA file in a standalone source file and a subroutine that are compiled into a library. The subroutine has a reference to "EXTERNAL <blockDataName>" to ensure that the BLOCK DATA file is compiled in. The library is then compiled into a program and the program writes out the value of the variable. In IFX, built into a Library, the value is 0 (not initialized to the BLOCK DATA value). In IFX compiled all at once, or in IFORT either way, the value is correct.

The issue can be reproduced with the following files:

testsub.f:

      subroutine testSub
	      INCLUDE 'bd.fi'
	      EXTERNAL BDINIT
		  
		  WRITE(*,*) "myvar is",myvar
	  end subroutine

bd.fi:

      double precision myvar
      common/mycommon/myvar

bdinit.f:

      BLOCK DATA BDINIT
      INCLUDE 'BD.FI'
      DATA myvar / 3.14159 /
      END

main.f:

      program testProgram
          call testSub
      end program

build.bat:

ifx /Qsave /Qinit:zero /libs:static /c testsub.f bdinit.f
lib /out:IfxLib.lib testsub.obj bdinit.obj
ifx main.f IfxLib.lib /o IfxWithLib.exe
ifx main.f testsub.f bdinit.f /o IfxNoLib.exe
del *.obj

ifort /Qsave /Qinit:zero /libs:static /c testsub.f bdinit.f
lib /out:IfortLib.lib testsub.obj bdinit.obj
ifort main.f IfortLib.lib /o IfortWithLib.exe
ifort main.f testsub.f bdinit.f /o IfortNoLib.exe
del *.obj

IfxWithLib.exe
IfxNoLib.exe
IfortWithLib.exe
IfortNoLib.exe

 Result (Intel Fortran Compiler 2024.0.0):

I:\Temp\Limerick\ifx_blockdata>IfxWithLib.exe
 myvar is  0.000000000000000E+000

I:\Temp\Limerick\ifx_blockdata>IfxNoLib.exe
 myvar is   3.14159011840820

I:\Temp\Limerick\ifx_blockdata>IfortWithLib.exe
 myvar is   3.14159011840820

I:\Temp\Limerick\ifx_blockdata>IfortNoLib.exe
 myvar is   3.14159011840820

[Arjen_Markus]

I do not know what is or is not required by the standard vis-à-vis BLOCK DATA, but in the past I had to explicitly link in the BLOCK DATA object file because it would not work via a library. But I have never used the EXTERNAL statement to force a reference like that. I can imagine that this is a rather grey area in the standard.

[mecej4]

Here is a slightly different way of establishing that IFX is not alert enough. Take the single file Tsub1.f containing

      subroutine testSub

      double precision myvar
      common/mycommon/myvar
      EXTERNAL BDINIT

      WRITE(*,*) "myvar is",myvar

      end subroutine

and compile with (a) Ifort and (b) Ifx, without attempting to link anything, and examine whether the resulting OBJ file contains the unsatisfied external BDINIT.

S:\LANG\smd>ifort.exe /c tsub1.f & dumpbin /symbols tsub1.obj | findstr /i bdinit
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.11.0 Build 20231010_000000
Copyright (C) 1985-2023 Intel Corporation.  All rights reserved.

00F 00000000 UNDEF  notype ()    External     | BDINIT

S:\LANG\smd>ifx.exe /c tsub1.f & dumpbin /symbols tsub1.obj | findstr /i bdinit
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.0.0 Build 20231017
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.


S:\LANG\smd>

IFX probably sees that there is a declaration for BDINIT but no reference to it, and there is nothing in the code to tell IFX that BDINIT is a code symbol and not a data symbol. In situations such as this, I feel handicapped by not having a way of declaring, "BDINIT is a typeless procedure, i.e., one that returns no value, i.e., a subroutine", or, alternatively, "BDINIT is not a data section/segment item".

[Barbara_P_Intel]

Thank you for reporting this. I think I see what you see on Windows, but not on Linux. Interesting that Linux cares about the case in the INCLUDE statement file name, but Windows does not.

I'll get a bug filed.

[Steve_Lionel]

I'll comment that an EXTERNAL declaration, without a reference, is exactly the way a BLOCK DATA is supposed to be pulled in from a library. It does not astonish me that this detail was missed in IFX, but it does need to work.

[Barbara_P_Intel]

I filed CMPLRLLVM-55045 to get this fixed.

[NasarAli]

I am facing the same issue. Is it fixed or not?

[Barbara_P_Intel]

The fix is in progress. I don't have a due date.

[Lukasz_H_1]

Hi,

I can only tell that I am also experiencing issue with this bug, i.e. when building with IFX rather than IFORT with hexacty the same project structure  (Common block etc.).

Please note that I have the latest Intel Fortran compiler installed (2024.2.1)  and this issue is still present.

With IFORT being planned for a withdrawal near end of 2024 it would be good to know when this is going to be fixed, unless there is some clear advice with a workaround.

By the way, the "Release Notes" for Fortran 2024.2.1:

Intel® Fortran Compiler for oneAPI Release Notes

point to Release Notes that say "2024.2.0" and the date mentioned is 13 June rather than 05 August (as seen in the individual components page for Intel Fortran compiler)

Best regards,

Lukasz

[Devorah_H_Intel]

There were no changes to the IFX compiler between 2024.2.0 and 2024.2.1 oneAPI Toolkits releases - hence, the Release Notes remained unchanged. 
The compiler development team is working on the fix. I will update you when it will be available.