On Tue, 18 Jan 2022 at 11:01, Jonathan Wakely <jwakely(a)redhat.com> wrote:
On Mon, 17 Jan 2022 at 14:01, Ben Beasley <code(a)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.
That change now only applies when compiling as C++23, so won't affect most
packages (once the fix makes it from upstream GCC to rawhide). It would
still be good to fix code that really does construct strings and
string_views from nullptr, otherwise it will break again in a few years
when GCC defaults to -std=gnu++23.
> 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.
Turns out it's both. The C++23 change breaks the json lib (and they have a
fix) but I made it apply to all of C++11/14/17/20/23, which is incorrect
because it breaks code that should be valid in C++20. Fixed in GCC upstream
now.