From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <oliva@adacore.com>
Received: from rock.gnat.com (rock.gnat.com
 [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1])
 by sourceware.org (Postfix) with ESMTP id 7FF8E3950C17;
 Thu, 14 Jan 2021 22:20:54 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7FF8E3950C17
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=adacore.com
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=oliva@adacore.com
Received: from localhost (localhost.localdomain [127.0.0.1])
 by filtered-rock.gnat.com (Postfix) with ESMTP id A7FAD5625F;
 Thu, 14 Jan 2021 17:20:53 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at gnat.com
Received: from rock.gnat.com ([127.0.0.1])
 by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id mgcxo5zwpcda; Thu, 14 Jan 2021 17:20:53 -0500 (EST)
Received: from free.home (tron.gnat.com
 [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by rock.gnat.com (Postfix) with ESMTPS id 6BF9A561A5;
 Thu, 14 Jan 2021 17:20:53 -0500 (EST)
Received: from livre (livre.home [172.31.160.2])
 by free.home (8.15.2/8.15.2) with ESMTPS id 10EMKkIq242766
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 14 Jan 2021 19:20:46 -0300
From: Alexandre Oliva <oliva@adacore.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org,
 Corentin Gay <gay@adacore.com>
Subject: Re: Add dg-require-wchars to libstdc++ testsuite
Organization: Free thinker, does not speak for AdaCore
References: <orwnx9ilza.fsf@lxoliva.fsfla.org>
 <20210114134142.GC7692@redhat.com>
Errors-To: aoliva@lxoliva.fsfla.org
Date: Thu, 14 Jan 2021 19:20:46 -0300
In-Reply-To: <20210114134142.GC7692@redhat.com> (Jonathan Wakely's message of
 "Thu, 14 Jan 2021 13:41:42 +0000")
Message-ID: <orh7nji2ip.fsf@lxoliva.fsfla.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.84
X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 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 <libstdc++.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/libstdc++/>
List-Post: <mailto:libstdc++@gcc.gnu.org>
List-Help: <mailto:libstdc++-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2021 22:20:55 -0000

On Jan 14, 2021, Jonathan Wakely <jwakely@redhat.com> wrote:

> The problem is that <bits/locale_conv.h> uses wchar_t in default
> template arguments:

> 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?

Thanks, I'll give it a spin.  That said, ...

> <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?

... it is definitely the case that the target currently defines wchar_t,
and it even offers wchar.h and a lot of (maybe all?) wcs* functions.
This was likely not the case when the patch was first written.

I'll double check whether any of the patch is still needed for current
versions.

I figured it would a waste to just discard Corentin's identification of
testcases that failed when glibc wchar_t support was not enabled.

This also means that the test results I'm going to get are likely to not
reflect the conditions for which these patches were originally written.


FWIW, I like very much the notion of offering a fallback wchar_t
implementation within libstdc++-v3, so that users get the expected C++
functionality even when libc doesn't offer it.  Even a (conditional?)
typedef to introduce wchar_t could be there.

Perhaps the test that sets or clears _GLIBCXX_USE_WCHAR_T should be used
to decide whether or not to offer a wchar.h header in libstdc++, and
then (pipe dream?) all other uses of this macro would be just gone?


> As Fran=C3=83=C2=A7ois 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 }

*nod*


> But we might not even need this new proc if the codecvt tests can be
> made to work using the attached patch.

Thanks,

--=20
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar