There is a lang/ghc build oddity: watching it in top during the early parts of its build shows: 52498 . . . /usr/local/llvm10/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align /tmp/ghc47452_0/gh so it is using devel/llvm10 at this stage. I see in the Makefile : LLVM_VERSION= 10 BOOT_GHC_VERSION= 8.10.7 # LLVM version that bootstrap compiler uses BOOT_LLVM_VERSION= 10 . . . .if ${ARCH} == aarch64 || ${ARCH:Marmv*} # ghc-8.10.x on arm requires devel/llvm10 # CONFIGURE_TARGET must to be the same as the llvm triple CONFIGURE_TARGET= ${ARCH}-unknown-freebsd${"${ARCH:Maarch64}" != "":?:-gnueabihf} CONFIGURE_ARGS+= --host=${CONFIGURE_TARGET} BUILD_DEPENDS+= llc${LLVM_VERSION}:devel/llvm${LLVM_VERSION} RUN_DEPENDS+= llc${LLVM_VERSION}:devel/llvm${LLVM_VERSION} # When GHC being compiled and GHC used for bootstrapping support different # LLVM versions, we have to pull in both. Luckily, this is relatively rare. . if ${BOOT_LLVM_VERSION} != ${LLVM_VERSION} BUILD_DEPENDS+= llc${BOOT_LLVM_VERSION}:devel/llvm${BOOT_LLVM_VERSION} . endif .endif Yet the log file for lang/ghc shows, for only some of its activity, far from all: . . . HC [stage 0] utils/genapply/dist/build/Main.o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... "inplace/bin/mkdirhier" utils/genapply/dist/build/tmp//. You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Adjustor.p_o rts_dist_HC rts/dist/build/Arena.p_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Capability.p_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/CheckUnload.p_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/ClosureFlags.p_o . . . rts_dist_HC rts/dist/build/PrimOps.p_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/StgMiscClosures.p_o rts_dist_HC rts/dist/build/StgStartup.p_o rts_dist_HC rts/dist/build/StgStdThunks.p_o rts_dist_HC rts/dist/build/Updates.p_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Adjustor.dyn_o rts_dist_HC rts/dist/build/Arena.dyn_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Capability.dyn_o . . . rts_dist_HC rts/dist/build/StgMiscClosures.dyn_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/StgStartup.dyn_o rts_dist_HC rts/dist/build/StgStdThunks.dyn_o "inplace/bin/ghc-pkg" --simple-output field rts extra-libraries \ | sed -e 's/\([^ ][^ ]*\)/-l\1/g' > rts/dist/libs.depend rts_dist_HC rts/dist/build/Updates.dyn_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Adjustor.l_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... "inplace/bin/ghc-pkg" --simple-output field rts library-dirs \ | sed -e 's/\([^ ][^ ]*\)/-L\1/g' >> rts/dist/libs.depend rts_dist_HC rts/dist/build/Arena.l_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Capability.l_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/CheckUnload.l_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/ClosureFlags.l_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Disassembler.l_o . . . rts_dist_HC rts/dist/build/StgMiscClosures.l_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/StgStartup.l_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/StgStdThunks.l_o rts_dist_HC rts/dist/build/Updates.l_o rts_dist_HC rts/dist/build/Adjustor.debug_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Arena.debug_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Capability.debug_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/CheckUnload.debug_o rts_dist_HC rts/dist/build/ClosureFlags.debug_o rts_dist_HC rts/dist/build/Disassembler.debug_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/FileLock.debug_o . . . rts_dist_HC rts/dist/build/StgStdThunks.debug_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Updates.debug_o rts_dist_HC rts/dist/build/Adjustor.thr_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Arena.thr_o rts_dist_HC rts/dist/build/Capability.thr_o rts_dist_HC rts/dist/build/CheckUnload.thr_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/ClosureFlags.thr_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Disassembler.thr_o rts_dist_HC rts/dist/build/FileLock.thr_o rts_dist_HC rts/dist/build/ForeignExports.thr_o rts_dist_HC rts/dist/build/fs.thr_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Globals.thr_o . . . rts_dist_HC rts/dist/build/StgStartup.thr_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/StgStdThunks.thr_o rts_dist_HC rts/dist/build/Updates.thr_o rts_dist_HC rts/dist/build/Adjustor.thr_debug_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/Arena.thr_debug_o rts_dist_HC rts/dist/build/Capability.thr_debug_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/CheckUnload.thr_debug_o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... rts_dist_HC rts/dist/build/ClosureFlags.thr_debug_o . . . I'll stop with that. There is more. The log files for lang/ghc show: ===> Installing existing package /packages/All/llvm10-10.0.1_10.pkg [CA72_ZFS] Installing llvm10-10.0.1_10... [CA72_ZFS] `-- Installing libedit-3.1.20210910,1... [CA72_ZFS] `-- Extracting libedit-3.1.20210910,1: .......... done [CA72_ZFS] `-- Installing libxml2-2.9.13_2... [CA72_ZFS] `-- Extracting libxml2-2.9.13_2: .......... done [CA72_ZFS] `-- Installing lua52-5.2.4... [CA72_ZFS] `-- Extracting lua52-5.2.4: ......... done [CA72_ZFS] `-- Installing perl5-5.32.1_1... [CA72_ZFS] `-- Extracting perl5-5.32.1_1: .......... done [CA72_ZFS] Extracting llvm10-10.0.1_10: .......... done but no other devel/llvm* install. So the use of llvm14 was via the system toolchain, not via use of devel/llvm14 . For reference . . . The /usr/ports content vintage in use: merge-base: 0a2f0da65b65bb9b3abf7a06815854f3cff063fa merge-base: CommitDate: 2022-05-07 18:07:34 +0000 0a2f0da65b65 (HEAD -> main) devel/py-tabulate: update to version 0.8.9 n582877 (--first-parent --count for merge-base) The aarch64 system (being used to target armv7 in the build): (system can execute armv7 code natively, so no use of qemu) main-n255745-77649f35a7e5-dirty
Can you show the contents of lib/ghc-8.10.7/settings file of the built package?
(In reply to Gleb Popov from comment #1) Later in the build it gets a memory allocation failure in llc and fails to finish. (Reminder: targeting armv7 --so, a 32-bit context and process sizes are limited.) I could try bulk with -w if the tar would contain appropriately interesting material to look at. Or I could try to target aarch64 and see how similar the reported issue may be --without the process size limitation. Preference?
(In reply to Gleb Popov from comment #1) From expanding the .tbz from a bulk -w : # more /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7-boot/lib/ghc-8.10.7/settings [("GCC extra via C opts", "") ,("C compiler command", "clang") ,("C compiler flags", "-marm") ,("C++ compiler flags", "") ,("C compiler link flags", "-fuse-ld=lld -Wl,-z,noexecstack") ,("C compiler supports -no-pie", "NO") ,("Haskell CPP command", "clang") ,("Haskell CPP flags", "-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs") ,("ld command", "ld.lld") ,("ld flags", "-z noexecstack") ,("ld supports compact unwind", "NO") ,("ld supports build-id", "YES") ,("ld supports filelist", "NO") ,("ld is GNU ld", "YES") ,("Merge objects command", "ld.lld") ,("Merge objects flags", "-r") ,("ar command", "ar") ,("ar flags", "qcls") ,("ar supports at file", "NO") ,("ranlib command", "ranlib") ,("otool command", "otool") ,("install_name_tool command", "install_name_tool") ,("touch command", "touch") ,("dllwrap command", "/bin/false") ,("windres command", "/bin/false") ,("libtool command", "libtool") ,("unlit command", "$topdir/bin/unlit") ,("cross compiling", "NO") ,("target platform string", "arm-unknown-freebsd") ,("target os", "OSFreeBSD") ,("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") ,("target word size", "4") ,("target has GNU nonexec stack", "YES") ,("target has .ident directive", "YES") ,("target has subsections via symbols", "NO") ,("target has RTS linker", "YES") ,("Unregisterised", "NO") ,("LLVM target", "armv7-unknown-freebsd-gnueabihf") ,("LLVM llc command", "llc10") ,("LLVM opt command", "opt10") ,("LLVM clang command", "clang") ,("integer library", "integer-simple") ,("Use interpreter", "YES") ,("Use native code generator", "NO") ,("Support SMP", "YES") ,("RTS ways", "l debug thr thr_debug thr_l ") ,("Tables next to code", "YES") ,("Leading underscore", "NO") ,("Use LibFFI", "YES") ,("Use Threads", "YES") ,("Use Debugging", "NO") ,("RTS expects libdw", "NO") ]
(In reply to Mark Millard from comment #3) I'll note that the core dump notice for the llc failure to allocate memory is: pid 41238 (llc), jid 51, uid 0: exited on signal 6 (core dumped) It does not say llc10 , despite the: ,("LLVM llc command", "llc10") ,("LLVM opt command", "opt10") ,("LLVM clang command", "clang") But then there is also the question: why not clang10 ?
(In reply to Mark Millard from comment #4) And, what of the llvm10 toolchain use for: ,("ld command", "ld.lld")
The settings file you've provided comes from the bootstrap compiler. It works fine. The problem is with a compiler we are building. Where did you get unprefixed llc executable from?
(In reply to Gleb Popov from comment #6) I assume the poudriere jail got it via: # poudriere jail -jmain-CA7-bulk_a -i Jail name: main-CA7-bulk_a Jail version: 14.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a Jail fs: Jail updated: 2021-12-04 14:54:10 Jail pkgbase: disabled # chroot /usr/obj/DESTDIRs/main-CA7-poud-bulk_a/ # which llc /usr/bin/llc Is there anything better to looks at under: /wrkdirs/usr/ports/lang/ghc/work/ from the -w ? For reference, the log around the later failure looks like: . . . You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... HC [stage 1] compiler/stage2/build/CmmLayoutStack.o HC [stage 1] compiler/stage2/build/GHC/StgToCmm/Prim.o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... LLVM ERROR: out of memory Allocation failed PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace. Stack dump: 0. Program arguments: llc -O2 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align /tmp/ghc22572_0/ghc_6.bc -o /tmp/ghc22572_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc22572_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"g3ky7_info$def"' LLVM ERROR: out of memory Allocation failed `llc' failed in phase `LLVM Compiler'. (Exit code: -6) gmake[2]: *** [compiler/ghc.mk:308: compiler/stage2/build/GHC/Hs/Instances.p_o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... However, watching with top showed llc . I do not remember ever seeing a llc10 at any stage. But I was trying to report the early activity that was (only sometimes) reporting the messages about LLVM version 14.0.3 being in use. That might invalidate later activity.
For reference: the messages around the first 2 LLVM 14.0.3 notices look like: . . . checking for gawk... (cached) /usr/bin/awk checking for armv7-unknown-freebsd-gnueabihf-llc-13... no checking for armv7-unknown-freebsd-gnueabihf-llc-13.0... no checking for armv7-unknown-freebsd-gnueabihf-llc13... no checking for armv7-unknown-freebsd-gnueabihf-llc... no checking for armv7-unknown-freebsd-gnueabihf-llc-12... no checking for armv7-unknown-freebsd-gnueabihf-llc-12.0... no checking for armv7-unknown-freebsd-gnueabihf-llc12... no checking for armv7-unknown-freebsd-gnueabihf-llc... no checking for armv7-unknown-freebsd-gnueabihf-llc-11... no checking for armv7-unknown-freebsd-gnueabihf-llc-11.0... no checking for armv7-unknown-freebsd-gnueabihf-llc11... no checking for armv7-unknown-freebsd-gnueabihf-llc... no checking for armv7-unknown-freebsd-gnueabihf-llc-10... no checking for armv7-unknown-freebsd-gnueabihf-llc-10.0... no checking for armv7-unknown-freebsd-gnueabihf-llc10... no checking for armv7-unknown-freebsd-gnueabihf-llc... no checking for armv7-unknown-freebsd-gnueabihf-llc-9... no checking for armv7-unknown-freebsd-gnueabihf-llc-9.0... no checking for armv7-unknown-freebsd-gnueabihf-llc9... no checking for armv7-unknown-freebsd-gnueabihf-llc... no checking for armv7-unknown-freebsd-gnueabihf-llc... no checking for llc-13... no checking for llc-13.0... no checking for llc13... no checking for llc... llc checking llc version (14.0.3) is between 9 and 13... no configure: We only support llvm 9 to 13 (found 14.0.3). checking for armv7-unknown-freebsd-gnueabihf-opt-13... no checking for armv7-unknown-freebsd-gnueabihf-opt-13.0... no checking for armv7-unknown-freebsd-gnueabihf-opt13... no checking for armv7-unknown-freebsd-gnueabihf-opt... no checking for armv7-unknown-freebsd-gnueabihf-opt-12... no checking for armv7-unknown-freebsd-gnueabihf-opt-12.0... no checking for armv7-unknown-freebsd-gnueabihf-opt12... no checking for armv7-unknown-freebsd-gnueabihf-opt... no checking for armv7-unknown-freebsd-gnueabihf-opt-11... no checking for armv7-unknown-freebsd-gnueabihf-opt-11.0... no checking for armv7-unknown-freebsd-gnueabihf-opt11... no checking for armv7-unknown-freebsd-gnueabihf-opt... no checking for armv7-unknown-freebsd-gnueabihf-opt-10... no checking for armv7-unknown-freebsd-gnueabihf-opt-10.0... no checking for armv7-unknown-freebsd-gnueabihf-opt10... no checking for armv7-unknown-freebsd-gnueabihf-opt... no checking for armv7-unknown-freebsd-gnueabihf-opt-9... no checking for armv7-unknown-freebsd-gnueabihf-opt-9.0... no checking for armv7-unknown-freebsd-gnueabihf-opt9... no checking for armv7-unknown-freebsd-gnueabihf-opt... no checking for armv7-unknown-freebsd-gnueabihf-opt... no checking for opt-13... no checking for opt-13.0... no checking for opt13... no checking for opt... opt checking opt version (14.0.3) is between 9 and 13... no configure: We only support llvm 9 to 13 (found 14.0.3). configure: Creating links for in-tree file handling routines. . . .
(In reply to Mark Millard from comment #8) The next notices have a context like: . . . rts_dist_HC rts/dist/build/ThreadLabels.o rts_dist_HC rts/dist/build/ThreadPaused.o rts_dist_HC rts/dist/build/Threads.o rts_dist_HC rts/dist/build/Ticky.o rts_dist_HC rts/dist/build/Timer.o rts_dist_HC rts/dist/build/TopHandler.o rts_dist_HC rts/dist/build/Trace.o rts_dist_HC rts/dist/build/TraverseHeap.o rts_dist_HC rts/dist/build/Weak.o rts_dist_HC rts/dist/build/WSDeque.o "inplace/bin/mkdirhier" rts/dist/build/hooks//. "inplace/bin/mkdirhier" rts/dist/build/sm//. "inplace/bin/mkdirhier" rts/dist/build/eventlog//. "inplace/bin/mkdirhier" rts/dist/build/linker//. "inplace/bin/mkdirhier" rts/dist/build/linker/macho//. "inplace/bin/mkdirhier" rts/dist/build/posix//. rts_dist_HC rts/dist/build/Apply.o rts_dist_HC rts/dist/build/Compact.o rts_dist_HC rts/dist/build/Exception.o rts_dist_HC rts/dist/build/HeapStackCheck.o rts_dist_HC rts/dist/build/PrimOps.o rts_dist_HC rts/dist/build/StgMiscClosures.o rts_dist_HC rts/dist/build/StgStartup.o rts_dist_HC rts/dist/build/StgStdThunks.o rts_dist_HC rts/dist/build/Updates.o You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... You are using an unsupported version of LLVM! Currently only 9 to 13 is supported. System LLVM version: 14.0.3 We will try though... "inplace/bin/mkdirhier" utils/genapply/dist/build/tmp//. HC [stage 0] utils/genapply/dist/build/Main.o rts_dist_HC rts/dist/build/Adjustor.p_o rts_dist_HC rts/dist/build/Arena.p_o . . .
(In reply to Mark Millard from comment #8) My guess is that none of that Comment #8 output is from looking anywhere matching the patterns: /usr/local/llvm*/bin/llc /usr/local/bin/llc* such as (for the devel/llvm10 based context): /usr/local/llvm10/bin/llc /usr/local/bin/llc10 For reference, for inside the poudriere jail context: Using poudriere bulk -jmain-CA7-bulk_a -i . . . . . . [00:00:37] Remounting /usr/ports read-write [00:00:38] Mounting logs from: /usr/local/poudriere/data/logs/bulk/main-CA7-bulk_a-default/2022-05-26_19h08m49s# pkg install llvm10 Updating local repository catalogue... [CA72_ZFS] Fetching meta.conf: 100% 163 B 0.2kB/s 00:01 [CA72_ZFS] Fetching packagesite.pkg: 100% 102 KiB 104.6kB/s 00:01 Processing entries: 100% local repository update completed. 369 packages processed. All repositories are up to date. Updating database digests format: 100% Checking integrity... done (0 conflicting) The following 11 package(s) will be affected (of 0 checked): New packages to be INSTALLED: gettext-runtime: 0.21 indexinfo: 0.3.1 libedit: 3.1.20210910,1 libffi: 3.3_1 libxml2: 2.9.13_2 llvm10: 10.0.1_10 lua52: 5.2.4 mpdecimal: 2.5.1 perl5: 5.32.1_1 python38: 3.8.13_1 readline: 8.1.2 Number of packages to be installed: 11 The process will require 849 MiB more space. Proceed with this action? [y/N]: y [CA72_ZFS] [1/11] Installing indexinfo-0.3.1... [CA72_ZFS] [1/11] Extracting indexinfo-0.3.1: 100% [CA72_ZFS] [2/11] Installing readline-8.1.2... [CA72_ZFS] [2/11] Extracting readline-8.1.2: 100% [CA72_ZFS] [3/11] Installing mpdecimal-2.5.1... [CA72_ZFS] [3/11] Extracting mpdecimal-2.5.1: 100% [CA72_ZFS] [4/11] Installing libffi-3.3_1... [CA72_ZFS] [4/11] Extracting libffi-3.3_1: 100% [CA72_ZFS] [5/11] Installing gettext-runtime-0.21... [CA72_ZFS] [5/11] Extracting gettext-runtime-0.21: 100% [CA72_ZFS] [6/11] Installing libedit-3.1.20210910,1... [CA72_ZFS] [6/11] Extracting libedit-3.1.20210910,1: 100% [CA72_ZFS] [7/11] Installing libxml2-2.9.13_2... [CA72_ZFS] [7/11] Extracting libxml2-2.9.13_2: 100% [CA72_ZFS] [8/11] Installing python38-3.8.13_1... [CA72_ZFS] [8/11] Extracting python38-3.8.13_1: 100% [CA72_ZFS] [9/11] Installing perl5-5.32.1_1... [CA72_ZFS] [9/11] Extracting perl5-5.32.1_1: 100% [CA72_ZFS] [10/11] Installing lua52-5.2.4... [CA72_ZFS] [10/11] Extracting lua52-5.2.4: 100% [CA72_ZFS] [11/11] Installing llvm10-10.0.1_10... [CA72_ZFS] [11/11] Extracting llvm10-10.0.1_10: 100% ===== Message from python38-3.8.13_1: -- Note that some standard Python modules are provided as separate ports as they require additional dependencies. They are available as: py38-gdbm databases/py-gdbm@py38 py38-sqlite3 databases/py-sqlite3@py38 py38-tkinter x11-toolkits/py-tkinter@py38 root@CA72_ZFS:~ # which llc10 /usr/local/bin/llc10 root@CA72_ZFS:~ # which llc /usr/bin/llc root@CA72_ZFS:~ # find /usr/local/ -name 'llc*' -print | more /usr/local/bin/llc10 /usr/local/llvm10/bin/llc /usr/local/share/doc/llvm10/llvm/html/_sources/CommandGuide/llc.rst.txt /usr/local/share/doc/llvm10/llvm/html/CommandGuide/llc.html /usr/local/man/man1/llc10.1.gz root@CA72_ZFS:~ # echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin root@CA72_ZFS:~ # exit =========================================================================== [00:08:39] Cleaning up [00:08:39] Unmounting file systems
amd64 FreeBSD version does not have llc in the base, which is why I never stumbled upon this problem. I guess, the port have to somehow explicitly pass the llc executable to be used. I'll look into it.
(In reply to Gleb Popov from comment #11) Same for opt: not there for amd64 but there for armv7. So it has analogous problems to for llc commands.
I looked at aarch64 (arm64) and it also has llc and opt in /usr/bin/ . But the builds on the freebsd build servers show logs looking like: checking for gawk... (cached) /usr/bin/awk checking for llc-13... no checking for llc-13.0... no checking for llc13... no checking for llc-12... no checking for llc-12.0... no checking for llc12... no checking for llc-11... no checking for llc-11.0... no checking for llc11... no checking for llc-10... no checking for llc-10.0... no checking for llc10... llc10 checking llc10 version (10.0.1) is between 9 and 13... yes checking for opt-13... no checking for opt-13.0... no checking for opt13... no checking for opt-12... no checking for opt-12.0... no checking for opt12... no checking for opt-11... no checking for opt-11.0... no checking for opt11... no checking for opt-10... no checking for opt-10.0... no checking for opt10... opt10 checking opt10 version (10.0.1) is between 9 and 13... yes configure: $CC is not gcc; assuming it's a reasonably new C compiler Looks like something is more specific to armv7 (and armv6 ?) for how things are working, not just the llc and opt being in the system.
(In reply to Mark Millard from comment #13) My apologies on a bad comparison in comment #12. The build has 2 instances of sequences of: checking for gawk... (cached) /usr/bin/awk then checking for llc and opt. The armv7 list that I reported is from the 2nd but the aarch64 one that I reported is from the 1st. For aarch64, here is the 2nd sequence from the FreeBSD build server log file, for better comparison to my armv7 material: checking for gawk... (cached) /usr/bin/awk checking for aarch64-unknown-freebsd-llc-13... no checking for aarch64-unknown-freebsd-llc-13.0... no checking for aarch64-unknown-freebsd-llc13... no checking for aarch64-unknown-freebsd-llc... no checking for aarch64-unknown-freebsd-llc-12... no checking for aarch64-unknown-freebsd-llc-12.0... no checking for aarch64-unknown-freebsd-llc12... no checking for aarch64-unknown-freebsd-llc... no checking for aarch64-unknown-freebsd-llc-11... no checking for aarch64-unknown-freebsd-llc-11.0... no checking for aarch64-unknown-freebsd-llc11... no checking for aarch64-unknown-freebsd-llc... no checking for aarch64-unknown-freebsd-llc-10... no checking for aarch64-unknown-freebsd-llc-10.0... no checking for aarch64-unknown-freebsd-llc10... no checking for aarch64-unknown-freebsd-llc... no checking for aarch64-unknown-freebsd-llc-9... no checking for aarch64-unknown-freebsd-llc-9.0... no checking for aarch64-unknown-freebsd-llc9... no checking for aarch64-unknown-freebsd-llc... no checking for aarch64-unknown-freebsd-llc... no checking for llc-13... no checking for llc-13.0... no checking for llc13... no checking for llc... no checking for llc-12... no checking for llc-12.0... no checking for llc12... no checking for llc... no checking for llc-11... no checking for llc-11.0... no checking for llc11... no checking for llc... no checking for llc-10... no checking for llc-10.0... no checking for llc10... llc10 checking llc10 version (10.0.1) is between 9 and 13... yes checking for aarch64-unknown-freebsd-opt-13... no checking for aarch64-unknown-freebsd-opt-13.0... no checking for aarch64-unknown-freebsd-opt13... no checking for aarch64-unknown-freebsd-opt... no checking for aarch64-unknown-freebsd-opt-12... no checking for aarch64-unknown-freebsd-opt-12.0... no checking for aarch64-unknown-freebsd-opt12... no checking for aarch64-unknown-freebsd-opt... no checking for aarch64-unknown-freebsd-opt-11... no checking for aarch64-unknown-freebsd-opt-11.0... no checking for aarch64-unknown-freebsd-opt11... no checking for aarch64-unknown-freebsd-opt... no checking for aarch64-unknown-freebsd-opt-10... no checking for aarch64-unknown-freebsd-opt-10.0... no checking for aarch64-unknown-freebsd-opt10... no checking for aarch64-unknown-freebsd-opt... no checking for aarch64-unknown-freebsd-opt-9... no checking for aarch64-unknown-freebsd-opt-9.0... no checking for aarch64-unknown-freebsd-opt9... no checking for aarch64-unknown-freebsd-opt... no checking for aarch64-unknown-freebsd-opt... no checking for opt-13... no checking for opt-13.0... no checking for opt13... no checking for opt... no checking for opt-12... no checking for opt-12.0... no checking for opt12... no checking for opt... no checking for opt-11... no checking for opt-11.0... no checking for opt11... no checking for opt... no checking for opt-10... no checking for opt-10.0... no checking for opt10... opt10 checking opt10 version (10.0.1) is between 9 and 13... yes
I see a possible notational oddity in the /wrkdir/... materials: In notation like: PROG_VERSION_CANDIDATES=$(for llvmVersion in `seq $LlvmMaxVersion -1 $LlvmMinVersion`; do echo "llc-$llvmVersion llc-$llvmVersion.0 llc$llvmVersion llc$llvmVersion0"; done) Is llc$llvmVersion0 intended to behave more like: llc${llvmVersion}0 or more like: llc${llvmVersion0} ? My guess is more like llc${llvmVersion}0 . I expect that the notation llc$llvmVersion0 is wrong for the purpose of the code.
(In reply to Mark Millard from comment #15) Based on the following sort of experiment, I'm no longer getting the messages that I reported: # git -C /usr/ports diff lang/ghc diff --git a/lang/ghc/files/patch-aclocal.m4 b/lang/ghc/files/patch-aclocal.m4 index 2eb04c157343..dc83f27a23d7 100644 --- a/lang/ghc/files/patch-aclocal.m4 +++ b/lang/ghc/files/patch-aclocal.m4 @@ -14,7 +14,7 @@ AC_DEFUN([FIND_LLVM_PROG],[ # Test for program with and without version name. - PROG_VERSION_CANDIDATES=$(for llvmVersion in `seq $4 -1 $3`; do echo "$2-$llvmVersion $2-$llvmVersion.0"; done) -+ PROG_VERSION_CANDIDATES=$(for llvmVersion in `seq $4 -1 $3`; do echo "$2-$llvmVersion $2-$llvmVersion.0 $2$llvmVersion $2$llvmVersion0"; done) ++ PROG_VERSION_CANDIDATES=$(for llvmVersion in `seq $4 -1 $3`; do echo "$2-$llvmVersion $2-$llvmVersion.0 $2$llvmVersion $2${llvmVersion}0"; done) AC_CHECK_TOOLS([$1], [$PROG_VERSION_CANDIDATES $2], []) AS_IF([test x"$$1" != x],[ PROG_VERSION=`$$1 --version | awk '/.*version [[0-9\.]]+/{for(i=1;i<=NF;i++){ if(\$i ~ /^[[0-9\.]]+$/){print \$i}}}'` Watching with top shows paths like: /usr/local/llvm10/bin/llc which should be fine. The build is still ongoing, so other issues may show up. But they are not what was being reported in this bugzilla submittal. For reference: . . . checking for gawk... (cached) /usr/bin/awk checking for armv7-unknown-freebsd-gnueabihf-llc-13... no checking for armv7-unknown-freebsd-gnueabihf-llc-13.0... no checking for armv7-unknown-freebsd-gnueabihf-llc13... no checking for armv7-unknown-freebsd-gnueabihf-llc130... no checking for armv7-unknown-freebsd-gnueabihf-llc-12... no checking for armv7-unknown-freebsd-gnueabihf-llc-12.0... no checking for armv7-unknown-freebsd-gnueabihf-llc12... no checking for armv7-unknown-freebsd-gnueabihf-llc120... no checking for armv7-unknown-freebsd-gnueabihf-llc-11... no checking for armv7-unknown-freebsd-gnueabihf-llc-11.0... no checking for armv7-unknown-freebsd-gnueabihf-llc11... no checking for armv7-unknown-freebsd-gnueabihf-llc110... no checking for armv7-unknown-freebsd-gnueabihf-llc-10... no checking for armv7-unknown-freebsd-gnueabihf-llc-10.0... no checking for armv7-unknown-freebsd-gnueabihf-llc10... no checking for armv7-unknown-freebsd-gnueabihf-llc100... no checking for armv7-unknown-freebsd-gnueabihf-llc-9... no checking for armv7-unknown-freebsd-gnueabihf-llc-9.0... no checking for armv7-unknown-freebsd-gnueabihf-llc9... no checking for armv7-unknown-freebsd-gnueabihf-llc90... no checking for armv7-unknown-freebsd-gnueabihf-llc... no checking for llc-13... no checking for llc-13.0... no checking for llc13... no checking for llc130... no checking for llc-12... no checking for llc-12.0... no checking for llc12... no checking for llc120... no checking for llc-11... no checking for llc-11.0... no checking for llc11... no checking for llc110... no checking for llc-10... no checking for llc-10.0... no checking for llc10... llc10 checking llc10 version (10.0.1) is between 9 and 13... yes checking for armv7-unknown-freebsd-gnueabihf-opt-13... no checking for armv7-unknown-freebsd-gnueabihf-opt-13.0... no checking for armv7-unknown-freebsd-gnueabihf-opt13... no checking for armv7-unknown-freebsd-gnueabihf-opt130... no checking for armv7-unknown-freebsd-gnueabihf-opt-12... no checking for armv7-unknown-freebsd-gnueabihf-opt-12.0... no checking for armv7-unknown-freebsd-gnueabihf-opt12... no checking for armv7-unknown-freebsd-gnueabihf-opt120... no checking for armv7-unknown-freebsd-gnueabihf-opt-11... no checking for armv7-unknown-freebsd-gnueabihf-opt-11.0... no checking for armv7-unknown-freebsd-gnueabihf-opt11... no checking for armv7-unknown-freebsd-gnueabihf-opt110... no checking for armv7-unknown-freebsd-gnueabihf-opt-10... no checking for armv7-unknown-freebsd-gnueabihf-opt-10.0... no checking for armv7-unknown-freebsd-gnueabihf-opt10... no checking for armv7-unknown-freebsd-gnueabihf-opt100... no checking for armv7-unknown-freebsd-gnueabihf-opt-9... no checking for armv7-unknown-freebsd-gnueabihf-opt-9.0... no checking for armv7-unknown-freebsd-gnueabihf-opt9... no checking for armv7-unknown-freebsd-gnueabihf-opt90... no checking for armv7-unknown-freebsd-gnueabihf-opt... no checking for opt-13... no checking for opt-13.0... no checking for opt13... no checking for opt130... no checking for opt-12... no checking for opt-12.0... no checking for opt12... no checking for opt120... no checking for opt-11... no checking for opt-11.0... no checking for opt11... no checking for opt110... no checking for opt-10... no checking for opt-10.0... no checking for opt10... opt10 checking opt10 version (10.0.1) is between 9 and 13... yes . . .
So, the patch you provided fixes the problem for you?
(In reply to Gleb Popov from comment #17) It fixes what I reported and gets much farther along before running into a memory allocation failure in haddock. Overall: yes for the purpose at hand. For reference, though it is a separate issue . . . haddock: out of memory (requested 1048576 bytes) gmake[2]: *** [compiler/ghc.mk:310: compiler/stage2/doc/html/ghc/ghc.haddock] Error 251 gmake[2]: *** Deleting file 'compiler/stage2/doc/html/ghc/ghc.haddock' gmake[1]: *** [Makefile:128: all] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7' ===> Compilation failed unexpectedly. The new out of memory failure seems to be a known issue that the ports tree does not have the update for yet. See: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6224 The end of that is in the last couple of months or so. (But I'm no ghc user. I happen to have tried something that involved this for other reasons.)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=afdc95c40d4f1fb2625f945fc70ecc558d56e6ca commit afdc95c40d4f1fb2625f945fc70ecc558d56e6ca Author: Mark Millard <marklmi26-fbsd@yahoo.com> AuthorDate: 2022-05-30 20:05:34 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2022-05-30 20:08:35 +0000 lang/ghc: Properly dereference a shell variable. This makes GHC build system to pick up correct LLVM tools during the build on ARM. PR: 264192 lang/ghc/files/patch-aclocal.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A commit in branch 2022Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=39e8ccaa065430d6e8ee3baa46c6772f0e02f899 commit 39e8ccaa065430d6e8ee3baa46c6772f0e02f899 Author: Mark Millard <marklmi26-fbsd@yahoo.com> AuthorDate: 2022-05-30 20:05:34 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2022-05-30 20:13:42 +0000 lang/ghc: Properly dereference a shell variable. This makes GHC build system to pick up correct LLVM tools during the build on ARM. PR: 264192 (cherry picked from commit afdc95c40d4f1fb2625f945fc70ecc558d56e6ca) lang/ghc/files/patch-aclocal.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
> haddock: out of memory (requested 1048576 bytes) There is a known problem that GHC runtime is quite memory hungry. This should get better with 9.2 release, which I hope too land to the ports soon. For now, you can disable DOCS option.
Thanks for the report, the analysis and the provided fix!
(In reply to Gleb Popov from comment #21) I'm confused. The Makefile has (and had): OPTIONS_DEFINE= DYNAMIC GMP PROFILE DOCS OPTIONS_DEFAULT= DYNAMIC PROFILE GMP (So DOCS not being a default?) Yet I somehow ended up with: ---Begin OPTIONS List--- ===> The following configuration options are available for ghc-8.10.7_1: DOCS=on: Install HTML documentation DYNAMIC=on: Add support for dynamic linking GMP=on: Use GNU Multi-precision Library for big integers support PROFILE=on: Add support for performance profiling ====> Bootsrap using installed ghc BOOT=off: Use installed GHC for bootstrapping ===> Use 'make config' to modify these settings ---End OPTIONS List--- despite having only: # find /usr/local/etc/ -name 'options' -print /usr/local/etc/poudriere.d/options /usr/local/etc/poudriere.d/options/ports-mgmt_poudriere-devel/options So I'm not sure how folks are to interpret the instruction to disable the already-disabled (?) option. Note: Likely more important to other folks than to me. So more of an FYI relative to me.
(In reply to Mark Millard from comment #13) There is something broken on your system, llc and opt are not installed in the base system. IIRC $2$llvmVersion0 was added back in the days when llvm9 was required, and the binaries were named llc90 / opt90 (instead of llc9 / opt9). It can probably be dropped at this point. This is the build log on my armv7 chroot: checking for armv7-unknown-freebsd-gnueabihf-llc... no checking for llc-13... no checking for llc-13.0... no checking for llc13... no checking for llc... no checking for llc-12... no checking for llc-12.0... no checking for llc12... no checking for llc... no checking for llc-11... no checking for llc-11.0... no checking for llc11... no checking for llc... no checking for llc-10... no checking for llc-10.0... no checking for llc10... llc10 checking llc10 version (10.0.1) is between 9 and 13... yes See also https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6599/diffs
(In reply to Mark Millard from comment #18) This is a problem when building ghc on aarch64 for armv7. It builds fine on real armv7 hw.
Disregard my comment about DOCS option. The haddock tool is run unconditionally.
(In reply to Mikael Urankar from comment #24) llc is installed in main for armv7 . . . From the typescript of an installworld into a directory tree: # grep "\<llc\>" typescript-make-main-CA7-nodbg-clang.aarch64-host.2022-05-15:08:00:42 --- realinstall_subdir_usr.bin/clang/llc --- ===> usr.bin/clang/llc (install) --- realinstall_subdir_usr.bin/clang/llc --- install -N /usr/main-src/etc -o root -g wheel -m 555 llc /usr/obj/DESTDIRs/main-CA7-poud/usr/bin/llc --- realinstall_subdir_usr.bin/clang/llc --- install -N /usr/main-src/etc -o root -g wheel -m 444 llc.debug /usr/obj/DESTDIRs/main-CA7-poud/usr/lib/debug/usr/bin/llc.debug --- realinstall_subdir_usr.bin/clang/llc --- install -N /usr/main-src/etc -o root -g wheel -m 444 llc.1.gz /usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man1/ --- installconfig_subdir_usr.bin/clang/llc --- ===> usr.bin/clang/llc (installconfig) And similalrly for opt. The same happens for aarch64 (CA72 naming in my context).
(In reply to Mikael Urankar from comment #25) Do you mean the haddock memory allocation failure? The correction to the patch file fixed what I originally reported for "armv7 on aarch64" in my context. The haddock issue is separate.
(In reply to Mikael Urankar from comment #24) Perhaps assumptions are being made about the likes of: WITH_ELFTOOLCHAIN_BOOTSTRAP= WITHOUT_LLVM_TARGET_AARCH64= WITH_LLVM_TARGET_ARM= WITHOUT_LLVM_TARGET_MIPS= WITHOUT_LLVM_TARGET_POWERPC= WITHOUT_LLVM_TARGET_RISCV= WITHOUT_LLVM_TARGET_X86= WITH_CLANG= WITH_CLANG_IS_CC= WITH_CLANG_FULL= WITH_CLANG_EXTRAS= WITH_LLD= WITH_LLD_IS_LD= or: WITH_ELFTOOLCHAIN_BOOTSTRAP= WITH_LLVM_TARGET_AARCH64= WITH_LLVM_TARGET_ARM= WITHOUT_LLVM_TARGET_MIPS= WITHOUT_LLVM_TARGET_POWERPC= WITHOUT_LLVM_TARGET_RISCV= WITHOUT_LLVM_TARGET_X86= WITH_CLANG= WITH_CLANG_IS_CC= WITH_CLANG_FULL= WITH_CLANG_EXTRAS= WITH_LLD= WITH_LLD_IS_LD= WITH_LLDB= or the like?
(In reply to Mark Millard from comment #27) No it's not: fetch https://download.freebsd.org/snapshots/arm/armv7/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220519-716fd348e01-255696.img.xz unxz -T0 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220519-716fd348e01-255696.img.xz mdconfig FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220519-716fd348e01-255696.img mount /dev/md0s2a /mnt find /mnt -name llc (yields nothing)
(In reply to Mark Millard from comment #28) Yes, the haddock is only a problem in aarch64 / armv7 context (it works fine on a armv7 board)
(In reply to Mikael Urankar from comment #30) That buiuld does not have: WITH_CLANG_EXTRAS= in use for buildworld. Mine does. For reference: # more /usr/main-src/usr.bin/clang/Makefile . . . .if ${MK_CLANG_EXTRAS} != "no" SUBDIR+= bugpoint SUBDIR+= llc SUBDIR+= lli SUBDIR+= llvm-as SUBDIR+= llvm-bcanalyzer SUBDIR+= llvm-cxxdump SUBDIR+= llvm-diff SUBDIR+= llvm-dis SUBDIR+= llvm-dwarfdump SUBDIR+= llvm-dwp SUBDIR+= llvm-extract SUBDIR+= llvm-link SUBDIR+= llvm-lto SUBDIR+= llvm-lto2 SUBDIR+= llvm-mc SUBDIR+= llvm-mca SUBDIR+= llvm-modextract SUBDIR+= llvm-pdbutil SUBDIR+= llvm-rtdyld SUBDIR+= llvm-xray SUBDIR+= opt .endif . . .
(In reply to Mark Millard from comment #32) More for reference: /usr/main-src/tools/build/mk/OptionalObsoleteFiles.inc has: .if ${MK_CLANG_EXTRAS} == no OLD_FILES+=usr/bin/bugpoint OLD_FILES+=usr/bin/llc OLD_FILES+=usr/bin/lli OLD_FILES+=usr/bin/llvm-as OLD_FILES+=usr/bin/llvm-bcanalyzer OLD_FILES+=usr/bin/llvm-cxxdump OLD_FILES+=usr/bin/llvm-diff OLD_FILES+=usr/bin/llvm-dis OLD_FILES+=usr/bin/llvm-dwarfdump OLD_FILES+=usr/bin/llvm-dwp OLD_FILES+=usr/bin/llvm-extract OLD_FILES+=usr/bin/llvm-link OLD_FILES+=usr/bin/llvm-lto OLD_FILES+=usr/bin/llvm-lto2 OLD_FILES+=usr/bin/llvm-mc OLD_FILES+=usr/bin/llvm-mca OLD_FILES+=usr/bin/llvm-modextract OLD_FILES+=usr/bin/llvm-pdbutil OLD_FILES+=usr/bin/llvm-rtdyld OLD_FILES+=usr/bin/llvm-xray OLD_FILES+=usr/bin/opt OLD_FILES+=usr/share/man/man1/bugpoint.1.gz OLD_FILES+=usr/share/man/man1/llc.1.gz OLD_FILES+=usr/share/man/man1/lli.1.gz OLD_FILES+=usr/share/man/man1/llvm-as.1.gz OLD_FILES+=usr/share/man/man1/llvm-bcanalyzer.1.gz OLD_FILES+=usr/share/man/man1/llvm-diff.1.gz OLD_FILES+=usr/share/man/man1/llvm-dis.1.gz OLD_FILES+=usr/share/man/man1/llvm-dwarfdump.1 OLD_FILES+=usr/share/man/man1/llvm-extract.1.gz OLD_FILES+=usr/share/man/man1/llvm-link.1.gz OLD_FILES+=usr/share/man/man1/llvm-pdbutil.1.gz OLD_FILES+=usr/share/man/man1/opt.1.gz .endif
[A similar submittal of again having the wrong mix of llc versions in use may need to be submitted.] For ghc-9.2.4 builds, should the early: /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7-boot/lib/ghc-8.10.7/bin/ghc . . . related command activity be using: /usr/local/llvm12/bin/llc . . . commands? Or should it be using: /usr/local/llvm10/bin/llc . . . commands? What I see is only /usr/local/llvm12/bin/llc based despite the Makefile file listing BOOT_LLVM_VERSION as 10: LLVM_VERSION?= 12 BOOT_GHC_VERSION= 8.10.7 # LLVM version that bootstrap compiler uses BOOT_LLVM_VERSION= 10 I ask because the existing builds on the servers for armv7 again look like they did for when this was submitted, where an incorrect mix of llc versions had been in use. The failure is now before the haddock issues again, as well. (The below is from my personal test build so I would watch the build commands, instead of being from the FreeBSD build servers.) LLVM ERROR: out of memory Allocation failed PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align /tmp/ghc24288_0/ghc_6.bc -o /tmp/ghc24288_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc24288_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"s17Rl_info$def"' LLVM ERROR: out of memory Allocation failed HC [stage 1] libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/PreProcess.o `llc12' failed in phase `LLVM Compiler'. (Exit code: -6) gmake[2]: *** [compiler/ghc.mk:288: compiler/stage2/build/GHC/Hs/Instances.p_o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [Makefile:128: all] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/ghc/work/ghc-9.2.4' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 If: /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7-boot/lib/ghc-8.10.7/bin/ghc . . . should use: /usr/local/llvm10/bin/llc . . . then a new problem looks like it would need submittal and fixing. For reference, the recent http://ampere2.nyi.freebsd.org/data/main-armv7-default/p85ef7d020401_s0fd8d3589/logs/errors/ghc-9.2.4.log lists: LLVM ERROR: out of memory Allocation failed PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align /tmp/ghc22379_0/ghc_6.bc -o /tmp/ghc22379_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc22379_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"s17Rl_info$def"' HC [stage 1] compiler/stage2/build/GHC/StgToCmm/Monad.p_o `llc12' failed in phase `LLVM Compiler'. (Exit code: -6) gmake[2]: *** [compiler/ghc.mk:288: compiler/stage2/build/GHC/Hs/Instances.p_o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [Makefile:128: all] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/ghc/work/ghc-9.2.4' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1
(In reply to Mark Millard from comment #34) Note: Having gotten some sleep, I sent a variant of the #34 text to the list instead of using closed defect report to report the apparent problem. Sorry for the noise here.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3ef9df6fa282cf733d3b67b327af644cd02ba3ff commit 3ef9df6fa282cf733d3b67b327af644cd02ba3ff Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2022-08-26 19:01:03 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2022-08-26 19:01:55 +0000 lang/ghc: Use correct LLVM toolchain for the bootstrap compiler. PR: 264192 Reported by: Mark Millard <marklmi26-fbsd@yahoo.com> lang/ghc/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to commit-hook from comment #36) For: -BOOT_CONFIGURE_ENV_OFF= GHC=${BOOT_GHC} +BOOT_CONFIGURE_ENV_OFF= GHC=${BOOT_GHC} LLC=llc${BOOT_LLVM_VERSION} OPT=opt${BOOT_LLVM_VERSION} does something need to control what CLANG and CC translate to? Somewhat older lang/ghc/Makefile content did so, not just LLC and OPT.
(In reply to Mark Millard from comment #37) Nope, CC and friends are already passed by Ports Framework.
(In reply to Gleb Popov from comment #38) I'm confused. How does the Ports Framework know when to use LLVM10 clang (bootstrap 8.10.7) vs. LLVM12 clang (9.2.4)? (No system-clang use as far as I can tell.) As far as I can tell, LLC and OPT and clang use have to match for each of the two types of sub-builds --unless there is no clang use at all. Mixing LLVM10, LLVM12, and/or system-clang materials looks to be incoherent.
(In reply to Mark Millard from comment #39) CC is always the base clang, it is unrelated to ports LLVM.
(In reply to Gleb Popov from comment #40) You have not answered how lang/ghc/Makefile leads to bootstrap 8.10.7 using LLVM10's clang for/during its build. There is evidence of use: # grep -r "\<CC\>" work/ghc-8.10.7-boot/ | more Binary file work/ghc-8.10.7-boot/utils/ghc-cabal/dist-install/build/tmp/ghc-cabal matches Binary file work/ghc-8.10.7-boot/utils/ghc-pkg/dist-install/build/tmp/ghc-pkg matches Binary file work/ghc-8.10.7-boot/utils/iserv/stage2/build/tmp/ghc-iserv matches work/ghc-8.10.7-boot/mk/config.mk.in:# NB. Don't override $(CC) using build.mk, re-configure using work/ghc-8.10.7-boot/mk/config.mk.in:# the flag CC=<blah> instead. The reason is that the configure script work/ghc-8.10.7-boot/mk/config.mk.in:CC = @CC@ work/ghc-8.10.7-boot/mk/config.mk.in:CC_STAGE1 = $(CC) work/ghc-8.10.7-boot/mk/config.mk.in:CC_STAGE2 = $(CC) work/ghc-8.10.7-boot/mk/config.mk.in:CC_STAGE3 = $(CC) work/ghc-8.10.7-boot/mk/config.mk.in:AS = @CC@ work/ghc-8.10.7-boot/includes/ghc.mk:DERIVE_CONSTANTS_FLAGS += --gcc-program "$(CC)" . . . # grep -r "\<CLANG\>" work/ghc-8.10.7-boot/ | more work/ghc-8.10.7-boot/mk/config.mk.in:CLANG = @ClangCmd@ Similarly for how lang/ghc/Makefile leads to 9.2.4 using LLVM12's clang for/during its build. There is evidence of use: # grep -r "\<CC\>" work/ghc-9.2.4/ | more work/ghc-9.2.4/configure:CC work/ghc-9.2.4/configure:CC work/ghc-9.2.4/configure:To assign environment variables (e.g., CC, CFLAGS...), specify them as work/ghc-9.2.4/configure: --with-gcc=ARG Use ARG as the path to gcc (obsolete, use CC=ARG work/ghc-9.2.4/configure: --with-clang=ARG Use ARG as the path to clang (obsolete, use CC=ARG work/ghc-9.2.4/configure: CC C compiler command work/ghc-9.2.4/configure:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' work/ghc-9.2.4/configure:ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' work/ghc-9.2.4/configure: CC="${mingwbin}gcc.exe" . . . # grep -r "\<CLANG\>" work/ghc-9.2.4/ | more work/ghc-9.2.4/configure:CLANG work/ghc-9.2.4/configure:CLANG work/ghc-9.2.4/configure: CLANG Use as the path to clang [default=autodetect] work/ghc-9.2.4/configure: if test -n "$CLANG"; then work/ghc-9.2.4/configure: ac_cv_prog_CLANG="$CLANG" # Let the user override the test. work/ghc-9.2.4/configure:CLANG=$ac_cv_prog_CLANG work/ghc-9.2.4/configure:if test -n "$CLANG"; then work/ghc-9.2.4/configure: { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $CLANG" >&5 work/ghc-9.2.4/configure:printf "%s\n" "$CLANG" >&6; } work/ghc-9.2.4/configure: ac_ct_CLANG=$CLANG work/ghc-9.2.4/configure: CLANG=$ac_ct_CLANG work/ghc-9.2.4/configure: CLANG="" work/ghc-9.2.4/configure: CLANG="$ac_cv_prog_CLANG" work/ghc-9.2.4/configure:ClangCmd="$CLANG" . . .
(In reply to Mark Millard from comment #41) For work/ghc-8.10.7-boot/mk/config.mk.in : . . . #----------------------------------------------------------------------------- # C compiler # # NB. Don't override $(CC) using build.mk, re-configure using # the flag CC=<blah> instead. The reason is that the configure script # needs to know which gcc you're using in order to perform its tests. # TargetPlatformFull retains the string passed to configure so we have it in # the necessary format to pass to libffi's configure. TargetPlatformFull = @TargetPlatformFull@ # Do we have a C compiler using an LLVM back end? CcLlvmBackend = @CcLlvmBackend@ CC = @CC@ CC_STAGE0 = @CC_STAGE0@ CC_STAGE1 = $(CC) CC_STAGE2 = $(CC) CC_STAGE3 = $(CC) AS = @CC@ AS_STAGE0 = @CC_STAGE0@ AS_STAGE1 = $(AS) AS_STAGE2 = $(AS) AS_STAGE3 = $(AS) # why no LD=@LD@ ? LD_STAGE0 = @LD_STAGE0@ LD_STAGE1 = $(LD) LD_STAGE2 = $(LD) LD_STAGE3 = $(LD) . . . LD = @LdCmd@ NM = @NmCmd@ AR = @ArCmd@ OBJDUMP = @ObjdumpCmd@ CLANG = @ClangCmd@ LLC = @LlcCmd@ OPT = @OptCmd@ And for work/ghc-9.2.4/configure : Optional Packages: . . . --with-gcc=ARG Use ARG as the path to gcc (obsolete, use CC=ARG instead) [default=autodetect] --with-clang=ARG Use ARG as the path to clang (obsolete, use CC=ARG instead) [default=autodetect] . . .
(In reply to Mark Millard from comment #42) The system is busy and will be for some time. I'll not be able to set up a context for monitoring if/what compilers are used during either of the 2 sub-builds until later. So, until I've done so and reported on what I observe, it may be best to ignore my questions in this area.
(In reply to Mark Millard from comment #43) For my future reference ( from work/ghc-9.2.4/configure ): Some influential environment variables: GHC Use as the path to GHC [default=autodetect] CC_STAGE0 C compiler command (bootstrap) LD_STAGE0 Linker command (bootstrap) AR_STAGE0 Archive command (bootstrap) RTS_WAYS_STAGE0 RTS ways SH Use as the full path to a Bourne shell. [default=autodetect] CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> LIBS libraries to pass to the linker, e.g. -l<library> CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor LD Use as the path to ld. See also --disable-ld-override. CLANG Use as the path to clang [default=autodetect] LLC Use as the path to LLVM's llc [default=autodetect] OPT Use as the path to LLVM's opt [default=autodetect] HAPPY Use as the path to happy [default=autodetect] ALEX Use as the path to alex [default=autodetect] Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations.
(In reply to Mark Millard from comment #41) > You have not answered how lang/ghc/Makefile leads to bootstrap 8.10.7 using LLVM10's clang for/during its build. The clang used is always /usr/bin/clang. It doesn't have to match LLVM version used.
(In reply to Gleb Popov from comment #45) Yea, looking at the lang/ghc810 result (that makes it all the way to haddock's out of memory) does indicate that it was okay with the mix, no need for CLANG and CC control. Sorry for the noise relative to CLANG and CC. At least the LLC and OPT part of my activity proved useful.
(In reply to Mark Millard from comment #34) I wonder if armv7 (and armv6 and 32 bit powerpc) should be marked for being ignored or as broken for lang/ghc* . This is based in part on the below. I built an aarch64 llvm12 and used its llc to process a copy of the ghc_6.bc involved in the armv7 allocation failure context --under a time -l command: 4275764 maximum resident set size So a little over 4 GiBytes resident at some point. (armv7 based processing goes over 2 GiBytes for sure, same file content being processed.) The aarch64 llc did run to completion. With --stats and --time-passes there was the output: ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 267.3322 seconds (271.6376 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 138.2117 ( 58.9%) 7.5446 ( 23.1%) 145.7563 ( 54.5%) 152.2172 ( 56.0%) ARM Instruction Selection 19.4413 ( 8.3%) 11.4447 ( 35.0%) 30.8859 ( 11.6%) 30.4681 ( 11.2%) ARM Assembly Printer 9.1118 ( 3.9%) 1.7649 ( 5.4%) 10.8767 ( 4.1%) 10.1547 ( 3.7%) Greedy Register Allocator . . . 234.6558 (100.0%) 32.6764 (100.0%) 267.3322 (100.0%) 271.6376 (100.0%) Total . . . LLVM IR Parsing ===-------------------------------------------------------------------------=== Total Execution Time: 25.9741 seconds (25.9732 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 24.5730 (100.0%) 1.4011 (100.0%) 25.9741 (100.0%) 25.9732 (100.0%) Parse IR 24.5730 (100.0%) 1.4011 (100.0%) 25.9741 (100.0%) 25.9732 (100.0%) Total . . . Instruction Selection and Scheduling ===-------------------------------------------------------------------------=== Total Execution Time: 113.1396 seconds (118.8488 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 46.0782 ( 42.4%) 0.9671 ( 21.4%) 47.0452 ( 41.6%) 50.7440 ( 42.7%) DAG Combining 1 18.3827 ( 16.9%) 0.4413 ( 9.8%) 18.8240 ( 16.6%) 19.8558 ( 16.7%) DAG Combining 2 12.1597 ( 11.2%) 0.1607 ( 3.6%) 12.3204 ( 10.9%) 13.0605 ( 11.0%) DAG Combining after legalize types 10.6380 ( 9.8%) 0.4853 ( 10.7%) 11.1233 ( 9.8%) 11.6023 ( 9.8%) Instruction Selection 9.5097 ( 8.8%) 0.7766 ( 17.2%) 10.2863 ( 9.1%) 10.3773 ( 8.7%) Instruction Scheduling . . . 108.6230 (100.0%) 4.5166 (100.0%) 113.1396 (100.0%) 118.8488 (100.0%) Total The recent armv7 failure examples via ghc 9 stage activity have all reported llc failure during: Running pass 'ARM Instruction Selection' as well. Older ghc (8.10.7) hit the haddock related memory allocation failures on armv7.
(In reply to Mark Millard from comment #47) I'm able to build ghc on armv7 (tegra k1 board). haddock failed at first (due to multiple jobs running) and then succeeded: haddock: out of memory (requested 1048576 bytes) check-plist and stage-qa are ok
(In reply to Mikael Urankar from comment #48) That is 9.2.4 or so that you built --via llvm12 for the 9.2.4 stages? I do not get anywhere near haddock's stage for it. (I did for 8.10.7, last I tried.) I see the same 9.2.4 and 8.7.10 status when I look at the FreeBSD build server log failures. Notably, for the 9.2.4 context, it is llc that runs out of memory processing a specific file and top does not indicate that multi-threading is in use for that in my context. I wonder if the content of the input file varies or if it is only llc itself that is at issue. GHC/Hs/Instances gets a ghc_6.bc that is what gets the failure in my context. I've a copy of that ghc_6.bc and running the armv7 LLVM12 llc command independently on it gets the out of memory problem. (The aarch64 llvm12 llc processes it just fine, but uses far more than 2 GiBytes in its processing in order to do so.) The only armv7-only system that I have access to is a Orange Pi Plus 2E. As I remember, build experiments on this took a very long time. But the llc / ghc_6.bc file experiment might be more reasonable if I get the OPi+2e set up for it. I might try that. Another possibility is that llvm12 builds differently on armv7-only hardware vs. on aarch64+armv7 hardware used for armv7 --so that the llc's are not equivalent.
(In reply to Mark Millard from comment #49) On the OPi+2e (so a Cortex-A7 form of armv7 -- without aarch64 present), UFS context, I tried: # /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc -o ghc2478_0/ghc_7.lm_s Ultimately, lcc on the OPi+2e, processing the ghx_6.bc in question, got: # /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc -o ghc2478_0/ghc_7.lm_s LLVM ERROR: out of memory Allocation failed PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc -o ghc2478_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module 'ghc2478_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"clp2g_info$def"' #0 0x221ac0a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20ac0a0) #1 0x221a9d1c llvm::sys::RunSignalHandlers() (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20a9d1c) #2 0x221acd08 (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20acd08) #3 0x24d2eed8 handle_signal /usr/main-src/lib/libthr/thread/thr_sig.c:0:3 Abort trap (core dumped) But it was interesting to watch: direct armv7 does not limit processes to 2 GiBytes of SIZE (as top lables it) but keeps the RES under 2 GiBytes --but aarch64's handling of chroot to armv7 prevents getting to such a state if I remember right. On the OPi+2e, before the failure: PID JID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 1291 0 root 25 0 2489Mi 1705Mi biowr 2 23:02 6.72% /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc For reference, from shortly before the process did fail for out of memory: (modified variant of top that tracks various "Maximum Observed" figures) Mem: . . ., 1680Mi MaxObsActive, 190356Ki MaxObsWired, 1932Mi MaxObs(Act+Wir+Lndry) Swap: 3072Mi Total, 1014Mi Used, 2058Mi Free, 33% Inuse, 1014Mi MaxObsUsed, 2708Mi MaxObs(Act+Lndry+SwapUsed), 2888Mi MaxObs(Act+Wir+Lndry+SwapUsed) I'm rerunning with time -l and will report the result.
(In reply to Mark Millard from comment #50) The "time -l" results: # time -l /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc -o ghc2478_0/ghc_7.lm_s LLVM ERROR: out of memory Allocation failed PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc -o ghc2478_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module 'ghc2478_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"clp2g_info$def"' #0 0x221ac0a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20ac0a0) #1 0x221a9d1c llvm::sys::RunSignalHandlers() (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20a9d1c) #2 0x221acd08 (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20acd08) #3 0x24d2eed8 handle_signal /usr/main-src/lib/libthr/thread/thr_sig.c:0:3 time: command terminated abnormally 1718.54 real 1364.81 user 52.56 sys 1789944 maximum resident set size 43 average shared memory size 7 average unshared data size 239 average unshared stack size 1215088 page reclaims 50009 page faults 0 swaps 27735 block input operations 123535 block output operations 0 messages sent 0 messages received 1 signals received 209286 voluntary context switches 16725 involuntary context switches Abort trap And, shortly before the failure: Mem: 1440Mi Active, 217184Ki Inact, 83552Ki Laundry, 186812Ki Wired, 107716Ki Buf, 45980Ki Free, 1674Mi MaxObsActive, 189672Ki MaxObsWired, 1918Mi MaxObs(Act+Wir+Lndry) Swap: 3072Mi Total, 1029Mi Used, 2043Mi Free, 33% Inuse, 1029Mi MaxObsUsed, 2724Mi MaxObs(Act+Lndry+SwapUsed), 2902Mi MaxObs(Act+Wir+Lndry+SwapUsed) PID JID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 1406 0 root 24 0 2489Mi 1684Mi CPU1 1 23:34 8.27% /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc
(In reply to Mark Millard from comment #51) Confirming the aarch64 chroot to armv7 shows a 2 GiByte limitation instead what direct armv7 shows . . . On a Cortex-A72's based system (UFS), chroot'd into an armv7 context: # time -l /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc -o ghc2478_0/ghc_7.lm_s LLVM ERROR: out of memory Allocation failed PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc -o ghc2478_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module 'ghc2478_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"rRIA_info$def"' #0 0x422ac0a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20ac0a0) #1 0x422a9d1c llvm::sys::RunSignalHandlers() (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20a9d1c) #2 0x422acd08 (/usr/local/llvm12/bin/../lib/libLLVM-12.so+0x20acd08) #3 0x400eaed8 handle_signal /usr/main-src/lib/libthr/thread/thr_sig.c:0:3 time: command terminated abnormally 228.25 real 214.27 user 11.41 sys 1927128 maximum resident set size 43 average shared memory size 7 average unshared data size 238 average unshared stack size 1036170 page reclaims 134 page faults 0 swaps 17472 block input operations 88235 block output operations 0 messages sent 0 messages received 1 signals received 136543 voluntary context switches 3185 involuntary context switches Abort trap Just before/during the process crash top showed just a little below 2 GiBytes (2046 MiBytes) for SIZE for the llc process, never showing more than 2048 MiBytes: PID JID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 1118 0 root 52 0 2046Mi 1880Mi CPU9 9 3:38 85.00% /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/ghc_6.bc 1117 0 root 21 0 4352Ki 1596Ki wait 12 0:00 0.00% time -l /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ghc2478_0/
(In reply to Mark Millard from comment #49) I've just typed "make" in lang/ghc with 3ef9df6fa282cf733d3b67b327af644cd02ba3ff
(In reply to Mikael Urankar from comment #53) I looked up the Tegra K1: The armv7 variant T124 has Cortex-A15's with LPAE (limited to 8 GiBytes). Does FreeBSD do anything to support the LPAE? If yes, might that lead to a larger maximum process size in FreeBSD? Be that as it may, is there any chance that you could use, say, top and watch llvm12's llc command's SIZE for the: HC [stage 1] compiler/stage2/build/GHC/Hs/Instances.p_o to see how large it grows? If it stays smaller than 2 GiBytes, that would indicate a different direction of investigation than if it grows larger (the current status of the investigation). Also, how large a SIZE for a successful llc would be of interest itself.
(In reply to Mark Millard from comment #54) Hmm. a normal build of top might not show enough significant digits for near or above 2G for SIZE to allow for reasonable comparisons. That specific aspect of what I wrote (tool to use) may have some better alternative. Separately . . . The OPi+2e has LPAE as well, but only 2 GiBytes of RAM: CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features: Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7, PXN, LPAE, Coherent Walk Optional instructions: SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory = 2113273856 (2015 MB) avail memory = 2053693440 (1958 MB)
(In reply to Mikael Urankar from comment #31) Just a summary note about the status of my armv7 experiments, and that I'm going to stop attempting them. I'll not even be tracking the armv7 or aarch64 status any more. > Yes, the haddock is only a problem in aarch64 / armv7 context (it works > fine on a armv7 board) But not on other armv7 boards, in my context: The Orange Pi Plus 2E does not manage to build it, failing well before haddock is the issue. (Other, earlier comments have some details.) So far as I know, no one has managed to isolate specific criteria for what it takes to allow builds to work on armv7 --or for armv7 via an aarch64 that can execute armv7 code. (Likely a similar point goes for "on armv6".) Possibly it is just the process size limit and memory usage both being sufficiently large. But no one has indicated a pair of figures that are known to work if the armv7 context allows the sizes. I do not have a context that can explore that: too limited for the process size at least.