Pragma-related ICE building RTS

[simonjwright]

Following the advice in #19 to check out the commits in #18, and after struggles with clang++ & macOS (will report later) I get this while building the RTS (target quicklib):

	gprbuild -v -n -p --target=llvm -j1 -P/Volumes/Miscellaneous2/ll/gnat-llvm/llvm-interface/lib/rts-native/adainclude/libada \
	  -XCFLAGS="-O2 -g" \
	  -XEXTRALIBFLAGS=" -gdwarf-aranges" \
	  -XLIBRARY_KIND=static
object directory "/Volumes/Miscellaneous2/ll/gnat-llvm/llvm-interface/lib/rts-native/adainclude/../obj-static" created for project Libgnarl
Changing to object directory of "Libgnarl": "/Volumes/Miscellaneous2/ll/gnat-llvm/llvm-interface/lib/rts-native/obj-static/"
/volumes/miscellaneous2/ll/clang+llvm-11.0.0-x86_64-apple-darwin/bin/clang -c -x c -O2 -g -I../include -DIN_RTS=1 -fexceptions -DSTANDALONE -gdwarf-aranges -I/volumes/miscellaneous2/ll/gnat-llvm/llvm-interface/lib/rts-native/adainclude /Volumes/Miscellaneous2/ll/gnat-llvm/llvm-interface/lib/rts-native/adainclude/thread.c
/volumes/miscellaneous2/ll/gnat-llvm/llvm-interface/bin/llvm-gcc -c -x ada -gnatA -O2 -g -nostdinc -I../adainclude -gnatpg -gnatec=/private/var/folders/_q/fvnxz46903z9hjh38fz0lyhm0000gs/T/GNAT-TEMP-000002.TMP -gnatem=/private/var/folders/_q/fvnxz46903z9hjh38fz0lyhm0000gs/T/GNAT-TEMP-000003.TMP /Volumes/Miscellaneous2/ll/gnat-llvm/llvm-interface/lib/rts-native/adainclude/a-synbar.adb

raised SEM_PRAG.ANALYZE_PRAGMA.PRAGMA_EXIT : sem_prag.adb:6605
gprbuild: *** compilation phase failed
make[1]: *** [quicklib] Error 4

---

Could this perhaps be related to these warnings about llvm_wrapper.o being compiled with different visibility settings while linking llvm-gnat1?

ld: warning: direct access in function 'llvm::LLParser::ParseStandaloneMetadata()' from file
 '/Volumes/Miscellaneous2/ll/clang+llvm-11.0.0-x86_64-apple-darwin/lib/libLLVMAsmParser.a(LLParser.cpp.o)'
 to global weak symbol 'llvm::MDTuple::get(llvm::LLVMContext&,
 llvm::ArrayRef<llvm::Metadata*>)' from file 'libgnat_llvm.a(llvm_wrapper.o)' means 
 the weak symbol cannot be overridden at runtime. This was likely caused by different
 translation units being compiled with different visibility settings.
ld: warning: direct access in function 'llvm::LLParser::ParseMDTuple(llvm::MDNode*&, bool)' from file
 '/Volumes/Miscellaneous2/ll/clang+llvm-11.0.0-x86_64-apple-darwin/lib/libLLVMAsmParser.a(LLParser.cpp.o)'
 to global weak symbol 'llvm::MDTuple::get(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>)' from file 'libgnat_llvm.a(llvm_wrapper.o)' means
 the weak symbol cannot be overridden at runtime. This was likely caused by different
 translation units being compiled with different visibility settings.

llvm_wrapper.o compiled with clang++ below, same issue with g++.

/Volumes/Miscellaneous2/ll/gnat-llvm/../llvm/bin/clang++ -c -x c++ -g -I/Volumes/Miscellaneous2/ll/clang+llvm-11.0.0-x86_64-apple-darwin/include -std=c++14 -fno-exceptions -fno-rtti -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -MMD -MF llvm_wrapper.d /Volumes/Miscellaneous2/ll/gnat-llvm/llvm-interface/llvm_wrapper.cc

[ArnaudCharlet]

This is unrelated to the warning you got although I have no idea what impact this warning will have.
It looks like you do not have a functioning exception handling in the base GNAT compiler you've used to build GNAT LLVM and exception propagation needed during the compilation of a-synbar.adb breaks as a result (generates an unhandled exception instead of an internal exception silently handled during compilation). Which GNAT compiler are you using to build GNAT LLVM? Most likely the error comes from there and is somewhat unrelated to GNAT. I'd suggest building GNAT LLVM with GNAT Community 2020.

[simonjwright]

Building with CE 2020 gives the same result.

I don’t see how exception handling in the base GNAT compiler (was FSF GCC 10.1.0, which passes the ACATS tests) could affect exception handling in the newly-built llvm-gnat1, which is where the problem arises?

[ArnaudCharlet]

llvm-gnat1 is built and linked with the base compiler, in other words, it uses the runtime from the base compiler. Probably some subtletly during the link or which libgcc/libgcc_s is actually used by llvm-gnat1.

[ekoeppen]

@simonjwright were you able to resolve this? I'm stuck at the same point, using GNAT CE 2020 on macOS with llvm 11 from homebrew.

[simonjwright]

@ekoeppen After a period of confusion & discouragement, largely caused by setting the Darwin clang ahead of the LLVM version in the PATH, this morning I have to report SUCCESS!

• running on Big Sur,
• base compiler FSF GCC 10.1.0,
• FSF GCC master branch updated today,
• GNAT LLVM commit d447ac3, as advised,
• LLVM 11.0.0 from https://llvm.org ,
• changes in simonjwright/gnat-llvm@2b3ae05,

and this setup:

PATH=$PWD/../clang+llvm-11.0.0-x86_64-apple-darwin/bin:$PATH

export SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

@ArnaudCharlet should I open a PR?

[ArnaudCharlet]

You may although some of your changes most likely cannot be included and will go in conflict with other platforms or aren't going in the right direction. Other general changes are probably fine. Also if some changes will disappear with e.g. LLVM/Clang 12, then best to keep them on your fork and not put them as part of your PR since we will switch to LLVM 12 soon.