Building world with WITH_ASAN= I hit this near the end of the build: markj@nuc> sh archive_read_support_format_tar-29e157.sh Assertion failed: (!Op->getType()->isPointerTy() && "Can't extend pointer!"), function getZeroExtendExpr, file /root/freebsd/contrib/llvm-project/llvm/lib/Analysis/ScalarEvolution.cpp, line 1582. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/bin/cc -cc1 -triple i386-unknown-freebsd14.0 -emit-obj --mrelax-relocations -disable-free -main-file-name archive_read_support_format_tar.c -mrelocation-model pic -pic-level 2 -fhalf-no-semantic-interposition -mframe-pointer=all -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu i686 -target-feature +mmx -target-feature +sse -target-feature +sse2 -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=gdb --compress-debug-sections=zlib -fcoverage-compilation-dir=/usr/obj/usr/home/markj/src/freebsd/amd64.amd64/obj-lib32/lib/libarchive -sys-header-deps -D COMPAT_32BIT -D PIC -D HAVE_ICONV=1 -D HAVE_ICONV_H=1 -D ICONV_CONST= -D HAVE_BZLIB_H=1 -D HAVE_LIBLZMA=1 -D HAVE_LZMA_H=1 -D HAVE_ZSTD_H=1 -D HAVE_LIBZSTD=1 -D PLATFORM_CONFIG_H=\"/usr/home/markj/src/freebsd/lib/libarchive/config_freebsd.h\" -D WITH_OPENSSL -O2 -Wno-format-zero-length -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -std=gnu99 -fconst-strings -fdebug-compilation-dir=/usr/obj/usr/home/markj/src/freebsd/amd64.amd64/obj-lib32/lib/libarchive -ferror-limit 19 -fsanitize=address -fsanitize-recover=address -fsanitize-address-use-after-scope -fno-assume-sane-operator-new -stack-protector 2 -fgnuc-version=4.2.1 -vectorize-loops -vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -x c archive_read_support_format_tar-29e157.c 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'archive_read_support_format_tar-29e157.c'. 4. Running pass 'Loop Pass Manager' on function '@tar_read_header' 5. Running pass 'Loop Strength Reduction' on basic block '%while.cond45.i' #0 0x00000000050964e0 PrintStackTrace /root/freebsd/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13 #1 0x00000000050947f5 RunSignalHandlers /root/freebsd/contrib/llvm-project/llvm/lib/Support/Signals.cpp:98:18 #2 0x0000000005096c10 SignalHandler /root/freebsd/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 0x000000080a8e85d0 handle_signal /root/freebsd/lib/libthr/thread/thr_sig.c:0:3 Abort trap (core dumped)
Created attachment 229677 [details] input file
Created attachment 229678 [details] driver
I can reproduce this with recent versions of clang, up to very recent upstream main branch (llvmorg-14-init-10170-gf849640a0c6). It seems to be a regression somewhere between llvmorg-13-init-14958-g1a4d1315650 and llvmorg-13-init-14978-gd919bca8755. I wll pinpoint the exact regression revision, produce a reduced test case, then file an upstream bug report.
Reported upstream as https://bugs.llvm.org/show_bug.cgi?id=52594, with a minimized test case. I think upstream simply added a bunch of sanity checks, and these now fire, most likely due to the limited address space on 32-bit architectures.
This appears to be fixed now (and the corresponding LLVM ticket is closed). The WITH_ASAN build still fails, but now for other reasons. I'll open a new ticket for that.