On Fri, 28 Feb 2025, Giuseppe D'Angelo wrote: > 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.dang...@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.
LGTM > > -- > Giuseppe D'Angelo >
