[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

[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 > >

[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 >

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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|

[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: > > > >

[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: > > > >

[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

[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:

[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,

[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

[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.

[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

[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 ---

[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 >

[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

[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, > >

[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

[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.

[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: > > > >

[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

[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

[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

[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 ---

[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.

[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

[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

[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: