On Tue, Oct 09, 2001 at 12:43:01PM +0200, Othmar Pasteka wrote: > Hi, > > On Tue, Oct 09, 2001 at 11:30:13AM +0100, Nicholas Clark wrote: > > What kernel is on the machine attempting to build? IIRC there were NaN > > the kernel was a 2.4.5-rmk7 ... it's now a 2.4.9-ac18-rmk1 ... so > maybe it was fixed meanwhile. although your other comments > doesn't look like it ...
Sorry if I wasn't clear. I've seen no NaN problems on any 2.4 series kernel. I did see problems on 2.2.18, and tracked it down to problems in the version of NWFPE on 2.2.18. I'm aware of one other FP oddity, which probably isn't what you're seeing. Last time I explicitly checked (2.1.3 or so) glibc (or gcc 2.95.2 if that's the culprit) was causing floating point less than the smallest signed long long to some odd value which appeared to be an error. This may also cause problems. [I realise that casting out of range floating point values to integers is undefined behaviour in ANSI C. Any portable program that relies on this is buggy. The observation I'm making is that it appears that gcc/glibc (at least on arm) is attempting to provide a specific behaviour of clamping out of range values, but the code on arm was (is?) buggy. If I'm right both in that gcc/glibc generally is attempting to define a behaviour, and in that it's only the arm code that is buggy, then programs which work on other Debian architectures will break on arm for no apparent reason] Sorry that this message is long an waffling, with no solid content. Nicholas Clark
