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)


Rainer Orth <ro@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


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