-------- 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@cs.nyu.edu To: Roberto Bagnara bagnara@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