On Wed, May 23, 2012 at 2:08 PM, Adam D. Barratt
<adam@adam-barratt.org.uk> wrote:
On Wed, 2012-05-23 at 13:44 -0500, Patrick Baggett wrote:
> I didn't see where GCC was dropping 32-bit sparc upstream in the
> changelogs. This seems inaccurate since a 64-bit userland has negative
> performance implications, and this is true for both Solaris and Linux
> and not recommended by anyone. A 64-bit userland is barely available
> for Linux -- just a few C libraries like pthreads, libc, and zlib. Are
> you sure this is correct?
If you check http://release.debian.org/squeeze/arch_qualify.html ,
you'll see that the comment on 32-bit code generation was added the last
time we went through this exercise, a release cycle ago. Also note the
careful phrasing of the note - "32 bit code generation _as we use it_".
My memory (backed up somewhat by having found the notes from the
relevant IRC meeting) is that this was related to the use of -mcpu=v9 on
32-bit in a way that was very Debian-specific rather than being fully
supported upstream.
I'm not sure how much all of that still applies, but if it's wrong then
hopefully someone from the porters can correct it. That's rather why I
requested comments...
Regards,
Adam
Hmm. That does seem odd too. "-mcpu=v9" means "use SPARCv9 instructions and extensions from SPARCv8". Any CPU > 1996 can use these, and it's the default on Solaris. I build a lot of 32-bit sparc code on both Solaris and Linux (same code base) and use this flag without issues. I can't imagine what the alternative might be. I would like to hear about this from any porters as well. It seems critical that some method for using v9 extensions in 32-bit code be maintained.
Patrick