[PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Olivier Hainque]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Hello,

Bootstrap for mingw target configurations is failing today, with complaints
about an inexistant /dev/null.

The failing commands are issued by the selftest recipes in gcc/Makefile, using:

    SELFTEST_FLAGS = -nostdinc /dev/null -S -o /dev/null \
            -fself-test=$(srcdir)/testsuite/selftests

The attached patch is a proposal to fix this by resorting to "nul" instead of
"/dev/null" when the build machine name indicates a mingw setup.

It fixes the gcc-7 bootstrap in our Windows setup (i686-pc-mingw32), and passes
bootstrap and regression tests on x86_64-linux.

OK to commit ?

Thanks much in advance,

With Kind Regards,

Olivier

2017-11-24  Olivier Hainque  <hainque@adacore.com>

	* Makefile.in (SELFTEST_FLAGS): Use nul instead of /dev/null
	on mingw build hosts.


[-- Attachment #2: dev_null.diff --]
[-- Type: application/octet-stream, Size: 886 bytes --]

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 5db7855..9b7ca1b 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1907,9 +1907,12 @@ rest.cross: specs
 # Specify -o /dev/null so the output of -S is discarded. More importantly
 # It does not try to create a file with the name "null.s" on POSIX and
 # "nul.s" on Windows. Because on Windows "nul" is a reserved file name.
+# Beware that /dev/null is not available for mingw tools, so directly use
+# "nul" instead of "/dev/null" if we're building on a mingw machine.
 # Specify the path to gcc/testsuite/selftests within the srcdir
 # as an argument to -fself-test.
-SELFTEST_FLAGS = -nostdinc /dev/null -S -o /dev/null \
+DEVNULL=$(if $(findstring mingw,$(build)),nul,/dev/null)
+SELFTEST_FLAGS = -nostdinc $(DEVNULL) -S -o $(DEVNULL) \
 	-fself-test=$(srcdir)/testsuite/selftests
 
 C_SELFTEST_FLAGS = -xc $(SELFTEST_FLAGS)

Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Jeff Law]

On 11/24/2017 11:18 AM, Olivier Hainque wrote:
> Hello,
> 
> Bootstrap for mingw target configurations is failing today, with complaints
> about an inexistant /dev/null.
> 
> The failing commands are issued by the selftest recipes in gcc/Makefile, using:
> 
>     SELFTEST_FLAGS = -nostdinc /dev/null -S -o /dev/null \
>             -fself-test=$(srcdir)/testsuite/selftests
> 
> The attached patch is a proposal to fix this by resorting to "nul" instead of
> "/dev/null" when the build machine name indicates a mingw setup.
> 
> It fixes the gcc-7 bootstrap in our Windows setup (i686-pc-mingw32), and passes
> bootstrap and regression tests on x86_64-linux.
> 
> OK to commit ?
> 
> Thanks much in advance,
> 
> With Kind Regards,
> 
> Olivier
> 
> 2017-11-24  Olivier Hainque  <hainque@adacore.com>
> 
> 	* Makefile.in (SELFTEST_FLAGS): Use nul instead of /dev/null
> 	on mingw build hosts.
Would it make more sense to set the output file to HOST_BIT_BUCKET when
-fselftest is active?

Jeff

Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Olivier Hainque]

Hi Jeff,

(Thanks for your feedback)

> On Nov 27, 2017, at 04:55 , Jeff Law <law@redhat.com> wrote:
> 
>> 	* Makefile.in (SELFTEST_FLAGS): Use nul instead of /dev/null
>> 	on mingw build hosts.
> Would it make more sense to set the output file to HOST_BIT_BUCKET when
> -fselftest is active?


Hmm, possibly. Interesting suggestion :)

David, who introduced the framework, would
know for sure - cc'ed.

David, thoughts on this ?

Thanks much in advance,

With Kind Regards,

Olivier

Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Olivier Hainque]

(typo in David's email address in the previous message,
resending. sorry for the duplicates)

Hi Jeff,

(Thanks for your feedback)

> On Nov 27, 2017, at 04:55 , Jeff Law <law@redhat.com> wrote:
> 
>> 	* Makefile.in (SELFTEST_FLAGS): Use nul instead of /dev/null
>> 	on mingw build hosts.
> Would it make more sense to set the output file to HOST_BIT_BUCKET when
> -fselftest is active?


Hmm, possibly. Interesting suggestion :)

David, who introduced the framework, would
know for sure - cc'ed.

David, thoughts on this ?

Thanks much in advance,

With Kind Regards,

Olivier

Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[David Malcolm]

On Mon, 2017-11-27 at 09:40 +0100, Olivier Hainque wrote:
> (typo in David's email address in the previous message,
> resending. sorry for the duplicates)
> 
> Hi Jeff,
> 
> (Thanks for your feedback)
> 
> > On Nov 27, 2017, at 04:55 , Jeff Law <law@redhat.com> wrote:
> > 
> > > 	* Makefile.in (SELFTEST_FLAGS): Use nul instead of /dev/null
> > > 	on mingw build hosts.
> > 
> > Would it make more sense to set the output file to HOST_BIT_BUCKET
> > when
> > -fselftest is active?
> 
> 
> Hmm, possibly. Interesting suggestion :)
> 
> David, who introduced the framework, would
> know for sure - cc'ed.
> 
> David, thoughts on this ?
 
[CCing Tamar]

The selftests currently assume both:
(a) reading a source file from /dev/null, and
(b) writing the generated asm to /dev/null

I note that r241895 added "-o /dev/null" for the asm output to "Fix the
Windows native x86-64 build.":

+2016-11-07  Tamar Christina  <tamar.christina@arm.com>
+
+       PR driver/78196
+       * Makefile.in (SELFTEST_FLAGS): Added -o /dev/null.
+

HOST_BIT_BUCKET seems to be a header thing, rather than a Makefile
thing; presumably there would need to be logic to handle both input and
output for the HOST_BIT_BUCKET approach.

Given that, I prefer Olivier's patch - it seems simpler to me.

Dave

Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Jeff Law]

On 11/27/2017 03:16 PM, David Malcolm wrote:
> On Mon, 2017-11-27 at 09:40 +0100, Olivier Hainque wrote:
>> (typo in David's email address in the previous message,
>> resending. sorry for the duplicates)
>>
>> Hi Jeff,
>>
>> (Thanks for your feedback)
>>
>>> On Nov 27, 2017, at 04:55 , Jeff Law <law@redhat.com> wrote:
>>>
>>>> 	* Makefile.in (SELFTEST_FLAGS): Use nul instead of /dev/null
>>>> 	on mingw build hosts.
>>>
>>> Would it make more sense to set the output file to HOST_BIT_BUCKET
>>> when
>>> -fselftest is active?
>>
>>
>> Hmm, possibly. Interesting suggestion :)
>>
>> David, who introduced the framework, would
>> know for sure - cc'ed.
>>
>> David, thoughts on this ?
>  
> [CCing Tamar]
> 
> The selftests currently assume both:
> (a) reading a source file from /dev/null, and
> (b) writing the generated asm to /dev/null
> 
> I note that r241895 added "-o /dev/null" for the asm output to "Fix the
> Windows native x86-64 build.":
> 
> +2016-11-07  Tamar Christina  <tamar.christina@arm.com>
> +
> +       PR driver/78196
> +       * Makefile.in (SELFTEST_FLAGS): Added -o /dev/null.
> +
> 
> HOST_BIT_BUCKET seems to be a header thing, rather than a Makefile
> thing; presumably there would need to be logic to handle both input and
> output for the HOST_BIT_BUCKET approach.
Well, the idea was that HOST_BIT_BUCKET is available inside the compiler
itself.  So rather than hacking it into the Makefile as well, we'd just
force the compiler driver to DTRT, utilizing the existing xm.h define
along the way.

> 
> Given that, I prefer Olivier's patch - it seems simpler to me.
OK.  I can live with it.

jeff

Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Olivier Hainque]

> On Nov 28, 2017, at 07:20 , Jeff Law <law@redhat.com> wrote:

>> Given that, I prefer Olivier's patch - it seems simpler to me.
> OK.  I can live with it.

Thanks for for your reviews Jeff and David. Will commit.

Windows hosts are full of surprises. It shouldn't be hard to
revisit the approach if need be.

With Kind Regards,

Olivier

RE: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Tamar Christina]

Sending reply to list.

> -----Original Message-----
> From: Tamar Christina
> Sent: Tuesday, November 28, 2017 10:02
> To: 'David Malcolm' <dmalcolm@redhat.com>; Olivier Hainque
> <hainque@adacore.com>; Jeff Law <law@redhat.com>
> Cc: GCC Patches <gcc-patches@gcc.gnu.org>
> Subject: RE: [PATCH, Makefile.in] refine selftest recipes to restore mingw
> bootstrap
> 
> > -----Original Message-----
> > From: David Malcolm [mailto:dmalcolm@redhat.com]
> > Sent: Monday, November 27, 2017 22:16
> > To: Olivier Hainque <hainque@adacore.com>; Jeff Law <law@redhat.com>
> > Cc: GCC Patches <gcc-patches@gcc.gnu.org>; Tamar Christina
> > <Tamar.Christina@arm.com>
> > Subject: Re: [PATCH, Makefile.in] refine selftest recipes to restore
> > mingw bootstrap
> >
> > On Mon, 2017-11-27 at 09:40 +0100, Olivier Hainque wrote:
> > > (typo in David's email address in the previous message, resending.
> > > sorry for the duplicates)
> > >
> > > Hi Jeff,
> > >
> > > (Thanks for your feedback)
> > >
> > > > On Nov 27, 2017, at 04:55 , Jeff Law <law@redhat.com> wrote:
> > > >
> > > > > 	* Makefile.in (SELFTEST_FLAGS): Use nul instead of /dev/null
> > > > > 	on mingw build hosts.
> > > >
> > > > Would it make more sense to set the output file to HOST_BIT_BUCKET
> > > > when -fselftest is active?
> > >
> > >
> > > Hmm, possibly. Interesting suggestion :)
> > >
> > > David, who introduced the framework, would know for sure - cc'ed.
> > >
> > > David, thoughts on this ?
> >
> > [CCing Tamar]
> >
> > The selftests currently assume both:
> > (a) reading a source file from /dev/null, and
> > (b) writing the generated asm to /dev/null
> >
> > I note that r241895 added "-o /dev/null" for the asm output to "Fix
> > the Windows native x86-64 build.":
> >
> > +2016-11-07  Tamar Christina  <tamar.christina@arm.com>
> > +
> > +       PR driver/78196
> > +       * Makefile.in (SELFTEST_FLAGS): Added -o /dev/null.
> > +
> 
 Yeah I choose this fix because /dev/null is converted to "nul" by the
 Cygwin/msys2 runtime. So when invoked On the shell it gets converted
 before GCC sees it.
 
 Nothing against using nul directly, though I am surprised that there's an
 environment that provides Configure, automake and coreutils which doesn't
 convert /dev/null to nul.
 
Thanks,
Tamar
> 
> 
> > HOST_BIT_BUCKET seems to be a header thing, rather than a Makefile
> > thing; presumably there would need to be logic to handle both input
> > and output for the HOST_BIT_BUCKET approach.
> >
> > Given that, I prefer Olivier's patch - it seems simpler to me.
> >
> > Dave

Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Olivier Hainque]

Hello Tamar,

> On Nov 28, 2017, at 11:05 , Tamar Christina <tamar.christina@arm.com> wrote:
> 
> Yeah I choose this fix because /dev/null is converted to "nul" by the
> Cygwin/msys2 runtime. So when invoked On the shell it gets converted
> before GCC sees it.
> 
> Nothing against using nul directly, though I am surprised that there's an
> environment that provides Configure, automake and coreutils which doesn't
> convert /dev/null to nul.

My understanding is that it's not only a property of
the environment in which the tool gets executed, but also of
the tool itself.

For gcc in particular, ISTM it depends on the target for
which you configured.

Our toolchains are configured for x86_64-pc-mingw32

Maybe yours are configured for cygwin, not mingw (are they ?),
and then are linked with cygwin libraries which perform various
transformations.

Olivier

RE: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Tamar Christina]

Hi Olivier,

> -----Original Message-----
> From: Olivier Hainque [mailto:hainque@adacore.com]
> Sent: Tuesday, November 28, 2017 10:40
> To: Tamar Christina <Tamar.Christina@arm.com>
> Cc: Olivier Hainque <hainque@adacore.com>; David Malcolm
> <dmalcolm@redhat.com>; Jeff Law <law@redhat.com>; GCC Patches <gcc-
> patches@gcc.gnu.org>; nd <nd@arm.com>
> Subject: Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw
> bootstrap
> 
> Hello Tamar,
> 
> > On Nov 28, 2017, at 11:05 , Tamar Christina <tamar.christina@arm.com>
> wrote:
> >
> > Yeah I choose this fix because /dev/null is converted to "nul" by the
> > Cygwin/msys2 runtime. So when invoked On the shell it gets converted
> > before GCC sees it.
> >
> > Nothing against using nul directly, though I am surprised that there's
> > an environment that provides Configure, automake and coreutils which
> > doesn't convert /dev/null to nul.
> 
> My understanding is that it's not only a property of the environment in which
> the tool gets executed, but also of the tool itself.
> 
> For gcc in particular, ISTM it depends on the target for which you configured.

This is true, but In this case, the tool should have never seen "/dev/null". Since the invocation
Of the command that uses SELFTEST_FLAGS should have converted it. Unless you're using
Something like mingw32-make, which would explain the difference.

> 
> Our toolchains are configured for x86_64-pc-mingw32
> 
> Maybe yours are configured for cygwin, not mingw (are they ?), and then are
> linked with cygwin libraries which perform various transformations.

No, mine are configured for x86_64-w64-mingw32 and are just native gcc builds.
It's just build using cygwin derived tools to not encounter certain differences like this one.

I think using nul is fine if it makes your use-case work, it shouldn't break the mingw64 builds.

Thanks,
Tamar

> 
> Olivier
> 

Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap

[Olivier Hainque]

> On Nov 28, 2017, at 11:56 , Tamar Christina <Tamar.Christina@arm.com> wrote:
>> For gcc in particular, ISTM it depends on the target for which you configured.
> 
> This is true, but In this case, the tool should have never seen "/dev/null". Since the invocation
> Of the command that uses SELFTEST_FLAGS should have converted it. Unless you're using
> Something like mingw32-make, which would explain the difference.

Oh, right. We are using

  GNU Make 3.82.90
  Built for i686-w64-mingw32

>> Maybe yours are configured for cygwin, not mingw (are they ?), and then are
>> linked with cygwin libraries which perform various transformations.
> 
> No, mine are configured for x86_64-w64-mingw32 and are just native gcc builds.
> It's just build using cygwin derived tools to not encounter certain differences like this one.
> 
> I think using nul is fine if it makes your use-case work, it shouldn't break the mingw64 builds.

OK. It does help our use case for sure.

Thanks for your feedback!

Olivier