Re: libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'
On 4/28/22 15:45, Thomas Schwinge wrote: Hi Tom! On 2022-04-08T09:35:44+0200, Tom de Vries wrote: On 4/8/22 00:27, Thomas Schwinge wrote: On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote: Especially for distributions it is undesirable to need to have proprietary CUDA libraries and headers installed when building GCC. --- libgomp/plugin/configfrag.ac.jj 2017-01-13 12:07:56.0 +0100 +++ libgomp/plugin/configfrag.ac 2017-01-13 17:33:26.608240936 +0100 + PLUGIN_NVPTX_CPPFLAGS='-I$(srcdir)/plugin/cuda' + PLUGIN_NVPTX_LIBS='-ldl' + PLUGIN_NVPTX_DYNAMIC=1 +AC_DEFINE_UNQUOTED([PLUGIN_NVPTX_DYNAMIC], [$PLUGIN_NVPTX_DYNAMIC], + [Define to 1 if the NVIDIA plugin should dlopen libcuda.so.1, 0 if it should be linked against it.]) Actually, the conditionals leading to 'PLUGIN_NVPTX_DYNAMIC=1' here do control two orthogonal aspects; OK to disentangle that with the attached "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? we discussed dropping --with-cuda, so do I understand it correctly that you now propose to drop --with-cuda and --with-cuda-driver-lib but intend to keep --with-cuda-driver-include ? No, I think you're reading too much into this first patch. ;-) The goal with this patch is just to help disentangle two orthogonal concepts (as described in the commit log), and then... Can you explain what user or maintainer scenario is served by this? ... in a next step, we may indeed remove the current user-visible '--with-cuda-driver' etc., but keep the underlying functionality available for the developers. That's to address the point you'd made in the "Proposal to remove '--with-cuda-driver'" thread: that it still "could be useful for debugging / comparison purposes" -- and especially for development purposes, in my opinion: if you develop CUDA API-level changes in the libgomp nvptx plugin, it's likely to be easier to just use the full CUDA toolkit 'cuda.h' and directly link against libcuda (so that you've got all symbols etc. available), and only once you know what exactly you need, update GCC's 'include/cuda/cuda.h' and 'libgomp/plugin/cuda-lib.def'. With that hopefully clarified, OK to push the re-attached "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? Ack, understood, thanks for the detailed explanation. LGTM. Thanks, - Tom Is there a problem with using gcc's cuda.h? No, all good. 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
[PING^2] libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'
Hi! Another ping -- Jakub maybe? This is a simple refactor; no change in behavior. I'll soon post further patches depending on this. Grüße Thomas On 2022-05-05T21:18:47+0200, I wrote: > Hi! > > Ping. > > > Grüße > Thomas > > > On 2022-04-28T15:45:20+0200, I wrote: >> Hi Tom! >> >> On 2022-04-08T09:35:44+0200, Tom de Vries wrote: >>> On 4/8/22 00:27, Thomas Schwinge wrote: >>>> On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote: >>>>> Especially for distributions it is undesirable to need to have proprietary >>>>> CUDA libraries and headers installed when building GCC. >>>> >>>>> --- libgomp/plugin/configfrag.ac.jj 2017-01-13 12:07:56.0 +0100 >>>>> +++ libgomp/plugin/configfrag.ac 2017-01-13 17:33:26.608240936 +0100 >>>> >>>>> + PLUGIN_NVPTX_CPPFLAGS='-I$(srcdir)/plugin/cuda' >>>>> + PLUGIN_NVPTX_LIBS='-ldl' >>>>> + PLUGIN_NVPTX_DYNAMIC=1 >>>> >>>>> +AC_DEFINE_UNQUOTED([PLUGIN_NVPTX_DYNAMIC], [$PLUGIN_NVPTX_DYNAMIC], >>>>> + [Define to 1 if the NVIDIA plugin should dlopen libcuda.so.1, 0 if it >>>>> should be linked against it.]) >>>> >>>> Actually, the conditionals leading to 'PLUGIN_NVPTX_DYNAMIC=1' here do >>>> control two orthogonal aspects; OK to disentangle that with the attached >>>> "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into >>>> 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? >> >>> we discussed dropping --with-cuda, so do I understand it correctly that >>> you now propose to drop --with-cuda and --with-cuda-driver-lib but >>> intend to keep --with-cuda-driver-include ? >> >> No, I think you're reading too much into this first patch. ;-) >> >> The goal with this patch is just to help disentangle two orthogonal >> concepts (as described in the commit log), and then... >> >>> Can you explain what user or maintainer scenario is served by this? >> >> ... in a next step, we may indeed remove the current user-visible >> '--with-cuda-driver' etc., but keep the underlying functionality >> available for the developers. That's to address the point you'd made in >> the "Proposal to remove '--with-cuda-driver'" thread: that it still >> "could be useful for debugging / comparison purposes" -- and especially >> for development purposes, in my opinion: if you develop CUDA API-level >> changes in the libgomp nvptx plugin, it's likely to be easier to just use >> the full CUDA toolkit 'cuda.h' and directly link against libcuda (so that >> you've got all symbols etc. available), and only once you know what >> exactly you need, update GCC's 'include/cuda/cuda.h' and >> 'libgomp/plugin/cuda-lib.def'. >> >> With that hopefully clarified, OK to push the re-attached >> "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into >> 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? >> >>> Is >>> there a problem with using gcc's cuda.h? >> >> No, all good. >> >> >> 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 >From 72e5a2271348fe167713dd3b2afbcd988274bf7c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 7 Apr 2022 23:10:16 +0200 Subject: [PATCH] libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA' Including the GCC-shipped 'include/cuda/cuda.h' vs. system and 'dlopen'ing the CUDA Driver library vs. linking it are separate concerns. libgomp/ * plugin/Makefrag.am: Handle 'PLUGIN_NVPTX_DYNAMIC'. * plugin/configfrag.ac (PLUGIN_NVPTX_DYNAMIC): Change 'AC_DEFINE_UNQUOTED' into 'AM_CONDITIONAL'. * plugin/plugin-nvptx.c: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'. * Makefile.in: Regenerate. * config.h.in: Likewise. * configure: Likewise. --- libgomp/Makefile.in | 26 +++--- libgomp/config.h.in | 4 libgomp/configure | 21 +++-- libgomp/plugin/Makefrag.am| 16 +++- libgomp/plugin/configfrag.ac | 3 +-- libgomp/plugin/plugin-nvptx.c | 4 ++-- 6 files changed, 52 insertions(+), 22 deletions(-) diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in index 1d55f4b6
[PING] libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'
Hi! Ping. Grüße Thomas On 2022-04-28T15:45:20+0200, I wrote: > Hi Tom! > > On 2022-04-08T09:35:44+0200, Tom de Vries wrote: >> On 4/8/22 00:27, Thomas Schwinge wrote: >>> On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote: >>>> Especially for distributions it is undesirable to need to have proprietary >>>> CUDA libraries and headers installed when building GCC. >>> >>>> --- libgomp/plugin/configfrag.ac.jj 2017-01-13 12:07:56.0 +0100 >>>> +++ libgomp/plugin/configfrag.ac 2017-01-13 17:33:26.608240936 +0100 >>> >>>> + PLUGIN_NVPTX_CPPFLAGS='-I$(srcdir)/plugin/cuda' >>>> + PLUGIN_NVPTX_LIBS='-ldl' >>>> + PLUGIN_NVPTX_DYNAMIC=1 >>> >>>> +AC_DEFINE_UNQUOTED([PLUGIN_NVPTX_DYNAMIC], [$PLUGIN_NVPTX_DYNAMIC], >>>> + [Define to 1 if the NVIDIA plugin should dlopen libcuda.so.1, 0 if it >>>> should be linked against it.]) >>> >>> Actually, the conditionals leading to 'PLUGIN_NVPTX_DYNAMIC=1' here do >>> control two orthogonal aspects; OK to disentangle that with the attached >>> "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into >>> 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? > >> we discussed dropping --with-cuda, so do I understand it correctly that >> you now propose to drop --with-cuda and --with-cuda-driver-lib but >> intend to keep --with-cuda-driver-include ? > > No, I think you're reading too much into this first patch. ;-) > > The goal with this patch is just to help disentangle two orthogonal > concepts (as described in the commit log), and then... > >> Can you explain what user or maintainer scenario is served by this? > > ... in a next step, we may indeed remove the current user-visible > '--with-cuda-driver' etc., but keep the underlying functionality > available for the developers. That's to address the point you'd made in > the "Proposal to remove '--with-cuda-driver'" thread: that it still > "could be useful for debugging / comparison purposes" -- and especially > for development purposes, in my opinion: if you develop CUDA API-level > changes in the libgomp nvptx plugin, it's likely to be easier to just use > the full CUDA toolkit 'cuda.h' and directly link against libcuda (so that > you've got all symbols etc. available), and only once you know what > exactly you need, update GCC's 'include/cuda/cuda.h' and > 'libgomp/plugin/cuda-lib.def'. > > With that hopefully clarified, OK to push the re-attached > "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into > 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? > >> Is >> there a problem with using gcc's cuda.h? > > No, all good. > > > 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 >From c455522ac5d8ab41e5d11f8997678e042ff48e87 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 7 Apr 2022 23:10:16 +0200 Subject: [PATCH] libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA' Including the GCC-shipped 'include/cuda/cuda.h' vs. system and 'dlopen'ing the CUDA Driver library vs. linking it are separate concerns. libgomp/ * plugin/Makefrag.am: Handle 'PLUGIN_NVPTX_DYNAMIC'. * plugin/configfrag.ac (PLUGIN_NVPTX_DYNAMIC): Change 'AC_DEFINE_UNQUOTED' into 'AM_CONDITIONAL'. * plugin/plugin-nvptx.c: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'. * Makefile.in: Regenerate. * config.h.in: Likewise. * configure: Likewise. --- libgomp/Makefile.in | 26 +++--- libgomp/config.h.in | 4 libgomp/configure | 21 +++-- libgomp/plugin/Makefrag.am| 16 +++- libgomp/plugin/configfrag.ac | 3 +-- libgomp/plugin/plugin-nvptx.c | 4 ++-- 6 files changed, 52 insertions(+), 22 deletions(-) diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in index 22cb2136a08..d43c584a32d 100644 --- a/libgomp/Makefile.in +++ b/libgomp/Makefile.in @@ -119,8 +119,16 @@ build_triplet = @build@ host_triplet = @host@ target_triplet = @target@ @PLUGIN_NVPTX_TRUE@am__append_1 = libgomp-plugin-nvptx.la -@PLUGIN_GCN_TRUE@am__append_2 = libgomp-plugin-gcn.la -@USE_FORTRAN_TRUE@am__append_3 = openacc.f90 + +# Including the GCC-shipped 'include/cuda/cuda.h' vs. system . +@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_2 = -DPLUGIN_
Re: libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'
Hi Tom! On 2022-04-08T09:35:44+0200, Tom de Vries wrote: > On 4/8/22 00:27, Thomas Schwinge wrote: >> On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote: >>> Especially for distributions it is undesirable to need to have proprietary >>> CUDA libraries and headers installed when building GCC. >> >>> --- libgomp/plugin/configfrag.ac.jj 2017-01-13 12:07:56.0 +0100 >>> +++ libgomp/plugin/configfrag.ac 2017-01-13 17:33:26.608240936 +0100 >> >>> + PLUGIN_NVPTX_CPPFLAGS='-I$(srcdir)/plugin/cuda' >>> + PLUGIN_NVPTX_LIBS='-ldl' >>> + PLUGIN_NVPTX_DYNAMIC=1 >> >>> +AC_DEFINE_UNQUOTED([PLUGIN_NVPTX_DYNAMIC], [$PLUGIN_NVPTX_DYNAMIC], >>> + [Define to 1 if the NVIDIA plugin should dlopen libcuda.so.1, 0 if it >>> should be linked against it.]) >> >> Actually, the conditionals leading to 'PLUGIN_NVPTX_DYNAMIC=1' here do >> control two orthogonal aspects; OK to disentangle that with the attached >> "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into >> 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? > we discussed dropping --with-cuda, so do I understand it correctly that > you now propose to drop --with-cuda and --with-cuda-driver-lib but > intend to keep --with-cuda-driver-include ? No, I think you're reading too much into this first patch. ;-) The goal with this patch is just to help disentangle two orthogonal concepts (as described in the commit log), and then... > Can you explain what user or maintainer scenario is served by this? ... in a next step, we may indeed remove the current user-visible '--with-cuda-driver' etc., but keep the underlying functionality available for the developers. That's to address the point you'd made in the "Proposal to remove '--with-cuda-driver'" thread: that it still "could be useful for debugging / comparison purposes" -- and especially for development purposes, in my opinion: if you develop CUDA API-level changes in the libgomp nvptx plugin, it's likely to be easier to just use the full CUDA toolkit 'cuda.h' and directly link against libcuda (so that you've got all symbols etc. available), and only once you know what exactly you need, update GCC's 'include/cuda/cuda.h' and 'libgomp/plugin/cuda-lib.def'. With that hopefully clarified, OK to push the re-attached "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? > Is > there a problem with using gcc's cuda.h? No, all good. 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 >From c455522ac5d8ab41e5d11f8997678e042ff48e87 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 7 Apr 2022 23:10:16 +0200 Subject: [PATCH] libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA' Including the GCC-shipped 'include/cuda/cuda.h' vs. system and 'dlopen'ing the CUDA Driver library vs. linking it are separate concerns. libgomp/ * plugin/Makefrag.am: Handle 'PLUGIN_NVPTX_DYNAMIC'. * plugin/configfrag.ac (PLUGIN_NVPTX_DYNAMIC): Change 'AC_DEFINE_UNQUOTED' into 'AM_CONDITIONAL'. * plugin/plugin-nvptx.c: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'. * Makefile.in: Regenerate. * config.h.in: Likewise. * configure: Likewise. --- libgomp/Makefile.in | 26 +++--- libgomp/config.h.in | 4 libgomp/configure | 21 +++-- libgomp/plugin/Makefrag.am| 16 +++- libgomp/plugin/configfrag.ac | 3 +-- libgomp/plugin/plugin-nvptx.c | 4 ++-- 6 files changed, 52 insertions(+), 22 deletions(-) diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in index 22cb2136a08..d43c584a32d 100644 --- a/libgomp/Makefile.in +++ b/libgomp/Makefile.in @@ -119,8 +119,16 @@ build_triplet = @build@ host_triplet = @host@ target_triplet = @target@ @PLUGIN_NVPTX_TRUE@am__append_1 = libgomp-plugin-nvptx.la -@PLUGIN_GCN_TRUE@am__append_2 = libgomp-plugin-gcn.la -@USE_FORTRAN_TRUE@am__append_3 = openacc.f90 + +# Including the GCC-shipped 'include/cuda/cuda.h' vs. system . +@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_2 = -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H \ +@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@ -DPLUGIN_NVPTX_LINK_LIBCUDA + +# 'dlopen'ing the CUDA Driver library vs. linking it. +@PLUGIN_NVPTX_DYNAMIC_TRUE@@PLUGIN_NVPTX_TRUE@am__append_3 = $(PLUGIN_NVPTX_LIBS) +@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_4 = $(PLUGIN_NVPTX_LIB
Re: libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA' (was: [PATCH] Allow building GCC with PTX offloading even without CUDA
On 4/8/22 00:27, Thomas Schwinge wrote: Hi! On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote: Especially for distributions it is undesirable to need to have proprietary CUDA libraries and headers installed when building GCC. --- libgomp/plugin/configfrag.ac.jj 2017-01-13 12:07:56.0 +0100 +++ libgomp/plugin/configfrag.ac 2017-01-13 17:33:26.608240936 +0100 + PLUGIN_NVPTX_CPPFLAGS='-I$(srcdir)/plugin/cuda' + PLUGIN_NVPTX_LIBS='-ldl' + PLUGIN_NVPTX_DYNAMIC=1 +AC_DEFINE_UNQUOTED([PLUGIN_NVPTX_DYNAMIC], [$PLUGIN_NVPTX_DYNAMIC], + [Define to 1 if the NVIDIA plugin should dlopen libcuda.so.1, 0 if it should be linked against it.]) Actually, the conditionals leading to 'PLUGIN_NVPTX_DYNAMIC=1' here do control two orthogonal aspects; OK to disentangle that with the attached "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? Hi Thomas, we discussed dropping --with-cuda, so do I understand it correctly that you now propose to drop --with-cuda and --with-cuda-driver-lib but intend to keep --with-cuda-driver-include ? Can you explain what user or maintainer scenario is served by this? Is there a problem with using gcc's cuda.h? Thanks, - Tom 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
libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA' (was: [PATCH] Allow building GCC with PTX offloading even without CUDA bein
Hi! On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote: > Especially for distributions it is undesirable to need to have proprietary > CUDA libraries and headers installed when building GCC. > --- libgomp/plugin/configfrag.ac.jj 2017-01-13 12:07:56.0 +0100 > +++ libgomp/plugin/configfrag.ac 2017-01-13 17:33:26.608240936 +0100 > + PLUGIN_NVPTX_CPPFLAGS='-I$(srcdir)/plugin/cuda' > + PLUGIN_NVPTX_LIBS='-ldl' > + PLUGIN_NVPTX_DYNAMIC=1 > +AC_DEFINE_UNQUOTED([PLUGIN_NVPTX_DYNAMIC], [$PLUGIN_NVPTX_DYNAMIC], > + [Define to 1 if the NVIDIA plugin should dlopen libcuda.so.1, 0 if it > should be linked against it.]) Actually, the conditionals leading to 'PLUGIN_NVPTX_DYNAMIC=1' here do control two orthogonal aspects; OK to disentangle that with the attached "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"? 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 >From c455522ac5d8ab41e5d11f8997678e042ff48e87 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 7 Apr 2022 23:10:16 +0200 Subject: [PATCH] libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA' Including the GCC-shipped 'include/cuda/cuda.h' vs. system and 'dlopen'ing the CUDA Driver library vs. linking it are separate concerns. libgomp/ * plugin/Makefrag.am: Handle 'PLUGIN_NVPTX_DYNAMIC'. * plugin/configfrag.ac (PLUGIN_NVPTX_DYNAMIC): Change 'AC_DEFINE_UNQUOTED' into 'AM_CONDITIONAL'. * plugin/plugin-nvptx.c: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'. * Makefile.in: Regenerate. * config.h.in: Likewise. * configure: Likewise. --- libgomp/Makefile.in | 26 +++--- libgomp/config.h.in | 4 libgomp/configure | 21 +++-- libgomp/plugin/Makefrag.am| 16 +++- libgomp/plugin/configfrag.ac | 3 +-- libgomp/plugin/plugin-nvptx.c | 4 ++-- 6 files changed, 52 insertions(+), 22 deletions(-) diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in index 22cb2136a08..d43c584a32d 100644 --- a/libgomp/Makefile.in +++ b/libgomp/Makefile.in @@ -119,8 +119,16 @@ build_triplet = @build@ host_triplet = @host@ target_triplet = @target@ @PLUGIN_NVPTX_TRUE@am__append_1 = libgomp-plugin-nvptx.la -@PLUGIN_GCN_TRUE@am__append_2 = libgomp-plugin-gcn.la -@USE_FORTRAN_TRUE@am__append_3 = openacc.f90 + +# Including the GCC-shipped 'include/cuda/cuda.h' vs. system . +@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_2 = -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H \ +@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@ -DPLUGIN_NVPTX_LINK_LIBCUDA + +# 'dlopen'ing the CUDA Driver library vs. linking it. +@PLUGIN_NVPTX_DYNAMIC_TRUE@@PLUGIN_NVPTX_TRUE@am__append_3 = $(PLUGIN_NVPTX_LIBS) +@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_4 = $(PLUGIN_NVPTX_LIBS) +@PLUGIN_GCN_TRUE@am__append_5 = libgomp-plugin-gcn.la +@USE_FORTRAN_TRUE@am__append_6 = openacc.f90 subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ @@ -197,8 +205,10 @@ libgomp_plugin_gcn_la_LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC \ $(libgomp_plugin_gcn_la_LDFLAGS) $(LDFLAGS) -o $@ @PLUGIN_GCN_TRUE@am_libgomp_plugin_gcn_la_rpath = -rpath \ @PLUGIN_GCN_TRUE@ $(toolexeclibdir) +@PLUGIN_NVPTX_DYNAMIC_TRUE@@PLUGIN_NVPTX_TRUE@am__DEPENDENCIES_2 = $(am__DEPENDENCIES_1) +@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__DEPENDENCIES_3 = $(am__DEPENDENCIES_1) @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_DEPENDENCIES = libgomp.la \ -@PLUGIN_NVPTX_TRUE@ $(am__DEPENDENCIES_1) +@PLUGIN_NVPTX_TRUE@ $(am__DEPENDENCIES_2) $(am__DEPENDENCIES_3) @PLUGIN_NVPTX_TRUE@am_libgomp_plugin_nvptx_la_OBJECTS = \ @PLUGIN_NVPTX_TRUE@ libgomp_plugin_nvptx_la-plugin-nvptx.lo libgomp_plugin_nvptx_la_OBJECTS = \ @@ -533,7 +543,7 @@ libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include AM_CPPFLAGS = $(addprefix -I, $(search_path)) AM_CFLAGS = $(XCFLAGS) AM_LDFLAGS = $(XLDFLAGS) $(SECTION_LDFLAGS) $(OPT_LDFLAGS) -toolexeclib_LTLIBRARIES = libgomp.la $(am__append_1) $(am__append_2) +toolexeclib_LTLIBRARIES = libgomp.la $(am__append_1) $(am__append_5) nodist_toolexeclib_HEADERS = libgomp.spec # -Wc is only a libtool option. @@ -559,16 +569,18 @@ libgomp_la_SOURCES = alloc.c atomic.c barrier.c critical.c env.c \ oacc-parallel.c oacc-host.c oacc-init.c oacc-mem.c \ oacc-async.c oacc-plugin.c oacc-cuda.c priority_queue.c \ affinity-fmt.c teams.c allocator.c oacc-profiling.c \ - oacc-target.c $(am__append_3) + oacc-target.c $(a