Re: [Mingw-w64-public] [PATCH] Fix potential deadlock in pthread condition variable

在 2019/4/23 下午11:30, Andrew Ng 写道: > Any feedback on this patch? > > I did have a look at this code in winpthreads, but failed to understand how it works. I would like to ask Kai for some details, but he hasn't been on IRC recently. -- Best regards, LH_Mouse signature.asc Description: Open

Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having GCC compile errors

On Tue, 23 Apr 2019, Kacvinsky, Tom wrote: HI -Original Message- From: Liu Hao Sent: Monday, April 22, 2019 10:18 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having GCC compile errors 在 2019/4/23 上午5:12, Martin St

Re: [Mingw-w64-public] [PATCH] Fix potential deadlock in pthread condition variable

Any feedback on this patch? Cheers, Andrew On Fri, 12 Apr 2019 at 16:50, Andrew Ng wrote: > Sorry about that. I was hoping that a ".diff" file might make it through > to the mailing list, as I thought that I had seen other such file > attachments in some of the other messages. I'll stick to ".t

Re: [Mingw-w64-public] [PATCH 3/3] math: Don't do pointer type punning via a union

在 2019/4/23 15:51, Martin Storsjö 写道: > Don't converting from one pointer type to another via a union; > that is still a strict aliasing violation as far as I know. > > Use unions for actually reinterpreting the values instead, which > is not an aliasing violation, and is defined according to the

Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having GCC compile errors

HI > -Original Message- > From: Liu Hao > Sent: Monday, April 22, 2019 10:18 PM > To: mingw-w64-public@lists.sourceforge.net > Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having > GCC compile errors > > 在 2019/4/23 上午5:12, Martin Storsjö 写道: > > I haven't looked

[Mingw-w64-public] [PATCH 3/3] math: Don't do pointer type punning via a union

Don't converting from one pointer type to another via a union; that is still a strict aliasing violation as far as I know. Use unions for actually reinterpreting the values instead, which is not an aliasing violation, and is defined according to the C99 standard (which also was relied on before).

[Mingw-w64-public] [PATCH 2/3] crt: Include math.h in signbitl.c instead of duplicating declarations

Signed-off-by: Martin Storsjö --- mingw-w64-crt/math/signbitl.c | 19 +-- 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/mingw-w64-crt/math/signbitl.c b/mingw-w64-crt/math/signbitl.c index 723933dbb..e1eeadf78 100644 --- a/mingw-w64-crt/math/signbitl.c +++ b/mingw-w

[Mingw-w64-public] [PATCH 1/3] crt: arm: Provide logb* and ilogb* for msvcrt.dll for arm/arm64

Signed-off-by: Martin Storsjö --- mingw-w64-crt/Makefile.am | 6 ++ mingw-w64-crt/lib-common/msvcrt.def.in | 3 +++ mingw-w64-crt/math/arm-common/ilogb.c | 19 +++ mingw-w64-crt/math/arm-common/ilogbf.c | 19 +++ mingw-w64-crt/math/arm-common/il

[Mingw-w64-public] [PATCH 1/3] math: Don't read a double aliased via a long double struct

The particular fields used here happened to be laid out in the same way for both double and long double though. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/math.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/crt/math.h b/mingw-w64-headers/

[Mingw-w64-public] [PATCH 2/3] math: Change FP_ILOGBNAN to match UCRT

On ARM/ARM64, we currently use ilogb functions from the dynamically linked ucrt. This requires updating (compiler produced, not hand written) assembly code for x86, to return the right values. Signed-off-by: Martin Storsjö --- mingw-w64-crt/math/x86/ilogb.S | 14 -- mingw-w64-crt/m

[Mingw-w64-public] [PATCH 3/3] crt: x86: Correctly handle denormals in the logb functions

Also update similar code in headers, although it is disabled (within #if 0). Signed-off-by: Martin Storsjö --- mingw-w64-crt/math/x86/logb.c | 6 -- mingw-w64-crt/math/x86/logbf.c | 4 ++-- mingw-w64-headers/crt/math.h | 16 ++-- 3 files changed, 16 insertions(+), 10 deletio