Date: Mon, 17 Mar 2003 23:30:19 -0800 From: David Schultz <das@FreeBSD.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: current@FreeBSD.org, alpha@FreeBSD.org Subject: Re: HEADS UP: Don't upgrade your Alphas! Message-ID: <20030318073019.GA10737@HAL9000.homeunix.com> In-Reply-To: <20030317164037.GB98100@sunbay.com> References: <20030317161219.GA1429@sunbay.com> <200303150947.h2F9l5eQ028059@repoman.freebsd.org> <20030317164037.GB98100@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Ruslan Ermilov <ru@FreeBSD.org>:
> Yes, as I have suspected, the gdtoa change is responsible
> for a breakage. libc corresponding to this lib/libc works:
>
> cvs -q up -P -d -D'2003/03/12 20:20:00'
>
> : Using /home/ru/w/f/usr.bin/awk/nawk nawk...
>
> This version, together with contrib/gdtoa, doesn't:
>
> cvs -q up -P -d -D'2003/03/12 20:29:59'
>
> : Using /home/ru/w/f/usr.bin/awk/nawk nawk...
> : nawk: floating point exception 8
> : input record number 325, file
> : source line number 84
>
> To see the breakage, one needs to install new libc, and
> run (assuming that /usr/bin/nawk is dynamically linked)
> make in usr.bin/truss; this will run the awk(1) script
> that exhibits one of these FPEs.
>
> P.S. Hmm, I didn't test this on i386, as I found this
> bug when attempting to produce a cross-release of i386
> on Alpha, so i386's may be affected too. Will see.
The bug is Alpha specific; makenewsyscalls.sh will die if you are
using an awk compiled with the new sources, regardless of what
architecture you are building for. This is because floating point
support on Alpha is broken unless you specifically tell gcc to
unbreak it by specifying -mieee. This week is really bad for me,
so unless there's a quick fix, I won't get a chance to look into
it further until Thursday night. Here's a way (other than using
-mieee when compiling awk) to hack around the problem. It may not
work with higher optimization levels.
Index: lib.c
===================================================================
RCS file: /home/ncvs/src/contrib/one-true-awk/lib.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 lib.c
--- lib.c 17 Mar 2003 07:59:58 -0000 1.1.1.3
+++ lib.c 18 Mar 2003 07:09:45 -0000
@@ -678,7 +678,7 @@
char *ep;
errno = 0;
r = strtod(s, &ep);
- if (ep == s || r == HUGE_VAL || errno == ERANGE)
+ if (ep == s || isinf(r) || errno == ERANGE)
return 0;
while (*ep == ' ' || *ep == '\t' || *ep == '\n')
ep++;
That said, can someone out there with Alpha FP clue let me know
why silent NaN's are broken? The architecture guide says that
software support is needed to support quiet vs. signalling NaNs,
but the default gcc settings seem to do this incorrectly. For
instance, the following is wrong:
das@beast:~> cat foo.c
#include <math.h>
int main () { return (NAN == HUGE_VAL); }
das@beast:~> gcc foo.c
das@beast:~> ./a.out
Floating exception
das@beast:~>
FWIW, the bug is caused by the fact that our strtod() didn't used
to understand the string "nan" as specified in ANSI C99, and now
it does. awk detects whether a given token is a number using
strtod(), and since quiet NaNs seem to incorrectly cause
exceptions on Alpha, it chokes on the "nanosleep" symbol in
syscalls.master. I'm hoping there's a better solution than
disabling support for NaNs in strtod().
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030318073019.GA10737>