Re: RFC: A redesign of `-Mmodules` output

[Nathaniel Shead via Gcc]

On Tue, Mar 04, 2025 at 01:09:33PM +, vspefs via Gcc wrote:
> On Tuesday, March 4th, 2025 at 18:04, Ben Boeckel via Gcc  
> wrote:
> 
> > On Tue, Mar 04, 2025 at 07:53:51 +, vspefs wrote:
> > 
> > > By the way, what's stop us from having compiler options like
> > > `g++ -Rgcm.cache -Rsomewhere/else/gcm.cache` to specify CMI repo path, 
> > > like `-I`
> > > for include paths? It could be useful for projects with complex folder
> > > structure, as build tools like Make sometimes change current working 
> > > directory,
> > > and so we need to locate CMIs in different folders.
> > 
> > 
> > Numerous :) . Consider these (non-exhaustive) problematic scenarios:
> > 
> > - incremental build, so some modules already exist, you find
> > `imported.cmi`, but how do you know it is up-to-date?
> > - flag compatibility matters; if you find `imported.cmi`, but its flag
> > set is incompatible, do you keep searching or give up?
> > - caching and distributed build tools now need to somehow encapsulate
> > repository state into their hashes and send contents as necessary
> 
> In my beautiful, blinded fantasy, this flag should only be used with other 
> tools
> keeping the CMIs up-to-date, e.g. a build system. If a build system ensures 
> all
> needed CMIs are updated before the source gets built, there should be no
> problem.
> 
> Flag compatibility - it should reject incompatible CMIs.
> 
> My whole intention of this flag is to provide a handy way to configure the
> built-in module mapper, especially for build systems that use subdirectories 
> to
> structure projects. The  in `-R` should be dynamic, decided by the
> build system at *configure* time, usually representing the paths of CMI cache
> folders of multiple subdirectories under 1 specific build profile. It cannot 
> be
> used together with `-fmodule-mapper`.
> 

Worth noting that GCC already provides a mapper that you can customise:

$ g++ -fmodules -fmodule-mapper='|@g++-module-server -r path' -c m.cpp

for an m.cpp that provides a module "M" will write to 'path/M.gcm'.

> In shorter words, it is a way to 1) isolate CMIs of different build profiles,
> and 2) make handling modules in different subdirectories easier, with minor
> effort needed on the build system side.
> 
> Caching build tools - God, I guess you're right.
> 
> > > The mapping between module interface unit, module name, and expected CMI
> > > filename is still performed by the module mapper. But now when looking up 
> > > a CMI,
> > > it goes to each repo in the list, in order, until it finds a CMI that 
> > > matches
> > > and returns its full path. When producing a CMI, the CMI file is dumped 
> > > to the
> > > first repo.
> > 
> > 
> > The mapper returns the path to where it wants the CMI; why second-guess
> > it by putting it somewhere it didn't specify? Same with lookup; the
> > mapper knows the full path it made the CMI at in the first place and
> > returns that. There should not need to be any searching involved at all.
> 
> Like mentioned above, the point is not searching but specifying. For a capable
> build system, it can provide straight-forward mapper file that contains
> module-name-CMI-path pairs like CMake does. Or other facility that works.
> 
> I had this idea when I was toying with module mappers. I thought module 
> mappers
> could optionally provide some logic, and it can be useful. But with current
> `-fmodule-mapper`, you either use the simple built-in mapper, or write one
> yourself, build a standalone executable, and remember to handle its lifetime
> during the build. This flag should give users some power to configure the
> built-in module mapper behaviour that makes life easier.
> 
> > > Ideally, all invocations concerning modules should have `-Rgcm.cache` as 
> > > the
> > > first CMI repo. This way, all CMI producing calls remain deterministic, 
> > > and
> > > behave same as before.
> > 
> > 
> > If you have a single build with both release and debug configurations,
> > they at least need to have separate repositories. Each executable should
> > as well because while `export module foo;` has to be unique in a
> > program, each executable could have their own `foo` module that doesn't
> > interact with others of the same name.
> 
> My bad. Didn't mention the intended use. The whole point of having a `-R` flag
> is to have separate repositories. We should have `-Rgcm.cache-debug` under 
> debug
> configuration, and `-Rgcm.cache-release` under release.
> 
> Each executable should as well - Yes, I didn't think of that. I always 
> believed
> that "avoiding duplicated module names" is something commonly accepted, but 
> now
> come to think of it, it's not something I can decide. It can be handled 
> though.
> Something like `-Rgcm.cache--`.
> 
> I might have oversimplified the situation. But the "mangling" of CMI paths 
> can't
> be avoided, and I believe this flag can help.
> 
> > > This could make Make-based build systems really work. The Makefile rules
> > > propo

gcc-git-customization.sh error

[Jonathan Wakely via Gcc]

While onboarding somebody today we noticed an error in the
customization script if you use a non-default value for the local
prefix.

I reproduced it with bash -x to show where it happens. In the output
below I entered "jw" as the local prefix, instead of the default "me":

+ echo 'Setting up tracking for personal namespace redi in remotes/users/jw'
Setting up tracking for personal namespace redi in remotes/users/jw
+ git config remote.users/jw.url git+ssh://r...@gcc.gnu.org/git/gcc.git
+ '[' x '!=' x ']'
+ git config --replace-all remote.users/jw.fetch
'+refs/users/redi/heads/*:refs/remotes/users/jw/*'
refs/users/redi/heads/
+ git config --replace-all remote.users/jw.fetch
'+refs/users/redi/tags/*:refs/tags/users/jw/*' refs/users/redi/tags/
+ git config --replace-all remote.users/jw.push
'refs/heads/jw/*:refs/users/redi/heads/*' refs/users/redi
+ '[' me '!=' jw -a me '!=' origin ']'
+ git config --remove-section remote.me
fatal: no such section: remote.me
+ git config --unset-all remote.origin.fetch refs/users/redi/
+ git config --unset-all remote.origin.push refs/users/redi/
+ git fetch users/jw

The script finishes successfully, but because the last line that is
printed out is "fatal: no such section: remote.me" it makes it look
like it failed and exited. But it's only fatal to the 'git config'
sub-process, not the script that the user is actually running.

Should we just add a 2>/dev/null redirect to that command, or do we
want to check if it exists before trying to remove it? i.e.
if git config get --regexp remote.me >/dev/null; then
  git config --remove-section remote.me
fi

Or should we just remove that part entirely?
I doubt anybody used the original version of that script prior to
January 2020, and hasn't updated to the new structure yet. See
r10-6086-g24b178184f260a which introduced that part.

Re: RFC: A redesign of `-Mmodules` output

[vspefs via Gcc]

On Wednesday, March 5th, 2025 at 21:06, Nathaniel Shead via Gcc 
 wrote:

> Worth noting that GCC already provides a mapper that you can customise:
> 
> $ g++ -fmodules -fmodule-mapper='|@g++-module-server -r path' -c m.cpp
> 
> for an m.cpp that provides a module "M" will write to 'path/M.gcm'.

Exactly! I have found that as well. I had always thought that the whole default
module mapper is embedded in GCC source, but when I started to look into that
I immediately found the standalone `g++-module-server` executable.

I'll implement this `-R` thing there, and try to have Autotools working with
modules in this way. We'll see how things roll out.

Re: gcc-git-customization.sh error

[Jonathan Wakely via Gcc]

On Wed, 5 Mar 2025 at 14:05, Richard Earnshaw (lists)
 wrote:
>
> On 05/03/2025 13:47, Jonathan Wakely wrote:
> > On Wed, 5 Mar 2025 at 13:37, Richard Earnshaw (lists)
> >  wrote:
> >>
> >> On 05/03/2025 13:10, Jonathan Wakely via Gcc wrote:
> >>> While onboarding somebody today we noticed an error in the
> >>> customization script if you use a non-default value for the local
> >>> prefix.
> >>>
> >>> I reproduced it with bash -x to show where it happens. In the output
> >>> below I entered "jw" as the local prefix, instead of the default "me":
> >>>
> >>> + echo 'Setting up tracking for personal namespace redi in 
> >>> remotes/users/jw'
> >>> Setting up tracking for personal namespace redi in remotes/users/jw
> >>> + git config remote.users/jw.url git+ssh://r...@gcc.gnu.org/git/gcc.git
> >>> + '[' x '!=' x ']'
> >>> + git config --replace-all remote.users/jw.fetch
> >>> '+refs/users/redi/heads/*:refs/remotes/users/jw/*'
> >>> refs/users/redi/heads/
> >>> + git config --replace-all remote.users/jw.fetch
> >>> '+refs/users/redi/tags/*:refs/tags/users/jw/*' refs/users/redi/tags/
> >>> + git config --replace-all remote.users/jw.push
> >>> 'refs/heads/jw/*:refs/users/redi/heads/*' refs/users/redi
> >>> + '[' me '!=' jw -a me '!=' origin ']'
> >>> + git config --remove-section remote.me
> >>> fatal: no such section: remote.me
> >>> + git config --unset-all remote.origin.fetch refs/users/redi/
> >>> + git config --unset-all remote.origin.push refs/users/redi/
> >>> + git fetch users/jw
> >>>
> >>> The script finishes successfully, but because the last line that is
> >>> printed out is "fatal: no such section: remote.me" it makes it look
> >>> like it failed and exited. But it's only fatal to the 'git config'
> >>> sub-process, not the script that the user is actually running.
> >>>
> >>> Should we just add a 2>/dev/null redirect to that command, or do we
> >>> want to check if it exists before trying to remove it? i.e.
> >>> if git config get --regexp remote.me >/dev/null; then
> >>
> >> You'd want to match ^remote.${old_pfx}, for safety.
> >
> > Good point!
> >
> >> You could also use 'git config --get-regexp', but perhaps that's what you 
> >> mean anyway.
> >
> > I think 'get --regexp' works, but it doesn't matter if we just remove
> > that chunk.
> >
>
> git config --help only shows the form I mentioned.  That doesn't mean yours 
> won't work as well, though.

Ah that's deprecated now (not sure when that happened though):
https://git-scm.com/docs/git-config#_deprecated_modes


>
> >>
> >>>   git config --remove-section remote.me
> >>> fi
> >>>
> >>> Or should we just remove that part entirely?
> >>> I doubt anybody used the original version of that script prior to
> >>> January 2020, and hasn't updated to the new structure yet. See
> >>> r10-6086-g24b178184f260a which introduced that part.
> >>
> >> But this might be easier.  I agree, that was very much a transitional bit 
> >> of code as we settled on our new workflows.
> >>
> >> I'll trust your decision on this one.
> >
> > I'll wait for any other comments, but if nobody disagrees, I think we
> > should remove it. How much of it is cleaning up the old config, just
> > this?
> >
> > -- a/contrib/gcc-git-customization.sh
> > +++ b/contrib/gcc-git-customization.sh
> > @@ -205,12 +205,4 @@ git config --replace-all
> > "remote.users/${new_pfx}.fetch" "+refs/users/${remote_i
> > git config --replace-all "remote.users/${new_pfx}.fetch"
> > "+refs/users/${remote_id}/tags/*:refs/tags/users/${new_pfx}/*" "re
> > fs/users/${remote_id}/tags/"
> > git config --replace-all "remote.users/${new_pfx}.push"
> > "refs/heads/${new_pfx}/*:refs/users/${remote_id}/heads/*" "refs/use
> > rs/${remote_id}"
> >
> > -if [ "$old_pfx" != "$new_pfx" -a "$old_pfx" != "${upstream}" ]
> > -then
> > -git config --remove-section "remote.${old_pfx}"
> > -fi
> > -
> > -git config --unset-all "remote.${upstream}.fetch" 
> > "refs/users/${remote_id}/"
> > -git config --unset-all "remote.${upstream}.push" "refs/users/${remote_id}/"
> > -
> > git fetch "users/${new_pfx}"
> >
> >
> > While making t hat edit, I noticed that the lines above it have:
> >
> > git config --replace-all "remote.users/${new_pfx}.fetch"
> > "+refs/users/${remote_id}/heads/*:refs/remotes/users/${new_pfx}/*"
> > "refs/users/${remote_id}/heads/"
> > git config --replace-all "remote.users/${new_pfx}.fetch"
> > "+refs/users/${remote_id}/tags/*:refs/tags/users/${new_pfx}/*"
> > "refs/users/${remote_id}/tags/"
> >
> > That doesn't look right, because the second line will replace what was
> > done by the first.
>
> Really? isn't one working on heads and the other on tags?

Ah right, yes, the value-pattern at the end restricts what gets
replaced (that syntax is also now deprecated apparently).



> All of this hunk seems related to legacy layouts as well:
>
> +# Scan the existing settings to see if there are any we need to rewrite.
> +vendors=$(git config --get-all "remote.${upstream}.fetch" "refs/vendors/" | 
> sed
>  -r "s:.*

Re: gcc-git-customization.sh error

[Jonathan Wakely via Gcc]

On Wed, 5 Mar 2025 at 13:37, Richard Earnshaw (lists)
 wrote:
>
> On 05/03/2025 13:10, Jonathan Wakely via Gcc wrote:
> > While onboarding somebody today we noticed an error in the
> > customization script if you use a non-default value for the local
> > prefix.
> >
> > I reproduced it with bash -x to show where it happens. In the output
> > below I entered "jw" as the local prefix, instead of the default "me":
> >
> > + echo 'Setting up tracking for personal namespace redi in remotes/users/jw'
> > Setting up tracking for personal namespace redi in remotes/users/jw
> > + git config remote.users/jw.url git+ssh://r...@gcc.gnu.org/git/gcc.git
> > + '[' x '!=' x ']'
> > + git config --replace-all remote.users/jw.fetch
> > '+refs/users/redi/heads/*:refs/remotes/users/jw/*'
> > refs/users/redi/heads/
> > + git config --replace-all remote.users/jw.fetch
> > '+refs/users/redi/tags/*:refs/tags/users/jw/*' refs/users/redi/tags/
> > + git config --replace-all remote.users/jw.push
> > 'refs/heads/jw/*:refs/users/redi/heads/*' refs/users/redi
> > + '[' me '!=' jw -a me '!=' origin ']'
> > + git config --remove-section remote.me
> > fatal: no such section: remote.me
> > + git config --unset-all remote.origin.fetch refs/users/redi/
> > + git config --unset-all remote.origin.push refs/users/redi/
> > + git fetch users/jw
> >
> > The script finishes successfully, but because the last line that is
> > printed out is "fatal: no such section: remote.me" it makes it look
> > like it failed and exited. But it's only fatal to the 'git config'
> > sub-process, not the script that the user is actually running.
> >
> > Should we just add a 2>/dev/null redirect to that command, or do we
> > want to check if it exists before trying to remove it? i.e.
> > if git config get --regexp remote.me >/dev/null; then
>
> You'd want to match ^remote.${old_pfx}, for safety.

Good point!

> You could also use 'git config --get-regexp', but perhaps that's what you 
> mean anyway.

I think 'get --regexp' works, but it doesn't matter if we just remove
that chunk.

>
> >   git config --remove-section remote.me
> > fi
> >
> > Or should we just remove that part entirely?
> > I doubt anybody used the original version of that script prior to
> > January 2020, and hasn't updated to the new structure yet. See
> > r10-6086-g24b178184f260a which introduced that part.
>
> But this might be easier.  I agree, that was very much a transitional bit of 
> code as we settled on our new workflows.
>
> I'll trust your decision on this one.

I'll wait for any other comments, but if nobody disagrees, I think we
should remove it. How much of it is cleaning up the old config, just
this?

-- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -205,12 +205,4 @@ git config --replace-all
"remote.users/${new_pfx}.fetch" "+refs/users/${remote_i
git config --replace-all "remote.users/${new_pfx}.fetch"
"+refs/users/${remote_id}/tags/*:refs/tags/users/${new_pfx}/*" "re
fs/users/${remote_id}/tags/"
git config --replace-all "remote.users/${new_pfx}.push"
"refs/heads/${new_pfx}/*:refs/users/${remote_id}/heads/*" "refs/use
rs/${remote_id}"

-if [ "$old_pfx" != "$new_pfx" -a "$old_pfx" != "${upstream}" ]
-then
-git config --remove-section "remote.${old_pfx}"
-fi
-
-git config --unset-all "remote.${upstream}.fetch" "refs/users/${remote_id}/"
-git config --unset-all "remote.${upstream}.push" "refs/users/${remote_id}/"
-
git fetch "users/${new_pfx}"


While making t hat edit, I noticed that the lines above it have:

git config --replace-all "remote.users/${new_pfx}.fetch"
"+refs/users/${remote_id}/heads/*:refs/remotes/users/${new_pfx}/*"
"refs/users/${remote_id}/heads/"
git config --replace-all "remote.users/${new_pfx}.fetch"
"+refs/users/${remote_id}/tags/*:refs/tags/users/${new_pfx}/*"
"refs/users/${remote_id}/tags/"

That doesn't look right, because the second line will replace what was
done by the first.

Re: gcc-git-customization.sh error

[Richard Earnshaw (lists) via Gcc]

On 05/03/2025 13:47, Jonathan Wakely wrote:
> On Wed, 5 Mar 2025 at 13:37, Richard Earnshaw (lists)
>  wrote:
>>
>> On 05/03/2025 13:10, Jonathan Wakely via Gcc wrote:
>>> While onboarding somebody today we noticed an error in the
>>> customization script if you use a non-default value for the local
>>> prefix.
>>>
>>> I reproduced it with bash -x to show where it happens. In the output
>>> below I entered "jw" as the local prefix, instead of the default "me":
>>>
>>> + echo 'Setting up tracking for personal namespace redi in remotes/users/jw'
>>> Setting up tracking for personal namespace redi in remotes/users/jw
>>> + git config remote.users/jw.url git+ssh://r...@gcc.gnu.org/git/gcc.git
>>> + '[' x '!=' x ']'
>>> + git config --replace-all remote.users/jw.fetch
>>> '+refs/users/redi/heads/*:refs/remotes/users/jw/*'
>>> refs/users/redi/heads/
>>> + git config --replace-all remote.users/jw.fetch
>>> '+refs/users/redi/tags/*:refs/tags/users/jw/*' refs/users/redi/tags/
>>> + git config --replace-all remote.users/jw.push
>>> 'refs/heads/jw/*:refs/users/redi/heads/*' refs/users/redi
>>> + '[' me '!=' jw -a me '!=' origin ']'
>>> + git config --remove-section remote.me
>>> fatal: no such section: remote.me
>>> + git config --unset-all remote.origin.fetch refs/users/redi/
>>> + git config --unset-all remote.origin.push refs/users/redi/
>>> + git fetch users/jw
>>>
>>> The script finishes successfully, but because the last line that is
>>> printed out is "fatal: no such section: remote.me" it makes it look
>>> like it failed and exited. But it's only fatal to the 'git config'
>>> sub-process, not the script that the user is actually running.
>>>
>>> Should we just add a 2>/dev/null redirect to that command, or do we
>>> want to check if it exists before trying to remove it? i.e.
>>> if git config get --regexp remote.me >/dev/null; then
>>
>> You'd want to match ^remote.${old_pfx}, for safety.
> 
> Good point!
> 
>> You could also use 'git config --get-regexp', but perhaps that's what you 
>> mean anyway.
> 
> I think 'get --regexp' works, but it doesn't matter if we just remove
> that chunk.
> 

git config --help only shows the form I mentioned.  That doesn't mean yours 
won't work as well, though.

>>
>>>   git config --remove-section remote.me
>>> fi
>>>
>>> Or should we just remove that part entirely?
>>> I doubt anybody used the original version of that script prior to
>>> January 2020, and hasn't updated to the new structure yet. See
>>> r10-6086-g24b178184f260a which introduced that part.
>>
>> But this might be easier.  I agree, that was very much a transitional bit of 
>> code as we settled on our new workflows.
>>
>> I'll trust your decision on this one.
> 
> I'll wait for any other comments, but if nobody disagrees, I think we
> should remove it. How much of it is cleaning up the old config, just
> this?
> 
> -- a/contrib/gcc-git-customization.sh
> +++ b/contrib/gcc-git-customization.sh
> @@ -205,12 +205,4 @@ git config --replace-all
> "remote.users/${new_pfx}.fetch" "+refs/users/${remote_i
> git config --replace-all "remote.users/${new_pfx}.fetch"
> "+refs/users/${remote_id}/tags/*:refs/tags/users/${new_pfx}/*" "re
> fs/users/${remote_id}/tags/"
> git config --replace-all "remote.users/${new_pfx}.push"
> "refs/heads/${new_pfx}/*:refs/users/${remote_id}/heads/*" "refs/use
> rs/${remote_id}"
> 
> -if [ "$old_pfx" != "$new_pfx" -a "$old_pfx" != "${upstream}" ]
> -then
> -git config --remove-section "remote.${old_pfx}"
> -fi
> -
> -git config --unset-all "remote.${upstream}.fetch" "refs/users/${remote_id}/"
> -git config --unset-all "remote.${upstream}.push" "refs/users/${remote_id}/"
> -
> git fetch "users/${new_pfx}"
> 
> 
> While making t hat edit, I noticed that the lines above it have:
> 
> git config --replace-all "remote.users/${new_pfx}.fetch"
> "+refs/users/${remote_id}/heads/*:refs/remotes/users/${new_pfx}/*"
> "refs/users/${remote_id}/heads/"
> git config --replace-all "remote.users/${new_pfx}.fetch"
> "+refs/users/${remote_id}/tags/*:refs/tags/users/${new_pfx}/*"
> "refs/users/${remote_id}/tags/"
> 
> That doesn't look right, because the second line will replace what was
> done by the first.

Really? isn't one working on heads and the other on tags?

All of this hunk seems related to legacy layouts as well:

+# Scan the existing settings to see if there are any we need to rewrite.
+vendors=$(git config --get-all "remote.${upstream}.fetch" "refs/vendors/" | sed
 -r "s:.*refs/vendors/([^/]+)/.*:\1:" | sort | uniq)
+url=$(git config --get "remote.${upstream}.url")
+pushurl=$(git config --get "remote.${upstream}.pushurl")
+for v in $vendors
+do
+echo "Migrating vendor $v to new remote vendors/$v"
+git config --unset-all "remote.${upstream}.fetch" "refs/vendors/$v/"
+git config --unset-all "remote.${upstream}.push" "refs/vendors/$v/"
+git config "remote.vendors/${v}.url" "${url}"
+if [ "x$pushurl" != "x" ]
+then
+   git config "remote.vendors/${v}.pushurl" "${pushurl}

Re: gcc-git-customization.sh error

[Richard Earnshaw (lists) via Gcc]

On 05/03/2025 13:10, Jonathan Wakely via Gcc wrote:
> While onboarding somebody today we noticed an error in the
> customization script if you use a non-default value for the local
> prefix.
> 
> I reproduced it with bash -x to show where it happens. In the output
> below I entered "jw" as the local prefix, instead of the default "me":
> 
> + echo 'Setting up tracking for personal namespace redi in remotes/users/jw'
> Setting up tracking for personal namespace redi in remotes/users/jw
> + git config remote.users/jw.url git+ssh://r...@gcc.gnu.org/git/gcc.git
> + '[' x '!=' x ']'
> + git config --replace-all remote.users/jw.fetch
> '+refs/users/redi/heads/*:refs/remotes/users/jw/*'
> refs/users/redi/heads/
> + git config --replace-all remote.users/jw.fetch
> '+refs/users/redi/tags/*:refs/tags/users/jw/*' refs/users/redi/tags/
> + git config --replace-all remote.users/jw.push
> 'refs/heads/jw/*:refs/users/redi/heads/*' refs/users/redi
> + '[' me '!=' jw -a me '!=' origin ']'
> + git config --remove-section remote.me
> fatal: no such section: remote.me
> + git config --unset-all remote.origin.fetch refs/users/redi/
> + git config --unset-all remote.origin.push refs/users/redi/
> + git fetch users/jw
> 
> The script finishes successfully, but because the last line that is
> printed out is "fatal: no such section: remote.me" it makes it look
> like it failed and exited. But it's only fatal to the 'git config'
> sub-process, not the script that the user is actually running.
> 
> Should we just add a 2>/dev/null redirect to that command, or do we
> want to check if it exists before trying to remove it? i.e.
> if git config get --regexp remote.me >/dev/null; then

You'd want to match ^remote.${old_pfx}, for safety. You could also use 'git 
config --get-regexp', but perhaps that's what you mean anyway.

>   git config --remove-section remote.me
> fi
> 
> Or should we just remove that part entirely?
> I doubt anybody used the original version of that script prior to
> January 2020, and hasn't updated to the new structure yet. See
> r10-6086-g24b178184f260a which introduced that part.

But this might be easier.  I agree, that was very much a transitional bit of 
code as we settled on our new workflows.

I'll trust your decision on this one.

R.

web page c++-status proposal revision updates

[Heiko Eißfeldt]

For some C++26 language features listed on 
https://gcc.gnu.org/projects/cxx-status.html

there are newer proposal revisions available:

Remove undefined behavior from lexing P2621R3 
constexpr structured bindings and references to constexpr variables P2686R5
constexpr exceptions P3068R6 

Oxford variadic comma P3176R1 


Removing deprecated array comparisons P2865R6 

Heiko



OpenPGP_0x6C5B5E2DE9D181E2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature