Created attachment 214222 [details]
make NO_CLEAN=yes buildworld
I've tried routinely perform source upgrade of 11.2-STABLE/i386 r341008 (clang6) upto stable/11/i386 r360772. The build fails at "stage 3: cross tools":
c++: error: unable to execute command: Abort trap (core dumped)
c++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
This is the same with and without CPUTYPE?=core2 in /etc/make.conf; with and without following in /etc/src.conf:
See attached files for full build log and generated debugging info.
Created attachment 214223 [details]
auto-generated by clang
Created attachment 214224 [details]
preprocessed AArch64InstPrinter-5a6d13.cpp (xz-compressed)
It seems the problem is related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242266 (or same).
Created attachment 214225 [details]
Dimitry, please take a look at this.
As temporary work-around, I update to stable/11 r360655 (5 May 2020 before import of clang-9) instead of tip of stable/11.
Yeah, this looks about the same. I tried installing 11.2-RELEASE which comes with clang version 6.0.0 (tags/RELEASE_600/final 326565), and that gives:
$ /usr/bin/time -l clang -cc1 -triple i386-unknown-freebsd11.2 -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name AArch64InstPrinter.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -dwarf-column-info -debugger-tuning=gdb -ffunction-sections -fdata-sections -coverage-notes-file /usr/obj/home/src/tmp/home/src/lib/clang/libllvm/Target/AArch64/MCTargetDesc/AArch64InstPrinter.gcno -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D HAVE_VCS_VERSION_INC -D NDEBUG -D LLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.4\" -D LLVM_HOST_TRIPLE=\"i386-unknown-freebsd11.4\" -D DEFAULT_SYSROOT=\"/usr/obj/home/src/tmp\" -D LLVM_TARGET_ENABLE_AARCH64 -D LLVM_TARGET_ENABLE_ARM -D LLVM_TARGET_ENABLE_MIPS -D LLVM_TARGET_ENABLE_POWERPC -D LLVM_TARGET_ENABLE_SPARC -D LLVM_TARGET_ENABLE_X86 -D LLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -D LLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -D LLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -D LLVM_NATIVE_TARGET=LLVMInitializeX86Target -D LLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -D LLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -O2 -Wno-c++11-extensions -std=c++11 -fdeprecated-macro -ferror-limit 19 -fmessage-length 0 -fno-rtti -fobjc-runtime=gnustep -fdiagnostics-show-option -vectorize-loops -vectorize-slp -x c++ AArch64InstPrinter-5a6d13.cpp
165.43 real 30.21 user 45.18 sys
3876424 maximum resident set size
60691 average shared memory size
436 average unshared data size
271 average unshared stack size
4423574 page reclaims
130240 page faults
0 block input operations
5 block output operations
0 messages sent
0 messages received
0 signals received
130255 voluntary context switches
958 involuntary context switches
so it takes ~3.7 GiB and a *long* time to compile, though it does not crash.
With -O1, it takes about 20 seconds and ~250 MiB instead, so I suggest using that for now.
I don't think that default FreeBSD 11.2/i386 allows userland process to take 3.7GB.
Is it possible to force buildworld to use -O1 for this specific part of bootstrap so it would work "out of the box"?
(In reply to Eugene Grosbein from comment #8)
Hm as a crutch we could add something to llvm.build.mk to lower the optimization level when TOOLS_PREFIX is unset (e.g. when the cross-tools stage is run). @emaste what's your opinion on this?
E.g. adding something like:
# Lower optimization level to increase probability of successful bootstrap
That is rather ugly though. I'd rather have people with low-spec systems use CFLAGS=-O1 in their /etc/make.conf or /etc/src.conf, or simply use external toolchains.
My system is not low-spec.
real memory = 4294967296 (4096 MB)
avail memory = 3142152192 (2996 MB)
This is very old server installed when FreeBSD/amd64 was not ready for production and updated over time staying i386.
Source upgrade path should work for i386, I believe.
Is it possible to turn on PAE as a workaround?
PAE would be much worse "workaround".
(In reply to Eugene Grosbein from comment #12)
Depends on your point of view. I'm suggesting it in this case, not in gereral. It is likely to work, and addresses the actual issue rather directly.
(In reply to Dimitry Andric from comment #9)
Maybe the equivalent of:
.if !defined(TOOLS_PREFIX) && defined(IS_A_32BIT_BUILD_HOST)