From: Martin Sebor <msebor@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Florian Weimer <fweimer@redhat.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: tests failing on x86_64-linux
Date: Mon, 14 Dec 2020 17:55:38 -0700 [thread overview]
Message-ID: <559d1d1e-e8ba-8945-60a8-239e9da6eca6@gmail.com> (raw)
In-Reply-To: <CAMe9rOp=uiQh1cD=LNGLD7pN9eJmCHiNkmn2zxjjukvAAoWR3A@mail.gmail.com>
On 12/9/20 7:50 PM, H.J. Lu wrote:
> On Wed, Dec 9, 2020 at 2:31 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> 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.
>
> r11-5888 is also "make check" clean.
I still see the same failures with today's top of trunk and two
more:
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
FAIL: elf/tst-dlopen-self-container
FAIL: elf/tst-dlopen-tlsmodid-container
UNSUPPORTED: elf/tst-env-setuid
UNSUPPORTED: elf/tst-env-setuid-tunables
FAIL: elf/tst-glibc-hwcaps-cache
FAIL: elf/tst-glibc-hwcaps-prepend-cache
FAIL: elf/tst-ldconfig-bad-aux-cache
FAIL: elf/tst-ldconfig-ld_so_conf-update
FAIL: elf/tst-pldd
FAIL: elf/tst-preload-pthread-libc
XPASS: elf/tst-protected1a
XPASS: elf/tst-protected1b
FAIL: grp/tst-initgroups1 <<< new
FAIL: grp/tst-initgroups2 <<< new
FAIL: locale/tst-localedef-path-norm
FAIL: localedata/tst-localedef-hardlinks
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
FAIL: nptl/tst-pthread-getattr
UNSUPPORTED: nptl/tst-thread-exit-clobber
UNSUPPORTED: nptl/tst-thread_local1
FAIL: nss/tst-nss-db-endgrent
FAIL: nss/tst-nss-db-endpwent
FAIL: nss/tst-nss-files-hosts-long
FAIL: nss/tst-nss-test3
FAIL: nss/tst-reload1
FAIL: posix/bug-ga2
UNSUPPORTED: posix/bug-ga2-mem
UNSUPPORTED: resolv/mtrace-tst-leaks2
FAIL: resolv/tst-leaks2
UNSUPPORTED: stdlib/tst-quick_exit
FAIL: stdlib/tst-system
UNSUPPORTED: stdlib/tst-thread-quick_exit
FAIL: string/tst-strerror
FAIL: string/tst-strsignal
Summary of test results:
23 FAIL
4192 PASS
26 UNSUPPORTED
16 XFAIL
2 XPASS
Martin
next prev parent reply other threads:[~2020-12-15 0:55 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
2020-12-10 2:50 ` H.J. Lu
2020-12-15 0:55 ` Martin Sebor [this message]
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=559d1d1e-e8ba-8945-60a8-239e9da6eca6@gmail.com \
--to=msebor@gmail.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
/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).