| 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.

Both floating point and C++ code generation is just broken.

| 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?)

As far as I know the NTP problem is not a sparc64 specific problem but
a general gcc foulup that happens to hit sparc64 because it's a 64-bit
platform and doesn't to alignment fixups.

| 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.)

There may be issues with SPARC assembly code routines, or the sources 
could just not be 64-bit clean.

Eduardo