[Bug driver/101238] Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS

["tomas.kalibera at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #2 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
I started writing that email, but on the way I found that one should add
-D__USE_MINGW_ACCESS also BOOT_CXXFLAGS, which I have neither done nor tested.
The problem I debugged required only required adding to CXXFLAGS.

In principle, one needs to add -D__USE_MINGW_ACCESS everywhere, where GCC might
use "access()" to query X_OK, so it should be safe to add simply everywhere
when compiling C or C++, it just must have been forgotten.

I see -D__USE_MINGW_ACCESS has been added to CXXFLAGS and BOOT_CXXFLAGS in GCC
11 by a patch from Martin Storsjo, "mh-mingw: Set __USE_MINGW_ACCESS in missed
C++ flags variables",
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567815.html

And it is related to "[MinGW] Set __USE_MINGW_ACCESS for C++ as well"
https://gcc.gnu.org/pipermail/gcc-patches/2019-March/518147.html
(done also in GCC 10), which adds __USE_MINGW_ACCESS to STAGE*_CXXFLAGS.

My testing was using an MXE-based build of GCC 10.2 (cross-compiled on Linux,
for 64-bit Windows, with MinGW-w64 7). Without the change, gcc.exe did not find
cc1.exe. Process monitor showed that gcc.exe called stat on cc1.exe
successfully (so used the correct path already the first time), but then
continued checking other locations and when it failed, tried to execute without
path name (relying on system PATH). So a workaround I have been using was to
have also cc1.exe on PATH, where it would be found by Windows (so the problem
of access(,X_OK) did not apply there).

Then the observed behavior matched the code of the driver gcc.c, which calls
access(,X_OK) to check that cc1.exe is executable, and it incorrectly concludes
that it isn't. Which in turn is because access on Windows does not support X_OK
(and __USE_MINGW_ACCESS provides a MinGW replacement which does). I've
confirmed this was what happened via adding print statements to the driver and
rebuilding. And eventually I rebuilt gcc with the proposed patch and it found
cc1.exe fine.

Should I still send a copy of Martin Storsjo's patch to
gcc-patches@gcc.gnu.org, or is this information here now sufficient?