https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #7 from Martin Storsjö ---
(In reply to Jonathan Wakely from comment #6)
> I have zero interest in learning any native APIs and my employer isn't
> interested in Windows support, so if I can't easily get it working with code
> simila
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #5 from Martin Storsjö ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Martin Storsjö from comment #2)
> > > I also don't want to have to use Windows APIs here.
> >
> > How does that work within libstdc++ in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #2 from Martin Storsjö ---
> I also don't want to have to use Windows APIs here.
How does that work within libstdc++ in general, with std::filesystem using
wchar_t as std::filesystem::path::value_type? Are all paths converted to nar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
Bug ID: 118003
Summary: std::filesystem::remove_all() hangs on Windows on
directories containing a deep tree with long paths
Product: gcc
Version: 14.2.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116159
--- Comment #6 from Martin Storsjö ---
(In reply to Jonathan Wakely from comment #4)
> But is that even going to work on this target when the actual symbol has __Z
> ?
>
> T __ZNSt8ios_base4InitC1Ev
>
> (why doesn't the alias give an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116159
--- Comment #2 from Martin Storsjö ---
(In reply to Jakub Jelinek from comment #1)
> Is mingw really using GNU symbol versioning? That ought to be an ELF only
> thing and this is guarded with #ifdef _GLIBCXX_SYMVER_GNU.
It's not actually using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #14 from Martin Storsjö ---
(In reply to GCC Commits from comment #13)
> The master branch has been updated by Jonathan Wakely :
>
> https://gcc.gnu.org/g:6af8d8e618ed27dae3432c96484de4360bd893ab
>
> commit r15-1342-g6af8d8e618ed27
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
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 behaviou
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_" prepe
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
Com
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.
>
> https://learn.microsoft.com/en-us/cpp/c-runtime-libra
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:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.
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 cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
Martin Storsjö changed:
What|Removed |Added
CC||martin at martin dot st
--- Comment #6
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
Severity:
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 least
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
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=095f78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274
Martin Storsjö changed:
What|Removed |Added
CC||martin at martin dot st
--- Comment #3
19 matches
Mail list logo
