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.