NEW Added tests for existing math operators

[jkrude]

Rework of #828
Tests were run on a cuda-device and std-backend.
See also https://github.com/ComputationalRadiationPhysics/alpaka/pull/828 for the previous version.
Implemented functors and abstraction, so that one code is used for all operators.

[tdd11235813]

thanks @jkrude. In our case we took a more involved code to keep the definition and extensions of math operations compact and to learn C++11. I am happy, that you use patterns of meta-programming, so you are getting into Alpaka :) You also document the code, that's good!

However, the code is too complex and error-prone to leave it untested itself, e.g. how do I know, that the arguments' data are filled correctly?
I am going to prepare a PR for your side, since there are several things that need be fixed in the interface and coding style.

[BenjaminW3]

Can #828 be closed now?

[tdd11235813]

@jkrude is preparing an update to this PR next days. I gonna close the #828.

[psychocoderHPC]

Do not wonder I stopped the CI because we need to prioritize another PR. I will start the test by hand later.
Restarted the tests now.

[BenjaminW3]

There are ome compilation errors when clang is used as native CUDA compiler:

In file included from /home/travis/build/ComputationalRadiationPhysics/alpaka/test/unit/math/mathOps/src/mathOps.cpp:12:
/home/travis/build/ComputationalRadiationPhysics/alpaka/test/unit/math/mathOps/src/../include/Functor.hpp:120:1: error: reference to __host__ function 'execute<nullptr_t, double, 0>' in __host__ __device__ function
ALPAKA_TEST_MATH_OP_FUNCTOR( OpAbs,
^
/home/travis/build/ComputationalRadiationPhysics/alpaka/test/unit/math/mathOps/src/../include/Functor.hpp:90:17: note: expanded from macro 'ALPAKA_TEST_MATH_OP_FUNCTOR'
    -> decltype(execute(acc, args.arg[0]))                                      \
                ^
/home/travis/build/ComputationalRadiationPhysics/alpaka/test/unit/math/mathOps/src/../include/Functor.hpp:120:1: note: 'execute<nullptr_t, double, 0>' declared here
/home/travis/build/ComputationalRadiationPhysics/alpaka/test/unit/math/mathOps/src/../include/Functor.hpp:72:10: note: expanded from macro 'ALPAKA_TEST_MATH_OP_FUNCTOR'
    auto execute(                                                               \
         ^
/home/travis/build/ComputationalRadiationPhysics/alpaka/test/unit/math/mathOps/src/mathOps.cpp:40:29: note: called by 'operator()<alpaka::acc::AccGpuCudaRt<std::integral_constant<unsigned long, 1>, unsigned long>, alpaka::test::unit::math::Buffer<alpaka::acc::AccGpuCudaRt<std::integral_constant<unsigned long, 1>, unsigned long>, double, 1000>, alpaka::test::unit::math::OpAbs, alpaka::test::unit::math::Buffer<alpaka::acc::AccGpuCudaRt<std::integral_constant<unsigned long, 1>, unsigned long>, alpaka::test::unit::math::ArgsItem<double, alpaka::test::unit::math::Arity::UNARY>, 1000> >'
          results(i, acc) = functor(args(i, acc), acc);
                            ^
/home/travis/build/ComputationalRadiationPhysics/alpaka/include/alpaka/kernel/TaskKernelGpuCudaRt.hpp:88:21: note: called by 'cudaKernel<std::integral_constant<unsigned long, 1>, unsigned long, TestKernel, alpaka::test::unit::math::Buffer<alpaka::acc::AccGpuCudaRt<std::integral_constant<unsigned long, 1>, unsigned long>, double, 1000>, alpaka::test::unit::math::OpAbs, alpaka::test::unit::math::Buffer<alpaka::acc::AccGpuCudaRt<std::integral_constant<unsigned long, 1>, unsigned long>, alpaka::test::unit::math::ArgsItem<double, alpaka::test::unit::math::Arity::UNARY>, 1000> >'
                    kernelFnObj(
                    ^

[BenjaminW3]

Is anyone working on fixing the compilation issues?

[psychocoderHPC]

@jkrude PLease rebase this PR against the current dev and squash all commits.
I tested this PR with HIP-clang 3.1 on our dev system fwk388 and all works fine.

[BenjaminW3]

Some of the windows builds seem to have problems like:
C:\Users\RUNNER~1\AppData\Local\Temp\tmpxft_000007f8_00000000-9_mathOps.cudafe1.cpp : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj [D:\a\alpaka\alpaka\build\test\unit\math\mathOps\mathOps.vcxproj]
You can solve this by adding:

target_compile_options(${_COMMON_TARGET_NAME} PUBLIC "/bigobj")

after line 37 in alpaka/test/common/CMakeLists.txt.

[BenjaminW3]

I created a PR to fix the Windows bigobj issue: #979

[sbastrakov]

Sorry, I did not notice this in time. I believe it's better to avoid relative paths here, and also in other files added by this PR, and instead do #include <alpaka/test/unit/math/mathOps/include/Defines.hpp>. What do you think @jkrude @BenjaminW3 @psychocoderHPC ?

[BenjaminW3]

The CMake way would be to add the include folder to the target_include_directories of the test target. Then you do not need relative includes anymore.

[BenjaminW3]

But on the other hand those files are no public includes at all. We should simply move them into the src folder.

[psychocoderHPC]

Moving them into src is IMO ok. The current relative path requires that the install folder structure is equal to the structure we have in our source code. We should not assume it.

[sbastrakov]

@jkrude when you have time, could you implement this change? Should be not much work, just moving the files and fixing the includes.

[psychocoderHPC]

@jkrude when you have time, could you implement this change? Should be not much work, just moving the files and fixing the includes.

Already fixed and merged with #986