Subject: Exactly what is wrong with our compiler?
To: None <port-sparc64@netbsd.org>
From: Geoff Adams <gadams@avernus.com>
List: port-sparc64
Date: 01/03/2002 02:45:43
As I understand it, there are known to be problems with the sparc v9 
code generated by gcc (both 2.9x.x and 3.x). According to a brief email 
conversation with one of the gcc maintainers, 3.x is not considered 
working on Ultrasparc. I also notice that we use 2.95.3 as our sparc64 
compiler, which hints that we (NetBSD) also know of problems with gcc 
3.x. I also understand that we have a number of patches relative to gcc 
2.95.3 for our NetBSD-specific version of the compiler. Still, as I 
understand it, there are problems with our 2.95.3.

But nowhere can I find documentation about just what is wrong with the 
compiler. Does anyone really know, or do we just know that things don't 
quite work all the time? Is there any web page or set of pages that 
contain this information? I'd be happy to gather and summarize (suitable 
for inclusion on a port-sparc web page, even) if anyone can point me at 
concrete information about what's going on, here.

I do know about the NTP problem, recently discussed here, that isn't 
strictly a gcc codegen error; more of a disagreement. I also know that 
we have FPU emulation problems with quad floats. (As I understand it, 
this is a matter of missing support for quad floats in the FPU emulator. 
I don't understand why we're using an FPU emulator for this, though -- 
surely we have a real FPU! Or is it that the FPU doesn't handle quad 
floats, and we are just emulating what an FPU would do with quad floats 
if it supported them? In that event, -mquad-soft-float works, so why 
can't the emulator do what -mquad-soft-float does? Would this be 
equivalent to making that option the default?)

I thank anyone in advance for any help elucidating this.

In the meantime, I've discovered that the db library built as part of 
MIT Kerberos 5 (and probably much of the rest of krb5) doesn't work as 
compiled by our in-tree gcc. (It works with at least gcc 2.95.2 on 
Solaris 7, although that's producing 32-bit V8+ code, of course.) 
Despite some time spent in gdb, I haven't yet tracked down at what point 
it fails, but it does fail the regression tests. That, and nothing 
works. Hmph. (And, before anyone asks: yes, I know we have Heimdal 
in-tree, but I run MIT krb5 at my sites, and the two are incompatible in 
distressing ways.)

Cheers,
- Geoff