Re: [Mingw-w64-public] [PATCH] winpthreads: Avoid using MemoryBarrier() in public headers with GCC/Clang

2024-04-23 Thread LIU Hao

在 2024-04-24 00:18, Antonin Décimo 写道:

I couldn't find the difference between MemoryBarrier and _ReadWriteBarrier.
Maybe the MemoryBarrier macro is available on more architectures than
_ReadWriteBarrier which is only documented for x86 and x64?


`MemoryBarrier()` is a macro defined in 'winnt.h'. As a rule of thumb I think we had better avoid 
inclusion of Windows headers in our headers, especially headers that may be included by standard 
libraries.




If there's no problems using _ReadWriteBarrier, it seems like the
easiest solution.
I'd suggest moving to C11 atomic_thread_fence [1], but MSVC likely
misses support…


Strangely that MSVC has only gained C11 atomic recently, and requires `/std:c11 
/experimental:c11atomics`. So it yet results in more complexity which I think we had better avoid:


   #if defined __GNUC__ || defined __clang__
   /* GCC or Clang-CL */
   #  define __pthread_MemoryBarrier()  \
__sync_synchronize()  /* __atomic_thread_fence(__ATOMIC_SEQ_CST) */
   #elif defined __cplusplus && (__cplusplus >= 201103L)
   /* C++11 */
   #  include 
   #  define __pthread_MemoryBarrier()  \
::std::atomic_thread_fence(::std::memory_order_seq_cst)
   #else
   /* C11 */
   #  include 
   #  define __pthread_MemoryBarrier()  \
atomic_thread_fence(memory_order_seq_cst)
   #endif




--
Best regards,
LIU Hao



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] [PATCH] winpthreads: Avoid using MemoryBarrier() in public headers with GCC/Clang

2024-04-23 Thread Antonin Décimo
> Liu Hao also pointed out that we could use _ReadWriteBarrier() with MSVC,
> and that one doesn't seem to require including any header before it is
> usable.

I couldn't find the difference between MemoryBarrier and _ReadWriteBarrier.
Maybe the MemoryBarrier macro is available on more architectures than
_ReadWriteBarrier which is only documented for x86 and x64?
If there's no problems using _ReadWriteBarrier, it seems like the
easiest solution.
I'd suggest moving to C11 atomic_thread_fence [1], but MSVC likely
misses support…

[1]: https://en.cppreference.com/w/c/atomic/atomic_thread_fence


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Rust test failure after some math functions were moved

2024-04-23 Thread Jacek Caban

On 23.04.2024 13:39, Martin Storsjö wrote:

On Tue, 16 Apr 2024, Jacek Caban wrote:

But in this particular case, I think we may improve things on 
mingw-w64-crt side and move __sinl_internal to msvcr* importlibs. 
Something like the attached (untested) patch should help.


Unfortunately, we can't really do this; __sinl_internal and 
__cosl_internal are used by both math/x86/sin.c and math/x86/cos.c, 
which are in src_msvcrt_common_add_x86 (i.e. in the msvcr* specific 
import libraries), but they're also used by math/x86/sinl.c and 
math/x86/cosl.c, which are in src_libmingwex_x86, because the long 
double form of them are needed even with UCRT. 



Oh right, we'd be missing it in UCRT. It seems that the most reliable 
fix is on Rust side.



Thanks,

Jacek



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Rust test failure after some math functions were moved

2024-04-23 Thread Martin Storsjö

On Tue, 16 Apr 2024, Jacek Caban wrote:

But in this particular case, I think we may improve things on 
mingw-w64-crt side and move __sinl_internal to msvcr* importlibs. 
Something like the attached (untested) patch should help.


Unfortunately, we can't really do this; __sinl_internal and 
__cosl_internal are used by both math/x86/sin.c and math/x86/cos.c, which 
are in src_msvcrt_common_add_x86 (i.e. in the msvcr* specific import 
libraries), but they're also used by math/x86/sinl.c and math/x86/cosl.c, 
which are in src_libmingwex_x86, because the long double form of them are 
needed even with UCRT.


// Martin



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] [PATCH] winpthreads: Avoid using MemoryBarrier() in public headers with GCC/Clang

2024-04-23 Thread Martin Storsjö

On Tue, 23 Apr 2024, Martin Storsjö wrote:


Commit f281f4969d332efc842b93da892c2e97084e403e changed
pthread_cleanup_push() to use MemoryBarrier() instead of
__sync_synchronize(), for various reasons - one of them being
able to build winpthreads with MSVC.

Unfortunately, this change had the effect of breaking user code,
including winpthreads headers and using pthread_cleanup_push()
without including Windows headers first, as the MemoryBarrier()
intrinsic requires including headers to get it properly declared
(both with GCC, Clang and MSVC).

To avoid this issue, revert to __sync_synchronize() in the
installed header, as long as it is included with a GCC compatible
compiler. For MSVC, keep using MemoryBarrier().

Signed-off-by: Martin Storsjö 
---
Commit f281f4969d332efc842b93da892c2e97084e403e argues that
__sync_synchronize is deprecated within GCC, so we could of course
look into using a more recommended intrinsic instead; this
is only an attempt to undo the breakage to user code.
---
mingw-w64-libraries/winpthreads/include/pthread.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/include/pthread.h 
b/mingw-w64-libraries/winpthreads/include/pthread.h
index 93d7c11c3..b1b5c8165 100644
--- a/mingw-w64-libraries/winpthreads/include/pthread.h
+++ b/mingw-w64-libraries/winpthreads/include/pthread.h
@@ -208,13 +208,22 @@ struct _pthread_cleanup
_pthread_cleanup *next;
};

+/* Using MemoryBarrier() requires including Windows headers. User code
+ * may want to use pthread_cleanup_push without including Windows headers
+ * first, thus prefer GCC specific intrinsics where possible. */
+#ifdef __GNUC__
+#define __pthread_MemoryBarrier() __sync_synchronize()
+#else
+#define __pthread_MemoryBarrier() MemoryBarrier()


Liu Hao also pointed out that we could use _ReadWriteBarrier() with MSVC, 
and that one doesn't seem to require including any header before it is 
usable.


// Martin

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


[Mingw-w64-public] [PATCH] winpthreads: Avoid using MemoryBarrier() in public headers with GCC/Clang

2024-04-23 Thread Martin Storsjö
Commit f281f4969d332efc842b93da892c2e97084e403e changed
pthread_cleanup_push() to use MemoryBarrier() instead of
__sync_synchronize(), for various reasons - one of them being
able to build winpthreads with MSVC.

Unfortunately, this change had the effect of breaking user code,
including winpthreads headers and using pthread_cleanup_push()
without including Windows headers first, as the MemoryBarrier()
intrinsic requires including headers to get it properly declared
(both with GCC, Clang and MSVC).

To avoid this issue, revert to __sync_synchronize() in the
installed header, as long as it is included with a GCC compatible
compiler. For MSVC, keep using MemoryBarrier().

Signed-off-by: Martin Storsjö 
---
Commit f281f4969d332efc842b93da892c2e97084e403e argues that
__sync_synchronize is deprecated within GCC, so we could of course
look into using a more recommended intrinsic instead; this
is only an attempt to undo the breakage to user code.
---
 mingw-w64-libraries/winpthreads/include/pthread.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/include/pthread.h 
b/mingw-w64-libraries/winpthreads/include/pthread.h
index 93d7c11c3..b1b5c8165 100644
--- a/mingw-w64-libraries/winpthreads/include/pthread.h
+++ b/mingw-w64-libraries/winpthreads/include/pthread.h
@@ -208,13 +208,22 @@ struct _pthread_cleanup
 _pthread_cleanup *next;
 };
 
+/* Using MemoryBarrier() requires including Windows headers. User code
+ * may want to use pthread_cleanup_push without including Windows headers
+ * first, thus prefer GCC specific intrinsics where possible. */
+#ifdef __GNUC__
+#define __pthread_MemoryBarrier() __sync_synchronize()
+#else
+#define __pthread_MemoryBarrier() MemoryBarrier()
+#endif
+
 #define pthread_cleanup_push(F, A)  \
 do {\
 const _pthread_cleanup _pthread_cup =   \
 { (F), (A), *pthread_getclean() };  \
-MemoryBarrier();\
+__pthread_MemoryBarrier();  \
 *pthread_getclean() = (_pthread_cleanup *) &_pthread_cup;   \
-MemoryBarrier();\
+__pthread_MemoryBarrier();  \
 do {\
 do {} while (0)
 
-- 
2.34.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


[Mingw-w64-public] [PATCH] headers: Add tcpxcv.h

2024-04-23 Thread Biswapriyo Nath

From fe72cdf89cd2d583c3fa4c43406fc08777bc1fe5 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath 
Date: Tue, 23 Apr 2024 07:41:17 +
Subject: [PATCH] headers: Add tcpxcv.h

Fixes https://github.com/mingw-w64/mingw-w64/issues/46

Signed-off-by: Biswapriyo Nath 
---
 mingw-w64-headers/include/tcpxcv.h | 92 ++
 1 file changed, 92 insertions(+)
 create mode 100644 mingw-w64-headers/include/tcpxcv.h

diff --git a/mingw-w64-headers/include/tcpxcv.h 
b/mingw-w64-headers/include/tcpxcv.h
new file mode 100644
index 000..a2bf467
--- /dev/null
+++ b/mingw-w64-headers/include/tcpxcv.h
@@ -0,0 +1,92 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#ifndef _TCPXCV_
+#define _TCPXCV_
+
+#include 
+
+#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+
+#if !defined(UNKNOWN_PROTOCOL)
+#define UNKNOWN_PROTOCOL 0
+#define PROTOCOL_UNKNOWN_TYPE UNKNOWN_PROTOCOL
+#endif
+
+#if !defined(RAWTCP)
+#define RAWTCP 1
+#define PROTOCOL_RAWTCP_TYPE RAWTCP
+#endif
+
+#if !defined(LPR)
+#define LPR 2
+#define PROTOCOL_LPR_TYPE LPR
+#endif
+
+#define MAX_PORTNAME_LEN 64
+#define MAX_NETWORKNAME_LEN 49
+#define MAX_NETWORKNAME2_LEN 128
+#define MAX_SNMP_COMMUNITY_STR_LEN 33
+#define MAX_QUEUENAME_LEN 33
+#define MAX_IPADDR_STR_LEN 16
+#define MAX_ADDRESS_STR_LEN 13
+#define MAX_DEVICEDESCRIPTION_STR_LEN 257
+
+typedef struct _PORT_DATA_1 {
+  WCHAR sztPortName[MAX_PORTNAME_LEN];
+  DWORD dwVersion;
+  DWORD dwProtocol;
+  DWORD cbSize;
+  DWORD dwReserved;
+  WCHAR sztHostAddress[MAX_NETWORKNAME_LEN];
+  WCHAR sztSNMPCommunity[MAX_SNMP_COMMUNITY_STR_LEN];
+  DWORD dwDoubleSpool;
+  WCHAR sztQueue[MAX_QUEUENAME_LEN];
+  WCHAR sztIPAddress[MAX_IPADDR_STR_LEN];
+  BYTE Reserved[540];
+  DWORD dwPortNumber;
+  DWORD dwSNMPEnabled;
+  DWORD dwSNMPDevIndex;
+} PORT_DATA_1, *PPORT_DATA_1;
+
+typedef struct _PORT_DATA_2 {
+  WCHAR sztPortName[MAX_PORTNAME_LEN];
+  DWORD dwVersion;
+  DWORD dwProtocol;
+  DWORD cbSize;
+  DWORD dwReserved;
+  WCHAR sztHostAddress [MAX_NETWORKNAME2_LEN];
+  WCHAR sztSNMPCommunity[MAX_SNMP_COMMUNITY_STR_LEN];
+  DWORD dwDoubleSpool;
+  WCHAR sztQueue[MAX_QUEUENAME_LEN];
+  BYTE Reserved[514];
+  DWORD dwPortNumber;
+  DWORD dwSNMPEnabled;
+  DWORD dwSNMPDevIndex;
+  DWORD dwPortMonitorMibIndex;
+} PORT_DATA_2, *PPORT_DATA_2;
+
+typedef struct _PORT_DATA_LIST_1 {
+  DWORD dwVersion;
+  DWORD cPortData;
+  PORT_DATA_2 pPortData[1];
+} PORT_DATA_LIST_1, *PPORT_DATA_LIST_1;
+
+typedef struct _DELETE_PORT_DATA_1 {
+  WCHAR psztPortName[MAX_PORTNAME_LEN];
+  BYTE Reserved[98];
+  DWORD dwVersion;
+  DWORD dwReserved;
+} DELETE_PORT_DATA_1, *PDELETE_PORT_DATA_1;
+
+typedef struct _CONFIG_INFO_DATA_1 {
+  BYTE Reserved[128];
+  DWORD dwVersion;
+} CONFIG_INFO_DATA_1, *PCONFIG_INFO_DATA_1;
+
+#endif /* WINAPI_PARTITION_DESKTOP */
+
+#endif /* _TCPXCV_ */
-- 
2.44.0

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public