]> git.ipfire.org Git - thirdparty/gcc.git/commit
[nvptx] Use --no-verify for sm_30
authorTom de Vries <tdevries@suse.de>
Thu, 3 Mar 2022 08:21:04 +0000 (09:21 +0100)
committerTom de Vries <tdevries@suse.de>
Thu, 3 Mar 2022 09:43:34 +0000 (10:43 +0100)
commit12fa7641ceed9c9139e2ea7b62c11f3dc5b6f6f4
tree97b475f6a73b164207be2b3c1f0aa2ad2f6ad8df
parent5065d69fca535eeb869ba209cdf605f3ecf8b18d
[nvptx] Use --no-verify for sm_30

In PR97348, we ran into the problem that recent CUDA dropped support for
sm_30, which inhibited the build when building with CUDA bin in the path,
because the nvptx-tools assembler uses CUDA's ptxas to do ptx verification.

To fix this, in gcc-11 the default sm_xx was moved from sm_30 to sm_35.

This however broke support for sm_30 boards: an executable build for sm_30
might contain sm_35 code from the libraries, which are build with the default
sm_xx (PR104758).

We want to fix this by going back to having the libraries build with sm_30, as
was the case for gcc-5 to gcc-10.  That however reintroduces the problem from
PR97348.

Deal with PR97348 in the simplest way possible: when calling the assembler for
sm_30, specify --no-verify.

This has the unfortunate effect that after fixing PR104758 by building
libraries with sm_30, the libraries are no longer verified.  This can be
improved upon by:
- adding a configure test in gcc that tests if CUDA supports sm_30, and
  if so disabling this patch
- dealing with this in nvptx-tools somehow, either:
  - detect at ptxas execution time that it doesn't support sm_30, or
  - detect this at nvptx-tool configure time.

gcc/ChangeLog:

2022-03-03  Tom de Vries  <tdevries@suse.de>

* config/nvptx/nvptx.h (ASM_SPEC): Add %{misa=sm_30:--no-verify}.
gcc/config/nvptx/nvptx.h