On 22.02.2024 18:45, Andrew Pinski wrote:
On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists)
wrote:
On 21/02/2024 18:30, Evgeny Karpov wrote:
+/* X18 reserved for the TEB on Windows. */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define FIXED_X18
Hi Costas,
On 3/7/23 15:00, Costas Argyris wrote:
Hi Jacek,
"Is there a reason to make it specific to x86_64? It seems to me that
all mingw hosts could use it."
Are you referring to the 32-bit host? My concern here is that this
functionality (embedding the UTF-8
manifest file into the ex
Hi Costas,
On 3/7/23 01:52, Costas Argyris via Gcc-patches wrote:
This is a proposal for addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
by integrating the UTF-8 manifest file into gcc's build process for the
64-bit mingw host.
Is there a reason to make it specific to x86_64?
builds (from GCC 12
release branch) with these patches at https://gcc-mcf.lhmouse.com/.
Forwarded Message
在 2022/10/23 18:06, Jacek Caban 写道:
>
> Please, let's not do that. It's possible to fix existing
implementations, we don't need to make
> things mo
On 10/21/22 14:29, LIU Hao wrote:
在 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
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 problem about this approach is that, semaphores are valuable kernel objects, and the maximum
number of HANDLEs that a process can open concurrently has a limit (like FDs on Linux), while 'many
critical sections are used only occasionally (or never at all), meaning the auto-reset event often
On 02/07/2019 12:12, Jacek Caban wrote:
On 02/07/2019 11:57, Liu Hao wrote:
在 2019/7/2 下午5:19, Eric Botcazou 写道:
It seems inappropriate to use handles as thread identifiers (as
handles
imply resource ownership and are not unique identifiers); thread
IDs (as
`DWORD` or `unsigned long
On 02/07/2019 11:57, Liu Hao wrote:
在 2019/7/2 下午5:19, Eric Botcazou 写道:
It seems inappropriate to use handles as thread identifiers (as handles
imply resource ownership and are not unique identifiers); thread IDs (as
`DWORD` or `unsigned long`) would be a better alternative.
This was consider
Hi Eric,
On 6/28/19 3:42 PM, NightStrike wrote:
FYI, Eric posted this today to the GCC patches list. This may be of
great interest to many who would prefer native threads instead of the
winpthreads posix style interface.
Great work, Eric! I look forward to trying this out!
-- Forward
On 09/18/13 10:57, Pedro Alves wrote:
> On 09/17/2013 12:19 PM, Jacek Caban wrote:
>> This is no-op for usual GCC targets, because we don't pass any string to
>> CreateSemaphore anyway. However this trivial change will help
>> mingw-w64's efforts to support WinRT
On 09/17/13 13:41, Kai Tietz wrote:
> 2013/9/17 Jacek Caban :
>> This is no-op for usual GCC targets, because we don't pass any string to
>> CreateSemaphore anyway. However this trivial change will help
>> mingw-w64's efforts to support WinRT, where only
This is no-op for usual GCC targets, because we don't pass any string to
CreateSemaphore anyway. However this trivial change will help
mingw-w64's efforts to support WinRT, where only unicode variant is
available.
libgcc/Changelog:
config/i386/gthr-win32.c: CreateSemaphoreW instead of CreateSe
On 09/12/13 14:38, Jason Merrill wrote:
> On 09/12/2013 06:26 AM, Jacek Caban wrote:
>> +@deftypefn {C Target Hook} bool TARGET_CXX_IMPLICIT_EXTERN_C (const
>> char*@var{})
>> +Define this hook to add target-specific C++ implicit extern C
>> functions. An example of
On 09/12/13 12:20, Kai Tietz wrote:
> Hi Jacek,
>
> 2013/9/12 Jacek Caban :
>> Hi,
>>
>> This is a resend after I'm done with assignment paper work.
>>
>> gcc/c-family/ChangeLog:
>> c-target.def: New hook
>>
>> gcc/Cha
xi.in: Document new hook
doc/tm.texi: Regenerated
gcc/cp/Changelog:
decl.c: Use new cxx_implicit_extern_c hook
gcc/testsuite/ChangeLog:
g++.dg/abi/main.C: Added implicit C linkage tests
commit f35cdda381f8213b3d005363e557f1b76732be3b
Author: Jacek Caban
Date: Sat D
Hi,
This is another version of my old patch, changed to use target hooks as
requested by Steven Bosscher.
Tested on i686-w64-mingw32, x86_64-w64-mingw32 and
x86_64-unknown-linux-gnu, bootstrapped on x86_64-unknown-linux-gnu.
Disclaimer: the patch is in public domain.
(because I don't have
gcc/ChangeLog:
* config/i386/mingw-w64.h: Specify entry points with implicit C linkage
gcc/cp/ChangeLog:
* decl.c: Allow custom target implicit C linkage
gcc/testsuite/ChangeLog:
* g++.dg/ext/main.C: Added implicit C linkage tests
---
gcc/config/i386/mingw-w64.h |
Fixed Changelog as requested by Eric. Thanks.
gcc/ChangeLog
* config/i386/mingw-w64.h: Specify entry points with implicit C linkage
gcc/cp/ChangeLog:
* decl.c: Allow custom target implicit C linkage
gcc/testsuite/ChangeLog:
* g++.dg/ext/main.C: Added implicit C linkage
This is my first patch to GCC, so please let me know if I did something
wrong. This patch fixes common annoyance on w64-mingw32 targets, where
once needs to add explicit "C" linkage to make C++ app work with wmain
entry point.
* decl.c: Allow custom target implicit C linkage
*
20 matches
Mail list logo
