On Mon, Nov 17, 2025 at 04:45:44PM +0530, Jason Merrill wrote:
> On 11/16/25 4:28 AM, Jakub Jelinek wrote:
> > I've tried to test a patch to switch -std=gnu++17 C++ default
> > to -std=gnu++20 (will post momentarily), but ran into various problems
> > during GCC bootstraps, our codebase isn't fully C++20 ready.
> >
> > The most common problems are arithmetic or bitwise operations
> > between enumerators of different enum types (or between enumerator
> > and floating point in the testsuite), ambiguous overloaded
> > operator == because of forgotten const qualification of const inside
> > of the argument and then libcody being largely stuck in C++ and incompatible
> > with C++20 which introduced char8_t type and uses it for u8 literals.
> >
> > The following patch fixes various issues I've run into, for libcody
> > this patch just makes sure code including cody.hh can be compiled
> > with -std=gnu++20, libcody itself I have a tweak in the other patch.
>
> Frankly I'm not sure what the point of libcody's u8 dance is; UTF-8 for all
> the ASCII characters that it uses S2C(u8"x") for is the same byte as the 'x'
> plain character literal. I'd be inclined to strip that all out.
It isn't the same for -fexec-charset=IBM1047 (or other non-ASCII execution
charsets), so perhaps the intent is to communicate using UTF-8 (or ASCII?)
instead of using arbitrary other character set.
Detail::S2C is from I understand just a workaround for C++11 and one can use
(char) u8'x' instead for C++14 and later (perhaps conditionally based on
feature test macros).
I don't know what other projects use libcody.
If it is just GCC, perhaps it is time to update it to minimum C++14 like
rest of GCC and the workarounds can go.
But for C++20 another thing is that I think we'd need to add some extra
overloads for const char8_t * etc. and just cast to const char. Plus
there are some uses of std::string created from u8 literals, dunno if it
should use std::u8string in that case or have casts to const char * first.
Jakub
