Project

General

Profile

Bug #1402

Error compiling 5.0-beta1 with CUDA and gcc >= 4.6

Added by Arthur Zalevsky about 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

I've got an issue compiling 5.0-beta1 version with CUDA.

With gcc 4.4 everything works fine, but with 4.6-4.8 I've got following error

make: Warning: File `Makefile' has modification time 63 s in the future
make[1]: Warning: File `CMakeFiles/Makefile2' has modification time 65 s in the future
make[2]: Warning: File `src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir/flags.make' has modification time 64 s in the future
[  0%] Building NVCC (Device) object src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir//./cuda_tools_generated_copyrite_gpu.cu.o
[  0%] Building NVCC (Device) object src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir//./cuda_tools_generated_cudautils.cu.o
/usr/include/boost/config/suffix.hpp(496): error: identifier "__int128" is undefined

/usr/include/boost/config/suffix.hpp(497): error: expected a ";" 

2 errors detected in the compilation of "/tmp/tmpxft_00003b78_00000000-12_cudautils.compute_35.cpp1.ii".
CMake Error at cuda_tools_generated_cudautils.cu.o.cmake:260 (message):
  Error generating file 
  /home/domain/silwer/tmp/gromacs-5.0-beta1/build/src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir//./cuda_tools_generated_cudautils.cu.o

make[2]: *** [src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir/./cuda_tools_generated_cudautils.cu.o] Error 1
make[1]: *** [src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir/all] Error 2
make: *** [all] Error 2

Details about system:
Ubuntu 13.10 x86_64, gcc from repos (gcc -v output attached)
gcc

gcc (4.03 KB) gcc gcc -v output for all versions Arthur Zalevsky, 12/11/2013 06:21 PM
cmake.log (8.36 KB) cmake.log cmake output Arthur Zalevsky, 12/11/2013 06:22 PM
make.log (1.25 KB) make.log make output Arthur Zalevsky, 12/11/2013 06:22 PM

Related issues

Related to GROMACS - Bug #1468: boost/assert.hpp:102:47: error: ‘noinline’ was not declared in this scopeClosed03/23/2014

History

#1 Updated by Szilárd Páll about 6 years ago

  • Category set to mdrun
  • Status changed from New to Accepted
  • Priority changed from Normal to High
  • Target version set to 5.0

Reproduced with CUDA 5.0 and boost 1.53. This seems to be a known issue: https://svn.boost.org/trac/boost/ticket/8048. Not sure what the solution could be.

#2 Updated by Szilárd Páll about 6 years ago

The built-in boost subset works, so unless somebody can suggest a reasonable solution, we may have to disable external boost for all GPU-enabled builds with the affected compiler versions.

Any ideas?

[@Teemu/@Roland: added you guys with the hope that they have a better suggestion - if you mind it, feel free to remove yourselves.]

#3 Updated by Teemu Murtola about 6 years ago

Szilárd Páll wrote:

The built-in boost subset works, so unless somebody can suggest a reasonable solution, we may have to disable external boost for all GPU-enabled builds with the affected compiler versions.

Any ideas?

That sounds reasonable; we can also do the disable only for affected boost versions, since that is also available from the CMake detection.

An alternative would be to reorganize the headers such that boost does not get included into CUDA code. Currently, it is just coincidental that this happens; functionality in utility/common.h that depends on boost::scoped_ptr is not required for the header (smalloc.h) that probably pulls this into CUDA code. But I'm not a fan of such an approach, since such a barrier requires extra effort to maintain, and it can only get more difficult in the future.

#4 Updated by Mark Abraham about 6 years ago

Requiring the fallback internal Boost code seems best. Using a system version of Boost seems likely to be generally problematic, anyway. I'd be tempted to make the internal Boost the default even if Boost is detected. What would we even gain from a system Boost, if it works?

#5 Updated by Teemu Murtola about 6 years ago

Mark Abraham wrote:

Requiring the fallback internal Boost code seems best. Using a system version of Boost seems likely to be generally problematic, anyway. I'd be tempted to make the internal Boost the default even if Boost is detected. What would we even gain from a system Boost, if it works?

If one wants to just compile Gromacs and run it, there is no advantage from a system Boost. But if one wants to write code that links against libgromacs (most likely, user's own analysis tools), the internal Boost can be problematic if a system Boost is also available, and is not the same version as our internal copy. This is because our public API depends on Boost (and it is difficult to remove such dependencies, in particular since we don't even have a definition of what is in our public API). To make it possible to circumvent some of these issues, we install the internal Boost headers together with our own headers, but that doesn't solve all the problems, and also requires extra care from the user.

There are two possible issues with the internal Boost:
  • If the user does not want to use Boost in their own code (beyond our internal subset), they need to pay extra care to set the include path correctly so that the installed copy of the internal headers get picked up instead of the system paths.
  • If the user wants to use Boost in their own code, they can't do the above, since that would easily lead to mixing different versions of the Boost headers in the same compilation unit, which is quite likely not going to work. So they have no choice except to use the system Boost to compile all of their code, including the Gromacs headers.

In both cases, if there is any change in memory layout or such in the Boost classes between the internal and system Boost (any binary incompatible change), they can see obscure crashes or incorrect behavior at run time, even though things will likely compile and possibly even link fine.

With some extra effort (and some wrapper headers that get generated by CMake based on the value of GMX_EXTERNAL_BOOST), it is possible to make the first work better (not requiring the user to set the include path), but there is no way around the second.

#6 Updated by Michael Shirts about 6 years ago

I seem to be having problems with this as well. But even when I set GMX_EXTERNAL_BOOST to OFF, it insists on including the boost in the $INCLUDE path.

#7 Updated by Teemu Murtola about 6 years ago

Michael Shirts wrote:

I seem to be having problems with this as well. But even when I set GMX_EXTERNAL_BOOST to OFF, it insists on including the boost in the $INCLUDE path.

What do you mean by "insists"? There must always be some boost headers in the include path; the setting only controls where those are taken.

#8 Updated by Erik Lindahl over 5 years ago

  • Priority changed from High to Normal

#9 Updated by Erik Lindahl over 5 years ago

I can't seem to reproduce this right now, but I had similar issues with gcc-4.8 and 4.9 and CUDA on OS X, and there I managed to solve it by adding -D__STRICT_ANSI__.

#10 Updated by Erik Lindahl over 5 years ago

  • Target version changed from 5.0 to 5.x

#11 Updated by Erik Lindahl over 5 years ago

  • Status changed from Accepted to Resolved

I can no longer reproduce this with Cuda-5.5 and Boost 1.53 on Ubuntu 13.10 using the latest release-5-0 branch.

I would suspect that either some of our recent CMake fixes worked around it, or that Nvidia did so in Cuda-5.5. In either case, I'm changing this to "resolved" for now.

There might still be special combinations of a buggy Boost with older Cuda versions that do not work, but there I think we need to draw a line and not complicate our configuration setup for corner case bugs that are not related to Gromacs - with Cuda I suspect most people will want to use recent drivers, anyway.

#12 Updated by Teemu Murtola over 5 years ago

I changed the code a bit in some reorganization commit such that the boost headers no longer probably get included in the CUDA code. This works around the issue for now.

#13 Updated by Teemu Murtola over 5 years ago

  • Related to Bug #1468: boost/assert.hpp:102:47: error: ‘noinline’ was not declared in this scope added

#14 Updated by Teemu Murtola over 5 years ago

  • Assignee set to Teemu Murtola
  • Target version changed from 5.x to 5.0

#15 Updated by Roland Schulz over 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF