Vincent Lefevre writes:
One of those who saw the bug with MPFR 4 RC1 + GMP dev said that
everything seems fine with the latest GMP dev:
https://sympa.inria.fr/sympa/arc/mpfr/2017-12/msg00067.html
Thanks.
--
Torbjörn
Please encrypt, key id 0xC8601622
_
Updated GMP sources to r17506.
MPFR (r11929) builds with GMP using with
configurations finished successfully and all
tests, including previously failed, passed for both libraries. Thank you for
fix!
--- Оригінальне повідомлення ---
Від кого: "Torbjörn Granlund"
Дата: 15 грудня 2017, 01:0
On 2017-12-15 00:00:40 +0100, Torbjorn Granlund wrote:
> It is a flaw in our testing setup that this calling convention breach is
> not caught by the automated testing. I will fix both bugs. :-)
>
> I have now pushed a fix for the mainline repo. Testing would be
> appreciated!
One of tho
It is a flaw in our testing setup that this calling convention breach is
not caught by the automated testing. I will fix both bugs. :-)
I have now pushed a fix for the mainline repo. Testing would be
appreciated!
Improving test suite calling conventions checks (through
tests/x86call.a
Vincent Lefevre writes:
There appears to be a bug in mpn/x86_64/fastsse/com-palignr.asm,
which is now used by the GMP trunk. If I understand correctly,
the optimized loop uses xmm6 and xmm7 without restoring their
values. This is correct under Linux, but not under MS Windows,
You are rig
There appears to be a bug in mpn/x86_64/fastsse/com-palignr.asm,
which is now used by the GMP trunk. If I understand correctly,
the optimized loop uses xmm6 and xmm7 without restoring their
values. This is correct under Linux, but not under MS Windows,
according to:
https://en.wikipedia.org/wik
