John Martin wrote: > At best all I can say now is what the above compiler versions emit > for pure C code on SPARC with "-xregs=no%appl". If I understood > why other 32 bit "system" libraries in /usr/lib don't destructively use > %g2, I would agree it is a compiler bug. Things I still need > to investigate: > > Are 32 bit system libraries still being built with SOS8?
I (as an external person) would rather wonder if this was the case, but it's only a guess. Maybe in Solaris10(_n), but in Nevada?? > > > If not, are the 32 bit system libraries being built with a > new/different option? New option probably not, mhh. At least the most recent Studio 11 docs do not suggest a relevant change in usability : http://docs.sun.com/source/819-3688/cc_ops.app.html TABLE B-38 The -xregs Flags [no%]appl /(SPARC)/ [Does not] Allow the compiler to generate code using the application registers as scratch registers. The application registers are: g2, g3, g4 (v8a, v8, v8plus, v8plusa, v8plusb) g2, g3 (v9, v9a, v9b) It is strongly recommended that all system software and libraries be compiled using -xregs=no%appl. System software (including shared libraries) must preserve these registers' values for the application. Their use is intended to be controlled by the compilation system and must be consistent throughout the application. For more information on SPARC instruction sets, see Section B.2.66, -xarch=isa <http://docs.sun.com/source/819-3688/cc_ops.app.html#13670>. In the SPARC ABI, these registers are described as /application/ registers. Using these registers can increase performance because fewer load and store instructions are needed. However, such use can conflict with some old library programs written in assembly code. However, somebody has already found inconsitencies with another option: *-xregs=frameptr http://forum.java.sun.com/thread.jspa?threadID=5098159&messageID=9336146 * Maybe it is really a bug in cc?
