On 2023-02-11 06:32, Jonathan Yong wrote:
On 2/6/23 06:40, Jonathan Yong wrote:
On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote:
hello again!
the final version of the path for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
successfully bootstraped for x86_64-mingw32 and x86_64
hello,
could someone look at patch attached please?
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610147.html
hello,
could someone look at the patch attached please?
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610392.html
hello Jakub,
The above looks way too complicated for what it does.
If all you want to change mp_limb* to be long long for mingw 64-bit,
then just do:
done.
Why?
could you explain which of the nine lines are you talking about?
As for the rest, it would help if you could list the exact
updated path.
only the comment has been corrected.
diff --git a/libquadmath/printf/gmp-impl.h b/libquadmath/printf/gmp-impl.h
index 94d88efc57f..af0719321dc 100644
--- a/libquadmath/printf/gmp-impl.h
+++ b/libquadmath/printf/gmp-impl.h
@@ -33,15 +33,30 @@ MA 02111-1307, USA. */
#define MAX(h,i) (
hello,
I have fixed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204
tested on i686-mingw-w64, x86_64-mingw-w64, and for i686 and x86_64
linux.
could anyone check and apply please?
best!
diff --git a/libquadmath/printf/gmp-impl.h b/libq
hello again!
the final version of the path for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
successfully bootstraped for x86_64-mingw32 and x86_64-linux.
could anyone apply it please?
best!
diff --git a/libiberty/lrealpath.c b/libiberty/lrealpath.c
index 3c7053b0b70..a1ad074d00e 100
updated patch in attachments.
diff --git a/libiberty/lrealpath.c b/libiberty/lrealpath.c
index 3c7053b0b70..8858619e854 100644
--- a/libiberty/lrealpath.c
+++ b/libiberty/lrealpath.c
@@ -68,8 +68,138 @@ extern char *canonicalize_file_name (const char *);
/* cygwin has realpath, so it won't get
hello,
I just finished with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
could anyone review and apply the attached patch please?
GCC master was succesfully bootstrapped as x86_64-w64-mingw32.
best!
diff --git a/libiberty/lrealpath.c b/libiberty/lrealpath.c
index 3c7053b0b70..885861
On 2022-12-24 15:57, i.nix...@autistici.org wrote:
On 2022-12-24 15:42, i.nix...@autistici.org wrote:
fixed and tested.
Jonathan Yong, could you please apply the attached patch too?
kings regards!
oh no...
please wait.
fixed now.
bootstrapped successfully!
Jonathan Yong, could you pl
On 2022-12-24 15:42, i.nix...@autistici.org wrote:
fixed and tested.
Jonathan Yong, could you please apply the attached patch too?
kings regards!
oh no...
please wait.
On 2022-12-24 13:50, i.nix...@autistici.org wrote:
On 2022-12-24 05:58, NightStrike wrote:
I think this might have broken fortran. I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:
In file included from /tmp/rtmingw/mingw/include/windows.h:71,
fro
On 2022-12-24 05:58, NightStrike wrote:
I think this might have broken fortran. I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:
In file included from /tmp/rtmingw/mingw/include/windows.h:71,
from ../libgcc/gthr-default.h:606,
fro
On 2022-12-24 05:58, NightStrike wrote:
I think this might have broken fortran. I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:
In file included from /tmp/rtmingw/mingw/include/windows.h:71,
from ../libgcc/gthr-default.h:606,
fro
On 2022-12-23 23:59, Jonathan Yong wrote:
Done, pushed to master branch. Thanks Eric.
thank you Jonathan!
On 2022-12-22 12:21, Jonathan Yong wrote:
hello,
On 12/16/22 19:20, Eric Botcazou wrote:
The libgcc parts look reasonable to me, but I can't approve them.
Maybe Jonathan Yong can approve those parts as mingw-w64 target
maintainer, or maybe a libgcc approver can do so.
OK.
The libstdc++ par
On 2022-11-02 21:27, Eric Botcazou wrote:
Great! Did you check that C++ threads are enabled in your build? If
they
are, you must be able to run the attached C++ test; if they are not
(because
the MinGW64 build is configured for older versions of Windows), you
need to
configure the compiler
hi Eric, Jonathan,
I was able to successfully build gcc-trunk using the provided patch.
moreover, I was able to successfully build all of the packages used in
the toolchain!
(gmp, mpfr, mpc, isl, libgnurx, bzip2, termcap, libffi, expat, ncurses,
readline, gdbm, tcl, tk, openssl, xz-utils, sql
On 2022-10-31 09:18, Eric Botcazou wrote:
hello Eric!
This also changes libstdc++ to pass -D_WIN32_WINNT=0x0600 but only when
the
switch --enable-libstdcxx-threads is passed, which means that C++11
threads
are still disabled by default *unless* MinGW-W64 itself is configured
for
Windows Vista
On 2022-10-31 09:18, Eric Botcazou wrote:
Hi Eric!
thank you very much for the job!
I will try to build our (MinGW-Builds project) builds using this patch
and will report back.
@Jonathan
what the next steps to be taken to accept this patch?
best!
I have attached a revised version of th
On 2022-10-24 08:15, Eric Botcazou wrote:
could you please refresh/recheck your patch for the current gcc master
and solve the objections noted in the thread? is it possible?
Hi,
I can do the former, but not the latter as my development setup (mostly
testing) on Windows has nearly vanished
On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:
How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
My proposal was to reimplement (and extend) the native thread model
(win32)
instead of adding a new one, the advantage being
On 2022-10-21 12:19, LIU Hao wrote:
在 2022/10/21 19:54, i.nix...@autistici.org 写道:
Jacek Caban, who is also a mingw-w64 developer, expressed the same
idea a few days ago.
While integrating mcfgthread into gcc is practically possible, my
concerns are:
* GCC never provides a threading li
On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:
How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
My proposal was to reimplement (and extend) the native thread model
(win32)
instead of adding a new one, the advantage being
On 2022-10-21 11:36, LIU Hao wrote:
在 2022/10/21 18:09, i.nix...@autistici.org 写道:
On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote:
How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
It would be good if we can accept one o
On 2022-10-21 10:48, Jonathan Wakely wrote:
On Fri, 21 Oct 2022 at 11:10, i.nixman--- via Libstdc++
wrote:
On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote:
> How does this compare with Eric B's proposal at
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
>
> It woul
On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote:
How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
It would be good if we can accept one of them for GCC 13, but I don't
know Windows well enough to determine which is better.
27 matches
Mail list logo
