If there are no further concerns, could a C++ or libcpp maintainer
please commit this for me?
Thank you!
Tom.
On 8/4/22 12:42 PM, Tom Honermann via Gcc-patches wrote:
Are there any further concerns with this patch? If not, I extend my
gratitude to anyone so kind as to commit this for me as I
On 8/2/22 6:14 PM, Joseph Myers wrote:
On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
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
Are there any further concerns with this patch? If not, I extend my
gratitude to anyone so kind as to commit this for me as I don't have
commit access.
I just noticed that I neglected to add a ChangeLog entry for the comment
addition to gcc/cp/parser.cc. Noted inline below. I can re-send the
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
ordi
This patch implements the core language and compiler dependent library
changes adopted for C2X via WG14 N2653. The changes include:
- Change of type for UTF-8 string literals from array of const char to
array of const char8_t (unsigned char).
- A new atomic_char8_t typedef.
- A new ATOMIC_CHAR8_
This patch series provides an implementation and tests for the WG14 N2653
paper as adopted for C2X.
Additionally, a fix is included for the C++ preprocessor to treat UTF-8
character literals in preprocessor directives as an unsigned type in char8_t
enabled modes (in C++17 and earlier with -fchar8_
On 8/2/22 12:53 PM, Joseph Myers wrote:
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
Could you please send a complete patch series? I'm not sure wha
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
gcc/testsuite/ChangeLog:
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test.
* g
On 8/1/22 3:13 PM, Joseph Myers wrote:
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
new file mode 100644
index 000..3456105563a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg
Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target diagnostic option be enabled for the preprocessor
(see c_option_is_from_cpp_diagnostics). This change modifies the
-Wc++20-compat
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
gcc/testsuite/ChangeLog:
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test.
* g
This patch implements the core language and compiler dependent library
changes adopted for C2X via WG14 N2653. The changes include:
- Change of type for UTF-8 string literals from array of const char to
array of const char8_t (unsigned char).
- A new atomic_char8_t typedef.
- A new ATOMIC_CHAR8_
On 7/27/22 7:23 PM, Joseph Myers wrote:
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
I'd expect this patch also to add tests verifying that u8"
On 7/31/22 11:05 AM, Lewis Hyatt wrote:
On Sat, Jul 30, 2022 at 7:06 PM Tom Honermann via Gcc-patches
wrote:
On 7/27/22 7:09 PM, Joseph Myers wrote:
On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote:
Gcc's '#pragma GCC diagnostic' directives are processed in &q
On 7/27/22 7:20 PM, Joseph Myers wrote:
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
index bfcfdf664c7..75ed7965689 100644
--- a/gcc/ginclude/stdatomic.h
+++ b/gcc/ginclude/stdatomic.h
@@ -49,6 +49,10 @@ typedef
On 7/27/22 7:09 PM, Joseph Myers wrote:
On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote:
Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target dia
On 7/25/22 2:05 PM, Andrew Pinski wrote:
On Mon, Jul 25, 2022 at 11:01 AM Tom Honermann via Gcc-patches
wrote:
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
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
ordi
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
gcc/testsuite/ChangeLog:
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test.
* g
This patch implements the core language and compiler dependent library
changes adopted for C2X via WG14 N2653. The changes include:
- Change of type for UTF-8 string literals from array of const char to
array of const char8_t (unsigned char).
- A new atomic_char8_t typedef.
- A new ATOMIC_CHAR8_
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
ordi
This patch series provides an implementation and tests for the WG14 N2653
paper as adopted for C2X.
Additionally, a fix is included for the C++ preprocessor to treat UTF-8
character literals in preprocessor directives as an unsigned type in char8_t
enabled modes (in C++17 and earlier with -fchar8_
Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target diagnostic option be enabled for the preprocessor
(see c_option_is_from_cpp_diagnostics). This change modifies the
-Wc++20-compat
This change addresses the following issue raised on the libc-alpha mailing list:
https://sourceware.org/pipermail/libc-alpha/2022-July/140825.html
Glibc 2.36 adds a char8_t typedef in C++ modes that do not enable the char8_t
builtin type (C++17 and earlier by default; subject to _GNU_SOURCE and u
On 1/10/22 4:38 PM, Jonathan Wakely wrote:
On Mon, 10 Jan 2022 at 21:24, Tom Honermann via Libstdc++
wrote:
On 1/10/22 8:23 AM, Jonathan Wakely wrote:
On Sat, 8 Jan 2022 at 00:42, Tom Honermann via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch completes implementation o
On 1/10/22 9:23 PM, Joseph Myers wrote:
Please repost these patches after GCC 12 branches (updated as appropriate
depending on whether the feature is accepted at the two-week Jan/Feb WG14
meeting, which doesn't yet have an agenda), since we're currently
stabilizing for the release and so not cons
On 1/10/22 8:23 AM, Jonathan Wakely wrote:
On Sat, 8 Jan 2022 at 00:42, Tom Honermann via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch completes implementation of the C++20 proposal P0482R6
[1] by
adding declarations of std::c8rtomb() and std::mbrtoc8() in
This patch provides new tests for the core language and compiler
dependent library changes proposed in WG14 N2653 [1] for C2x.
Tested on Linux x86_64.
gcc/testsuite/ChangeLog:
2021-05-31 Tom Honermann
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atom
This patch implements the core language and compiler dependent library
changes proposed in WG14 N2653 [1] for C2x. The changes include:
- Change of type for UTF-8 string literals from array of char to array
of char8_t (unsigned char) when targeting C2x.
- A new atomic_char8_t typedef.
- A new A
This series of patches implements the core language features for the
WG14 N2653 [1] proposal to provide char8_t support in C. These changes
are intended to align char8_t support in C with the support provided in
C++20 via WG21 P0482R6 [2].
These patches addresses feedback provided in response
This patch completes implementation of the C++20 proposal P0482R6 [1] by
adding declarations of std::c8rtomb() and std::mbrtoc8() in if
provided by the C library in .
This patch addresses feedback provided in response to a previous patch
submission [2].
Autoconf changes determine if the C l
On 6/11/21 1:27 PM, Joseph Myers wrote:
On Fri, 11 Jun 2021, Tom Honermann via Gcc-patches wrote:
The option is needed because it impacts core language backward compatibility
(for both C and C++, the type of u8 string literals; for C++, the type of u8
character literals and the new char8_t
On 6/11/21 12:53 PM, Jakub Jelinek wrote:
On Fri, Jun 11, 2021 at 12:20:48PM -0400, Tom Honermann wrote:
I'm open to whatever signaling mechanism would be preferred. It took me a
while to settle on _CHAR8_T_SOURCE as the mechanism to propose as I didn't
find much for other precedents.
I agree
On 6/11/21 12:01 PM, Jakub Jelinek wrote:
On Fri, Jun 11, 2021 at 11:52:41AM -0400, Tom Honermann via Gcc-patches wrote:
On 6/7/21 5:11 PM, Joseph Myers wrote:
On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote:
When -fchar8_t support is enabled for non-C++ modes, the _CHAR8_T_SOURCE
On 6/7/21 5:12 PM, Joseph Myers wrote:
Also, it seems odd to add a new field to cpp_options without any code in
libcpp that uses the value of that field.
Ah, thank you. That appears to be leftover code from prior
experimentation and I failed to identify it as such when preparing the
patch. I
On 6/7/21 5:11 PM, Joseph Myers wrote:
On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote:
When -fchar8_t support is enabled for non-C++ modes, the _CHAR8_T_SOURCE macro
is predefined. This is the mechanism proposed to glibc to opt-in to
declarations of the char8_t typedef and c8rtomb
On 6/7/21 5:03 PM, Joseph Myers wrote:
On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote:
These changes do not impact default gcc behavior. The existing -fchar8_t
option is extended to C compilation to enable the N2653 changes, and
-fno-char8_t is extended to explicitly disable them
This patch updates documentation for the -fchar8_t and -fno-char8_t
options to describe their effect on C code as proposed in WG14 N2653 [1].
Tested on Linux x86_64.
2021-05-31 Tom Honermann
* doc/invoke.texi (-fchar8_t): update for char8_t support for C.
Tom.
[1]: WG14 N2653
This patch provides new tests for the core language and compiler
dependent library changes proposed in WG14 N2653 [1] for C.
Most of the tests are provided in both a positive (-fchar8_t) and
negative (-fno-char8_t) form to ensure behaviors are appropriately
present or absent in each mode.
Te
This patch implements the core language and compiler dependent library
changes proposed in WG14 N2653 [1] for C. The changes include:
- Use of the existing -fchar8_t and -fno-char8_t options to opt-in to
(or opt-out of) the following changes when compiling C code.
- Change of type for UTF-8 st
This series of patches implements the core language features for the
WG14 N2653 [1] proposal to provide char8_t support in C. These changes
are intended to align char8_t support in C with the support provided in
C++20 via WG21 P0482R6 [2].
These changes do not impact default gcc behavior. Th
41 matches
Mail list logo
