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
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
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
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
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
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
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
):
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
/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
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
to the corresponding bug report / conversation?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
. 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
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
++ 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
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
+ (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
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
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
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
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
2010 21:34:40 -0600
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
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
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
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
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
((UI) 0 (UI) = GMP_NUMB_MAX)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
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
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
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
);
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
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
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
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
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
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
.
Comments?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
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
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
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
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
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
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
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
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
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
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
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
for the itch functions in
that file.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
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
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
. 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
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
(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
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
, 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
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
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
, 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
On Mon, 2 Feb 2015, Torbjörn Granlund wrote:
Does MIPS64r6 contain all older architecture revisions as a subset,
Apparently not, the motivation for the patch is that multu has
disappeared...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel
that pointer may abort the program.
In such a setting, all of this memory-related error handling
stuff is pointless]
Yes. Memory overcommit can often be disabled or mitigated in various
ways, but it does complicate things (get a better OS ;-)
--
Marc Glisse
On Thu, 21 May 2015, Marc Glisse wrote:
On powerpc-linux-gnu, clang complains about the bc+ instruction, and
indeed I can't find that in IBM's documentation. After removing
divrem_2.asm, it compiles fine and passes the testsuite.
Now I've found it (and reported
https://llvm.org/bugs
On Mon, 25 May 2015, Torbjörn Granlund wrote:
Marc Glisse marc.gli...@inria.fr writes:
Now I've found it (and reported
https://llvm.org/bugs/show_bug.cgi?id=23646 ). Note that the same (?)
instruction is spelled differently in the same file:
bc+ 12, 28, L(9)
vs.
blt
On Mon, 25 May 2015, Marc Glisse wrote:
On Mon, 25 May 2015, Torbjörn Granlund wrote:
Marc Glisse marc.gli...@inria.fr writes:
Now I've found it (and reported
https://llvm.org/bugs/show_bug.cgi?id=23646 ). Note that the same (?)
instruction is spelled differently in the same file
with extra warnings in the release notes or some such
place. But again, your call.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
trying to clarify why each
type is used (unsigned long is mp_bitcnt_t in some places, mp_builtin_ui
in others, etc).
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
.
On Thu, 20 Aug 2015, Torbjörn Granlund wrote:
(We might consider adding mpf_cmp_z too, at least in a simple-minded
manner, to keep the GMP interface as orthogonal as possible.)
Adding new mpf_t functions might confuse the message that people should
use mpfr...
--
Marc Glisse
On Fri, 21 Aug 2015, Marco Bodrato wrote:
On Thu, August 20, 2015 9:56 am, Marc Glisse wrote:
Is casting an mpz to an mpq, then accessing only the NUM() part of it,
portable?
From what I understand of the aliasing model currently used by gcc, to
be safe, in the function using it, we should
)op2 is a safer way to do the same
thing as NUM(op2) in this case.
(I am not suggesting changing the gmp-impl implementation of NUM to a
cast)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
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
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
On Sun, 20 Mar 2016, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
when configure wants to define a macro, it usually puts it in
config.h. We do have one exception: NO_ASM, which ends up defined in
CFLAGS. Was there a particular reason for this choice?
I'm greping f
On Sun, 20 Mar 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
One issue with changing it is MPFR: src/mpfr-longlong.h tests for
NO_ASM, but there is no code to define it. As far as I understand,
MPFR uses __GMP_CFLAGS by default, in which GMP may have in
ations.
If this is for the development of free software, the GCC compile farm
includes some aarch64 machines on which you could experiment.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Mon, 21 Mar 2016, Vincent Lefevre wrote:
On 2016-03-20 12:14:49 +0100, Marc Glisse wrote:
but it seems likely that a user who went to the trouble of disabling
assembly for GMP doesn't want to use that same assembly in MPFR.
I'm not so sure about that. AFAIK, longlong.h has far less asm
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
enominator means "this is an integer",
and treated as one.
The fact that an mpq is made of 2 mpz that can be accessed directly is
part of the interface. I think following your suggestion would mean
changing that.
--
Marc Glisse
___
gmp-de
On 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.
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
ejected
with a recent gcc? Do they mean the same thing?
I trust that you know what you are doing, I just like to understand a
patch before applying it.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
so well in previous releases, so it may indeed be
unnecessary to support the old syntax.
Does that make sense or did I misunderstand something? I'll probably push
the patch in a few days, when I get the chance.
--
Marc Glisse
___
gmp-devel ma
-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
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
On Sat, 5 Nov 2016, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
Uh? I have 2 very natural use cases for libgmp.a:
1) to build a static (or at least with few dependencies) executable
that I am going to send to someone else [...]
2) I am rebuilding GMP on my sp
On Fri, 25 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
Fixed. It was unhappy about (-13) << 2. I am a bit surprised it
doesn't complain about (-13) >> 2 on the next line, we'll see if it
ever becomes an issue.
This must be a compiler
On Fri, 25 Nov 2016, Marc Glisse wrote:
On Mon, 21 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
On Sun, 20 Nov 2016, Niels Möller wrote:
> It would make sense to test both gmp and mini-gmp with
> -fsanitize=undefined.
If we are not already d
On Mon, 21 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
On Sun, 20 Nov 2016, Niels Möller wrote:
> It would make sense to test both gmp and mini-gmp with
> -fsanitize=undefined.
If we are not already doing it, yes, I highly recommend it
On Fri, 25 Nov 2016, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
a user was asking if we could support calling mpz_gcd_ext with a NULL
first argument (the gcd), since they are only interested in the
coefficients s and t and would like to save the unnecessary
allocat
ling comma in enum hex_random_op)
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
> si - 1 to true,
and warns that this optimization may break your program if you rely on
wrapping. The usefulness of such a warning is debatable, and we tend to
drop some of them from gcc when we think nobody will notice.
--
Marc Glisse
___
g
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
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
ou cannot really support t==NULL
without supporting s==NULL. You may prefer not documenting it though...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
a user. If
you want to rewrite it to clarify that the gains aren't much, please go
ahead...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
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
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
to
have to install the mpfr dependency anyway, his project is not
self-contained, so he might as well install the real GMP.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Sat, 28 Oct 2017, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
2) The rounding occurs in the addition in
weight = 1/MP_BASE_AS_DOUBLE;
d = up[size - 1];
for (i = size - 2; i >= 0; i--)
{
d += up[i] * weight;
.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Fri, 27 Apr 2018, Marc Glisse wrote:
On Fri, 27 Apr 2018, paul zimmermann wrote:
quite interesting. Why is gmp/mpn not tested in the head coverage?
It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of
symlinks created at build time.
sorry I missed that. I see some
, 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
1 - 100 of 153 matches
Mail list logo
