[flang-commits] [clang] [flang] [llvm] [flang] Add -finit-local= to initialize automatic variables (PR #216164)

[via flang-commits]

================
@@ -0,0 +1,92 @@
+! Pinned negative tests for -finit-local= exclusions.
+!
+! Each case uses %flang_fc1 -emit-hlfir -finit-local=0xAA and asserts that
+! no synthesized initialization store appears for the excluded variable.
+!
+! Exclusions verified here:
+!   1. Function result variable
+!   2. Main-program local (implicit SAVE per Fortran 2018 8.5.16p4)
+!   3. Runtime-sized automatic array (unknown extent at compile time)
+!   4. CHARACTER array (pending memset infrastructure, PR #159788)
+!   5. Derived type with POINTER component (IsAllocatableOrPointer on component)
+!   6. host,device CUDA local (allocated via cuf.alloc, not fir.alloca)
+!      -- see finit-local-cuda.cuf for the CUDA cases
+!   7. PowerPC vector locals (direct or as a derived-type component)
+!      -- see finit-local-ppc-vector-llvm.f90 for the vector cases
+
+! RUN: %flang_fc1 -emit-hlfir -finit-local=0xAA %s -o - | FileCheck %s
----------------
MattPD wrote:

Could this invocation gain an eligible positive control? The file's directives pass against compiler output produced with no `-finit-local=` option at all, so they cannot distinguish a working guard from an inactive option.

The negative directives for the runtime array, the CHARACTER array, and the pointer component forbid only `fir.do_loop`. I changed `test_runtime_array` at two lines so that its local became an eligible scalar. The compiler then emitted `fir.store %c-1431655766_i32 to %4#0 : !fir.ref<i32>`, and this file's directives still passed.

Two changes would close that gap. An eligible local under the same RUN line would fail if the option stopped taking effect. Binding each `CHECK-NOT` to the excluded declaration, rather than to `fir.do_loop`, would reject a direct synthesized store.


https://github.com/llvm/llvm-project/pull/216164