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.mu...@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 via email to