Opened 12 years ago

Closed 12 years ago

#4431 closed Bugs (fixed)

stdint.h not available in CUDA nvcc + visual studio

Reported by: Sergey Mitsyn <svm@…> Owned by: Joel Falcou
Milestone: Boost 1.44.0 Component: concept_check
Version: Boost 1.43.0 Severity: Problem
Keywords: CUDA nvcc stdint.h Cc: joel.falcou@…

Description

The "boost/config/compiler/nvcc.hpp" contains "#define BOOST_HAS_STDINT_H", but it looks like stdint.h availability for CUDA nvcc is platform-dependent; it is unavailable if nvcc is used with visual studio (in my case it is vc9). Thus this fails to compile with nvcc:

#include "boost/cstdint.hpp"

Also, AFAIK, nvcc passes all code that is not CUDA-related to the native compiler that is g++ on linux and cl on windows. So, it may sound silly, but commenting out anything and including "boost/config/compiler/visualc.hpp" in nvcc.hpp helps with several other compile errors, of course for msvc only.

Change History (13)

comment:1 by John Maddock, 12 years ago

Cc: joel.falcou@… added

Sergey,

I'm not able to run the nvcc compiler here, so I'm totally dependent upon others supplying the correct patches. The current nvcc config is the one supplied by Joel Falcoe here: https://svn.boost.org/trac/boost/ticket/3919. I'm adding him as a CC to this ticket - perhaps you can work out a better configuration option between you - I'm fairly sure he enabled BOOST_HAS_STDINT_H for a reason?

Cheers, John Maddock.

comment:2 by Joel Falcou, 12 years ago

I can test the following ticket tomorrow no problem.

I think the fact is that the original patch was generated using a unix based nvcc with the config script. Now I think Sergey is right and the nvcc.hpp file should be rewritten by just adding the NVCC macro AND forward to the current underlying compiler

I will give a shot to that

comment:3 by sprevrha, 12 years ago

I followed the advice and commented out everything and included the msvc config. Now I am getting

\boost\include\boost-1_43\boost/test/utils/basic_cstring/basic_cstring.hpp(60): error: enumeration value is out of "int" range

when I do a empty boost test in a .cu file.

comment:4 by anonymous, 12 years ago

If you look at the line of code in question, you'll see a possible workaround there already.

If you get something that works, please report a separate bug to Boost.Test.

In the mean time, what config are you using - if there's a patch available I can apply to Trunk.

Thanks, John.

comment:5 by sven.prevrhal@…, 12 years ago

John - At this point, I am using MSVC 9.0 on Win 7 64-bit, compiling for 64-bit with CUDA 3.2 using nvcc with the -m64 switch.

Getting this to work has failed, at least for me. If I switch in basic_cstring

#if !BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600))
    enum npos_type { npos = static_cast<size_type>(-1) };
#else
    // IBM/VisualAge version 6 is not able to handle enums larger than 4 bytes.
    // But size_type is 8 bytes in 64bit mode.
    static const size_type npos = -1 ;
#endif

to the #else clause, the cuda compiler dies:

1>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v3.2\\bin\nvcc.exe"   -m64 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin"  -D_DEBUG -D_WIN32   -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v3.2\\include" -I"./" -I"../../common/inc" -I"../../../shared/inc" -I""D:\projects\quattro\src\recon\src\\..\include\TEST_librecon"" -I""D:\projects\quattro\src\recon\src\\..\include"" -I""c:\packages\boost\include\boost-1_43"" -I""c:\packages\boost\include"" -Xcompiler "/EHsc /W3 /nologo /O2 /Zi   /MDd  " -maxrregcount=32  -gencode=arch=compute_10,code=\"sm_10,compute_10\" -gencode=arch=compute_20,code=\"sm_20,compute_20\"  --compile -o "x64\Debug\sorting.cu.obj" "d:\projects\quattro\src\recon\src\TEST_librecon\sorting.cu" 
1>sorting.cu
1>c:\packages\boost\include\boost-1_43\boost/test/utils/basic_cstring/basic_cstring.hpp(59): warning: integer conversion resulted in a change of sign
1>nvcc error   : 'cudafe' died with status 0xC0000005 (ACCESS_VIOLATION)
1>Compiling...

I am not experienced enough to work up a patch for this. I can't even tell if that's a bug with nvcc (since people report boost to work with gcc, but have they tested boost unit testing?) or whether the boost macros are just wrong for the nvcc on MSVC case.

comment:6 by anonymous, 12 years ago

That looks like an nvcc bug given that the compiler is segfaulting.

Sorry, I don't really know what to suggest here, how is the rest of Boost doing with your current nvcc config?

John.

comment:7 by Joel Falcou, 12 years ago

Owner: changed from John Maddock to Joel Falcou

comment:8 by sven.prevrhal@…, 12 years ago

Component: configconcept_check

I found a compliant stdint.h for my MSVC 9.0 compiler at http://msinttypes.googlecode.com/.svn/trunk/stdint.h , put this in the path, still didn't work, nvcc complaining about enumeration value is out of "int" range in the boost generic traits header. What worked was to undefine BOOST_NO_INCLASS_MEMBER_INITIALIZATION in config/compiler/nvcc.hpp (read some similar issue with this resolution in a different ticket). As a patch, I am proposing to wrap #define BOOST_NO_INCLASS_MEMBER_INITIALIZATION -

#ifndef _MSC_VER #define BOOST_NO_INCLASS_MEMBER_INITIALIZATION #endif

if it's indeed only a Windows problem. Sven

comment:9 by anonymous, 12 years ago

I'm not sure that's the correct fix - as I understand it nvcc supports inline initializarion perfectly well - the bug is elsewhere (assigning a too large value to an enum). What/where was the actual error?

Thanks, John.

comment:10 by sven.prevrhal@…, 12 years ago

You're right...The actual error without, but with a stdint.h in place is/was

c:\packages\boost\include\boost-1_45\boost/integer_traits.hpp(56): error: enumeration value is out of "int" range 1> detected during instantiation of class "boost::detail::integer_traits_base<T, min_val, max_val> [with T=boost::long_long_type, min_val=-9223372036854775808LL, max_val=9223372036854775807LL]"

and occured, as far as I can tell during #include <boost/random.hpp> in a nvcc-compiled cuda file. I use nvcc flags -m64 -ccbin -use_fast_math -Xcompiler "/EHsc /W3 /nologo /O2 /Zi /MD " -maxrregcount=32 -gencode=arch=compute_13,code=\"sm_13,compute_13\" -gencode=arch=compute_20,code=\"sm_20,compute_20\" --compile -o "x64\ReleaseLib\projection.cu.obj" "d:\projects\quattro\src\recon\src\CUDAProjector\projection.cu"

comment:11 by anonymous, 12 years ago

Hold on though, if I am not mistaken #define'ing BOOST_NO_INCLASS_MEMBER_INITIALIZATION _dis_allows initialization inlining, so therefore having the #define in nvcc.hpp is wrong, and putting it inside a #ifdef _MSC_VER prevents it for nvcc on Windows, so in fact allows inline initialization.

comment:12 by anonymous, 12 years ago

Hold on though, if I am not mistaken #define'ing BOOST_NO_INCLASS_MEMBER_INITIALIZATION _dis_allows initialization inlining, so therefore having the #define in nvcc.hpp is wrong, and putting it inside a #ifdef _MSC_VER prevents it for nvcc on Windows, so in fact allows inline initialization.

It would have to be inside an #ifndef _MSC_VER block? But I see this comment in the header file:

NVCC Basically behaves like some flavor of MSVC6 + some specific quirks

Which suggests inline initialization is *not* supported?

Confused yours, John.

comment:13 by John Maddock, 12 years ago

Resolution: fixed
Status: newclosed

(In [68566]) Change nvcc config to use underlying compiler config. Fixes #4431.

Note: See TracTickets for help on using tickets.