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 |
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
*
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
: 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 ja...@codeweavers.com
On 09/12/13 12:20, Kai Tietz wrote:
Hi Jacek,
2013/9/12 Jacek Caban cja...@gmail.com:
Hi,
This is a resend after I'm done with assignment paper work.
gcc/c-family/ChangeLog:
c-target.def: New hook
gcc/ChangeLog:
config/config.gcc: Use new winnt-c.c target hooks
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 such function is WinMain on Win32
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
On 09/17/13 13:41, Kai Tietz wrote:
2013/9/17 Jacek Caban cja...@gmail.com:
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
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, where only unicode variant is
available
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
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
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
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!
--
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
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 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
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 more complic
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
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
20 matches
Mail list logo
