[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #7 from Steve Kargl --- On Wed, Mar 15, 2023 at 08:35:41AM +, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 > > --- Comment #6 from Richard Biener --- > (In reply to Steve Kargl from comment #4) > > On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot > > apl.washington.edu wrote: > > > > Looking in obj/gcc/Makefile at line 341 I see the comment > > > > # Make sure the $(MAKE) variable is defined. > > > > followed by no checking to see if MAKE is defined. > > Makefile.in has > > # Make sure the $(MAKE) variable is defined. > @SET_MAKE@ > > configure has > > if eval test \$ac_cv_prog_make_${ac_make}_set = yes; then > { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5 > $as_echo "yes" >&6; } > SET_MAKE= > else > { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 > $as_echo "no" >&6; } > SET_MAKE="MAKE=${MAKE-make}" > fi > > from AC_PROG_MAKE_SET which seems to check whether make sets $MAKE. > That appearantly succeeds for you. Do you "properly" do sth like > > MAKE=gmake ../configure > > so configure sees which make you are using? I think if your gmake No. I simply use '../configure ; gmake -j6 bootstrap'. This has worked for years. I'm currently using GNU make 4.3. If MAKE is not being set to gmake, then I would expect bootstrap to fail. I plan to run gmake with debugging output, and need to check gmake.info to see how to dump the environment information. > doesn't set it then even recursive configure invocations from gmake > will resort to 'make' > > but then I _think_ that gmake itself sets $MAKE (if it was not set?) for > sub-processes. But maybe only if it thinks its recursive make? I suppose I'll start using the 'MAKE=gmake ..' form or some variation as I use tcsh.
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #6 from Richard Biener --- (In reply to Steve Kargl from comment #4) > On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot > apl.washington.edu wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 > > > > --- Comment #3 from Steve Kargl > > --- > > On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote: > > > > > > --- Comment #1 from Andrew Pinski --- > > > This is not a testsuite issue but rather the issue is the lto code is > > > calling > > > make ... > > > > > > > That explains why groping around in gcc/testsuite for > > a rogue make or MAKE was coming up empty. > > > > I'm in the middle of doing a serial 'gmake check-fortran', > > which takes a long time on my system. Is there a way > > to invoke only lto testing? > > So, 'gmake check-fortran' finishes without any lto issues. > It seems one must invoke the checking with 'gmake -j6 check-fortran' > to get failures. > > Looking in obj/gcc/Makefile at line 341 I see the comment > > # Make sure the $(MAKE) variable is defined. > > followed by no checking to see if MAKE is defined. Makefile.in has # Make sure the $(MAKE) variable is defined. @SET_MAKE@ configure has if eval test \$ac_cv_prog_make_${ac_make}_set = yes; then { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5 $as_echo "yes" >&6; } SET_MAKE= else { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 $as_echo "no" >&6; } SET_MAKE="MAKE=${MAKE-make}" fi from AC_PROG_MAKE_SET which seems to check whether make sets $MAKE. That appearantly succeeds for you. Do you "properly" do sth like MAKE=gmake ../configure so configure sees which make you are using? I think if your gmake doesn't set it then even recursive configure invocations from gmake will resort to 'make' but then I _think_ that gmake itself sets $MAKE (if it was not set?) for sub-processes. But maybe only if it thinks its recursive make?
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #5 from Steve Kargl --- On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 > > --- Comment #3 from Steve Kargl --- > On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote: > > > > --- Comment #1 from Andrew Pinski --- > > This is not a testsuite issue but rather the issue is the lto code is > > calling > > make ... > > > > That explains why groping around in gcc/testsuite for > a rogue make or MAKE was coming up empty. > > I'm in the middle of doing a serial 'gmake check-fortran', > which takes a long time on my system. Is there a way > to invoke only lto testing? > Answered my own question. % gmake RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran ... === gfortran Summary === # of expected passes1 % gmake -j 1 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran ... === gfortran Summary === # of expected passes1 % gmake -j 2 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran ... FAIL: gfortran.dg/pr71526.f90 -O (test for excess errors) === gfortran Summary === # of unexpected failures1 % setenv MAKE gmake % gmake -j 2 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran ... === gfortran Summary === # of expected passes1 So, the work around is to explicitly set MAKE to gmake before running the testsuite.
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #4 from Steve Kargl --- On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 > > --- Comment #3 from Steve Kargl --- > On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote: > > > > --- Comment #1 from Andrew Pinski --- > > This is not a testsuite issue but rather the issue is the lto code is > > calling > > make ... > > > > That explains why groping around in gcc/testsuite for > a rogue make or MAKE was coming up empty. > > I'm in the middle of doing a serial 'gmake check-fortran', > which takes a long time on my system. Is there a way > to invoke only lto testing? So, 'gmake check-fortran' finishes without any lto issues. It seems one must invoke the checking with 'gmake -j6 check-fortran' to get failures. Looking in obj/gcc/Makefile at line 341 I see the comment # Make sure the $(MAKE) variable is defined. followed by no checking to see if MAKE is defined.
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #3 from Steve Kargl --- On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote: > > --- Comment #1 from Andrew Pinski --- > This is not a testsuite issue but rather the issue is the lto code is calling > make ... > That explains why groping around in gcc/testsuite for a rogue make or MAKE was coming up empty. I'm in the middle of doing a serial 'gmake check-fortran', which takes a long time on my system. Is there a way to invoke only lto testing?
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #2 from Andrew Pinski --- lto-wrapper.cc use MAKE env if it exists: char **make_argv = buildargv (getenv ("MAKE")); if (make_argv) { for (unsigned argc = 0; make_argv[argc]; argc++) obstack_ptr_grow (_obstack, make_argv[argc]); } else obstack_ptr_grow (_obstack, "make"); obstack_ptr_grow (_obstack, "-f"); obstack_ptr_grow (_obstack, makefile); if (!jobserver) { snprintf (jobs, 31, "-j%ld", auto_parallel ? nthreads_var : parallel); obstack_ptr_grow (_obstack, jobs); } But I don't see why gmake is failing to set MAKE env correctly here ...
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 Andrew Pinski changed: What|Removed |Added Component|testsuite |driver Keywords||lto --- Comment #1 from Andrew Pinski --- This is not a testsuite issue but rather the issue is the lto code is calling make ...