One could think about using OpenLibm. Julia is using OpenLibm as its math
implementation.
There is a nice comparison of glibc, OpenLibm, Musl and Intel as well AMD
math implementations: "Accuracy of Mathematical Functions in Single,
Double, Extended Double and Quadruple Precision" Paul Zimmermann
On Mon, 14 Jun 2021, Liu Hao wrote:
在 6/14/21 3:58 PM, Martin Storsjö 写道:
BTW, one different aspect of this initialization; if you have a DLL that is
built with -funsigned-char, and this is loaded by an EXE that isn't built
that way, the DLL still initializes the lconv info to unsigned mode.
在 6/14/21 3:58 PM, Martin Storsjö 写道:
BTW, one different aspect of this initialization; if you have a DLL that is built with
-funsigned-char, and this is loaded by an EXE that isn't built that way, the DLL still initializes
the lconv info to unsigned mode. The same happens with MSVC too (as lo
Hi,
On Mon, 14 Jun 2021, Liu Hao wrote:
在 6/14/21 3:37 PM, Martin Storsjö 写道:
This symbol vaguely seems like it might be meant to be overridden
by the app code, but I don't see how that practically would work,
as the init routines (crtdll.c and crtexe.c) set it anyway, so
whatever default valu
在 6/14/21 3:37 PM, Martin Storsjö 写道:
This symbol vaguely seems like it might be meant to be overridden
by the app code, but I don't see how that practically would work,
as the init routines (crtdll.c and crtexe.c) set it anyway, so
whatever default value the user code provided wouldn't have any
On Mon, 14 Jun 2021, Martin Storsjö wrote:
On Mon, 14 Jun 2021, Liu Hao wrote:
在 6/14/21 3:09 PM, Martin Storsjö 写道:
Right yes... Normal C++ e.g. declared in a class header are emitted that
way (but that comes with all the extra hairiness regarding inline
functions that might not be emitte
On Mon, 14 Jun 2021, Liu Hao wrote:
在 6/14/21 3:09 PM, Martin Storsjö 写道:
Right yes... Normal C++ e.g. declared in a class header are emitted that
way (but that comes with all the extra hairiness regarding inline functions
that might not be emitted and/or optimized out). So unless we know we
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/crt/charmax.c | 2 +-
mingw-w64-crt/crt/crtexe.c | 12 ++--
mingw-w64-crt/crt/tlssup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/mingw-w64-crt/crt/charmax.c b/mingw-w64-crt/crt/charmax.c
index 08aa5a1d3
This symbol vaguely seems like it might be meant to be overridden
by the app code, but I don't see how that practically would work,
as the init routines (crtdll.c and crtexe.c) set it anyway, so
whatever default value the user code provided wouldn't have any
effect anyway.
Signed-off-by: Martin St
Signed-off-by: Martin Storsjö
---
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 a7af136fe..8b1c86392 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -99,8
在 6/14/21 3:09 PM, Martin Storsjö 写道:
Right yes... Normal C++ e.g. declared in a class header are emitted that way (but that comes with
all the extra hairiness regarding inline functions that might not be emitted and/or optimized out).
So unless we know we can do manual selectany on a plain no
On Mon, 14 Jun 2021, Liu Hao wrote:
在 6/14/21 1:49 PM, Martin Storsjö 写道:
FWIW we have __declspec(selectany) in a number of places in our headers
already (which expands to the same), but not in the crt/* headers yet. I
don't mind either this or plain __declspec(selectany).
The GCC manual
12 matches
Mail list logo
