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