On 2020-06-21 18:44 +0100, Ken Moffat via lfs-dev wrote:
> 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
> > >
GCC itself is OK with -O3, but some tests are not. With "CFLAGS=-O3 ./configure
..." many tests will fail. The correct way is:
# some CFLAGS set up very early
export CFLAGS="-O3"
export CXXFLAGS="$CFLAGS"
# ... ... build other packages
{unset CFLAGS CXXFLAGS; ./configure ...}
make STAGE1_CFLAGS="-O3" BOOT_CFLAGS="-O3" CFLAGS_FOR_TARGET="-O3 -g"
-g is there because libstdc++ needs debug information.
But my make variables are for 3-stage bootstrapping. Not sure what should we do
with --disable-bootstrap.
> 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
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
