Backports C++17/20 <chrono> features to C++14

[jrhemstad]

Depends on #44

• Moves <chrono> features guarded to C++17/20 to C++14

• Adds missing _LIBCUDACXX_INLINE_VISIBILITY functions in <chrono> to ensure they are annotated with __host__ __device__

• Backports libc++ std/utilities/time tests that were previously only tested in C++17/20 to be tested with C++14

• Added explicit casts to operator- for weekday to workaround an NVCC bug

• Removed the _LIBCUDACXX_HAS_NO_CXX20_CHRONO_LITERALS definition since the literals were backported This turned out to not be possible because compilers warn on the "user" defined literal.

Porting the tests required a few changes/workarounds to upstream tests:

• Updated tests to build with --expt-relaxed-constexpr to allow accessing constexpr globals from <chrono> in device code

• nvcc does not support ODR-user of constexpr global variables (e.g., cuda::std::chrono::March). To workaround, in several tests I created a constexpr local copy of the global, e.g.,

__device__ void odr_use_month(cuda::std::chrono::month const& m);

__device__ void foo(){
   // odr_use_month(cuda::std::March); // This won't work
   auto constexpr March = cuda::std::March;
   odr_use_month(March); // this works
}

• Rename operator[].pass.cpp to operator_index.pass.cpp because nvcc doesn't like square brackets in a file name

• Marked the following tests as XFAIL with gcc below 7.0 due to gcc bug:

  • time/time.cal/time.cal.ymdlast/time.cal.ymdlast.members/plus_minus_equal_month.pass.cpp
  • time/time.cal/time.cal.ymdlast/time.cal.ymdlast.members/plus_minus_equal_year.pass.cpp
  • time/time.cal/time.cal.ymwd/time.cal.ymwd.members/plus_minus_equal_month.pass.cpp
  • time/time.cal/time.cal.ymwd/time.cal.ymwd.members/plus_minus_equal_year.pass.cpp

[griwes]

How many tests are there that require relaxed constexpr? Could we perhaps have a mode where we don't enable the flag, add a feature that let's tests know it's not added, and XFAIL or UNSUPPORTED them when the flag is not on?

@brycelelbach any opinions on that? Another option would be to wrap the offending code in the check for relaxed constexpr, but I think we talked about that and discarded it as an option previously?

Otherwise this looks good, but I'd like to resolve the question above first. I have a feeling that without a mode without that flag, we may accidentally brick NVRTC completely by introducing a constexpr function without an annotation somewhere; I want to make sure we don't accidentally force end users to add NVRTC flags that shouldn't be necessary. (NVCC users should be able to deal with it, maybe just not be able to use some functionality on the device side - NVRTC however errors when it merely parses a host definition, so NVRTC users would just be bricked if we miss something because of this flag.)

[griwes]

I assume this is consciously C++17 only? Or you just missed it? (Same in the next file.)

[jrhemstad]

Nope, looks like I missed it. I wasn't as diligent about checking test files for pre-processor C++ version checks.

[jrhemstad]

So I looked into this further. These tests are guarded with TEST_STD_VER > 14 because they are testing functionality that wasn't made constexpr until C++17, e.g., https://en.cppreference.com/w/cpp/chrono/time_point/operator_arith

It doesn't appear there's any language reason these operations can't be made constexpr in C++14. Are we comfortable with backporting the constexprness of these operations from C++17 to C++14?

[griwes]

Do you need them be constexpr in C++14? I think it'd be fine if there's nothing C++17 specific in that code, given we are already backporting parts of this, but I'm unsure here.

[jrhemstad]

I don't think we have a strong need for this to be constexpr, but if we're already backporting, might as well?

[brycelelbach]

Yah, let's not assume relaxed constexpr. It's fine to have some separate tests that are relaxed constexpr specific.

[jrhemstad]

Yah, let's not assume relaxed constexpr. It's fine to have some separate tests that are relaxed constexpr specific.

Sure, how do I configure it so that only some tests are compiled with relaxed constexpr?

[jrhemstad]

So it turns out that we don't need --expt-relaxed-constexpr for any of the tests after all. You can access constexpr globals w/o the relaxed constexpr.

https://godbolt.org/z/Y9f4fq

I originally had thought it was necessary because the tests were ODR using constexpr globals, but that isn't allowed even with --expt-relaxed-constexpr. My WAR of using a constexpr local variable looks to have eliminated the need for relaxed constexpr at all.

[griwes]

LGTM, I'll start doing CI runs on your changes today.

[griwes]

Internal CI launched on CL 29332841.

[griwes]

Relaunched internal CI on CL 29338478.

[griwes]

Relaunched internal CI on CL 29342510.