public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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

  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).