public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Matthias Klose <doko@ubuntu.com>
Cc: Gaius Mulley <gaius.mulley@southwales.ac.uk>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
Date: Tue, 09 Jul 2019 12:31:00 -0000	[thread overview]
Message-ID: <yddwogrpf4n.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <e0b24505-bb5b-5395-0d3e-a99bb6358f79@ubuntu.com> (Matthias	Klose's message of "Mon, 8 Jul 2019 23:19:34 +0200")

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

Hi Matthias,

> I had a look at the GCC 9 version of the patches, with a build including a make
> install. Some comments:
>
>  - A parallel build (at least with -j4) isn't working. A sequental
>    build works fine.  I think forcing a sequential build will not
>    work well, increasing the build time too much.

absolutely: I'd go as far as claiming that this is the number one
priority.  Otherwise build and test times are just too long for all but
the most dedicated testers, and forcing a sequential build would be a
showstopper for trunk integration.

The same holds for the current requirement of a non-bootstrap build.  At
least that's what I saw initially: it may be that it works sequentially,
but haven't tried since the build time was way too long already.

>  - libgm2 multilib builds are not working.  <builddir>/<target>/32/libgm2
>    is configured, but not built.

True, but the fix is a simple one-liner:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ml.patch --]
[-- Type: text/x-patch, Size: 283 bytes --]

--- ../../../m2/dist/gcc-versionno/libgm2/Makefile.am	2019-06-06 15:17:19.634469354 +0000
+++ libgm2/Makefile.am	2019-07-09 00:41:23.214142811 +0000
@@ -97,3 +97,5 @@
 
 # Subdir rules rely on $(FLAGS_TO_PASS)
 FLAGS_TO_PASS = $(AM_MAKEFLAGS)
+
+include $(top_srcdir)/../multilib.am

[-- Attachment #3: Type: text/plain, Size: 3829 bytes --]


This allowed me to build both 32 and 64-bit gm2 libs on
i386-pc-solaris2.11 and get the testresults I reported earlier, which
are identical for -m32 and -m64.

Here are a couple of other issues I saw:

* There are many many warnings during the build in the gcc/gm2 code.

* The mc output is far too verbose right now: this isn't of interest to
  anyone but gm2 developers ;-)

* Running make check-gm2 in gcc produces gm2 testsuite output directly
  in gcc/testsuite.  This needs to go into a testsuite/gm2 subdir (or
  gm2<N> once the testsuite is parallelized: it is far too large to only
  run sequentially).

* Many tests FAIL like this:

ESC[01mESC[Kxgm2:ESC[mESC[K ESC[01;31mESC[Kfatal error: ESC[mESC[Kcannot execute �<80><98>ESC[01mESC[Kgm2lESC[mESC[K�<80><99>: execvp: No such file or directory
compilation terminated.
compiler exited with status 1
FAIL: gm2/calling-c/datatypes/unbounded/run/pass/m.mod compilation,  -g 

  For one, I didn't have gm2l anywhere in my tree.  Besides, the tests
  absolutely need to be run with -fno-diagnostics-show-caret
  -fno-diagnostics-show-line-numbers -fdiagnostics-color=never

  This problem seems to account for the vast majority of failing tests
  right now:

   6820 xgm2: fatal error: cannot execute ‘gm2l’: execvp: No such file or directory
      6 xgm2: fatal error: no input files

  gm2l and a couple of other tools are built by gm2/Make-lang.in's
  gm2.all.build rule, that the seems not to be referenced anywhere.
  Even after manually building them, the stay in stage1/gm2 and need a
  make gm2l to be copied into gcc/gm2.  This all needs to work without
  such manual steps or without installing gm2 first.

* There are a couple of broken testcase names in gm2.sum, e.g.

PASS: /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gm2/pim/options/optimize/run/pass/addition.mod compilation, -g {compiler=/var/gcc/gcc-10.0.0-20190708/11.5-gcc-gas-gm2-no-bootstrap-j1/gcc/xgm2 -B/var/gcc/gcc-10.0.0-20190708/11.5-gcc-gas-gm2-no-bootstrap-j1/gcc -I/var/gcc/gcc-10.0.0-20190708/11.5-gcc-gas-gm2-no-bootstrap-j1/i386-pc-solaris2.11/./libgm2/libpim:/vol/gcc/src/hg/trunk/solaris/gcc/testsuite/../gm2/gm2-libs -I/var/gcc/gcc-10.0.0-20190708/11.5-gcc-gas-gm2-no-bootstrap-j1/i386-pc-solaris2.11/./libgm2/libiso:/vol/gcc/src/hg/trunk/solaris/gcc/testsuite/../gm2/gm2-libs-iso -I/vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gm2/pim/options/optimize/run/pass -fpim -L/var/gcc/gcc-10.0.0-20190708/11.5-gcc-gas-gm2-no-bootstrap-j1/i386-pc-solaris2.11/./libgm2/libpim/.libs -L/var/gcc/gcc-10.0.0-20190708/11.5-gcc-gas-gm2-no-bootstrap-j1/i386-pc-solaris2.11/./libgm2/libiso/.libs}

  Names are required to be unique, and must not contain absolute
  pathnames to allow for comparing different test results.  All this
  stuff in braces above should go.

With the missing gm2l worked around as above, my i386-pc-solaris2.11
testresults are way better now:

                === gm2 Summary for unix ===

# of expected passes            11186
# of unexpected failures        24
# of unresolved testcases       12

                === gm2 Summary for unix/-m64 ===

# of expected passes            10976
# of unexpected failures        156
# of unresolved testcases       90

                === gm2 Summary ===

# of expected passes            22162
# of unexpected failures        180
# of unresolved testcases       102

However, you may want to reconsider if really the whole gm2 testsuite
needs to be torture-tested, i.e. run at -g/-O/-O -g/-Os/-O3
-fomit-frame-pointer/-O3 -fomit-frame-pointer -finline-functions.  This
seems pretty excessive to me.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

  parent reply	other threads:[~2019-07-09 12:27 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-14 13:10 Gaius Mulley
2019-06-29 10:15 ` Richard Sandiford
2019-06-29 12:52   ` Richard Biener
2019-06-29 20:29   ` Gaius Mulley
2019-06-29 18:08 ` Segher Boessenkool
2019-07-02  0:18   ` Gaius Mulley
2019-07-03  8:41 ` Rainer Orth
2019-07-08 15:20   ` Gaius Mulley
2019-07-08 15:31     ` Rainer Orth
2019-07-09  9:25       ` Rainer Orth
2019-07-09 11:41         ` Gaius Mulley
2019-07-10 11:50           ` Rainer Orth
2019-07-08 15:41     ` Gaius Mulley
2019-07-08 21:21 ` Matthias Klose
2019-07-09  6:37   ` Matthias Klose
2019-07-09 19:50     ` Gaius Mulley
2019-07-09 21:35       ` Matthias Klose
2019-07-10 17:56         ` Matthias Klose
2019-07-10 20:18           ` Gaius Mulley
2019-07-10 20:38             ` Matthias Klose
2019-07-10 21:16               ` Gaius Mulley
2019-07-09  9:56   ` Matthias Klose
2019-07-09 12:14     ` Gaius Mulley
2019-07-09 13:24       ` Matthias Klose
2019-07-09 13:49         ` Gaius Mulley
2019-07-09 16:23           ` Matthias Klose
2019-07-09 17:22             ` Gaius Mulley
2019-07-09 12:31   ` Rainer Orth [this message]
2019-07-09 15:57     ` Gaius Mulley
2019-07-09 17:32       ` Matthias Klose
2019-07-10 20:45         ` Gaius Mulley
2019-07-10 12:11       ` Rainer Orth
2019-07-09 21:36   ` Matthias Klose
2019-07-10 17:11     ` Matthias Klose
2019-07-10 20:49       ` Gaius Mulley
2019-07-11  7:57   ` Matthias Klose
2019-07-11 12:12     ` Gaius Mulley
2019-07-11 16:40       ` Segher Boessenkool
2019-07-11 17:26         ` Gaius Mulley
2019-07-12 15:41           ` Segher Boessenkool
2019-07-12 18:35             ` Gaius Mulley
2019-07-18 20:15   ` Matthias Klose
2019-11-20 10:10     ` Gaius Mulley
2019-07-19 14:22 ` Matthias Klose
2019-07-20 21:41 ` Matthias Klose

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=yddwogrpf4n.fsf@CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=doko@ubuntu.com \
    --cc=gaius.mulley@southwales.ac.uk \
    --cc=gcc-patches@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).