在 2023/6/13 14:29, Pali Rohár 写道:
Of course, just I'm not sure where to put the new paragraph. At the
beginning? Or after the text? What do you think?
Maybe just in front of 'This option is available for MinGW targets.' Also you
may reword it as you like.
--
Best regards,
LIU Hao
OpenPGP
在 2023/6/12 07:08, Jonathan Yong 写道:
+preprocessor is done. MinGW import library @code{msvcrt} is just a
+symlink (or file copy) to the other MinGW CRT import library
I suggest a change to this line:
symlink to (or a copy of) another MinGW CRT import library
Also, as discussed earlier, l
--
Best regards,
LIU Hao
From a4d5e161fbaa5b9994077ffb474e2b55c6c3b3cb Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Tue, 10 May 2022 13:19:07 +0800
Subject: [PATCH] gcc: Remove size limit of PCH for *-*-mingw32 hosts
PCHs can now be relocated, so the size limit makes no sense any more.
This pa
在 2023-01-21 12:05, Eli Zaretskii via Gcc 写道:
I'm not sure I follow the logic. A program that calls
GetModuleHandleW will refuse to start on Windows that doesn't have
that API. So any version before XP is automatically excluded the
moment you use code which calls that API directly (i.e. not thr
This fixes bootstrap issues with current mingw-w64 headers:
```
../../gcc/gcc/system.h:791:30: error: expected identifier before string
constant
791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
| ^~~~
```
The changes i
在 2022-11-19 19:27, Jonathan Wakely 写道:
I rebased the patch and re-tested with those options, and all tests
passed again:
=== jit Summary ===
# of expected passes15081
The patch is OK for trunk if you have favorable answers for the above
two questions.
Thanks
在 2022/11/12 02:27, Jonathan Wakely 写道:
A clean build fixed that. This patch bootstraps and passes testing on
x86_64-pc-linux-gnu (CentOS 8 Stream).
OK for trunk?
What should we do if no one has been approving this patch?
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP di
在 2022-11-07 20:57, Jonathan Wakely 写道:
It would be a lot nicer if playback::context met the C++ Lockable
requirements, and playback::context::compile () could just take a
scoped lock on *this:
Yeah yeah that makes a lot of sense. Would you please just commit that? I don't have write access t
在 2022/11/7 15:03, Andrew Pinski 写道:
The win32 thread model does not have `std::mutex`; but there is no
`pthread_mutex_t` either, so it
does not build either way.
Oh, but I would assume it will later on right?
There has been effort on C++11 threading support for win32 thread model, but I ha
在 2022-11-07 12:37, Andrew Pinski 写道:
The original code which used pthread was added in GCC 5 way before GCC
moved to being written in C++11 which was only in the last 3 years.
pthread_* functions were the best choice at the time (2014) but now
GCC is written in C++11, I don't see any reason not
在 2022/10/21 20:34, i.nix...@autistici.org 写道:
got it...
anyway it seems logical to me the way I proposed :)
Below is a message forwarded from mingw-w64-public, elaborating the necessity
of a new thread model.
As there are objections from other mingw-w64 developers, I am putting those patc
This allows building libobjc and enabling Objective-C. Tested against GCC 12
branch on i686-w64-mingw32.
--
Best regards,
LIU Hao
From c05cceb2f3baa96c9381be38717bdf6f1f3adb76 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Sat, 22 Oct 2022 17:31:46 +0800
Subject: [PATCH] libgcc: Update 'gthr-mcf
在 2022/10/21 20:13, Jacek Caban 写道:
This is not true for past 15 years, CRITICAL_SECTIONS use something like
RtlWaitOnAddress (an equivalent of futexes) since Vista, see Wine
implementation for details:
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/sync.c#L190
Ah Jacek, nice
在 2022/10/21 19:54, i.nix...@autistici.org 写道:
I have a questions:
1) wouldn't it be logical not to write yet another implementation of pthreads-wor-windows, but to
make changes to the winpthreads library because it's already supported by GCC? (maybe I don’t know
about some reasons why it wasn
在 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 of them for GCC 13, but I don't
know W
在 2022/10/20 03:53, Bernhard Reutner-Fischer 写道:
which has kernel32 twice, which might not be ideal for the speed of linking?
I'm not familiar with the content of ntdll so cannot judge if you'd put that in
MCFGTHREAD_SPEC and drop kernel32 there, though, and put the whole
MCFG spec simply before
在 2022-10-10 23:56, LIU Hao 写道:
在 2022-10-04 20:44, LIU Hao 写道:
Attached are revised patches. These are exported from trunk.
Revised further. The patch for libgfortran has been committed to trunk today, so I include only the
other two.
* In the second patch, a space character has been i
在 2022-10-04 20:44, LIU Hao 写道:
Attached are revised patches. These are exported from trunk.
Revised further. The patch for libgfortran has been committed to trunk today, so I include only the
other two.
* In the second patch, a space character has been inserted after
`(int)` for clea
在 2022-10-04 21:13, Xi Ruoyao 写道:
In GCC development we usually include the configure regeneration in the
patch because the scripts are also version controlled.
There is a reason for not doing that: Generated contents can't be reviewed.
In mingw-w64 we do the opposite: The person who commits
Attached are revised patches. These are exported from trunk.
There is a change since my last message:
* A new Makefile variable `SHLIB_MCFGTHREAD_LIBS` has been introduced, to keep
the other thread models from being affected.
After applying these patches, configure scripts in these subd
在 2022-10-03 13:03, Bernhard Reutner-Fischer 写道:
No, sorry for my brevity.
Using __gthread_t like in your patch is correct.
I see. In 'libgfortran/io/async.c' there is
```
async_unit *au = u->au;
LOCK (&au->lock);
thread_unit = u;
au->thread = __gthread_self ();
```
so i
在 2022-10-02 04:02, Bernhard Reutner-Fischer 写道:
On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches
wrote:
Greetings.
The first patch is necessary because somewhere in libgfortran, `pthread_t` is
referenced. If the thread model is not `posix`, it fails to compile.
One of several
Greetings.
After some years I think it's time to put on this topic again.
This patch series is an attempt to add a new thread model basing on the mcfgthread library
(https://github.com/lhmouse/mcfgthread), which provides efficient implementations of mutexes,
condition variables, once flags, et
The attached patch addresses a build issue when is not included.
Please review.
--
Best regards,
LIU Hao
From 7b573e4cdb7c3b666baac4c38046c64a01b6dcb5 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Fri, 27 May 2022 23:12:48 +0800
Subject: [PATCH] libgfortran: Use `__gthread_t` instead of `pthre
在 2022-05-10 22:28, Jakub Jelinek 写道:
This looks reasonable, but doesn't contain the most important part.
As mentioned in https://gcc.gnu.org/r12-5855
the generic part can now support relocation of PCH, so it is fine if it is
mapped at some other address, it is preferrable if it is mapped at the
在 2022-05-10 20:00, Xi Ruoyao 写道:
On Tue, 2022-05-10 at 19:35 +0800, LIU Hao via Gcc-patches wrote:
Subject: [PATCH] Remove size limit of PCH
Make it "Remove size limit of PCH [PR14940]", so once it's committed a
message will show up in bugzilla.
Here is the revised patc
Remove the limit and solve https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940.
I have tested the patch on `x86_64-w64-mingw32` with MSVCRT, by pre-compiling a header of many
standard and boost headers to generate a 313-MiB-large .gch file and using it to compile a simple
'hello world' program,
This is the third revision of my patch:
1. Two typos in the commit message have been fixed.
2. Support for `%a` and `%A` has been added. Documentation can be
found on the same page in the commit message.
3. GCC will no longer warn about 'ISO C does not support the ‘L’
ms_printf length modifi
在 2020/11/14 上午8:12, Joseph Myers 写道:
> On Fri, 13 Nov 2020, Liu Hao via Gcc-patches wrote:
>
>> 在 2020/11/13 2:46, Joseph Myers 写道:
>>> I'd expect these patches to include updates to the gcc.dg/format/ms_*.c
>>> tests to reflect the changed semantics
在 2020/11/13 2:46, Joseph Myers 写道:
> I'd expect these patches to include updates to the gcc.dg/format/ms_*.c
> tests to reflect the changed semantics (or new tests there if some of the
> changes don't result in any failures in the existing tests).
>
Does the attached patch suffice?
I know ver
在 2020/11/12 23:12, Liu Hao 写道:
>
> My humble opinion is that people should have gotten used to the `ll`
> specifier so I propose a
> different patch that enables it unconditionally. As Jonathan Yong pointed
> out, GCC is impossible to
The previous patch missed a `double_name` field. A revised
在 2020/11/12 18:18, Jonathan Yong 写道:
> libgomp build fails because of the false -Wformat error, even though:
> 1. Correct C99 inttypes.h macros are used.
> 2. __mingw_* C99 wrappers are used.
> 3. The printf attribute is used, but it was aliased to ms_printf
>
> The attached patch makes mingw-w64
Ping?
在 2020/10/29 下午3:56, Liu Hao 写道:
> I forward it here for comments.
>
> Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is used
> to register the
> destructor of thread_local objects directly, suggesting the first parameter
> should have `__thiscall`
> convention.
I forward it here for comments.
Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is used to
register the
destructor of thread_local objects directly, suggesting the first parameter
should have `__thiscall`
convention.
libstdc++ used the default `__cdecl` convention and caused
在 2020/10/8 22:56, Jason Merrill 写道:
>
> Hmm, why isn't the mingw implementation used for all programs? That would
> avoid the bug.
>
There was a little further discussion about this [1].
TL;DR: The mingw-w64 function is linked statically and subject to issues about
order of destruction.
Re
在 2020/10/8 22:56, Jason Merrill 写道:
> On 10/7/20 10:52 PM, Liu Hao via Gcc-patches wrote:
>> [Please CC me as I am not subscribed to this list.]
>
> Hmm, why isn't the mingw implementation used for all programs? That would
> avoid the bug.
>
I am afraid the libstdc+
[Please CC me as I am not subscribed to this list.]
[This patch is only a draft and has not been tested at all.]
Some details have been discussed in [1]. mingw-w64 has got an implementation
[2] [3] for static libraries, but it takes a
destructor using the `__thiscall` convention. As both functio
在 2020/5/29 22:01, Liu Hao 写道:
> This is necessary as libmsvcrt.a is not a pure import library, but
> also contains some functions that invoke others in KERNEL32.DLL.
>
> * config/i386/mingw32.h: Insert -lkernel32 after -lmsvcrt
> ---
> gcc/config/i386/mingw32.h | 2 +-
> 1 file changed, 1
This is necessary as libmsvcrt.a is not a pure import library, but
also contains some functions that invoke others in KERNEL32.DLL.
* config/i386/mingw32.h: Insert -lkernel32 after -lmsvcrt
---
gcc/config/i386/mingw32.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/g
39 matches
Mail list logo
