Trouble using -check uninit

[vanderwb]

We're trying to use the -check uninit feature in ifx and running into what appear to be very basic false positives with glibc. Here is a test program:

program test
  implicit none
  integer :: i = 4
end program test

 This is then compiled using:

$ ifx -check uninit -g -O0 test.f90

and then when it is run, we get:

$ ./a.out
==34877==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x00000040d2d2 in _GLOBAL__sub_I_fast_mem_ops.c fast_mem_ops.c
#1 0x7fabb902b43e in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2b43e) (BuildId: 8523b213e7586a93ab00f6dd476418b1e521e62c)
#2 0x00000040d344 in _start /home/abuild/rpmbuild/BUILD/glibc-2.42-build/glibc-2.42/csu/../sysdeps/x86_64/start.S:115

Uninitialized value was created by an allocation of 'a.i.i' in the stack frame
#0 0x00000040c741 in _GLOBAL__sub_I_fast_mem_ops.c fast_mem_ops.c

SUMMARY: MemorySanitizer: use-of-uninitialized-value fast_mem_ops.c in _GLOBAL__sub_I_fast_mem_ops.c
Exiting

We're using Intel OneAPI Compilers 2025.2.1, but have tried multiple versions through 2025.3. This is on SLES 15.6.

[Mark_Lewy]

I've just tried this with ifx 2025.3 and Ubuntu 22.04.5 LTS on WSL and had no issues.

While "SuSE LINUX Enterprise Server* 15 SP4, SP5, SP6" are on the list of supported releases in the Intel® Fortran Compiler System Requirements, they are deprecated. SP7 is the recommended version.  If you can, see if upgrading to that helps.

[MarcGrodent]

This is strange. I have exactly the same configuration as you (Ubuntu 22.04.5 LTS on WSL; IFX 2025.3.0), but I get the same warning message as @vanderwb  at runtime as soon as the flag "-check uninit" is activated (both in debug and release modes).

[vanderwb]

Thanks, Mark. This being an HPC cluster, upgrading to SP7 isn't something we are able to do in the short term. That said, I run OpenSUSE Tumbleweed - up to date with upgrades - and see the same problem at home.

I could try testing this in an OpenSUSE 15.7 container image, but given Marc's comment that he can reproduce in Ubuntu, perhaps that is not necessary. I wonder if some system packages need to be installed for this to work properly?

[Mark_Lewy]

Yes, that might be the problem. I wonder if the two different versions of glibc reported by the memory sanitizer are significant?

#1 0x7fabb902b43e in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2b43e) (BuildId: 8523b213e7586a93ab00f6dd476418b1e521e62c)
#2 0x00000040d344 in _start /home/abuild/rpmbuild/BUILD/glibc-2.42-build/glibc-2.42/csu/../sysdeps/x86_64/start.S:115

FYI,

"getconf GNU_LIBC_VERSION" returns "glibc 2.35" on my instance.

"ldd a.out" returns

linux-vdso.so.1 (0x00007ffef53db000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000074d02dc4f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000074d02da00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000074d02dc2b000)
/lib64/ld-linux-x86-64.so.2 (0x000074d02dd41000)

(I expect this is going to be somewhat different for you, because your distro is different)

[vanderwb]

Hi Mark,

Thanks again for the reply. I don't think the glibc ecosystem is a problem - or at least the versions. Our glibc version on our system is 2.38, as indicated by getconf. Our system libc does support some symbols versioned back to 2.2.5, but this should be fine. I haven't read anything in the LLVM memory sanitizer documentation suggesting otherwise, at least.

I'll play around in an Ubuntu container image to see if I can determine anything else, but right now I don't have any leads.

Regards,
Brian