Bug#1021660: gcc-12-offload-nvptx: offloading to nvidia via nvptx fails with cuda version 11 (default in sid)
Hi!
(Tom added in CC; for your information, this is about
<https://bugs.debian.org/1021660>.)
On 2022-10-13T12:38:17+0200, Giacomo Mulas <giacomo.mulas@inaf.it> wrote:
> On Thu, 13 Oct 2022, Thomas Schwinge wrote:
>
>> Aha, that's a legit question to wonder about: the reason is that GCC 11
>> defaulted to sm_35 code generation (which CUDA 11 still does support):
>> <https://gcc.gnu.org/gcc-11/changes.html#nvptx>, just then GCC 12 again
>> reverted to sm_30: <https://gcc.gnu.org/gcc-12/changes.html#nvptx>.
>
> but then, wouldn't the most straightforward fix to change again GCC 12 to
> generate sm_35 code by default?
GCC upstream would like to continue supporting old GPU hardware, some of
which doesn't support sm_35. That's why GCC 12 fixed this "regression"
introduced in GCC 11, and reverted back to sm_30, like GCC 10 and earlier
had.
> And also, is there some oscure command line
> option to explicitly request GCC 12 to generate code of some specific sm
> level (possibly even higher than sm_35)? I did try using
> gcc-12 -fopenmp -foffload=nvptx-none -foffload-options="-misa=sm_35"
> but it still does not work, while in principle it should. Why doesn't it?
It does work, but only for the code that GCC/nvptx generates in that
'gcc-12' invocation, but not for the support libraries that it linkes in,
which are built for sm_30.
> On the other hand, if I use
> gcc-11 -fopenmp -foffload=nvptx-none="-misa=sm_30"
> then I get the same error message I get with gcc-12.
ACK.
> Is there something wrong in how GCC 12 handles nvptx code generation
> options?
Works as expected, per my understanding.
That said, with the upcoming GCC 13 you'll be able to build (!) GCC/nvptx
with a '--with-arch=[...]' 'configure' option, see
<https://gcc.gnu.org/gcc-13/changes.html#nvptx>.
'gcc/doc/install.texi', "nvptx-*-none":
The @option{--with-arch} option may be specified to override the
default value for the @option{-march} option, and to also build
corresponding target libraries.
The default is @option{--with-arch=sm_30}.
For example, if @option{--with-arch=sm_70} is specified,
@option{-march=sm_30} and @option{-march=sm_70} target libraries are
built, and code generation defaults to @option{-march=sm_70}.
However, that doesn't really help you as a user of GCC, as long as the
distributions don't (have an easy way to) build more variants for several
sm_[...]. More work is necessary in GCC/nvptx upstream to make that
feasible.
Grüße
Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Reply to: