From: Tom Honermann <tom@honermann.net>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: Jonathan Wakely <jwakely@redhat.com>,
"libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] C++ P0482R6 char8_t: declare std::c8rtomb and std::mbrtoc8 if provided by the C library
Date: Tue, 11 Jan 2022 15:13:52 -0500 [thread overview]
Message-ID: <723ca8d2-d509-3045-f223-f14ec253dded@honermann.net> (raw)
In-Reply-To: <CAH6eHdT9Zej5iyFuv8unK96gEoNza5wRVNhfr4Yw0XVhLo6m3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5009 bytes --]
On 1/10/22 4:38 PM, Jonathan Wakely wrote:
> On Mon, 10 Jan 2022 at 21:24, Tom Honermann via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
>> On 1/10/22 8:23 AM, Jonathan Wakely wrote:
>>>
>>> On Sat, 8 Jan 2022 at 00:42, Tom Honermann via Libstdc++
>>> <libstdc++@gcc.gnu.org <mailto:libstdc%2B%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
>>> <cuchar> if
>>> provided by the C library in <uchar.h>.
>>>
>>> This patch addresses feedback provided in response to a previous
>>> patch
>>> submission [2].
>>>
>>> Autoconf changes determine if the C library declares c8rtomb and
>>> mbrtoc8
>>> at global scope when uchar.h is included and compiled with either
>>> -fchar8_t or -std=c++20. New
>>> _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T
>>> and _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20 configuration macros
>>> reflect the probe results. The <cuchar> header declares these
>>> functions
>>> in the std namespace only if available and the _GLIBCXX_USE_CHAR8_T
>>> configuration macro is defined (by default it is defined if the C++20
>>> __cpp_char8_t feature test macro is defined)
>>>
>>> Patches to glibc to implement c8rtomb and mbrtoc8 have been
>>> submitted [3].
>>>
>>> New tests validate the presence of these declarations. The tests pass
>>> trivially if the C library does not provide these functions.
>>> Otherwise
>>> they ensure that the functions are declared when <cuchar> is included
>>> and either -fchar8_t or -std=c++20 is enabled.
>>>
>>> Tested on Linux x86_64.
>>>
>>> libstdc++-v3/ChangeLog:
>>>
>>> 2022-01-07 Tom Honermann <tom@honermann.net
>>> <mailto:tom@honermann.net>>
>>>
>>> * acinclude.m4 Define config macros if uchar.h provides
>>> c8rtomb() and mbrtoc8().
>>> * config.h.in <http://config.h.in>: Re-generate.
>>> * configure: Re-generate.
>>> * include/c_compatibility/uchar.h: Declare ::c8rtomb and
>>> ::mbrtoc8.
>>> * include/c_global/cuchar: Declare std::c8rtomb and
>>> std::mbrtoc8.
>>> * include/c_std/cuchar: Declare std::c8rtomb and std::mbrtoc8.
>>> * testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
>>> New test.
>>> *
>>> testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc:
>>> New test.
>>>
>>>
>>>
>>> Thanks, Tom, this looks good and I'll get it committed for GCC 12.
>> Thank you!
>>> My only concern is that the new tests depend on an internal macro:
>>>
>>> +#if _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20
>>> + using std::mbrtoc8;
>>> + using std::c8rtomb;
>>>
>>> I prefer if tests are written as "user code" when possible, and not
>>> using our internal macros. That isn't always possible, and in this
>>> case would require adding new effective-target keyword to
>>> testsuite/lib/libstdc++.exp just for use in these two tests. I don't
>>> think we should bother with that.
>> I went with this approach solely due to my unfamiliarity with the test
>> system. I knew there should be a way to conditionally make the test
>> "pass" as unsupported or as an expected failure, but didn't know how to
>> go about implementing that. I don't mind following up with an additional
>> patch if such a change is desirable. I took a look at
>> testsuite/lib/libstdc++.exp and it looks like it may be pretty straight
>> forward to add effective-target support. It would probably be a good
>> learning experience for me. I'll prototype and report back.
> Yes, it's very easy to do. Take a look at the
> check_effective_target_blah procs in that file, especially the later
> ones that use v3_check_preprocessor_condition. You can use that to
> define an effective target keyword for any preprocessor condition
> (such as the new macros you're adding).
>
> Then the test can do:
> // { dg-do compile { target blah } }
> which will make it UNSUPPORTED if the effective target proc doesn't return true.
> See https://gcc.gnu.org/onlinedocs/gccint/Selectors.html#Selectors for
> the docs on target selectors.
>
> I'm just not sure it's worth adding a new keyword for just two tests.
Thank you for the implementation direction; this was quite easy!
Patch attached (to be applied after the original one).
libstdc++-v3/ChangeLog:
2022-01-11 Tom Honermann <tom@honermann.net>
* testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
Modify to use new c8rtomb_mbrtoc8_cxx20 effective target.
* testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc:
Modify to use new c8rtomb_mbrtoc8_fchar8_t effective target.
* testsuite/lib/libstdc++.exp: Add new effective targets.
If you decide that the new keywords aren't worth adding, no worries; my
feelings won't be hurt :)
Tom.
[-- Attachment #2: p0482r6-n2653-eff-target.patch --]
[-- Type: text/x-patch, Size: 2648 bytes --]
commit 0542361fe8cb5da146097f86ca8ea8bca86421e0
Author: Tom Honermann <tom@honermann.net>
Date: Tue Jan 11 14:57:51 2022 -0500
Add effective target support for tests of C++20 c8rtomb and mbrtoc8.
diff --git a/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc b/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc
index 7c152ed42b5..681c12127db 100644
--- a/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc
+++ b/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc
@@ -1,12 +1,10 @@
-// { dg-do compile }
+// { dg-do compile { target c8rtomb_mbrtoc8_cxx20 } }
// { dg-options "-std=c++20" }
#include <cuchar>
namespace gnu
{
-#if _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20
using std::mbrtoc8;
using std::c8rtomb;
-#endif // _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20
}
diff --git a/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc b/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc
index 1cfaf7427e5..836690f0349 100644
--- a/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc
+++ b/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc
@@ -1,12 +1,10 @@
-// { dg-do compile }
+// { dg-do compile { target c8rtomb_mbrtoc8_fchar8_t } }
// { dg-options "-fchar8_t" }
#include <cuchar>
namespace gnu
{
-#if _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T
using std::mbrtoc8;
using std::c8rtomb;
-#endif // _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T
}
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 1a43dd05ba7..7a2379c9982 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1346,6 +1346,22 @@ proc check_effective_target_std_allocator_new { } {
}]
}
+# Return 1 if mbrtoc8 and c8rtomb are available for C++20, 0 otherwise.
+proc check_effective_target_c8rtomb_mbrtoc8_cxx20 { } {
+ return [check_v3_target_prop_cached et_c8rtomb_mbrtoc8_cxx20 {
+ set cond "_GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20"
+ return [v3_check_preprocessor_condition c8rtomb_mbrtoc8_cxx20 $cond]
+ }]
+}
+
+# Return 1 if mbrtoc8 and c8rtomb are available for -fchar8_t, 0 otherwise.
+proc check_effective_target_c8rtomb_mbrtoc8_fchar8_t { } {
+ return [check_v3_target_prop_cached et_c8rtomb_mbrtoc8_fchar8_t {
+ set cond "_GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T"
+ return [v3_check_preprocessor_condition c8rtomb_mbrtoc8_fchar8_t $cond]
+ }]
+}
+
set additional_prunes ""
if { [info exists env(GCC_RUNTEST_PARALLELIZE_DIR)] \
next prev parent reply other threads:[~2022-01-11 20:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-08 0:42 Tom Honermann
2022-01-10 13:23 ` Jonathan Wakely
2022-01-10 21:23 ` Tom Honermann
2022-01-10 21:38 ` Jonathan Wakely
2022-01-11 20:13 ` Tom Honermann [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-06-07 2:16 Tom Honermann
2021-06-23 17:27 ` Jonathan Wakely
2021-06-24 19:35 ` Tom Honermann
2021-06-24 19:39 ` Jonathan Wakely
2021-06-25 2:56 ` Tom Honermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=723ca8d2-d509-3045-f223-f14ec253dded@honermann.net \
--to=tom@honermann.net \
--cc=gcc-patches@gcc.gnu.org \
--cc=jwakely.gcc@gmail.com \
--cc=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).