From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 01B6D38708A0 for ; Thu, 14 Jan 2021 13:41:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 01B6D38708A0 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-43-ivxUaN2vNsCIvUFIAzqm9Q-1; Thu, 14 Jan 2021 08:41:45 -0500 X-MC-Unique: ivxUaN2vNsCIvUFIAzqm9Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 63CEF8030C0; Thu, 14 Jan 2021 13:41:44 +0000 (UTC) Received: from localhost (unknown [10.33.37.44]) by smtp.corp.redhat.com (Postfix) with ESMTP id E37175D9DD; Thu, 14 Jan 2021 13:41:43 +0000 (UTC) Date: Thu, 14 Jan 2021 13:41:42 +0000 From: Jonathan Wakely To: Alexandre Oliva Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Corentin Gay Subject: Re: Add dg-require-wchars to libstdc++ testsuite Message-ID: <20210114134142.GC7692@redhat.com> References: MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline X-Spam-Status: No, score=-14.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 13:41:50 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 @@ > // . > > // { 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 uses wchar_t in default template arguments: #ifdef _GLIBCXX_USE_WCHAR_T _GLIBCXX_BEGIN_NAMESPACE_CXX11 /// String conversions template 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 generically without using any libc functions (or just using them as optimisations) we might be able to support std::basic_string and iostream classes with almost no work. But that's something to consider in the future. >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. --AqsLC8rIMeq19msA Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" diff --git a/libstdc++-v3/include/bits/locale_conv.h b/libstdc++-v3/include/bits/locale_conv.h index 0e409da9876..d8a4d0851f4 100644 --- a/libstdc++-v3/include/bits/locale_conv.h +++ b/libstdc++-v3/include/bits/locale_conv.h @@ -222,11 +222,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION #endif // _GLIBCXX_USE_CHAR8_T #ifdef _GLIBCXX_USE_WCHAR_T +# define _GLIBCXX_WCHAR_DEFAULT_TEMPL_ARG = wchar_t +#else +// wstring_convert and wbuffer_convert are still defined for targets without +// wchar_t support, but the second template argument must be given explictly. +# define _GLIBCXX_WCHAR_DEFAULT_TEMPL_ARG +#endif _GLIBCXX_BEGIN_NAMESPACE_CXX11 /// String conversions - template, typename _Byte_alloc = allocator> class wstring_convert @@ -382,7 +388,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 _GLIBCXX_END_NAMESPACE_CXX11 /// Buffer conversions - template> class wbuffer_convert : public basic_streambuf<_Elem, _Tr> { @@ -606,8 +612,6 @@ _GLIBCXX_END_NAMESPACE_CXX11 bool _M_always_noconv; }; -#endif // _GLIBCXX_USE_WCHAR_T - /// @} group locales _GLIBCXX_END_NAMESPACE_VERSION --AqsLC8rIMeq19msA--