[PATCH v1 0/4] libstdc++: Implement first part of submdspan.

[Tomasz Kaminski]

On Fri, Oct 3, 2025 at 2:44 PM Luc Grosheintz <luc.grosheintz@gmail.com>
wrote:

>
>
> On 10/3/25 12:09 PM, Tomasz Kaminski wrote:
> > On Thu, Oct 2, 2025 at 11:34 AM Luc Grosheintz <luc.grosheintz@gmail.com
> >
> > wrote:
> >
> >> This patch series contains everything up to submdspan_extents and
> >> implements them as described in N5014, i.e. without P3663.
> >>
> >> The reasons to not include P3663 are:
> >>
> >>    - Doing both allows us to benchmark the change.
> >>
> > My concern is that this duplicates the amount of reviews required,
> > and work spent on this paper.
>
> That's a very valid argument. I'll locally incorporate all
> you feedback for v1. We could pause and continue directly
> with P3663, is that better for you?
>
> There's a few things I'd like to do:
>
>    1. I'm very curious to see if this canonicalization has
>    an impact on the generated code.
>
>    2. I should also re-check the mapping::operator() for all
>    five layouts; and I'd like to analyze some slightly more
>    advanced usecases and compare to naive almost C-style code.
>
> >
> >>
> >>    - Carefully implementing both, automatically leads to looking at the
> >>      problem from different angles. We can spot differences between the
> >>      two proposals. One such difference is that P3663 seems to allow
> >>      ambiguous slices, e.g. slices that convert to both full_extent and
> >>      index_type.
> >>
> > Yes, this was an intentional change in the paper.
>
> That's interesting, what was the reason?
>
Because the new specification, instead of using index-pair-like, defines
acceptable
slice pair via structured binding. i.e. the following being well-formed:
  auto [x, y] = s;
We no longer are able to write a concept check for that, note that the above
supports structs with two members, while index-pair-like only std::pair,
std::tuple.

The only way to implement that is to have a some if-condition chaing:
 * try single element
 * try convertible to full_extent
 * try strided slice
 * unconditionally attempt doing auto [x, y] = s, if it is ill-formed
   function will be ill-formed.
As a consequence, we can no longer check if we meet more than one
interpretation.


>
> >
> >>
> >>    - P3663 hasn't been finalized yet, if we implement it now we'll need
> >>      to keep track of the difference. That's easier (or at least not
> >>      harder) if we have a commit containing the already applied changes
> >>      from N5014.
> >>
> > We hope that it will be finalized in today's telecon.
>
> Congrats & best of luck!
>
> >
> >>
> >>    - With a casting layer in place, the changes in the paper are quite
> >>      contained, e.g. remove cases for handling tuple, slightly refine
> >>      the range checks of slices (more can be done at compile-time).
> >>
> > The wording before  P3663 does not allow slices to be canonicalized
> > before calling submdspan_mapping customization point, at least for user
> > defined-layouts. This is not an issue for the sub extents, as it is not
> > customizable.
> > But it will show up in the next commits. Maybe it is less of the issues
> as
> > __subextents
> > will already perform most of the required checks.
> >
> >>
> >>    - We could easily revert P3663 if needed.
> >>
> >> Luc Grosheintz (4):
> >>    libstdc++: Implement strided_slice from <mdspan>. [PR110352]
> >>    libstdc++: Implement full_extent_t. [PR110352]
> >>    libstdc++: Implement submdspan_mapping_result. [PR110352]
> >>    libstdc++: Implement submdspan_extents. [PR110352]
> >>
> >>   libstdc++-v3/include/bits/version.def         |   9 +
> >>   libstdc++-v3/include/bits/version.h           |   9 +
> >>   libstdc++-v3/include/std/mdspan               | 311 ++++++++++++++++++
> >>   libstdc++-v3/src/c++23/std.cc.in              |   7 +-
> >>   .../testsuite/23_containers/mdspan/int_like.h |   9 +
> >>   .../mdspan/submdspan/strided_slice.cc         |  46 +++
> >>   .../mdspan/submdspan/strided_slice_neg.cc     |  19 ++
> >>   .../mdspan/submdspan/submdspan_extents.cc     | 159 +++++++++
> >>   .../mdspan/submdspan/submdspan_extents_neg.cc |  66 ++++
> >>   9 files changed, 633 insertions(+), 2 deletions(-)
> >>   create mode 100644
> >> libstdc++-v3/testsuite/23_containers/mdspan/submdspan/strided_slice.cc
> >>   create mode 100644
> >>
> libstdc++-v3/testsuite/23_containers/mdspan/submdspan/strided_slice_neg.cc
> >>   create mode 100644
> >>
> libstdc++-v3/testsuite/23_containers/mdspan/submdspan/submdspan_extents.cc
> >>   create mode 100644
> >>
> libstdc++-v3/testsuite/23_containers/mdspan/submdspan/submdspan_extents_neg.cc
> >>
> >> --
> >> 2.50.1
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20251003/9d803438/attachment.htm>