public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Dennis Clarke <dclarke@blastwave.org>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: make check fails in the "libatomic tests"
Date: Tue, 7 Jun 2022 13:36:07 +0100	[thread overview]
Message-ID: <CAH6eHdRh7cvXwUg2gCNmObMh=HoWx9u+WjSOTtyGj+bmb9eD8Q@mail.gmail.com> (raw)
In-Reply-To: <d0e86f0d-3f05-4dfc-a085-ba80529691a2@blastwave.org>

On Wed, 1 Jun 2022 at 18:49, Dennis Clarke via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
>
> Wish I knew why things fail but seem to not fail at the same time.
> Perhaps there is not supposed to be an error status returned back to the
> shell? I don't know.

No, because you used make -k which means that errors are ignored.

>
> Anyways on an old Red Hat Enterprise Linux 6 machine ( AMD64 ) I have
> carefully bootstrapped GCC 12.1.0 over and over and over again. With new
> binutils installed also. I also built dejagnu and tcl and the usual
> little bits we need to run the testsuite. I should point out that this
> is an old slow machine ( by modern standards ) but it runs just fine.
>
> After about a day and 13 hours and 45 minutes of "make -k check" running

Even on a uniprocessor you would get some speed-up from -j2 and if you
have more cores you can run with additional jobs.

> I see this :
>
> .

> srcdir='../../../../gcc-12.1.0/libatomic/testsuite'; export srcdir; \
>          EXPECT=expect; export EXPECT; \
>          if /bin/sh -c "runtest --version" > /dev/null 2>&1; then \
>            exit_status=0; l='libatomic'; for tool in $l; do \
>              if runtest  --tool $tool --srcdir $srcdir ; \
>              then :; else exit_status=1; fi; \
>            done; \
>          else echo "WARNING: could not find 'runtest'" 1>&2; :;\
>          fi; \
>          exit $exit_status
> WARNING: Couldn't find the global config file.
> Using ../../../../gcc-12.1.0/libatomic/testsuite/lib/libatomic.exp as
> tool init file.
> Test run by dclarke on Wed Jun  1 07:41:54 2022
> Native configuration is x86_64-pc-linux-gnu
>
>                  === libatomic tests ===
>
> Schedule of variations:
>      unix
>
> Running target unix
> Using /opt/bw/share/dejagnu/baseboards/unix.exp as board description
> file for target.
> Using /opt/bw/share/dejagnu/config/unix.exp as generic interface file
> for target.
> Using ../../../../gcc-12.1.0/libatomic/testsuite/config/default.exp as
> tool-and-target-specific interface file.
> Running ../../../../gcc-12.1.0/libatomic/testsuite/libatomic.c/c.exp ...
>
>                  === libatomic Summary ===
>
> # of expected passes            54
> make[4]: Leaving directory
> `/opt/bw/build/gcc-12.1.0_rhel6_amd64.007/x86_64-pc-linux-gnu/libatomic/testsuite'
> make[3]: Leaving directory
> `/opt/bw/build/gcc-12.1.0_rhel6_amd64.007/x86_64-pc-linux-gnu/libatomic/testsuite'
> make[3]: Entering directory
> `/opt/bw/build/gcc-12.1.0_rhel6_amd64.007/x86_64-pc-linux-gnu/libatomic'
> Makefile:875: warning: overriding commands for target `all-multi'
> Makefile:866: warning: ignoring old commands for target `all-multi'
> true  DO=all multi-do # make
> make[3]: Leaving directory
> `/opt/bw/build/gcc-12.1.0_rhel6_amd64.007/x86_64-pc-linux-gnu/libatomic'
> make[2]: Leaving directory
> `/opt/bw/build/gcc-12.1.0_rhel6_amd64.007/x86_64-pc-linux-gnu/libatomic'
> make[1]: Leaving directory `/opt/bw/build/gcc-12.1.0_rhel6_amd64.007'
> make: *** [do-check] Error 2
> make: Target `check' not remade because of errors.
> real 135930.17
> user 122350.27
> sys 14525.06
> mimas$ echo $?
> 0
> mimas$
>
> I have no idea what happened there and no idea how much longer things
> could have been left quietly churning away but there seems to be an
> issue in the libatomic section of life. Somewhere.
>
> Is there a way to manually isolate just this test section and then
> figure out what went wrong?

I don't see any errors in the libatomic results, I think that's coming
from an earlier testsuite. Because you used "make -k" it will keep
going after earlier errors, and so run the later testsuites (like
libitm and libatomic). The error isn't coming from the last step
though.

Look at the rest of the test results, not just the end. There will be
at least one failure (but that's common, especially on an ancient
system with an old glibc).

      reply	other threads:[~2022-06-07 12:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01 17:48 Dennis Clarke
2022-06-07 12:36 ` Jonathan Wakely [this message]

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='CAH6eHdRh7cvXwUg2gCNmObMh=HoWx9u+WjSOTtyGj+bmb9eD8Q@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=dclarke@blastwave.org \
    --cc=gcc-help@gcc.gnu.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).