================ @@ -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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
