[Bug driver/98943] New: gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[Bug driver/98943] New: gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[slyfox at gcc dot gnu.org]

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

            Bug ID: 98943
           Summary: gcc driver does not fail on unknown files: tricks
                    configure scripts to recognize /W4 and -diag-disable
                    1,2,3,4 options
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Example failures are extracted from Gentoo downstream:
- https://bugs.gentoo.org/768399: gdal build failure (-diag-disable)
- https://bugs.gentoo.org/768222: lz4 build failure (/W4 option)

$ gcc-11.0.0 /W4 -c -x c /dev/null
gcc-11.0.0: warning: /W4: linker input file unused because linking not done

$ gcc-10.2.0 /W4 -c -x c /dev/null
gcc-10.2.0: error: /W4: No such file or directory

$ gcc-11.0.0 -diag-disable 188,1684,2259,2304,3280,11074,11076 -c -x c
/dev/null
cc1: warning: unrecognized gcc debugging option: i
cc1: warning: unrecognized gcc debugging option: g
cc1: warning: unrecognized gcc debugging option: -
cc1: warning: unrecognized gcc debugging option: d
cc1: warning: unrecognized gcc debugging option: i
cc1: warning: unrecognized gcc debugging option: s
cc1: warning: unrecognized gcc debugging option: b
cc1: warning: unrecognized gcc debugging option: l
cc1: warning: unrecognized gcc debugging option: e
gcc-11.0.0: warning: 188,1684,2259,2304,3280,11074,11076: linker input file
unused because linking not done

$ gcc-10.2.0 -diag-disable 188,1684,2259,2304,3280,11074,11076 -c -x c
/dev/null
gcc-10.2.0: error: 188,1684,2259,2304,3280,11074,11076: No such file or
directory

Was gcc change intentional and upstream packages should try harder to test
flags against linker as well? Or it's an unintentional gcc change?

Thanks!

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.0.0_pre9999/work/gcc-11.0.0_pre9999/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.0.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/python
--enable-languages=c,c++,go,jit,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 11.0.0_pre9999 p6, commit
33a1e511b57465d898429740377466894a0b247d' --disable-esp --enable-libstdcxx-time
--enable-host-shared --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-systemtap
--enable-valgrind-annotations --enable-vtable-verify --with-zstd --enable-lto
--with-isl --disable-isl-version-check --enable-default-pie
--enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20210201 (experimental) (Gentoo 11.0.0_pre9999 p6, commit
33a1e511b57465d898429740377466894a0b247d)

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
           Keywords|                            |needs-bisection
           Priority|P3                          |P1
            Summary|gcc driver does not fail on |[11 Regression] gcc driver
                   |unknown files: tricks       |does not fail on unknown
                   |configure scripts to        |files: tricks configure
                   |recognize /W4 and           |scripts to recognize /W4
                   |-diag-disable 1,2,3,4       |and -diag-disable 1,2,3,4
                   |options                     |options

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Definitely undesired.

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-02-03
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |nathan at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Haven't bisected, but just git blame tells me this is
r11-6855-g4804de453e7f5f90dd5e64114abbd272f9e8f62d
aka PR98452 change.
I think we should reconsider that, perhaps limit to modules only or something.

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[nathan at gcc dot gnu.org]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |nathan at gcc dot gnu.org

--- Comment #3 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
sad face.  It seems wrong for the driver to duplicate the file-location logic
of each of the various compilers.  But these failure modes are unsatisfactory
too.

Perhaps the driver should reject all unrecognized options that begin with '-'. 
If you really have a file named thusly, use './-$FOO'.  (I'd prefer it this
way, rather than an 'ok if -$FOO is a file', as that can lead to confusion as
we discussed in the breaking commit around @file handling).

As for trying to use DOS option syntax, because of their similarity to absolute
pathnames, perhaps those we should stat to see if it is a file.

I am hesitant to make a modules-specific exception to the old behaviour as
modules will eventually become a default C++ thing, and these'll all fail again
then. (or we push even more cc1plus logic into the driver)

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For -diag-disable , even gcc 10 would just warn on that rather than error:
gcc -S -diag-disable -xc /dev/null
cc1: warning: unrecognized gcc debugging option: i
cc1: warning: unrecognized gcc debugging option: g
cc1: warning: unrecognized gcc debugging option: -
cc1: warning: unrecognized gcc debugging option: d
cc1: warning: unrecognized gcc debugging option: i
cc1: warning: unrecognized gcc debugging option: s
cc1: warning: unrecognized gcc debugging option: b
cc1: warning: unrecognized gcc debugging option: l
cc1: warning: unrecognized gcc debugging option: e

It is just that one got error because 188,1684,... wasn't an existing filename.

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Created attachment 50119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50119&action=edit
proposed direction

Here's a test patch.  As Jakub points out, we pass -d$ANYTHING to the compiler,
it is the following 123,456 that is considered a file to pass to the linker. 
It's fun trying to find a -OPTION that the driver doesn't pass to the linker
and doesn't already reject.  '-n' is one.

a) Reject any filename that is -STUFF (allow plain '-')
b) Reject any absolute path that is not accessible
c) When ignoring linker files, error if they are inaccessible.  If there are
funky ways of spelling a member of an archive, why are you trying to pass them
when not linking (i.e.  you're doing something specialized, do it in the right
place)

devvm1702:116>./xg++ -B./ -diag 123,44 -x c -c /dev/null
cc1: warning: unrecognized gcc debugging option: i
cc1: warning: unrecognized gcc debugging option: g
xg++: error: 123,44: unreadable linker input file file unused because linking
is not done: No such file or directory

devvm1702:120>./xg++ -B./ -nart bob.c 
xg++: error: unrecognized command-line option '-nart'

though I notice:

devvm1702:121>./xg++ -B./ -nope bob.c 
xg++: error: unrecognized command-line option '-nope'; did you mean '-no-pie'?

perhaps that check should apply to all - options, and not just near misses?

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
spotted the 'file file' typo in the linker error, btw

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 3 Feb 2021, nathan at gcc dot gnu.org via Gcc-bugs wrote:

> a) Reject any filename that is -STUFF (allow plain '-')

Any -STUFF that's not a known option should be handled as 
OPT_SPECIAL_unknown and should not go through OPT_SPECIAL_input_file code 
at all.

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Affects compiler-rt cmake configury too: /wd4146 /wd4291 /wd4391 /wd4722
/wd4800
See https://bugzilla.redhat.com/show_bug.cgi?id=1923664

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathan Sidwell <nathan@gcc.gnu.org>:

https://gcc.gnu.org/g:6606b852bfa866c19375a7c5e9cb94776a28bd94

commit r11-7124-g6606b852bfa866c19375a7c5e9cb94776a28bd94
Author: Nathan Sidwell <nathan@acm.org>
Date:   Thu Feb 4 08:16:17 2021 -0800

    driver: error for nonexistent linker inputs [PR 98943]

    We used to check all unknown input files, even when passing them to a
    compiler.  But that caused problems.  However, not erroring out on
    non-existent would-be-linker inputs confuses configure machinery that
    probes the compiler to see if it accepts various inputs.  This
    restores the access check for things that are thought to be linker
    input files, when we're not linking.  (If we are linking, we presume
    the linker will error out on its own accord.)

            PR driver/98943
            gcc/
            * gcc.c (driver::maybe_run_linker): Check for input file
            accessibility if not linking.
            gcc/testsuite/
            * c-c++-common/pr98943.c: New.

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[nathan at gcc dot gnu.org]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

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

--- Comment #10 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
 6606b852bfa 2021-02-04 | driver: error for nonexistent linker inputs [PR
98943]

I think that's sufficient, but please reopen if it is not.