On Mon, Jan 17, 2022 at 09:00:13AM -0500, Ben Beasley wrote:
**Internal compiler or debugger error:**
abseil-cpp: “internal compiler error: tree code 'template_type_parm' is not
supported in LTO streams”
Dunno, would need to reproduce.
debugbreak: %check uses gdb, which now crashes (“(core dumped) gdb -q
-x
"${exe}-rpm-test.gdb" --batch < /dev/null”) on ppc64le/x86_64, but not on
aarch64
If gdb crashes, it would be nice if somebody from the gdb team had a look,
of course it can be a gcc bug too.
**Compilation error from a dependency header:**
dependency “boost”: “# error "Never use <bmiintrin.h> directly; include
<x86intrin.h> instead."”, via
boost/multiprecision/cpp_int/intel_intrinsics.hpp
This is weird.
bmiintrin.h had:
#ifndef _X86GPRINTRIN_H_INCLUDED
# error "Never use <bmiintrin.h> directly; include <x86gprintrin.h>
instead."
#endif
in both gcc 11 and 12. In fact, most of the more recent *intrin.h headers
want users to only use one of x86intrin.h, x86gprintrin.h or maybe
immintrin.h.
octave-iso2mesh
dependency “boost”: “error: use of deleted function
'std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(std::nullptr_t)” via
boost/graph/bellman_ford_shortest_paths.hpp
the basic_string(std::nullptr_t) = deleted; is now at least in
gcc-12.0.1-0.3.fc36 that is almost finished building for C++23 and up only,
so for the time being it will work again. But if it is really
std::string s = nullptr;
or so, then it would be a good to fix it in the package, it is still
undefined.
This will be fixed with the above mentioned change.
giada
dependency “opencv”: “invalid parameter combination for AltiVec intrinsic
'__builtin_vec_sldw'” on ppc64le, in opencv4/opencv2/core/vsx_utils.hpp
vec_sldw with vector float is now supported in gcc-12.0.1-0.3.fc36.
Jakub