| Message ID | 87lhnhao0r.fsf@oracle.com |
|---|---|
| State | New |
| Headers | show |
> If no --with-cpu is specified at configure time gcc/config.gcc sets the > "cpu" option in configure_default_options to `v9' in sparc64 targets. > This leads to the usage of the following spec by the driver: > > %{!m32:%{!mcpu=*:-mcpu=v9}} > > Which in turn triggers the usage of -Av9 by default when invoking the > assembler. This leads to failures when VIS instructions are used in > inline assembly or .s files: > > [jemarch@install2 gcc]$ echo 'int main () { asm ("fzero %f0"); return 0; }' > | gcc -xc - /tmp/cc1F9iJm.s: Assembler messages: > /tmp/cc1F9iJm.s:11: Error: Architecture mismatch on "fzero". > /tmp/cc1F9iJm.s:11: (Requires v9a|v9b; requested architecture is v9.) I think that passing -mcpu=ultrasparc -mvis is a reasonable expectation when VIS instructions are used. > This prevents building upstream glibc with a gcc configured with not > --with-cpu option, for example. Certainly annoying. > I think it would be reasonable to have gcc targetting ultrasparc > extensions by default in sparc64-*-linux*. WDYT? No strong opinion. FreeBSD and OpenBSD already do it so why not? DaveM, any opinion?
From: Eric Botcazou <ebotcazou@adacore.com> Date: Mon, 15 Dec 2014 22:27:38 +0100 >> I think it would be reasonable to have gcc targetting ultrasparc >> extensions by default in sparc64-*-linux*. WDYT? > > No strong opinion. FreeBSD and OpenBSD already do it so why not? > > DaveM, any opinion? Keep in mind that some early Niagara chips lacked some portion of the VIS instructions and they are thus emulated in software. The other problem is that the instruction scheduling for "ultrasparc" is either completely unnecessary or wrong for all of the Niagara variants. In fact, 'ultrasparc' is the most complicated and resource intensive of all of the instruction schedulers we have yet it applies to a very small percentage of the actual chips still in use. The "ultrasparc3" scheduler is much smaller and much more efficient, and provides a schedule that works well across all chip variants.
Index: gcc/config.gcc =================================================================== --- gcc/config.gcc (revision 217346) +++ gcc/config.gcc (working copy) @@ -2709,6 +2709,7 @@ tm_file="sparc/biarch64.h ${tm_file} dbxelf.h elfos.h sparc/sysv4.h gnu-user.h linux.h glibc-stdint.h sparc/default-64.h sparc/linux64.h sparc/tso.h" extra_options="${extra_options} sparc/long-double-switch.opt" tmake_file="${tmake_file} sparc/t-sparc sparc/t-linux64" + test x$with_cpu != x || with_cpu=ultrasparc ;; sparc64-*-freebsd*|ultrasparc-*-freebsd*) tm_file="${tm_file} ${fbsd_tm_file} dbxelf.h elfos.h sparc/sysv4.h sparc/freebsd.h"
Hi. If no --with-cpu is specified at configure time gcc/config.gcc sets the "cpu" option in configure_default_options to `v9' in sparc64 targets. This leads to the usage of the following spec by the driver: %{!m32:%{!mcpu=*:-mcpu=v9}} Which in turn triggers the usage of -Av9 by default when invoking the assembler. This leads to failures when VIS instructions are used in inline assembly or .s files: [jemarch@install2 gcc]$ echo 'int main () { asm ("fzero %f0"); return 0; }' | gcc -xc - /tmp/cc1F9iJm.s: Assembler messages: /tmp/cc1F9iJm.s:11: Error: Architecture mismatch on "fzero". /tmp/cc1F9iJm.s:11: (Requires v9a|v9b; requested architecture is v9.) This prevents building upstream glibc with a gcc configured with not --with-cpu option, for example. I think it would be reasonable to have gcc targetting ultrasparc extensions by default in sparc64-*-linux*. WDYT? Thanks. 2014-11-11 Jose E. Marchesi <jose.marchesi@oracle.com> * config.gcc: Use ultrasparc as the default with_cpu option in sparc64-*-linux* targets.