ency, I also
> renamed realloc to xrealloc.
Committed at last, with minor changes (see below).
> --- a/mini-gmp/tests/t-mpq_str.c Mon Mar 09 17:01:17 2020 +0100
> +++ b/mini-gmp/tests/t-mpq_str.c Thu Mar 12 15:50:15 2020 -0400
> @@ -1,6 +1,6 @@
> /*
>
> -Copyright 20
On 2020-04-26 14:31:21 +0200, Niels Möller wrote:
> I'm updating the copy of mini-gmp I use in nettle to the latest version.
> In Nettle, it's compiled with gcc -Wall, and I some new warnings, like
>
> /home/nisse/hack/nettle/mini-gmp.c: In function ‘mpn_common_scan’:
> /home/ni
Marco Bodrato writes:
> The following line works in my environment:
>
> make CPPFLAGS="-DMINI_GMP_LIMB_TYPE=char" check-mini-gmp
Thanks, seems to work fine (and make clean-mini-gmp before changing limb
size).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is prefer
Il 2020-04-26 16:22 ni...@lysator.liu.se ha scritto:
Is there an easy way to run mini-gmp tests with
small limb size?
In mini-gmp/mini-gmp.h we have the following lines:
#ifndef MINI_GMP_LIMB_TYPE
#define MINI_GMP_LIMB_TYPE long
#endif
typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t;
So, you
se unsigned.
I'll do that, then. Is there an easy way to run mini-gmp tests with
small limb size?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-d
Ciao,
Il 2020-04-26 15:11 ni...@lysator.liu.se ha scritto:
ni...@lysator.liu.se (Niels Möller) writes:
There are a couple of other uses of LOCAL_SHIFT_BITS,
LOCAL_GMP_LIMB_BITS, LOCAL_CHAR_BIT, added as part of the support for
testing with small limb sizes. Is it for some reason important to
\
I get another warning,
gcc -O2 -pedantic -fomit-frame-pointer -m64 -mtune=broadwell -march=broadwell
-I../.. -c /home/nisse/hack/gmp/mini-gmp/tests/testutils.c -o testutils.o
In file included from
/home/nisse/hack/gmp/mini-gmp/tests/testutils.c:24:
/home/nisse/hack/gmp/mini-gmp/tests
I'm updating the copy of mini-gmp I use in nettle to the latest version.
In Nettle, it's compiled with gcc -Wall, and I some new warnings, like
/home/nisse/hack/nettle/mini-gmp.c: In function ‘mpn_common_scan’:
/home/nisse/hack/nettle/mini-gmp.c:99:23: warning: comparison of integer
expressions
Marco Bodrato writes:
> Please Niels, choose the implementation you prefer and change also
> mpz_fits_slong_p accordingly.
Pushed, including the new tests from your patch.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to
On 2020-04-20 15:25:54 +0200, Marco Bodrato wrote:
> Ciao,
>
> Il 2020-04-20 11:08 Vincent Lefevre ha scritto:
> > I think that in general, you should not write code that depends on
> > whether INT_MAX + INT_MIN == 0 or not (the constant INT_MAX + INT_MIN
> > might be useful in some rare cases,
Ciao,
Il 2020-04-20 11:08 Vincent Lefevre ha scritto:
I think that in general, you should not write code that depends on
whether INT_MAX + INT_MIN == 0 or not (the constant INT_MAX + INT_MIN
might be useful in some rare cases, but I think that testing whether
this constant is 0 or not should be
On 2020-04-19 12:23:03 +0200, Niels Möller wrote:
> >> BTW, do we have any C implementation where INT_MAX + INT_MIN == 0,
> >> i.e.,
> >> not using two's complement?
> >
> > I'm almost sure the compiler can optimise that out at compile time.
>
> Agreed. But if we attempt to support non two's
the condition I wrote, with one more branch.
I too would hope the compiler can inline mpz_cmp_si and propagate
constants. But my point was to make the source code simpler. By using
mpz_cmp_si the new functions become considerably simpler, imo. I don't
think this mini-gmp function needs to be optimi
Il 2020-04-19 10:44 ni...@lysator.liu.se ha scritto:
Marco Bodrato writes:
+int
+mpz_fits_sint_p (const mpz_t u)
+{
+ return (INT_MAX + INT_MIN == 0 || mpz_cmp_ui (u, INT_MAX) <= 0) &&
+mpz_cmpabs_ui (u, GMP_NEG_CAST (unsigned long int, INT_MIN)) <=
0;
+}
I think this and
Marco Bodrato writes:
> +int
> +mpz_fits_sint_p (const mpz_t u)
> +{
> + return (INT_MAX + INT_MIN == 0 || mpz_cmp_ui (u, INT_MAX) <= 0) &&
> +mpz_cmpabs_ui (u, GMP_NEG_CAST (unsigned long int, INT_MIN)) <= 0;
> +}
I think this and mpz_fits_sshort_p would be simpler using mpz_cmp_si,
int
Ciao,
On the gmp-discuss list,
Il 2020-04-11 21:41 Simon Sobisch ha scritto:
mini-gmp provides mpz_fits_slong_p ad mpz_fits_uslingt_p, but it does
not provide the same for smaller integer types.
We can easily add the requested functions. I suggest the following code:
diff -r 805304ca965a
ze) ((*gmp_reallocate_func)(ptr,
> > old_size, size))
>
> Here, "xalloc" is the traditional name (at least in GNU code, another
> name is xmalloc) for an allocation function that will crash with an
> error message on failure, rather than returning NULL. The name
> gmp_xal
in GNU code, another
name is xmalloc) for an allocation function that will crash with an
error message on failure, rather than returning NULL. The name
gmp_xalloc in mini-gmp most likely dates from before support for
get_set_memory_functions was added, and then it did the same thing as
the current g
Hello,
On Mon, Mar 9, 2020 at 8:43 AM Marco Bodrato wrote:
> Il 2020-03-09 13:04 minux ha scritto:
> > I added a check for out-of-range base to the beginning of mpq_get_str
>
> I'd prefer to let checking ranges outside of the mpq code.
> If res==NULL for whatever reason, goto ret is incorrect
Ciao,
Il Lun, 9 Marzo 2020 12:30 pm, Niels Möller ha scritto:
> Marco Bodrato writes:
>> For the style, I do not know which one is better:
>> "if(c){v=val}else{v=0};" or "v=0;if(c){v=val};"
> I don't have a very strong opinion on this point, but when it's easy to
> do, I prefer to assign once
Ciao,
Il Lun, 9 Marzo 2020 2:08 pm, Niels Möller ha scritto:
> Marco Bodrato writes:
>
>> -gmp_free_func (rden, 0);
>> +gmp_free_func (rden, lden * sizeof (char));
>
> sizeof (char) == 1 by definition, so no need to multiply with it.
Of course you are right!
Ĝis,
m
Marco Bodrato writes:
> -gmp_free_func (rden, 0);
> +gmp_free_func (rden, lden * sizeof (char));
sizeof (char) == 1 by definition, so no need to multiply with it.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale
LL, but details can
> also be refined later...
>
> There is an undocumented "feature" that the proposed patch breaks:
> "safe" failure when the base is out of range.
> The question is, should we keep it or not, document it or not, should
> GMP and mini-gmp agre
Marco Bodrato writes:
> For the style, I do not know which one is better:
> "if(c){v=val}else{v=0};" or "v=0;if(c){v=val};"
I don't have a very strong opinion on this point, but when it's easy to
do, I prefer to assign once on each code path. Then one (i) doesn't have
to reason about mutated
n is, should we keep it or not, document it or not, should
GMP and mini-gmp agree?
I attach a possible patch for tests that check that feature.
> @@ -4199,7 +4208,7 @@
> - size_t i, sn;
> + size_t i, sn, osn = 0;
> @@ -4220,15 +4229,15 @@
>if (!sp)
> -sp = (
nfo, CCCS, data_size_in_words);
>
> /* and return a ptr to the goods inside the array */
> return arr->payload;
>
> Maybe it would be easy for the realloc function to get the "arr" object
> back and get data size from here?
Yes, it's possible to modify ghc to avoi
All comments addressed, except as noted below.
I also fixed similar issues in mini-mpq.c changes.
On Sat, Mar 7, 2020 at 2:26 PM Niels Möller wrote:
> minux writes:
> > Because we don't have separate docs for mini-gmp, and mini-gmp does
> > provide mp_set_memory_functions, I
minux writes:
> Because we don't have separate docs for mini-gmp, and mini-gmp does
> provide mp_set_memory_functions, I think it's best if it can match
> gmp's behavior here to avoid confusions.
The differences are documented in mini-gmp/README (and your patch fixes
al
desired, and in that case
> the smaller of old_size and new_size bytes must be copied to the new
> location."
Sure, this code uses GMP correctly, according to GMP docs. And mini-gmp
has a documentedly different behavior.
> I consider the risk of passing a slightly smaller old_size in
as no way of
> knowing that and passing the original allocation size when later
> deallocating the buffer. GMP's implementation deals with this case using
> an extra realloc, to guarantee that the allocation size equals strlen +
> 1.
>
> The reason mini-gmp behaves differently here is that (i)
minux writes:
> mini-gmp currently always passes old_size == 0 to the custom
> reallocate function, causing custom allocators for GMP that use
> old_size to determine the amount of data to copy data to newly
> allocated space to malfunction with mini-gmp.
That's right. Deleting
Hi,
mini-gmp currently always passes old_size == 0 to the custom
reallocate function, causing custom allocators for GMP that use
old_size to determine the amount of data to copy data to newly
allocated space to malfunction with mini-gmp.
According to GMP documentation chapter 13
> Now the emulated systems on servile/qemuusr (the 3950X system's qemu
> user level emulator system) have all pre-compiled qemu under
> /usr/bin/qemu/. It seems that this bug was introduced with qemu 3.1
> and
> fixed in qemu 4.2. (The default qemu used is 4.1.1.)
Great! Thank you
Ciao,
Il 2019-12-18 11:25 t...@gmplib.org ha scritto:
Marco Bodrato writes:
Just looking at the report, it looks like an incorrect definition of
HUGE_VAL by the compiler/headers, or an incorrect handling of the
"infinity" value by the arithmetic operations on it. So yes, it can
be
a
I made qemu-4.2.0 the default for the affected systems, and also changed
to the cpu type to power9 from powerpc750..
Things work better now.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
gmp-devel@gmplib.org
Marco Bodrato writes:
Just looking at the report, it looks like an incorrect definition of
HUGE_VAL by the compiler/headers, or an incorrect handling of the
"infinity" value by the arithmetic operations on it. So yes, it can be
a qemu bug on floats.
Now the emulated systems on
Ciao,
Il 2019-12-17 23:18 t...@gmplib.org ha scritto:
Marco Bodrato writes:
The test t-cmp_d for mini-gmp is failing with:
mpz_cmp_d wrong (from check_infinity)
got 1
want -1
x=141246703213942603[...]
[...]
y 3.40282e+38
y 47 F0 00 00 00 00 00 00
This comes
Marco Bodrato writes:
From our testing system is emerging an error on some powerpc750.
The test t-cmp_d for mini-gmp is failing with:
mpz_cmp_d wrong (from check_infinity)
got 1
want -1
x=141246703213942603[...]
[...]
y 3.40282e+38
y 47 F0 00 00 00 00 00 00
From our testing system is emerging an error on some powerpc750.
The test t-cmp_d for mini-gmp is failing with:
mpz_cmp_d wrong (from check_infinity)
got 1
want -1
x=141246703213942603[...]
[...]
y 3.40282e+38
y 47 F0 00 00 00 00 00 00
This comes from the following lines in mini-gmp
Marco Bodrato writes:
>> With asl.h intermediates will get truncated to the size of mp_limb_t.
>
> I don't think mini-gmp is ready for asl.h jet. sizeof(mp_limb_t) is
> still used by some functions...
It looks like that it's only mpz_export and mpz_import that use
. But... what about mini- ? :-D
Ok. We can decide to keep a single variant for mpn_invert_3by2.
Done. https://gmplib.org/repo/gmp/rev/c22e8feca8e3
With asl.h intermediates will get truncated to the size of mp_limb_t.
I don't think mini-gmp is ready for asl.h jet. sizeof(mp_limb_t) is
still used
Marco Bodrato writes:
I was thinking also to some embedded systems I used some years ago,
where "unsigned long" was supported by the compiler, but slow on the
hardware...
But currently also those embedded systems are probably obsolete.
Not obsolete at all! I program a 80251 at work,
small-limb testing of mini-gmp. If it makes mini-gmp
with small limbs much faster, it might aid small-limb tests of mpfr.
Not only, it also aid small-limb testing of the implementations in
mini-gmp of gcd, primality testing, combinatorics, modular
exponentiation...
It is possible (and
t...@gmplib.org (Torbjörn Granlund) writes:
> Would it be feasible to use asl.h instead of the new coarse typing in
> mini-GMP? I think we should then conditionally #include asl.h from each
> test case, but leave mini-gmp.{c,h} alone.
Or maybe it's sufficient to add "-inc
This mini-GMP semi-asl project makes me eager to get full asl to work
for the full GMP. I think we could make it work for limbs down to 4
bits, perhaps even 2 bits. IIRC, one issue which needs resolving is our
occasional use of some limb macros for sizes.
Would it be feasible to use asl.h
"Marco Bodrato" writes:
> Ciao,
>
> Il Mar, 19 Novembre 2019 7:50 pm, Torbjörn Granlund ha scritto:
>> If there is special code for several asl cases, doesn't that defeat the
>> purpose of asl, at least to some extent?
I think it defeats small-limb testing of
Ciao,
Il Mar, 19 Novembre 2019 7:50 pm, Torbjörn Granlund ha scritto:
> If there is special code for several asl cases, doesn't that defeat the
> purpose of asl, at least to some extent?
Of course, to some extent you are right.
There are two functions that contain really special code for
"Marco Bodrato" writes:
For asl8, one of the existing shortcuts is used, not the generic code.
In particular, mpn_invert_3by2 (mp_limb_t u1, mp_limb_t u0) reduces to:
return (((unsigned) 1 << 24) - 1) / (((unsigned) u1 << 8) + u0);
If there is special code for several asl cases,
Ciao,
Il Mar, 19 Novembre 2019 5:02 pm, Torbjörn Granlund ha scritto:
> "Marco Bodrato" writes:
> The generic code (for mpn_invert_3by2) works only when "unsigned" is
> half
> the size of "mp_limb_t" or has the same size... this means that large
> types for mp_limb_t are not supported
"Marco Bodrato" writes:
Now the ABI=32 -asl16 issue should be healed.
I will whack it soon.
The generic code (for mpn_invert_3by2) works only when "unsigned" is half
the size of "mp_limb_t" or has the same size... this means that large
types for mp_limb_t are not supported (e.g. no
Ciao,
Il Mar, 19 Novembre 2019 9:50 am, Torbjörn Granlund ha scritto:
> "Marco Bodrato" writes:
> Il Lun, 18 Novembre 2019 1:06 pm, Torbjörn Granlund ha scritto:
> > t...@gmplib.org (Torbjörn Granlund) writes:
>
> > The build on maticrunch under the 32-bit ABI using "unsigned short"
> >
"Marco Bodrato" writes:
Il Lun, 18 Novembre 2019 1:06 pm, Torbjörn Granlund ha scritto:
> t...@gmplib.org (Torbjörn Granlund) writes:
> The build on maticrunch under the 32-bit ABI using "unsigned short" for
> mp_limb_t failed.
Ok, I'll investigate!
It might be easier to either do a
Ciao,
Il Lun, 18 Novembre 2019 1:06 pm, Torbjörn Granlund ha scritto:
> t...@gmplib.org (Torbjörn Granlund) writes:
> The build on maticrunch under the 32-bit ABI using "unsigned short" for
> mp_limb_t failed.
Ok, I'll investigate!
Ĝis,
m
___
t...@gmplib.org (Torbjörn Granlund) writes:
I've run a test round for 8-bit and 16-bit limbs now, on the system
shell.
The automated tests will however be run on the system mati, as that
system is many times faster than the hardware which runs shell.
The build on maticrunch under the
I've run a test round for 8-bit and 16-bit limbs now, on the system
shell.
The automated tests will however be run on the system mati, as that
system is many times faster than the hardware which runs shell.
--
Torbjörn
Please encrypt, key id 0xC8601622
Ciao,
Il Dom, 17 Novembre 2019 1:43 am, Vincent Lefevre ha scritto:
> It should work by conditionally including .
>
> Alternatively, you can predefine some types, e.g.:
>
> typedef unsigned char gmp_uchar_t;
I think that mini-gmp should not contain too many types, symbols,
defini
On 2019-11-17 01:00:14 +0100, Torbjorn Granlund wrote:
> We cannot use uint8_t as it is not a builtin type, as you know.
I don't understand why you need a builtin type.
It should work by conditionally including .
Alternatively, you can predefine some types, e.g.:
typedef unsigned char
> The needed space causes problems as this needs to go through several
> scripts and evaluations. I am not sure how to get it working, actually.
>
> I think the original proposal to have the word unsigned already in the
> file was better.
Not using a space is better.
Unfortunately
On 2019-11-17 00:41:17 +0100, Torbjorn Granlund wrote:
> "Marco Bodrato" writes:
>
> Committed.
>
> The needed space causes problems as this needs to go through several
> scripts and evaluations. I am not sure how to get it working, actually.
>
> I think the original proposal to have the
"Marco Bodrato" writes:
Committed.
The needed space causes problems as this needs to go through several
scripts and evaluations. I am not sure how to get it working, actually.
I think the original proposal to have the word unsigned already in the
file was better.
--
Torbjörn
Please
Ciao,
Il Sab, 16 Novembre 2019 9:49 pm, Torbjörn Granlund ha scritto:
> Marco Bodrato writes:
> With the patch below applied, the following line works on shell:
> gmake CPPFLAGS='-DMINI_GMP_LIMB_TYPE=unsigned\ char' check-mini-gmp
> As soon as that is committed, I will conf
pacey "long long" as overriding types, or
>
> I guess that's good enough for now. But is it that difficult to do
> quoting of "unsigned char"? Something like
>
> make check-mini-gmp CPPFLAGS='-D"MINI_GMP_LIMB_TYPE=unsigned char"'
With the
ood enough for now. But is it that difficult to do
quoting of "unsigned char"? Something like
make check-mini-gmp CPPFLAGS='-D"MINI_GMP_LIMB_TYPE=unsigned char"'
With the patch below applied, the following line works on shell:
gmake CPPFLAGS='-DMINI_GMP_LIMB_TYPE=unsigne
uot; as overriding types, or
>
> I guess that's good enough for now. But is it that difficult to do
> quoting of "unsigned char"? Something like
>
> make check-mini-gmp CPPFLAGS='-D"MINI_GMP_LIMB_TYPE=unsigned char"'
>
> (I don't remember trying to use -D with spaces in the ex
to do
quoting of "unsigned char"? Something like
make check-mini-gmp CPPFLAGS='-D"MINI_GMP_LIMB_TYPE=unsigned char"'
(I don't remember trying to use -D with spaces in the expansion, but it
can't be unheard of).
> 3. allow the use of asl.h. I am not sure we should support tha
Let's not make the best is the enemy of the good!
I suggest that we either,
1. do nothing now, or
2. follow Marco's proposal allowing "char", "short", "int", "long", and
perhaps the spacey "long long" as overriding types, or
3. allow the use of asl.h. I am not sure we should support that with
On 2019-11-13 17:41:47 +0100, Marco Bodrato wrote:
> I did hope that "unsigned" were just a modifier...
>
> But it seems that a line like the following is not allowed
>
> typedef unsigned uint128_t mp_limb_t
>
> I do not understand why...
If it were a modifier, then I suppose that "signed"
Il 2019-11-13 16:28 Vincent Lefevre ha scritto:
On 2019-11-12 22:22:00 +0100, Marco Bodrato wrote:
Is something like the following too tricky?
#ifndef MINI_GMP_LIMB_TYPE
#define MINI_GMP_LIMB_TYPE long
#endif
typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t
As only unsigned types are
On 2019-11-12 22:22:00 +0100, Marco Bodrato wrote:
> Is something like the following too tricky?
>
> #ifndef MINI_GMP_LIMB_TYPE
> #define MINI_GMP_LIMB_TYPE long
> #endif
>
> typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t
>
> As only unsigned types are supported...
Unsigned types do not
adapt the Makefile target check-mini-gmp in such a way
that it can handle
make MINI_GMP_LIMB_TYPE=char check-mini-gmp
Avoiding a space in the type would help. :-)
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
gmp-devel
...
Then, should we adapt the Makefile target check-mini-gmp in such a way
that it can handle
make MINI_GMP_LIMB_TYPE=char check-mini-gmp
?
Ĝis,
m
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
t...@gmplib.org (Torbjörn Granlund) writes:
> (Editing the mp_limb_t declaration from within the test drivers might be
> a poor approach, though, so I'll wait until there is a defined method of
> controlling its declaration.)
Then we'd need something like
#ifndef MINI_GMP_LIMB_TYPE
#define
Marco Bodrato writes:
But I'm not sure we should officially document this feature, for the
simple reason that... it is not currently tested by our great testing
framework.
I'd be willing to add whatever test is desirable.
(Editing the mp_limb_t declaration from within the test drivers
PS:
Il 2019-11-10 12:02 Marco Bodrato ha scritto:
It works thanks to the last corrections and to the work done last year
after the discussion on Paul's micro-gmp.
e.g.: https://gmplib.org/repo/gmp/rev/3f1afa83957e
Ĝis,
m
___
gmp-devel mailing list
Ciao Niels!
Il 2019-11-10 09:43 ni...@lysator.liu.se ha scritto:
I noticed the recent change
https://gmplib.org/repo/gmp/rev/d5f4f8640be9, "mini-gmp: Avoid
undefined
behaviour with small limb sizes."
Are you planning to do something like artificial-small-limbs
for mini-gmp,
Hi,
I noticed the recent change
https://gmplib.org/repo/gmp/rev/d5f4f8640be9, "mini-gmp: Avoid undefined
behaviour with small limb sizes."
Currently, mini-gmp.h makes mp_limb_t an alias for unsigned long, which
by the C spec ought to be at least 32 bits. And then, e.g.,
int LOCAL_
I replaced comments with #ifdef's , take a look in
https://github.com/vfonov/cork/blob/CloudCompare/contrib/gmp-6.1.2/mini-gmp/mini-gmpxx.h
, if I replace gmpxx.h with the contents of mini-gmpxx.h and configure
with --enable-cxx , running "make test" seem to be passing.
On Fri, Ju
Marc Glisse writes:
Or we could have a much more simplistic mini C++ wrapper without
expression templates, if we are going to maintain 2 versions, although
I am not fond of the idea of maintaining 2 versions.
We could generate two versions using m4. :-D
--
Torbjörn
Please encrypt, key
On Fri, 12 Jul 2019, Vladimir S. FONOV wrote:
I needed a mini version of gmp, to work with C++ inteface, so I created
mini-gmpxx.h (gmpxx.h for mini-gmp) , mostly for the purpose of compiling
cork on macOS without libgmp present, take a look in
https://github.com/vfonov/cork/tree/master/contrib
Hello,
I needed a mini version of gmp, to work with C++ inteface, so I created
mini-gmpxx.h (gmpxx.h for mini-gmp) , mostly for the purpose of compiling
cork on macOS without libgmp present, take a look in
https://github.com/vfonov/cork/tree/master/contrib/gmp-6.1.2/mini-gmp , it
is basically
Ciao,
Il Ven, 21 Dicembre 2018 11:36 pm, Marco Bodrato ha scritto:
> Il Ven, 21 Dicembre 2018 7:13 pm, Niels Möller ha scritto:
> Before my changes, lcov (
> https://gmplib.org/devel/lcov/shell/gmp/mini-gmp/ ) reported for the file
> mini-gmp.c:
>Line Coverage: 98.4 % 2029 / 2
Il 2018-12-21 19:13 ni...@lysator.liu.se ha scritto:
2. Reduce the number of places that depend on mp_limb_t == unsigned
long, where that also makes code simpler. E.g, using init_set_ui or
roinit_ui in more of the _ui functions.
Starting from the current code:
- for comparison functions
s, lcov (
https://gmplib.org/devel/lcov/shell/gmp/mini-gmp/ ) reported for the file
mini-gmp.c:
Date: 2018-12-15 08:18:37
Line Coverage: 98.5 % 2034 / 2066
Functions: 99.0 % 197 / 199
Branches: 87.6 % 1117 / 1275
Now it says:
Date: 2018-12-21 08:03:29
Line Coverage: 98.4 % 2029 /
t...@gmplib.org (Torbjörn Granlund) writes:
> I think we should consider carefully whether mini-gmp should be
> generalised to do small limbs. To me, it makes sense to keep to
> mini-gmp's main goal of being small en simple.
Agree, we should not compromise simplicity. To me it might m
I think we should consider carefully whether mini-gmp should be
generalised to do small limbs. To me, it makes sense to keep to
mini-gmp's main goal of being small en simple.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
gmp
On 2018-12-21 01:43:12 +0100, Marco Bodrato wrote:
> We know, we never claimed that mini-gmp was supporting different limb sizes.
> The suggestion was "by Paul" :-)
In https://gmplib.org/list-archives/gmp-devel/2018-December/005117.html
you said:
A attach a possible implementa
Il Gio, 20 Dicembre 2018 2:56 pm, Vincent Lefevre ha scritto:
> On 2018-12-16 02:22:27 +0100, Vincent Lefevre wrote:
>> This was a suggestion by Paul:
>>
>> --
>> How to use mini
------
How to use mini-gmp with reduced limb size
==
Following the idea of Micro-GMP [1], the GMP developers have adapted mini-gmp
so that it can be used with a reduced limb size.
For that, you have to take a GMP snapshot from December
Vincent Lefevre writes:
> Yes, this is expected by MPFR. But since mini-gmp.c includes
> mini-gmp.h, this prevents one from redefining GMP_LIMB_BITS
> in mini-gmp.h, except by exactly the same content, which is
> not interesting.
I'm afraid I'm missing simthing. Why would you redefine it in
On 2018-12-15 09:48:41 +0100, Niels Möller wrote:
> paul zimmermann writes:
>
> > would it be possible to move the following from mini-gmp.c to mini-gmp.h?
> >
> > #define GMP_LIMB_BITS (sizeof(mp_limb_t) * CHAR_BIT)
> >
> > It would expose GMP_LIMB
paul zimmermann writes:
> would it be possible to move the following from mini-gmp.c to mini-gmp.h?
>
> #define GMP_LIMB_BITS (sizeof(mp_limb_t) * CHAR_BIT)
>
> It would expose GMP_LIMB_BITS to applications using mini-gmp, without
> requiring
> them to redefine it.
The re
Hi,
would it be possible to move the following from mini-gmp.c to mini-gmp.h?
#define GMP_LIMB_BITS (sizeof(mp_limb_t) * CHAR_BIT)
It would expose GMP_LIMB_BITS to applications using mini-gmp, without requiring
them to redefine it.
Paul
On 2018-09-05 17:43:29 +0200, Vincent Lefevre wrote:
> On 2018-09-05 16:00:18 +0200, Torbjorn Granlund wrote:
> > Perhaps this can be automated and given a new, trendy name now that
> > fuzzing has been on everybody's mind for so long? :-)
>
> An interesting place is to check inequalities on
On 2018-09-05 16:00:18 +0200, Torbjorn Granlund wrote:
> paul zimmermann writes:
>
> void
> mpz_add_ui (mpz_t r, const mpz_t a, unsigned long b)
> {
> b = b % 0x;
> if (a->_mp_size >= 0)
> r->_mp_size = mpz_abs_add_ui (r, a, b);
> else
> r->_mp_size =
paul zimmermann writes:
void
mpz_add_ui (mpz_t r, const mpz_t a, unsigned long b)
{
b = b % 0x;
if (a->_mp_size >= 0)
r->_mp_size = mpz_abs_add_ui (r, a, b);
else
r->_mp_size = -mpz_abs_sub_ui (r, a, b);
}
An interestng approach, patch the library to
Hi,
I noticed the mini-gmp test suite does not seem to contain any test of
mpz_add_ui with the unsigned long argument having more than 32 bits.
Indeed with the following change "make check" still says "All 25 tests passed"
(with the mini-gmp from gmp-6.1.2):
void
"Marco Bodrato" <bodr...@mail.dm.unipi.it> writes:
> Il Dom, 20 Maggio 2018 9:57 pm, Niels Möller ha scritto:
>> You could consider making this into small step towards modularizing
>> mini-gmp. Something like
>
>> #ifndef MINI_GMP_FLOAT_SUPPORT
>
>&g
sing the generic code, without HAVE_DOUBLE_VAX_D?
> Testing the generic code seems more important than testing VAX-specific
> optimizations.
Right.
The current generic implementation is very similar to the implementation
in mini-gmp. So, in some sense, even testing mini-gmp only can be
interest
ni...@lysator.liu.se (Niels Möller) writes:
I think so. Does current gcc support VAX, or what compiler would we use?
vaxpropp$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/lto-wrapper
Target: vax--netbsdelf
Thread model: posix
gcc version 4.8.5 (nb2 20150115)
t...@gmplib.org (Torbjörn Granlund) writes:
> Would it be beneficial to add some non-IEEE host to the GMP autobuild
> setup? We could revive vax using simh.
I think so. Does current gcc support VAX, or what compiler would we use?
Can VAX be supported using the generic code, without
1 - 100 of 313 matches
Mail list logo
