[Bug libgcc/113337] Uncaught rethrown exceptions don't invoke std::terminate if SEH-based unwinding is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113337 jyong at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||jyong at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #4 from jyong at gcc dot gnu.org --- Marking as resolved.
[Bug libgcc/113850] condition variables timed wait does a lot of spurious wakeups on Win32 threading implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113850 jyong at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||jyong at gcc dot gnu.org --- Comment #6 from jyong at gcc dot gnu.org --- Pushed the patch to master branch and 13.x.
[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192 jyong at gcc dot gnu.org changed: What|Removed |Added CC||jyong at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from jyong at gcc dot gnu.org --- Changed to use __mingw_*printf.
[Bug libgcc/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 jyong at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||jyong at gcc dot gnu.org --- Comment #15 from jyong at gcc dot gnu.org --- Pushed the patch as dcf8fe1eeab668a4d24bcc4baa3ad185dbf1b5e0, thanks David.
[Bug bootstrap/55886] gcc/configure.ac problems lead to GCC 4.7.2 not building for x86_64-pc-mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55886 jyong at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX CC||jyong at gcc dot gnu.org --- Comment #3 from jyong at gcc dot gnu.org --- x86_64-w64-mingw32 has been the defacto triplet for targeting Windows 64bit Win32API for awhile now. Closing this ticket for now.
[Bug debug/100383] cfi sections directive detection fails with binutils 2.36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100383 jyong at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from jyong at gcc dot gnu.org --- I can confirm it was detected as no with binutils 2.36, and back to yes after the grep change.
[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 --- Comment #6 from jyong at gcc dot gnu.org --- I can confirm the symbols are correctly generated regardless of -fno-leading-underscore or not, the internal symbols are no longer emitted as undefined after assembly. GCC can also finish building the target libraries without any problems for 32bit MinGW.
[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 --- Comment #5 from jyong at gcc dot gnu.org --- I'll test out the patch soon.
[Bug c/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 --- Comment #2 from jyong at gcc dot gnu.org --- No, its the internal compiler symbols like LC5 and _LC6 generated by GCC ignoring the underscore prefix setting for the target, causing GAS to emit them as external undefined symbols. LD fails to find the symbols to satisfy them upon linking. 32bit Windows PE symbols should come with an underscore prefix, this does not apply to 64bit Windows code.
[Bug c/99872] New: [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 Bug ID: 99872 Summary: [11 Regression] optimizations sometimes lead to missing asm prefixes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jyong at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-w64-mingw32 Build: x86_64-pc-linux-gnu Created attachment 50497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50497=edit lib32_libmingwex_a-pow.c test case Compiling with the following command line: x86_64-w64-mingw32-gcc -O2 -c lib32_libmingwex_a-pow.c -std=gnu99 -m32 Causes an undefined symbols with the wrong asm prefixes to be emitted: T ___attribute__pow 0010 B ___attribute__pow_d 0008 B ___attribute__pow_x B ___attribute__pow_y b .bss d .data U ___fpclassify U _internal_modf U LC5 U _LC6 r .rdata r .rdata$zzz U ___signbit t .text Adding -fno-leading-underscore makes the symbols resolved, 32bit Windows code is supposed to have a leading underscore.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #60 from jyong at gcc dot gnu.org --- Thanks all for debugging and finding a solution.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #56 from jyong at gcc dot gnu.org --- OK, I've tested the patch from attachment 50461, seems to work fine: gcc uses dwarf 4 by default if it does find a broken linker, but allows the user to specify -gdwarf-5 if they want, resulting in a broken executable. If the linker was found to be working at build time, dwarf-5 would be default. I prefer the non-noisy patch because gcc doesn't actually detect the linker bug at runtime, just silently doing what it thinks is best, which may not be accurate if the user upgrades or downgrades binutils without a rebuild.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #52 from jyong at gcc dot gnu.org --- Oops I need retest with optimizations enabled to see the debug sections emitted. On the other hand, the new adjusted patch detects the binutils bug fine, tested with new and old binutils.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 jyong at gcc dot gnu.org changed: What|Removed |Added Attachment #50459|0 |1 is obsolete|| --- Comment #51 from jyong at gcc dot gnu.org --- Created attachment 50460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50460=edit Slightly adjusted patch to fix errors Adjust the patch to deal with xyes and silent result issues. Testing with older binutils worked, -gdwarf-5 ignored, not sure if intentional.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #50 from jyong at gcc dot gnu.org --- I'll try testing it out over the next few days, thanks for the patch.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #48 from jyong at gcc dot gnu.org --- Now that's an interesting trick I never thought of. There's LLVM based mingw, but I have never used nor do I know if it is relevant here. Gold is ELF only as far as I know, so it would never be used. That should leave only BFD ld.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #46 from jyong at gcc dot gnu.org --- Is there a machine parsable output from objdump? I'm not sure if using gawk would be OK. Such a test also won't work in build != host conditions. I'm considering just having a notice in the gcc-11 release note to the particular binutils commit/patch, so that anyone rolling their own toolchain would be aware of it and try to apply the patch on binutils, since no released version has the patch yet.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #43 from jyong at gcc dot gnu.org ---
Is it as simple as running the following?
${target}-objdump -j .debug_loclists -h a.exe | grep -q 0001
A return code 0 means potentially broken linker script is used.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #40 from jyong at gcc dot gnu.org --- Personally I'm fine with gcc configure warning of a potentially broken binutils dwarf5 handing when targeting mingw/cygwin with binutils 2.35.1 or earlier. How do you even parse binutils versions? Of course, all bets are off if build!=host.
[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 jyong at gcc dot gnu.org changed: What|Removed |Added CC||ktietz70 at googlemail dot com, ||lh_mouse at 126 dot com --- Comment #9 from jyong at gcc dot gnu.org --- Adding more Windows devs.
