topic Re: Bug in IFX - Standalone BLOCK DATA Source File in Library in Intel® Fortran Compiler

Bug in IFX - Standalone BLOCK DATA Source File in Library

Stuart-McDonald — Thu, 04 Jan 2024 21:19:22 GMT

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

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

Arjen_Markus — Fri, 05 Jan 2024 07:30:09 GMT

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.

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

mecej4 — Fri, 05 Jan 2024 16:36:35 GMT

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".

Re:Bug in IFX - Standalone BLOCK DATA Source File in Library

Barbara_P_Intel — Fri, 05 Jan 2024 17:17:04 GMT

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.

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

Steve_Lionel — Fri, 05 Jan 2024 18:42:15 GMT

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.

Re:Bug in IFX - Standalone BLOCK DATA Source File in Library

Barbara_P_Intel — Fri, 05 Jan 2024 19:43:32 GMT

I filed CMPLRLLVM-55045 to get this fixed.

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

NasarAli — Fri, 03 May 2024 05:28:26 GMT

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

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

Barbara_P_Intel — Fri, 03 May 2024 15:01:39 GMT

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

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

Lukasz_H_1 — Tue, 03 Sep 2024 21:32:27 GMT

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

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

Devorah_H_Intel — Wed, 04 Sep 2024 04:20:42 GMT

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.

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

Hiram_Brown — Mon, 06 Jan 2025 21:16:50 GMT

Is this bug still in work. I see that it was reported a year ago. I observed the same issue with my legacy applications.

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

Hiram_Brown — Mon, 06 Jan 2025 21:24:58 GMT

My latest download of ONEAPI did not include IFORT so I am dependent on IFX. I have a very unpopular work around that involves pulling all BLOCK DATA code from the static library code to a single file so that it can be manually compiled into the application that requires the static library. I would request that this issue be addressed so that legacy applications can be built properly.

Re: Bug in IFX - Standalone BLOCK DATA Source File in Library

Devorah_H_Intel — Mon, 06 Jan 2025 21:39:02 GMT

@Hiram_Brown wrote:

Is this bug still in work. I see that it was reported a year ago. I observed the same issue with my legacy applications.

There is no fix.

Please check the Release Notes https://www.intel.com/content/www/us/en/developer/articles/release-notes/oneapi-fortran-compiler-release-notes.html

Particularly this part under Known Issues:

BLOCK DATA

On Windows systems, a subprogram built into a library that references a common block variable initialized in a BLOCK DATA subprogram that is compiled separately and linked with the library will not get initialized but will have a zero value. The workaround for this problem is to compile the subprogram and the BLOCK DATA subprogram together, or pass the object file with BLOCK DATA separately on the link line.