CUDA 9 failed to support the latest Visual Studio 2017 version 15.5
Once I upgraded by Visual Studio 2017 to version 15.5 (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) CUDA stops working, the minimal code below can reproduce it ``` nvcc mycu.cu mycu.cu 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?
Once I upgraded by Visual Studio 2017 to version 15.5 (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) CUDA stops working, the minimal code below can reproduce it

```
nvcc mycu.cu
mycu.cu
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?

#1
Posted 12/07/2017 04:33 PM   
This version of MSVS is not supported by CUDA (yet), use a supported version instead.
This version of MSVS is not supported by CUDA (yet), use a supported version instead.

#2
Posted 12/07/2017 08:05 PM   
[quote=""]This version of MSVS is not supported by CUDA (yet), use a supported version instead.[/quote] WOW, Captain Obvious!!! Rewards for the best answer goes to [b]njuffa[/b]!!! [i]This comment was nuked by txbob at 12/09/17 3:57 PM GMT[/i]

This Comment Has Been Nuked

#3
Posted 12/09/2017 03:00 PM   
Read the solution below
Read the solution below

#4
Posted 12/09/2017 04:26 PM   
[quote=""]Once I upgraded by Visual Studio 2017 to version 15.5 (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) CUDA stops working, the minimal code below can reproduce it ``` nvcc mycu.cu mycu.cu 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?[/quote] Hi! 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...:-)
said:Once I upgraded by Visual Studio 2017 to version 15.5 (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) CUDA stops working, the minimal code below can reproduce it

```
nvcc mycu.cu
mycu.cu
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?


Hi!

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...:-)

#5
Posted 12/09/2017 04:50 PM   
@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 [i]responsible[/i] 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 [i]validated[/i], 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 [i]seem[/i] 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 [i]free of charge[/i]? 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]
@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]

#6
Posted 12/09/2017 06:47 PM   
@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?
@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?

#7
Posted 12/11/2017 01:27 AM   
You should be able to get things to work with VS2015, either directly, or in the VS2015 toolchain from within VS2017. [url]https://devtalk.nvidia.com/default/topic/1027209/cuda-setup-and-installation/cuda-9-0-does-not-work-with-the-latest-vs-2017-update/[/url] 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.
You should be able to get things to work with VS2015, either directly, or in the VS2015 toolchain from within VS2017.

https://devtalk.nvidia.com/default/topic/1027209/cuda-setup-and-installation/cuda-9-0-does-not-work-with-the-latest-vs-2017-update/

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.

#8
Posted 12/11/2017 01:43 AM   
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, [i]independent[/i] of CUDA: Only upgrade working software components if you absolutely have to. It is bad enough that some vendors [i]force[/i] 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.
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.

#9
Posted 12/11/2017 01:45 AM   
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.
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.

#10
Posted 12/11/2017 01:56 AM   
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 [i]workaround[/i] for Microsoft's [i]failure[/i] 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: http://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html CUDA Compilers. Microsoft Visual Studio 2017 (starting with Update 1) support is beta. Only the RTM version (vc15.0) is fully supported.
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:

http://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html
CUDA Compilers. Microsoft Visual Studio 2017 (starting with Update 1) support is beta. Only the RTM version (vc15.0) is fully supported.

#11
Posted 12/11/2017 02:07 AM   
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 [u]Nvidia and Microsoft do not team up in any way to better support their developers[/u].
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.

#12
Posted 12/11/2017 09:27 AM   
"I read the news today, oh boy..." [url]https://developer.nvidia.com/cuda-toolkit/whatsnew[/url]
"I read the news today, oh boy..."

https://developer.nvidia.com/cuda-toolkit/whatsnew

#13
Posted 12/11/2017 10:54 AM   
There is an older version of VS2017 install (15.4.5) at https://www.visualstudio.com/en-us/productinfo/installing-an-earlier-release-of-vs2017. 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.
There is an older version of VS2017 install (15.4.5) at https://www.visualstudio.com/en-us/productinfo/installing-an-earlier-release-of-vs2017. 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.

#14
Posted 12/11/2017 02:24 PM   
@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.
@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.

#15
Posted 12/11/2017 05:13 PM   
Scroll To Top

Add Reply