This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)


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:

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]