On Mon, 22 Dec 2025 at 12:15, Tomasz Kamiński <[email protected]> wrote:
>
> ---
> htdocs/gcc-16/changes.html | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/htdocs/gcc-16/changes.html b/htdocs/gcc-16/changes.html
> index 013282ec..e067862b 100644
> --- a/htdocs/gcc-16/changes.html
> +++ b/htdocs/gcc-16/changes.html
> @@ -101,6 +101,29 @@ for general information.</p>
> with GNU dialects (<code>-std=gnu++17</code>, <code>-std=gnu++14</code>,
> etc.) and not with strict dialects (<code>-std=c++17</code>, etc.)
> </li>
> +
> + <li>
> + The <a
> href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0952r2.html"/>
> + A new specification for <code>std::generate_canonical</code></a> was
> implemented
> + in all affecte modes (since C++11), impacting the observed output. The
> previous
"affected"
> + behavior can be restored by defining
> <code>_GLIBCXX_USE_OLD_GENERATE_CANONICAL</code>.
> + </li>
> + <li>
> + The <code>std::variant</code> ABI is updated to make it conforming
"was updated"
> + and consistent with C++20 and later modes. This impact the layout
"impacts"
> + of the types that uses the same non-trivially destructible empty-type
> + type <code>E</code> as an base class and alternative of the
> + <code>std::variant</code> that is used as first member:
I think this would be a bit easier to read as:
"This impacts the layout of classes which have a std::variant as the
first member and a base class of the same type as one of the variant's
alternatives, if that type is an empty class and has a non-trivial
destructor."
> + <pre>struct Affected : E
> +{
> + std::variant<E, int> mem; // before stored at offset zero,
"previously stored at offset zero"
> + // uses non-zero offset now
> +};</pre>
> + The previous behavior can be restored by defining
> + <code>_GLIBCXX_USE_VARIANT_CXX17_OLD_ABI</code>. This impacts only
> + C++17 mode.
> + </li>
> +
> <li>Improved experimental support for C++20, including:
> <ul>
> <li>
> @@ -136,7 +159,7 @@ for general information.</p>
> <li>
> Representation of some range adaptors in <code><ranges></code>.
> </li>
> - </ul>.
> + </ul>
> This list is not necessarily complete. As with all experimental support,
> programs using C++20 components should assume that those components
> are not compatible between different major releases.
> @@ -165,7 +188,8 @@ for general information.</p>
> thanks to Nathan Myers.
> </li>
> <li>
> - Padded mdspan layouts, aligned accessor, and <code>std::dims</code>,
> + Padded mdspan layouts, aligned accessor, <code>std::dims</code>,
> + <code>std::constant_wrapper</code>, and <code>std::submdspan</code>
> thanks to Luc Grosheintz.
> </li>
> </ul>
> --
> 2.52.0
>
