Add dg-require-wchars to libstdc++ testsuite
Jonathan Wakely
jwakely@redhat.com
Thu Jan 14 13:41:42 GMT 2021
On 22/12/20 18:12 -0300, Alexandre Oliva wrote:
>--- a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc
>+++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc
>@@ -16,6 +16,7 @@
> // <http://www.gnu.org/licenses/>.
>
> // { dg-do run { target c++11 } }
>+// { dg-require-wchars "" }
This test doesn't use wchar_t, so it shouldn't depend on
_GLIBCXX_USE_WCHAR_T being defined.
The problem is that <bits/locale_conv.h> uses wchar_t in default
template arguments:
#ifdef _GLIBCXX_USE_WCHAR_T
_GLIBCXX_BEGIN_NAMESPACE_CXX11
/// String conversions
template<typename _Codecvt, typename _Elem = wchar_t,
That makes it impossible to use wstring_convert and wbuffer_convert
without wchar_t, even if you don't want to convert to wchar_t.
I think we should fix the header, not disable tests that don't use
that default template argument. The attached patch should allow you to
use wstring_convert and wbuffer_convert without wchar_t support. The
tests which instantiate it with char16_t or char32_t instead of
wchar_t should work with this patch, right?
<aside>
Is it the case that the wchar_t type is defined on this target, it's
just that libc doesn't have support for wcslen etc? Because we should
probably audit all our uses of _GLIBCXX_USE_WCHAR_T and find which
ones actually need libc support and which just need the wchar_t type
to exist. Some things really do need the libc support, but I suspect
many others don't.
It seems wrong that we can provide full support for char16_t and
char32_t but not wchar_t, just because the former two don't depend on
anything being present in libc. Why can't we just implement the same
functionality for wchar_t without using libc?
In fact, if we just define std::char_traits<wchar_t> generically
without using any libc functions (or just using them as optimisations)
we might be able to support std::basic_string<wchar_t> and iostream
classes with almost no work. But that's something to consider in the
future.
</aside>
>diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp b/libstdc++-v3/testsuite/lib/libstdc++.exp
>index b7d7b906de41c..2c22bcc0f0c94 100644
>--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
>+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
>@@ -702,6 +702,53 @@ proc v3-build_support { } {
> }
> }
>
>+proc check_v3_target_wchars { } {
>+ global et_wchars
>+ global et_wchars_target_name
>+ global tool
>+
>+ if { ![info exists et_wchars_target_name] } {
>+ set et_wchars_target_name ""
>+ }
>+
>+ # If the target has changed since we set the cached value, clear it.
>+ set current_target [current_target_name]
>+ if { $current_target != $et_wchars_target_name } {
>+ verbose "check_v3_target_wchars: `$et_wchars_target_name'" 2
>+ set et_wchars_target_name $current_target
>+ if [info exists et_wchars] {
>+ verbose "check_v3_target_wchars: removing cached result" 2
>+ unset et_wchars
>+ }
>+ }
>+
>+ if [info exists et_wchars] {
>+ verbose "check_v3_target_wchars: using cached result" 2
>+ } else {
>+ set et_wchars 0
>+
>+ # Set up and preprocess a C++ test program that depends
>+ # on wchars support being configured in the libstdc++.
>+ set src wchars[pid].cc
>+
>+ set f [open $src "w"]
>+ puts $f "#ifndef _GLIBCXX_USE_WCHAR_T"
>+ puts $f "# error No wchar header."
As François said, this could use the new proc. I'd also prefer if it
was defined as an effective-target keyword so we can use:
// { dg-require-effective-target wchars }
instead of the old fashioned { dg-require-wchars "" } form. I've
recently added effective-target keywords for several of the
dg-require-FOO directives, so we can move away from the old form. I
think new directives should be done as effective-target keywords. See
the recent changes to libstdc++-v3/testsuite/lib/libstdc++.exp for
examples, e.g. 10ee46adf44ae731fc4f9e9fdc25ad60c9d43a9c
But we might not even need this new proc if the codecvt tests can be
made to work using the attached patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 1470 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210114/3417c6c2/attachment.bin>
More information about the Gcc-patches
mailing list