Re: g++-3.4 bug
On Mon, 20 Feb 2012, Richard Guenther wrote:
On Thu, 16 Feb 2012, Marc Glisse wrote:
Hello,
some tests currently fail on gmpxx with g++-3.4 (on shell). This is due to a
bug in g++-3.4, which for l=2 says the following is true:
__builtin_constant_p(l) (l == 0)
it is interesting to insert a printf statement that prints both l and l==0 and
have it print 2 and true :-/
Not for me.
int main () { int l = 2; if (__builtin_constant_p (l) (l == 0)) return
1; return 0; }
Did you try getting a snapshot of the gmp repos and running the c++
testsuite? Yes, your simple example passes, but you know better than I do
how much the context matters for optimizations. And since the bug doesn't
seem reproducible with more recent versions of gcc, there is little
motivation to reduce the failing tests.
The failing compiler was 3.4.6, from ports on freebsd 8.1, with -O2 -m64.
4.2.5 seems good.
In gmpxx.h, you can do this change:
struct __gmp_binary_lshift // LINE 425
{
static void eval(mpz_ptr z, mpz_srcptr w, mp_bitcnt_t l)
{
if (__GMPXX_CONSTANT(l) (l == 0))
{
std::cerr l '\n'; // NEW LINE
if (z != w) mpz_set(z, w);
}
(and replace iosfwd with iostream at the beginning)
and wonder why it prints 2...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: g++-3.4 bug
On Mon, 20 Feb 2012, Torbjorn Granlund wrote: Marc Glisse marc.gli...@inria.fr writes: Yes, my main concern is whether I should let people notice that the testsuite is failing so they try a more recent compiler, or work around it by disabling the use of __builtin_constant_p for 3.4.* (and anything older?). If just the test suite is miscompiled, libgmp.* and libgmpxx.* seem fine. and the compiler is actually still used, then we might as well make a (trivial) workaround in the test suite. I am not sure what you mean. Note that as is, a g++34 user who multiplies a mpz_class by 4u (what the testsuite does) in his code is likely to hit the bug. I am not really happy with hiding the testsuite failure, I'd rather either let the testsuite noisily fail, or (trivially) work around the bug in gmpxx.h so the user's code is safe too. (now that I think about it, there is a testsuite failure on solaris (likely with g++-3.4.3) visible at http://hydra.nixos.org/build/2112917 when creating a mpz_class from an mpz_t, 3.4 is really an unlucky number) which last I checked didn't work with the master repos ;-) (it doesn't understand the instruction jb,pt in mpn/x86_64/mod_34lsub1.asm (and neither does oracle)) I suppose we could as well remove it. Now done. Thanks. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
_mp_alloc vs ALLOC
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 mpq_denref are not used much internally because of 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? Unrelated, I was thinking of changing (when gmp is compiled with a C++ compiler, so that wouldn't affect many people...) the definitions of TMP_DECL and TMP_FREE so TMP_DECL would create a variable whose destructor (executed when the variable goes out of scope, which shouldn't be far from where TMP_FREE is currently called) does what TMP_FREE currently does. The advantage is that in case an exception is thrown in between, the destructor is executed. That doesn't solve all memory issues by far, but it is a first step that costs little in terms of code and 0 in speed. I am not saying I will do either any time soon, just checking first. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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 there). I'd vote for killing TMP_ALLOC_LIMBS_2 rather than add TMP_ALLOC_LIMBS_N for some range of N. 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 the target variable. Cost: about 1 cycle. 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 with many separate allocations that all barely fit below this threshold, the total amount of stack memory used can become too large for some applications (lowering the threshold may be easier than allocating things in groups though). On Wed, 22 Feb 2012, Niels Möller wrote: 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 or not that's worth the clutter, I'm not sure. Er, I guess you mean TMP_ALLOC_LIMBS_2 as opposed to a single call to TMP_ALLOC_LIMBS manually split in two, not as opposed to 2 calls to TMP_ALLOC_LIMBS. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: test if an unsigned long fits in a limb.
On Tue, 6 Mar 2012, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Note that mpir is replacing signed/unsigned long by two typedefs that can be defined as (unsigned) long long on _LONG_LONG_LIMB platforms. That works around the problem too... (actually they don't seem to have released that yet, they are just experimenting) But the point of the _ui and _si functions, as I understand them, is to make it safe and easy to pass values between code using GMP and code which is unaware of GMP types. One can have alternative functions accepting mp_limb_t and mp_limb_signed_t, if one finds that useful. But for the above reason, advertising such functions as a substitute for the _ui and _si functions seems to totally miss the point. Their main goal is to be able to interact with 64 bit integers on win64. Imagine that mpz_set_si takes as argument a long long on win64. I can still pass it a long with no problem. Imagine that mpz_get_si outputs a long long. I can still store it safely in a long, because I first called mpz_fits_slong_p to check that it would fit. It doesn't look like I have lost anything. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: test if an unsigned long fits in a limb.
On Wed, 7 Mar 2012, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Imagine that mpz_set_si takes as argument a long long on win64. I can still pass it a long with no problem. Imagine that mpz_get_si outputs a long long. I can still store it safely in a long, because I first called mpz_fits_slong_p to check that it would fit. It doesn't look like I have lost anything. I see. That could work, even if I'm still not convinced it's a good idea to have the type used depend on the GMP configuration. If the intention is to get an integer of size matching a the native word size, no matter which C type that may be, I think using mp_limb_t and mp_limb_signed_t (but without nail bits) should be goood enough. Possibly. I repeated some arguments, but I don't know the answer either. Functions using long long would provide additional functionality on platforms where long long is larger than mp_limb_t (presumably because long long is larger than the native word size). But I think those should be additional functions, since they will give a larger overhead if you really just want a long (which fits in a native word on sane platforms). We can add an awful lot of functions here, so I imagine we need to think a bit on which function really are needed. If I understand you correctly, the most urgent problem is to be able to convert between mpz_t and native (64-bit) integers on W64. Is there any other supported platform that has chosen an ABI where Long is smaller than the native word size? I would assume that this mostly corresponds to the 'longlong' configurations, which according to configure.in include quite a few 64bit platforms that provide a 32bit ABI. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: ABS_CAST
On Tue, 27 Mar 2012, Niels Möller wrote: I had a look at the ABS_CAST macro introduced a while ago, #define ABS_CAST(T,x) ((x) = 0 ? (T)(x) : -((T)((x) + 1) - 1)) As I understand it, the point is that, e.g., int x; unsigned absx; ... absx = ABS_CAST (unsigned, x); should give the right result for x = INT_MIN (where plain ABS would give the result INT_MIN). And be more portable than the simpler definition #define ABS_CAST(T, x) ((T) ABS(x)) This would usually give the right result for INT_MIN, but some gcc-4.7 optimizations manage to break it. But the current definition seems strange. When x 0, it will cast the negative value to an unsigned type (which I suspect is not portable according to the C89 spec (maybe it's more well defined in C99?)), and I'm not sure what is gained by the extra +1 and -1 when doing that. I'd suggest using instead #define ABS_CAST(T,x) ((x) = 0 ? (T)(x) : (((T)(-((x) + 1))) + 1)) Then in the case x 0, first add 1, and note that both (x+1) and -(x+1) always fit in a signed int. Then negate, cast the resulting *non-negative* number to unsigned, and then an unsigned add of 1 to get the correct absolute value. Am I misunderstanding anything here? Writing just -(T)(x) is safe, is what mpfr uses, and is what I had written. Torbjorn added the +1-1 for extra safety. I agree that your version is even safer. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Unused code
On Fri, 13 Apr 2012, Torbjorn Granlund wrote: Are you aware if any more files or functions that are unused? It is a different information, but a code coverage tool run during the testsuite tells which functions are never called there (on one specific platform, with one set of options): http://hydra.nixos.org/build/2398430/download/1/coverage/ -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Unused code
On Fri, 13 Apr 2012, bodr...@mail.dm.unipi.it wrote: http://hydra.nixos.org/build/2398430/download/1/coverage/ Very interesting! Moreover you got the current code! It is the continuous build infratructure that Ludovic Courtès presented about a year ago: http://hydra.nixos.org/jobset/gnu/gmp-default so it should always be about the latest code (although the first link I gave is one specific build, you have to follow the links from the main page to get the latest one). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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... Assuming we can... And then the question remains, are there systems and C libraries where free + malloc is significantly slower than realloc in common cases? I am afraid so. Experiments are needed, but my intuition tells me that for small numbers (for large numbers, the cost of copying in realloc is anyway small compared to whatever operation you are doing), free+malloc will be significantly slower than realloc. probably naïve, but if we consider the case that the current block can be easily extended in place, I imagine that free will put it at the head of the free list, and the subsequent call to malloc will get it back. Allocators often try to separate allocations depending on their size. They will try to respect a realloc call, but if they can (free+malloc) they may prefer taking a block from another pool. Letting them do it may be a good thing in the long run (less fragmentation, future allocations are faster), but may be slower for this particular call. Again, this is pure speculation, I may be way off. Then the additional overhead compared to realloc seems small, but I guess it could matter, e.g., if access to the free list is protected by a mutex. I don't think many allocators still do that... (Speaking of allocation, I also wonder what to do about the problem described in http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html, there were no replies at the time). Good question ;-) Related: I was always unhappy about the order of the reallocation function arguments. malloc and free can be used by gmp (just ignore the old size passed as last argument) but realloc needs a wrapper. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP aborting in __gmpn_cpuvec_init when run inside KVM
On Thu, 31 May 2012, Richard Guenther wrote: KVM unfortunately defaults to an impossible CPU model/family on x86_64 (GenuineIntel, family 6, model 2). This leads to __gmpn_cpuvec_init abort()ing. Of course KVM is to blame here but they appearantly don't want to fix ... Do you have a link to the corresponding bug report / conversation? -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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 you mean copying, so the conservative one would be the regular realloc and the other one could safely be realloc or free+malloc? I am asking because other functions like try_expand (like realloc if it can do it in place, but if it can't, returns 0 without deallocating) can also be useful but are harder to provide (unless you make them always return 0). I know people were discussing the allocator concept for the C++ standard, but that doesn't seem to have led anywhere (yet?). - should we change the order of parameters? I would be very afraid of doing something that confusing. If there was already an ABI break that changes the number of arguments maybe... -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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 ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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 thread-local, like the regular errno. Doing the right configuration magic may be some work, but other projects must have done it before. Making some C error handling mechanism would be great, though. I am not sure that's easy, though. For error handling, use C++? One great thing about C++ exceptions is how little they cost when no exception is thrown. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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 junk (uninitialised) data as much as it likes. [...] A complaint is issued only when your program attempts to make use of uninitialised data in a way that might affect your program's externally-visible behaviour. So, if the value is correctly overwritten before using it, Valgrind should not complain. Cool, I did not know that, thanks! I inserted the line for testing purposes, but it obviously is useless, it can be removed! No, no, looks good :-) I think mpz_neg is a candidate for MPZ_NEWALLOC. I think there are many, because the macro destroys the content only if a memory enlargement is needed. E.g. mpz/tdiv_?_2exp.c are candidate for _NEWALLOC, because no reallocation (i.e. no data loose) happen when source and destination operands coincide. Good. I wanted to make sure before adding some (not that that will happen anytime soon...). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_get_ld
On Mon, 18 Jun 2012, Zimmermann Paul wrote:
I am contributing the following function:
long double
mpz_get_ld (mpz_t z)
{
double h, l;
mpz_t tmp;
h = mpz_get_d (z);
mpz_init (tmp);
mpz_set_d (tmp, h);
mpz_sub (tmp, tmp, z);
l = mpz_get_d (tmp);
mpz_clear (tmp);
return (long double) h + (long double) l;
}
If the function mpz_get_ld is provided, I expect it to work for the whole
(exponent) range of long double value, not just the range of double.
Should we first do something about large z, then apply your method and fix
the result with ldexpl?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: LIBGMPXX_LT_*
On Tue, 26 Jun 2012, Torbjorn Granlund wrote: Marc Glisse marc.gli...@inria.fr writes: I just added a new symbol to libgmpxx. Should I touch one of the LIBGMPXX_LT_* in Makefile.am, mark somewhere that it may need to be done prior to release, or ignore the (non-)issue? You might fill in the table in Makefile.am to make sure a CXX update is not forgotten. Ok, I did that. And noticed that, although LIBMP_LT_* are still there, mpbsd was removed a while ago (I had completely forgotten about that...). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
long long
Hello, last conversation about 'long long' was in March, here is a link to one of the messages: http://gmplib.org/list-archives/gmp-devel/2012-March/002292.html 2 possibilities were discussed: 1) make the _ui functions take a mp_limb_t instead of an unsigned long (or maybe the longest of the two). This provides long long support on those platforms that can most benefit from it without complicating the interface or the code (it would actually simplify the code a bit). 2) provide additional functions for long long, with a configure test to disable this code on platforms that do not have long long (are there many of those?). In the worst case we could document a macro GMP_USE_LONG_LONG to let users decide. The alimb branch (any progress?) decouples limbs from builtin types. With some extra effort, that might make it possible to compile a file mpz/*_ui.c twice with different macros to generate both the usual _ui function and a new _ul (or _ull?) function for long long. It will then be trivial to add _u128 versions for unsigned __int128 if we decide to. This approach may cause a bit of binary code duplication in the library though. Does this match your vision of the current status? Any opinion on the best way forward? Or a veto against long long? -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: long long
On Tue, 31 Jul 2012, Patrick Pelissier wrote: Why not intmax_t / uintmax_t instead of long long / unsigned long long? I believe every platform that has intmax_t also has long long, but the converse is not true. Do you have an example of such a platform? Say, MS visual studio up to version 9 maybe? (I don't have it here to check) Some platforms provide types larger that intmax_t (intmax_t is part of the ABI, and they couldn't change it when they added a longer type, see for instance __int128 in gcc). Well according to PR#49595, __int128 is not even an extended integer type but something strange which can hold an integer of 128 bits. Since the C standard doesn't apply (since it is not an extended nor standard integer tyoe) and since GCC Manual doesn't specify what operations are valid and what are not, I am not even sure what a+b does when a and b are __int128 :) The reason __int128 is documented as not an extended integer type is precisely so they don't have to make intmax_t a typedef to it and break the ABI. Doesn't sound so great... Note that there are patches floating aroung to introduce __int256 and larger types. Possibly on demand (user would just write a typedef with a suitable attribute to define a new extended integer type). intmax_t started from a good intention, but it seems fairly useless in practice. I rarely used long long but used intmax_t quite often. I found long long quite useless: either you need 64 bits arithmetic, and you should use int64_t (or its friends) to have the optimal type, Probably int_least64_t or int_fast64_t, in theory. or you need the type which can fit them all, and you should use intmax_t. which, on every platform I met where it was present, is a typedef for long long. I agree that intmax_t is nice in theory, but I haven't seen practice catch up yet. Ok, now I've criticized intmax_t enough, I think mpfr's set of *_[su]j functions is a fine interface, and I would be happy to see the same in gmp ;-) -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: speed of mpz_odd_p and lazy allocation
On Wed, 15 Aug 2012, Niels Möller wrote: bodr...@mail.dm.unipi.it writes: There are places in the code where mp_d[0] is written disregard of previous value of size and alloc... (E.g. try $ grep -C2 PTR *(.)\[0\] *= mpz/*.c ) Pointing to a const limb won't help there, of course. Common scratch limb (as suggested by Torbjörn) might work. Hm, the reads are sometimes too eager, but when a write happens, it is usually important, so writing it to a scratch location is strange. In a number of those places you'll need to modify the code to allocate anyway, so you might as well do it before the write. A was thinking of abort on write, rather. I have seen two use cases that call for changes to these conventions: 1. Initialization of objects containing mpz_t fields with a single memcpy from a template object. Currently, one must also call mpz_init for each mpz_t. I imagine Marc's use cases are something similar. My main use cases are dictated by C++. It would help if mpz_class::mpz_class() didn't throw = mpz_init doesn't throw. It would help if mpz_class::mpz_class(mpz_class) was fast (when the argument is unused afterwards) and didn't throw = mpz_init immediatly followed by mpz_clear is (in a way the compiler can notice) a nop. (the right hand side of the arrows is just one way to achieve the result, not the only way) Note that it is possible for the C++ front-end to use the techniques we are discussing even if the C front-end doesn't. And it would likely be completely invisible from the user's point of view, so if the C front-end later decided on another strategy, it wouldn't break anything. Note also that I am not going as far as some propositions for the future C++ std::integer type, which may require construction from int to be a compile-time operation (no dynamic allocation). 2. Compile time constants. I'd like a way to define compile time constant bignums, without using gmp internals. One could solve (1) by saying that alloc = 0, size = 0 means that storage should be allcoated at write. _mp_d could point to a scratch limb, if we want to keep _mp_d[0] writable at all times. And solva part of (2) by sating that alloc = 0, size != 0 means storage allocated by the application, and the mpz_t should be treated as read-only by gmp. Without thinking deeply about it, I think needed handling of alloc = 0 could be done in the unlikely branch of MPZ_REALLOC. There are still quite a few other places that need patching with that solution. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Undefined-behavior overflows in GMP?
On Tue, 20 Nov 2012, Roberto Bagnara wrote: I have just finished reading Understanding Integer Overflow in C/C++, by Will Dietz, Peng Li, John Regehr, and Vikram Adve (http://www.cs.utah.edu/~regehr/papers/overflow12.pdf). On page 9, it says: Finally, we reported nine undefined overflows in the GNU Multiple Precision Arithmetic Library, one in BIND, and one in OpenSSL. We received no response from the developers of these three packages. Talking about GMP alone, is this accurate and up to date? Would it be possible to see the reports that were sent? on gmp-bugs: Date: Fri, 20 Aug 2010 21:34:40 -0600 -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP 6 the incomatible GMP?
On Tue, 8 Jan 2013, Niels Möller wrote: Torbjorn Granlund t...@gmplib.org writes: The idea is to instead make a 64-bit bitfield of the _mp_size and _mp_alloc fields. One would give _mp_size about 48 bits, and _mp_alloc the remaining 16. The alloc field would lose granularity, but should code small sizes exactly. Hmm. I guess one could go down to only 8 bits or so for the alloc field, and for larger allocations, store the number of allocated limbs at the head of the limb array (in the case limb size is not artificially small, it could be just _mp_d[-1]). Then we might as well always put it in _mp_d[-1], no? IIRC that's what mpfr does. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP 6 the incomatible GMP?
On Tue, 8 Jan 2013, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Then we might as well always put it in _mp_d[-1], no? IIRC that's what mpfr does. That will increase overhead (both allocation and processing, I think) for small bignums, which may be undesirable. But I don't really know how significant that is. I am not sure about processing. The allocated size is hidden behind the pointer, but you are already dereferencing that pointer anyway, and you are saving on the bit manipulations to separate size from alloc. It does indeed waste a bit of heap space (not sure that's significant), which can also increase the processing in malloc/free. Experimentally (for me, others can have wildly different use cases), what really helps for small nums isn't to save space, it is to not allocate at all, for instance storing a few limbs in the base type and only allocating when that's not enough (recycling storage can work even better, but is for very specific uses and may not make sense for a generic library). There are plans to add a bignum type to the C++ standard, and people are discussing whether it should be part of the specification that constructing small numbers (not even just 0) doesn't use dynamic allocation. Now the target users of this bignum type and GMP are not exactly the same (bignum would be used a lot by people who only need int but want to be safe), so it makes sense if the best solutions differ. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: [patch] add x32 support
On Thu, 10 Jan 2013, Torbjorn Granlund wrote: How could I test this? I don't remember what linux you have access to. Debian for instance has packages in experimental named libx32gcc1, libc6-x32, etc. Then you just need to compile with gcc -mx32. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: [patch] add x32 support
On Thu, 10 Jan 2013, Marc Glisse wrote: On Thu, 10 Jan 2013, Torbjorn Granlund wrote: How could I test this? I don't remember what linux you have access to. Debian for instance has packages in experimental named libx32gcc1, libc6-x32, etc. Then you just need to compile with gcc -mx32. Hmm, it also requires installing a kernel compiled with a different option, etc, so scratch that, sorry :-( -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_{eq,lt,gt}_{ui,si}_p macros?
On Sun, 10 Feb 2013, Torbjorn Granlund wrote: bodr...@mail.dm.unipi.it writes: If you like the idea, then please read carefully the lt_si and gt_si variants, I'm not sure I'm handling correctly the negative constants. I like the idea. I stopped reading when I found that several __builtin_constant_p had compund arguments. I doubt __builtin_constant_p (0 1) makes sense, I think the argument must be a lexical constant, not an expression which after folding is constant. I think we already had the same conversation in February 2011 on gmp-discuss ;-) Example: __builtin_constant_p ((UI) 0 (UI) = GMP_NUMB_MAX) -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_{eq,lt,gt}_{ui,si}_p macros?
On Wed, 13 Feb 2013, bodr...@mail.dm.unipi.it wrote: Ciao Marc, Il Lun, 11 Febbraio 2013 12:42 am, Marc Glisse ha scritto: Could we have inline functions instead of macros? I'd rather avoid macros Are inline functions as portable as macros? Not quite, but I don't know any current compiler that doesn't support them. Besides, I thought we were talking about __builtin_constant_p, and thus gcc (or compatible compilers). If a compiler does not inline the function corresponding to: #define mpz_lt_ui_p(Z,UI) (_mpz_cmp_ui (Z,UI) 0) then we will have two function calls instead of one. If the compiler is bad, there are many bad things that can happen... I am wondering (true question) how much this gains compared to refining the existing mpz_cmp_[su]i macros. I don't know exactly, I didn't try. The _cmp_ functions return three possible values. The compiler should be able to select. We can define _cmp_ui (z,0) as (SIZ(z)0)-(SIZ(z)0), will the compiler detect that this expression is 0 iif SIZ(z) is? and 0 iif SIZ(z) is? and ==0 iif SIZ(z)==0? I tried with gcc-4.8, it optimized this just fine. Even worse for cmp_ui (z,limb), it is hard to write a branchless expression. Branches may actually make it easier for the compiler to understand the code and thus remove useless branches, as opposed to clever but obscure branchless expressions. Assume we write cmp_ui (z,limb) as gt()?1:lt()?-1:0, it is easy for the compiler to understand that the expression 0 iif gt(), but what about 0? I tested (i0?1:i0?-1:0)0 (and 0 and ==0) and gcc optimized it to just i0 (resp. i0, i==0). If UI always fits in a LIMB, we can write (even for non-gcc compilers) #define mpz_gt_ui_p(Z,UI) (SIZ(Z) (PTR(Z)[0] = (UI))) #define mpz_lt_ui_p(Z,UI) (SIZ(Z) = (PTR(Z)[0] (UI)) - ((UI) == 0)) #define mpz_eq_ui_p(Z,UI) (SIZ(Z) == ((UI) != 0) (((UI) == 0) || (PTR(Z)[0] == (UI))) Can you suggest a definition for cmp_ui to obtain something similar? OK, that looks harder... If you like the idea, then please read carefully the lt_si and gt_si variants, I'm not sure I'm handling correctly the negative constants. -(SI) seems wrong, you need to cast to an unsigned type before taking the opposite, or LONG_MIN gives you undefined behavior. ... you are right ... I don't know if I'll be able to write a shortcut for negative numbers... Why not? If -(SI) is the only issue, then -(unsigned long)(SI) should work, no? -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Extending the mpn interface
On Sat, 23 Feb 2013, Niels Möller wrote: ni...@lysator.liu.se (Niels Möller) writes: Another revision, this time as a patch. As you can see, I renamed things a bit more. Compile tested only... New patch below, including some testcases (no tests for mpz_roinit_n and MPZ_ROINIT_N though). I'd like to check this in now. Any objections? Was the documentation in an earlier message (I couldn't find it)? The fact that the finish function normalizes makes sense but is hard to guess. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Extending the mpn interface
On Thu, 28 Feb 2013, Niels Möller wrote: And MPN_ROINIT_N can't normalize, of course. I think it could in modern languages (say C++11 for instance), but that's not the point, sorry for the digression. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: mpq_get_d_nearest
On Fri, 12 Apr 2013, Zimmermann Paul wrote:
the mpq_get_d function rounds towards zero (i.e., truncates).
In several applications, people usually prefer rounding to nearest.
Is it planned to provide a function (say mpq_get_d_nearest) for that?
I could contribute it, based on the code below (which does not deal with
subnormal numbers yet).
We could also have rounding towards -infinity and +infinity, which would be
useful for people doing interval arithmetic.
Preferably with a single function that returns both roundings :-)
That would allow us to remove this slow code from CGAL (and stop linking
with mpfr in many cases):
operator()( const mpq_class x ) const {
mpfr_t y;
mpfr_init2 (y, 53); /* Assume IEEE-754 */
mpfr_set_q (y, x.get_mpq_t(), GMP_RNDD);
double i = mpfr_get_d (y, GMP_RNDD); /* EXACT but can overflow */
mpfr_set_q (y, x.get_mpq_t(), GMP_RNDU);
double s = mpfr_get_d (y, GMP_RNDU); /* EXACT but can overflow */
mpfr_clear (y);
return std::pairdouble, double(i, s);
}
(I hadn't looked at that code in a while, it could at least use
MPFR_DECL_INIT I guess, but best would be not needing mpfr)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: Preparing GMP 5.1.2
On Mon, 13 May 2013, Torbjorn Granlund wrote: I think it is time for a 5.1.2 release, since we've found and fixed a couple of bugs since the last release. I am redirecting the nightly build scripts to use the 5.1 repo. The main repository will thus be untested for a while. Unless I hear protests, I'll make the new release towards the end of this week. I need to backport a couple changes that I made soon after 5.1 branched, I'll try to do that soon... -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Preparing GMP 5.1.2
On Mon, 13 May 2013, Torbjorn Granlund wrote: Marc Glisse marc.gli...@inria.fr writes: I need to backport a couple changes that I made soon after 5.1 branched, I'll try to do that soon... Sorry, I had missed that. My fault for being so slow to backport them. Some of them were waiting for improved versions based on discussions back then, but they are still better than nothing. I will not make the release until you have the time to address this. Hopefully I am done. Since they have been on the main branch for a while, I don't expect any new issues. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Preparing GMP 5.1.2
On Thu, 16 May 2013, Torbjorn Granlund wrote: Marc Glisse marc.gli...@inria.fr writes: I will not make the release until you have the time to address this. Hopefully I am done. Since they have been on the main branch for a while, I don't expect any new issues. Thanks. Should we mention these changes in NEWS? (Any suggested text?) Not sure it is worth it. BUGS fixed - #include tweaks for C++ portability. MISC - New testcase to detect compilers with broken exception support. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Moving C++ bindings in gmpxx.h into a namespace
On Sat, 29 Jun 2013, Sam Varshavchik wrote: Is there any interest in moving all the C++ bindings into their own namespace, say gnu::mp? Vaguely. Preferably at the same time as some other ABI-breaking changes. This is popular with many C++ dev libraries, like boost, for example. There are several advantages with doing that; mainly reducing the risk of clashing with application's own symbols, or even with symbols from other libraries that an app also links to. The risk of clashing is very low. We currently use the old C namespacing technique of giving all names an application-specific prefix (plus we illegally put most names in the implementation namespace). Did you hit a particular issue or are you just suggesting it because it sounds good? I can prepare a patch to do that, if there's interest. Compatibility with existing code is trivial. Binary compatibility is trivially broken. And some odd programs would also fail to compile (though that might be acceptable). Either provide a separate file that existing code can include, that contains a grand total of three typedefs: typedef gnu::mp::mpz_class mpz_class; typedef gnu::mp::mpf_class mpf_class; typedef gnu::mp::mpq_class mpq_class; You forgot gmp_randclass at least (and using is shorter than typedef). Or, for 100% source backwards compatibility, rename gmpxx.h to something else, and have it declare everything in gnu::mp, and replace gmpxx.h with a stub that includes the real file, and provides the three typedefs. I'd probably import the names to the global namespace by default anyway, so no point complicating things too much. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: [PATCH] Fix common typos.
On Sun, 21 Jul 2013, Ondřej Bílka wrote: One of things that benefit from economy of scale is fixing typos. Below is patch that fixes 99 typos and it was fast to generate. coproccessor ?? I think you can drop the capitalization parts of the checker, they are not that useful and sometimes plain wrong when they refer to the name of a file (sparc.md for instance). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
automake -a
Hello, on a machine with more recent autotools, they complain that for instance our missing script is too old. It seems that it would be easiest to do what the comment in .bootstrap says, remove those files from the repository and use automake -a to make sure we have a consistent version of everything (no -f so it doesn't override our specific INSTALL, config.guess, etc). So I would like to apply the following: remove: doc/mdate-sh doc/texinfo.tex install-sh missing ylwrap --- a/.bootstrapSat Sep 21 01:48:10 2013 +0200 +++ b/.bootstrapSat Sep 21 10:42:52 2013 +0200 @@ -1,14 +1,9 @@ #! /bin/sh -# FIXME: Use automake -a? Then we could remove various -# automake-supplied files from the repository. - # We need to remove the cache, else things are not regenerated properly rm -rf autom4te.cache -# Stick to automake-1.8, since later versions require the ylwrap -# script. -aclocal libtoolize autoconf autoheader automake +aclocal libtoolize autoconf autoheader automake -a cat doc/version.texi EOF @set UPDATED 19 January 2038 I am getting a few errors in the testsuite on shell at the moment (the same that appear in the GMP testresults page) so I'll wait until that settles a bit. With recent autotools, we still get plenty of messages: Makefile.am:126: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS') Makefile.am:278: warning: source file 'cxx/dummy.cc' is in a subdirectory, Makefile.am:278: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. cxx/Makefile.am:21: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS') demos/Makefile.am:24: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS') [... repeated for all directories] But I guess those can wait. Comments? -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: automake -a
On Mon, 23 Sep 2013, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: It seems that it would be easiest to do what the comment in .bootstrap says, remove those files from the repository and use automake -a to make sure we have a consistent version of everything (no -f so it doesn't override our specific INSTALL, config.guess, etc). Makes sense to me, as long as removing files in the repo is decided on a case-by-case basis. Do you agree with the initial list I proposed? E.g., I think the COPYING file should stay in the repo, even if automake -a currently installs an identical file. Ah, I hadn't noticed COPYING, precisely because the file is identical ;-) Ok with keeping it if you want to... I did an automake -a -c -f, followed by hg status to see what had changed, and pruned that list a bit. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: automake -a
On Mon, 23 Sep 2013, Vincent Lefevre wrote: On 2013-09-23 15:37:20 +0200, Marc Glisse wrote: On Mon, 23 Sep 2013, Niels Möller wrote: E.g., I think the COPYING file should stay in the repo, even if automake -a currently installs an identical file. Ah, I hadn't noticed COPYING, precisely because the file is identical ;-) Ok with keeping it if you want to... I think that you must keep it: you choose the license, not the autotools developers. I would assume that the autotools get the information on which licence is wanted from somewhere and don't add a random licence, but keeping it sounds natural indeed. I did an automake -a -c -f, followed by hg status to see what had changed, and pruned that list a bit. How about doing something like the autogen.sh script proposed by Daniel Richard G. for MPFR: #!/bin/sh # autoreconf -f will clobber our INSTALL file with a generic one if we # don't move it out of the way mv -f INSTALL INSTALL.$$.tmp autoreconf -v -f -i -W all rm -f INSTALL mv -f INSTALL.$$.tmp INSTALL rm -rf autom4te.cache We could. I think avoiding -f is safer. Starting from a clean checkout when you upgrade your autotools isn't that hard. I hadn't realized that autoreconf -i -s would call automake -a, which is good. So a minimal change to use autoreconf -i -s instead of our current long line would be nice. A script could also be used to get the latest config.guess as configfsf.guess, but we probably don't want that (have to make sure it interacts ok with the specialized config.guess). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: automake -a
On Mon, 23 Sep 2013, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Do you agree with the initial list I proposed? I don't think I've seen an explicit list. remove: doc/mdate-sh doc/texinfo.tex install-sh missing ylwrap -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: A contribution to GMP
On Wed, 23 Oct 2013, Lukasz Komsta wrote: I know about MPFR and noticed some time ago that it contains such functions, but I have not tested this library as I had no time to switch my codes to it. However, I will do it soon. I developed my functions during several long evenings to deal with some problems on computational cluster with installed GMP, not forcing administrator to install MPFR. I do not know if there is a trend to suspend GMP in floating point partand urge users to switch to MPFR - if so, my work was only for fun. However, I cannot deduce such feeling from GMP page On the homepage gmplib.org: Externally supported: High-level floating-point accurately rounding arithmetic functions (mpfr). See the mpfr site for more information. Starting with GMP 4.2, mpfr is released separately from GMP. (New projects should consider using mpfr instead of GMP's own mpf.) and plans page include developing of such functions. The projects.html page? Below that item, it says Note that the mpfr functions already provide these functions, and that we usually recommend new programs to use mpfr instead of mpf. In my opinion, it doesn't make sense to duplicate the work in GMP and MPFR and that item should disappear, but I am only speaking for myself here, you can wait and see if others have comments. If they can be somehow used, its my pleasure. Maybe some parts of the code could be used to improve some MPFR functions? I am just installing MPFR under Cygwin and will play a bit with MPFR, noticing about my conclusions. Let us (and the mpfr developers) know how it goes. Thanks again for contributing, -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Including limits.h in gmp-impl.h
Hello, trying to compile gmp with clang, I got this error in the C++ testsuite: In file included from /usr/include/limits.h:152: /usr/include/x86_64-linux-gnu/bits/xopen_lim.h:97:7: error: token is not a valid binary operator in a preprocessor subexpression # if INT_MAX == 2147483647 ^~~ /data/repos/gmp/gmp-impl.h:579:31: note: expanded from macro 'INT_MAX' #define INT_MAX(-(INT_MIN+1)) ^~~ /data/repos/gmp/gmp-impl.h:576:35: note: expanded from macro 'INT_MIN' #define INT_MIN((int) UINT_HIGHBIT) ~ ^ /data/repos/gmp/gmp-impl.h:564:28: note: expanded from macro 'UINT_HIGHBIT' #define UINT_HIGHBIT (UINT_MAX ^ ((unsigned) UINT_MAX 1)) ^ Something in the glibc headers doesn't like the gmp definitions of those macros. It is easily worked around by including limits.h in gmp-impl.h, but I see this comment: /* limits.h is not used in general, since it's an ANSI-ism, and since on solaris gcc 2.95 under -mcpu=ultrasparc in ABI=32 ends up getting wrong values (the ABI=64 values). On Cray vector systems, however, we need the system limits.h since sizes of signed and unsigned types can differ there, depending on compiler options (eg. -hnofastmd), making our SHRT_MAX etc expressions fail. For reference, int can be 46 or 64 bits, whereas uint is always 64 bits; and short can be 24, 32, 46 or 64 bits, and different for ushort. */ #if defined _CRAY #include limits.h #endif So even using autoconf to check if limits.h exists may not be enough. Or can we ignore the old solaris issue? -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Including limits.h in gmp-impl.h
Oups, looks like I already asked about that: https://gmplib.org/list-archives/gmp-bugs/2011-November/002443.html and the reply was to try including tests.h before gmp-impl.h. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Including limits.h in gmp-impl.h
On Fri, 27 Dec 2013, Torbjorn Granlund wrote: Marc Glisse marc.gli...@inria.fr writes: I couldn't find anything other than the -mcpu=ultrasparc ABI=32 issue with gcc-2.9x around 1999-2000. I haven't looked deeply into this issue, but to me it seems strange that we define INT_MAX etc ourselves. I think we might trust limits.h these days. If a 15 year old system then gets desupported, too bad. Then I am considering pushing the attached patch soon. -- Marc Glissediff -r 709a37323927 ChangeLog --- a/ChangeLog Fri Dec 27 07:50:29 2013 +0100 +++ b/ChangeLog Fri Dec 27 15:02:47 2013 +0100 @@ -1,3 +1,9 @@ +2013-12-27 Marc Glisse marc.gli...@inria.fr + + * configure.ac: Test for limits.h. + * gmp-impl.h: Include limits.h if available. + * tests/mpn/t-get_d.c: Remove comment about limits.h + 2013-12-26 Marco Bodrato bodr...@mail.dm.unipi.it * Update many file's encoding to UTF-8. diff -r 709a37323927 configure.ac --- a/configure.ac Fri Dec 27 07:50:29 2013 +0100 +++ b/configure.ac Fri Dec 27 15:02:47 2013 +0100 @@ -2597,7 +2597,7 @@ # inttypes.h, stdint.h, unistd.h and sys/types.h are already in the autoconf # default tests # -AC_CHECK_HEADERS(fcntl.h float.h invent.h langinfo.h locale.h nl_types.h sys/attributes.h sys/iograph.h sys/mman.h sys/param.h sys/processor.h sys/pstat.h sys/sysinfo.h sys/syssgi.h sys/systemcfg.h sys/time.h sys/times.h) +AC_CHECK_HEADERS(fcntl.h float.h invent.h langinfo.h limits.h locale.h nl_types.h sys/attributes.h sys/iograph.h sys/mman.h sys/param.h sys/processor.h sys/pstat.h sys/sysinfo.h sys/syssgi.h sys/systemcfg.h sys/time.h sys/times.h) # On SunOS, sys/resource.h needs sys/time.h (for struct timeval) AC_CHECK_HEADERS(sys/resource.h,,, diff -r 709a37323927 gmp-impl.h --- a/gmp-impl.hFri Dec 27 07:50:29 2013 +0100 +++ b/gmp-impl.hFri Dec 27 15:02:47 2013 +0100 @@ -36,9 +36,9 @@ #include intrinsics.h /* for _popcnt */ #endif -/* limits.h is not used in general, since it's an ANSI-ism, and since on - solaris gcc 2.95 under -mcpu=ultrasparc in ABI=32 ends up getting wrong - values (the ABI=64 values). +/* For INT_MAX, etc. We used to avoid it because of a bug (on solaris, + gcc 2.95 under -mcpu=ultrasparc in ABI=32 ends up getting wrong + values (the ABI=64 values)), but it should be safe now. On Cray vector systems, however, we need the system limits.h since sizes of signed and unsigned types can differ there, depending on compiler @@ -46,7 +46,7 @@ reference, int can be 46 or 64 bits, whereas uint is always 64 bits; and short can be 24, 32, 46 or 64 bits, and different for ushort. */ -#if defined _CRAY +#if HAVE_LIMITS_H #include limits.h #endif diff -r 709a37323927 tests/mpn/t-get_d.c --- a/tests/mpn/t-get_d.c Fri Dec 27 07:50:29 2013 +0100 +++ b/tests/mpn/t-get_d.c Fri Dec 27 15:02:47 2013 +0100 @@ -17,12 +17,6 @@ You should have received a copy of the GNU General Public License along with the GNU MP Library test suite. If not, see https://www.gnu.org/licenses/. */ -/* Note that we don't use limits.h for LONG_MIN, but instead our own - definition in gmp-impl.h. In gcc 2.95.4 (debian 3.0) under - -mcpu=ultrasparc, limits.h sees __sparc_v9__ defined and assumes that - means long is 64-bit long, but it's only 32-bits, causing fatal compile - errors. */ - #include config.h #include setjmp.h ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Including limits.h in gmp-impl.h
On Fri, 27 Dec 2013, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Then I am considering pushing the attached patch soon. Do we really need a configure test? No idea. It seemed safer, and since we already have fallback code... On the other hand, mini-gmp seems happy enough with limits.h. If we really want to assume limits.h exists and works, there is more cleanup that can be done in gmp-impl.h (remove the fallback code for INT_MAX etc). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: TODO for 5.2
Hello, on my machine, I am getting: doc/gmp.texi:5807: must be after `@deftypefun' to use `@deftypefunx' (that's mpn_sec_minvert_itch) though it looks like it works fine on shell. It is happier if we remove the newline in the middle of the @deftypefun. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Including limits.h in gmp-impl.h
On Thu, 2 Jan 2014, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: I'll also push a patch handling the fact that the standard SHRT_MAX and others don't have type short but int. Can you explain what the problem is? I noticed this change, --- a/gmp-h.in Thu Jan 02 12:28:21 2014 +0100 +++ b/gmp-h.in Thu Jan 02 13:25:31 2014 +0100 @@ -437,10 +437,10 @@ #define __GMP_MAX(h,i) ((h) (i) ? (h) : (i)) /* __GMP_USHRT_MAX is not ~ (unsigned short) 0 because short is promoted - to int by ~. */ + to int by ~. It still needs to have the promoted type. */ #define __GMP_UINT_MAX (~ (unsigned) 0) #define __GMP_ULONG_MAX (~ (unsigned long) 0) -#define __GMP_USHRT_MAX ((unsigned short) ~0) +#define __GMP_USHRT_MAX (0 + (unsigned short) ~0) Questions: 1. Why should it be of type int? Which problems are caused by having it as unsigned short? 2. If int is desired, I think it's a bit clearer with an explicit cast, #define __GMP_USHRT_MAX ((int) (unsigned short) ~0) But, unconditionally defining it as int also seems unportable. A C implementation may define both short and int to be 32 bits, right? Then the maximum unsigned short doesn't fit in a signed int. While it would always fit in an *unsigned* int. Is that what the 0 + promotion thing is intended to do; you know the spec a better than me, but you'd get unsigned int if short and int are of the same size, and signed int if it's of larger size than short? I miss a comment spelling out which type really is intended, and why. You have pretty much said everything already ;-) C99 (it's the only version I have here) says about SHRT_MAX and others: the following shall be replaced by expressions that have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. integer promotion for a short means int, and for an unsigned short it means either int or unsigned int depending on their relative size. 0 + is indeed a random way to force type promotion (note the sentence I added in the comment above __GMP_USHRT_MAX). I made the change so that the type of USHRT_MAX is the same whether it comes from limits.h or from gmp. The type is mostly irrelevant, except that we have a few printf calls in the testsuite where we were using %hX. For gmp-5.3 (not this one, the one after that), I think we should remove __GMP_USHRT_MAX altogether and forcibly include limits.h in gmp.h (it isn't comparable to stdio.h). We would also remove all the related code in gmp-impl.h, and half of my patch would become irrelevant. (I didn't want to do it so close to the release, but it would only take a few minutes if you want me to do it for 5.2) So, do you agree with the change? (care to add a suitable comment?) Or would you prefer a different change? -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Massive failure
On Fri, 3 Jan 2014, Torbjorn Granlund wrote: Marc Glisse marc.gli...@inria.fr writes: That's sad, I was hoping to use limits.h more in GMP :-( I'd still like to find out what is broken, see if we can work around it without disabling the whole thing. Let's desupport ABI=32 on amd64 chips under FreeBSD 9 and earlier. Ah... ok. That sure simplifies my task ;-) -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Should we declare _itch functions __GMP_NOTHROW __GMP_ATTRIBUTE_PURE ?
On Sun, 5 Jan 2014, bodr...@mail.dm.unipi.it wrote: Ciao, Il Dom, 5 Gennaio 2014 5:06 pm, Torbjorn Granlund ha scritto: bodr...@mail.dm.unipi.it writes: Indeed. I pushed a fix. Any comment about marking them also with __GMP_NOTHROW ? Perhaps that too. I suppose __GMP_ATTRIBUTE_PURE should really be the stronger ATTRIBUTE_CONST, except that we don't yet have any name space clean way of doing that for gmp.h. But we have it in gmp-impl.h, I pushed this change. Are there compilers that have the attribute pure and not the attribute const? In case, should we use pure as a fallback? With something like this patch? From the doc, it seems that gcc had attribute const in 2.5 and pure in 2.9x, so I am not sure why we go through all this trouble for const (autoconf, etc), I would just define __GMP_ATTRIBUTE_CONST in gmp-h.in next to __GMP_ATTRIBUTE_PURE and use it also for the itch functions in that file. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: TODO for 5.2 v3
On Wed, 15 Jan 2014, Niels Möller wrote:
Torbjorn Granlund t...@gmplib.org writes:
The volatile qualifier makes sure the number of memory reads and memory
writes remain unchanged from the source code.
Question is, when is it useful for our purposes? First example,
mpn_sec_add_1:
mp_limb_t
mpn_sec_add_1 (mp_limb_t *rp, mp_limb_t *ap, mp_size_t n, mp_limb_t b,
mp_ptr scratch)
{
scratch[0] = b;
MPN_ZERO (scratch + 1, n-1);
return mpn_add_n (rp, ap, scratch, n);
}
volatile probably makes no difference here, as far as I see (except
possibly if there's some global optimization which inlines mpn_add_n).
But maybe we should still declare some or all of the parameters (rp, ap,
scratch) as pointing to volatile data?
I doubt that it would help, but I could be wrong.
Or would that give type conversion warnings when calling mpn_add_n, with
parameters which aren't volatile-declared? I'm not entirely sure what
volatile means, if it's only giving the compiler some constraints for
the *implementation* of a function, or if volatile in a function
*prototype* also affects type checking or code generation in callers in
some way.
From a type POV, volatile works like 'const', you can't strip it away.
Second example,
void
mpn_cnd_swap (mp_limb_t cnd,
mp_limb_t *ap, mp_limb_t *bp, mp_size_t n)
{
mp_limb_t mask = - (mp_limb_t) (cnd != 0);
mp_size_t i;
for (i = 0; i n; i++)
{
mp_limb_t a, b, t;
a = ap[i];
b = bp[i];
t = (a ^ b) mask;
ap[i] = a ^ t;
bp[i] = b ^ t;
}
}
Here a compiler might be tempted to do an initial branch on cnd != 0,
and skip the loop if cnd is false. Using volatile for ap and bp gives it
less reason to do so, but I guess even with volatile it may still
generate code equivalent to
if (cnd)
for (i = 0; i n; i++)
{
mp_limb_t a, b, t;
a = ap[i];
b = bp[i];
ap[i] = b;
bp[i] = a;
}
else
for (i = 0; i n; i++)
{
mp_limb_t a, b, t;
a = ap[i];
b = bp[i];
ap[i] = a;
bp[i] = b;
}
which leaks through the cache.
So is it useful or not to volatile-declare ap and bp here?
volatile mp_limb_t b = cnd != 0;
mp_limb_t mask = -b;
The compiler is still allowed to do b=cnd?1:0 with a branch, but the
volatile blocks any kind of constant propagation, the compiler can't
assume that the value it reads from b is in any way related to what it
just wrote there.
Note that even if mask doesn't come from a condition, the compiler is
allowed to test if mask is 0 or -1 and generate special code for those
cases, so you can't escape either writing asm or compiling with
not-too-extreme optimizations with your fingers crossed.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
On Tue, 21 Jan 2014, Niels Möller wrote: There's a ChangeLog entry from the day before yesterday: * doc/gmp.texi: Undocument mpz_array_init. Thanks, I hadn't seen it yet. One can still use mpz_realloc2, which can be viewed as an allocation hint to the gmp implementation (so in mini-gmp, it's harmless but also mostly useless, due to the frequent use of mpz_swap). I was talking of the case where I already have a preexisting buffer I want to use as _mp_d, I don't want to allocate a new one with mpz_realloc2. That seems to be a few steps further than the new limb interface goes, and I can understand not wanting to support that. Playing with mp_set_memory_functions, there is a complicated way to use a preexisting buffer without breaking if I am using mini-gmp, but having 2 versions of the code still seems simpler and more efficient (and that's all unsupported anyway). I guess it would be hard to make an official interface that lets users reimplement __GMPXX_TMPZ_D. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
On Tue, 21 Jan 2014, Niels Möller wrote: No, the new limb interface can only do it the other way round. If you want to use a buffer as mpz_t output, and access it with low-level fucntions too, you have give the reponsibility for allocating it to _mpz_realloc, and write the code to tolerate that any use of the buffer as an mpz_t output might do an unexpected reallocation. Up to now, we have always kind of promised that if there was enough margin in the output variables, there wouldn't be any unexpected reallocation. When does this situation arise? __GMPXX_TMPZ_D, for instance. But this is mostly a speed issue, we shouldn't reallocate when it is obviously unneeded. I guess I got confused between what is a guideline for us (don't reallocate) and what is promised in the doc (don't bother specifying when reallocation may happen: always), so we can drop this. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
On Thu, 6 Feb 2014, Niels Möller wrote: ni...@lysator.liu.se (Niels Möller) writes: For mpn_set_d, I think it would make some sense to have it return a base-2 exponent, and write the mantissa to a few limbs. Number of limbs would be a constant, part of the ABI, similar to LIMBS_PER_DOUBLE but renamed for external use. mp_bitcnt_t mpn_set_d (mp_limb_t rp[LIMBS_PER_BOUBLE], d); Below is a patch to do this (and return value is long, not mp_bitcnt_t, since it needs to be signed). Thanks. What do you think? (I haven't looked at it much yet) Why not return int, since int is what we use for _mp_size? Is 53 really safe for non-IEEE double? Maybe something based on DBL_MANT_DIG, assuming that FLT_RADIX==2? I don't think we are still supporting gcc-2.8... From a performance POV, it may not be optimal to split the sign/infinity/nan/zero test from the rest, but I agree 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/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
On Thu, 6 Feb 2014, Niels Möller wrote:
Vincent Lefevre vinc...@vinc17.net writes:
Yes. If you want to differentiate between NaN and infinities:
d != d is true only for NaN.
I'm looking at the definition of DOUBLE_NAN_INF_ACTION in gmp-impl.h.
Maybe it could be simplified to a single, unconditional, definition
Note that there exist standard functions like isfinite.
#define DOUBLE_NAN_INF_ACTION(x, a_nan, a_inf) \
do { \
if (UNLIKELY ((x) - (x) != 0.0)) \
{ \
if ((x) != (x)) { a_nan; } \
else { a_inf; } \
} \
} while (0)
Does any of the current three definitions have any advantage over the
above portable one? I would hope that the above is
* no slower then the _GMP_IEEE_FLOATS definition (which extracts the
exponent via a union).
Are you sure about that? If x is a denormal, x-x may take a very long time
to compute.
* equivalent to the NOP definition for VAX; then x - x != 0.0 should be
always false, and the compiler ought to know.
* faster than the generic version, which implies a sequence of three
(false) tests in the common case.
I'm tempted to
1. Replace the DOUBLE_NAN_INF_ACTION macro.
2. Check in the mpn_set_d changes (possibly with smaller tweaks).
3. Make mpn_get_d public, and document both functions.
Ok? Or should this wait until after 5.2?
I would have been in favor of avoiding new features less than a couple
months before the release, but since there are already plenty of *sec*
changes going on...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
On Thu, 6 Feb 2014, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Note that there exist standard functions like isfinite. But so far, we don't use any libm functions in gmp. True. * no slower then the _GMP_IEEE_FLOATS definition (which extracts the exponent via a union). Are you sure about that? I'm not sure about anything... I'd expect that moving floating point values to integer registers (or to memory) is often slow. If x is a denormal, x-x may take a very long time to compute. I don't think the case of denormals is very important for performance. And there's a bit-by-bit normalization loop for that case later on. How long is very long? 10 cycles? 100 cycles? I don't know exactly. I looked into it some time ago, there are some links at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57056 in the first comment. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: allocated blocks holding pointers to other allocated blocks
On Wed, 5 Mar 2014, David Warme wrote: The GMP manual on Custom Allocation contains the following paragraph: GMP may use allocated blocks to hold pointers to other allocated blocks. This will limit the assumptions a conservative garbage collection scheme can make. Questions: 1. This seems like a situation that can only exist while certain GMP routines are active in the call stack context -- if no GMP function is active, then this situation will not exist, correct? That's not obvious to me. 2. What places within GMP use this technique (pervasive, 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 ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Compiling GMP with clang
On Sat, 29 Nov 2014, Torbjörn Granlund wrote:
3. Link errors on some arm32 systems. We have not investigates this.
Help is welcome. Failure log:
https://gmplib.org/devel/testmachines/build/failure/armv5.gmplib.org-stat-clang-clang++:standard.txt
#include stdexcept
int main(){throw std::invalid_argument(hello);}
$ clang++ -target arm-linux-gnueabi main.cc
$ clang++ -target arm-linux-gnueabi main.cc -O -latomic
$ clang++ -target arm-linux-gnueabi main.cc -O
/tmp/main-d6b7a1.o: In function `main':
main.cc:(.text+0x84): undefined reference to `__atomic_fetch_add_4'
It should 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
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
TMP_ALLOC in C++
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 tests_end.
(for the tal-debug.c patch, it may be simpler to change the type of block
to void* in gmp-impl.h)
--
Marc Glissediff --git a/gmp-impl.h b/gmp-impl.h
--- a/gmp-impl.h
+++ b/gmp-impl.h
@@ -5150,16 +5150,53 @@ mpn_toom54_mul_itch (mp_size_t an, mp_si
#if 0
#define mpn_fft_mul mpn_mul_fft_full
#else
#define mpn_fft_mul mpn_nussbaumer_mul
#endif
#ifdef __cplusplus
+/* Handle C++ exceptions. */
+#if !WANT_TMP_DEBUG || __cplusplus = 201103L
+struct gmp_tmp_salloc_t {
+ /* May warn in pedantic mode when TMP_SDECL is empty. */
+ TMP_SDECL;
+ gmp_tmp_salloc_t(){ TMP_SMARK; }
+ void*salloc(size_t n){ return TMP_SALLOC(n); }
+ ~gmp_tmp_salloc_t(){ TMP_SFREE; }
+};
+struct gmp_tmp_alloc_t {
+ TMP_DECL;
+ gmp_tmp_alloc_t(){ TMP_MARK; }
+ void*salloc(size_t n){ return TMP_SALLOC(n); }
+ void*balloc(size_t n){ return TMP_BALLOC(n); }
+ void*alloc(size_t n){ return TMP_ALLOC(n); }
+ ~gmp_tmp_alloc_t(){ TMP_FREE; }
+};
+#undef TMP_SDECL
+#undef TMP_DECL
+#undef TMP_SMARK
+#undef TMP_MARK
+#undef TMP_SALLOC
+#undef TMP_BALLOC
+#undef TMP_ALLOC
+#undef TMP_SFREE
+#undef TMP_FREE
+#define TMP_SDECL
+#define TMP_DECL
+#define TMP_SMARK gmp_tmp_salloc_t gmp_tmp_alloc
+#define TMP_MARK gmp_tmp_alloc_t gmp_tmp_alloc
+#define TMP_SALLOC(n) gmp_tmp_alloc.salloc(n)
+#define TMP_BALLOC(n) gmp_tmp_alloc.balloc(n)
+#define TMP_ALLOC(n) gmp_tmp_alloc.alloc(n)
+#define TMP_SFREE
+#define TMP_FREE
+#endif
+
/* A little helper for a null-terminated __gmp_allocate_func string.
The destructor ensures it's freed even if an exception is thrown.
The len field is needed by the destructor, and can be used by anyone else
to avoid a second strlen pass over the data.
Since our input is a C string, using strlen is correct. Perhaps it'd be
more C++-ish style to use std::char_traitschar::length, but char_traits
isn't available in gcc 2.95.4. */
diff --git a/mpf/get_str.c b/mpf/get_str.c
--- a/mpf/get_str.c
+++ b/mpf/get_str.c
@@ -175,16 +175,17 @@ mpf_get_str (char *dbuf, mp_exp_t *exp,
if (un == 0)
{
*exp = 0;
*dbuf = 0;
n_digits = 0;
goto done;
}
+ {
TMP_MARK;
/* Allocate temporary digit space. We can't put digits directly in the user
area, since we generate more digits than requested. (We allocate
2 * GMP_LIMB_BITS extra bytes because of the digit block nature of the
conversion.) */
tstr = (unsigned char *) TMP_ALLOC (n_digits + 2 * GMP_LIMB_BITS + 3);
@@ -312,16 +313,17 @@ mpf_get_str (char *dbuf, mp_exp_t *exp,
if (SIZ(u) 0)
{
dbuf[0] = '-';
n_digits++;
}
TMP_FREE;
+ }
done:
/* If the string was alloced then resize it down to the actual space
required. */
if (alloc_size != 0)
{
__GMP_REALLOCATE_FUNC_MAYBE_TYPE (dbuf, alloc_size, n_digits + 1, char);
}
diff --git a/tal-debug.c b/tal-debug.c
--- a/tal-debug.c
+++ b/tal-debug.c
@@ -103,17 +103,17 @@ void *
{
__gmp_assert_header (file, line);
fprintf (stderr, GNU MP: TMP_ALLOC without TMP_MARK(%s)\n, decl_name);
abort ();
}
p = __GMP_ALLOCATE_FUNC_TYPE (1, struct tmp_debug_entry_t);
p-size = size;
- p-block = (*__gmp_allocate_func) (size);
+ p-block = (char*) (*__gmp_allocate_func) (size);
p-next = mark-list;
mark-list = p;
return p-block;
}
void
__gmp_tmp_debug_free (const char *file, int line, int dummy,
struct tmp_debug_t **markp,
diff --git a/tests/mpn/logic.c b/tests/mpn/logic.c
--- a/tests/mpn/logic.c
+++ b/tests/mpn/logic.c
@@ -57,78 +57,80 @@ check_one (mp_srcptr refp, mp_srcptr rp,
int
main (int argc, char **argv)
{
mpz_t a, b;
mp_ptr ap, bp, rp, refp;
mp_size_t max_n, n, i;
gmp_randstate_ptr rands;
long test, reps = 1000;
- TMP_DECL;
- TMP_MARK;
+ {
+TMP_DECL;
+TMP_MARK;
- tests_start ();
- TESTS_REPS (reps, argv, argc);
+tests_start ();
+TESTS_REPS (reps, argv, argc);
- mpz_inits (a, b, NULL);
+mpz_inits (a, b, NULL);
- rands = RANDS; /* FIXME: not used */
+rands = RANDS; /* FIXME: not used */
- max_n = 100;
+max_n = 100;
- rp = TMP_ALLOC_LIMBS (1 + max_n * 8 / GMP_LIMB_BITS);
- refp = TMP_ALLOC_LIMBS (1 + max_n * 8 / GMP_LIMB_BITS);
+rp = TMP_ALLOC_LIMBS (1 + max_n * 8 / GMP_LIMB_BITS);
+refp = TMP_ALLOC_LIMBS (1 + max_n * 8 / GMP_LIMB_BITS);
- for (test = 0; test reps; test++)
-{
- for (i = 1; i = max_n; i++)
- {
- mpz_rrandomb (a, rands, i * 8);
- mpz_rrandomb (b, rands, i * 8);
- mpz_setbit (a, i * 8 - 1);
- mpz_setbit (b, i * 8 - 1);
-
C++ factorial error reporting
Hello,
I am trying to add factorial to the C++ interface, and since GMP only
provides mpz_fac_ui, I end up having to check and report errors directly.
Any preferences?
Calling factorial on a negative integer doesn't make sense, we could have
assert(number = 0). I am throwing an exception because that seems a
little friendlier, but I am still choosing one that derives from
logic_error.
Calling factorial on a number that is a bit too large is a different
issue. overflow_error is the natural exception when trying to convert an
mpz_class to an unsigned long if it will not fit. But even if it fits, it
may still be too big and mpz_fac_ui may fail, in the allocation function,
which might abort but a natural replacement would throw bad_alloc. I don't
think it makes that much sense to have a different exception depending on
who notices that the number is too big, which is why I was also
considering throwing bad_alloc instead of overflow_error.
We could also pick a single exception and throw it for both negative and
too-big.
(you can check the list of standard exceptions at
http://en.cppreference.com/w/cpp/error/exception , defining our own
exception type doesn't seem worth the trouble)
struct __gmp_factorial_function
{
static void eval(mpz_ptr z, mpz_srcptr w)
{
if (mpz_sgn(w) 0)
throw std::domain_error (factorial(negative));
// There is no point trying to compute such a huge number.
if (!mpz_fits_ulong_p(w))
throw std::overflow_error (factorial); // or std::bad_alloc()?
eval(z, mpz_get_ui(w));
}
static void eval(mpz_ptr z, unsigned long int l) { mpz_fac_ui(z, l); }
static void eval(mpz_ptr z, signed long int l)
{
if (l 0)
throw std::domain_error (factorial(negative));
eval(z, 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
Re: Adding support for R6 of MIPS architecture
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@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Additional memory handler features.
On Sun, 4 Jan 2015, Victor Shoup wrote: But I see mention of itching and scratching: could somebody describe what that is or provide a link? Sorry for my ignorance. and sorry for the length of this post The general idea is to push all operations that may fail or otherwise require customization to user code. There would be a function mpn_mul_itch that would tell you how much temporary (scratch) space mpn_mul may need, and mpn_mul would take as argument a pointer to a buffer of at least this size. Allocation is the user's responsibility. There should already be a few functions or macros with itch in their name. [FULL DISCLOSURE: my own, somewhat narrow and selfish goal is to see GMP's mpn-level routines throw exceptions, rather than abort, with no interface changes. This is what would work best for my own NTL library] mpn functions have few reasons to abort. Except for allocation failure, as long as you checked the operands before passing them to GMP... [And yet another issue: my understanding is that some OS's actually have rather weird ways of dealing with out-of-memory errors: malloc always succeeds and returns a non-null pointer, but indirecting through 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 ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP and clang bugginess
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/show_bug.cgi?id=23646 ). Note that the same (?) instruction is spelled differently in the same file: bc+ 12, 28, L(9) vs. blt+cr7, L(24) (there is also a mix of using 7 vs cr7) and llvm is happy with the second form. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP and clang bugginess
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+cr7, L(24) Note that the former form works with clang 3.5 installs. A 3.6 regression? Indeed... (there is also a mix of using 7 vs cr7) and llvm is happy with the second form. Please point me to the place where 7 is used. Ah, no, my mistake, I got confused by the preprocessing. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP and clang bugginess
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: bc+ 12, 28, L(9) vs. blt+cr7, L(24) Note that the former form works with clang 3.5 installs. A 3.6 regression? Indeed... Er, actually, that's just the time when they enabled the integrated 'as' by default, 3.5 was using binutils. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP and clang bugginess
On Thu, 21 May 2015, Torbjörn Granlund wrote: GMP triggers bugs in clang on every platform where we tried this compiler. Some configs work, though. To see how bad it is, please take a look here: https://gmplib.org/devel/tm-date.html I think we would help our users by making it hard to use clang with the next release. What do you think? My idea is to reject clang with an error message along these lines: error: clang is not able to correctly compile GMP. To override, use --enable-clang. Make sure to run make check and don't use the library of this fails. It is your call, but that seems a bit excessive to me. I just did a few tests with clang-3.6. It seems to work fine on x86_64, so probably on macs, where it is the default compiler and a large part of the user base is. 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. aarch64-linux-gnu and arm-linux-gnueabihf are working fine for me. powerpc64le-linux-gnu seems broken indeed. I tend to consider that the usual run the testsuite message is sufficient, possibly 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
mp_bitcnt_signed_t
Hello, mpz_get_d_2exp and mpf_get_d_2exp currently take as argument a long*. Since we introduced a type mp_bitcnt_t, I guess it would make sense to add mp_bitcnt_signed_t and use it there. Any objection? For the mpz case, the answer should always be nonnegative, so we could use an unsigned type if we wanted, but I guess it is better to keep the current signed type, which is consistent with the mpf case. What do you think of introducing 2 typedefs mp_builtin_[su]i (or mp_native_[su]i or gmp_[su]i or whatever) and using them in all the functions with _si or _ui in their name ? Just 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
Re: mpq_cmp_z
On Thu, 20 Aug 2015, Marco Bodrato 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 have: mpz_srcptr op2n = NUM(op2); and then use SIZ(op2n) instead of directly SIZ(NUM(op2)). The reason is that as long as you are only doing pointer arithmetic (NUM counts as pointer arithmetic), the exact type is kind of irrelevant (size matters as a multiplicative factor, and alignment because it can make the result invalid, but that's it), but as soon as you actually use it (load or store), you are making a promise that the type is right. So x=op2-_mp_den._mp_size promises that op2 points to a __mpq_struct while x=op2n-_mp_size only promises a __mpz_struct (and gcc folds * to nothing very early, so it sees SIZ(NUM(op2)) as the first expression). Note that my understanding could be wrong, and other compilers could have a different model. In practice, I doubt your code would fail, but with the generalization of link-time optimizations, the library and user code are not hidden from each other anymore, and surprising things could happen. The cast itself seems fine: A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning. 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 ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpq_cmp_z
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 have: mpz_srcptr op2n = NUM(op2); and then use SIZ(op2n) instead of directly SIZ(NUM(op2)). The reason is x=op2-_mp_den._mp_size promises that op2 points to a __mpq_struct while x=op2n-_mp_size only promises a __mpz_struct (and gcc folds * Maybe we can promise the right type, by adding an explicit cast? SIZ((mpz_srcptr) NUM(op2)) I think that cast would be ignored, you really want them in separate expressions. Another thing I forgot: computing DEN(op2) could also be illegal unless the layout of __mpq_struct is the same as __mpz_struct[2], in which case we are computing the past-the-end pointer of the mpz_t, which is ok. Anyway, I was just trying to think of potential issues with the code, feel free to ignore it as long as nobody reports an issue with it. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpq_cmp_z
On Fri, 21 Aug 2015, Torbjörn Granlund wrote: Marco Bodrato bodr...@mail.dm.unipi.it writes: Maybe we can promise the right type, by adding an explicit cast? SIZ((mpz_srcptr) NUM(op2)) Except that we should cast op2, not NUM(ops). I am not sure Marc's reasoning is accurate, nor am I suggesting it is not, I've forgotten this level of detail of the C standard. I am not too enthusiastic about passing the wrong type, but if we add casts both when going to mpq and when going back to mpz, I cannot see how that could break with a conforming compiler. Good point. I agree that (mpz_srcptr)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
Re: mpz_export to file?
On Wed, 9 Dec 2015, paul zimmermann wrote:
mpz_export() exports an integer to some allocated array. For saving huge
integers to a file, this is not optimal since one has first to allocate a
huge array in memory, "export" the mpz_t to that array, and then copy that
array to memory.
Can't you use mmap for that? (not arguing against your interface, just
wondering)
Would it be possible to have a function that exports directly to a file
(and of course the corresponding import function)?
void mpz_export_file (FILE *f, mpz_t op);
void mpz_import_file (mpz_t op, FILE *f);
One could imagine a format where several numbers can be exported in the same
file:
f = fopen ("toto", "w");
mpz_export_file (f, a);
mpz_export_file (f, b);
mpz_export_file (f, c);
fclose (f);
...
f = fopen ("toto", "r");
mpz_import_file (a, 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
Re: Lazy mpz allocation
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 mpz case, it is more for consistency.
--
Marc Glissediff -r 835f8974ff6e mpq/clear.c
--- a/mpq/clear.c Thu Apr 07 22:50:07 2016 +0200
+++ b/mpq/clear.c Mon Apr 11 11:42:59 2016 +0200
@@ -34,6 +34,7 @@
void
mpq_clear (mpq_t x)
{
- __GMP_FREE_FUNC_LIMBS (PTR(NUM(x)), ALLOC(NUM(x)));
+ if (ALLOC (NUM(x)))
+__GMP_FREE_FUNC_LIMBS (PTR(NUM(x)), ALLOC(NUM(x)));
__GMP_FREE_FUNC_LIMBS (PTR(DEN(x)), ALLOC(DEN(x)));
}
diff -r 835f8974ff6e mpq/clears.c
--- a/mpq/clears.c Thu Apr 07 22:50:07 2016 +0200
+++ b/mpq/clears.c Mon Apr 11 11:42:59 2016 +0200
@@ -41,7 +41,8 @@
do
{
- __GMP_FREE_FUNC_LIMBS (PTR(NUM(x)), ALLOC(NUM(x)));
+ if (ALLOC (NUM(x)))
+ __GMP_FREE_FUNC_LIMBS (PTR(NUM(x)), ALLOC(NUM(x)));
__GMP_FREE_FUNC_LIMBS (PTR(DEN(x)), ALLOC(DEN(x)));
x = va_arg (ap, mpq_ptr);
}
diff -r 835f8974ff6e mpq/init.c
--- a/mpq/init.cThu Apr 07 22:50:07 2016 +0200
+++ b/mpq/init.cMon Apr 11 11:42:59 2016 +0200
@@ -34,8 +34,9 @@
void
mpq_init (mpq_t x)
{
- ALLOC(NUM(x)) = 1;
- PTR(NUM(x)) = __GMP_ALLOCATE_FUNC_LIMBS (1);
+ static const mp_limb_t dummy_limb=0xc1a0;
+ ALLOC(NUM(x)) = 0;
+ PTR(NUM(x)) = (mp_ptr) _limb;
SIZ(NUM(x)) = 0;
ALLOC(DEN(x)) = 1;
PTR(DEN(x)) = __GMP_ALLOCATE_FUNC_LIMBS (1);
diff -r 835f8974ff6e mpq/set_si.c
--- a/mpq/set_si.c Thu Apr 07 22:50:07 2016 +0200
+++ b/mpq/set_si.c Mon Apr 11 11:42:59 2016 +0200
@@ -56,7 +56,7 @@
}
else
{
- PTR(NUM(dest))[0] = abs_num;
+ MPZ_NEWALLOC (NUM(dest), 1)[0] = abs_num;
SIZ(NUM(dest)) = num > 0 ? 1 : -1;
}
diff -r 835f8974ff6e mpq/set_ui.c
--- a/mpq/set_ui.c Thu Apr 07 22:50:07 2016 +0200
+++ b/mpq/set_ui.c Mon Apr 11 11:42:59 2016 +0200
@@ -52,7 +52,7 @@
}
else
{
- PTR(NUM(dest))[0] = num;
+ MPZ_NEWALLOC (NUM(dest), 1)[0] = num;
SIZ(NUM(dest)) = 1;
}
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: Move -DNO_ASM to config.h?
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 for its uses, and it is used only in C files as far as I can see. I sure hope we don't use NO_ASM inside asm files ;-) I was wondering if it was useful in the rest of the configure script, but it seems to be done late enough that it is unlikely. Moving it to config.h makes sense to me. If we move it, we have make sure that config.h is always included before longlong.h. Most files get config.h via gmp-impl.h. So, e.g., #include "longlong.h" followed by #include "gmp-impl.h" would break. longlong.h requires some types like UWtype which we provide in gmp-impl.h, so I am hoping that the inclusions are already handled properly. I think the autoconf manual recommends an explicit include of config.h (guarded by HAVE_CONFIG_H) first in every C file. We don't have to do it that way of course, just be aware that we depart from that convention. Thanks. autoconf is still rather unfamiliar to me (though at least it makes more sense than the cmake I am forced to use at work). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Move -DNO_ASM to config.h?
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 included -DNO_ASM. If we move NO_ASM to config.h, that also affects them (not that it should necessarily stop us). We could also define NO_ASM both in CFLAGS and config.h. It looks like gcc and clang only warn when redefining a macro to something different, they don't warn for -DNO_ASM with #define NO_ASM 1, so it wouldn't be so bad. In what way is it relevant to MPFR whether a GMP build included asm or not? I am guessing that, just like they want to use the exact same flags as GMP to compile (__GMP_CFLAGS), they also want to mimic this part of the build process. I don't know if their version of longlong.h is kept in sync with GMP's, 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. On the other hand, MPFR could probably add a --disable-assembly configure flag to define NO_ASM, so the user would just have to pass the same option to MPFR that he already passed to GMP. I currently think I'll go with just config.h (no CFLAGS). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: __uint128_t
On Wed, 23 Mar 2016, Victor Shoup wrote: This may be a bit off topic, but I figure the people on this list might know something about this. In some code I've been developing lately (NTL related, of course), I've been making more use of the __uint128_t type that is available on gcc (and its clang and icc clones). It's all ifdef'd properly, so I only use it when it actually works. Anyway, I find that on x86-64 machines and recent gcc's, the compiler does a pretty good job of code generation...much better than I recall some years ago. However, I was wondering about the 64-bit ARM machine. I don't have access to such a machine, but I tried some code out at https://gcc.godbolt.org (which is a very convenient site, by the way). I was somewhat surprised that the code generated there by gcc-4.8 for 64-bit ARM was terrible: a 64x64->128 mul gets mapped to a generic128x128->128 function call. You realize ARM64 barely existed at the time of gcc-4.8? If gcc-5, or better yet a snapshot of gcc-6, still generates suboptimal code, please report to https://gcc.gnu.org/bugzilla/ with a testcase, and the asm you would like gcc to generate instead. So I'm starting to question whether relying on __uint128_t is such a good idea. Maybe it would be better for me to isolate all of that code so that I can just drop in appropriate assembly (as in GMP's longlong.h), as an alternative. It is always a compromise... I could also ask gcc people what their plans for future optimizations in this area are, but I don't know who or where to ask. You could ask on g...@gcc.gnu.org, but reporting bugs when you see suboptimal code generated seems much more likely to get you answers, and by showing constructive interest it may spark further optimizations. 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
Re: Move -DNO_ASM to config.h?
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 code than the whole GMP. So, it is less likely that a user would want to disable asm from MPFR's copy of longlong.h. In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69134 ( https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00127.html ), users specifically wanted to disable MPFR's copy ;-) On the other hand, MPFR could probably add a --disable-assembly configure flag to define NO_ASM, so the user would just have to pass the same option to MPFR that he already passed to GMP. I don't think that such an option would really be useful (unless there is a demand for it). The user could still pass -DNO_ASM in CFLAGS. The drawback is that the user won't benefit from the default CFLAGS, but if he wants -DNO_ASM, this is quite specific so that he may not need the default CFLAGS anyway. Ok. I guess I saw --disable-assembly mostly as a way to document this, but probably NO_ASM is not worth documenting in MPFR. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Lazy mpz allocation
Hello, the function mpz_init could now be marked __GMP_NOTHROW. Do we want to do it? I could then propagate the change to the C++ wrapper, which would have a significant impact on the performance of std::vector for instance. On the other hand, this is a promise in the interface, going back 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
Re: Lazy mpz allocation
On Wed, 4 May 2016, Niels Möller wrote: t...@gmplib.org (Torbjörn Granlund) writes: I forgot about that we need to have an explicit denominator. We could surely point that to some static read-only data, but that would of course incur a cost when "re-allocating". I'm not familiar with mpq internals, but I guess it might be possible to get away with leaving the denominator as zero on initialization. Then one would need to follow the convention that if numerator is zero, then the denominator is ignored. Or (but I guess that's more cumbersome) adapt the convention that zero denominator 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-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Lazy mpz allocation
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. Which I guess is also expected to work on a const mpq_t, so it's not an easy solution to redefine it to do lazy assignment. And it's used in quite a lot of places, debian codesearch lists the following packages: python-gmpy, llvm-toolchain-3.8, mpfr4, lcalc, yap, flint-arb, mlgmp, ats-lang-anairiats, givaro, parrot, llvm-toolchain-snapshot, librep, linbox, python-gmpy2, swi-prolog, libgmpada, isl, polymake, kcalc, pynac, flint, pike7.8, apron, cloog, llvm-toolchain-3.7, pike8.0, ocamlcreal, qsopt-ex, gambas3, cgal, surf-alggeo, singular, cvc3, gmp, regina-normal, gcl, ppl, libaqbanking, gmp-ecm, zimpl, ats2-lang, ledger, libalkimia, gfan, guile-1.8, genius, postgresql-pgmp But I'm not giving up just yet. Would it be possible to initialize the denominator as static const mp_limb_t the_one = 1; q->_mp_den._mp_alloc = 0; q->_mp_den._mp_size = 1; q->_mp_den._mp_d = (mp_limb_t*) _one; (This kind-of requires that _mp_alloc == 0, _mp_size != 0 is supported in general for mpz_t, meaning any modification requires new storage, and that the storage pointed to by _mp_d should not be deallocated by gmp). That looks pretty much like the copy-on-write thing you and Marco were discussing last year https://gmplib.org/list-archives/gmp-devel/2015-September/004169.html It should be possible, but it may require changing quite a number of places in the code. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP work on symbol visibility
On Wed, 31 Aug 2016, Torbjörn Granlund wrote: There are several complex issues I need to understand and resolve. One issue is how to handle (unit) testing of hidden functions. I will probably resolve that with alias symbols such as foo_for_testing as an alias for foo. Would that be only in a temporary, testing-only libgmp.so, or also in the installed libgmp.so? I am guessing the second, but it seems a bit sad that the exported symbol list remains polluted. Another issue is with libgmpxx.so and its dependency on libgmp.so. As separate shared libs, hidden symbols of libgmp.so will not be reachable from libgmpxx.so, which of course means we cannot hide them. Also, there will be no performance wins for any libgmpxx.so references to libgmp.so. I see two solutions: (1) If we really want to discourage external use, arrange an alias to something wierd, making libgmpxx reach the symbol foo as fuckhead_foo. (2) Put (allmost) all of libgmp.so in libgmpxx.so. This gives the best performance. Does libgmpxx.so use that many private functions from libgmp.so and are they performance critical? To me, libgmpxx.so is very small and only contains I/O functions, where 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
Re: [PATCH] longlong.h: Fix obsolete ARC asm constraints
On Wed, 17 Aug 2016, Vlad Zakharov wrote: We replace obsolete "J" constraint with "Cal" constraint. Hello, could you give a little more information please? In particular, does "Cal" work with older versions of gcc? Does "J" still work or is it rejected 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
RE: [PATCH] longlong.h: Fix obsolete ARC asm constraints
On Wed, 24 Aug 2016, Claudiu Zissulescu wrote: The J-constant was mainly used by Arc 4 architecture for 32-bit integer constants. It got obsoleted once we pushed the new ARCompact architecture to gcc (GCC5.x+). The replace constraint is the Cal which is again a 32 bit constraint fitted for arithmetic ops. On Wed, 24 Aug 2016, Vlad Zakharov wrote: I got inspiration from the following gcc patch: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01964.html "J" constraint is rejected with recent gcc, so we have to replace it. Thanks to both of you. My main concerns were (sorry, I should have stated it this way in the first place) 1) Does the patch break things for people using an older compiler? (how old?) Is it worth having both versions with an #if on the compiler version? 2) Do we need to backport the patch if we ever do a 6.1.2 release? From your messages, it seems clear that the answer to 2) is yes. 1) is not quite clear yet though. As far as I can tell from gcc's sources, the current ARC port was added for gcc-4.9 and already supported "Cal". A previous ARC port was obsoleted in gcc-4.6. That usually means the port already didn't work 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 mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Adding support for the Fuchsia OS
On Fri, 4 Nov 2016, Josh Conner wrote: Hello - I'd like to add support for fuchsia (https://github.com/fuchsia-mirror) to libgmp. I believe the change is trivial (just adding it to the $os conditional). I'm not sure what the process is for submitting a proposed change to this library -- would you like me to just send a patch? Posting a patch to this list seems fine. What kind of special support do you need? I would expect most support work to happen in autoconf, libtool, config.guess, etc, all things were we can just import a new upstream version. If the patch is not a trivial one-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 mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Flurry of GMP check failures
On Sat, 5 Nov 2016, Niels Möller wrote: At this point in time, I think use-cases involving static libgmp.a (or libnettle.a) are somewhat obscure. 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 who doesn't have much control over the computer he uses (either lack of permission or lack of competence). 2) I am rebuilding GMP on my specific platform in order to get the best possible performance. I might as well use a static libgmp to squeeze that extra bit of speed out 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/listinfo/gmp-devel
Re: Flurry of GMP check failures
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 specific platform in order to get the best possible performance. [...] I see. In these cases, is it important whether or not libgmp.a uses pic code? In the first case, it doesn't matter. In the second case, we would have to run benchmarks where one build uses --with-pic and not the other. The PIC library is a tiny bit larger (1321280 vs 1319632). GMPbench doesn't really see the difference on x86_64 core2 (2117 vs 2124), but it may not be the best test for this. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Help stabilising mini-gmp
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 problem. At least in C, shifting negative integers is undefined. It is a pity that it is, but the standard say so. I am less sure about C++. Some googling did not provide a definitive answer. But if left shift of negative integers is undefined, surely right shift is too! Surprisingly, shifting negative numbers left is undefined, while shifting them right it implementation-defined. The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned type, the value of the result is E1 × 2^E2 , reduced modulo one more than the maximum value representable in the result type. Otherwise, if E1 has a signed type and non-negative value, and E1 × 2^E2 is representable in the corresponding unsigned type of the result type, then that value, converted to the result type, is the resulting value; otherwise, the behavior is undefined. The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2^E2 . If E1 has a signed type and a negative value, the resulting value is implementation-defined. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Help stabilising mini-gmp
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 doing it, yes, I highly recommend it. It is now running for ivydeb64v9 and ivydeb32v9. Two errors were triggered for the former, one in mini-gmp (presumably fixed by nisse) and one on cxx/t-ops2z. Please take a look, glisse. 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. There is something strange with https://gmplib.org/devel/tm/gmp/date.html . When I click to get the logs for ivydeb32v9.gmplib.org-dyn-noasm-ubsan, the build log is from 26/11, but the check log is from 21/11... -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Help stabilising mini-gmp
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. It is now running for ivydeb64v9 and ivydeb32v9. Two errors were triggered for the former, one in mini-gmp (presumably fixed by nisse) and one on cxx/t-ops2z. Please take a look, glisse. 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. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_gcd_ext(NULL, ...)
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 allocation. I doubt it would save that much, but it seems trivial to add a check if(g!=NULL) similar to the tests for s and t. Does it make sense to you? Sounds reasonable to me. Done. But then I'd also consider adding a return value, returning one if the inputs were coprime (gcd == 1), otherwise zero. Would be useful for mpz_invert. Makes sense. If you want to do it... It won't save much for the computation, only the final copy. But it's also a gain to clarity if callers don't have to pass in dummy, unused, result arguments. Agreed. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Help stabilising mini-gmp
On Sat, 19 Nov 2016, Niels Möller wrote: I don't think so. But I think the right way is to simply add $(CFLAGS) to the linker command line. That's the usual way to use it, right? That's a common hack (that I am ok with), but I don't think I would call it "the right way"... The first failure was also a bit interesting, an internal compiler error with gcc-6. In file included from gmp/mini-gmp/tests/testutils.c:24:0: gmp/mini-gmp/tests/../mini-gmp.c: In function 'mpz_set_d': gmp/mini-gmp/tests/../mini-gmp.c:1647:3: internal compiler error: Aborted if (x != x || x == x * 0.5) ^~ https://gmplib.org/devel/tm/gmp/build/failure/sky.gmplib.org-dyn-fat-fake:64.txt Strange that it only shows up there, the command line does not have anything specific to skylake (no -march or -mtune). I can't reproduce on another machine. (btw, some compilers warn about the trailing comma in enum hex_random_op) -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Help stabilising mini-gmp
On Sun, 20 Nov 2016, Niels Möller wrote: ni...@lysator.liu.se (Niels Möller) writes: It seems "trivially" reproducible on ppc64 though, both real metal versions and fake ones like ppceb-debv8 (and ppcel-debv8). I'll try to debug (if no one else beats me to it), but not today. I've logged in to ppceb-debv8, and it's easy to reproduce. No gdb installed, so I'm attempting printf debugging. And then I noticed that the test succeeds if adding a few debug printouts... I next tried adding -Wall to the command line flags, and I see gcc -std=gnu99 -m64 -mtune=power7 -O3 -Wall -I../.. -c /home/nisse/hack/gmp/mini-gmp/tests/t-signed.c -o t-signed.o /home/nisse/hack/gmp/mini-gmp/tests/t-signed.c: In function 'testmain': /home/nisse/hack/gmp/mini-gmp/tests/t-signed.c:45:26: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow] if ((si < oi ? -1 : si > oi) != c) ^ /home/nisse/hack/gmp/mini-gmp/tests/t-signed.c:45:21: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow] if ((si < oi ? -1 : si > oi) != c) ^ I don't quite understand neither what the testcase is doing, nor what the warning means, since there's no subtraction in there. 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 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 ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Help stabilising mini-gmp
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 that I am just speculating, but the warning does not surprise me) If the code becomes undefined by gcc's transformations, that it's a compiler bug. That's not at all what I said, the code doesn't become undefined. If it was fine, it remains fine. If it was broken, the brokenness may become more obvious. Let me rephrase the warning: "Reminder: computing INT_MIN-1 is forbidden. If you are not doing that, you can ignore this message. I am giving you this warning because you are computing X-1 and I decided to key the launch of nuclear missiles to the value X==INT_MIN. Have a safe day!" (the computation of X-1 is in try_op_si, but the warning points at the location where the compiler inserts the trigger for the nuclear missiles) -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Help stabilising mini-gmp
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://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz reuse test takes too much time
On Sat, 3 Dec 2016, Niels Möller wrote:
"Marco Bodrato" <bodr...@mail.dm.unipi.it> writes:
! #define GCDEXT_CHECK2(i1, i2) do {\
! mpz_gcdext (res1, res2, NULL, i1, i2); \
! MPZ_CHECK_FORMAT (res1);\
! MPZ_CHECK_FORMAT (res2);\
! if (mpz_cmp (ref1, res1) != 0 || mpz_cmp (ref2, res2) != 0) \
! FAIL2 (mpz_gcdext, i1, i2, NULL); \
! } while (0)
Should we check both mpz_gcdext (res1, res2, NULL, i1, i2); and mpz_gcdext
(res1, NULL, res2, i2, i1) in this macro?
Hmm, you changed the code to not only allow G to be NULL, but allow NULL
S too?
That was already the case before my patch. Since s and t may get swapped
depending on the values of a and b, you 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
Re: mpz_gcd_ext(NULL, ...)
On Sat, 3 Dec 2016, Marco Bodrato wrote:
The modified manual now says that "If @var{s}, @var{t} or @var{g} is
@code{NULL} then that value is not computed.", but g is computed anyway,
even if it is not returned...
The only change is that it is about g, s and t instead of just t. But that
was already not quite true before, since depending on a < b or b < a, we
swap the arguments and the mpn function ends up computing t anyway. We are
saving the copy, which counts as computation, so the formulation seemed
good enough to me, and most importantly easy to understand for 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
Re: mpn_sqrtrem{1,2}
On Sat, 25 Mar 2017, Torbjörn Granlund wrote: The sqrtss and sqrtds are SIMD operations, right? That means that if we don't initialise all input fields with something, they might contain special values which triggers exceptional conditions. I don't think so. sqrtsd computes sqrt of the lower 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 ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpn_sqrtrem{1,2} - patch for pure C implem
On Sat, 1 Apr 2017, Adrien Prost-Boucle wrote: On Sat, 2017-04-01 at 18:15 +0200, Marco Bodrato wrote: Sorry, but even correcting the obvious typos, it doesn't pass the tests. I think I have found the error. The final correction was wrong. I hope it's OK now, but... I still can't compile GMP with ABI=32. Like you suggested I launched: ./configure ABI=32 && make && make check The 5th or 6th source file does not compile: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_com -m32 -O2 -pedantic -fomit-frame-pointer -mtune=core2 -march=core2 -c com.c -fPIC -DPIC -o .libs/com.o In file included from ../gmp-impl.h:147:0, from com.c:31: ../fib_table.h:4:1: warning: data definition has no type or storage class Error, error, this data is for 64 bits ^ Did you run "make distclean" between the 64-bit 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
Re: mini-gmp
Hello, I am curious why you are trying to support mini-gmp in mpfr at all. As far as I understand, the goal of mini-gmp is that a user can take a copy of those 2 files, stick them in his project, and get a self-contained program. Unless you provide a similar mini-mpfr, your user is going 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
Re: Generic get_d_2exp failures
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;
weight /= MP_BASE_AS_DOUBLE;
if (weight == 0)
break;
}
we could make that code uglier to make sure there is no rounding up,
maybe comparing d+up[i]*weight to d+oldweight, and trying again by
zeroing out an increasing number of low bits of up[i].
It would be nice if we could find a portable way to add two floating
point values without rounding up. Would something like this work?
s = a + b; /* Assume a > b */
r = (s - a) - b; /* No rounding expected here. */
if (r > 0)
s -= 2*r;
Not sure where the 2*r is coming from. And I am not very optimistic that
there is such a simple formula that works for any rounding mode, though I
could easily be wrong. There is also the question of how portable exactly
it needs to be. C99 nextafter can be helpful.
But doesn't make the tests pass in my initial testing. I guess it might
be necessary to isolate the high bit of r (possibly be converting to
mp_limb_t ans usign count_leading_zeros), which should correspond to
the lsb of the mantissa (or if it's half the lsb).
And might also need special handling of the case that s, after rounding,
is a power of two.
The variant I tested:
@@ -368,7 +369,13 @@ mpn_get_d (mp_srcptr up, mp_size_t size,
d = up[size - 1];
for (i = size - 2; i >= 0; i--)
{
- d += up[i] * weight;
+ double l, s, r;
+ l = up[i] * weight;
+ s = d + l;
+ r = (s - d) - l;
+ if (r > 0)
+ s -= 2*r;
+ d = s;
weight /= MP_BASE_AS_DOUBLE;
if (weight == 0)
break;
It may be easier to assert that FLT_RADIX==2 and use DBL_MANT_DIG to avoid
any rounding. There is even code in one of the tests to compute
DBL_MANT_DIG at runtime (preferably once, at startup) if it isn't
available / reliable at compile-time.
3) Drop the generic path. It hasn't passed the testsuite for a long
time, can't be that important.
If we keep it, we'd need to (i) fix it, and (ii) test it regularly.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: C99 and GMP
On Fri, 27 Apr 2018, paul zimmermann wrote: https://gmplib.org/devel/lcov/shell/gmp/mini-gmp/mini-mpq.c.gcov.html 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. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: C99 and GMP
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 of the files are not tested at all (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). Hmm, no, mpn_add_err3_n really seems completely unused. There is a refmpn implementation ready for comparisons... -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: documentation on internals not up to date
On Fri, 27 Apr 2018, Niels Möller wrote: _mp_alloc == 0 and _mp_size != 0 is a read-only value, _mp_d is neither written, reallocated or freed by mpz functions. It must not be passed as destination argument to any mpz function. Should also link to docs for mpz_roinit_n and MPZ_ROINIT_N. Currently, if an mpz_t is initialised with _roinit, it can be passed to _clear or _clears with no errors. Should we document this? I think we should. Moreover, the various mpz_set_ functions should work smoothly too. I'd prefer that we not document any way to pass _roinit values to any mpz functions taking a non-const mpz_t, even if it happens to work in the current implementation. Maybe as a later extension, *if* we find some use cases where it provides a significant advantage. 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 document that none work. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
