From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95355 invoked by alias); 24 Jan 2019 13:07:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 95335 invoked by uid 89); 24 Jan 2019 13:07:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Jan 2019 13:07:49 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65E6343A35; Thu, 24 Jan 2019 13:07:48 +0000 (UTC) Received: from localhost (unknown [10.33.36.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id D326D1048107; Thu, 24 Jan 2019 13:07:47 +0000 (UTC) Date: Thu, 24 Jan 2019 13:32:00 -0000 From: Jonathan Wakely To: Christophe Lyon Cc: libstdc++@gcc.gnu.org, gcc Patches Subject: Re: [PATCH 2/2] PR libstdc++/86756 Move rest of std::filesystem to libstdc++.so Message-ID: <20190124130747.GJ15627@redhat.com> References: <20190107094825.GN15627@redhat.com> <20190107123945.GP15627@redhat.com> <20190109100923.GV15627@redhat.com> <20190109101128.GW15627@redhat.com> <20190123152811.GA18402@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Mh8CTEa8Ax54aLHp" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2019-01/txt/msg01432.txt.bz2 --Mh8CTEa8Ax54aLHp Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-length: 4781 On 23/01/19 17:01 +0100, Christophe Lyon wrote: >On Wed, 23 Jan 2019 at 16:28, Jonathan Wakely wrote: >> >> On 09/01/19 13:53 +0100, Christophe Lyon wrote: >> >On Wed, 9 Jan 2019 at 11:11, Jonathan Wakely wrote: >> >> >> >> On 09/01/19 10:09 +0000, Jonathan Wakely wrote: >> >> >On 08/01/19 11:13 +0100, Christophe Lyon wrote: >> >> >>On aarch64, I'm seeing an addtional: >> >> >>FAIL: 27_io/filesystem/path/compare/strings.cc execution test >> >> >>because: >> >> >>/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc:39: >> >> >>void test01(): Assertion 'p.compare(p0) == p.compare(s0)' failed. >> >> > >> >> >Odd, I don't know why that would be target-specific. It's probably >> >> >just latent on other targets. I'll try to reproduce it on my aarch64 >> >> >system, but it will take a while to build current trunk. >> >> > >> >> >If you have time, could you please apply this patch, re-run that test >> >> >> >> *This* patch: >> >> >> >> --- a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc >> >> +++ b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc >> >> @@ -36,6 +36,7 @@ test01() >> >> path p(s); >> >> VERIFY( p.compare(s) == 0 ); >> >> VERIFY( p.compare(s.c_str()) == 0 ); >> >> + __builtin_printf("Comparing %s as path:%d as string:%d\n", s.c_str(), p.compare(p0), p.compare(s0)); >> >> VERIFY( p.compare(p0) == p.compare(s0) ); >> >> VERIFY( p.compare(p0) == p.compare(s0.c_str()) ); >> >> } >> >> >> >> >> >> >> >> >> >> >(cd $target/libstdc++-v3 && make check >> >> >RUNTESTFLAGS=conformance.exp=*/path/compare/strings/cc) and send me >> >> >the output from the $target/libstdc++-v3/testsuite/libstdc++.log file? >> >> > >> >> >On x86_64 I get: >> >> > >> >> >Comparing as path:-1 as string:-1 >> >> >Comparing / as path:-1 as string:-1 >> >> >Comparing // as path:-1 as string:-1 >> >> >Comparing /. as path:-51 as string:-51 >> >> >Comparing /./ as path:-51 as string:-51 >> >> >Comparing /a as path:-2 as string:-2 >> >> >Comparing /a/ as path:-1 as string:-1 >> >> >Comparing /a// as path:-1 as string:-1 >> >> >Comparing /a/b/c/d as path:1 as string:1 >> >> >Comparing /a//b as path:1 as string:1 >> >> >Comparing a as path:-1 as string:-1 >> >> >Comparing a/b as path:-1 as string:-1 >> >> >Comparing a/b/ as path:-1 as string:-1 >> >> >Comparing a/b/c as path:-1 as string:-1 >> >> >Comparing a/b/c.d as path:-1 as string:-1 >> >> >Comparing a/b/.. as path:-1 as string:-1 >> >> >Comparing a/b/c. as path:-1 as string:-1 >> >> >Comparing a/b/.c as path:-1 as string:-1 >> >> >PASS: 27_io/filesystem/path/compare/strings.cc execution test >> >> > >> > >> >Here is what I have on aarch64-none-elf: >> >Comparing as path:-1 as string:-1^M >> >Comparing / as path:-1 as string:-1^M >> >Comparing // as path:-1 as string:-1^M >> >Comparing /. as path:-102 as string:-51^M >> >/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc:40: >> >void test01(): Assertion 'p.compare(p0) == p.compare(s0)' failed.^M >> >^M >> >*** EXIT code 4242^M >> >emu: host signal 6^M >> >FAIL: 27_io/filesystem/path/compare/strings.cc execution test >> >> This is a strange one. With my aarch64-unknown-linux-gnu trunk build I get: >> >> Comparing /. as path:-51 as string:-51 >> >> Which suggests it's a newlib vs glibc difference, but this target uses >> glibc (right?) and has the same FAIL: >> https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg02276.html > >Yes, it uses glibc-2.28 > >That build has this in its libstdc++.log: >/home/tcwg-buildslave/workspace/tcwg-buildfarm_0/snapshots/gcc.git~master_rev_2e9ceebcd7618d0e068e0029b43cd75d679022d7/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc:39: >void test01(): Assertion 'p.compare(p0) == p.compare(s0)' failed. >timeout: the monitored command dumped core >FAIL: 27_io/filesystem/path/compare/strings.cc execution test > > >> >> The test should be reducable to simply: >> >> // { dg-options "-std=gnu++17" } >> #include >> #include >> >> int main() >> { >> std::string_view s0 = "a"; >> std::string p0(s0); >> std::string p("."); >> __builtin_printf("as path:%d as string:%d\n", p.compare(p0), p.compare(s0)); >> } >> >> Again, I get -51 and -51 for this. Could you test it on >> aarch64-none-elf? >> >> In terms of what the standard requires, this comparison is based on >> strcmp, i.e. it only specifies a result less than zero, equal to zero, >> or greater than zero. But I'd like to know why the comparisons aren't >> returning the same consistent value. >> > >I get: >as path:-102 as string:-102 I have no idea what's going on here, so I think I will just change the test to only care about the sign of the result, as in the attached patch. --Mh8CTEa8Ax54aLHp Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" Content-length: 1110 commit 84fc5b9d432788414e75df1f62bf8645db57f395 Author: Jonathan Wakely Date: Thu Jan 24 12:53:45 2019 +0000 Fix failing test due to inconsistent strcmp results * testsuite/27_io/filesystem/path/compare/strings.cc: Only compare sign of results. diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc index 3f0aa4bde06..83487ae35b6 100644 --- a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc +++ b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc @@ -26,6 +26,8 @@ using std::filesystem::path; +int sign(int i) { return i > 0 ? 1 : i < 0 ? -1 : 0; } + void test01() { @@ -36,8 +38,8 @@ test01() path p(s); VERIFY( p.compare(s) == 0 ); VERIFY( p.compare(s.c_str()) == 0 ); - VERIFY( p.compare(p0) == p.compare(s0) ); - VERIFY( p.compare(p0) == p.compare(s0.c_str()) ); + VERIFY( sign(p.compare(p0)) == sign(p.compare(s0)) ); + VERIFY( sign(p.compare(p0)) == sign(p.compare(s0.c_str())) ); } } --Mh8CTEa8Ax54aLHp--