GMP build issues on Solaris 10 UltraSPARC
cryintothebluesky at gmail.com
Fri Nov 10 17:24:30 UTC 2017
On Fri, 10 Nov 2017 17:49:05 +0100
tg at gmplib.org (Torbjörn Granlund) wrote:
> Sad Clouds <cryintothebluesky at gmail.com> writes:
> + [ultrasparct])
> + gcc_cflags_cpu="-mcpu=niagara -mcpu=v9"
> + gcc_32_cflags_asm="-Wa,-Av8plusc
> + gcc_64_cflags_asm="-Wa,-Av9c
> Using -xarch=v8plusc is wrong for UltraSPARC T1 and T2 processors,
> since they don't support VIS3 instructions set. This results in the
> following ld.so errors when using Sun assembler hardware capability
> (CA_SUNW_HW_1) unsupported: 0x400
> GNU assembler states that:
> ?-Av8plusc? and ?-Av9c? enable the UltraSPARC Niagara instructions,
> as well as the instructions enabled by ?-Av8plusb? and ?-Av9b?.
> However this is wrong, since with Sun/Oracle compilers this option
> is used for SPARC64 VI processor.
> Clearly, the GNU compiler/assembler and the Solaris compiler/assembler
> do not agree about the meaning of what v8plusc means. I suppose it
> is a mistake in the GNU camp.
> What do you suggest that we do for GMP?
> Perhaps just pass v8plusb for T1/T2? I mean, these CPUs are so
> horrendously slow anyway that nobody in his right mind would perform
> any computation on them anyway.
Well, the CPUs in question are about 11 years old and they were not
designed for HPC workloads, but for highly threaded applications, prone
to memory latencies, etc. The biggest problem with UltraSPARC is that
Oracle are pulling the plug on it and laid off many SPARC and Solaris
engineers. I just happen to like SPARC and Solaris and the hardware on
Ebay is really cheap now, when I saw Sun Enterprise T5220 server for
$200 I couldn't resist it.
Anyway, Sun/Oracle C compiler expands -xtarget=natvie to the following:
-xtarget=native -xchip=ultraT2 -xcache=8/16/4:4096/64/16 -xarch=sparcvis2
So, I think using -xarch=sparcvis2 for these processors should be OK.
More information about the gmp-bugs