diff options
author | Tom de Vries <tdevries@suse.de> | 2022-03-03 09:21:04 +0100 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2022-03-03 10:43:34 +0100 |
commit | 12fa7641ceed9c9139e2ea7b62c11f3dc5b6f6f4 (patch) | |
tree | 97b475f6a73b164207be2b3c1f0aa2ad2f6ad8df /gcc/fortran/openmp.cc | |
parent | 5065d69fca535eeb869ba209cdf605f3ecf8b18d (diff) | |
download | gcc-12fa7641ceed9c9139e2ea7b62c11f3dc5b6f6f4.zip gcc-12fa7641ceed9c9139e2ea7b62c11f3dc5b6f6f4.tar.gz gcc-12fa7641ceed9c9139e2ea7b62c11f3dc5b6f6f4.tar.bz2 |
[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}.
Diffstat (limited to 'gcc/fortran/openmp.cc')
0 files changed, 0 insertions, 0 deletions