[libc++] Experimental simd tests make assumptions about floating point conversions

[ldionne]

I encountered this issue while working on #68753. Basically, some simd tests start failing when optimizations are enabled because they make invalid assumptions about floating-point conversions.

Reproducer (from libcxx/test/std/experimental/simd/simd.class/simd_ctor_conversion.pass.cpp):

#include <bit>
#include <cassert>
#include <cstddef>
#include <type_traits>
#include <utility>
#include <iostream>

struct simd {
  long double __data __attribute__((__vector_size__(std::bit_ceil((sizeof(long double) * 2)))));

  template <class Array>
  simd(Array const& array) noexcept {
    for (size_t __i = 0; __i != 2; ++__i) {
      __data[__i] = array[__i];
    }
  }
};

int main(int, char**) {
  double as_double __attribute__((__vector_size__(std::bit_ceil((sizeof(double) * 2)))));
  as_double[0] = static_cast<double>(0);
  as_double[1] = static_cast<double>(1);

  simd as_long_double = as_double;

  std::cout << "data[0] as double = " << as_double[0] << std::endl;
  std::cout << "data[1] as double = " << as_double[1] << std::endl;

  std::cout << "data[0] as long double = " << as_long_double.__data[0] << std::endl;
  std::cout << "data[1] as long double = " << as_long_double.__data[1] << std::endl;

  std::cout << "0.0l = " << 0.0l << std::endl;
  std::cout << "1.0l = " << 1.0l << std::endl;

  assert(as_long_double.__data[0] == 0.0l);
  assert(as_long_double.__data[1] == 1.0l);

  return 0;
}

Godbolt: https://godbolt.org/z/8vaKaMb4s

In order to reproduce this in the test suite, you can run libcxx/test/std/experimental/simd/simd.class/simd_ctor_conversion.pass.cpp with -O3 by adding // ADDITIONAL_COMPILE_FLAGS: -O3 to the test and it should reproduce. You should do this inside the Docker image environment to make sure it reproduces, see libcxx/utils/ci/run-buildbot-container.

[joy2myself]

https://godbolt.org/z/f6Tqzcx8s
It seems that GCC works on this code well with -O3 option. Does that mean there are some problems with clang vector extension of type long double and the -O3 optimization?

I have no idea what the issue actually is. However, I tried to put the loop and calculations into internal layer and this seems to avoid the issue. But this may not actually fix the real issue.

[ldionne]

When I tried debugging this, it seemed like the issue was that 1.0 as a double was not the same as 1.0l as a long double, but we use the equality operator to check they are equal in the test. But I'm happy if we only fix the test, my goal is to unblock #68753.