[Bug other/115189] libiberty introduces UNC paths waking up binutils bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189 --- Comment #8 from Tomas Kalibera --- (In reply to Bill Zissimopoulos from comment #4) > A more robust alternative to GetFinalPathNameByHandleW/VOLUME_NAME_DOS may > be the following: > > - Use GetFinalPathNameByHandleW with VOLUME_NAME_NORMALIZED|VOLUME_NAME_NT. > > - Enumerate all available drives for the current process using > GetLogicalDrives. > > - For each logical drive use QueryDosDeviceW to see if the returned prefix > matches the NT namespace prefix returned by the earlier call to > GetFinalPathNameByHandleW. > > For an example of this approach see the chromium code here: > > https://chromium.googlesource.com/chromium/src/base/+/master/files/ > file_util_win.cc#828 > > (See functions NormalizeFilePath and DevicePathToDriveLetterPath.) I am not sure how this would work. On my system, I get a number of different NT namespace prefixes from QueryDosDevice: (1) \??\UNC\tsclient\share (2) \??\UNC\192.168.0.45\share (3) \Device\LanmanRedirector\;Y:01189cc1\192.168.0.45\share (4) \Device\RdpDr\;Z:2\tsclient\share the forms of (1),(2) are with "subst". The form of (3) is when using Explorer on a real samba drive (also "net use"). The form of (4) is when using Explorer on an RDP share (also "net use"). But, GetFinalPathNameByHandle() returns prefixes in a yet different form: (A) /Device/Mup/192.168.0.45/share (B) /Device/Mup/tsclient/share where (A) is for a real samba drive and (B) for the RDP share. So, simply matching the prefix (whether the result of QueryDosDevice() is a prefix of the result of GetFinalPathNameByHandle) probably wouldn't work?
[Bug other/115189] libiberty introduces UNC paths waking up binutils bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189 --- Comment #7 from Tomas Kalibera --- (In reply to Bill Zissimopoulos from comment #6) > > I can reproduce the problem with "subst" and with the Windows Explorer > > ("File/Map network drive"). I assume the is the usual way to map network > > drives. > > The usual way to map network drives is indeed "Map network drive", but > GetFinalPathNameByHandleW should work with those. I am surprised that it > does not, unless the problem you are experiencing is not related to > GetFinalPathNameByHandleW after all. I am testing using lrealpath.c from libiberty (gcc 13.3), instrumented to make sure GetFinalPathNameByHandle is called and seeing what it returned. It returns UNC paths (\\server\share) for mapped network drives. I've tried with a regular samba network share in addition to the RDP share, the result is the same. On Windows 10 Pro, Version 10.0.19045 Build 19045.
[Bug other/115189] libiberty introduces UNC paths waking up binutils bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189 --- Comment #5 from Tomas Kalibera --- (In reply to Bill Zissimopoulos from comment #4) > I do not currently have access to a Windows system with dev tools, but my > recollection is that the VOLUME_NAME_DOS flag should be sufficient to > correctly find the DOS drive in most cases including network drives. > Unfortunately GetFinalPathNameByHandleW does not work with drives created > with the DefineDosDeviceW API (e.g. drives created using the SUBST utility). > > How are people who stumble on this bug create their drives? Yes, that's probably the case. I can reproduce the problem with "subst" and with the Windows Explorer ("File/Map network drive"). I assume the is the usual way to map network drives. Also, e.g. mklink /D c:\share \\tsclient\share results in "c:\share" normalized to "\\tsclient\share" (though I expect using directory symlinks used this way would be rare).
[Bug other/115189] libiberty introduces UNC paths waking up binutils bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189 --- Comment #3 from Tomas Kalibera --- I hope there is a more elegant solution, but I could think of a best-effort one. Check if the result of the normalization is a UNC path, if yes, check if the original path started with a drive letter, if yes, modify the UNC path replacing the \\server\share by that drive, normalize the modified path again and if it normalizes to the same UNC path, use the version with the drive; otherwise, use the original UNC result of normalization.
[Bug other/115189] New: libiberty introduces UNC paths waking up binutils bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189 Bug ID: 115189 Summary: libiberty introduces UNC paths waking up binutils bug Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- With gcc 13.2 (and binutils 2.42) located on a mapped network drive on Windows, it is not possible to build a trivial example below. It worked with gcc 12.3 (and binutils 2.40). The problem is that a UNC path (\\host\share) is passed to the linker (ld.exe) instead of the traditional drive letter (D:\directory) via which gcc is invoked, and the linker cannot deal with it. Reverting commit e2bb55ec3b70cf45088bb73ba9ca990129328d60 Author: niXman Date: Sat Feb 11 06:18:10 2023 + libiberty: fix lrealpath on Windows NTFS symlinks gcc computes the wrong prefix if invoked through an NTFS symlink. Try to resolve it if possible. PR/108350 libiberty/ChangeLog: * lrealpath.c (lrealpath): try to resolve symlink and use UNC paths where applicable. restores the previous behavior (and I am using it as a work-around). My understanding is (but I've not tested) that this has been fixed in binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=29533 https://sourceware.org/bugzilla/show_bug.cgi?id=31527 However, binutils with that fix haven't been released, yet. It is not impossible that UNC paths newly produced by gcc would confuse some other tools coming from the Unix world (though I've not seen it happen, yet). In principle, I would tend to think that people on Windows use mapped network drives primarily to avoid UNC paths, as their applications may not work with them, so, ideally one should respect that and preserve the mapped network drives in paths. I wonder if it would be possible to defensively amend libiberty following this principle and hence reduce the amount of bugs it wakes up in other software. -- # example output from a trivial example # using Msys2 shell, gcc is on p: mapped from //tsclient/share env PATH=/p/x86_64-w64-mingw32.static.posix/bin:$PATH g++ -o hw hw.c P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find //tsclient/share/x86_64-w64-mingw32.static.posix/bin/../lib/gcc/x86_64-w64-mingw32.static.posix/13.2.0/../../../../lib/crt2.o: Invalid argument P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find //tsclient/share/x86_64-w64-mingw32.static.posix/bin/../lib/gcc/x86_64-w64-mingw32.static.posix/13.2.0/crtbegin.o: Invalid argument P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lstdc++: No such file or directory P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lmingw32: No such file or directory ...
[Bug libstdc++/115122] Incorrect detection of C99 support when cross back builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115122 --- Comment #2 from Tomas Kalibera --- (In reply to Andrew Pinski from comment #1) > When I do cross back builds, I normally don't rebuild the target libraries > and just use the already built target libraries from the cross builds. Since > you are now building the target libraries twice and you really don't need to > though. Thanks, but it is still a bug, right? I've got a report from a user who ran into this in gcc built via MXE (specifically via Rtools which are a fork of MXE for building R and packages), plugins/examples/host-toolchain/gcc-host. I assume MXE builds libstdc++ twice to simplify maintenance of the build scripts which would otherwise have to somehow copy some of the files from the previous build (and ccache is used). The docker file attached is a simplified version of the build but retains the same problem.
[Bug libstdc++/115122] New: Incorrect detection of C99 support when cross-compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115122 Bug ID: 115122 Summary: Incorrect detection of C99 support when cross-compiling Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 58219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58219=edit docker file that reproduces the problem (libstdc++ doesn't use C99 complex functions which are available) When cross-compiling a native toolchain, configuration of libstdc++ incorrectly concludes that there is no C99 support (which then triggers Bug 115117). I've ran into this when building a native toolchain (to run on Windows, produce code for Windows) on a Linux machine. Configure in libstdc++ builds a test program as follows: x86_64-w64-mingw32-c++ -L/opt/gcc-mingw/native/x86_64-w64-mingw32/lib -L/opt/gcc-mingw/native/mingw/lib -isystem /opt/gcc-mingw/native/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/native/mingw/include -o conftest.exe -g -O2 -std=c++11 -fno-exceptions conftest.cpp -lm >&5 so, it tries to build the configure test using the cross-compiler, including the "-std=c++11" argument but not including "-nostdinc++". That way, C99 functions would appear not available, and the test would fail. I've attached a docker file that reproduces the problem. It ends by showing that "c++config.h" ends up with undefined _GLIBCXX11_USE_C99_COMPLEX and also copies the corresponding lines from the config.log of libstdc++. The docker file also builds a cross-compiler (to cross-compile the native compiler), so one can see that in the cross-compilation, the configure tests run as /build/gcc/build-x86_64/./gcc/xgcc -shared-libgcc -B/build/gcc/build-x86_64/./gcc -nostdinc++ -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/src -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/opt/gcc-mingw/x86_64-w64-mingw32/lib -L/opt/gcc-mingw/mingw/lib -isystem /opt/gcc-mingw/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/mingw/include -B/opt/gcc-mingw/x86_64-w64-mingw32/bin/ -B/opt/gcc-mingw/x86_64-w64-mingw32/lib/ -isystem /opt/gcc-mingw/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/x86_64-w64-mingw32/sys-include-o conftest.exe -g -O2 -std=c++11 -fno-exceptions conftest.cpp -lm >&5 and succeeds. Note, it uses "-nostdinc++".
[Bug libstdc++/115117] New: std::exp(Inf) result invalid with --disable-c99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115117 Bug ID: 115117 Summary: std::exp(Inf) result invalid with --disable-c99 Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 58218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58218=edit Example program ("im(e^inf):" should be 0, but is not with --disable-c99) When the C++ library is built without C99 support (e.g. via passing --disable-c99 to configure of gcc), the result of complex std::exp(Inf) is incorrect, the imaginary part is NaN, but it should be zero. It seems this is caused by this code in "complex", which doesn't handle special cases: // 26.2.8/3 exp(__z): Returns the complex base e exponential of x template inline complex<_Tp> __complex_exp(const complex<_Tp>& __z) { return std::polar<_Tp>(exp(__z.real()), __z.imag()); } that calls into: template inline complex<_Tp> polar(const _Tp& __rho, const _Tp& __theta) { __glibcxx_assert( __rho >= 0 ); return complex<_Tp>(__rho * cos(__theta), __rho * sin(__theta)); } where __rho is Inf, so the imaginary part becomes Inf * 0. For example, the glibc implementation handles this special case explicitly as follows (./math/s_cexp_template.c): else if (__glibc_likely (rcls == FP_INFINITE)) { /* Real part is infinite. */ if (__glibc_likely (icls >= FP_ZERO)) { /* Imaginary part is finite. */ FLOAT value = signbit (__real__ x) ? 0 : M_HUGE_VAL; if (icls == FP_ZERO) { /* Imaginary part is 0.0. */ __real__ retval = value; __imag__ retval = __imag__ x; } I've this problem happen via _GLIBCXX11_USE_C99_COMPLEX being disabled by accident, which still has to be investigated, but --disable-c99 reproduces it. Example program from Andrew Johnson is attached. I can reproduce the problem on Windows and Linux (on Windows I get nan, on Linux I get -nan).
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #22 from Tomas Kalibera --- (In reply to CVS Commits from comment #21) > The master branch has been updated by Jonathan Yong : > > https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3 > > commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3 > Author: Tomas Kalibera > Date: Sun Aug 20 02:16:16 2023 + > > Fix format attribute for printf > > Since a long time (GCC 4.4?) GCC does support annotating functions > with either the format attribute "gnu_printf" or "ms_printf" to > distinguish between different format string interpretations. > > However, it seems like the attribute is ignored for the "printf" > symbol; regardless what the function declaration says, GCC treats > it as "ms_printf". This has become an issue now that mingw-w64 > supports using the UCRT instead of msvcrt.dll, and in this case > the stdio functions are declared with the gnu_printf attribute, > and inttypes.h uses the same format specifiers as in GNU mode. > > A reproducible example of the problem: > > $ cat format.c > __attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char > *__format, ...); > __attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char > *__format, ...); > > void function(void) { > long long unsigned x = 42; > othername("%llu\n", x); > printf("%llu\n", x); > } > $ x86_64-w64-mingw32-gcc -c -Wformat format.c > format.c: In function 'function': > format.c:7:15: warning: unknown conversion type character 'l' in format > [-Wformat=] > 7 | printf("%llu\n", x); > | ^ > format.c:7:12: warning: too many arguments for format > [-Wformat-extra-args] > 7 | printf("%llu\n", x); > |^~~~ > > Note how both functions, printf and othername, are declare with > identical gnu_printf format attributes - GCC does take this into > account for "othername" and doesn't produce a warning, but GCC > seems to disregard the attribute in the printf declaration and > behave as if it was declared as ms_printf. > > If the printf function declaration is changed into a static inline > function, the actual attribute used is honored though. > > gcc/c-family/ChangeLog: > > PR c/95130 > * c-format.cc: skip default format for printf symbol if > explicitly declared by prototype. > > Signed-off-by: Tomas Kalibera > Signed-off-by: Jonathan Yong <10wa...@gmail.com> Great, thanks a lot for finishing and adding this, Tomas
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #20 from Tomas Kalibera --- (In reply to Julian Waters from comment #19) > (In reply to Tomas Kalibera from comment #17) > > (In reply to Tomas Kalibera from comment #16) > > > (In reply to Julian Waters from comment #15) > > > > It seems like the patch also doesn't fix the strftime case too, > > > > strangely > > > > enough. gcc with that patch applied still causes a compilation failure > > > > in > > > > the Windows JDK when encountering strftime with the %T specifier > > > > > > > > > I don't easily see why the patch doesn't help with %T in strftime. In > > > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so > > > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format > > > attribute is present. > > > > The older version of the patch I use with gcc 12 doesn't seem to be helping > > with %T, but the newer one (patch_master.diff) helps with %T on the current > > gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with > > MinGW-W64 11.0.1. > > If I may ask, could I have the link to patch_master.diff? It is one of the attachments of this report, https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778 This patch has not been reviewed. I am not an expert on GCC internals and I cannot guarantee that adding meta-data this way to the AST is safe. So please use with care.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #17 from Tomas Kalibera --- (In reply to Tomas Kalibera from comment #16) > (In reply to Julian Waters from comment #15) > > It seems like the patch also doesn't fix the strftime case too, strangely > > enough. gcc with that patch applied still causes a compilation failure in > > the Windows JDK when encountering strftime with the %T specifier > > > I don't easily see why the patch doesn't help with %T in strftime. In > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format > attribute is present. The older version of the patch I use with gcc 12 doesn't seem to be helping with %T, but the newer one (patch_master.diff) helps with %T on the current gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with MinGW-W64 11.0.1.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #16 from Tomas Kalibera --- (In reply to Julian Waters from comment #15) > It seems like the patch also doesn't fix the strftime case too, strangely > enough. gcc with that patch applied still causes a compilation failure in > the Windows JDK when encountering strftime with the %T specifier Given that this bug hasn't attracted enough attention to get fixed, perhaps you could try reporting this as a wish for improvement of the ms_strftime format (msformat-c.c, ms_time_char_table): probably it should support %T. I don't easily see why the patch doesn't help with %T in strftime. In MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format attribute is present.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #13 from Tomas Kalibera --- Another instance of this problem is %z (to print size_t). It is supported by UCRT, but the GCC's Microsoft format warns, because it wasn't supported with MSVCRT (seen with GCC 12.2).
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 Tomas Kalibera changed: What|Removed |Added Attachment #52007|0 |1 is obsolete|| --- Comment #12 from Tomas Kalibera --- Created attachment 53778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778=edit Draft patch to ignore built-in format attribute for a builtin, if there is another one This is a draft of an alternative patch, which addresses the concern that in theory the built in format attribute may not be the first one in the list of attributes of a built-in function. This patch puts attribute flags inside TREE_PURPOSE of the attribute, so that it can be checked later whether it is a built in attribute. I am not sure whether this is legal, but it should be easy to update it to store the flags somewhere else, if needed.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #11 from Tomas Kalibera --- (In reply to LIU Hao from comment #10) > (In reply to Tomas Kalibera from comment #7) > > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > > mailing list in May: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > > > The patches still apply to current 10,11,12 and trunk. Please see the email > > linked above for more information. > > > Thanks for the patch. Updated locally. I will test it against trunk as soon > as I get a little time. Thanks. Re Jeff's comment from the mailing list: > I guess we're going to depend on the builtin-format always appearing > first in the chain? While it's probably true in practice, I doubt we > really want to depend on that. > > Is there any sensible way to distinguish between the builtin format and > one that comes from the source? I didn't find any elegant way to find out whether a format attribute is a built-in attribute in check_function_format(). So unless I overlooked something (which is very much possible), it would make the patch more intrusive. handle_format_attribute() has that information in flags (ATTR_FLAG_BUILT_IN). Maybe handle_format_attribute() could add the flags (or only a boolean whether it is a builtin attribute) to the attribute tree, so that check_function_format() can access it, e.g. similarly to how no_sanitize does it. Would this be better? And if so, is there a recommended place in the format attribute tree where it should be added to?
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #9 from Tomas Kalibera --- (In reply to Martin Storsjö from comment #8) > (In reply to Tomas Kalibera from comment #7) > > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > > mailing list in May: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > > > The patches still apply to current 10,11,12 and trunk. Please see the email > > linked above for more information. > > Did you notice the review comment in July, > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/59.html? Ah, thanks, I missed it (as I wasn't on the to/cc).
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #7 from Tomas Kalibera --- I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches mailing list in May: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html The patches still apply to current 10,11,12 and trunk. Please see the email linked above for more information.
[Bug tree-optimization/105198] [9/10 Regression] Wrong code for C loop (GCC 12 -O2, GCC 11 -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198 --- Comment #11 from Tomas Kalibera --- Thanks for the very quick fix! I confirm that when R is built with the fixed version of GCC 12, the R testcase for MASS is fixed, it works with -O2.
[Bug middle-end/105198] New: Wrong code for C loop (GCC 12 -O2, GCC 11 -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198 Bug ID: 105198 Summary: Wrong code for C loop (GCC 12 -O2, GCC 11 -O3) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 52770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52770=edit Reproducible example to compile and execute (see comment in file) It seems that GCC produces wrong code for function next_set found in R package MASS (traced down by Brian Ripley): static void next_set(int *x, int n, int k) { int i, j, tmp; j = k - 1; tmp = x[j]++; while(j > 0 && x[j] >= n - (k - 1 -j)) tmp = ++x[--j]; for(i = j+1; i < k; i++) x[i] = ++tmp; } The attached standalone example reproduces the problem on a slightly modified and instrumented variant of the function, for one specific input, see comments in the code. Correct output (GCC 12 -O1, and can be seen from the C code): n == 5, k == 3, x == 0 1 4 tmp == 2, j == 1, x == 0 2 5 Incorrect but seen on x86_64/Linux (GCC 12 -O2, GCC 11 -O3): n == 5, k == 3, x == 0 1 4 tmp == 4, j == 2, x == 0 1 5 One can modify the example to get slightly simpler native code via writing to the array in "main" via volatile variables. It works with GCC 10 -O3.
[Bug target/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #28 from Tomas Kalibera --- I've also tested the patch with GCC 10.3 (with several backports from gcc10 branch plus some minor fixes, https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/plugins/gcc10/). I've built a cross-compiler and built R using it and ran the R regression testsuite (check-all), with -O2. No issues found. The same testsuite was previously triggering Bug 103274.
[Bug target/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #27 from Tomas Kalibera --- > > should do the job. Tomas, can you give it a try? > > Thanks, so far I tried it only on predict-22.c and it works (with a fixed > comma as below), enables the optimization. I will do more testing tomorrow. I've tested with gcc12 (6aa0859afaf28f4fb13121352225bc5877e02a44) gcc11 (a03aae8d9f5dbfe3ca3dbfe7eadc6bbe6fbbe1bc) gcc10 (48e0da239f65b7cfa0e6f51f266c2e04f5ad9bbd) I confirm that with the patch applied: * the original bug report about invalid note about '-freorder-blocks-and-partition' is fixed * the optimization is applied by default at -O3, -O2 and can be enabled at -O1 via -f * the optimization can be disabled via -fno- and via pragma * -Q --help=optimizers issue for the option goes away, so "fixed" (though as I understand from Martin other optimizations still disabled by target will incorrectly appear as enabled) So with this patch applied, I am happy for this bug report to be closed. Thanks to both of you.
[Bug target/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #26 from Tomas Kalibera --- > should do the job. Tomas, can you give it a try? Thanks, so far I tried it only on predict-22.c and it works (with a fixed comma as below), enables the optimization. I will do more testing tomorrow. diff --git a/gcc/coretypes.h b/gcc/coretypes.h index 0769a78a87c..f3559373433 100644 --- a/gcc/coretypes.h +++ b/gcc/coretypes.h @@ -228,15 +228,17 @@ enum stack_protector { SPCT_FLAG_EXPLICIT = 4 }; -/* Types of unwind/exception handling info that can be generated. */ +/* Types of unwind/exception handling info that can be generated. + Note that a UI_TARGET (or larger) setting is considered to be + incompatible with -freorder-blocks-and-partition. */ enum unwind_info_type { UI_NONE, UI_SJLJ, UI_DWARF2, - UI_TARGET, - UI_SEH + UI_SEH, + UI_TARGET }; /* Callgraph node profile representation. */
[Bug driver/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #24 from Tomas Kalibera --- FWIW, predict-22.c from GCC test suite is an example for which reorder-blocks-and-partition has an effect (creates foo.cold) in GCC trunk, up to but excluding https://gcc.gnu.org/g:a187edd2b437fc9571d57f771a624963fcce08f8 The repro example I used for Bug 103274 (a.c) is not good for testing this problem in the trunk, because the optimization is not applied on that specific example already since https://gcc.gnu.org/g:cd5ae148c47c6dee05adb19acd6a523f7187be7f
[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292 Tomas Kalibera changed: What|Removed |Added CC||tomas.kalibera at gmail dot com --- Comment #6 from Tomas Kalibera --- For reference, Bug 95130 is an instance of the same underlying issue (yet where the formats are different), with a proposed patch.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #5 from Tomas Kalibera --- (In reply to jos...@codesourcery.com from comment #1) > See bug 92292. The extra attribute isn't ignored, it simply means the > function has multiple format attributes, which is valid, but should > probably be special-cased for this case of built-in functions. I've added a draft of a patch to address the issue in the suggested way. I've tested it in gcc 10.3.0 on the example from comment 2 (also attached). With the patch applied, only line (2) gets a warning, as it should. When deciding whether to emit a format warning for a function with multiple format attributes, it skips the first format in case it is a builtin known to have a format added by gcc. Please let me know if you have any advice how to improve (thanks to Martin Liska for helping me with identifying the builtins), or indeed feel free to adjust and add your way. Fixing this would help the R community or anyone else who uses GCC with UCRT. Thanks, Tomas
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #4 from Tomas Kalibera --- Created attachment 52008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52008=edit Example from comment 2
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #3 from Tomas Kalibera --- Created attachment 52007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52007=edit Patch to ignore first format for builtins that have more than one This patch for 10.3.0 instructs gcc to ignore the first format attribute for functions that have multiple format attributes and are builtins with a format attribute added by GCC.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #14 from Tomas Kalibera --- Created attachment 51962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51962=edit example for comment 1 and 13
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #13 from Tomas Kalibera --- (In reply to Martin Liška from comment #12) > > So, still, the reorder-stacks-and-partition optimization is not dropped by > > target (though I am not claiming they should be dropped, I don't know, > > that's only what I learned from your response to my original report). > > I see. Can you see the following note: > > "%<-freorder-blocks-and-partition%> does not work " > "with exceptions on this architecture"); > > w/ -freorder-blocks-and-partition option used? Not with x86_64-w64-mingw32-gcc -c -O3 -freorder-blocks-and-partition a.c but I do (the variant for C) with the original example for this bug report x86_64-w64-mingw32-gcc -c -O3 -freorder-blocks-and-partition uwi.c -Wall uwi.c:3:9: note: '-freorder-blocks-and-partition' does not support unwind info on this architecture 3 | #pragma GCC optimize ("unroll-loops") | ^~~ uwi.c:5:1: note: '-freorder-blocks-and-partition' does not support unwind info on this architecture 5 | int main(int argc, char **argv) { | ^~~ this original example (uwi.c) has an GCC optimize pragma: #include #pragma GCC optimize ("unroll-loops") int main(int argc, char **argv) { printf("Hello 1\n"); printf("Hello 2\n"); printf("Hello 3\n"); return 0; } For C++ I get the note with "does not work with exceptions on this architecture"
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #10 from Tomas Kalibera --- (In reply to Tomas Kalibera from comment #7) > (In reply to Martin Liška from comment #5) > > > However, still talking about the current master only, I see a difference > > > with -O3, when I try on the repro example from Bug 103274 and -O3: > > > > > > x86_64-w64-mingw32-gcc -c -S -O3 -fno-reorder-blocks-and-partition a.c -o > > > nropt.s > > > > > > x86_64-w64-mingw32-gcc -c -S -O3 -freorder-blocks-and-partition a.c -o > > > ropt.s > > > x86_64-w64-mingw32-gcc -c -S -O3 a.c -o noopt.s > > > > > > All of these assembler files are different (and from my non-expert > > > reading, > > > noopt.s uses the optimization and does have the invalid unwind information > > > as reported in Bug 103274). Is the optimization correctly dropped also > > > with > > > -O3 only? > > > > Hmmm, I've just tested the same with the locally built cross-compiler: > > ~/Programming/gcc/configure --enable-languages=c,c++ > > --prefix=/home/marxin/bin/gcc --disable-multilib --enable-host-shared > > --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap > > --target=x86_64-w64-mingw32 > > > > and it works fine, all 3 assembly files are identical. > It tried on the current GCC trunk as now (747380f47da0da6c11fd5262ac428bb53433ea19). ropt.s is still the same as noopt.s. The unwinding information is correct now, because Bug 103274 has been fixed in the meantime. However, indeed, the reordering optimization is applied. nropt.s has correct unwinding information without the reordering. So, still, the reorder-stacks-and-partition optimization is not dropped by target (though I am not claiming they should be dropped, I don't know, that's only what I learned from your response to my original report). For these results I've only changed the git version in the dockerfile.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #9 from Tomas Kalibera --- Created attachment 51959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51959=edit Dockerfile for comment 7 Dockerfile to reproduce behavior in comment 7. To be placed in a fresh directory with a.c. The output files will appear in /build/out in the container. The Dockerfile is based on an earlier copy (reproducing something else) I got from Martin Storsjo.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #8 from Tomas Kalibera --- Created attachment 51958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51958=edit Example for comment 7. Example for Dockerfile for comment 7. To be placed in a new directory with that Dockerfile.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #7 from Tomas Kalibera --- (In reply to Martin Liška from comment #5) > > However, still talking about the current master only, I see a difference > > with -O3, when I try on the repro example from Bug 103274 and -O3: > > > > x86_64-w64-mingw32-gcc -c -S -O3 -fno-reorder-blocks-and-partition a.c -o > > nropt.s > > > > x86_64-w64-mingw32-gcc -c -S -O3 -freorder-blocks-and-partition a.c -o > > ropt.s > > x86_64-w64-mingw32-gcc -c -S -O3 a.c -o noopt.s > > > > All of these assembler files are different (and from my non-expert reading, > > noopt.s uses the optimization and does have the invalid unwind information > > as reported in Bug 103274). Is the optimization correctly dropped also with > > -O3 only? > > Hmmm, I've just tested the same with the locally built cross-compiler: > ~/Programming/gcc/configure --enable-languages=c,c++ > --prefix=/home/marxin/bin/gcc --disable-multilib --enable-host-shared > --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap > --target=x86_64-w64-mingw32 > > and it works fine, all 3 assembly files are identical. I am uploading a Dockerfile and my copy of the example which reproduces my observation, but please note, it was for 5e5f880d0452ef2cffb94f4a686d56833c9f4215. nropt.s has (correct unwind info, no reordering) .L5: callmyerrorcall nop .seh_endproc but ropt.s is same as noopt.s (incorrect unwind info, reordering) .L5: callmyerrorcall .seh_endproc [...] dummy.cold: .L19: So, from my reading the optimization was applied at -O3, it hence wasn't dropped by target.
[Bug target/103274] [10/11/12 regression] remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #12 from Tomas Kalibera --- I've tested with GCC 10.3 with R. R can be built and passes its tests (without the patch, it crashes). Also, I've checked the generated assembly with an awk script looking for a call instruction immediately followed by .seh_endproc. I didn't find any (while there were many without the patch, based on one the attached example was created). Thanks for the fix.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #4 from Tomas Kalibera --- (In reply to Martin Liška from comment #3) > Let's speak about the current master: > > > With "12.0" (5e5f880d0452ef2cffb94f4a686d56833c9f4215), the note is not > > emitted with -fno-reorder-blocks-and-partition, however, the other problem > > remains. The note is still not emitted when the optimization is enabled > > implicitly via -O2. > > I see: > > /xgcc -B. /home/marxin/Programming/testcases/pr103465.c -c -O2 > -freorder-blocks-and-partition > /home/marxin/Programming/testcases/pr103465.c:2:9: note: > ‘-freorder-blocks-and-partition’ does not support unwind info on this > architecture > 2 | #pragma GCC optimize ("unroll-loops") > | ^~~ > /home/marxin/Programming/testcases/pr103465.c:4:1: note: > ‘-freorder-blocks-and-partition’ does not support unwind info on this > architecture > 4 | int main(int argc, char **argv) { > | ^~~ > > which seems correct to me. With only -O2 there's no note emitted and the > flags are properly dropped (same in -freorder-blocks-and-partition): > > $ cat -n gcc/opts.c > ... > 1133if (opts->x_flag_unwind_tables > 1134&& !targetm_common.unwind_tables_default > 1135&& opts->x_flag_reorder_blocks_and_partition > 1136&& (ui_except == UI_SJLJ || ui_except >= UI_TARGET)) > 1137 { > 1138if (opts_set->x_flag_reorder_blocks_and_partition) > 1139 inform (loc, > 1140 "%<-freorder-blocks-and-partition%> does not support > " > 1141 "unwind info on this architecture"); > 1142opts->x_flag_reorder_blocks_and_partition = 0; > 1143opts->x_flag_reorder_blocks = 1; > 1144 } > > So what's wrong with that, please? Thanks for looking into this. I didn't realize an optimization can be dropped silently - I only checked x86_64-w64-mingw32-gcc -O2 -Q --help=optimizers and that said "enabled". Sorry for that. However, still talking about the current master only, I see a difference with -O3, when I try on the repro example from Bug 103274 and -O3: x86_64-w64-mingw32-gcc -c -S -O3 -fno-reorder-blocks-and-partition a.c -o nropt.s x86_64-w64-mingw32-gcc -c -S -O3 -freorder-blocks-and-partition a.c -o ropt.s x86_64-w64-mingw32-gcc -c -S -O3 a.c -o noopt.s All of these assembler files are different (and from my non-expert reading, noopt.s uses the optimization and does have the invalid unwind information as reported in Bug 103274). Is the optimization correctly dropped also with -O3 only?
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #2 from Tomas Kalibera --- (In reply to Martin Liška from comment #1) > I can take a look, what's the target please? Thanks, x86_64-w64-mingw32 (with UCRT as the CRT, but that probably does not matter).
[Bug rtl-optimization/103465] New: Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 Bug ID: 103465 Summary: Invalid note with -fno-reorder-blocks-and-partition Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- With GCC 10.3.0 and 11.2.0, compiling this example with -O2 -fno-reorder-blocks-and-partition for Windows emits a note uwi.c:3:9: note: '-freorder-blocks-and-partition' does not support unwind info on this architecture 3 | #pragma GCC optimize ("unroll-loops") | ^~~ uwi.c:5:1: note: '-freorder-blocks-and-partition' does not support unwind info on this architecture 5 | int main(int argc, char **argv) { | ^~~ (even though asking GCC to _not_ perform that optimization) #include #pragma GCC optimize ("unroll-loops") int main(int argc, char **argv) { printf("Hello 1\n"); printf("Hello 2\n"); printf("Hello 3\n"); return 0; } This note is emitted twice for this example and many times for bigger examples, also for other GCC optimization options pragmas. The outputs can become large (e.g. building R CRAN packages increased log file from about 1G to 12G). The note is also emitted when -freorder-blocks-and-partition is given (explicitly), which is probably intended, but it is not emitted when the optimization is used implicitly as part of -O2. The same problem exists with g++, except the wording of the note is "does not work with exceptions on this architecture" With "12.0" (5e5f880d0452ef2cffb94f4a686d56833c9f4215), the note is not emitted with -fno-reorder-blocks-and-partition, however, the other problem remains. The note is still not emitted when the optimization is enabled implicitly via -O2. Related to Bug 103274; the reason for using -fno-reorder-blocks-and-partition was to get valid unwind information for long jumps to work.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 Tomas Kalibera changed: What|Removed |Added CC||tomas.kalibera at gmail dot com --- Comment #2 from Tomas Kalibera --- My apologies if this is obvious, but please let me note this issue means that one cannot print(f) a 64-bit integer without a compile-time warning with UCRT on Windows. It would be a great help if this could somehow be fixed. In the example below, lines (1) and (2) work without a warning with MSVCRT. But, all three issue a warning with UCRT. #include #include int main(int argc, char **argv) { long long unsigned x = 112; printf("Hello %"PRIu64"\n", x); // 1 printf("Hello %I64u\n", x); // 2 printf("Hello %llu\n", x); // 3 return 0; }
[Bug target/103274] Remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #2 from Tomas Kalibera --- (In reply to Eric Botcazou from comment #1) > > -freorder-blocks-and-partition sometimes causes a function to end right in a > > (non-returning) call, but SEH needs at least one more instruction on x86_64. > > Seen in GCC 10.3, 11.2 and git master. Maybe [1] did not cover all the > > cases? > > SEH means "Structured Exception Handling" but there is no exception handling > in this chunk of program since it's written in C and compiled without > -fexceptions, so I'm not quite sure what you're expecting here. This also causes crashes with setjmp/longjmp only (no C++ exceptions, no explicit use of C-exceptions in the C code). R triggers unwinding via long jumps (explicitly calling longjmp in C, to implement error handling in R), of the frames between setjmp and longjmp. The unwinding sometimes crashes due to the problem reported, because it does not find the unwinding information for some frames. Windows looks for a function matching a given instruction pointer, which happens to be right after the call causing the long jump. However, when the function end is marked right after such a call (such as in the example), the instruction pointer is regarded past the function end, and hence it is not matched to the function it should be. We were using workarounds to disable SEH during unwinding, via redefining setjmp to __intrinsic_setjmpex((x), NULL), so using the NULL frame argument instead of the default __builtin_frame_address(0).
[Bug target/103274] New: Remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 Bug ID: 103274 Summary: Remaining -freorder-blocks-and-partition/ glitch with Windows SEH Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 51809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51809=edit When compiled with -O3, dummy ends in a call (invalid unwind information). -freorder-blocks-and-partition sometimes causes a function to end right in a (non-returning) call, but SEH needs at least one more instruction on x86_64. Seen in GCC 10.3, 11.2 and git master. Maybe [1] did not cover all the cases? The attached compile-only example compiled with -O3 reproduces the problem. It is extracted from R, where this problem causes crashes (and where in wine, one gets an error "virtual_unwind exception data not found" and further instrumentation reveals it is because the address following the call instruction is already at the function boundary). The problem can be seen directly from the assembly: gcc -O3 -c -S ../main/a.c -o - produces dummy: [...] .L5: callmyerrorcall .seh_endproc [...] dummy.cold: For reference, R is affected by this and has been disabling SEH as a workaround, but it has been reported that the workaround causes in turns crashes with CFG. This report is with substantial help from Martin Storsjo. === [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=15278fb2877184c75a6ee3a6def09efbb191968b;hp=9d3b9a3e70e634c7c48bb12bb35ec8219024f98b [2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386.c;h=1bca5a7eea6ab9accbbf6953f79e8a4da61859e2;hb=4212a6a3e44f870412d9025eeb323fd4f50a61da#l29076 [3] https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86AvoidTrailingCall.cpp [4] https://bugs.r-project.org/show_bug.cgi?id=18180
[Bug driver/101238] Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238 --- Comment #2 from Tomas Kalibera --- 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-patc...@gcc.gnu.org, or is this information here now sufficient?
[Bug driver/101238] New: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238 Bug ID: 101238 Summary: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 51070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51070=edit Use -D__USE_MINGW_ACCESS when compiling the driver. Summary: one needs to add CXXFLAGS+=-D__USE_MINGW_ACCESS to config/mh-mingw so that the driver finds executables on Windows. This is already fixed in GCC 11, but not in GCC 10. More details: GCC 10 driver is compiled with g++ without-D__USE_MINGW_ACCESS on MinGW. That option is only added to CFLAGS, but not CXXFLAGS. Consequently, the driver will not find executables such as cc1, because access(,X_OK) will always return an error on Windows, as access() on Windows does not check for executability anymore. With __USE_MINGW_ACCESS, MinGW will use its own implementation of access() which for X_OK behaves the same as R_OK. I've tested the (trivial) attached patch and it resolved the issue on my system as expected.