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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
