On Tue, Sep 9, 2025 at 5:03 PM Jonathan Wakely <[email protected]> wrote:
> On Tue, 9 Sept 2025 at 15:57, Tomasz Kaminski <[email protected]> wrote: > > > > > > > > On Tue, Sep 9, 2025 at 4:41 PM Jonathan Wakely <[email protected]> > wrote: > >> > >> On Mon, 8 Sept 2025 at 12:41, Tomasz Kamiński <[email protected]> > wrote: > >> > > >> > I have double checked that implementation-defined behavior in the > [compliance] > >> > (whether the implementation is freestanding) and [stringbuf.const] > (initialization > >> > of sequence pointers) are indeed null, and there are no corresponding > entires in > >> > eariel standards. > >> > >> "earlier" > >> > >> > > >> > libstdc++-v3/ChangeLog: > >> > > >> > * doc/html/manual/status.html: Regenerate. > >> > * doc/xml/manual/status_cxx2020.xml: Add more entires. > >> > --- > >> > OK for trunk? Should I also backport it, if so how far? > >> > >> Just trunk is fine, we need to document this stuff to be conforming, > >> but we aren't claiming conformance to C++20 for the branches. > >> > >> However, a few typos and a suggestion at the end ... > >> > >> > diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml > b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml > >> > index 3539de3cc4b..e646215e092 100644 > >> > --- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml > >> > +++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml > >> > @@ -1464,6 +1464,12 @@ and <function>chrono::parse</function> is > supported since 14.1. > >> > the 2020 standard. > >> > </para> > >> > > >> > + <para> > >> > + <emphasis>16.4.2.4 [compliance]</emphasis> The implementation > is > >> > + freestanding if <code>-ffreestanding</code> compiler flag is > used, > >> > >> "if the" > >> > >> > + and hosted otherwise. > >> > + </para> > >> > + > >> > <para> > >> > <emphasis>16.4.2.4 [compliance]</emphasis> > >> > The support for always lock-free integral atomic types and > presence of > >> > @@ -1472,6 +1478,21 @@ and <function>chrono::parse</function> is > supported since 14.1. > >> > target. > >> > </para> > >> > > >> > + <para> > >> > + <emphasis>27.5.11 [time.duration.io]</emphasis> > >> > + The <literal>"μs"</literal> > (<literal>"\u00b5\u0073"</literal>) is used > >> > + for <code>std::micro</code> <code>Period::type</code> if macro > >> > >> "if the macro" > >> > >> > + <code>_GLIBCXX_USE_ALT_MICROSECONDS_SUFFIX</code> is defined > to value > >> > >> "to a value" > >> > >> > + other than zero before inclusion of the <code>chrono</code> > header, > >> > + <literal>"us"</literal> is used otherwise. > >> > + </para> > >> > + > >> > + <para> > >> > + <emphasis>29.8.2.2 [stringbuf.cons]</emphasis> Sequence > pointers are > >> > + initialied to null pointers by > >> > >> "initialized", and "by the" > >> > >> This is PR80676 and I have a patch to change the constructor to use > >> the SSO capacity, but your patch is correct for now. > >> > >> > + <code>basic_stringbuf(ios_base::openmode)</code> constructor. > >> > + </para> > >> > + > >> > <para> > >> > <emphasis>31.7.1 [atomics.ref.generic.general]</emphasis>, > >> > <emphasis>31.7.3 [atomics.ref.int]</emphasis>, > >> > @@ -1503,6 +1524,14 @@ and <function>chrono::parse</function> is > supported since 14.1. > >> > <code>alignof(value_type)</code>. > >> > </para> > >> > > >> > + <para> > >> > + <emphasis>32.7.3 [thread.sema.cnt]</emphasis> The value of > default > >> > + argument for the <code>least_max_value</code> depends on the > target > >> > + operating system and platform, however the value of > >> > + <code>counting_semaphore<>::max()</code> is greater than > or equal > >> > + to <code>numeric_limits<int>::max()</code>. > >> > + </para> > >> > >> For std::binary_semaphore (a.k.a std::counting_semaphore<1>) the max > >> is 1, so would it make sense to say something like: > >> > >> "however the value of counting_semaphore<N>::max() for N > 1 is at > >> least INT_MAX, and for N <= 1 it is 1." > > > > I do not think this is relevant here, this is about the default value > for template parameter counting_semaphore, > > which affects only uses of counting_semaphore<>. > > Ah yes, I forgot how the "least_max_value" works and where it is relevant. > > We could potentially say it's > numeric_limits<atomic_signed_lock_free::value_type>::max() which is > true in practice, but I think what your patch says is better. > > > > I wanted to add something usable beyond depends on platform, so defined > that counting_semaphore<>::max > > will be at least numeric_limits<int>::max(), so you have an idea where > to put your own value. > > > > For other specializations, there is nothing implementation defined in > standard, you just get something greater or equal than. > > https://eel.is/c++draft/thread.sema#cnt-4 > > Yes, and that's where it varies depending on N==1 or N > 1. > > OK, patch is good for trunk with the typos fixed, thanks. > > This patch depends on atomic_ref docs, which added the implementation defined section for C++20. If you can also take a look at another one, that would simplify merging for me.
