On Wed, May 23, 2012 at 2:08 PM, Adam D. Barratt <a...@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
