From: "H.J. Lu" <hjl.tools@gmail.com>
To: Martin Sebor <msebor@gmail.com>
Cc: Florian Weimer <fweimer@redhat.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: tests failing on x86_64-linux
Date: Wed, 9 Dec 2020 14:31:59 -0800 [thread overview]
Message-ID: <CAMe9rOp-5RQRw7Tn5X0wr_HpnBtaSOX=cC374VTrMKONO=V6bg@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOq01q3v4gvEyg8Cg1ov-XLAg=AGhf8d86AWTfBAGoBNQg@mail.gmail.com>
On Wed, Dec 9, 2020 at 1:44 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Wed, Dec 9, 2020 at 1:17 PM Martin Sebor <msebor@gmail.com> wrote:
> >
> > On 12/9/20 11:28 AM, H.J. Lu wrote:
> > > On Wed, Dec 9, 2020 at 10:17 AM Martin Sebor via Libc-alpha
> > > <libc-alpha@sourceware.org> wrote:
> > >>
> > >> I've been seeing quite a few test failures in recent builds, more
> > >> than I used to in the past. Are those expected? I configure with
> > >> no options other than --prefix=/usr and after building without
> > >> installing (i.e., just make -j16) run make -j16 check.
> > >>
> > >> The results below are for the top of GCC/Glibc trunk on x86_64
> > >> Fedora Linux but I don't think using GCC 10 improves things much
> > >> if at all.
> > >>
> > >
> > > "make check" is clean for me on Fedora 33/x86-64. Please make sure that
> > > you have all required packages installed, including libstdc++-static.
> > >
> >
> > It's been a while since I built Glibc with the system compiler
> > so I must have misremembered the results. Here they are for
> > my Fedora 29 machine (with libstdc++-static installed and with
> > --prefix=/usr):
> >
> > gcc version 8.3.1 20190223 (Red Hat 8.3.1-2) (GCC)
> >
> > UNSUPPORTED: assert/tst-assert-c++
> > UNSUPPORTED: assert/tst-assert-g++
> > UNSUPPORTED: debug/tst-chk4
> > UNSUPPORTED: debug/tst-chk5
> > UNSUPPORTED: debug/tst-chk6
> > UNSUPPORTED: debug/tst-lfschk4
> > UNSUPPORTED: debug/tst-lfschk5
> > UNSUPPORTED: debug/tst-lfschk6
> > UNSUPPORTED: dlfcn/bug-atexit3
> > UNSUPPORTED: elf/tst-audit10
> > UNSUPPORTED: elf/tst-avx512
> > UNSUPPORTED: elf/tst-env-setuid
> > UNSUPPORTED: elf/tst-env-setuid-tunables
> > XPASS: elf/tst-protected1a
> > XPASS: elf/tst-protected1b
> > UNSUPPORTED: math/test-double-libmvec-sincos-avx512
> > UNSUPPORTED: math/test-float-libmvec-sincosf-avx512
> > UNSUPPORTED: misc/tst-pkey
> > UNSUPPORTED: nptl/tst-cancel24
> > UNSUPPORTED: nptl/tst-cancel24-static
> > UNSUPPORTED: nptl/tst-minstack-throw
> > UNSUPPORTED: nptl/tst-once5
> > UNSUPPORTED: nptl/tst-thread-exit-clobber
> > UNSUPPORTED: nptl/tst-thread_local1
> > UNSUPPORTED: stdlib/tst-quick_exit
> > UNSUPPORTED: stdlib/tst-thread-quick_exit
> > Summary of test results:
> > 4214 PASS
> > 24 UNSUPPORTED
> > 16 XFAIL
> > 2 XPASS
> >
> > And below are the results I see with today's top of GCC trunk.
> > All the failures are due to "original exit status 127" which IIUC
> > means the program wasn't found. Yet they're all there. Could it
> > have something to do with the paralellization? The other
> > difference between the native build and my GCC 11 build is that
> > the latter is an unoptimized GCC so it takes quite a bit longer
> > to compile.
> >
> > gcc version 11.0.0 20201209 (experimental) (GCC)
>
> Did you apply
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561332.html
Using built-in specs.
COLLECT_GCC=/usr/gcc-11.0.0-x32/bin/gcc
COLLECT_LTO_WRAPPER=/usr/gcc-11.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/gnu/import/git/gitlab/x86-gcc/configure
--enable-cet --with-demangler-in-ld --prefix=/usr/gcc-11.0.0-x32
--with-local-prefix=/usr/local --enable-gnu-indirect-function
--enable-clocale=gnu --with-system-zlib --with-target-system-zlib
--with-fpmath=sse --with-multilib-list=m32,m64,mx32
--enable-linker-build-id --enable-gnu-unique-object
--enable-languages=c,c++,fortran,lto,objc,obj-c++,go
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20201204 (experimental) (GCC)
is "makc check" clean. I will test r11-5888 + my PR target/98146 patches.
--
H.J.
next prev parent reply other threads:[~2020-12-09 22:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 18:17 Martin Sebor
2020-12-09 18:28 ` H.J. Lu
2020-12-09 21:17 ` Martin Sebor
2020-12-09 21:44 ` H.J. Lu
2020-12-09 22:31 ` H.J. Lu [this message]
2020-12-10 2:50 ` H.J. Lu
2020-12-15 0:55 ` Martin Sebor
2021-04-28 20:07 ` tests failing on x86_64-linux (due to test-container?) Martin Sebor
2021-04-28 20:37 ` DJ Delorie
2021-04-28 21:50 ` Martin Sebor
2021-04-28 23:08 ` DJ Delorie
2021-04-28 23:42 ` Martin Sebor
2021-04-28 23:54 ` DJ Delorie
2021-05-13 21:29 ` Martin Sebor
2022-01-12 22:04 ` Martin Sebor
2022-01-12 22:13 ` H.J. Lu
2022-01-12 23:24 ` Martin Sebor
2022-01-14 23:51 ` Martin Sebor
2022-01-17 18:04 ` Adhemerval Zanella
2022-01-17 19:09 ` Joseph Myers
2022-01-20 22:23 ` Martin Sebor
2020-12-16 10:21 ` tests failing on x86_64-linux Florian Weimer
2020-12-09 19:03 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMe9rOp-5RQRw7Tn5X0wr_HpnBtaSOX=cC374VTrMKONO=V6bg@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=msebor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).