[Bug c++/106426] New: UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

[Bug c++/106426] New: UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426

            Bug ID: 106426
           Summary: UTF-8 character literals do not have unsigned type in
                    the preprocessor in -fchar8_t mode
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tom at honermann dot net
  Target Milestone: ---

As demonstrated at https://godbolt.org/z/7xzWEbqb5, UTF-8 character literals in
preprocessor directives are given the same type as ordinary character literals
(`char` with signed or unsigned behavior dependent on target or use of the
`-fsigned-char` or `-funsigned-char` option) in `char8_t` modes.  In `char8_t`
enabled modes (C++20 by default or when `-fchar8_t` is used), such literals
should be treated as unsigned.

$ cat t.cpp
#if u8'\0' - 1 < 0
#error "UTF-8 character literals not unsigned in preprocessor"
#endif

$ gcc -c -std=c++17 -fchar8_t t.cpp
t.cpp:2:2: error: #error "UTF-8 character literals not unsigned in
preprocessor"
    2 | #error "UTF-8 character literals not unsigned in preprocessor"
      |  ^~~~~

$ gcc -c -std=c++20 t.cpp
t.cpp:2:2: error: #error "UTF-8 character literals not unsigned in
preprocessor"
    2 | #error "UTF-8 character literals not unsigned in preprocessor"
      |  ^~~~~

[Bug preprocessor/106426] UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426

--- Comment #1 from Tom Honermann <tom at honermann dot net> ---
A patch for this issue was submitted to the gcc-patches mailing list with the
patch series available at
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599240.html.

[Bug preprocessor/106426] UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Joseph Myers <jsm28@gcc.gnu.org>:

https://gcc.gnu.org/g:053876cdbe8057210e6f4da4eec2df58f92ccd4c

commit r13-1994-g053876cdbe8057210e6f4da4eec2df58f92ccd4c
Author: Tom Honermann <tom@honermann.net>
Date:   Tue Aug 2 14:36:02 2022 -0400

    preprocessor/106426: Treat u8 character literals as unsigned in char8_t
modes.

    This patch corrects handling of UTF-8 character literals in preprocessing
    directives so that they are treated as unsigned types in char8_t enabled
    C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously,
    UTF-8 character literals were always treated as having the same type as
    ordinary character literals (signed or unsigned dependent on target or use
    of the -fsigned-char or -funsigned char options).

            PR preprocessor/106426

    gcc/c-family/ChangeLog:
            * c-opts.cc (c_common_post_options): Assign
cpp_opts->unsigned_utf8char
            subject to -fchar8_t, -fsigned-char, and/or -funsigned-char.

    gcc/testsuite/ChangeLog:
            * g++.dg/ext/char8_t-char-literal-1.C: Check signedness of u8
literals.
            * g++.dg/ext/char8_t-char-literal-2.C: Check signedness of u8
literals.

    libcpp/ChangeLog:
            * charset.cc (narrow_str_to_charconst): Set signedness of
CPP_UTF8CHAR
            literals based on unsigned_utf8char.
            * include/cpplib.h (cpp_options): Add unsigned_utf8char.
            * init.cc (cpp_create_reader): Initialize unsigned_utf8char.

[Bug preprocessor/106426] UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426

--- Comment #3 from Tom Honermann <tom at honermann dot net> ---
I believe this issue can be resolved as fixed via commit
053876cdbe8057210e6f4da4eec2df58f92ccd4c for the gcc 13 release.