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

[Luc Grosheintz]

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?

> 
>>
>>    - 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
>>
>>
>