[PATCH v4] libstdc++: implement constexpr memory algorithms

Fri Feb 28 15:07:16 GMT 2025

Hello,

On 27/02/2025 15:34, Jonathan Wakely wrote:
> On 26/02/25 17:27 +0100, Giuseppe D'Angelo wrote:
>> On 26/02/2025 16:33, Giuseppe D'Angelo wrote:
>>> Whops, sorry, missed this sub-thread (while replying to the other one).
>>> Change of plans then, I'll amend and remove the ad-hoc constexpr macro.
>>
>> Done, v3 attached.
>>
>> Thanks,
>> -- 
>> Giuseppe D'Angelo
>>
> 
>>From de3751a38330f508be9f08b77136a31481018828 Mon Sep 17 00:00:00 2001
>> From: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
>> Date: Sun, 16 Feb 2025 19:37:07 +0100
>> Subject: [PATCH] libstdc++: implement constexpr memory algorithms
>>
>> This commit adds support for C++26's constexpr specialized memory
>> algorithms, introduced by P2283R2, P3508R0, P3369R0.
>>
>> The uninitialized_default, value, copy, move and fill algorithms are
>> affected, in all of their variants (iterator-based, range-based and _n
>> versions.)
>>
>> The changes are mostly mechanical -- add `constexpr` to a number of
>> signatures when compiling in C++26 and above modes. The internal helper
>> guard class for range algorithms instead can be marked unconditionally.
>>
>> The only "real" change to the implementation of the algorithms is that
>> during constant evaluation I need to dispatch to a constexpr-friendly
>> version of them.
>>
>> For each algorithm family I've added only one test to cover it and its
>> variants; the idea is to avoid too much repetition and simplify future
>> maintenance.
> 
> The patch itself looks good, but I have some comments on the ChangeLog
> part.

I'm adding a v4 because I discovered that one more tweak was necessary 
to an existing test of the <memory> header synopsis...

  These are thigns I would have tweaked myself before pushing, but
> now that you have commit access ...
> 
>> libstdc++-v3/ChangeLog:
>>
>> 	* include/bits/ranges_uninitialized.h: Mark the specialized
>> 	memory algorithms as constexpr in C++26. Also mark the members
>> 	of the _DestroyGuard helper class.
>> 	* include/bits/stl_uninitialized.h: Ditto.
>> 	* include/bits/stl_construct.h: Mark _Construct_novalue (which
>> 	uses placement new to do default initialization) as constexpr
>> 	in C++26. This is possible due to P2747R2, which GCC already
>> 	implements; other compilers in C++26 modes already implement
>> 	P2448R2, so there should be no issues there.
> 
> Per-file ChangeLog entries should say "what, not why" ... for reasons.

The best reasons :)

> That makes old GNU-style ChangeLog files sometimes not very useful.
> But at least we now have Git commit messages where we can put all the
> detailed background, rationale etc.
> 
> So the explanation that it's possible to make it constexpr due to
> P2448R2 should be above in the free text part of the commit message
> above, along with the parenthesis saying what the function does.
> 
> Also, please mention the changed function by name, i.e.
> 
> 	* include/bits/stl_construct.h (_Construct_novalue): Mark
> 	constexpr for C++26.
> 
> See
> https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
> for the format.
> 
> For the changes in ranges_uninitialized.h and stl_uninitialized.h it's
> basically "all the functions" so I think it's OK not to name them all.
> (It would also be OK if you did name them all individually, but I
> don't think it's necessary.)
> 
>> 	* include/bits/version.def: Bump the feature-testing macro.
> 
> Please mention which macro, e.g. something like:
> 
> 	* include/bits/version.def (raw_memory_algorithms): Bump
>           value.
> 
>> 	* include/bits/version.h: Regenerate.
> 
> (No need to mention the specific macro by name here, because the whole
> file was regenerated so this is fine.)
> 
>> 	* testsuite/20_util/specialized_algorithms/feature_test_macro.cc: New test.
> 
> Please add a line break after the colon here (and the lines below). We
> try to keep ChangeLog entries below about 78 columns, but for
> libstdc++ tests that's often impossible because the pathname is
> already longer than that! But we can still put the "New test." on a
> new line.

The contrib/mklog.py script has a maximum column width of 100, should it 
be amended to 78? (I think that's what happened here, the script 
generated the overlong line and I didn't touch it.)

> 
> Feel free to push to trunk with those changes to the ChangeLog lines
> (and add Reviewed-by: tags for me and/or Patrick if you like). If
> you'd feel more comfortable sending it to the mailing list again for a
> final check, that's fine too.
> 
> Either way, the traditional first commit when you've got write after
> approval access is to add yourself to the MAINTAINERS file, as per:
> https://gcc.gnu.org/gitwrite.html#authenticated
> If you add yourself to the DCO section at the end of the file, you can
> omit the Signed-off-by: line in future commit messages (it's implied
> if your name is in that section of the MAINTAINERS file).

Done, thank you again for all of the guidance.

-- 
Giuseppe D'Angelo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libstdc-implement-constexpr-memory-algorithms.patch
Type: text/x-patch
Size: 32471 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20250228/1946a991/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20250228/1946a991/attachment-0001.p7s>