Bogus uninit check with ifx, works fine with ifort

[Harald1]

The following code with an array constructor works fine with ifort -check uninit, but fails with ifx:

program p
  implicit none
  integer, parameter :: cl = 1
  character(cl)      :: ch = "a"
  character(cl), allocatable :: c(:), res(:)

  allocate (c(0))
  res = [ c, ch ]
  print *, res
end

I get with current versions of ifort/ifx:

% ifort -check uninit ifx-bogus-uninit.f90 && ./a.out 2> /dev/null ; echo $?
 a
0
% ifx -check uninit ifx-bogus-uninit.f90 && ./a.out 2> /dev/null ; echo $?
 a
1

 Inspecting the output on stderr for ifx, I find:

Uninitialized bytes in __interceptor_write at offset 0 inside [0x725000000000, 3)
==16485==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4a8ab7 in for__write_output (/home/anlauf/a.out+0x4a8ab7) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #1 0x4a982e in for__put_sf (/home/anlauf/a.out+0x4a982e) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #2 0x493941 in for_write_seq_lis_xmit (/home/anlauf/a.out+0x493941) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #3 0x48fb62 in for_write_seq_lis (/home/anlauf/a.out+0x48fb62) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #4 0x488a86 in MAIN__ (/home/anlauf/a.out+0x488a86) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #5 0x409f38 in main (/home/anlauf/a.out+0x409f38) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #6 0x7fc794bd924c in __libc_start_main (/lib64/libc.so.6+0x3524c) (BuildId: 767aa1e4d4fc7c106971b202b6b00e92f47411dc)
    #7 0x409e19 in _start /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:120

  Uninitialized value was created by a heap allocation
    #0 0x4166f6 in __interceptor_malloc /netbatch/donb00013_00/dir/workspace/NIT/xmain-rel/LX/xmainefi2linux_release/ws/icsws/llvm/compiler-rt/lib/msan/msan_interceptors.cpp:933:3
    #1 0x48d6e2 in for__get_vm (/home/anlauf/a.out+0x48d6e2) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #2 0x4b85b9 in for__open_proc (/home/anlauf/a.out+0x4b85b9) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #3 0x4a6fba in for__open_default (/home/anlauf/a.out+0x4a6fba) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #4 0x48f613 in for_write_seq_lis (/home/anlauf/a.out+0x48f613) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #5 0x488a86 in MAIN__ (/home/anlauf/a.out+0x488a86) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #6 0x409f38 in main (/home/anlauf/a.out+0x409f38) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88)
    #7 0x7fc794bd924c in __libc_start_main (/lib64/libc.so.6+0x3524c) (BuildId: 767aa1e4d4fc7c106971b202b6b00e92f47411dc)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/anlauf/a.out+0x4a8ab7) (BuildId: 42bd01d616a716a4b672a26e1159112cbe46fc88) in for__write_output
Exiting

Strange...

[Barbara_P_Intel]

ifx -check uninit is different from ifort version. ifx uses the LLVM memory sanitizer and different variable types are checked. See the Developer Guide for additional info and compiler options. 

Did you watch A Townhall with the Intel® Fortran Compiler Developers? Ron covered -check uninit.

[Harald1]

Thanks for pointing to the presentation.  (For those interested: you may fast forward to minute 20.)

I take from it that - at 2023.2 - the uninit check is a feature preview, and false positives are possible.

Like for trivial code that only does I/O, such as:

program p
  stop 0
end

(or replacing the stop statement by a "print *"), which gives similar errors here.

(If you cannot reproduce it: I am using OpenSuse 15.4, so there might be an issue with compatibility.)

[Barbara_P_Intel]

False positives with I/O are common today unfortunately.

Be aware that -check uninit is enabled with -check all. Some developers are surprised by that. -check all,nouninit should removed the uninit work, if you want to eliminate that.

[Harald1]

That's actually how I ran into that issue...

It started with the question whether ifort/ifx are able to check the consistency of character lengths in an array constructor.  NAG can do this already at compile time, e.g. for the following variation from where I started:

program p
  implicit none
  integer, parameter :: cl = 2
  character(cl)      :: ch = "a"
  character(cl), allocatable :: c(:), res(:)

  allocate (c(0))
  res = [ c, ch(1:cl/2) ]  ! Are the different character lengths detected?
  print *, res
end

NAG gives:

NAG Fortran Compiler Release 7.1(Hanzomon) Build 7125
Warning: ifx-bogus-uninit2.f90, line 10: Allocatable variable C referenced but never set
Error: ifx-bogus-uninit2.f90, line 8: Array constructor values have differing CHARACTER lengths (2 and 1)

Since there was no compile-time diagnostics with ifort/ifx, I was hoping for a runtime diagnostic, starting from -check all, and then finding out that uninit is the reason for the confusing traceback.

To summarize: ifort/ifx currently apparently do not implement a check to that end.  (gfortran only diagnoses the issue at runtime with -fcheck=bounds).

[Barbara_P_Intel]

I checked with the Fortran standards experts on the Intel development team about checking the consistency of character lengths in an array constructor. Here's what I learned:

Constraints are supposed to be diagnosed at compile time.  The substring case cannot always be a compile time check because the substring expressions could use variables in the bounds expressions in the subscript. The test case uses a zero length array element in the constructor; that cannot be known at compile time either.

[Harald1]

Please look again: the substring length is known at compile-time, so are all character lengths.

Alternatively try:

program p
  implicit none
  character(1)              :: ch = "a"
  character(2), allocatable :: c(:), res(:)

  allocate (c(0))
  res = [ c, ch ]  ! Are the different character lengths detected?
  print *, res
end

 NAG says:

Error: ifx-bogus-uninit3.f90, line 7: Array constructor values have differing CHARACTER lengths (2 and 1)

 And if you are still not satisfied, take the following case where all sizes in the constructor are known:

program p
  implicit none
  character(1)              :: ch = "a"
  character(2)              :: c(0)
  character(2), allocatable :: res(:)

  res = [ c, ch ]  ! Are the different character lengths detected?
  print *, res
end

[Barbara_P_Intel]

Please see the Fortran DGR for information on Array Constructors. Intel expanded the scope (read the green comments).

However, I did file a bug, CMPLRLLVM-52309, because ifx should catch that when -stand or -standard-semantics is used.

[Barbara_P_Intel]

However, compiling with -stand or -standard-sematics should catch that. I'll get a bug filed.

[Steve_Lionel]

I would not expect -standard-semantics to have a role here.

[Barbara_P_Intel]

According to the DGR Fortran 2018 behavior, aka -stand f18, is part of -standard-semantics.

[Steve_Lionel]

-stand f18 is not "Fortran 2018 behavior", but rather "diagnose source forms and relations that do not conform to Fortran 2018". This is different from and orthogonal to -standard-semantics, which changes compiler defaults that affect semantics. Please point me to where the DGR says otherwise.

D:\Projects>type t.f90
real*4 foo
end
D:\Projects>ifx /standard-semantics t.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.2.0 Build 20230627
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.36.32532.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>ifx /stand t.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.2.0 Build 20230627
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

t.f90(1): warning #6916: Fortran 2018 does not allow this length specification.   [4]
real*4 foo
-----^
Microsoft (R) Incremental Linker Version 14.36.32532.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>

[Barbara_P_Intel]

@Steve_Lionel, thank you for clarifying -stand f18.

In the DGR, I read: "If you specify option standard-semantics, it enables all of the options that implement the current Fortran Standard behavior of the compiler, which is Fortran 2018 features." 

[Steve_Lionel]

The DGR is correct - the current Intel defaults (mostly -assume options) imply some semantics different from what F2018 specifies, as listed in the Description part of that page. However, that's different from diagnosing non-standard usages, which is what -stand does.

[Barbara_P_Intel]

The ifx and ifort versions that are planned for release in mid-2024 will print a warning message when the compiler option -stand used.

Enjoy!

+ ifx -what -stand h1.f90
 Intel(R) Fortran 24.0-1675
h1.f90(7): warning #8208: If type specification is omitted, each ac-value expression  in the array constructor of type CHARACTER must have the same length type parameters.   [CH]
  res = [ c, ch ]  ! Are the different character lengths detected?
-------------^
+ a.out
 a