On 2017-10-02 10:25 AM, Jonathan Wakely wrote: > On 2 October 2017 at 15:12, nick <xerofoify@xxxxxxxxx> wrote: >> >> >> On 2017-10-02 05:29 AM, Jonathan Wakely wrote: >>> On 2 October 2017 at 00:23, nick <xerofoify@xxxxxxxxx> wrote: >>>> >>>> >>>> On 2017-10-01 12:58 PM, Jonathan Wakely wrote: >>>>> On 1 October 2017 at 16:08, nick <xerofoify@xxxxxxxxx> wrote: >>>>>> >>>>>> >>>>>> On 2017-09-30 07:23 PM, Jonathan Wakely wrote: >>>>>>> On 1 October 2017 at 00:11, nick <xerofoify@xxxxxxxxx> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2017-09-30 07:01 PM, Jonathan Wakely wrote: >>>>>>>>> On 30 September 2017 at 22:42, nick wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> I tried running the tests with: >>>>>>>>>> make bootstrap >>>>>>>>>> make -k check >>>>>>>>>> and it fails like this: >>>>>>>>>> make[5]: Entering directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/32/libatomic' >>>>>>>>>> make all-recursive >>>>>>>>>> make[6]: Entering directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/32/libatomic' >>>>>>>>>> Making all in testsuite >>>>>>>>>> make[7]: Entering directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/32/libatomic/testsuite' >>>>>>>>>> make[7]: Nothing to be done for 'all'. >>>>>>>>>> make[7]: Leaving directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/32/libatomic/testsuite' >>>>>>>>>> make[7]: Entering directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/32/libatomic' >>>>>>>>>> true DO=all multi-do # make >>>>>>>>>> make[7]: Leaving directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/32/libatomic' >>>>>>>>>> make[6]: Leaving directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/32/libatomic' >>>>>>>>>> make[5]: Leaving directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/32/libatomic' >>>>>>>>>> make[4]: Leaving directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/libatomic' >>>>>>>>>> make[3]: Leaving directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/libatomic' >>>>>>>>>> make[2]: Leaving directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/libatomic' >>>>>>>>>> make[1]: Target 'check-target' not remade because of errors. >>>>>>>>>> make[1]: Leaving directory '/home/nick/gcc/obdjir' >>>>>>>>>> Makefile:2292: recipe for target 'do-check' failed >>>>>>>>>> make: *** [do-check] Error 2 >>>>>>>>>> make: Target 'check' not remade because of errors. >>>>>>>>> >>>>>>>>> This only says that Make failed because of some earlier error, which >>>>>>>>> you didn't show. >>>>>>>>> >>>>>>>>>> I have no idea why but I added this very minor fix: >>>>>>>>>> error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", _(reason)); >>>>>>>>>> >>>>>>>>>> The only odd thing about this build is I am running it through ccache but I have no >>>>>>>>>> idea how that would cause issues. Thoughts? >>>>>>>>> >>>>>>>>> There's no way we can say why this did or didn't fix an error that you >>>>>>>>> didn't show us. >>>>>>>>> >>>>>>>> What info do you require. I am just showing you code changes as that's generally a question >>>>>>>> asked. >>>>>>> >>>>>>> The error message that you didn't show. >>>>>>> >>>>>>> Make doesn't just fail and say "recipe for target 'do-check' failed" >>>>>>> ... it will fail because some other command failed, and you didn't >>>>>>> show that error. Look further back in the output of the make command. >>>>>>> >>>>>> Jonathan, >>>>>> This seems to be where it is starting to fail: >>>>>> make[3]: Leaving directory '/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/libgomp' >>>>>> Makefile:904: recipe for target 'check-recursive' failed >>>>> >>>>> Nope, this is Make saying something failed ... you still didn't show >>>>> that something. It will be further back in the history. >>>>> >>>> Jonathan, >>>> I just ran the test suite again and output in a file as clearly this is very far back. >>>> Even scrolling to it doesn't work with a terminal emulator. It's attached to this >>>> email. >>> >>> The first ten lines of that file show you don't have autogen >>> installed, which is listed as a requirement by >>> >>> https://gcc.gnu.org/install/prerequisites.html#Tools_002fpackages-necessary-for-modifying-GCC >>> >>> It also shows that every single libgomp test is failing, for some >>> reason. You'll have to look in >>> $objdir/$target/libgomp/testsuite/libgomp.log for the reasons. >>> >> Jonathan, >> >> The test is failing according to the compiler not building the test suite correctly here or so it seems: >> Running target unix >> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. >> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. >> Using ../../../../libgomp/testsuite/config/default.exp as tool-and-target-specific interface file. >> Running ../../../../libgomp/testsuite/libgomp.c/c.exp ... >> Executing on host: /home/nick/gcc/obdjir/gcc/xgcc -B/home/nick/gcc/obdjir/gcc/ -B/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/./libgomp/ -B/home/nick/gcc/obdjir/x86_64-pc-lin >> ux-gnu/./libgomp/.libs -I/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/./libgomp -I../../../../libgomp/testsuite/../../include -I../../../../libgomp/testsuite/.. -c -o ia325310 >> .o ia325310.c (timeout = 300) >> spawn -ignore SIGHUP /home/nick/gcc/obdjir/gcc/xgcc -B/home/nick/gcc/obdjir/gcc/ -B/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/./libgomp/ -B/home/nick/gcc/obdjir/x86_64-pc-lin >> ux-gnu/./libgomp/.libs -I/home/nick/gcc/obdjir/x86_64-pc-linux-gnu/./libgomp -I../../../../libgomp/testsuite/../../include -I../../../../libgomp/testsuite/.. -c -o ia325310. >> o ia325310.c^M ^[[01m^[[Kia325310.c:2:6:^[[m^[[K ^[[01;31m^[[Kerror: ^[[m^[[Ksize of array '^[[01m^[[Kdummy^[[m^[[K' is negative^M >> int ^[[01;31m^[[Kdummy^[[m^[[K[sizeof (int) == 4^M >> ^[[01;31m^[[K^~~~~^[[m^[[K^M >> ^[[01m^[[Kia325310.c:4:41:^[[m^[[K ^[[01;31m^[[Kerror: ^[[m^[[K'^[[01m^[[K__i386__^[[m^[[K' undeclared here (not in a function); did you mean '^[[01m^[[K__k8__^[[m^[[K'?^M >> && sizeof (long) == 4 ? 1 : -1] = { ^[[01;31m^[[K__i386__^[[m^[[K };^M >> ^[[01;31m^[[K^~~~~~~~^[[m^[[K^M >> ^[[32m^[[K__k8__^[[m^[[K^M >> compiler exited with status 1 >> >> >> Either this is a bug in the test suite or was there due to be not having autogen installed. > > Given that nobody else is having problems running the libgomp tests, > which do you think it might be? > I understand that seems I was missing a package or two. I am going to try it again with autogen installed to see if that fixes it. Nick
