public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
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)] \

  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).