CUDA 9 failed to support the latest Visual Studio 2017 version 15.5

Once I upgraded by Visual Studio 2017 to version 15.5 (Visual Studio 2017 15.9 Release Notes | Microsoft Docs) CUDA stops working, the minimal code below can reproduce it

c:\program files\nvidia gpu computing toolkit\cuda\v9.0\include\crt/host_config.h(133): fatal error C1189: #error: -- unsupported Microsoft Visual Studio version! Only the versions 2012, 2013, 2015 and 2017 are supported! 

When I investigate the issue, I noticed that in c:\program files\nvidia gpu computing toolkit\cuda\v9.0\include\crt/host_config.h has this line

#if _MSC_VER < 1600 || _MSC_VER > 1911

but VS 2017 15.5 has _MSC_VER set to 1912.

How can I work around this problem?

This version of MSVS is not supported by CUDA (yet), use a supported version instead.

Read the solution below


Try - Project Properties / Configuration Proprerties / General / Platform Toolset (set - Visual Studio 2015 (v140))

And “host_config.h” does not need changes.

It works fine for me.

And lets wait for CUDA Toolkit Updates patiently…:-)

@xnode: To avoid misunderstandings, please note that my presence in these forums is not part of any kind of professional activity. I am just a hobbyist CUDA user at this point.

My statement addressed the poster’s issue directly, and you added useful detail. Personally, I use a very old version of MSVS (2010) so I am not familiar with the toolset selection menu item you mention, but I assumed (maybe incorrectly) that MSVS 2017 users know how to operate the GUI IDE to select a tool chain version supported by CUDA.

[Later:] For those who object to my advice “Use a supported CUDA” version, let me explain why I believe that this is the only responsible advice.

Early in the genesis of CUDA (2005-2006) a decision was made that CUDA should integrate into the most popular host tool chains as seamlessly as possible to create as little of a hurdle to adoption as possible. This tight integration creates dependencies of host header files for example. This was not deemed a particularly risky approach at the time, because in the early days of CUDA, when the ecosystem was tiny, new CUDA releases were shipped every four to five months on average, while host tool chains had new releases every one to two years.

Tight integration with the host tool chain means that adjustments must be made to CUDA to adapt to new versions of the host tool chain. The integration must then be validated, using a large-ish body of CUDA code. In case of problems with the CUDA tool chain, NVIDIA offers support only when CUDA is used with such a validated, a.k.a. supported, host tool chain. Version checks in header files, such as the one identified by the OP enforce the use of a supported tool chain.

In the cited version check from CUDA 9, it is clear that only MSC version up to and including 1911 are supported, while the latest MSVS update identifies as version 1912. The discussions of such issues in these forums tend to follow a predictable trajectory: Someone will suggest a “workaround” that consists in modifying or eliminating the version check. That then seems to work for trivial code, but the next thing that typically happens is that the compilation for more complex code results in “strange error messages” (a consequence of missing adjustments). Some really clever people will then propose various hacks to CUDA header files, and this then seems to eliminate the compilation bugs.

The problem with that: this is hackery, not a reliable fix. Things may seem to work but may silently compile into an incorrect binary. There is no validation of the changes because CUDA programmers don’t normally have the large body of code at their disposal that NVIDIA uses for validation. It also effectively creates a one-off branch of the CUDA tool chain that makes support impossible should other problems occur later on. I highly doubt that NVIDIA accepts bug reports that state: “I am using CUDA version N, except for the following modified header files you will find attached to the bug report.” As I said, that is a guess, but it is an educated one.

The scheme of CUDA requiring specific host tool chains has lead to an increasing number of version mismatch issues as in this thread (on all OS platforms) as the cadence of CUDA releases has slowed down, while the cadence of host tool chain releases has increased rapidly.

[speculation] Why not have rapid-fire CUDA releases to deal with the issue? Plausible approach, but would likely drive up development costs. How would NVIDIA recoup that cost when the entire CUDA ecosystem is provided free of charge? Last time I purchased the equivalent ecosystem for my CPU (which also has a MSVS integration challenge), it set me back around $2K, so I have a pretty good idea how that vendor recoups (at least a part of) their cost.

Before someone points out that additional cost could be recouped through hardware sales, keep in mind that the bulk of GPU sales is still GeForce, and that in the consumer market the additional money NVIDIA can charge for providing CUDA is approximately $0. The price in that market is pretty much determined by how GeForce competes against the competition in popular games (I think any secondary pricing effects from crypto currency mining will be temporary).[/speculation]

@njuffa Unfortunately there isn’t an easy way to downgrade back to 15.4, and if I reinstall visual studio from scratch there is no option to install to 15.4, so I am stuck on 15.5 at the moment. Beats me! I also think that even though NVIDIA release CUDA more frequently might drive up development cost, but the time saved for downstream vendors will be immense. I am pretty sure I am not the first guy that ran into this problem. The unfortunate thing is there is no real competition (AMD OpenCLs are too far behind) so we have no options to easily switch and NVIDIA can just take their time to do whatever they want. We are at their mercy and is forced to figure out these hacks to make things work.

@xnode Unfortunately in my actual project I am using cmake so I have be able to handle this before the solution file is generated. Otherwise I am getting a No CMAKE_CUDA_COMPILER could be found. error. Do you have any ideas?

You should be able to get things to work with VS2015, either directly, or in the VS2015 toolchain from within VS2017.

[url]CUDA 9.0 does not work with the latest VS 2017 update - CUDA Setup and Installation - NVIDIA Developer Forums

VS2015 is a supported platform for CUDA 9. You can still get VS2015 as a separate, free (Community Edition) download if you look for it. Or just install and select the toolchain within VS2017 as indicated above.

Note that CMAKE is not a tool chain provided by NVIDIA, or supported by NVIDIA.

It is correct that there are (were) only certain versions of VS2017 that were supported by CUDA 9, and if you upgrade beyond that range, you are then in unsupported territory for VS2017. And AFAIK Microsoft makes it difficult or impossible to backtrack such an upgrade. Microsoft also, AFAIK, does not provide any way to install a previous version of VS2017.

My impression over the years has been that the number of CUDA programmers getting caught in OS vendor upgrade games is actually small. It is weird that Microsoft does not give you a way back to your previous version. There ought to be a way. Have you double-checked with them?

My advice has been the same for many years, independent of CUDA: Only upgrade working software components if you absolutely have to. It is bad enough that some vendors force their users into upgrades, but in recent years I observe a troubling phenomenon: people appear to chase the latest software versions, for no good reason (and that goes all the way from the BIOS, to drivers, to application software). Maybe it’s the same affliction that causes people to line up at the Apple store because they have to have the latest iPhone …

One of the main things software upgrades do is exchange old, known issues for new, unknown issues.

I can imagine downgrading to VS2015 will work but it really makes no sense. I had to reinstall all my dependent open source libraries because of this. Some of them takes multiple hours to compile (OpenCV, pcl aws-sdk-cpp etc). The thing is I was at VS 2015 and the moment CUDA 9 is announced I went through a painful process to update everything to VS 2017, and now you are telling me do go through the pain again to roll back everything to VS 2015 because NVIDIA refused to roll out the fix in a timely manner.

Understand getting cmake to work is not NVIDIA’s responsibility, I am merely hoping some other developers who ran into the same problem that is also using cmake (I am pretty sure there is a lot) might give me a pointer on how to make it work, and further save time for future developers that will stumble upon this post when they run into the same problem.

Though I agree Microsoft making it hard to rollback is questionable, but I think the main problem here is NVIDIA need to release a fix ASAP.

Downgrading Microsoft compiler versions used to be trivial. MSVS shipped as a base version, and you could install service packs on top of that. If there was a problem with the latest service pack, simply uninstall it, done. I have no idea what they are doing now, but it seems to screw their customers. The suggestions to downgrade to MSVS 2015 appear to be a workaround for Microsoft’s failure to provide a downgrade to your earlier version of MSVS 2017.

IMHO, it makes no sense to hold NVIDIA responsible for fixing a problem that was caused by a third party. From the CUDA 9 relase notes:

CUDA Compilers. Microsoft Visual Studio 2017 (starting with Update 1) support is beta. Only the RTM version (vc15.0) is fully supported.

History repeating. The exact same thing / issues were there with CUDA 8 and VS 2015. This disappointing experience taught me to be very patient and to stay away from CUDA 9 and VS 2017 until people can actually use it (com’on - there are dependencies, so it is not an option to use VS 2017 without any updates). It is so sad that no one learned from it, or to put it another way, that Nvidia and Microsoft do not team up in any way to better support their developers.

“I read the news today, oh boy…”


There is an older version of VS2017 install (15.4.5) at Visual Studio 2017 Release History | Microsoft Docs. I haven’t checked it fully out, but it looks like it should work after completely uninstalling 15.5.1. You should grab the download before MS removes it. It looks like CUDA 9 and Nsight 5 will need to be reinstalled once you reinstall VS2017. Who knows if CUDA 9.1 will work with the latest VS 2017.

Unfortunately, I’m in a pickle because CUDA 9 supports C++ ellipsis syntax, which I need to support a port of a NET BCL. CUDA 9.0.176/VS 2017 15.4.x was working fine for me until this upgrade.

@Ken Domino that is a great find. It actually works for me. I still need VS2017 15.5 at some point because it actually solved a pcl compilation problem.

Also great news on CUDA 9.1. Glad that NVIDIA is hearing our voice. Can’t wait to see it release.

thanks, i cna work.
my step log:[url][/url]


CUDA Toolkit 9.1.85 is available now!


Still not working with Visual Studio 2017 15.5.1 / Platform Toolset Visual Studio 2017 (v141)

“…\NVIDIA GPU Computing Toolkit\CUDA\v9.1\include\crt\host_config.h”:

#if _MSC_VER < 1600 || _MSC_VER > 1911

Changes to 1912 do not help.

Tips, Thoughts, Solutions???

Nooo CUDA 9.1 still don’t work with VS 2017 15.5. Looks like we are still stuck on VS 2017 15.4.

Where can I download / buy VS 2017 15.4 ??

This was mentioned earlier in the thread:

[url]CUDA 9 failed to support the latest Visual Studio 2017 version 15.5 - CUDA Setup and Installation - NVIDIA Developer Forums

Hello, I am a bit lost.
I just installed the CUDA Toolkit (9.1 my first, I am here to learn) and installed VS 2017 (I normally use Eclipse for all my coding).
So I am a total noob with CUUDA AND with Microsoft IDEs… been reading the few posts about this version mismatch, tried to get an older version of VStudio (the link in this thread is not working anymore) , installed different toolkits ( the VS 2015 v140) and retargeted the project, but no joy :(

I still get this

C:\Program Files (x86)\Microsoft Visual Studio017\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Platform.targets(55,5): error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using the v100 build tools, please install Visual Studio 2010 build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution".

At this point, what’s my best option? Is there a version of CUDA that can work with Eclipse? (and some instructions on how to set it up) or vith some version of any IDE I can still download?