The NMH "scan" program just reads the headers of each mail message in an NMH
	folder.  So all the first column numbers should have been consecutively
	numbered file names.  But instead of "1", etc. it was coming up with "?4128"
	which to me shows some kind of massive overflow problem with "-O2" in that
	particular instance.

From the description it sounds like a pointer aliasing problem
that's occurring because we use 64-bit big-endian datatypes.
The source should be checked for weird pointer casts.

	How did an entire OS and kernel get built successfully if it's in this kind of
	state?  'Cos other than some random programs (like "xntpd") that crash, most
	everything else seems to work OK so far ... (I'm glad for that!  hehe)

Code generation is pretty good in general.  It's more likely
for the compiler to fall on its face than generate bogus code.
Of course this is only for C code.  C++ seems to generate bad
code and not bomb.

	But I'm starting to run into thornier stuff.  For example, "sudo" needs
	autoconf-2.31 and m4-1.4.  When it runs "autoconf" to create "configure",
	these huge bogus line numbers get generated into "configure", and it barfs
	on itself when it runs.  I traced this back to "awk" (I think), and here's
	a simple demonstration:

awk is known to have problems.  We are building it with --fquad-soft-float
to work around them.  But I don't completely trust awk to work right.

	netbsd4me# uname -rm
	1.5 sparc64
	netbsd4me# awk 'END { printf("%d\n", 1) ; }'
	9223372045444710399

	Note that this number in Hex is 0x80000001FFFFFFFF.  Significant?

	If "awk" can't even print out a simple "1" without serious problems, well ...

There are some issues with floatind point printing and conversion
in older versions of libc.

Are you running the latest snapshot or 1.5?  Works for me:

nonplus.netbsd.org:/bsd/src/lib/libc/arch/sparc64: echo foo | awk 'END { printf("%d\n", 1) ; }'
1
nonplus.netbsd.org:/bsd/src/lib/libc/arch/sparc64:     

I'm running what I packaged up as the 20010114 snapshot.

Eduardo