Ben Collins <[EMAIL PROTECTED]> writes: >> The gcc flags are inconsistent between sparc and x86 (and former gcc >> maintainers can forget which way round they are...). -mcpu on sparc >> selects the instruction/register set, not just the tuning as it does >> on x86. > > Not quite true, I believe. > IIRC, i486 -> pentiumpro incurs some > instructions being used in addition to normal x86 instructions.
The manual is quite explicit. If I remember correctly, I once clarified the x86 section after checking the machine description files. >> For sparc, -mtune=ultrasparc would be reasonable, on the basis that >> number crunching normally should be tuned for recent machines. On the >> other hand, if it can be made to go significantly faster on ultras by >> compiling with -mcpu=ultrasparc, it would be worth making multiple >> library versions like openssl does. > > > Similar to how -mcpu=i686 does not run on i386 machines, No, that's -march=i686. > so -mcpu=ultrasparc wont run on pre-ultrasparc machines. Which is why that version would live in /usr/lib/v9, just like openssl's libcrypto. > It's a given. I can't see how this is confusing. It's clearly confusing that the same flag has different meanings for different gcc cpu families. That's why the original suggestion for compiler flags is wrong and would have to be replaced by architecture-specific cases. I was trying to explain that situation for the benefit of someone doing cross-platform maintenance because I recognise the issue and actually checked the doc. I can't see how it's confusing to suggest multilibbing like openssl, whether or not it's actually justified in this case. It apparently is confusing, though.
