er) program.
>
> > Bill.
>
> > 2010/1/30 Bill Hart :
> >> Hi Dan,
>
> >> That definitely looks like a bug. You are correct in that size should
> >> be set to zero.
>
> >> It's slightly bizarre in that we haven't altered mpz_gcdext,
#include
#include
int main () {
mpz_t a,b,d,u,v;
mpz_init(a);
mpz_init(b);
mpz_init(d);
mpz_init(u);
mpz_init(v);
mpz_set_si(a,1);
mpz_set_si(b,2);
mpz_gcdext(d,u,v,a,b);
assert(!(u->_mp_size == 1 && u->_mp_d[0] == 0));
assert(!(v->_mp_size == 1 && v->_mp_d[0] == 0));
ret
The memory allocator provided with Singular-Factory is in the file
libcfmem.a, and the routines are called getBlock, freeBlock, and
reallocBlock. I copied the routines more than 10 years ago and
continue to use the modified copy. I may even have destroyed 8 byte
alignment then while optimizing it
r be written to be faster if memory allocators
all returned 16-byte aligned data? It seems to be the case for this
routine.
On Dec 20, 2:50 pm, Bill Hart wrote:
> 2009/12/20 Dan Grayson :
...
> > What about installing a test under "make check" that tries all
> > routines w
ng the test, which I don't see how to provoke.
>
> 2) Introduce code to align data coming from custom allocators. This
> could probably be done in a handful of cycles per allocation, but
> would still introduce an overhead.
>
> I'm open to further suggestions.
>
> Bil
That's a fine decision, but now it becomes super important to help
developers discover that their custom allocator is breaking the rule,
if it does. It took me many hours of single-stepping to discover it.
It would have saved me a lot of time if the program had aborted with a
suitable error messag
Well, Macaulay2 comes with thousands of tests, and only one failed,
deep inside a D-modules computation. It took a lot of single stepping
to figure it out. Part of the problem is that we have two custom
memory allocators, Boehm's gc and one copied from Singular-Factory
long ago. The latter is us
He could also mean that the machine instructions that move 8 byte
words to vector registers would segfault if you tried to use them on
nonaligned data, and that he tried to write mpn_lshift to try to avoid
doing that. Those are the lines of code I pointed to in the original
report. It would be a
... oops, I was implicitly referring to mpn/tdiv_qr.c, which counts
leading bits before shifting by that amount; probably mpn_lshift
itself has no such dependency.
On Dec 10, 8:28 am, Dan Grayson wrote:
> I think the bug is activated only when the number of lead zero bits in
> the denom
I think the bug is activated only when the number of lead zero bits in
the denominator is in a certain narrow range, since that number
determines by how much to shift, but I haven't explored that
carefully. Therefore, for tests involving alignment, picking integers
with random bits is not good (if
Yup, that's how I was going to work around it. Actually, I should
have been doing it anyway, because I'm trying to prepare distributions
of Macaulay2 that will work on all architectures. Somehow I forgot to
do it. (A consequence of that is that if someone wants a fast
Macaulay2 in which the mpir
/*
Bug in mpir 1.2.1.
This program demonstrates that mpn_lshift, as implemented on 64 bit
intel
machines by mpn/x86_64/core2/lshift.as, gives the wrong answer if
the limbs
are not aligned to an 8 byte boundary.
The confusion in the code starts with these lines:
and r9
This line in genperf.c
fprintf(out, final.line[i]);
should be
fprintf(out, "%s", final.line[i]);
to prevent a warning from the compiler, and to ensure correct behavior
if lines contain %.
--~--~-~--~~~---~--~~
You received this message because yo
Under Mac OS 10.6, gcc compiles 64 bit binaries by default, and mpir's
configure script (both 1.2.1 and 1.3.0-rc1) gets confused by that if
you ask for a 32 bit compilation using the --build=i386-apple-
darwin10.0.0 option, because it doesn't add -m32 to the gcc command
line during the testing of
am wrote:
> On Thursday 22 October 2009 15:42:05 Dan Grayson wrote:> To get mpir to pass
> its C++ tests under cygwin (if I configure with --
> > enable-cxx) I had to also add -Wl,--enable-auto-import to LDFLAGS.
> > The warning message from ld if you don't have that opti
To get mpir to pass its C++ tests under cygwin (if I configure with --
enable-cxx) I had to also add -Wl,--enable-auto-import to LDFLAGS.
The warning message from ld if you don't have that option specified
doesn't sound very scary, because it says it's doing the auto import,
anyway, without being
That's a good thought, but returning 4.3.0-mpir as the gmp version
number would be less likely to break routines that compare version
numbers than returning mpir-4.3.0, especially when comparing to
something like 4.2.1 that doesn't have the extra characters. There
are lots of packages out there t
g a gmp.h from GMP and a binary from MPIR, it can be
> useful.
>
> Bill.
>
> 2009/10/18 Jason Moxham :
>
>
>
> > On Sunday 18 October 2009 21:34:40 Dan Grayson wrote:
> >> Suppose I link a program dynamically with libgmp, and at run time
> >> lib
This won't help detect which library is actually in use at run-time,
because the macros are examined only at compile-time.
On Oct 18, 4:36 pm, Jason Moxham wrote:
> On Sunday 18 October 2009 21:34:40 Dan Grayson wrote:> Suppose I link a
> program dynamically with libgmp, a
Suppose I link a program dynamically with libgmp, and at run time
libgmp is being impersonated by libmpir. Is there a (reliable) way
for the program to tell?
I ask, because I like to arrange the copyright message of Macaulay2 to
display the copyright of libraries in use, so it's nice to know whi
Dear Bill,
I (belatedly) see that bugs are to be reported to mpir-devel (i.e.,
here), so maybe I won't need a trac account. (I still haven't
isolated the bug I might have to report, which is why I haven't
already reported it.) Perhaps such accounts are only for people
fixing bugs? Or is it al
The web site refers to alpha-3 at the top but to alpha-1 a bit lower
down ...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com
To un
22 matches
Mail list logo
