From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48282 invoked by alias); 9 Jul 2019 15:53:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 48273 invoked by uid 89); 9 Jul 2019 15:53:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: postbox.isd.glam.ac.uk Received: from postbox.isd.glam.ac.uk (HELO postbox.isd.glam.ac.uk) (81.87.34.17) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Jul 2019 15:53:39 +0000 Received: from j228-gm.comp.glam.ac.uk ([193.63.148.84]) by postbox.isd.glam.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1hksQy-0003qz-3q; Tue, 09 Jul 2019 16:53:36 +0100 From: Gaius Mulley To: Rainer Orth Cc: Matthias Klose , Subject: Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2) References: <87k1doxqhv.fsf@j228-gm.comp.glam.ac.uk> Date: Tue, 09 Jul 2019 15:57:00 -0000 In-Reply-To: (Rainer Orth's message of "Tue, 9 Jul 2019 14:27:20 +0200") Message-ID: <87muhn5hmo.fsf@j228-gm.comp.glam.ac.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00711.txt.bz2 Rainer Orth writes: > 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. Hi, Many thanks for all the feedback/bugs/patches. I've been working through some of these. The parallel build is now done. > 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. //32/libgm2 >> is configured, but not built. > > True, but the fix is a simple one-liner: > > --- ../../../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 @@ >=20=20 > # Subdir rules rely on $(FLAGS_TO_PASS) > FLAGS_TO_PASS =3D $(AM_MAKEFLAGS) > + > +include $(top_srcdir)/../multilib.am thanks - applied to the master and 9.1.0 branch of gm2. > 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 ;-) added --quiet to all invocations of mc on master - will apply to 9.1.0 soon. > * 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 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 =EF=BF=BD<80><98>ESC[01mESC[Kgm2lESC[mESC[K=EF=BF=BD<80><99>: execv= p: No such file or directory > compilation terminated. > compiler exited with status 1 > FAIL: gm2/calling-c/datatypes/unbounded/run/pass/m.mod compilation, -g=20 > > 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=3Dnever applied to master and 9.1.0. > This problem seems to account for the vast majority of failing tests > right now: > > 6820 xgm2: fatal error: cannot execute =E2=80=98gm2l=E2=80=99: 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. rewritten some of the top level targets to build these tools (applied/pushed on master) will apply to 9.1.0. > * 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/optimiz= e/run/pass/addition.mod compilation, -g {compiler=3D/var/gcc/gcc-10.0.0-201= 90708/11.5-gcc-gas-gm2-no-bootstrap-j1/gcc/xgm2 -B/var/gcc/gcc-10.0.0-20190= 708/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-20= 190708/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-so= laris2.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. thanks for the heads up about this - I'll rename them. > With the missing gm2l worked around as above, my i386-pc-solaris2.11 > testresults are way better now: > > =3D=3D=3D gm2 Summary for unix =3D=3D=3D > > # of expected passes 11186 > # of unexpected failures 24 > # of unresolved testcases 12 these results are great for solaris. On the amd64/GNU/Linux I get 12 failures (long.mod and long2.mod) run 6 times each. > =3D=3D=3D gm2 Summary for unix/-m64 =3D=3D=3D > > # of expected passes 10976 > # of unexpected failures 156 > # of unresolved testcases 90 > > =3D=3D=3D gm2 Summary =3D=3D=3D > > # 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. ok, I'll cull some of the permutations, regards, Gaius