[libcxx-commits] [PATCH] D154367: [libc++] mdspan - implement mdspan class

[Christian Trott via Phabricator via libcxx-commits]

crtrott added a comment.

I investigated the failure on MinGW and tracked it down to a reproducer on godbolt, which indicates this is a bug in the compiler when using `--target=x86_64-w64-windows-gnu`
https://godbolt.org/z/Y6Mb7sMMc

Shortish version, you have something like this:

  template<class T, class M, class A>
  class mdspan {
      public:
    mdspan() = default;
    mdspan(const mdspan&) = default;
    mdspan(T* ptr_, M map_, A acc_):ptr(ptr_),map(map_),acc(acc_) {}
    template<class OT, class OM, class OA>
    mdspan(const mdspan<OT, OM, OA>& other):ptr(other.ptr), map(other.map), acc(other.acc) {}
  
    [[no_unique_address]] T* ptr;
    [[no_unique_address]] M map;
    [[no_unique_address]] A acc;
  };

If you now do `mdspan<const T, M2, A2>(mdspan<T, M1, A1>);` where M1 <https://reviews.llvm.org/M1>, A1 and A2 are empty, but M2 <https://reviews.llvm.org/M2> is not, and A1->A2 happens via a conversion operator in A1, not a converting constructor in A2 the last byte of ptr gets zeroed out.

The only standard conformant way to fix this is to not have [[no_unique_address]].
However this is a rather esoteric corner case, where you would need to have two accessors where A2 is constructible from A1, but doesn't have a constructor accepting const A1&.

So couple options: 
a) I just don't test that combo on MinGW, and users could run into this behavior which we will report as a bug, if they do something weird.
b) we remove [[no_unique_address]] for now on mdspan for a MinGW build, and break ABI later if and when this bug gets fixed
c) I don't land mdspan today, and we hope the bug is fixed in MinGW with clang 17.

I personally would opt for a) since the chances users will run into this are virtually zero, and one can work around this bug.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154367/new/

https://reviews.llvm.org/D154367