Skimming through Koschei, here are a sampling of regressions that seem
to be associated with GCC 12. Some of these are in packages I maintain
directly; others are via @neuro-sig.
With a few exceptions, I have triaged these only to the extent of
confirming the problem appeared at the same time as GCC 12 and noting
the initial error. I mostly haven’t gotten around to filing or searching
for bugs, upstream or downstream.
Explicit deletion of the
std::string(nullptr_t)/std::string_view(nullptr_t) constructors seems
like it is going to be a popular cause of FTBFS in C++ packages. Use of
this constructor mostly happens implicitly. I think explicit use of the
default constructor, e.g. std::string_view(), will usually be the
simplest correct substitute.
Problems in popular dependencies (boost, json, opencv) are also
impacting a lot of packages.
**Internal compiler or debugger error:**
abseil-cpp: “internal compiler error: tree code 'template_type_parm' is
not supported in LTO streams”
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
**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
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
python-graph-tool
dependency “json”:
https://github.com/nlohmann/json/issues/3138
dicomanonymizer
giada
dependency “opencv”: “invalid parameter combination for AltiVec
intrinsic '__builtin_vec_sldw'” on ppc64le, in
opencv4/opencv2/core/vsx_utils.hpp
fasttrack
highfive
**New test failures:**
moose: “Error: SetGet::strGet: Field Vm not found on Element z”,
multiple SIGABRT/SIGSEGV
mpir: “mpn_get_d wrong, didn't get 0.0 on underflow” on aarch64, ppc64le
python-numpoly: multiple results have dtype 'int64' where 'int32' is
expected
sleef:
https://github.com/shibatch/sleef/issues/439 – failing tests
skipped for now
New compilation errors:
COPASI: “error: passing 'const CDataVectorN<CCopasiTask>' as 'this'
argument discards qualifiers [-fpermissive]”
grpc: initializing std::string_view/absl::string_view with nullptr –
fixed and PR sent upstream
python-steps: “static assertion failed: key equality predicate must be
invocable with two arguments of key type” via c++/12/bits/hashtable_policy.h
vxl: “error: conversion from 'int' to
'std::__cxx11::basic_string<char>'
is ambiguous” – looks like an attempt to initialize a string by
std::string(nullptr), which is now explicitly deleted
(“basic_string(nullptr_t) = delete”)
On 1/14/22 09:31, Jakub Jelinek wrote:
> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
>
https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
>
>
https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code. Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on. Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.
>
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double. This is an ABI change. Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).
> Any suggestions on which packages have commonly used library packages
> that use long double?
> readelf -A on libraries on ppc64le prints either nothing (either
> the library is thought not to use long double or supports both ABIs
> transparently or hasn't been rebuilt for some years), or
> Attribute Section: gnu
> File Attributes
> Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> for libraries (or binaries or object files) that use IBM long double
> only or
> Attribute Section: gnu
> File Attributes
> Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
> for IEEE long doubles.
> So I think we want to rebuild on a side-tag packages that
> provide shared libraries used by hundreds of other packages that
> are
> Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> right now.
>
> Jakub
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure