在 2021-12-17 02:13, Michel Zou 写道:
> Hi,
> It turns out that these are inline functions, here is a new patch.
> xan
>
Thanks. Pushed to master.
Next time, please send a patch created by `git format`, and please do sign off
the commit with `git commit -s`.
--
Best regards,
LIU Hao
___
在 5/15/21 1:27 AM, Jacek Caban 写道:
>
> I think that the decision was unfortunate on GCC side, but there is little we
> can do. We will
> probably need to provide it in msvcrt importlibs. Please try the attached
> patch, it should help.
>
>
Doesn't GCC transform such pair of calls to `sincos()
在 4/20/21 9:31 PM, yume todo 写道:
>
> In ucrt64, quick_exit is not found.
>
>
This has been fixed on master now:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/7dda261
--
Best regards,
Liu Hao
___
Mingw-w64-public mailing list
Mingw-w64-public@l
On 2018/1/12 4:30, Jacek Caban wrote: > Signed-off-by: Jacek Caban
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_
On 2018/1/12 4:31, Jacek Caban wrote: > Signed-off-by: Jacek Caban
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_
On 2018/1/12 4:28, Jacek Caban wrote: > > Fixes compilation with clang. > >
Signed-off-by: Jacek Caban
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/s
On 2017/12/18 3:43, Martin Storsjö wrote: > Since long double just is normal
double on arm and arm64, just > call the normal ldexp function. > >
Signed-off-by: Martin Storsjö
> --- > Fixed the parameters in the C wrappers. > --- >
> mingw-w64-crt/Makefile.am | 3 ++- > mingw-w64-crt/ma
On 2017/6/12 23:24, Martell Malone wrote:
> In this thread https://sourceforge.net/p/mingw-w64/bugs/459/
> there is a suggested fix for print with whole numbers
>
> The builtin __mingw_printf is inconsistent with printf on %a format.
>> I think __mingw_printf is wrong, because obviously 1.0 != 0x0
On 2017/2/7 0:26, Hannes Domani wrote:
> Hello
>
>
> Does delay-loading work with 32bit executables?
>
> In the following example it crashes for me on the dll_function() call.
> I've used i686-6.3.0-release-win32-dwarf-rt_v5-rev1.7z for my tests.
I compiled the program and it did crash. The assembl
On 2017/1/26 19:00, Petri Hodju wrote:
> Hi!
> I ran to the same problem earlier and I posted patches here on the
> list on 2nd December 2016 for this problem.
> In short, the CompPtr has specialized constructors that can't access
> the protected members as they are not working on class level. The
On 2017/1/23 9:08, David Wohlferd wrote:
> Hmm.
>
> It seems a bit backwards to have the function that takes a 'long double'
> calling the function that takes a 'double.' Yes, they are both the same
> size on ARM, but I think I would have gone the other way. Plus I kinda
> like having all the imp
The mail has been being rejected for spamming for a few hours.
Hope it wouldn't be this time.
--
Best regards,
lh_mouse
From 82fd24e992a402ff2f7c55780fd76945ef83e094 Mon Sep 17 00:00:00 2001
From: LH_Mouse
Date: Wed, 18 Jan 2017 19:35:43 +0800
Subject: [PATCH] mingw-w64-crt/math/fma{,f,l}.
> So you have decided that __builtins can't be used then? That's too bad.
Yes it results in a call to `fma()` on x64. Can't test it on ARM though.
> I know almost nothing about the guts of floating point, so I'm prepared
> to defer to your judgement, but here's what I think:
>
> Let me propose a
New patch attached.
This patch fixes ARM functions and adds a check in `fpu_fma()` for potential
NaN or INF results.
--
Best regards,
lh_mouse
2017-01-19
From 3c55daec84dac190b9e3cb032371960e1acbc38f Mon Sep 17 00:00:00 2001
From: LH_Mouse
D
> I see that you have replaced the x86 parts for fma and fmaf with C
> code. That seems like a good thing. Is there some reason you can't do
> that with the ARM versions too?
ARM has hardware FMA and software emulation is not optimal.
> Reducing the amount of platform-specific code also seems
The correctness of fma() function can be verified using the following program:
---
#include
#include
volatile double x = 0x1.3p52;
volatile double y = 0x1.5p52;
volatile double z = -0x1.8p104;
int main(){
Patch is attached.
This patch removes assembly files that implement FMA on ARM and merges
them into the corresponding C files with the same name using inline assembly.
A re-generation of Makefile.in is required.
I don't have any knowledge about ARM assembly. Those functions for ARM
were created us
That might be because gcc has its own float.h:
/mingw32/lib/gcc/i686-w64-mingw32/6.2.1/include/float.h:113:#define FLT_EPSILON
__FLT_EPSILON__
--
Best regards,
lh_mouse
2016-12-20
-
发件
See comments about --enable-auto-import on
https://www.sourceware.org/binutils/docs/ld/Options.html .
When you refer to a member of a struct or array with static storage duration,
the compiler may generate instructions to read from or write to a constant
address that compares unequal to the addres
> I'd probably create a new exception handling model and conditionalize
> whatever code you need based on that.
That would require copy-n-paste of tons of code...
All this remains contingent on Microsoft's generosity because
they don't provide APIs for SEH on x86, unlike on x64.
So I have to reu
Hi there,
I come up with an idea about implementing stack unwinding for
the i686-w64-mingw32 target using native Windows Structured
Exception Handling (a.k.a SEH) for efficiency reasons.
Unlike DWARF and SEH for x64, SEH for x86 is stack-based
and works like the SJLJ exception model: The operatin
he DLL must not be removed.
--
Best regards,
lh_mouse
2016-10-14
-----
发件人："lhmouse"
发送日期：2016-10-14 01:21
收件人：Msys2,mingw-w64-public
抄送：
主题：[Msys2-users] Bootstrap gcc for i686 wit
Today I tried bootstrapping GCC 6.2.1 using PKGBUILD modified from
the MSYS2 one for gcc-git package.
I changed the line
https://github.com/lhmouse/MINGW-packages/blob/master/mingw-w64-gcc-git/PKGBUILD#L148
from `local _conf="--disable-sjlj-exceptions --with-dwarf2"`
to `local _conf
quo()`?
Hello Lefty!
I do think you have found a bug here, and it does appear to
be in the mingw-w64 code. Disclaimer: I don't understand
this completely.
Further comments in line, below.
On Tue, Sep 6, 2016 at 11:52 PM, lhmouse wrote:
> More likely a bug in mingw-w64:
>
&g
Please discard the previous patch as it does not handle denormal numbers
correctly.
Sorry for that.
---
>From 890aab4fc63264074b6e1e16f5bd64e3c4a6f795 Mon Sep 17 00:00:00 2001
From: lhmouse
Date: Fri, 9 Sep 2016 22:52:26 +0800
Subject: [PATCH] Added standard-conforming fmaf(), fma() and f
>From 52dd6b38d01e1f30bf1821a2621d707d07ec8f15 Mon Sep 17 00:00:00 2001
From: lhmouse
Date: Fri, 9 Sep 2016 22:52:26 +0800
Subject: [PATCH] Added standard-conforming fmaf(), fma() and fmal() functions.
Signed-off-by: lhmouse
---
mingw-w64-crt/Makefile.am | 4 +--
mingw-w64-crt/math/fm
n", 0x5p-80l);
}
E:\Desktop>gcc test.c -std=c99
E:\Desktop>a.exe
0x0p-141
Removing the `__mingw_` prefix and testing the same program
on Linux gives the correct result:
lh_mouse@lhmouse-dev:~$ uname -a
Linux lhmouse-dev 3.16.0-4-amd64 #1 SMP Debian 3.
Oops. Are there any volunteers to implement `fma()` functions for ARM ?
--
Best regards,
lh_mouse
2016-09-08
--
___
Mingw-w64-pub
---
mingw-w64-crt/Makefile.am | 4 ++--
mingw-w64-crt/math/fma.S | 42
mingw-w64-crt/math/fma.c | 12 ++
mingw-w64-crt/math/fmaf.S | 43 -
mingw-w64-crt/math/fmaf.c | 10
mingw-w64-crt/math/fmal.c | 61 +++
送：
主题：Re: [Mingw-w64-public] sinl/cosl/tanl accuracy problem
On 07.09.2016 17:21, lhmouse wrote:
> (I don't write AT&T assembly so I am unable to make a patch.
> Nevertheless I hope someone who writes AT&T assembly could fix it.)
I don't have time to write a patch but I c
n can be found here:
https://github.com/lhmouse/MCF/blob/master/MCFCRT/src/stdc/math/fma.c
--
Best regards,
lh_mouse
2016-
It is merely a function guaranteed to be declared implicitly
(thus requires no ) and has the same semantics with
the standard function `sinl()`. The GCC optimizer can perform
certain types of optimization such as constant folding and inlining
only if `fsinl()` is supposed to do the same thing as sp
If performance is the problem there are a number of solutions such as
inline assembly, static lookup tables, etc. `fsinl()` is apparently not one
of them.
But yes, I am all ears
--
Best regards,
lh_mouse
2016-09-08
---
6Le\n", my_sinl(theta));
It produces the following result:
sinl (theta) = 1.6263032587282567e-019
my_sinl(theta) = -0.e+000
My implementation could be found here:
https://github.com/lhmouse/MCF/blob/master/MCFCRT/src/stdc/math/sin.c#L12
static inline
More likely a bug in mingw-w64:
#include
#include
volatile double x = 10.001000, y = -1.299000;
int main(){
int quo;
double rem = remquo(x, y, &quo);
printf("rem = %f, quo = %d\n", rem, quo);
}
With mingw-w64 this program gives the following output:
The disagreement of glibc and mingw-w64 (in my opinion) is definitely glibc's
bug:
lh_mouse@lhmouse-dev:~$ cat test3.c
#include
#include
int main(){
double x = 10.001000;
double y = 0.701000;
int quo;
double rem = rem
----
发件人："lhmouse"
发送日期：2016-09-05 22:27
收件人：mingw-w64-public
抄送：
主题：[Mingw-w64-public] Wrong quotient results of `remquo()`?
Hello guys,
I am testing my `remquo()` implementation when I find that `remquo`
on Linux (using glibc) and on Windows (using mingw-w64) generate
different r
Hello guys,
I am testing my `remquo()` implementation when I find that `remquo`
on Linux (using glibc) and on Windows (using mingw-w64) generate
different results. I don't think this is the correct behavior. Any ideas?
The testcases in file `remquo.txt` the attached zip file was generated
on my VP
I haven't had a deep look at the patch, but AFAICS the problem is a simple
matter
that can be solved by adding `-nostdinc
-I"path/to/the/directory/of/new/headers"`
to `CPPFLAGS` when building the CRT.
--
Best regards,
lh_mouse
2016-08-26
--
high performance
are available from the mcfgthread library https://github.com/lhmouse/mcfgthread
.
The mcfgthread library is unable to be linked against statically at the moment.
Due to incompleteness of testing, these toolchains are highly experimental.
Please send comments and bug reports to
Hello all,
GCC 6.2 has been release today and new toolchains targeting i686 and x86_64
are now available. Pre-built binaries can be found just under the description on
https://github.com/lhmouse/mcfgthread. (SF was rejecting this mail because of
possibility
of spamming so I have to put the link
GCC (but not G++) doesn't enable this warning unless requested with
`-Wstrict-prototypes` explicitly.
--
Best regards,
lh_mouse
2016-08-22
-
发件人：David Wohlferd
发送日期：2016-08-22 11:20
收件人：mi
SSE2 is mandatory on x64.
On x86 you probably want to take a look at Vectored Exception Handling
which needs no compiler specific magic. However the canonical way to
test a CPU for SSE support would be using the CPUID instruction.
--
Best regards,
l
43 matches
Mail list logo
