Commited to mpir-2.1 and trunk . I should add a test case , was it when dn==nn
, although I couldn't get the K8 to fail.
Jason
On Saturday 04 September 2010 16:47:21 Bill Hart wrote:
> OK, I think the following patch to mpn/generic/divexact.c fixes this issue:
>
> wbh...@selmer:~/mpir-2.1.1/mpn/generic$ diff divexact.c divexact.old
> 131,141c131,138
> < if (qn)
> < {
> < inv = TMP_ALLOC_LIMBS(dn);
> < mpn_invert(inv, dp, dn);
> < cy = mpn_inv_divappr_q(qp, n2p, nn, dp, dn, inv);
> < if (!extend) qp[qn] = cy;
> <
> < if ((qp[0] & 1) + q_even != 1) /* quotient is out by 1 */
> < mpn_sub_1(qp, qp, qn + 1, 1);
> < } else
> < qp[0] = 1; // as dp is normalised, exact division means qp = 1
> ---
>
> > inv = TMP_ALLOC_LIMBS(dn);
> > mpn_invert(inv, dp, dn);
> > cy = mpn_inv_divappr_q(qp, n2p, nn, dp, dn, inv);
> > if (!extend) qp[qn] = cy;
> >
> > if ((qp[0] & 1) + q_even != 1) /* quotient is out by 1 */
> >
> > mpn_sub_1(qp, qp, qn + 1, 1);
>
> I don't seem to have an mpir svn setup at the moment. If someone could
> commit this and test, I'd be grateful.
>
> I don't see a reason to change the requirement that nn > dn, just that
> this requirement is respected by divexact, which it wasn't doing.
>
> Bill.
>
> On 4 September 2010 13:53, Bill Hart <[email protected]> wrote:
> > Ah, thanks for making progress with it. I'll see if I can chase it
> > through given what you've found.
> >
> > Bill.
> >
> > On 4 September 2010 13:43, Jason <[email protected]> wrote:
> >> On Saturday 04 September 2010 12:54:33 Jason wrote:
> >>> I can reproduce this error on boxen , which has gcc-4.2.4
> >>>
> >>> ./configure --enable-assert --build=core2-unknown-linux-gnu
> >>>
> >>> and just run the test case to get an assertion failure , therefore this
> >>> looks like a real error , although I could not the failure when I
> >>> copied the core param into the K8 directory and changed cflags , so I
> >>> think this also depends on which HAVE_NATIVE functions are availible
> >>
> >> No , if I put the core2 params in the k8 directory and build on a k8 , I
> >> get the error(must of done something daft before).
> >> The error happens when mpn_divexact (which can accept denom limbs dn <=
> >> numer limbs nn) calls mpn_inv_divapprox_q (which requires just <) .
> >> With the k8 thresholds it reduces that case properly , but with core2
> >> params it does not. It's possible that the k8 params could also produce
> >> this error as it just have to find the right input size.
> >> Unfortunately I'm not at all familiar with the code , I only roughly
> >> know the algorithm.
> >>
> >>> On Saturday 04 September 2010 11:36:35 Jason wrote:
> >>> > On Saturday 04 September 2010 11:09:23 Jason wrote:
> >>> > > The problem is that the gmp-mparam.h for core2 and nehalem have
> >>> > > some bad values in , when I replaced it with the k8 version it
> >>> > > was OK. I have to narrow down which values seem to be bad
> >>> >
> >>> > Actually thats not true , the values could be good , its just that it
> >>> > follows a different code path. Building with --enabel-assert we get
> >>> > this assertion failure when we run the code
> >>> >
> >>> > inv_divappr_q.c:46: GNU MP assertion failed: nn > dn
> >>> > Aborted
> >>> >
> >>> > > Jason
> >>> > >
> >>> > > On Saturday 04 September 2010 10:18:05 Jason wrote:
> >>> > > > Hi
> >>> > > >
> >>> > > > I can reproduce this error , I'm using gcc 4.4.4 , but only if I
> >>> > > > do a build for core2 or nehalem , the k8 build is OK , so
> >>> > > > perhaps it's the CFLAGS=- march=core2 that causes it?
> >>> > > > I'll change the flags and see if that makes a difference
> >>> > > >
> >>> > > > Jason
> >>> > > >
> >>> > > > On Friday 03 September 2010 23:49:14 Bill Hart wrote:
> >>> > > > > On 3 September 2010 23:44, Bill Hart
> >>> > > > > <[email protected]>
> >>> >
> >>> > wrote:
> >>> > > > > > Hi Jeroen,
> >>> > > > > >
> >>> > > > > > I've tried a variety of things to replicate this bug,
> >>> > > > > > including valgrinding with symbols on in MPIR and various
> >>> > > > > > compiler optimisation flags, but at least on my machine, I
> >>> > > > > > can't replicate it.
> >>> > > > > >
> >>> > > > > > If you have time, could you possibly help by taking the
> >>> > > > > > following steps:
> >>> > > > > >
> >>> > > > > > 1) Download a fresh copy of MPIR 2.1.1 from our website:
> >>> > > > > > http://www.mpir.org/ 2) Run ./configure; make; make check to
> >>> > > > > > verify that the library
> >>> > > > > > appears to compile OK on your machine (you could also try
> >>> > > > > > building your program against this clean library again if you
> >>> > > > > > haven't already done this)
> >>> > > > > > 3) Run ./configure again until about 30 lines are showing.
> >>> > > > > > You'll see something like
> >>> > > > > >
> >>> > > > > > CFLAGS="-O2 -m64 -march=k8 -mtune=k8"
> >>> > > > > >
> >>> > > > > > which will be indented (the string on your machine will be
> >>> > > > > > different). Copy the string that shows and alter the -O2 (or
> >>> > > > > > whatever you have) to -g, and pass to ./configure, e.g..:
> >>> > > > > > ./configure CFLAGS="-g -m64 -march=k8 -mtune=k8"
> >>> > > > > > 4) do
> >>> > > > > > make clean
> >>> > > > > > make
> >>> > > > > > 5) build your program against MPIR (to prevent it picking up
> >>> > > > > > a stray copy elsewhere, use -static when linking -- the
> >>> > > > > > library being in the .libs directory, the .h file in the top
> >>> > > > > > level directory of the MPIR source tree -- you'll have to
> >>> > > > > > set the -I and -L flags to gcc accordingly), e.g. I put the
> >>> > > > > > program in the top level mpir source directory and used:
> >>> > > > > > gcc -O2 mpirtest.c -o mpirtest -I. -L../.libs -lmpir -static
> >>> > > > >
> >>> > > > > Sorry, that should read:
> >>> > > > >
> >>> > > > > gcc -O2 mpirtest.c -o mpirtest -I. -L.libs -lmpir -static
> >>> > > > >
> >>> > > > > > 6) If you have valgrind installed on your machine, type:
> >>> > > > > > valgrind ./mpirtest
> >>> > > > > > and report to us the output. If not, a gdb backtrace, as you
> >>> > > > > > gave, may be sufficient.
> >>> > > > > > 7) If you have access to any other version of gcc on the same
> >>> > > > > > machine, it would also be useful to know if the same bug
> >>> > > > > > occurs with that version of gcc.
> >>> > > > > >
> >>> > > > > > This *may* be a compiler bug, but at this stage we have to
> >>> > > > > > assume it is more likely a bug in our code within MPIR.
> >>> > > > > >
> >>> > > > > > Bill.
> >>> > > > > >
> >>> > > > > > On 3 September 2010 22:10, Jeroen Demeyer
> >>> > > > > > <[email protected]>
> >>> > >
> >>> > > wrote:
> >>> > > > > >> Hello mpir-devel,
> >>> > > > > >>
> >>> > > > > >> I think I found a bug in MPIR 2.1.1 in mpz_divexact() (or
> >>> > > > > >> I'm doing something something very stupid). Running the
> >>> > > > > >> following program gives a Segmentation Fault:
> >>> > > > > >>
> >>> > > > > >> #include <mpir.h>
> >>> > > > > >> int main()
> >>> > > > > >> {
> >>> > > > > >>
> >>> > > > > >> mpz_t Z, R;
> >>> > > > > >> mpz_init(Z);
> >>> > > > > >> mpz_init(R);
> >>> > > > > >> mpz_ui_pow_ui(Z, 10, 100000);
> >>> > > > > >> mpz_divexact(R, Z, Z);
> >>> > > > > >> return 0;
> >>> > > > > >>
> >>> > > > > >> }
> >>> > > > > >>
> >>> > > > > >>
> >>> > > > > >> gdb backtrace:
> >>> > > > > >>
> >>> > > > > >> Program received signal SIGSEGV, Segmentation fault.
> >>> > > > > >> 0x00007fa2f2b5245d in mpn_submul_1 () from
> >>> > > > > >> /usr/local/src/pari/local/lib/libmpir.so.8
> >>> > > > > >> (gdb) bt
> >>> > > > > >> #0 0x00007fa2f2b5245d in mpn_submul_1 () from
> >>> > > > > >> /usr/local/src/pari/local/lib/libmpir.so.8
> >>> > > > > >> #1 0x00007fa2f2b73e72 in __gmpn_sb_divappr_q () from
> >>> > > > > >> /usr/local/src/pari/local/lib/libmpir.so.8
> >>> > > > > >> #2 0x00007fa2f2b812f2 in __gmpn_inv_divappr_q () from
> >>> > > > > >> /usr/local/src/pari/local/lib/libmpir.so.8
> >>> > > > > >> #3 0x00007fa2f2b88765 in __gmpn_divexact () from
> >>> > > > > >> /usr/local/src/pari/local/lib/libmpir.so.8
> >>> > > > > >> #4 0x00007fa2f2b3fb4b in __gmpz_divexact () from
> >>> > > > > >> /usr/local/src/pari/local/lib/libmpir.so.8
> >>> > > > > >> #5 0x0000000000400741 in main () at mpirtest.c:8
> >>> > > > > >>
> >>> > > > > >>
> >>> > > > > >> My system is:
> >>> > > > > >>
> >>> > > > > >> $ uname -a
> >>> > > > > >> Linux arcanis 2.6.32-gentoo-r7 #5 SMP Thu Jun 10 23:07:26
> >>> > > > > >> CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz
> >>> > > > > >> GenuineIntel GNU/Linux
> >>> > > > > >>
> >>> > > > > >> $ ./config.guess
> >>> > > > > >> core2-unknown-linux-gnu
> >>> > > > > >>
> >>> > > > > >> $ gcc --version
> >>> > > > > >> gcc-4.4.3 (Gentoo 4.4.3-r2 p1.2) 4.4.3
> >>> > > > > >>
> >>> > > > > >> This is with MPIR 2.1.1 configured with ./configure
> >>> > > > > >> --enable-gmpcompat
> >>> > > > > >>
> >>> > > > > >>
> >>> > > > > >> This bug was found thanks to Sage (see
> >>> > > > > >> http://trac.sagemath.org/sage_trac/ticket/9837)
> >>> > > > > >>
> >>> > > > > >>
> >>> > > > > >> Jeroen Demeyer.
> >>> > > > > >>
> >>> > > > > >> --
> >>> > > > > >> You received this message because you are subscribed to the
> >>> > > > > >> Google Groups "mpir-devel" group. To post to this group,
> >>> > > > > >> send email to [email protected]. To unsubscribe
> >>> > > > > >> from this group, send email to
> >>> > > > > >> [email protected]. For more options,
> >>> > > > > >> visit this group at
> >>> > > > > >> http://groups.google.com/group/mpir-devel?hl=en.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "mpir-devel" group. To post to this group, send email to
> >> [email protected]. To unsubscribe from this group, send email
> >> to [email protected]. For more options, visit
> >> this group at http://groups.google.com/group/mpir-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
