allocation can still dominate computation, and a small-string-like
optimization can help significantly (see Boost.Multiprecision's cpp_int).
Again, a one-size-fits-all seems optimistic.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https:
of resources in continuous integration (why would people bother
optimizing this as long as it works?). A mirror is probably less work than
what it saves, and pushes the problem to someone else (github).
Of course that's assuming the current issue is indeed a very wasteful CI
setup.
--
Marc
if people didn't set up their CI in such a wasteful way, but the trend
doesn't make me very optimistic.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
If nobody complains and I don't see something horribly flawed in the
patch, I am going to push this version, which for now only adds
initialization and assignment from long long when in C++11 mode (I expect
we will remove support for C++ compilers without long long in the next
release, but for
was desirable.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
++ support has been enabled
+(@pxref{Build Options}). For example,
@example
g++ mycxxprog.cc -lgmpxx -lgmp
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
tps://gmplib.org/mailman/listinfo/gmp-devel
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Fri, 11 Jun 2021, Emmanuel Thomé wrote:
On Thu, Jun 10, 2021 at 03:02:25PM +0200, Marc Glisse wrote:
On Thu, 10 Jun 2021, Emmanuel Thomé wrote:
> And as it turns out, we even discussed that very documentation bit about
> three years ago (here a link to an actual patch -- or
?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Wed, 9 Jun 2021, Marco Bodrato wrote:
Il 2021-05-12 15:17 Marc Glisse ha scritto:
the latest version of gcc has a new (questionable) warning that
complains if a function is declared as taking a mpz_t parameter and
redeclared as taking mpz_ptr, or the reverse.
We might as well be consistent
Hello,
I am tempted to go with something like the attached patch to support long
long in gmpxx.h. (the patch is not quite ready)
Essentially, it adds a way to build mpz_class from long long, and for all
other operations, long long is converted to long if it fits and to
mpz_class otherwise. So
Hello,
the latest version of gcc has a new (questionable) warning that complains
if a function is declared as taking a mpz_t parameter and redeclared as
taking mpz_ptr, or the reverse.
We might as well be consistent and use pointers everywhere, as in the
attached patch. Does someone
GMP, you can also get some information with `pkg-config --libs
gmp` (or other options than --libs), but that requires that the .pc file
be in PKG_CONFIG_PATH, which just shifts the issue.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
ht
t.
Trying to use CONFIG_SITE directly would be messy. An alternative would be
to guess that if there is only one subdirectory lib* in prefix, that might
be it, or try each lib* until one works, hoping that the name never gets
weirder. You could also complain to SUSE...
--
Marc Glisse
_
On Fri, 26 Feb 2021, Paul Zimmermann wrote:
on the gcc118 machine from the gcc compile farm, with gmp-6.2.1, make install
puts the libgmp.{a,so} files in $PREFIX/lib64 instead of $PREFIX/lib. Is there
any reason for that?
/usr/share/site/aarch64-unknown-linux-gnu does it?
--
Marc Glisse
On Mon, 17 Feb 2020, Marco Bodrato wrote:
Ciao,
Il 2020-02-17 20:34 Marc Glisse ha scritto:
easiest would be to rename the test from bit to something less common.
Do you mean that we should
$ hg rename tests/mpz/bit.c tests/mpz/t-bit.c
$ sed -i orig 's/ bit / t-bit /' tests/mpz/Makefile.am
On Mon, 17 Feb 2020, Torbjörn Granlund wrote:
Marc Glisse writes:
It looks like there is now a standard header called . We also
have a test bit.c that compiles to bit. And we have a -I flag pointing
to the location of this second bit file. Now, when clang sees #include
inside the libc
++ headers, it finds this binary file instead of the
standard header. I think we should fix that on the GMP side. The easiest
would be to rename the test from bit to something less common.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
g, and ensure we
get only a single branch.
On x86_64, both gcc and clang optimize (usize > vsize) ? 1 : -1 to 2 *
(usize > vsize) - 1 (as a single LEA for gcc, 2 ADD for llvm). So the
generated code may be just as good with the simple code.
--
Marc Glisse
__
ignore that unless we notice a
regression.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
, either
Libs: -L${libdir} -lgmpxx -lgmp
or
Libs: -L${libdir} -lgmpxx
Libs.private: -lgmp
?
I assume that "Requires: gmp" already handles that.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/li
, possibly libtool-related.
IIRC -lm is used in the build, the tuning, the tests, the demos, but not
in the library itself.
(the use in tests/cxx looks bad, it does -lm instead of using the result
of autoconf)
--
Marc Glisse
___
gmp-devel mailing list
<< that seems unlikely to compile.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Sun, 16 Jun 2019, Niels Möller wrote:
Marc Glisse writes:
https://github.com/sethtroisi/libgmp/pull/5.diff (or .patch for a
different format). AFAIK you have to modify the URL by hand...
But that gives me a sequence of patches, not a single patch ("squashed",
in git terms) re
mmand line instead of going though the
web interface)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Wed, 23 May 2018, Marco Bodrato wrote:
From gmp-discuss:
Il Lun, 21 Maggio 2018 12:15 pm, Marc Glisse ha scritto:
If m is a
moved-from object, it is fine to assign a new value to it with m =
whatever. That's even what std::swap does. It should also be fine to
read from it, although you
don't get too confused about what they should use
and when.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Tue, 15 May 2018, Marco Bodrato wrote:
Ciao Marc,
Il Lun, 19 Febbraio 2018 5:24 pm, Marc Glisse ha scritto:
On Mon, 19 Feb 2018, Marco Bodrato wrote:
mpq_get_d currently gives a double, but rounded towards zero...
Except when it uses the broken generic code :-(
If you want, you can
On Fri, 27 Apr 2018, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
There would be a significant advantage to mpq if we could have a
non-allocated 1 for the denominator. But indeed, with the current code
where only some mpz functions would work, it seems safer to do
, with the current code
where only some mpz functions would work, it seems safer to document that
none work.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Fri, 27 Apr 2018, Marc Glisse wrote:
On Fri, 27 Apr 2018, paul zimmermann wrote:
quite interesting. Why is gmp/mpn not tested in the head coverage?
It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of
symlinks created at build time.
sorry I missed that. I see some
(add_err3_n.c for example), and some have a low coverage (div_qr_1.c
for example). Are there any plans to improve that?
Even for the generic files, the coverage varies per target, maybe
add_err3_n is better tested on ARM or something (not really answering your
question).
--
Marc Glisse
.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
to think of things lying around that would be easy / safe to
push)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Fri, 20 Apr 2018, Marc Glisse wrote:
On Fri, 20 Apr 2018, Marc Glisse wrote:
On Fri, 20 Apr 2018, Marc Glisse wrote:
On Fri, 20 Apr 2018, Vincent Lefevre wrote:
On 2018-04-20 04:14:15 +0200, Fredrik Johansson wrote:
For operands with 1-4 limbs, that is; on my machine, mpn_mul takes up
On Fri, 20 Apr 2018, Marco Bodrato wrote:
Il Ven, 20 Aprile 2018 12:39 pm, Marc Glisse ha scritto:
I just tried (LTO+PGO) on a trivial testcase, and gcc didn't manage to do
anything clever with it. Doing it by hand to see how much potential gain
there is, the timings are:
mpn_mul: .56
On Fri, 20 Apr 2018, Marc Glisse wrote:
On Fri, 20 Apr 2018, Marc Glisse wrote:
On Fri, 20 Apr 2018, Vincent Lefevre wrote:
On 2018-04-20 04:14:15 +0200, Fredrik Johansson wrote:
For operands with 1-4 limbs, that is; on my machine, mpn_mul takes up to
twice as long as mpn_mul_basecase
On Fri, 20 Apr 2018, Marc Glisse wrote:
On Fri, 20 Apr 2018, Vincent Lefevre wrote:
On 2018-04-20 04:14:15 +0200, Fredrik Johansson wrote:
For operands with 1-4 limbs, that is; on my machine, mpn_mul takes up to
twice as long as mpn_mul_basecase, and inline assembly for 1x1, 2x1 or 2x2
t seem realistic in an application). What could
happen is partial inlining of the first test of each. Maybe using LTO+PGO
(profile-guided optimization)? Still, I am not particularly optimistic.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
or Marco's patch.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Fri, 20 Apr 2018, Marco Bodrato wrote:
Ciao,
Il Gio, 19 Aprile 2018 4:37 pm, Marc Glisse ha scritto:
I finally pushed it. It seemed unsafe to keep mpq unaware of lazy
allocation, in case people start swapping the numerator of a rational with
a lazy 0 integer or something like that.
If we
On Mon, 11 Apr 2016, Marc Glisse wrote:
On Mon, 9 Nov 2015, Marco Bodrato wrote:
Moreover, the mpq layer and mini-gmp need to migrate to lazy allocation
too...
For mpq, the attached seems sufficient to pass make check.
I finally pushed it. It seemed unsafe to keep mpq unaware of lazy
doubts? To clarify, allocation would work like
void *ptr = malloc (... + sizeof (size_t));
->_mp_d = (char *)ptr + sizeof (size_t);
size_t *size = ptr;
if you think the pointer arithmetic on _mp_d is problematic you can
always go through uintptr_t ...
IIRC that's roughly what MPFR does.
--
Ma
compilers. Or we arm autoconf to probe for this too, and stay away from
stdint.h.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Sat, 17 Mar 2018, Vincent Lefevre wrote:
On 2018-03-16 22:22:39 +0100, Marc Glisse wrote:
On Fri, 16 Mar 2018, Marco Bodrato wrote:
float.h was defined by C99, right?
I am pretty sure it was already in C89.
Yes, but was DBL_MANT_DIG necessarily an integer constant expression
(in case
On Fri, 16 Mar 2018, Marco Bodrato wrote:
float.h was defined by C99, right?
I am pretty sure it was already in C89.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
that they are only supported with a standard float.h
header. Or just assume that float.h is always available nowadays. Or even
assume that all double are 64-bit binary IEEE numbers...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org
to detect that it *is* IEEE. For instance when compiling to bitcode
(gcc LTO, LLVM, webassembly, etc). Of course, better IEEE detection would
help those more than fixing the fallback path.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
On Tue, 6 Mar 2018, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
On Tue, 6 Mar 2018, Marco Bodrato wrote:
Which solutions do you suggest? I see 3 possible ways:
- removing the non "fully compatible" functions;
- adding them to the "with a few
nstance last October, the generic, non-IEEE version of
mpn_get_d has a similar issue. Maybe they could both be fixed at the same
time with the same code?
Obviously this assumes that someone can find time to do it... Otherwise, I
guess that option 2 could do, until a volunteer appea
. If we wanted to, we could also specialize the
test q == 0 (and q < 0), which is probably common enough, but that's
independent, and a negligible gain.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listi
On Tue, 27 Feb 2018, Marco Bodrato wrote:
Il Mar, 27 Febbraio 2018 8:22 pm, Marc Glisse ha scritto:
If I write q = 1 + 1 / q, gmpxx currently generates:
mpq_inv(q, q);
mpz_addmul_ui(num, den, 1);
Not quite optimal yet :-(
May the following help?
Something like that, yes. But it feels like
)
{ mpz_add(mpq_numref(q), mpq_numref(q), mpq_denref(q)); }
static void eval(mpf_ptr f) { mpf_add_ui(f, f, 1); }
};
If I write q = 1 + 1 / q, gmpxx currently generates:
mpq_inv(q, q);
mpz_addmul_ui(num, den, 1);
Not quite optimal yet :-(
--
Marc Glisse
__assume_aligned on the target of memset).
The GCC manual mentions a __builtin_memset
builtin, though I don't know what it does exactly.
That's how a regular call to memset is encoded internally... For small
constant sizes, it may be expanded inline, but usually it remains a call
to memset.
--
Marc
mpn_zero...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Mon, 5 Feb 2018, Win C wrote:
int main()
{
int i;
mp_limb_t *pi = malloc(16);
That's not nearly enough, the code crashes for me.
$./zeroing
73491
17651
Try testing xor before zero...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel
to
have to install the mpfr dependency anyway, his project is not
self-contained, so he might as well install the real GMP.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Sat, 28 Oct 2017, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
2) The rounding occurs in the addition in
weight = 1/MP_BASE_AS_DOUBLE;
d = up[size - 1];
for (i = size - 2; i >= 0; i--)
{
d += up[i] * weight;
build and the 32-bit
build? (doing the build out-of-tree avoids this kind of problem, since
you can easily do the 32-bit build in a different directory)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
half of the source and
stores it to the lower half of the destination, it doesn't touch the rest,
so exceptional condition because of the rest seems unlikely. On the other
hand, false dependencies are possible and can affect performance.
--
Marc Glisse
ou cannot really support t==NULL
without supporting s==NULL. You may prefer not documenting it though...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
a user. If
you want to rewrite it to clarify that the gains aren't much, please go
ahead...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Fri, 25 Nov 2016, Marc Glisse wrote:
On Mon, 21 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
On Sun, 20 Nov 2016, Niels Möller wrote:
> It would make sense to test both gmp and mini-gmp with
> -fsanitize=undefined.
If we are not already d
On Fri, 25 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
Fixed. It was unhappy about (-13) << 2. I am a bit surprised it
doesn't complain about (-13) >> 2 on the next line, we'll see if it
ever becomes an issue.
This must be a compiler
On Fri, 25 Nov 2016, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
a user was asking if we could support calling mpz_gcd_ext with a NULL
first argument (the gcd), since they are only interested in the
coefficients s and t and would like to save the unnecessary
allocat
On Mon, 21 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
On Sun, 20 Nov 2016, Niels Möller wrote:
> It would make sense to test both gmp and mini-gmp with
> -fsanitize=undefined.
If we are not already doing it, yes, I highly recommend it
On Sun, 20 Nov 2016, Niels Möller wrote:
It would make sense to test both gmp and mini-gmp with
-fsanitize=undefined.
If we are not already doing it, yes, I highly recommend it.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https
On Sun, 20 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
After inlining, there are subtractions. check_si is called at least
once with oi = si + c (c is ±1). gcc simplifies the test si > si - 1
Inlining of check_si?
Of all the functions. (note
> si - 1 to true,
and warns that this optimization may break your program if you rely on
wrapping. The usefulness of such a warning is debatable, and we tend to
drop some of them from gcc when we think nobody will notice.
--
Marc Glisse
___
g
ling comma in enum hex_random_op)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
-liner, we may also need a
copyright assignment.
Are there easy ways to test GMP on fuchsia? One of the most convenient
things for developers is when there is a machine (possibly virtual)
available in the gcc compile farm.
--
Marc Glisse
___
gmp-devel
On Sat, 5 Nov 2016, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
Uh? I have 2 very natural use cases for libgmp.a:
1) to build a static (or at least with few dependencies) executable
that I am going to send to someone else [...]
2) I am rebuilding GMP on my sp
of it (I might even want to use LTO in that case,
although IIRC it currently causes some trouble in configure).
Note that I do not care about security in either case.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman
the overhead of a few calls shouldn't matter
that much.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
so well in previous releases, so it may indeed be
unnecessary to support the old syntax.
Does that make sense or did I misunderstand something? I'll probably push
the patch in a few days, when I get the chance.
--
Marc Glisse
___
gmp-devel ma
ejected
with a recent gcc? Do they mean the same thing?
I trust that you know what you are doing, I just like to understand a
patch before applying it.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Wed, 4 May 2016, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
The fact that an mpq is made of 2 mpz that can be accessed directly is
part of the interface. I think following your suggestion would mean
changing that.
I guess you're right, it would break mpq_denref.
enominator means "this is an integer",
and treated as one.
The fact that an mpq is made of 2 mpz that can be accessed directly is
part of the interface. I think following your suggestion would mean
changing that.
--
Marc Glisse
___
gmp-de
On Mon, 9 Nov 2015, Marco Bodrato wrote:
Moreover, the mpq layer and mini-gmp need to migrate to lazy allocation
too...
For mpq, the attached seems sufficient to pass make check. Of course,
without a copy-on-write mechanism for the 1 in the denominator, the gains
are not comparable to the
to a throwing mpz_init would be an ABI break.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
ations.
If this is for the development of free software, the GCC compile farm
includes some aarch64 machines on which you could experiment.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Mon, 21 Mar 2016, Vincent Lefevre wrote:
On 2016-03-20 12:14:49 +0100, Marc Glisse wrote:
but it seems likely that a user who went to the trouble of disabling
assembly for GMP doesn't want to use that same assembly in MPFR.
I'm not so sure about that. AFAIK, longlong.h has far less asm
On Sun, 20 Mar 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
One issue with changing it is MPFR: src/mpfr-longlong.h tests for
NO_ASM, but there is no code to define it. As far as I understand,
MPFR uses __GMP_CFLAGS by default, in which GMP may have in
On Sun, 20 Mar 2016, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
when configure wants to define a macro, it usually puts it in
config.h. We do have one exception: NO_ASM, which ends up defined in
CFLAGS. Was there a particular reason for this choice?
I'm greping f
mpz_import_file (b, f);
mpz_import_file (c, f);
fclose (f);
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
trying to clarify why each
type is used (unsigned long is mp_bitcnt_t in some places, mp_builtin_ui
in others, etc).
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Fri, 21 Aug 2015, Marco Bodrato wrote:
On Thu, August 20, 2015 9:56 am, Marc Glisse wrote:
Is casting an mpz to an mpq, then accessing only the NUM() part of it,
portable?
From what I understand of the aliasing model currently used by gcc, to
be safe, in the function using it, we should
)op2 is a safer way to do the same
thing as NUM(op2) in this case.
(I am not suggesting changing the gmp-impl implementation of NUM to a
cast)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
.
On Thu, 20 Aug 2015, Torbjörn Granlund wrote:
(We might consider adding mpf_cmp_z too, at least in a simple-minded
manner, to keep the GMP interface as orthogonal as possible.)
Adding new mpf_t functions might confuse the message that people should
use mpfr...
--
Marc Glisse
On Thu, 21 May 2015, Marc Glisse wrote:
On powerpc-linux-gnu, clang complains about the bc+ instruction, and
indeed I can't find that in IBM's documentation. After removing
divrem_2.asm, it compiles fine and passes the testsuite.
Now I've found it (and reported
https://llvm.org/bugs
On Mon, 25 May 2015, Torbjörn Granlund wrote:
Marc Glisse marc.gli...@inria.fr writes:
Now I've found it (and reported
https://llvm.org/bugs/show_bug.cgi?id=23646 ). Note that the same (?)
instruction is spelled differently in the same file:
bc+ 12, 28, L(9)
vs.
blt
On Mon, 25 May 2015, Marc Glisse wrote:
On Mon, 25 May 2015, Torbjörn Granlund wrote:
Marc Glisse marc.gli...@inria.fr writes:
Now I've found it (and reported
https://llvm.org/bugs/show_bug.cgi?id=23646 ). Note that the same (?)
instruction is spelled differently in the same file
with extra warnings in the release notes or some such
place. But again, your call.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Mon, 2 Feb 2015, Torbjörn Granlund wrote:
Does MIPS64r6 contain all older architecture revisions as a subset,
Apparently not, the motivation for the patch is that multu has
disappeared...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel
that pointer may abort the program.
In such a setting, all of this memory-related error handling
stuff is pointless]
Yes. Memory overcommit can often be disabled or mitigated in various
ways, but it does complicate things (get a better OS ;-)
--
Marc Glisse
, static_castunsigned long(l));
}
static void eval(mpz_ptr z, double d)
{ __GMPXX_TMPZ_D;eval (z, temp); }
};
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Hello,
this patch moves deallocation of temporary memory to a destructor when GMP
is compiled with a C++ compiler. This may not be the final form of the
patch, but I am interested in comments. Most of the patch is adjustments
to tests/mpn so that temporary memory is freed before calling
be possible to test this in configure.
I don't know how relevant armv5 is to GMP though.
(I also killed lt-reuse after 5 minutes, but it might just be that long)
-stdlib=libc++ testing is complicated because of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771512
--
Marc Glisse
, or hopefully
just a few places)?
I am surprised google didn't point you to:
https://gmplib.org/list-archives/gmp-discuss/2009-May/003733.html
Apparently, I had only found one at the time, and I doubt we introduced
many since. But I could have missed other places.
--
Marc Glisse
it makes the
interface simpler.
+ ASSERT (d != 0.5*d);/* Exclude infinities */
That excludes more than infinities, it might also exclude FLT_TRUE_MIN,
no?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org
1 - 100 of 153 matches
Mail list logo
