[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572 --- Comment #12 from Martin Storsjö --- (In reply to Jonathan Wakely from comment #11) > CC Martin Storsjo to see if changing Clang would be possible, or if he has a > better idea for the preprocessor check suggested in comment 9. > > It might

[Bug target/114984] asm() renaming of symbols inconsistent with dllimport

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984 --- Comment #2 from Martin Storsjö --- To clarify the concern for changing whether "__imp_" is implied for asm("") on dllimported symbols or not; on all other mingw architectures than i386, there's no extra symbol prefix, so the current

[Bug target/114984] asm() renaming of symbols inconsistent with dllimport

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984 --- Comment #1 from Martin Storsjö --- The suggestion in https://sourceware.org/pipermail/cygwin/2007-February/154845.html was that for dllimported symbols, the string passed in asm("") should be entirely literal, i.e. no implicit "__imp_"

[Bug target/114984] New: asm() renaming of symbols inconsistent with dllimport

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984 Bug ID: 114984 Summary: asm() renaming of symbols inconsistent with dllimport Product: gcc Version: 13.1.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 #25 from Martin Storsjö --- (In reply to Andrew Pinski from comment #23) > Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be > fixed to incldue that. > >

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #8 from Martin Storsjö --- (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 target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #8 from Martin Storsjö --- (In reply to Brecht Sanders from comment #7) > So I guess the question that remains is: Where is -D__USE_MINGW_ACCES > missing in the configuration of GCC 12? > > It would seem to me the answer lies in

[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 Martin Storsjö changed: What|Removed |Added CC||martin at martin dot st --- Comment

[Bug c/103956] New: [10 Regression] -Wstringop-overflow= false positive on -O3 for writes to array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103956 Bug ID: 103956 Summary: [10 Regression] -Wstringop-overflow= false positive on -O3 for writes to array Product: gcc Version: 10.0 Status: UNCONFIRMED

[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 #11 from Martin Storsjö --- (In reply to Eric Botcazou from comment #10) > Thanks for reporting the problem. Thanks for the fix! I can confirm that the version of the patch backported on the gcc-10 branch fixes the testcase at

[Bug target/103274] Remaining -freorder-blocks-and-partition/ glitch with Windows SEH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #4 from Martin Storsjö --- Also for additional context; with GCC 9.x, this testcase had the needed nop instruction between "call" and ".seh_endproc". In GCC 10.x (regressed in

[Bug target/103274] Remaining -freorder-blocks-and-partition/ glitch with Windows SEH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 Martin Storsjö changed: What|Removed |Added CC||martin at martin dot st --- Comment