On Mon, 17 Jan 2022 at 14:01, Ben Beasley <c...@musicinmybrain.net> wrote:
> 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. > All such uses were undefined behaviour (and should have thrown an exception at runtime if the code was ever executed. Fixing those is good. > New compilation errors: > > COPASI: “error: passing 'const CDataVectorN<CCopasiTask>' as 'this' > argument discards qualifiers [-fpermissive]” > What's the context? Is that being used as a comparison function in a std:: container or something? > > 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 > Maybe a variant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923 > > 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”) > If it's actually initializing it with nullptr, that's just undefined (and going to be ill-formed in C++23) and the code should be fixed. If it's like the nlohmann:json case, I need to investigate more whether it's a defect in the C++23 spec or the code should be fixed. > > 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-le...@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-le...@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-le...@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
