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.