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.

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@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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