Rainer Orth <r...@cebitec.uni-bielefeld.de> 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. <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
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<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
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 ‘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.
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/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.
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:
>
> === gm2 Summary for unix ===
>
> # 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.
> === 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.
ok, I'll cull some of the permutations,
regards,
Gaius
