> > > Because GCC maintainers have been saying for years, that they are > unwilling to support the weird use case of Debian sparc port, which has > 64-bit kernel but 32-bit userspace. I can find discussions about it going > back as far as 2009: > > Also, a lot of the messages about "removing v8 support" or "upstream dropping sparc32" is confusing. SPARCv8, sometimes called "sparc32" (more specifically, 32-bit SPARCv8 ISA that predates the 64-bit ISA, SPARCv9) is used by just *one* CPU that is modern -- "Leon". The remaining CPUs are all 64-bit since 1997. However, a 32-bit *ABI* (note ABI, NOT ISA) used on a v9 platform seems like a sane idea, and that is the current case of Debian and Solaris. This is because it's absolutely a terrible idea to remove a 32-bit ABI for v9 CPUs. This ABI is called "v8+", which incidentally is a terrible name.
I don't care if Debian or other upstream packages drops "sparc32" aka "v8" support, because the current kernel will only boot on SPARCv9 CPUs, so it doesn't make any sense to add a constraint that "binaries must run on v8 CPUs". And I mostly don't care if GCC removes the ability to generate "sparc32" aka "SPARCv8" code. What I *do* care about it the removal of the ability to build 32-bit binaries on SPARCv9, because 64-bit only binaries is a ridiculous idea. So Jurij, I don't see any reason to believe that "upstream support is disappearing". None of the messages are from GCC maintainers directly, and nothing on GCC's website about 4.7 / 4.8 states this to be the case. Patrick
