Since ~05/16/2022 amd64 build for math/vtk8 crashes clang. 1. <eof> parser at end of file 2. Optimizer #0 0x0000000004a64c90 (/usr/bin/c+++0x4a64c90) #1 0x0000000004a62f58 (/usr/bin/c+++0x4a62f58) #2 0x0000000004a141a4 (/usr/bin/c+++0x4a141a4) #3 0x0000000004a1438c (/usr/bin/c+++0x4a1438c) #4 0x0000000089b1d3a8 (/lib/libthr.so.3+0x293a8) c++: error: clang frontend command failed with exit code 134 (use -v to see invocation) FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) Target: aarch64-unknown-freebsd14.0
Are there preprocessed .cpp and .sh files available?
(In reply to Dimitry Andric from comment #1) I only got fallout messages.
I don't have access to aarch64 machines which can build ports, so somebody(TM) should maybe write a feature for poudriere that can lift out these crash reports... ;-)
(In reply to Dimitry Andric from comment #3) Downloading the log file from one of the recent failed builds and looking farther back in the log than what has been reported so far I find an "Assertion failed" notice: Assertion failed: (!getDef() && "VPValue is not a live-in; it is defined by a VPDef inside a VPlan"), function getLiveInIRValue, file /usr/local/poudriere/jails/main-arm64/usr/src/contrib/llvm-project/llvm/lib/Transforms/Vectorize/VPlanValue.h, line 188. 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/c++ -DVTK_IN_VTK -DvtkGeovisCore_EXPORTS -I/wrkdirs/usr/ports/math/vtk8/work/.build/Geovis/Core . . . (skipping many -I options) . . . -I/wrkdirs/usr/ports/math/vtk8/work/.build/ThirdParty/libproj/vtklibproj/src -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fPIC -fvisibility=hidden -std=c++11 -MD -MT Geovis/Core/CMakeFiles/vtkGeovisCore.dir/vtkGeoInteractorStyle.cxx.o -MF Geovis/Core/CMakeFiles/vtkGeovisCore.dir/vtkGeoInteractorStyle.cxx.o.d -o Geovis/Core/CMakeFiles/vtkGeovisCore.dir/vtkGeoInteractorStyle.cxx.o -c /wrkdirs/usr/ports/math/vtk8/work/VTK-8.2.0/Geovis/Core/vtkGeoInteractorStyle.cxx 1. <eof> parser at end of file 2. Optimizer #0 0x0000000004a64c90 (/usr/bin/c+++0x4a64c90) #1 0x0000000004a62f58 (/usr/bin/c+++0x4a62f58) #2 0x0000000004a141a4 (/usr/bin/c+++0x4a141a4) #3 0x0000000004a1438c (/usr/bin/c+++0x4a1438c) #4 0x000000008a3383a8 (/lib/libthr.so.3+0x293a8) c++: error: clang frontend command failed with exit code 134 (use -v to see invocation) FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) Target: aarch64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/vtkGeoInteractorStyle-010919.cpp c++: note: diagnostic msg: /tmp/vtkGeoInteractorStyle-010919.sh c++: note: diagnostic msg: May be that will help a little.
I tried a build targeting armv7 and it completed okay. I replicated the failure for targeting aarch64, using bulk -w -i . But the -i only shows the following in /tmp : # ls -Tldt /tmp/* -rw-r--r-- 1 root wheel 0 Jun 25 10:08:38 2022 /tmp/su-to-portbuild drwxr-xr-x 2 root wheel 7 Jun 25 10:08:03 2022 /tmp/packages Looking: it executes in /usr/local/poudriere/data/.m/main-CA72-default/ref/ and no numbered main-CA72-default/*/ exist at the time. So the relevant tmp/ has been cleaned out already. I was able to expand the -w created archive and re-execute the failing command and get the (or a) failure. I'll see about trying to get a .txz of the .cpp and .sh from tmp/ as an attachment. (No web browser or GUI for the aarch64 machine involved. So things are less direct. I'm not aware of a way to directly add the attachment to this bugzilla entry from such a context.) Note: My buildworld has clang built without assertions but it still fails. Thus the assertion failure would be unlikely to be a false positive.
Created attachment 234935 [details] Contains the /tmp/*.cpp and /tmp/*.sh from my replication effort
(In reply to Dimitry Andric from comment #3) FYI, relative to potential build infrastructure behavior, clang/clang++ has: QUOTE -fcrash-diagnostics-dir=<dir> Specify where to write the crash diagnostics files; defaults to the usual location for temporary files. END QUOTE So redirecting to someplace that poudriere(-devel) with -w includes in the (compressed) tar archive for build failures is a possibility.
(In reply to Dimitry Andric from comment #3) Using: # git -C /usr/ports/ diff math/vtk8 diff --git a/math/vtk8/Makefile b/math/vtk8/Makefile index 37d002652672..b38ed248c7d9 100644 --- a/math/vtk8/Makefile +++ b/math/vtk8/Makefile @@ -11,7 +11,7 @@ COMMENT= Visualization toolkit LICENSE= BSD3CLAUSE -BROKEN_FreeBSD_14_aarch64= clang-14 crashes, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264834 +#BROKEN_FreeBSD_14_aarch64= clang-14 crashes, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264834 LIB_DEPENDS= libtiff.so:graphics/tiff \ libpng.so:graphics/png \ @@ -100,6 +100,9 @@ DOCS_BUILD_DEPENDS= doxygen:devel/doxygen EXAMPLES_CMAKE_BOOL= BUILD_EXAMPLES +CFLAGS+= -fcrash-diagnostics-dir=. +CPPFLAGS+= -fcrash-diagnostics-dir=. + # Mangling so that it will build when science/netcdf is installed. post-patch: @${MV} ${WRKSRC}/ThirdParty/netcdf/vtknetcdf/include/netcdf.h \ got me (from expansion of the compressed tar for the failure): # find /wrkdirs/usr/ports/math/vtk8/ -name 'vtkGeoInteractorStyle-*' -print /wrkdirs/usr/ports/math/vtk8/work/.build/vtkGeoInteractorStyle-d93f99.sh /wrkdirs/usr/ports/math/vtk8/work/.build/vtkGeoInteractorStyle-d93f99.cpp So there is a more direct way than my original re-run-after-expansion technique to get such files. So may be the infrastructure would be made to have a mode for capturing clang/clang++ reproducer files in poudriere(-devel) bulk builds when clang/clang++ is in use.
This is fixed by commit 307ace7f20d5909d97ef6e81dbfa01e282a845e1 in the main LLVM repository. https://github.com/llvm/llvm-project/commit/307ace7f20d5909d97ef6e81dbfa01e282a845e1
1. Wait for LLVM 15 2. Ask LLVM project to cherry-pick the bugfix into the 14 stream (might be too late to fix 14) 3. Have the lords of the FreeBSD source repository cherry-pick the bug fix into the local copy of llvm
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=91ec809f0a90798296697cfc9afdb1c50c6d4971 commit 91ec809f0a90798296697cfc9afdb1c50c6d4971 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2022-09-27 21:45:56 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2022-09-27 21:45:56 +0000 Apply llvm fix for assertion/crash building math/vtk Merge commit 307ace7f20d5 from llvm git (by David Sherwood): [LoopVectorize] Ensure the VPReductionRecipe is placed after all it's inputs When vectorising ordered reductions we call a function LoopVectorizationPlanner::adjustRecipesForReductions to replace the existing VPWidenRecipe for the fadd instruction with a new VPReductionRecipe. We attempt to insert the new recipe in the same place, but this is wrong because createBlockInMask may have generated new recipes that VPReductionRecipe now depends upon. I have changed the insertion code to append the recipe to the VPBasicBlock instead. Added a new RUN with tail-folding enabled to the existing test: Transforms/LoopVectorize/AArch64/scalable-strict-fadd.ll Differential Revision: https://reviews.llvm.org/D129550 Reported by: yuri PR: 264834 MFC after: 3 days contrib/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
*** Bug 275784 has been marked as a duplicate of this bug. ***
Is this now specific to 13.2-RELEASE instead of CURRENT? Does math/vtk9 have the same 13.2-RELEASE issue? Adjusting this for such potential changes of context might be a good thing.
(In reply to Mark Millard from comment #13) I only got fallout for 13.2/arm64 and 13.2/arm64/quarterly.
(In reply to Yuri Victorovich from comment #14) I can not change "Version: CURRENT" to indicate the 13 release context.
^Triage: take a guess at what version is intended.