[Bug c++/97574] New: Allow for nul output with Windows

[Bug c++/97574] New: Allow for nul output with Windows

[svnpenn at gmail dot com]

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

            Bug ID: 97574
           Summary: Allow for nul output with Windows
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: svnpenn at gmail dot com
  Target Milestone: ---

Allow for nul output with Windows

A project I am trying to compile has this command:

    cc -xc++ -o/dev/null -lc++ -shared

However I am using PowerShell, which has no notion of `/dev/null`:

    PS C:\> cc -xc++ -o/dev/null -lc++ -shared
    C:/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../
    x86_64-w64-mingw32/bin/ld.exe: cannot open output file /dev/null.exe: No
    such file or directory

I tried using `-o$null`, but it just creates a file `$null.exe`. I also tried
this:

    PS C:\> cc -xc++ -o $null -lc++ -shared
    cc.exe: fatal error: no input files

It appears the issue is specific to GCC. If I get Clang [1], the same command
works with `nul` [2]:

    cc -xc++ -onul -lc++ -shared

but if I try the same thing with GCC, I get this:

    C:/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../
    x86_64-w64-mingw32/bin/ld.exe: nul.exe: final close failed: file truncated

Alternatively, if anyone knows a better way to check the availability of a
library, I would be interested in that.

[1] https://github.com/mstorsjo/llvm-mingw
[2] https://support.microsoft.com/help/110930

[Bug driver/97574] Allow for nul output with Windows

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think "nul" should work, but it looks like the error is in the linker,
ld.exe, not GCC.

[Bug driver/97574] Allow for nul output with Windows

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org

--- Comment #2 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
error is in the driver, it's accidentally adding the suffix when nul device is
used and making the filename invalid.

diff --git a/gcc/gcc.c b/gcc/gcc.c
index ff7b6c4a320..74438f63046 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -3651,7 +3651,7 @@ convert_filename (const char *name, int do_exe
ATTRIBUTE_UNUSED,
 #if defined(HAVE_TARGET_EXECUTABLE_SUFFIX)
   /* If there is no filetype, make it the executable suffix (which includes
      the ".").  But don't get confused if we have just "-o".  */
-  if (! do_exe || TARGET_EXECUTABLE_SUFFIX[0] == 0 || (len == 2 && name[0] ==
'-'))
+  if (! do_exe || TARGET_EXECUTABLE_SUFFIX[0] == 0 || not_actual_file_p
(name))
     return name;

   for (i = len - 1; i >= 0; i--)

should fix it, but can't test till later.

[Bug driver/97574] Allow for nul output with Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-10-26
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Confirmed then.

[Bug driver/97574] Allow for nul output with Windows

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Submitted a patch to get the driver to stop mangling nul so it makes it easier
for binutils to detect.

That said Jonathan is right in that there's still a binutils bug here. I had
forgotten that even though MSDN recommends against using extensions with
special filenames that it's not an error.

It looks like binutils is failing in bfd_close, looks like it's using stat to
detect special files, however on windows stat("nul") seems to be returning
_S_IFREG.  You'll need to report a ticker there for this.

I'll leave this open since the nul device shouldn't get an extension.

[Bug driver/97574] Allow for nul output with Windows

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:200c9e865f49255ea32d4891b746d394d156a16f

commit r11-5078-g200c9e865f49255ea32d4891b746d394d156a16f
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Tue Nov 17 10:14:53 2020 +0000

    MingW: Don't add suffix for nul device

    This patch fixes an issue where on systems that are
    HAVE_TARGET_EXECUTABLE_SUFFIX the driver calls convert_filename in order to
    add the suffix to the filename.  However while it excludes `-` it doesn't
    exclude the null device.  This patches changes the check to exclude
anything
    that is not a file by calling not_actual_file_p instead.

    This also fixes a bug in not_actual_file_p which was accidentally testing
    a the global variable output_file instead of the supplied argument.  This
    hasn't been an issue so far because because not_actual_file_p was only used
    on output_file till now.

    This fixes the adding of an extension to the nul device which is against
    the recommendations on msdn[0] and makes it harder for the next tool in
line
    to detect it.

    Bootstrapped Regtested on x86_64-w64-mingw32 and no issues.
    Did do a bootstrap on x86_64-pc-linux-gnu but no regtest as it's not a
    HAVE_TARGET_EXECUTABLE_SUFFIX system.

    [0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file

    gcc/ChangeLog:

            PR driver/97574
            * gcc.c (convert_filename): Don't add suffix to things that are
            not files.
            (not_actual_file_p): Use supplied argument.

[Bug driver/97574] Allow for nul output with Windows

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
The GCC part is fixed, I'll look at the binutils part this weekend.