libstdc++: potential bug in specification of layouts.

Tue Jun 3 13:28:32 GMT 2025

On Mon, Jun 2, 2025 at 10:30 AM Luc Grosheintz <luc.grosheintz@gmail.com>
wrote:

> I have a seventh question; and I think keeping them all together
> might be convenient.
>
> On 5/13/25 11:51, Luc Grosheintz wrote:
> > This email chain continues a discussion about potential bugs in the
> > specification that was started here:
> > https://gcc.gnu.org/pipermail/libstdc++/2025-May/061350.html
> >
> > For notational convenience, I'll write `layout_left` as shorthand for
> > `layout_left::mapping`, e.g. layout_left::required_span_size, refers to
> > layout_left::mapping<Extents>::required_span_size.
> >
> >
> > 1. operator==
> >
> > The observation is that for rank0 and rank1, two mappings, one of type
> > layout_left<Extents> and the other layout_right<OExtents>, the
> > operator== is ambiguous if `Extents == OExtents`; but not if the extents
> > are convertible (because the convertability is only in one direction).
> >
> > Godbolt: https://godbolt.org/z/35TbMnc1e
> >
> > Resolution: It's not clear to me what to propose. Likely, something that
> > fixes the ambiguity issue to allow comparing all rank 0 and rank 1
> > instances of layout_left and layout_right. Help would be most welcome:
> > either by collaboratively working on the proposed change; or if someone
> > wants to take over completely that would also work.
> >
> >
> > 2. Missing `noexcept` in layout_left.
> >
> > The specification (N4950 and as published on `eel.is`) consistently
> > doesn't mention `noexcept` in both the Overview and Constructors
> > sections for `layout_left(layout_stride)`.
> >
> > https://eel.is/c++draft/mdspan.layout.left#overview-1
> >
> https://eel.is/c++draft/mdspan.layout.left#lib:layout_left::mapping,constructor____
> >
> > Resolution: I suggest that I file an issue to add `noexcept`
> > consistently. Can this be considered an editorial issue?
> >
> >
> > 3. Inconsistency about `constexpr` in layout_right::required_span_size.
> >
> > The section Overview specifies that `required_span_size` must be
> > constexpr. In the section Observers this keyword is missing.
> >
> > I believe this is considered an editorial issue; and I can fix it by
> > submitting a PR to the text of the standard.
> >
> > https://eel.is/c++draft/mdspan.layout.right#overview-1
> >
> https://eel.is/c++draft/mdspan.layout.right.obs#lib:required_span_size,layout_right::mapping
> >
> > Resolution: I suggest that I file an editorial issue.
> >
> >
> > 4. Inconsistency about `noexcept` in `layout_left::stride`.
> >
> > The section Overview mentions it's `noexcept` but the section Observers
> > doesn't. Again, I think this is an editorial issue.
> >
> > https://eel.is/c++draft/mdspan.layout.left#overview-1
> >
> https://eel.is/c++draft/mdspan.layout.left.obs#lib:stride,layout_left::mapping
> >
> > Resolution: I suggest that I file an editorial issue.
> >
> >
> > 5. At Rank 0 layout_stride is untypically convertible.
> >
> > Commonly, two layouts are considered convertible, if the underlying
> > extent_types are convertible, e.g.
> >
> >
> https://eel.is/c++draft/mdspan.layout.left.cons#lib:layout_left::mapping,constructor_
> >
> https://eel.is/c++draft/mdspan.layout.left.cons#lib:layout_left::mapping,constructor__
> >
> https://eel.is/c++draft/mdspan.layout.right.cons#lib:layout_right::mapping,constructor_
> >
> https://eel.is/c++draft/mdspan.layout.right.cons#lib:layout_right::mapping,constructor__
> > https://eel.is/c++draft/mdspan.layout.stride.cons#9
> >
> > However, for the two ctors `layout_left(layout_stride)` and
> > `layout_right(layout_stride)`, the condition is `rank > 0`. Therefore,
> >
> >      using E1 = std::extents<int>;
> >      using E2 = std::extents<unsigned int>;
> >
> >      static_assert(std::is_convertible_v<
> >          std::layout_stride::mapping<E2>,
> >          std::layout_right::mapping<E1>
> >        >);
> >
> > even though:
> >
> >      static_assert(!std::is_convertible_v<E2, E1>);
> >
> >
> https://eel.is/c++draft/mdspan.layout.left.cons#lib:layout_left::mapping,constructor____
> >
> https://eel.is/c++draft/mdspan.layout.right.cons#lib:layout_right::mapping,constructor____
> >
> > Moreover, for rank 0 layout_stride can be converted to any
> > specialization of layout_left or layout_right; but not to every
> > specialization of `layout_stride`.
> >
> > Godbolt: https://godbolt.org/z/MdbvafG7n
> >
> > Resolution: I suggest I create an non-editorial issue to propose adding
> > the convertibility criterium to the explicitness condition.
>
> 7. Missing Prerequisite representable as size_t.
>
> The mapping policy requires that m(i...) is representable as both
> index_type
> and size_t.
>
> https://eel.is/c++draft/mdspan.layout#reqmts-8
>
> However, I can only find a prerequisite that requires the extents to be
> such
> that the required_span_size is representable as index_type. I can't find
> anything that ensures representable as size_t, e.g.
>
> https://eel.is/c++draft/mdspan.layout#left.cons-1
>
> Is this a missing prerequisite?
>
> My initial understanding (possibly faulty) was that the layouts did all
> their computations in `index_type` and that it would allow computing
> mappings even if size_t was too small, e.g. when dealing with 32-bit
> systems and either disks or distributed systems. In both cases a multi-
> dimensional array could be much larger than the addressable RAM; and
> while that would require some care and mdspan might/can't not work, one
> might still want to compute the mapping of multi-dimensional indexes to
> flat index. Moreover, the layouts don't introduce any notion of underlying
> memory (other than the requirement that m(i...) is representable as
> size_t).
>
> I will try to clarify that design question with the authors. For the
moment let's
ignore this situation, and just adjust the test cases, so they do not fail
in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20250603/51637cdb/attachment-0001.htm>