[Bug testsuite/109135] New: Wrong make utility called with LTO testsuite

[Bug testsuite/109135] New: Wrong make utility called with LTO testsuite

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135

            Bug ID: 109135
           Summary: Wrong make utility called with LTO testsuite
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

It seems the wrong make utility is being invoked when the testsuite tries to
run tests for LTO.  On FreeBSD, make is BSD make.  GNU make is installed as
gmake.  After bootstrapping gcc with gfortran support, I move into the obj/gcc
directory an execute 

% gmake -j6 check-fortran

There a number of failures reported.  In fact, with 'gmake -j6 check' is a
massive number of failures.  Looking into testsuite/gfortran/gfortran.log, I
see for example,


Executing on host: /usr/home/sgk/gcc/objx/gcc/testsuite/gfortran/../../gfortran
  -B/usr/home/sgk/gcc/objx/gcc/testsuite/gfortran/../../
  -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/
    /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/pr71526.f90 
  -fdiagnostics-plain-output  -fdiagnostics-plain-output  -O  -O2 -flto  
  -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libatomic/.libs
  -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs
  -lm  -o pr71526.exe    (timeout = 300)
spawn -ignore SIGHUP /usr/home/sgk/gcc/objx/gcc/testsuite/gfortran/../../\
  gfortran
  -B/usr/home/sgk/gcc/objx/gcc/testsuite/gfortran/../../
  -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/
  /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/pr71526.f90
  -fdiagnostics-plain-output -fdiagnostics-plain-output -O -O2 -flto
  -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libatomic/.libs
  -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs
  -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs
  -lm -o pr71526.exe
make[2]: illegal argument to -j -- must be positive integer!
FAIL: gfortran.dg/pr71526.f90   -O  (test for excess errors)
Excess errors:
make[2]: illegal argument to -j -- must be positive integer!

With BSD make and if one my projects, I see

% make -j Makefile
make: illegal argument to -j -- must be positive integer!
% make -j 0 Makefile
make: illegal argument to -j -- must be positive integer!
% make -j -6 Makefile
make: illegal argument to -j -- must be positive integer!

If run gmake with a Makefile suitable for gmake, I see
% gmake -j -6 -f Makefile.gnu
<GNU make usage message>
% gmake -j 0 -f Makefile.gnu
<GNU make usage message>
% gmake -j  -f Makefile.gnu
<GNU make builds my project>

I suspect the something in the testsuite is spawning a submake where the last
'gmake -j' example above is being spawned as the first 'make -j' example above.

[Bug driver/109135] Wrong make utility called with LTO testsuite

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|testsuite                   |driver
           Keywords|                            |lto

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is not a testsuite issue but rather the issue is the lto code is calling
make ...

[Bug driver/109135] Wrong make utility called with LTO testsuite

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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 (&argv_obstack, make_argv[argc]);
            }
          else
            obstack_ptr_grow (&argv_obstack, "make");

          obstack_ptr_grow (&argv_obstack, "-f");
          obstack_ptr_grow (&argv_obstack, makefile);
          if (!jobserver)
            {
              snprintf (jobs, 31, "-j%ld",
                        auto_parallel ? nthreads_var : parallel);
              obstack_ptr_grow (&argv_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

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Mar 14, 2023 at 10:25:53PM +0000, pinskia at gcc dot gnu.org wrote:
> 
> --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> 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

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Mar 14, 2023 at 10:36:27PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
> 
> --- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
> On Tue, Mar 14, 2023 at 10:25:53PM +0000, pinskia at gcc dot gnu.org wrote:
> > 
> > --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> > 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

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Mar 14, 2023 at 10:36:27PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
> 
> --- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
> On Tue, Mar 14, 2023 at 10:25:53PM +0000, pinskia at gcc dot gnu.org wrote:
> > 
> > --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> > 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 passes            1

% gmake -j 1 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran
...
                === gfortran Summary ===

# of expected passes            1

% gmake -j 2 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran
...
FAIL: gfortran.dg/pr71526.f90   -O  (test for excess errors)

                === gfortran Summary ===

# of unexpected failures        1

% setenv MAKE gmake
% gmake -j 2 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran
...
                === gfortran Summary ===

# of expected passes            1

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Steve Kargl from comment #4)
> On Tue, Mar 14, 2023 at 10:36:27PM +0000, sgk at troutmask dot
> apl.washington.edu wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
> > 
> > --- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
> > On Tue, Mar 14, 2023 at 10:25:53PM +0000, pinskia at gcc dot gnu.org wrote:
> > > 
> > > --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> > > 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

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Mar 15, 2023 at 08:35:41AM +0000, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
> 
> --- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
> (In reply to Steve Kargl from comment #4)
> > On Tue, Mar 14, 2023 at 10:36:27PM +0000, 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.