From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81976 invoked by alias); 5 Dec 2019 16:12:38 -0000 Mailing-List: contact libstdc++-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libstdc++-owner@gcc.gnu.org Received: (qmail 81966 invoked by uid 89); 5 Dec 2019 16:12:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=sigh X-HELO: mail-lj1-f195.google.com Received: from mail-lj1-f195.google.com (HELO mail-lj1-f195.google.com) (209.85.208.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Dec 2019 16:12:30 +0000 Received: by mail-lj1-f195.google.com with SMTP id z17so4165964ljk.13 for ; Thu, 05 Dec 2019 08:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bieaOlyh8GbuGN+WjOEaRLDg8AekHGE5CVqsLd7hlV8=; b=jbmP/i+qD+ee9O4QbIsUWgnlbU2CYplPSY+LQNKYchXEIjpP0hglTEWgs+DhOcfhCo IbL0jqf5y4xbqfabdvP4E6ex/lcW7/MjVKsmc3LamnYSZKLApeK0OAmIroUpq++wnMG1 MTmEtUWoLmfeHZZLUdi250WgYQFZtTtAr4VfTaJ1RBQRO6/5n5KA4Y1LTr7t/JCrwarr Edg+TtMHqTWWK3JvwFnz9aMCQRYPpKhTHlqfjEeAZQtTMeC+8+t3CZWFERbkQYHXdzB6 YGFZSSeFjoFj6dfXK78J+/kuNzMX1F0JIYHHf9JRxzA5XrObJMcMLPAtWwL3+yK1wj6B 0W3w== MIME-Version: 1.0 References: <23ef4bc4-bae7-662e-d6e7-07a60df053d4@honermann.net> <423ff8de-b0df-71ce-07a9-ee82ae083334@honermann.net> <20191203091619.GE11522@redhat.com> <20191205114326.GN11522@redhat.com> In-Reply-To: <20191205114326.GN11522@redhat.com> From: Christophe Lyon Date: Thu, 05 Dec 2019 16:12:00 -0000 Message-ID: Subject: Re: [PATCH 4/4]: C++ P1423R3 char8_t remediation: New tests To: Jonathan Wakely Cc: Tom Honermann , "libstdc++@gcc.gnu.org" , gcc-patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-12/txt/msg00025.txt.bz2 On Thu, 5 Dec 2019 at 12:43, Jonathan Wakely wrote: > > On 05/12/19 09:00 +0100, Christophe Lyon wrote: > >On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote: > >> > >> On 03/12/19 09:11 +0100, Christophe Lyon wrote: > >> >On Mon, 16 Sep 2019 at 04:34, Tom Honermann wrote: > >> >> > >> >> A revised patch is attached that modifies the tests for deleted ostream > >> >> inserters to require C++2a. This is required by the revision of patch > >> >> 2/4 that adds proper preprocessor conditionals to the definitions. > >> >> > >> >> Tom. > >> >> > >> >> On 9/15/19 3:40 PM, Tom Honermann wrote: > >> >> > This patch adds new tests to validate new deleted overloads of wchar_t, > >> >> > char8_t, char16_t, and char32_t for ordinary and wide formatted > >> >> > character and string ostream inserters. > >> >> > > >> >> > Additionally, new tests are added to validate invocations of u8path with > >> >> > sequences of char8_t for both the C++17 and filesystem TS implementations. > >> >> > > >> >> > libstdc++-v3/ChangeLog: > >> >> > > >> >> > 2019-09-15 Tom Honermann > >> >> > > >> >> > * > >> >> > libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/char/deleted.cc: > >> >> > > >> >> > New test to validate deleted overloads of character and string > >> >> > inserters for narrow ostreams. > >> >> > * > >> >> > libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/deleted.cc: > >> >> > > >> >> > New test to validate deleted overloads of character and string > >> >> > inserters for wide ostreams. > >> >> > * > >> >> > libstdc++-v3/testsuite/27_io/filesystem/path/factory/u8path-char8_t.cc: > >> >> > New test to validate u8path invocations with sequences of > >> >> > char8_t. > >> >> > * > >> >> > libstdc++-v3/testsuite/experimental/filesystem/path/factory/u8path-char8_t.cc > >> >> > > >> >> > New test to validate u8path invocations with sequences of > >> >> > char8_t. > >> >> > > >> > > >> >Hi, > >> > > >> >I've noticed that the new test > >> >27_io/filesystem/path/factory/u8path-char8_t.cc > >> >fails to compile on arm-none-eabi with default cpu/fpu, because: > >> >/tools/arm-none-eabi/bin/ld: > >> >/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/src/.libs/libstdc++.a(string-inst.o): > >> >in function `_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_': > >> >string-inst.cc:(.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_[_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_]+0xf4): > >> >undefined reference to `_ZSt15__alloc_on_moveISaIcEEvRT_S2_' > >> >[etc...] > >> > >> That function is defined inline and so should be instantiated in any > >> TU that needs it, and so should not give linker errors. There was a > >> similar bug reported the other day that turned out to be pilot error: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92733 > >> > >Hi, > >Sorry for the delay, it took me a while to reproduce the problem manually. > >I think I see this because I build that particular configuration with > >CXXFLAGS_FOR_TARGET=-fno-threadsafe-statics > > > >Does that sound plausible? > > Not really ... I still don't know why that function template would > ever be undefined. > Hmmm that's because doing CXXFLAGS_FOR_TARGET means that the generated Makefile contains: CXXFLAGS = -fno-threadsafe-statics while if I don't define CXXFLAGS_FOR_TARGET, it contains CXXFLAGS = -g -O2 -D_GNU_SOURCE Re-compiling string-inst with -O2 removes the undefined reference Sigh... looks like I fixed something similar 7 years ago :-( https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=189046 So... the current configure.ac code makes sure -O2 and -g are present in CXXFLAGS_FOR_TARGET only if it's derived from CXXFLAGS, which happens only when CXXFLAGS_FOR_TARGET is NOT overridden, and not cross-compiling... We have: case " $CXXFLAGS " in *" -O2 "*) ;; *) CXXFLAGS_FOR_TARGET="-O2 $CXXFLAGS_FOR_TARGET" ;; esac Why isn't it case "$CXXFLAGS_FOR_TARGET" instead? And that whole case/esac should be after the 'fi'. Or is it that way on purpose? So it seems the fix for the problem I saw is for me to use CXXFLAGS_FOR_TARGET="-O2 -g -fno-threadsafe-statics" Christophe