Estoy trabajando en una aplicación que usa tanto GLib como CUDA en C. Parece que hay un conflicto al importar tanto glib.h como cuda_runtime.h para un archivo .cu.
Hace 7 meses GLib hizo un cambio para evitar un conflicto con la macro de pixman. Agregaron __ antes y después del token noinline en gmacros.h: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2059
Eso debería haber funcionado, dado que gcc afirma:
Opcionalmente, puede especificar nombres de atributos con
__antes y después del nombre. Esto le permite usarlos en archivos de encabezado sin preocuparse por una posible macro del mismo nombre. Por ejemplo, puede usar el nombre de atributo__noreturn__en lugar de noreturn.
Sin embargo, CUDA usa __ en sus macros, y __noinline__ es una de ellas. Reconocen el posible conflicto y agregan algunas verificaciones del compilador para asegurarse de que no entre en conflicto en los archivos c regulares, pero parece que en los archivos .cu todavía se aplica:
#if defined(__CUDACC__) || defined(__CUDA_ARCH__) || defined(__CUDA_LIBDEVICE__) /* gcc allows users to define attributes with underscores, eg, __attribute__((__noinline__)). Consider a non-CUDA source file (eg .cpp) that has the above attribute specification, and includes this header file. In that case, defining __noinline__ as below would cause a gcc compilation error. Hence, only define __noinline__ when the code is being processed by a CUDA compiler component. */ #define __noinline__ \ __attribute__((noinline))Soy bastante nuevo en el desarrollo de CUDA, y este es claramente un posible problema del que ellos y gcc son conscientes, entonces, ¿me falta un indicador del compilador o algo así? ¿O es este un conflicto genuino que GLib tendría que resolver?
Entorno: glib 2.70.2, cuda 10.2.89, gcc 9.4.0
Editar: he planteado un problema de GLib aquí
Puede que no sea culpa de GLib, pero dada la diferencia de opinión en las respuestas hasta el momento, dejaré que los desarrolladores decidan si plantearlo con NVidia o no.
He usado la solución alternativa de nemequ por ahora y se compila sin quejas.
La documentación de GCC establece:
Opcionalmente, puede especificar nombres de atributos con
__antes y después del nombre. Esto le permite usarlos en archivos de encabezado sin preocuparse por una posible macro del mismo nombre. Por ejemplo, puede usar el nombre de atributo__noreturn__en lugar denoreturn.
Ahora, eso solo suponiendo que evite los nombres con doble subrayado que usan el compilador y la biblioteca; y pueden usar tales nombres. Entonces, si está usando NVCC, NVIDIA podría declarar "usamos noinline y no puede usarlo".
... y de hecho, este es básicamente el caso: la macro está protegida de la siguiente manera:
#if defined(__CUDACC__) || defined(__CUDA_ARCH__) || defined(__CUDA_LIBDEVICE__) #define __noinline__ __attribute__((noinline)) #endif /* __CUDACC__ || __CUDA_ARCH__ || __CUDA_LIBDEVICE__ */__CUDA_ARCH__ : solo se define para el código del lado del dispositivo, donde NVCC es el compilador (ignorando aquí la compatibilidad con Clang CUDA).__CUDA_LIBDEVICE__ : no sé dónde se usa esto, pero ciertamente no lo está construyendo, por lo que no le importa eso.__CUDACC__ definido cuando NVCC está compilando el código.Entonces, en el código normal del lado del host, incluir este encabezado no entrará en conflicto con las definiciones de Glib.
En pocas palabras: NVIDIA está (básicamente) haciendo lo correcto aquí y no debería ser un problema real.
GLib está claramente a la derecha aquí. Verifican __GNUC__ (que es lo que usan los compiladores para indicar la compatibilidad con GNU C, también conocido como las extensiones GNU para C y C++ ) antes de usar __noinline__ exactamente como la documentación de GNU indica que debe usarse: __attribute__((__noinline__)) .
GNU C claramente también está haciendo lo correcto aquí. Los compiladores que ofrecen las extensiones GNU (incluidos GCC, clang y muchos otros) son, bueno, compiladores, por lo que se les permite usar los identificadores prefijados de doble guión bajo. De hecho, esa es toda la idea detrás de ellos; es una forma de que los compiladores proporcionen extensiones sin tener que preocuparse por los conflictos con el código de usuario (que no puede declarar identificadores con prefijo de doble guión bajo).
A primera vista, NVidia parece estar haciendo lo correcto también, pero no es así. Suponiendo que los considere el compilador (lo que creo que es correcto), se les permite definir macros con prefijo de doble guión bajo como __noinline__ . Sin embargo, el problema es que NVidia también define __GNUC__ (intencionalmente, ya que quieren anunciar la compatibilidad con las extensiones de GNU), luego procede a definir __noinline__ de manera incompatible, rompiendo una API proporcionada por GNU C.
En pocas palabras: NVidia está equivocada aquí .
En cuanto a qué hacer al respecto, bueno, esa es una pregunta menos interesante, pero hay algunas opciones. Podría (y debería) presentar un problema con NVidia para arreglar su compilador. En mi experiencia, son bastante buenos para responder rápidamente, pero es poco probable que solucionen el problema en un tiempo razonable.
También puede enviar un parche a GLib para solucionar el problema haciendo algo como
#if defined(__CUDACC__) __attribute__((noinline)) #elif defined(__GNUC__) __attribute__((__noinline__)) #else ... #endifSi tiene el control del código que incluye glib, otra opción sería hacer algo como
#undef __noinline__ #include glib_or_file_which_includes_glib #define __noinline__ __attribute__((noinline))Mi consejo sería hacer los tres, pero especialmente el primero (archivar un problema con NVidia) y encontrar una manera de solucionarlo en su código hasta que NVidia solucione el problema.