On Fri, Jun 19, 2020 at 07:46:54PM +0100, Ken Moffat via lfs-dev wrote:
> On Fri, Jun 19, 2020 at 06:58:42PM +0200, Pierre Labastie via lfs-dev wrote:
> > On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote:
> > > I've now been through my test logs for the new build (on my i7
> > > haswell).
> > >
> > > Here are a few comments (in order of testing)
> > >
An update on ONLY my gcc test results.
> > >
> > > gcc-10.1.0
> > > ----------
> > >
> > > I seem to be getting rather more failures than the book implies,
> > > although I don't think they are either serious or unexpected.
> > >
> > > First, 14 failures i nthe torture test, variants of
> > > FAIL: gcc.c-torture/compile/limits-exprparen.c
> >
> > Isn't it the one that fails when ulimit is not increased?
> >
>
> Maybe. I'm increasing the ulimit as root, then running the test as
> 'tester', which matches the book. Again, my build of trunk from
> 20200603 didn't fail these, but cross-chap5 from that date did.
>
Pierre later commented about CFLAGS. That turned out to be the
cause of all the failures in the torture tests: with just -O3 in the
CFLAGS and CXXFLAGS that batch of tests fail. With -O2 and
optionally -march=native -fstack-clash-protection
-fstack-protector-strong and (for CXX) -D_GLIBCXX_ASSERTION those
tests pass.
So, from now on I'm dropping back to -O2 for building gcc. I've
uploaded a new Errata-2.txt to my tuning notes.
> > >
> > > Second, as wel las the 6 locale/get_time test failures I also had
> > > FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
> > > FAIL: 22_locale/numpunct/members/char/3.cc execution test
> >
> > Never seen those ones
> >
On my limited series of gcc-10 builds (one from trunk which turned
out to not have any added CFLAGS because I'd borked the name of the
file containing them, three builds of cross-chap5 and new trunk)
the 20_util/unsynchronized_pool_resource/allocate.cc failure is not
consistent.
And on one build there was some other failure, whcih perhaps
implies the testsuite is "variable".
But 22_locale/numpunct/members/char/3.cc always fails for me.
Looking at the test,
libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc
it starts
// { dg-require-namedlocale "nl_NL.ISO8859-15" }
and a bit later it says
// nl_NL chosen because it has no thousands separator (at this time).
locale loc_it = locale(ISO_8859(15,nl_NL));
(apparently it was originally using an italian locale, then changed)
Now in theory I have all the locales on this system. My log from
glibc for nl_NL shows:
nl_NL.ISO-8859-1... done
nl_NL.ISO-8859-15@euro... done
nl_NL.UTF-8... done
I have no idea how locales work in expect, but my normal quick test
for a locale is to use 'LC_ALL=someting date' and there I find that
only nl_NL and nl_NL.UTF-8 work, the rest give me english:
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15@euro date
Sat Jun 20 13:12:21 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-1 date
Sat Jun 20 13:12:29 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15 date
Sat Jun 20 13:13:35 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15@euro date
Sat Jun 20 13:13:41 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL.UTF-8 date
za 20 jun 2020 13:13:53 BST
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL date
za 20 jun 2020 13:14:40 BST
Now, that seems to be the only nl_NL.ISO8859-15 test, but there are
a lot which require de_DR.ISO8859-15, several for fr_FR.ISO8859-15
and one for it_IT-ISO8859-15.
I wondered if some of these might now fall into 'unsupported' (there
doesn't seem to be any easy way of identifying what is in that), but
my number of unsupported tests seems consistent at 344 in al lthe
builds so I ended up clueless about why that test only fails for me.
The test data seems to get deleted during the run, but the test is
apparently comparing the result to an empty string, so probably a
thousands separator was returned.
Interestingly, wikipedia suggests that the Netherlands uses a dot
'.' as the separator https://en.wikipedia.org/wiki/Decimal_separator
(in Examples of use, the entry for 1.234.567,89) and
https://www.freeformatter.com/netherlands-standards-code-snippets.html#numericformats
agrees that the grouping character is the dot. on that basis I
expect this test to fail for everyone!
if the test is to pass, I guess (from wikipedia) that de_DE might
work - but since it apparently doesn't fail for everyone I might
again be barking up completely the wrong tree.
ĸen
--
He died at the console, of hunger and thirst.
Next day he was buried, face-down, nine-edge first.
- the perfect programmer
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
