Use cxx14 standard

[tcojean]

Upgrade Ginkgo from C++11 standard to C++14.

There are multiple reasons for this:

1. CUDA's thrust will be deprecating C++11 and moving to C++14 shortly.
2. On paper and in practice, all the compiler versions we support already support C++14, so moving doesn't make us lose anything. The only failure is a corner case of CUDA 9.2 and clang 5.0 as CUDA host compiler which cannot be fixed, see the comments in the related PR on this issue.

What changed:

• Upgrade any mention of C++11 to C++14
• Review the std_extensions to use implementation from C++14 instead of the custom made one.
• Update all code calls from xstd to std when the feature used was a C++14 feature.
• Use Intel 2020 together with GCC 9 as there is an incompatibility when considering C++14 between Intel 2019 and GCC 9.
• Ensure tests are always compiled with the C++14 standard
• Throw a fatal_error when using CUDA 9.2 with clang 5.0 as CUDA host compiler.

Closes #604

[tcojean]

Everything is working except for cuda 9.2 + clang 5.0 as host compiler. For some reason, there is an issue interpreting the standard headers and I cannot find the reason. See this pipeline: https://gitlab.com/ginkgo-project/ginkgo-public-ci/-/pipelines/173724849

For some reason, a small example such as the following compiled with nvcc -std=c++14 -ccbin=/usr/bin/clang++ test.cu will fail, whereas nvcc -std=c++14 -ccbin=/usr/bin/g++ test.cu succeeds.

#include <complex>
int main() {
        return 0;
}

[tcojean]

The issue is clearly that nvcc for some reason adds spaces between operator and "" and more importantly "" and if (etc). The operator is defined as operator""if without space (the space has its importance it seems, see https://en.cppreference.com/w/cpp/numeric/complex/operator%22%22i and https://en.cppreference.com/w/cpp/language/user_literal (especially the example down there). Clearly, clang seems to be correct in saying that there is an error here, the issue is why does nvcc 9.2 transforms the perfectly valid header into

constexpr complex< float>  operator "" if(long double __num) 

[upsj]

This is a bug in the clang tokenization/parser: It consumes the "if" token as the if keyword instead of an identifier. Removing the space or changing the identifier to be a non-keyword fixes it.
Output of clang++ --std=c++14 -fsyntax-only -Xclang -dump-tokens:

string_literal '""'	 [LeadingSpace]	Loc=<test.cpp:1:33>
if 'if'	 [LeadingSpace]	Loc=<test.cpp:1:36>

No wait, that doesn't make sense, you are right. An identifier may never be a keyword.

[tcojean]

This can be reproduced with the following simple example

constexpr double operator "" if(unsigned long long d)
{
        return 0.0;
}

int main()
{
        return 0;
}

test.cpp:1:30: error: expected identifier
constexpr double operator "" if(unsigned long long d)
                             ^
1 error generated.

The error has two issues mixed in:

• The space is added by nvcc after the cudafe++ call as Tobias points out down below
• clang's parser messes up and interprets the if as a language construct, any other keyword creates the same problem (else, for, static_cast, operator, ...). Adding a space to a string literal with only an i or literally anything which isn't part of the grammar only gives a warning stating that an underscore is required.

[upsj]

Okay, I finished digging, this is a bug in cudafe++: --gnu_version=70500 gives the correct translation, --clang --clang_version=50000 inserts the space. I guess we can't do anything about that.

[upsj]

Regarding the space: The standard is a bit unclear about the details, but as the Literal operators section of the page you linked states, the user-defined-string-literal token was introduced to allow keywords to be used as literal suffixes, so I believe clang isn't at fault here. gcc emits a similar error message:
unexpected keyword; remove space between quotes and suffix identifier

[tcojean]

Yes, I think clang is somewhat correct in the end, despite the bug being a weird parsing issue. Overall, this shouldn't be valid C++. My understanding is that having a space at this place operator"" if means that it's a user defined literal, which should always start with a underscore. If you put an underscore here, as expected the test example compiles correctly.

[tcojean]

Tobias helped find a possible way to work around this issue, from the previous nvcc error example:

#include <complex>
int main() {
        return 0;
}

You can compile it successfully with the following arguments:

nvcc -ccbin=/usr/bin/clang++ -Xcudafe --gnu_version=70500 -Xcudafe --no_clang -std=c++14 test.cu

[pratikvn]

LGTM!

[tcojean]

The previous fix mentioned works for the complex header, but sadly it creates a lot of issues as soon as we include the <memory> header, so I went with the solution of throwing an error when using clang 5.0 as CUDA host compiler with CUDA 9.2.

[upsj]

LGTM!

[upsj]

Question: Are these changes necessary or left-over from the cuda11 branch?

[tcojean]

They are necessary, I had to upgrade the intel compiler to 2020 for this PR to work properly. I used the CUDA 11 PR to update this at the same time. The Intel 2019 has some incompatibility with GNU 9 backend when considering C++14 code. Therefore we will need to merge the CUDA11 container before this.

[upsj]

Same here

[codecov]

Codecov Report

Merging #611 into develop will not change coverage.
The diff coverage is 81.81%.

@@           Coverage Diff            @@
##           develop     #611   +/-   ##
========================================
  Coverage    93.01%   93.01%           
========================================
  Files          296      296           
  Lines        20656    20656           
========================================
  Hits         19214    19214           
  Misses        1442     1442           

Impacted Files	Coverage Δ
core/base/extended_float.hpp	92.23% <ø> (ø)
core/test/base/polymorphic_object.cpp	97.61% <ø> (ø)
core/test/utils/assertions.hpp	70.98% <ø> (ø)
include/ginkgo/core/base/array.hpp	92.52% <ø> (ø)
include/ginkgo/core/base/lin_op.hpp	97.64% <ø> (ø)
include/ginkgo/core/base/name_demangling.hpp	85.71% <ø> (ø)
include/ginkgo/core/base/range.hpp	95.48% <ø> (ø)
include/ginkgo/core/log/logger.hpp	92.10% <ø> (ø)
include/ginkgo/core/matrix/csr.hpp	47.69% <0.00%> (ø)
include/ginkgo/core/preconditioner/ilu.hpp	96.93% <ø> (ø)
... and 4 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c4c524a...634018e. Read the comment docs.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

36.4% Coverage
4.5% Duplication

The version of Java (1.8.0_121) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11.
Read more here