According to the gFortran docs in order to enable OpenACC support it is necessary to use the -fopenacc switch. However, this does not seem to work.
gfortran: error: unrecognized command line option ‘-fopenacc’
gFortran version is GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28).
What is the correct way to compile Fortran code with OpenACC support?
Your version is WAY too old. The currently supported versions of GCC are 7, 8 and 9.
The version specific manuals are available at https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gfortran/OpenACC.html#OpenACC Change the version number in the address to see other versions.
The option appears to be added in version 5 but the support in more recent versions is likely to be much better.
Related
How to find which gcc version the installed boost library is using ? So I can find which version of C++, my HPX library is using. HPX library depend on boost library hugely. I actually forgot how I (using which version of gcc) built boost library a year ago.
Thanks
If it's layout verioned when you built boost, the lib name must like: libboost_wave-gcc48-mt-s-1_65.a, so gcc48 (gcc 4.8.x) is your version.
More accurate : Run following command:
strings libboost_wave-gcc48-mt-s-1_65.a | egrep -ie "GCC.*([0-9]\.[0-9]\.[0-9])"
You'll get the exact gcc version 4.8.5 from the output:
GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-11)
I need to install cuda 5.0 in centos7 x64. But, I have a problem with GCC, as the current version installed is (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11).
What is the supported version of GCC for Cuda 5.0 and how to install this older GCC version with my actual compiler ((GCC) 4.8.5).
Thanks in advance
#talonmies has provided a list of maximum GCC version supported by different versions of CUDA. Specifically: CUDA 5.0 supports GCC up to 4.6 - and that's what you should install.
There's an answer here on SO which explains how to get GCC 4.6(.3) installed by building from sources. Essentially you need to build some libraries with any C compiler before you can build GCC itself.
Good luck.
The question is about a specific combination of versions but is relevant more generally.
I've just dist-upgraded from Kubuntu 12.04 to 14.04. Now, when I want to compile CUDA code (with CUDA 6.5), I get:
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
I installed gcc-4.8 (and 4.7), and tried to use the symlinks-in-/usr/local/cuda/bin solution suggested here:
CUDA incompatible with my gcc version
but this doesn't work. What should I do?
This solution is relevant to multiple combinations of CUDA and GCC versions.
You can tell CUDA's nvcc to use a specific version of gcc. So, suppose you want gcc 4.7 for use with CUDA 6. You run:
sudo apt-get install gcc-4.7 g++-4.7
and then add the following switch to your nvcc command-line:
nvcc --compiler-bindir /usr/bin/gcc-4.7 # rest of the command line here
If you're building with CMake, add an appropriate setting before looking for CUDA to your CMakeLists.txt, e.g.:
set(CUDA_HOST_COMPILER /usr/bin/gcc-4.7) # -> ADD THIS LINE <-
find_package(CUDA)
Also, it seems clang can compile CUDA as well, maybe that's worth experimenting with (although you would have to build it appropriately).
Note: Some Linux (or other OS) distributions don't have packages for multiple versions of gcc (in the same release of the OS distribution). I would advise against trying to install a package from another release of the distribution on an older release, and consider building gcc instead. That's not entirely trivial but it is quite doable - and of course, it's your only option if you don't have root access to your machine.
Switch back to a supported config. They are listed in the getting started document for any recent CUDA distribution.
For your particular configuration you have currently listed, you might have better luck with CUDA 7 RC, which is now available to registered developers.
I had a similar issue with CUDA Toolkit 7.5 and gcc 5.2.1.
I did modify the host_config.h file in /usr/local/cuda/include/:
Just remove the lines where it check the gcc version. It did solve my problem.
Credits goes to Darren Garvey (https://groups.google.com/forum/#!topic/torch7/WaNmWZqMnzw)
Very often you will find that CUDA has had newer releases by the time you encounter this problem. For example, the original formulation of the question was about CUDA 6 and GCC 4.9; CUDA 7 supported GCC 4.9. CUDA 8 supports GCC 5.x . And so on.
I'm trying to build a binary with GCC 4.9.0 that is backwards-compatible against libstdc++. According to GCC's ABI Policy and Guidelines and Options Controlling C++ Dialect, the command line option -fabi-version should do the trick; however, no matter which version I set, I still get imports of symbols from a version newer then desired, like this:
$ objdump -T binary | grep GLIBCXX_3.4.20
00000000 DF *UND* 00000000 GLIBCXX_3.4.20 _ZSt24__throw_out_of_range_fmtPKcz
I've tried -fabi-version=1 to -fabi-version=5 (ABI version 5 corresponds to GCC 4.6, which is guaranteed to be present on the target system), but those imports keep winding up in the resulting files.
How do I fix this? Going back to an old GCC version is not an option to me for other reasons.
the command line option -fabi-version should do the trick
No, that's completely unrelated to what you want. That option affects the code generated by the compiler, it does not mean you can link to an older version of libstdc++ (which is what you would need in order to stop depending on symbols in the newer libstdc++).
You cannot link to an older libstdc++ with a new GCC. The version of libstdc++ is tightly coupled to the version of GCC, so if you want to linker to an older libstdc++ then you need to compile with an older GCC.
You cannot tell libstdc++ to not use the new symbols, the reason it depends on them is because it needs them. Use an older libstdc++.
Going back to an old GCC version is not an option to me for other reasons.
Then you're screwed.
You either need to use an older GCC, or not link dynamically to libstdc++.so.
On Red Hat Enterprise Linux or CentOS you would have the option of using a newer GCC from the Developer Toolset which avoids linking to the new libstdc++.so but that is only compatible with the system GCC, which is GCC 4.4 for RHEL6 or GCC 4.7 for RHEL7. You can't use it to be compatible with GCC 4.6.
When I run g++ --version on in my Cloud9 terminal I get g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3). This is a fairly old version - old enough that when I try to use C++11 library features like std::unordered_set, I get: "This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options."
I'm not really okay with this, because I don't like having to worry about what features I'm allowed to use and which ones I need to avoid. So I went looking around for how to update g++ to the latest stable version (which seems to be 4.8.1 as of this writing), but I can't figure out how to do it. I tried apt-get, but I just got an error: "Sorry, apt-get is not supported on this system. Try c9pm instead.". Well I tried that, but c9pm list (which is supposed to "List available packages") doesn't show anything that looks like g++. So I'm lost.
How do I install g++ 4.8.1 on Cloud9?
When I run lsb_release -a I see that Cloud9 IDE currently runs on "Red Hat Enterprise Linux Server release 6.4 (Santiago)".
If you choose C/C++ as the project type for a new project you will get a newer gcc version (currently 4.7.2). If you need an even newer one let us know and we can update that version. You can always try to compile the tools you need on the workspace but in case of gcc this might take ages.
This is no longer a problem. g++ --version now returns g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 which, to my knowledge, has full support for C++11.
Actually, cloud9 gives you 4.8.2
cpp --version
cpp (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.