So I just finished building dev-lang/rust-1.61.0 on multiple systems just fine, then dev-lang/rust-1.61.0-r1 appears and I try to build that and... .... [554/2098] Building CXX object lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/InstrEmitter.cpp.o FAILED: lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/InstrEmitter.cpp.o /usr/bin/x86_64-pc-linux-gnu-g++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/llvm/build/lib/CodeGen/SelectionDAG -I/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/src/llvm-project/llvm/lib/CodeGen/SelectionDAG -I/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/llvm/build/include -I/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/src/llvm-project/llvm/include -ffunction-sections -fdata-sections -fPIC -m64 -pipe -march=native -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -fno-exceptions -fno-rtti -std=c++14 -MD -MT lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/InstrEmitter.cpp.o -MF lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/InstrEmitter.cpp.o.d -o lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/InstrEmitter.cpp.o -c /var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/src/llvm-project/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp In file included from /var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/src/llvm-project/llvm/include/llvm/ADT/DenseMapInfo.h:20, from /var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/src/llvm-project/llvm/include/llvm/ADT/DenseMap.h:17, from /var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/src/llvm-project/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.h:18, from /var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/src/llvm-project/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:15: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/tuple: In instantiation of ‘std::__uniq_ptr_impl<_Tp, _Dp>::__uniq_ptr_impl(std::__uniq_ptr_impl<_Tp, _Dp>&&) [with _Tp = llvm::DISubroutineType; _Dp = llvm::TempMDNodeDeleter]’: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/bits/unique_ptr.h:211:7: required from here /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/tuple:1094:17: internal compiler error: Segmentation fault 1094 | constexpr tuple(tuple&&) = default; | ^~~~~ 0x1758959 internal_error(char const*, ...) ???:0 0x7e245e cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*) ???:0 ..... The only thing that changed meanwhile was an update to dev-util/cmake-3.22.4 - maybe that's the reason? Sorry for short info, need to go to bed now and can't debug further... Reproducible: Always
It shouldn't be CMake related. 1. Please include the full build.log (compressed if needed) and emerge --info. 2. Is this reproducible? 3. Can you reproduce with GCC 11.3.0? 3. I'm sorry, and I know this is a pain, but can you do a memtest before we go any further? Once all of that is done, we'll follow https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide together if you can reproduce it & the memtest comes back clean.
also if you can reproduce it reliably at the same file - please try to reproduce without seminterpos and related flags.
I have to apologize. *blush* Yesterday I reported this issue because it seemed quite clear - just cmake changed and new rust rev, and rebuild and baam, a segfault - but I did not try again because it was already very late and I was sleepy, and also did not notice I selected "repro always". I should have slept first, try again and then file a bug... :-/ I currently cannot reproduce this. I understand your suggestion for a memtest, but this box has been running now 24/7 for almost 3 years without any issues, build every rust since 1.48 without any problem - if memory is bad, I should have noticed some corruption somehow by now? But yes, compiling rust runs at full load and it is summer temperatures now, there is the argument that this makes very very rare bit flips only very rare but plausible? Will try to repro this - sorry again for the noise...
(In reply to Morton Pellung from comment #3) > I have to apologize. *blush* > > Yesterday I reported this issue because it seemed quite clear - just cmake > changed and new rust rev, and rebuild and baam, a segfault - but I did not > try again because it was already very late and I was sleepy, and also did > not notice I selected "repro always". I should have slept first, try again > and then file a bug... :-/ > > I currently cannot reproduce this. I understand your suggestion for a > memtest, but this box has been running now 24/7 for almost 3 years without > any issues, build every rust since 1.48 without any problem - if memory is > bad, I should have noticed some corruption somehow by now? > But yes, compiling rust runs at full load and it is summer temperatures now, > there is the argument that this makes very very rare bit flips only very > rare but plausible? > The reason I ask is because memory can "go bad" and I've also heard this many times before and then it turns out it is indeed bad RAM. Some programs are just really got at exposing it.
