Re: [Mingw-w64-public] [PATCH 01/19] math: Add errors in assembly sources if no implementation exists

On 08/05/2017 09:14 PM, Martin Storsjö wrote: > This helps finding unimplemented functions; otherwise the symbol > will exist, but won't contain any implementation, so the function > will end up pointing at whatever other function the linker places > next. I would prefer these checks be in the

[Mingw-w64-public] [PATCH 19/19] crt: Disable win64 unwinding on arm64

This allows building this file for now, until the necessary struct (CONTEXT in winnt.h) is available. --- mingw-w64-crt/crt/gs_support.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c index c5c1773..0c6ac68

[Mingw-w64-public] [PATCH 18/19] winnt.h: Add empty definition of arch specific structs for arm64

--- The correct/official definition of these structs are available in winnt.h in the win10 sdk (but they are not documented on e.g. MSDN). I haven't looked closer at them other than noticing that they exist there. This setup (with empty dummy structs) is enough for code to compile without error at

[Mingw-w64-public] [PATCH 09/19] math: Add aarch64 assembly implementations of math functions

--- mingw-w64-crt/math/_chgsignl.S | 3 +++ mingw-w64-crt/math/ceil.S | 3 +++ mingw-w64-crt/math/ceilf.S | 3 +++ mingw-w64-crt/math/ceill.S | 3 +++ mingw-w64-crt/math/copysignl.S | 2 ++ mingw-w64-crt/math/floor.S | 3 +++ mingw-w64-crt/math/floorf.S | 3 +++

[Mingw-w64-public] [PATCH 16/19] crt: Disable __mingw_init_ehandler on aarch64

This was enabled for _WIN64 before, but only enable it on x86_64 for now. --- mingw-w64-crt/crt/crt_handler.c | 2 +- mingw-w64-crt/crt/crtdll.c | 2 +- mingw-w64-crt/crt/crtexe.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/mingw-w64-crt/crt/crt_handler.c

[Mingw-w64-public] [PATCH 14/19] crtexe: Skip __initenv on aarch64 just as on arm

--- mingw-w64-crt/crt/crtexe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c index ae37e0f..bbef685 100644 --- a/mingw-w64-crt/crt/crtexe.c +++ b/mingw-w64-crt/crt/crtexe.c @@ -26,7 +26,7 @@ extern wchar_t ***

[Mingw-w64-public] [PATCH 08/19] math: Use the same generic codepaths for aarch64 as for arm

Just as on arm, long double is the same as double. --- mingw-w64-crt/math/arm/exp2.c | 2 +- mingw-w64-crt/math/arm/log2.c | 2 +- mingw-w64-crt/math/arm/scalbn.c | 2 +- mingw-w64-crt/math/arm/sincos.c | 2 +- mingw-w64-crt/math/cephes_mconf.h | 4 ++-- mingw-w64-crt/math/fabs.c

[Mingw-w64-public] [PATCH 11/19] stdio: Add aarch64 assembly wrappers for the v*scanf functions

Implement the forwarding function in scanf2-template.S and the va_list unwrapper in the __argtos function in scanf.S, and add aarch64 to the list of supported architectures in the files that need it. --- mingw-w64-crt/stdio/scanf.S | 32

[Mingw-w64-public] [PATCH 05/19] headers: Detection of __aarch64__ in some main locations

--- mingw-w64-headers/crt/malloc.h| 2 +- mingw-w64-headers/include/winnt.h | 21 ++--- 2 files changed, 15 insertions(+), 8 deletions(-) diff --git a/mingw-w64-headers/crt/malloc.h b/mingw-w64-headers/crt/malloc.h index b4c9dc4..9d75ea6 100644 ---

[Mingw-w64-public] [PATCH 12/19] intrin-impl.h: Include compiler builtins based parts on aarch64 as well

--- mingw-w64-headers/include/psdk_inc/intrin-impl.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h b/mingw-w64-headers/include/psdk_inc/intrin-impl.h index 352b686..a1c77b5 100644 ---

[Mingw-w64-public] [PATCH 17/19] winnt.h: Add arm64 specific handling of TEB

--- mingw-w64-headers/include/winnt.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/mingw-w64-headers/include/winnt.h b/mingw-w64-headers/include/winnt.h index 9107a36..f48cb30 100644 --- a/mingw-w64-headers/include/winnt.h +++ b/mingw-w64-headers/include/winnt.h @@ -8395,6

[Mingw-w64-public] [PATCH 13/19] intrin-impl.h: Add aarch64 functions corresponding to the arm ones

--- mingw-w64-headers/include/psdk_inc/intrin-impl.h | 145 +++ 1 file changed, 145 insertions(+) diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h b/mingw-w64-headers/include/psdk_inc/intrin-impl.h index a1c77b5..6f7d60e 100644 ---

[Mingw-w64-public] [PATCH 00/19] ARM64 support in MinGW

Hi, This patchset adds initial support for targeting ARM64 in MinGW. While Windows on ARM64 isn't publicly available yet (but rumored to be released this fall), it is (somewhat) testable in Wine (bootstrapped with some arm64 binaries from the windows 10 sdk, by André Hentschel). Additionally,

[Mingw-w64-public] [PATCH 10/19] math: Implement the exp2() wrappers using assembly on aarch64

The LLVM optimizer replaces a call to pow(2, x) back into a call to exp2(x), which ends up in an infinite loop/recursion here. To avoid the issue, one could either build exp2.c (or easier to accomplish, all of libmingwex.a) using -fno-builtin or -ffreestanding, or produce the exp2() function

[Mingw-w64-public] [PATCH 01/19] math: Add errors in assembly sources if no implementation exists

This helps finding unimplemented functions; otherwise the symbol will exist, but won't contain any implementation, so the function will end up pointing at whatever other function the linker places next. --- mingw-w64-crt/math/_chgsignl.S | 2 ++ mingw-w64-crt/math/ceil.S | 2 ++

[Mingw-w64-public] [PATCH 06/19] headers: Skip the inline interlocked functions for aarch64 (as on all other non-i386 archs)

These are skipped on x86_64, arm and aarch64 - in practice the condition maybe should be inverted to only include i386. --- mingw-w64-headers/include/interlockedapi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-headers/include/interlockedapi.h

[Mingw-w64-public] [PATCH 03/19] crt: Add initial support for arm64 in mingw-w64-crt Makefile.am/configure.ac

This is supported by llvm-dlltool only so far. The actual def files in the libarm64 subdirectory are added in a separate commit. --- mingw-w64-crt/Makefile.am | 253 + mingw-w64-crt/configure.ac | 21 2 files changed, 274 insertions(+) diff

[Mingw-w64-public] [PATCH 02/19] setjmp.h: Add a fallback definition for unsupported architectures

This allows including the header without errors, if building for an architecture that we lack setjmp support for so far. This matches what wine have got at the end of their setjmp.h. --- mingw-w64-headers/crt/setjmp.h | 5 + 1 file changed, 5 insertions(+) diff --git

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

What I meant is that if GCC's optimizer ever figures out that we are comparing pointers that came from two different memory objects, it would know we are doing undefined behavior and would have a license to do whatever it wants, including removing that code. The way the loop is written right now

[Mingw-w64-public] [Project News|New Builds]

Hi, The new builds of MinGW-W64 based on GCC-6.4.0 is uploaded. MinGW-w64 v5.x is used. 32-bit: posix-sjlj: https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/6.4.0/threads-posix/sjlj/i686-6.4.0-release-posix-sjlj-rt_v5-rev0.7z posix-dwarf:

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

> > I think Martell's last patch would have worked but it's not as safe as > I would like it to be. I think the constructor and destructor lists should not be defined in gccmain.c where they are used, because then > the compiler optimizer might start to get smart and stop optimizing > things in a

Re: [Mingw-w64-public] Where are headers defined?

On 8/5/17, Jeroen Ooms wrote: > Trying to build opendap [1] but the configure script can't find uuid.h: > > checking uuid/uuid.h usability... no > checking uuid/uuid.h presence... no > checking for uuid/uuid.h... no > checking uuid.h usability... no > checking uuid.h

[Mingw-w64-public] Where are headers defined?

Trying to build opendap [1] but the configure script can't find uuid.h: checking uuid/uuid.h usability... no checking uuid/uuid.h presence... no checking for uuid/uuid.h... no checking uuid.h usability... no checking uuid.h presence... no checking for uuid.h... no configure: error: Could not find

Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

Thanks LH_Mouse, I've tested the -malign-data option and it does the job. Sadly for now I'm stuck with gcc 4.9.2 in production and this option was introduced in 5.0. Ah, well... At least the problem will solve itself in future, and the attribute approach must suffice for now. Best regards,

Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

> and you get the following from objdump: >[ 20](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x >test_struct >[ 21](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0024 a >[ 22](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0028 b >With the section size of 0x40. In

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

Oops, here is the patch. On Sat, Aug 5, 2017 at 10:14 AM, David Grayson wrote: > I think Martell's last patch would have worked but it's not as safe as > I would like it to be. I think the constructor and destructor lists > should not be defined in gccmain.c where they

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

I think Martell's last patch would have worked but it's not as safe as I would like it to be. I think the constructor and destructor lists should not be defined in gccmain.c where they are used, because then the compiler optimizer might start to get smart and stop optimizing things in a bad way.