From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely.gcc@gmail.com>
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [IPv6:2a00:1450:4864:20::430])
 by sourceware.org (Postfix) with ESMTPS id 9C8AD3846078;
 Fri, 15 Jan 2021 10:09:58 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9C8AD3846078
Received: by mail-wr1-x430.google.com with SMTP id d13so8638145wrc.13;
 Fri, 15 Jan 2021 02:09:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=GYlN0SwUk3bJOFfRcP/8WPDZXWAZ8h50eXkHCLgwwr0=;
 b=UQlkwWuPykoyP/a7LdWi9zPUDuK8+EmDomgp3gLwK//qY/WNhhEAKvYgPE94NkNyMX
 iYdIIoDFnKc0aBo2rdW7AxUqa3FYXrh6mi65mYA9teVk4d44NVcf6xgT8K0O9fFVwQmt
 5oY1XH2RCjj9uHXRtcO1DdaM9exreGByuN2b8KiT7xKWdcEcU24wu853/zyXCP3UNjaz
 v+Jfp3EDsiPMXqy4SyKrq/rTDlU996bfJDEwSTnqJt1ngNwtm8nN/ZTD9QCyo0F9ObsB
 5qP/kAt+e1N1A6zO+AQZ8AL/7G+S4ZnvV9OjeBM9cYqWZ2D+LgXgtFGBdlWiB+JWyQQp
 qqzg==
X-Gm-Message-State: AOAM532J5UtKpPLTd1Oc6F/G4QmYMwnqVFTsiT7EYQ/JrinM9Dnlrr9t
 X3F/6u9JUVXAVsFnXPAe22Wl8ss9Ukzz2bJghXA=
X-Google-Smtp-Source: ABdhPJzGpMq8XUPIDOg9fDWsLrN5a+O7DMnGGoXUcYOwKUPyj3Knl550loxJgoYLZ+wIiKhMg6xEVMR//nmjjrSwMEI=
X-Received: by 2002:a5d:510f:: with SMTP id s15mr7914208wrt.21.1610705397734; 
 Fri, 15 Jan 2021 02:09:57 -0800 (PST)
MIME-Version: 1.0
References: <orwnx9ilza.fsf@lxoliva.fsfla.org>
 <20210114134142.GC7692@redhat.com>
 <orh7nji2ip.fsf@lxoliva.fsfla.org>
In-Reply-To: <orh7nji2ip.fsf@lxoliva.fsfla.org>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Fri, 15 Jan 2021 10:09:46 +0000
Message-ID: <CAH6eHdRF64DBGsB-3bRa44mg2j5rxRO-EzqYs0TJNFNTrNmBiA@mail.gmail.com>
Subject: Re: Add dg-require-wchars to libstdc++ testsuite
To: Alexandre Oliva <oliva@adacore.com>
Cc: Jonathan Wakely <jwakely@redhat.com>, "libstdc++" <libstdc++@gcc.gnu.org>,
 gcc-patches@gcc.gnu.org, Corentin Gay <gay@adacore.com>
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE,
 RCVD_IN_DNSWL_NONE, 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
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
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: Fri, 15 Jan 2021 10:10:00 -0000

On Thu, 14 Jan 2021, 22:22 Alexandre Oliva, <oliva@adacore.com> wrote:

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

Definitely not a waste, as it's led to this discussion and plan for
improvement.



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


That would be great. We might be able to get close even if not all the way
there. However, some small embedded systems might not want the extra
symbols for explicit instantiations of std::wstring, std::wistream in
libstdc++.so so we might want a way to suppress them (they could still
instantiate those templates implicitly by using them, we just wouldn't have
them pre-instantiated in the library).

Anyway, let's start just by making wstring_convert usable without wchar_t.