Ciao,
Il Ven, 8 Giugno 2012 10:28 pm, Marc Glisse ha scritto:
((mp_ptr) res)[0] = ~ ((mp_ptr) res)[ALLOC (z) - 1];
Won't valgrind complain about an uninitialized read here?
It shouldn't! I read from the manual of Valgrind:
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.uninitvals
On Sat, 9 Jun 2012, bodr...@mail.dm.unipi.it wrote:
Won't valgrind complain about an uninitialized read here?
It shouldn't! I read from the manual of Valgrind:
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.uninitvals
It is important to understand that your program can copy around
Torbjorn Granlund wrote:
I started a page: http://gmplib.org/devel/incompatibility.html
We might want to classify incompatibilities as source, binary, and both.
I have not listed obsolete functions. The cost of retaining obsolete
function compatibility is very low; the temptation to
Ciao,
Il Lun, 4 Giugno 2012 6:32 pm, Torbjorn Granlund ha scritto:
Pedro Gimeno p.gim...@formauri.es writes:
Also, I seem to remember there were plans to make a new version of
mpz_nextprime accepting a random state and the number of M-R tests, and
of mpz_probab_prime_p accepting a
ni...@lysator.liu.se (Niels Möller) writes:
The old_size argument should be removed also from the free function, not
just realloc.
Fixed.
Add return value to mpz_sqrt, for consistency with mpz_root (assuming
such a flag can be returned very cheaply, which I think it can).
Added.
Torbjorn Granlund wrote:
Pedro Gimeno p.gim...@formauri.es writes:
My recollection is that gmp_errno was not thread-safe, not just
obsolete, and that that was a reason for getting rid of it.
Making some C error handling mechanism would be great, though. I am not
sure that's easy,
Torbjorn Granlund t...@gmplib.org writes:
Last time you suggested this, I think I asked you to explain how to do
with the multitude of multiply functions, which might need to store the
full n-limb value in a new large temp area, then copy its low n-1 limbs
to the target area.
One would have
On Mon, 4 Jun 2012, Torbjorn Granlund wrote:
Pedro Gimeno p.gim...@formauri.es writes:
My recollection is that gmp_errno was not thread-safe, not just
obsolete, and that that was a reason for getting rid of it.
If the main issue with gmp_errno is thread-safety, it should just become
Torbjorn Granlund t...@gmplib.org writes:
I know of only two C mechanims, either signals+handlers or setjmp+
longjmp.
I'm not entirely sure what type of errors you are considering handling
here? Memory allocation failures? Divide-by-zero? Something else?
It's possible to make errno-style
ni...@lysator.liu.se (Niels Möller) writes:
The point, as I understand it, is to collect various problems where the
fixes imply interface changes, and which hence are not going to happen
in any release currently planned. So we don't forget them, if/when we
ever to planning a release which
On Sun, 3 Jun 2012, Niels Möller wrote:
Add return value to mpz_sqrt, for consistency with mpz_root (assuming
such a flag can be returned very cheaply, which I think it can).
Naive question:
are there many ABIs where adding a return type breaks compatibility?
--
Marc Glisse
Marc Glisse marc.gli...@inria.fr writes:
Naive question:
are there many ABIs where adding a return type breaks compatibility?
Probably few. But it breaks source code compatibility, if it is called
via a typed function pointer. Our own tests/mpz/reuse.c would need
modifications...
--
Ciao,
Il Sab, 2 Giugno 2012 6:32 pm, Niels Möller ha scritto:
Torbjorn Granlund t...@gmplib.org writes:
I thought avoiding the copying was a good idea, but this thread has made
me less sure.
I guess some benchmarks are needed here.
That's why I did not propose to change the behavior of the
On Fri, 1 Jun 2012, bodr...@mail.dm.unipi.it wrote:
- should we ask for a fourth function (alloc, free, conservative_realloc,
nonconservative_realloc)?
If the usual allocators don't provide it, it is inconvenient to require
it (I know this is a chicken and egg thing...). By conservative, do
Ciao!
Il Ven, 1 Giugno 2012 9:16 am, Marc Glisse ha scritto:
On Fri, 1 Jun 2012, bodr...@mail.dm.unipi.it wrote:
- should we ask for a fourth function (alloc, free,
conservative_realloc,
nonconservative_realloc)?
If the usual allocators don't provide it, it is inconvenient to require
Both
Ciao,
I'm looking inside the mpq directory, to perform something similar to
Torbjorn's change mpz: Use MPZ_REALLOC return value when possible,
that's why I revive an old question...
Il Ven, 24 Febbraio 2012 12:32 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
I always
bodr...@mail.dm.unipi.it writes:
Do you mind if I define a new macro MPZ_NEWALLOC?
Currently it should be the same as MPZ_REALLOC, but it can be changed in
the future...
To me it would make some sense to make it do something useful right
away...
You'd also need a corresponding function
On Thu, 31 May 2012, Niels Möller wrote:
bodr...@mail.dm.unipi.it writes:
Do you mind if I define a new macro MPZ_NEWALLOC?
Currently it should be the same as MPZ_REALLOC, but it can be changed in
the future...
To me it would make some sense to make it do something useful right
away...
Il Mer, 22 Febbraio 2012 8:32 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Unrelated :-) We might define more macros like TMP_ALLOC_LIMBS_2 . I
Please look at the generated code from TMP_ALLOC from any reasonable
compiler. It is a sub from sp, the a copy from sp to
ni...@lysator.liu.se (Niels Möller) writes:
Torbjorn Granlund t...@gmplib.org writes:
Surely a plain TMP_ALLOC adds red zones? If not, that is something we
ought to fix.
But
tp = TMP_ALLOC_LIMBS (2*n);
xp = tp + n;
does not add any between T and X (intended to
ni...@lysator.liu.se (Niels Möller) writes:
What about the test in
#define TMP_ALLOC(n) \
(LIKELY ((n) 65536) ? TMP_SALLOC(n) : TMP_BALLOC(n))
That test will cost a cycle or two for each TMP_ALLOC call (with
non-constant n), regardless of size, won't it?
I think my previous
Ciao,
Il Ven, 24 Febbraio 2012 10:40 am, Torbjorn Granlund ha scritto:
I cannot see how TMP_ALLOC_LIMBS_2 could save *anything* for small
I'm not sure I agree with Torbjorn. Nevertheless developers time is a far
more precious resource than a few cpu cycles or bytes of code size...
That's why I
Hello,
is there any objection if I replace most uses of -_mp_alloc by calls to
the ALLOC macro in mp[zqf] (and similarly for _mp_size, etc)? It helps
when experimenting... I am also considering moving the NUM and DEN macros
from test/mpq/t-cmp* to gmp-impl.h, since I assume mpq_numref and
Marc Glisse marc.gli...@inria.fr writes:
is there any objection if I replace most uses of -_mp_alloc by calls
to the ALLOC macro in mp[zqf] (and similarly for _mp_size, etc)? It
helps when experimenting... I am also considering moving the NUM and
DEN macros from test/mpq/t-cmp* to
Ciao,
Il Mer, 22 Febbraio 2012 7:41 pm, Torbjorn Granlund ha scritto:
Marc Glisse marc.gli...@inria.fr writes:
their length. By the way, is there any difference between PTR and
LIMBS? Say one that should be used in some circumstances and one in
others?
You're welcome to clean up
bodr...@mail.dm.unipi.it writes:
Unrelated :-) We might define more macros like TMP_ALLOC_LIMBS_2 . I mean
_3 and _4. So that they can be used to reduce the number of allocations.
Do you agree? (I just touched mpz/gcdext.c, and _4 should be used there).
I'd vote for killing
Torbjorn Granlund t...@gmplib.org writes:
TMP_ALLOC_LIMBS_2 is clutter IMHO.
Sure, it's pointless in a normal build.
As I understand it, the reason for having TMP_ALLOC_LIMBS_2 is to make
--enable-alloca=debug more effective, by getting some kind of red zone
separating the two areas. Whether
On Wed, 22 Feb 2012, Torbjorn Granlund wrote:
bodr...@mail.dm.unipi.it writes:
Unrelated :-) We might define more macros like TMP_ALLOC_LIMBS_2 . I mean
_3 and _4. So that they can be used to reduce the number of allocations.
Do you agree? (I just touched mpz/gcdext.c, and _4 should be used
Marc Glisse marc.gli...@inria.fr writes:
That's for the alloca case. Without alloca, one call to malloc is
better than two (although that usually also means the numbers are big
and any gmp operation will dwarf allocation). Also, the threshold
between alloca and malloc is quite high, and
29 matches
Mail list logo
