libstdc++: potential bug in specification of layouts.

[Tomasz Kaminski]

On Tue, Jun 3, 2025 at 3:28 PM Tomasz Kaminski <tkaminsk@redhat.com> wrote:

>
>
> 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.
>
I got a response, and this is already implied by:
https://eel.is/c++draft/mdspan.layout.reqmts#8
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20250604/f0046720/attachment.htm>