See <https://wg21.link/p2513>.
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>: https://gcc.gnu.org/g:567329fdd9d65a1e6254206fefff89fa151ba7f3 commit r13-2881-g567329fdd9d65a1e6254206fefff89fa151ba7f3 Author: Marek Polacek <polacek@redhat.com> Date: Fri Sep 23 18:06:34 2022 -0400 c++: P2513R4, char8_t Compatibility and Portability Fix [PR106656] P0482R6, which added char8_t, didn't allow const char arr[] = u8"howdy"; because it said "Declarations of arrays of char may currently be initialized with UTF-8 string literals. Under this proposal, such initializations would become ill-formed." This caused too many issues, so P2513R4 alleviates some of those compatibility problems. In particular, "Arrays of char or unsigned char may now be initialized with a UTF-8 string literal." This restriction has been lifted for initialization only, not implicit conversions. Also, my reading is that 'signed char' was excluded from the allowable conversions. This is supposed to be treated as a DR in C++20. PR c++/106656 gcc/c-family/ChangeLog: * c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_char8_t for C++20. gcc/cp/ChangeLog: * typeck2.cc (array_string_literal_compatible_p): Allow initializing arrays of char or unsigned char by a UTF-8 string literal. gcc/testsuite/ChangeLog: * g++.dg/cpp23/feat-cxx2b.C: Adjust. * g++.dg/cpp2a/feat-cxx2a.C: Likewise. * g++.dg/ext/char8_t-feature-test-macro-2.C: Likewise. * g++.dg/ext/char8_t-init-2.C: Likewise. * g++.dg/cpp2a/char8_t3.C: New test. * g++.dg/cpp2a/char8_t4.C: New test.
Implemented in GCC 13.
The documentation for CLI flag -fchar8_t should be updated https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html . Is there any chance that this fix gets backported because it is treated as defect report to C++20?
(In reply to Dimitrij Mijoski from comment #3) > The documentation for CLI flag -fchar8_t should be updated > https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html . Oh right, this is not an error anymore: char ca[] = u8"xx"; I'll fix, thanks. > Is there any chance that this fix gets backported because it is treated as > defect report to C++20? I wasn't really planning to do that.