Alpaka: CUDA 8 and gcc 4.9.2 not compatible

[psychocoderHPC]

With gcc 4.9 and CUDA 8 the compiler crash if -DCMAKE_BUILD_TYPE=Debug is set (like in the CI tests).

Tested exmaple bufferCopy

[psychocoderHPC]

The problem is the compiler flag -G for the cuda compiler, this will disable all optimizations. Maybe -G also increase the compile time of all tests.

[psychocoderHPC]

I found the trigger for this issue in #427, but fixing the wrong used stream not solve this issue.

[psychocoderHPC]

@BenjaminW3 I thinking about removing the support for gcc 4.9.2 in combination with CUDA 8+.
A point against 4.9.2 is that full and correct C++11 is only supported since gcc 5.x.

[BenjaminW3]

I am always for minimizing the supported compiler version. By removing support for gcc 4.9.2 we would also lose support for CUDA 7.0 and 7.5. How widespread is CUDA 8 on the relevant HPC and dev systems to support such a change? Currently we have two work arounds in the code base specific to gcc 4.9.

[psychocoderHPC]

But we can also only disable gcc 4.x if CUDA 8+ is used.

CC-ing: @ax3l

[psychocoderHPC]

@BenjaminW3 Do you know why the buffer test passed the CI tests with CUDA8 and gcc 4.9? Do we check this combination?

[BenjaminW3]

But then we are still limited to the C++11 that gcc 4.9.2 supports.

[psychocoderHPC]

We can do a release within the next week and than remove the bad compiler^^

[BenjaminW3]

CUDA 8 & gcc 4.9 should be checked in job#4 but this is a Debug build and not a release build.

[psychocoderHPC]

is this testing all the examples?

[BenjaminW3]

The examples are build in all cases except when ALPAKA_ACC_GPU_CUDA_ONLY_MODE is set, which is not the case.
My current PR build: https://travis-ci.org/ComputationalRadiationPhysics/alpaka/jobs/290435436
Using gcc 4.9.4 and CUDA 8.0.
Maybe we should update the gcc version in the readme table to state 4.9.4 instead of 4.9.2.

[ax3l]

It's not a good idea to drop gcc 4.9 just because -G is not working with it. It's still wide-spread used and explicitly compatible with CUDA 8.

We can throw warnings or errors if the combination is used.

Maybe we should update the gcc version in the readme table to state 4.9.4 instead of 4.9.2.

yes, let's test that first.

[BenjaminW3]

Yes, as a first step we could drop the '-G' flag when building for CUDA 8+ and issue a warning.

[psychocoderHPC]

416 is not passing because of this issue, I will do a test and remove -G in #416 to check if the CI than pass all tests.

[ax3l]

We can also add the -G issue as a note to the install/compatebility list. -G is quite tricky due to it's high register consumption in many cases and warning that we do not support it well with GCC 4.9(.2) is fine imho.

[ax3l]

Idea:
Additional to adding it to the docs as a note: Since we set -G in CMake on the debug build type, we can just throw a warning for GCC 4.9 and not set -G automatically. (Of course, control via CXXFLAGS is stil possible but users need to know what they do if they want it with that combo.) With that, you can even leave the travis build matrix as is.

[ax3l]

@BenjaminW3 should we also add a note about the -G issue to the docs or will the current patch be sufficient?

[BenjaminW3]

I think the CMake warning is enough.

[ax3l]

All right!

[psychocoderHPC]

I need to correct myself, in #416 I get the some issue with all CUDA <= 8.0 and with CLANG 3.7.1.
I will remove the usage of -G for CUDA <= 8.0 for GCC <5.0 and CLANG 3.7.X

update: CLANG 3.7.1 was only the host compiler and the device side was compiled with nvcc

[psychocoderHPC]

fixed in #435