July 2004 - PURRS-devel - BUGSENG Mailman

[Fwd: Re: Apparent non-termination of NTL's `make check' (version 5.3.2)]
by Roberto Bagnara 04 Jul '04

04 Jul '04

-------- Original Message -------- Subject: Re: Apparent non-termination of NTL's `make check' (version 5.3.2) Date: Sun, 4 Jul 2004 14:43:08 -0400 From: victor shoup <shoup(a)cs.nyu.edu> To: Roberto Bagnara <bagnara(a)cs.unipr.it> Thanks...the code where it seems stuck looks pretty innocent. For now, I'll go on the assumption that it's a gcc bug. You should be able to safely use NTL, with LLL_FP.c compiled with -O1. All the best, Victor On Sunday, July 4, 2004, at 11:57 AM, Roberto Bagnara wrote: > victor shoup wrote: >> I just thought of one other thing to try. >> Recompile everything with -O2, but ./configure with NTL_CLEAN_INT=on >> NTL_CLEAN_PTR=on >> To be honest, I'd be surprised if this worked, but if it does, that >> would be very interesting to me. >> These flags are supposed to avoid some code sequences that make >> assumptions that go >> beyond the language standard (but which seem to be universally >> implemented). > > No, compiling with these flags does not eliminate the infinite loop. > >> Some other things to investigate: are the problems ONLY with the >> subset program? > > Yes. > >> Finally, I guess one should try compiling with -g -O2, and run the >> subset program in gdb, >> force it to quit when its in an infinite loop, and get a >> backtrace...now that I think of it, I guess this is >> the first thing one should really try! > > Yes, it seems to loop around here: > > Program received signal SIGINT, Interrupt. > BKZ_FP (BB=@0xbfffd740, UU=0x0, delta=0.98999999999999999, beta=20, > prune=10, > check=0x8049640 <SubsetSumSolution(NTL::vec_ZZ const&)>) at > LLL_FP.c:1505 > 1505 for (i = jj; i <= kk; i++) { > (gdb) info stack > #0 BKZ_FP (BB=@0xbfffd740, UU=0x0, delta=0.98999999999999999, beta=20, > prune=10, check=0x8049640 <SubsetSumSolution(NTL::vec_ZZ const&)>) > at LLL_FP.c:1505 > #1 0x08049fa1 in main () at subset.c:111 > (gdb) > > All the best, > > Roberto > > -- > Prof. Roberto Bagnara > Computer Science Group > Department of Mathematics, University of Parma, Italy > http://www.cs.unipr.it/~bagnara/ > mailto:bagnara@cs.unipr.it > -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

Re: Apparent non-termination of NTL's `make check' (version 5.3.2)
by Roberto Bagnara 04 Jul '04

04 Jul '04

victor shoup wrote: > I just thought of one other thing to try. > Recompile everything with -O2, but ./configure with NTL_CLEAN_INT=on > NTL_CLEAN_PTR=on > To be honest, I'd be surprised if this worked, but if it does, that > would be very interesting to me. > These flags are supposed to avoid some code sequences that make > assumptions that go > beyond the language standard (but which seem to be universally > implemented). No, compiling with these flags does not eliminate the infinite loop. > Some other things to investigate: are the problems ONLY with the subset > program? Yes. > Finally, I guess one should try compiling with -g -O2, and run the > subset program in gdb, > force it to quit when its in an infinite loop, and get a backtrace...now > that I think of it, I guess this is > the first thing one should really try! Yes, it seems to loop around here: Program received signal SIGINT, Interrupt. BKZ_FP (BB=@0xbfffd740, UU=0x0, delta=0.98999999999999999, beta=20, prune=10, check=0x8049640 <SubsetSumSolution(NTL::vec_ZZ const&)>) at LLL_FP.c:1505 1505 for (i = jj; i <= kk; i++) { (gdb) info stack #0 BKZ_FP (BB=@0xbfffd740, UU=0x0, delta=0.98999999999999999, beta=20, prune=10, check=0x8049640 <SubsetSumSolution(NTL::vec_ZZ const&)>) at LLL_FP.c:1505 #1 0x08049fa1 in main () at subset.c:111 (gdb) All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

Re: Apparent non-termination of NTL's `make check' (version 5.3.2)
by Roberto Bagnara 04 Jul '04

04 Jul '04

victor shoup wrote: > That's interesting...so the problem lies somewhere else. No, sorry: the problem goes away if LLL_FP.c is compiled with -O1 or without optimization. Yesterday I was misled by the fact that if you run `make' any number of times on NTL's src directory, things are recompiled again and again. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

[Fwd: Re: Cannot compile GIAC 0.4.0]
by Roberto Bagnara 04 Jul '04

04 Jul '04

-------- Original Message -------- Subject: Re: Cannot compile GIAC 0.4.0 Date: Sun, 04 Jul 2004 09:33:36 +0200 From: Bernard Parisse <bernard.parisse(a)wanadoo.fr> Reply-To: parisse(a)mozart.ujf-grenoble.fr To: Roberto Bagnara <bagnara(a)cs.unipr.it> References: <40E6CC11.7080207(a)cs.unipr.it> <40E6FA38.3090905(a)wanadoo.fr> <40E713CB.6040501(a)cs.unipr.it> Hello, Attached is my patched version with your changes + the following changes: * a variable name change for modgcd * removed zero declaration, replaced by constructor calls, I had to use a static local variable for the reference. * removed all offending ptr_fun (it seems the compiler knows how to make the ptr_fun better than me) I hope that it will now compile with gcc 3.4, if not then maybe a ssh account on your machine could help me adapt giac. Regards, Bernard -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

[Fwd: Re: Apparent non-termination of NTL's `make check' (version 5.3.2)]
by Roberto Bagnara 04 Jul '04

04 Jul '04

-------- Original Message -------- Subject: Re: Apparent non-termination of NTL's `make check' (version 5.3.2) Date: Sat, 3 Jul 2004 19:56:57 -0400 From: victor shoup <shoup(a)cs.nyu.edu> To: Roberto Bagnara <bagnara(a)cs.unipr.it> I just thought of one other thing to try. Recompile everything with -O2, but ./configure with NTL_CLEAN_INT=on NTL_CLEAN_PTR=on To be honest, I'd be surprised if this worked, but if it does, that would be very interesting to me. These flags are supposed to avoid some code sequences that make assumptions that go beyond the language standard (but which seem to be universally implemented). Some other things to investigate: are the problems ONLY with the subset program? Try removing that from the test script, and see if all the other tests pass (which they apparently do, up to that one). Finally, I guess one should try compiling with -g -O2, and run the subset program in gdb, force it to quit when its in an infinite loop, and get a backtrace...now that I think of it, I guess this is the first thing one should really try! -- Victor On Saturday, July 3, 2004, at 03:45 PM, Roberto Bagnara wrote: > > I have replaced "-O2" by "-g" in `makefile', but recompiling LLL_FP.c > only did not fix the problem. However, by rebuilding the entire > library > with "-g" instead of "-O2", `make check' terminates successfully. > Please let me know if I can do more to help you trace the problem. > All the best, > > Roberto > -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

[Fwd: Re: Apparent non-termination of NTL's `make check' (version 5.3.2)]
by Roberto Bagnara 04 Jul '04

04 Jul '04

-------- Original Message -------- Subject: Re: Apparent non-termination of NTL's `make check' (version 5.3.2) Date: Sat, 3 Jul 2004 18:03:42 -0400 From: victor shoup <shoup(a)cs.nyu.edu> To: Roberto Bagnara <bagnara(a)cs.unipr.it> Hi, That's interesting...so the problem lies somewhere else. Isolating the problem is a matter of a process of elimination, and it won't be to easy to do this, unless I have direct access to your gcc compiler. I don't have immediate access gcc v3.4.1. Maybe someone here at NYU has one I can borrow...or maybe you could give me login access to one of your machines with the same compiler. I'm busy with lots of other things right now, and don't have a lot of time to work on this. If you can survive for the moment with this workaround, I'll wait and see if others have a similar problem....so far, you're the first I've heard from with such a problem (and actually, I get *very* few bug reports of any kind). Here are a few simple things you might try. First, try compiling with the option -O1, just to see if that makes a difference. What I would do next is figure out what .o files are actually linked into the subset program. Then do a "binary search", compiling some with and some without -O2 (or whatever) to isolate at least which .c file is causing the problem. Then one has to do a binary search within the file (maybe there are pragmas to turn optimization on/off...I forget). It's not very exciting work! This isn't the first gcc problem I've encountered! Although I admit, there is the possibility that the NTL code is making assumptions that are too strong (and which the optimizer does not honor). -- Victor On Saturday, July 3, 2004, at 03:45 PM, Roberto Bagnara wrote: > > I have replaced "-O2" by "-g" in `makefile', but recompiling LLL_FP.c > only did not fix the problem. However, by rebuilding the entire > library > with "-g" instead of "-O2", `make check' terminates successfully. > Please let me know if I can do more to help you trace the problem. > All the best, > > Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

Re: Cannot compile GIAC 0.4.0
by Roberto Bagnara 03 Jul '04

03 Jul '04

Bernard Parisse wrote: > I have some hints that could fix the problem, but I can not test > them since I don't have gcc 3.4 installed. Dear Bernard, please let me know if I can help (e.g., by giving you access to a machine with gcc 3.4.1). > The template code for Normalrref is never instantiated, that's why the > error does not appear with previous versions of gcc. Declaring > temp and newcoord as vector< monomial<T> > should fix the compilation > error. OK. > zero is assumed to be declared of type T when these functions are > instantiated. I don't know how to declare zero as a template variable > (would extern T zero; work inside a function?) Yes, if this is what you want. However, this conflicts with the declaration extern gen zero; in gen.h. > gcc is correct, f. should be removed (twice) OK. We still have the following problems (apart from the conflicting declarations for zero): c++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -g -O2 -c gausspol.cc -fPIC -DPIC -o .libs/gausspol.lo gausspol.cc: In function `bool giac::gcd_modular_algo(giac::polynome&, giac::polynome&, giac::polynome&)': gausspol.cc:982: error: no match for call to `(giac::polynome) (giac::polynome&, giac::polynome&, giac::gen&)' poly.h:385: note: candidates are: giac::tensor<T> giac::tensor<T>::operator()(const T&) const [with T = giac::gen] poly.h:266: note: T& giac::tensor<T>::operator()(const giac::index_m&) [with T = giac::gen] poly.h:277: note: const T& giac::tensor<T>::operator()(const giac::index_m&) const [with T = giac::gen] The following is cured by adding an include of <iostream> in global.h c++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -g -O2 -c ti89.cc -fPIC -DPIC -o .libs/ti89.lo In file included from misc.h:23, from ti89.cc:25: global.h: In member function `void giac::dbgprint_vector<T>::dbgprint()': global.h:130: error: `cout' is not a member of `std' A similar problem with cerr is in monomial.h. The nastier seems to be this one: monomial.h: In function `std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> > > giac::operator+(const std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> > >&, const std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> > >&)': monomial.h:302: error: there are no arguments to `ptr_fun' that depend on a template parameter, so a declaration of `ptr_fun' must be available monomial.h:302: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) monomial.h: In function `std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> > > giac::operator-(const std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> > >&, const std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> > >&)': monomial.h:364: error: there are no arguments to `ptr_fun' that depend on a template parameter, so a declaration of `ptr_fun' must be available In file included from sym2poly.h:23, from input_lexer.ll:44: poly.h: In constructor `giac::tensor<T>::tensor()': poly.h:47: error: there are no arguments to `ptr_fun' that depend on a template parameter, so a declaration of `ptr_fun' must be available poly.h: In constructor `giac::tensor<T>::tensor(int)': poly.h:48: error: there are no arguments to `ptr_fun' that depend on a template parameter, so a declaration of `ptr_fun' must be available poly.h: In constructor `giac::tensor<T>::tensor(const giac::monomial<T>&)': poly.h:49: error: there are no arguments to `ptr_fun' that depend on a template parameter, so a declaration of `ptr_fun' must be available poly.h: In constructor `giac::tensor<T>::tensor(const T&, int)': poly.h:52: error: there are no arguments to `ptr_fun' that depend on a template parameter, so a declaration of `ptr_fun' must be available poly.h: In constructor `giac::tensor<T>::tensor(int, const std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> > >&)': poly.h:56: error: there are no arguments to `ptr_fun' that depend on a template parameter, so a declaration of `ptr_fun' must be available I attach the patch file containing my changes up to now. I would be grateful if you could tell me how to procees. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it diff -rcp2N --exclude-from=exclude /usr/local/distrib/giac-0.4.0/src/fraction.h giac-0.4.0/src/fraction.h *** /usr/local/distrib/giac-0.4.0/src/fraction.h Sat Jul 3 21:51:52 2004 --- giac-0.4.0/src/fraction.h Thu Feb 12 10:22:04 2004 *************** std::ostream & operator << (std::ostream *** 183,187 **** template <class T> void Tfraction<T>::dbgprint() { ! std::cout << num << "/" << den << " " ; } --- 183,187 ---- template <class T> void Tfraction<T>::dbgprint() { ! std::cout << f.num << "/" << f.den << " " ; } diff -rcp2N --exclude-from=exclude /usr/local/distrib/giac-0.4.0/src/global.h giac-0.4.0/src/global.h *** /usr/local/distrib/giac-0.4.0/src/global.h Sat Jul 3 22:00:15 2004 --- giac-0.4.0/src/global.h Wed Jun 23 13:27:24 2004 *************** inline double giac_log(double d){ *** 73,77 **** #include <signal.h> #include <stdexcept> - #include <iostream> #include "help.h" --- 73,76 ---- diff -rcp2N --exclude-from=exclude /usr/local/distrib/giac-0.4.0/src/monomial.h giac-0.4.0/src/monomial.h *** /usr/local/distrib/giac-0.4.0/src/monomial.h Sat Jul 3 22:03:33 2004 --- giac-0.4.0/src/monomial.h Wed May 5 20:52:22 2004 *************** void Add ( typename std::vector< monomia *** 292,296 **** } if (log) ! std::cerr << "+ end " << clock() << endl; } --- 292,296 ---- } if (log) ! cerr << "+ end " << clock() << endl; } *************** template <class T> *** 765,770 **** void Normalrref (std::vector< monomial<T> > & v,int rows,int cols, index_t & permut, bool dobareiss=true){ Rref(v,rows,cols,permut,dobareiss); - std::vector< monomial<T> > temp; - std::vector< monomial<T> > newcoord; // divide each non-zero row by leading coeff and order typename std::vector< monomial<T> >::const_iterator it=v.begin(),itend=v.end(); --- 765,768 ---- diff -rcp2N --exclude-from=exclude /usr/local/distrib/giac-0.4.0/src/poly.h giac-0.4.0/src/poly.h *** /usr/local/distrib/giac-0.4.0/src/poly.h Sat Jul 3 21:56:39 2004 --- giac-0.4.0/src/poly.h Mon Mar 8 13:29:50 2004 *************** index_m tensor<T>::vector_int(int positi *** 265,269 **** template <class T> T & tensor<T>::operator () ( const index_m & v) { - extern T zero; int p=position(v); if (p!=-1) --- 265,268 ---- *************** T & tensor<T>::operator () ( const index *** 276,280 **** template<class T> const T & tensor<T>::operator () ( const index_m & v) const{ - extern T zero; int p=position(v); if (p==-1) { --- 275,278 ---- *************** bool tensor<T>::TPseudoDivRem (const ten *** 784,788 **** template <class T> T tensor<T>::constant_term () const { - extern T zero; if (!((*this).coord.size())) return zero; --- 782,785 ----

1 0

[Fwd: Re: Cannot compile GIAC 0.4.0]
by Roberto Bagnara 03 Jul '04

03 Jul '04

-------- Original Message -------- Subject: Re: Cannot compile GIAC 0.4.0 Date: Sat, 03 Jul 2004 20:26:00 +0200 From: Bernard Parisse <bernard.parisse(a)wanadoo.fr> Reply-To: parisse(a)mozart.ujf-grenoble.fr To: Roberto Bagnara <bagnara(a)cs.unipr.it> References: <40E6CC11.7080207(a)cs.unipr.it> Roberto Bagnara wrote: > > Dear Bernard, > > I have downloaded GIAC 0.4.0 and tried to compile it with > GCC 3.4.1 (which contains a fix for the bug I told you back > in May). However, the compilation fails immediately as > follows: > Hello! I have some hints that could fix the problem, but I can not test them since I don't have gcc 3.4 installed. > monomial.h: In function `void > giac::Normalrref(std::vector<giac::monomial<T>, > std::allocator<giac::monomial<T> > >&, int, int, giac::index_t&, bool)': > monomial.h:776: error: `temp' undeclared (first use this function) > monomial.h:776: error: (Each undeclared identifier is reported only > once for each function it appears in.) > monomial.h:778: error: `newcoord' undeclared (first use this function) The template code for Normalrref is never instantiated, that's why the error does not appear with previous versions of gcc. Declaring temp and newcoord as vector< monomial<T> > should fix the compilation error. > > In file included from sym2poly.h:23, > from sym2poly.cc:32: > poly.h: In member function `T& giac::tensor<T>::operator()(const > giac::index_m&)': > poly.h:270: error: `zero' undeclared (first use this function) > poly.h: In member function `const T& giac::tensor<T>::operator()(const > giac::index_m&) const': > poly.h:279: error: `zero' undeclared (first use this function) > poly.h: In member function `T giac::tensor<T>::constant_term() const': > poly.h:785: error: `zero' undeclared (first use this function) zero is assumed to be declared of type T when these functions are instantiated. I don't know how to declare zero as a template variable (would extern T zero; work inside a function?) > In file included from gen.h:37, > from sym2poly.h:24, > from sym2poly.cc:32: > fraction.h: In member function `void Tfraction<T>::dbgprint()': > fraction.h:185: error: `f' undeclared (first use this function) gcc is correct, f. should be removed (twice) > In file included from sym2poly.h:24, > from sym2poly.cc:32: > gen.h: At global scope: > gen.h:308: error: `giac::gen giac::zero' used prior to declaration Maybe it's related to the zero above? Seems strange since line 308 is a declaration. > > The compiler seems right in, e.g., `temp' is undeclared in > giac::Normalrref(). Have you got any idea what the problem > may be? > Best regards, Bernard -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

Re: Apparent non-termination of NTL's `make check' (version 5.3.2)
by Roberto Bagnara 03 Jul '04

03 Jul '04

victor shoup wrote: > Don't worry about the version number issue. OK. > I haven't seen the problem with the "subset" program before. > It should terminate in a few seconds. > > The code associated with that program hasn't changed for years. > It looks like you are using a pretty "bleeding edge" version of gcc. > I suspect it could be some kind of issue with floating point > arithmetic...possibly a bug in the > compiler, or possibly the NTL code makes an assumption about code > generation that is > not strictly "legal" somehow. > > If you have access to an older version of gcc, try that. > Also, try compiling without optimization...the quickest way to do this > in this case: > 1) edit makefile, and delete -O2 from the compiling options (should be > obvious where this is). > 2) touch LLL_FP.c (that should be the file causing the problem) > 3) make ntl.a (should cause just LLL_FP.c to be recompiled) > 4) make check (try again) > > Let me know what happens....even if this is a gcc bug, I should try to > find a work-around. I have replaced "-O2" by "-g" in `makefile', but recompiling LLL_FP.c only did not fix the problem. However, by rebuilding the entire library with "-g" instead of "-O2", `make check' terminates successfully. Please let me know if I can do more to help you trace the problem. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

[Fwd: Re: Apparent non-termination of NTL's `make check' (version 5.3.2)]
by Roberto Bagnara 03 Jul '04

03 Jul '04

-------- Original Message -------- Subject: Re: Apparent non-termination of NTL's `make check' (version 5.3.2) Date: Sat, 3 Jul 2004 11:01:50 -0400 From: victor shoup <shoup(a)cs.nyu.edu> To: Roberto Bagnara <bagnara(a)cs.unipr.it> Hi, Don't worry about the version number issue. I haven't seen the problem with the "subset" program before. It should terminate in a few seconds. The code associated with that program hasn't changed for years. It looks like you are using a pretty "bleeding edge" version of gcc. I suspect it could be some kind of issue with floating point arithmetic...possibly a bug in the compiler, or possibly the NTL code makes an assumption about code generation that is not strictly "legal" somehow. If you have access to an older version of gcc, try that. Also, try compiling without optimization...the quickest way to do this in this case: 1) edit makefile, and delete -O2 from the compiling options (should be obvious where this is). 2) touch LLL_FP.c (that should be the file causing the problem) 3) make ntl.a (should cause just LLL_FP.c to be recompiled) 4) make check (try again) Let me know what happens....even if this is a gcc bug, I should try to find a work-around. Also: I doubt that it is a gmp bug, but if turning optimization off doesn't help, then you should try rebuilding ntl w/ "classic" long integer arithmetic, just to rule that out. -- Victor On Saturday, July 3, 2004, at 10:25 AM, Roberto Bagnara wrote: > > Dear Sir, > > I have downloaded NTL 5.3.2 and I have configured it with the command > > $ ./configure NTL_GMP_LIP=on NTL_STD_CXX=on GMP_PREFIX=/usr/local > > Doing `make' proceeds fine, even though the MakeDesc command seems > to print the wrong version number: > > $ make > make setup1 > make[1]: Entering directory `/usr/local/distrib/ntl-5.3.2/src' > gcc -I../include -I. -O2 -c MakeDescAux.c > gcc -I../include -I. -O2 -o MakeDesc MakeDesc.c MakeDescAux.o -lm > ./MakeDesc > This is NTL version 5.3.1 > > GOOD NEWS: compatible machine. > summary of machine characteristics: > bits per long = 32 > bits per int = 32 > bits per size_t = 32 > arith right shift = yes > double precision = 53 > NBITS (maximum) = 30 > single mul ok = yes > register double precision = 64 > double rounding detected = yes > -- auto x86 fix > > > mv mach_desc.h ../include/NTL/mach_desc.h > [...] > > When I do `make check', the process arrives to the following point > > [...] > running LLLTest > LLL_FP...0 > LLL_QP...0.02 > LLL_XD...0.03 > LLL_RR...0.18 > G_LLL_FP...0.01 > G_LLL_QP...0.07 > G_LLL_XD...0.07 > G_LLL_RR...0.52 > LLL...0.01 > LLLTest OK > > --------------------------------- > making subset > make[1]: Entering directory `/usr/local/distrib/ntl-5.3.2/src' > g++ -I../include -I. -O2 -o subset subset.c ntl.a -L/usr/local/lib > -lgmp -lm > make[1]: Leaving directory `/usr/local/distrib/ntl-5.3.2/src' > subset 40 40 20 10 999999 f > n: b: size: prune: seed: alg [fqQxr]: + > > and then sits there for ages. On my machine, an Athlon 2800 running > Red Hat Linux 9, the `subset' process is running since almost 5 hours > now. > I am using GCC 3.4.1 and GMP 4.3.1. > Have you any idea what the problem may be? > Thanks a lot, > > Roberto > > -- > Prof. Roberto Bagnara > Computer Science Group > Department of Mathematics, University of Parma, Italy > http://www.cs.unipr.it/~bagnara/ > mailto:bagnara@cs.unipr.it > > -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0