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