Perfect Hash Generator problem building RTS on macOS

[simonjwright]

This is with

• gnat-llvm at commit 053e755 of 25 Feb
• GCC sources at commit f320197 of 14 Feb
• GCC 12.0.1 x86_64-apple-darwin15 built from same sources (same issue with GCC 11.2.0)
• clang+llvm-13.0.1-x86_64-apple-darwin from llvm.org on darwin-21.3.0.

I was rather expecting the standard GCC bug box, I suppose this is the gnat-llvm equivalent?

/volumes/miscellaneous1/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-000004.TMP /Volumes/Miscellaneous1/ll/gnat-llvm/llvm-interface/lib/rts-native/adainclude/s-tasren.adb
/volumes/miscellaneous1/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/Miscellaneous1/ll/gnat-llvm/llvm-interface/lib/rts-native/adainclude/s-tasque.adb
/volumes/miscellaneous1/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-000006.TMP /Volumes/Miscellaneous1/ll/gnat-llvm/llvm-interface/lib/rts-native/adainclude/s-taspri.ads

raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693

   compilation of s-tasren.adb failed

gprbuild: *** compilation phase failed
make[2]: *** [quicklib] Error 4
make[1]: *** [gnatlib-automated] Error 2
make: *** [all] Error 2

(s-tasque and s-taspri had both compiled without complaint)

Trouble with gdb, so I made a little change to s-pehage.adb, got

raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : tries = 4

[ArnaudCharlet]

So this very likely means that exception propagation is broken on your compiler (the exception is expected here, and it's supposed to be handled within the compiler), possibly a misconfiguration, or use of the wrong exception handling library (libgcc_eh and co) which do not come with GNAT LLVM, they come from the OS.

[simonjwright]

Worked round this problem, notes here.