_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 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 reall
On Tue, 8 Jan 2013, David Miller wrote:
From: Torbjorn Granlund
Date: Tue, 08 Jan 2013 12:50:01 +0100
Marc Glisse writes:
Then we might as well always put it in _mp_d[-1], no? IIRC that's what
mpfr does.
I see some problems with that:
* There is a serial memory dependency pr
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.
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
in_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
opportunities. And then gcc does optimize this.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
fully 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.
--
Marc Glisse
___
On Mon, 11 Feb 2013, Vincent Lefevre wrote:
On 2013-02-11 00:24:12 +0100, Marc Glisse wrote:
You should use i*=2 instead of i<<=1 to maximize optimization
opportunities.
Why? I would say that a good compiler has more chances to optimize
i<<=1 as the only difference between these
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 curren
On Thu, 14 Feb 2013, bodr...@mail.dm.unipi.it wrote:
Il Mer, 13 Febbraio 2013 9:28 am, Marc Glisse ha scritto:
On Wed, 13 Feb 2013, bodr...@mail.dm.unipi.it wrote:
Are inline functions as portable as macros?
Not quite, but I don't know any current compiler that doesn't su
x27;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@
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 mailin
RNDU);
double s = mpfr_get_d (y, GMP_RNDU); /* EXACT but can overflow */
mpfr_clear (y);
return std::pair(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)
--
Ma
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://gmp
On Mon, 13 May 2013, Torbjorn Granlund wrote:
Marc Glisse 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 ver
On Thu, 16 May 2013, Torbjorn Granlund wrote:
Marc Glisse 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 ch
s 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
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
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
On Mon, 23 Sep 2013, Niels Möller wrote:
Marc Glisse 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 overrid
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, prec
On Mon, 23 Sep 2013, Niels Möller wrote:
Marc Glisse 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
_
e the main
motivations for sticking with mpf_t?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
FR 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@gmpli
several depending on what we mean by that
exactly).
But if it isn't faster in practice, and doesn't have any other
advantages over mpfr, it would make sense to clearly deprecate all use
of mpf.
+1 (the mpf2mpfr.h header may help people who want to switch if it
onf -f; it will..."
?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
rt can be 24, 32, 46 or 64 bits, and different for ushort. */
#if defined _CRAY
#include
#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
g
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
with gcc-2.9x around 1999-2000.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Fri, 27 Dec 2013, Torbjorn Granlund wrote:
Marc Glisse 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.
On Fri, 27 Dec 2013, Niels Möller wrote:
Marc Glisse 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 .
If we really
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.
On Thu, 2 Jan 2014, Torbjorn Granlund wrote:
Marc Glisse writes:
On Fri, 27 Dec 2013, Niels Möller wrote:
> Marc Glisse writes:
>
>> Then I am considering pushing the attached patch soon.
>
> Do we really need a configure test?
No idea. It seemed safer, and sin
On Thu, 2 Jan 2014, Niels Möller wrote:
Marc Glisse 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
The previous form has worked so far, and I'd like to remove the macro
completely soon, so it doesn't seem worth it.
Is that out-of-range conversion really Proper C?
unsigned = modular arithmetic, so yes, it is fine.
--
Marc Glisse
___
g
On Fri, 3 Jan 2014, Torbjorn Granlund wrote:
The following tests fail on 32-bit hosts.
Looks related to my commits, I'll look at it and revert/improve as
appropriate.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
On Fri, 3 Jan 2014, Torbjorn Granlund wrote:
Marc Glisse writes:
Looks related to my commits, I'll look at it and revert/improve as
appropriate.
I think all failing systems run 32-bit FreeBSD.
Yes, I noticed the same.
This is probably yet another FreeBSD problem hitting GMP.
On Fri, 3 Jan 2014, Marc Glisse wrote:
I bet their limits.h is plain and simply broken.
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.
They have an unconditional
On Fri, 3 Jan 2014, Torbjorn Granlund wrote:
Marc Glisse 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 unde
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
or 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
erformance is not a concern, but it is for
mpfr and many users, and even if they rewrite the code to accomodate
mini-gmp, they will probably want to keep the current one for regular gmp
(with suitable #if).
--
Marc Glisse
___
gmp-devel mailing l
t'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
. 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 th
(moved to gmp-devel)
On Sat, 18 Jan 2014, Marc Glisse wrote:
It probably also breaks the ABI since it changes the size of some
objects.
By the way, do we have a policy about breaking binary compatibility? In
this case, mixing old and new objects could result in crashes (almost
certainly at
On Wed, 22 Jan 2014, Torbjorn Granlund wrote:
Marc Glisse writes:
By the way, do we have a policy about breaking binary compatibility?
In this case, mixing old and new objects could result in crashes
(almost certainly at -O0, seldom at -O3). It should be possible to
prevent this issue by
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://
th 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...
--
M
On Thu, 6 Feb 2014, Niels Möller wrote:
Marc Glisse 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
e, 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.
--
M
hould 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?bu
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_
when to pop, changing the gmp allocation
functions around that operation. But that's a bit complicated, has some
overhead, and may not be a great fit for some uses. This is a special case
of Niels' pool idea.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Thu, 18 Dec 2014, Marc Glisse wrote:
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
in_error ("factorial(negative)");
eval(z, static_cast(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
stick to using mpn.
+1
Although itch/scratch may force a compromise between overestimating the
space required or spending too long estimating it, which I hope won't
penalize small numbers too much.
--
Marc Glisse
___
gmp-devel mailing l
, 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 bett
into corresponding C++ exceptions. This is probably
already done for certain OS signals (SIGFPE, etc.).
I only know of windows where signals are implemented as exceptions.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.
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
ssage 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
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:
On Mon, 25 May 2015, Torbjörn Granlund wrote:
Marc Glisse 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)
On Mon, 25 May 2015, Marc Glisse wrote:
On Mon, 25 May 2015, Torbjörn Granlund wrote:
Marc Glisse 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,
ithin 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 tha
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
ee 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
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 Sat, 22 Aug 2015, Niels Möller wrote:
Marc Glisse writes:
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.
If it's reall
bound on either the number or the size of the variables. It could also be
done per-thread because those numbers had no way to migrate from one
thread to another. But that's quite a specific use-case.
--
Marc Glisse
___
gmp-devel mailing list
gmp-de
part of the Debian GNU/Linux distribution as it is
licenced under the GFDL with invariant texts. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335403 and
http://lists.debian.org/debian-legal/2006/03/msg00536.html
--
Marc Glisse
___
gmp-devel ma
, 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
overrides the definition of NO_ASM and fails quite badly.
I don't like what gcc is doing there, but it made me aware of this special
handling for the macro NO_ASM.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmpli
On Sun, 20 Mar 2016, Niels Möller wrote:
Marc Glisse 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
On Sat, 19 Mar 2016, Marc Glisse wrote:
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?
One issue with changing it is MPFR: src/mpfr-longlong.h tests for
On Sun, 20 Mar 2016, Torbjörn Granlund wrote:
Marc Glisse 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
On Sun, 20 Mar 2016, Torbjörn Granlund wrote:
Marc Glisse writes:
I currently think I'll go with just config.h (no CFLAGS).
sgtm
https://gmplib.org/repo/gmp/rev/a70e6b446199
I tested it some and it seemed to work...
--
Marc Glisse
__
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 fa
y 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
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
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 mp
hat 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
On Wed, 4 May 2016, Niels Möller wrote:
Marc Glisse 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
ted
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
x27;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
_
) that supports this constraint letter as the
Tangent architecture is retired for a long time now.
Thanks :-)
https://gmplib.org/repo/gmp/rev/58879634af3c
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo
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
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/ma
On Sat, 5 Nov 2016, Niels Möller wrote:
Marc Glisse 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
rivial 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
___
me 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
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
_
On Sun, 20 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse 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
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
) similar to the tests for s and t. Does it make sense to you?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
On Mon, 21 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse 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 ivydeb64
On Fri, 25 Nov 2016, Niels Möller wrote:
Marc Glisse 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
On Fri, 25 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse 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 i
On Fri, 25 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse writes:
Surprisingly, shifting negative numbers left is undefined, while
shifting them right it implementation-defined.
I fail to appreciate the difference between these definitions of
undefinedness.
I assume "undefined"
On Fri, 25 Nov 2016, Marc Glisse wrote:
On Mon, 21 Nov 2016, Torbjörn Granlund wrote:
Marc Glisse 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 rec
101 - 200 of 211 matches
Mail list logo
