Re: lang/ghc bootstrap compiler build likely using wrong llc: using /usr/local/llvm12/bin/llc despite BOOT_LLVM_VERSION=10 ( for BOOT_GHC_VERSION=8.10.7 )

From: Mark Millard <marklmi_at_yahoo.com>
Date: Fri, 26 Aug 2022 00:54:06 UTC
On 2022-Aug-25, at 14:07, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Aug-23, at 10:20, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> 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 when a previous incorrect mix of llc versions
>> had been in use. The old example was:
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264192
>> 
>> The fix for that changed the out of memory error behavior at the
>> time. The garbage-in/garbage-out status seemed to lead more out
>> of memory failures.
>> 
>> I've not checked on ld or other toolchain commands but I
>> suppose that if the wrong llc is in use then the wrong
>> versions of other toolchain commands is a possibility
>> that should be looked into.
>> 
>> 
>> OVERALL . . .
>> 
>> If the
>> 
>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7-boot/lib/ghc-8.10.7/bin/ghc . . .
>> 
>> related activity should use:
>> 
>> /usr/local/llvm10/bin/llc . . .
>> 
>> then the port needs to be fixed to use the commands from
>> the right toolchain.
>> 
> 
> Going in a different direction, having gotten llc.core from
> a poudiere bulk -i use to manually run make for lang/ghc
> for this armv7 via aarchh64 context . . .
> 
. . . (old backtrace removed) . . .

Replaced with a better llc backtrace based on now having a
copy of the ghc_6.bc input file in question:

# gdb /usr/local/llvm12/bin/llc
. . .
(gdb) run -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ./ghc2478_0/ghc_6.bc -o ./ghc2478_0/ghc_7.lm_s
Starting program: /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

Program received signal SIGABRT, Aborted.
Sent by thr_kill() from pid 32295 and user 0.
0x450240e4 in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x450240e4 in thr_kill () from /lib/libc.so.7
#1  0x44f9770c in raise () from /lib/libc.so.7
#2  0x4504f680 in abort () from /lib/libc.so.7
#3  0x421f703c in llvm::report_bad_alloc_error(char const*, bool) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#4  0x421f7130 in ?? () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#5  0x44edb94c in operator new(unsigned int) () from /lib/libc++.so.1
#6  0x42768518 in std::__1::vector<llvm::SUnit, std::__1::allocator<llvm::SUnit> >::reserve(unsigned int) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#7  0x42931678 in llvm::ScheduleDAGSDNodes::BuildSchedUnits() () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#8  0x4293231c in llvm::ScheduleDAGSDNodes::BuildSchedGraph(llvm::AAResults*) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#9  0x429280cc in ?? () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#10 0x429c08cc in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#11 0x429c0490 in llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, bool&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#12 0x429bfda4 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#13 0x429bdf0c in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#14 0x43e76cc8 in ?? () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#15 0x425f1440 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#16 0x423f1a90 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#17 0x423f79e4 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#18 0x423f208c in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so
#19 0x0002fc70 in main ()
(gdb) 

(So: before llc itself tries to deal with producing a
backtrace.)

> 
> It looks like the out of memory happens during llvm::sys::PrintStackTrace
> related activity that was initiated during llvm::sys::RunSignalHandlers .
> In other words: some other problem happened but the backtrace handling is
> leading to a later problem that hides the original problem --or it looks
> like such might be the case.
> 
> It seems vaguely familiar that armv7 backtraces were problematical
> in other examples of code that tried to print its own backtraces.
> But, at this point, I do not remember any details.
> 
> 
> For reference:
> 
> The actual llc command reported is, in full:
> 
> /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align /tmp/ghc64754_0/ghc_6.bc -o /tmp/ghc64754_0/ghc_7.lm_s
> 
(. . . removed note about not having ghc_6.bc . . .)
> 
> # ls -Tld llc.core
> -rw-------  1 root  wheel  2064687104 Aug 25 19:40:34 2022 llc.core
> 
> Also, I was using:
> 
> # git -C /usr/ports/ diff lang/ghc
> diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
> index 5939c5a318d7..aa2c64bfc1ea 100644
> --- a/lang/ghc/Makefile
> +++ b/lang/ghc/Makefile
> @@ -142,12 +142,16 @@ post-patch-BOOT-off:
>        @${REINPLACE_CMD} -e '/^docdir/d' ${BOOT_DIR}/mk/build.mk
>        @${REINPLACE_CMD} -e '/^htmldir/d' ${BOOT_DIR}/mk/build.mk
> 
> +CONFIGURE_ENV_BOOTSTRAP=LLC=llc${BOOT_LLVM_VERSION} \
> +                       OPT=opt${BOOT_LLVM_VERSION} \
> +                       CLANG=clang${BOOT_LLVM_VERSION} \
> +                       CC=clang${BOOT_LLVM_VERSION}
> pre-configure:
>        # Call the bootstrap script
>        cd ${WRKSRC}/ && ./boot
> # If we are using bootstrap compiler, configure and install it into ${BOOT_DIR}
> .if empty(PORT_OPTIONS:MBOOT)
> -       cd ${BOOT_DIR} && ${CONFIGURE_ENV} ${CONFIGURE_CMD} --prefix=${BOOT_DIR}
> +       cd ${BOOT_DIR} && ${CONFIGURE_ENV} ${CONFIGURE_ENV_BOOTSTRAP} ${CONFIGURE_CMD} --prefix=${BOOT_DIR}
>        cd ${BOOT_DIR} && PACKAGES='' ${MAKE_CMD} install
> .endif
> 
> 
> in order to have llvm10's tools in use for 8.10.7 activity and
> llvm12's tools in use for 9.2.4 activity. (But I could be wrong
> about such being necessary. It certainly is not sufficient by
> itself for the overall build to work.)
> 


===
Mark Millard
marklmi at yahoo.com