Thank you @rovka for the original/cleaner approach and @awarzynski for your encouragement to stick with it. Also thank you for your previous patch for adding support to flang-new for generating executables. This makes running new codes through flang-new much easier!

I went back to the original patch, added some more debugging, and found that the options in cmake_parse_arguments had a space instead of a semicolon so ARG_STATIC was never being set.

Thanks for the quick response. I've verified that this revision now builds flang successfully for me. I am fine with you committing this. I'll add @awarzynski as a reviewer (since this is related to his https://reviews.llvm.org/rG97a32d3e43fe) in case he has any other suggestions.

If the install logic in add_flang_library is moved into a separate macro (to avoid the "SHARED STATIC"), this problem is avoided and only the archive version of Fortran_main is built/installed:

I just tried this patch but it seems to fail when it tries to build a shared libFortran_main.so:

I applied this change to see if it fixed the following (since this routine is called when deciding to serialize nested parallel regions):

I've reenabled the use of DataLayout::getAllocaAddrSpace as that does indeed still work as intended in the larger runnable test cases that hit this problem...and is the right thing to do since not all target architectures would necessarily have alloca in the local address space.

• reenable DataLayout::getAllocaAddrSpace

Also, as requested, I tried adding --check-prefixes=ALL,AMDGPU and --check-prefixes=ALL,NVPTX to the FileCheck in the test, but that caused lit to report an error that the prefixes weren't found:

In D109500#2992918, @JonChesterfield wrote:

Potentially interesting that getAllocaAddrSpace returns a different value to local (as that's presumably why they're behaving differently)

While updating the lit test as requested (add -mtriple and run for both amdgcn & nvptx), I found that the alloca addrspace(5) and cast to generic was no longer appearing. I backed out the change to use DataLayout::getAllocaAddrSpace...and then the modified lit test started passing. Now investigating what is happening when using DataLayout::getAllocaAddrSpace.

• update test to pass -mtriple and run for both amdgcn & nvptx

• ran: git-clang-format HEAD^

• Updates to code per review (will update test next)

This change doesn't appear to be thread-safe. With this change, the Google Halide buildbot (which uses the LLVM HVX backend) detected a crash in a test that was built multi-threaded. When switching the test to build single-threaded, the crash goes away. Backtrace shows the failure is occuring in NfaTranscriber::transition.