Re: Update bootstrap requirement to C++14?

[Florian Weimer via Gcc]

* Jason Merrill via Gcc:

> We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after
> support was stable in GCC 4.8.

Note that some documentation still says C++03, for example:

| The directories gcc, libcpp and fixincludes may use C++03. They may
| also use the long long type if the host C++ compiler supports
| it. These directories should use reasonably portable parts of C++03,
| so that it is possible to build GCC with C++ compilers other than GCC
| itself. If testing reveals that reasonably recent versions of non-GCC
| C++ compilers cannot compile GCC, then GCC code should be adjusted
| accordingly. (Avoiding unusual language constructs helps immensely.)
| Furthermore, these directories should also be compatible with C++11.



I think this is just out of date.

Thanks,
Florian

Editorconfig

[Jonathan Wakely via Gcc]

I've pushed .editorconfig files for the libstdc++-v3 sub-directory:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663071.html

As mentioned there, I'll experiment with similar files for the rest of
the tree. I will share those files and it would be helpful if people
who work on the rest of the tree could test them, because most of what
I do is isolated to the libstdc++-v3 dir!

b4 config

[Jonathan Wakely via Gcc]

As a reminder, I added .b4-config to the top-level, so that using the
kernel's b4 tool inside a GCC source tree will automatically use
inbox.sourceware.org and will submit mail to gcc-patc...@gcc.gnu.org

See https://b4.docs.kernel.org/en/latest/ for docs on how to use b4 to
work with patches in the inbox.sourceware.org archives.

I'll add this info to the wiki. (And the .editorconfig info, and git
commit signing info, and sourcehut info ...)

Gcc

[Matilda via Gcc]

Dear Gcc,



I'm checking if you're interested in acquiring the Members/Distribution list



·   New Mexico Chamber of Commerce  2024 (New Mexico, USA)

·1,000+ Contacts



I’m waiting for your response so i can let you know the price & more
information.

Regards,
Matilda – Business Executive



You can type "unsubscribe" if you do not want the marketing email.
[image: beacon]

Signing your git commits

[Jonathan Wakely via Gcc]

Git supports signing commits with a GPG key, and more recently (since
Git 2.34) also started supporting signing with an SSH key. The latter
is IMHO much easier to set up, because anybody who can push to the GCC
repo already has an SSH key configured.

To start signing your git commits, just enable commit.gpgsign (which
also enables signing with SSH, despite the name) and tell Git where to
find your public key. To use SSH keys instead of GPG, set
gpg.format=ssh. I suggest the ssh key you sign with should be the same
key that you use to push to gcc.gnu.org / sourceware.org

i.e.

git config --global gpg.format ssh
git config user.signingKey ~/.ssh/id_your_gcc_key.pub
git config commit.gpgsign true

More info online e.g.
https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html

You can see the signature on a signed commit using git log --show-signature e.g.

$ git log --show-signature origin/master | head -6
commit eb67e2396f3ee834bf3a8299f5b6d93ba82d3950
Good "git" signature for jwak...@redhat.com with RSA key
SHA256:8rFaYhDWn09c3vjsYIg2JE9aSpcxzTnCqajoKevrUUo
Author: Jonathan Wakely 
Date:   Mon Sep 16 10:04:40 2024

If a signature is not recognised you'll see something like this:

commit 323291c29c77e3214f4850129bb8a3d0d8da6a45
gpg: Signature made Wed 11 Sep 2024 22:53:40 BST
gpg:using RSA key E5E9554C5B7F774F55B28733BF63C1BC3FA43540
gpg: Can't check signature: No public key
Author: Martin Jambor 
Date:   Wed Sep 11 22:53:21 2024

This says it's signed, but by a key my machine doesn't know, maybe
because it's a GPG key and I have no GPG keychain? But somebody who
does know Martin's key would probably see this as a good signature.

For SSH keys, you can configure git to use a file of known keys, e.g.
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers
I have my own SSH public key in that file (see 'man ssh-keygen' or the
gitlab URL above for the format of that file) so git log shows my
signed commits in happy colours without a warning.

Because I've also uploaded my public key to github, when you view the
commit there (in any fork of the GCC repo) it shows as "verified" e.g.
in the unofficial mirror:
https://github.com/gcc-mirror/gcc/commit/eb67e2396f3ee834bf3a8299f5b6d93ba82d3950

Re: Signing your git commits

[Richard Biener via Gcc]

On Mon, Sep 16, 2024 at 1:37 PM Jonathan Wakely via Gcc  wrote:
>
> Git supports signing commits with a GPG key, and more recently (since
> Git 2.34) also started supporting signing with an SSH key. The latter
> is IMHO much easier to set up, because anybody who can push to the GCC
> repo already has an SSH key configured.
>
> To start signing your git commits, just enable commit.gpgsign (which
> also enables signing with SSH, despite the name) and tell Git where to
> find your public key. To use SSH keys instead of GPG, set
> gpg.format=ssh. I suggest the ssh key you sign with should be the same
> key that you use to push to gcc.gnu.org / sourceware.org
>
> i.e.
>
> git config --global gpg.format ssh
> git config user.signingKey ~/.ssh/id_your_gcc_key.pub
> git config commit.gpgsign true
>
> More info online e.g.
> https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html

What is the benefit of having a SSH signature in addition to
sourceware verifying
the SSA key upon commit?

Richard.

> You can see the signature on a signed commit using git log --show-signature 
> e.g.
>
> $ git log --show-signature origin/master | head -6
> commit eb67e2396f3ee834bf3a8299f5b6d93ba82d3950
> Good "git" signature for jwak...@redhat.com with RSA key
> SHA256:8rFaYhDWn09c3vjsYIg2JE9aSpcxzTnCqajoKevrUUo
> Author: Jonathan Wakely 
> Date:   Mon Sep 16 10:04:40 2024
>
> If a signature is not recognised you'll see something like this:
>
> commit 323291c29c77e3214f4850129bb8a3d0d8da6a45
> gpg: Signature made Wed 11 Sep 2024 22:53:40 BST
> gpg:using RSA key E5E9554C5B7F774F55B28733BF63C1BC3FA43540
> gpg: Can't check signature: No public key
> Author: Martin Jambor 
> Date:   Wed Sep 11 22:53:21 2024
>
> This says it's signed, but by a key my machine doesn't know, maybe
> because it's a GPG key and I have no GPG keychain? But somebody who
> does know Martin's key would probably see this as a good signature.
>
> For SSH keys, you can configure git to use a file of known keys, e.g.
> git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers
> I have my own SSH public key in that file (see 'man ssh-keygen' or the
> gitlab URL above for the format of that file) so git log shows my
> signed commits in happy colours without a warning.
>
> Because I've also uploaded my public key to github, when you view the
> commit there (in any fork of the GCC repo) it shows as "verified" e.g.
> in the unofficial mirror:
> https://github.com/gcc-mirror/gcc/commit/eb67e2396f3ee834bf3a8299f5b6d93ba82d3950
>

Re: Signing your git commits

[Jonathan Wakely via Gcc]

On Mon, 16 Sept 2024 at 13:13, Richard Biener
 wrote:
>
> On Mon, Sep 16, 2024 at 1:37 PM Jonathan Wakely via Gcc  
> wrote:
> >
> > Git supports signing commits with a GPG key, and more recently (since
> > Git 2.34) also started supporting signing with an SSH key. The latter
> > is IMHO much easier to set up, because anybody who can push to the GCC
> > repo already has an SSH key configured.
> >
> > To start signing your git commits, just enable commit.gpgsign (which
> > also enables signing with SSH, despite the name) and tell Git where to
> > find your public key. To use SSH keys instead of GPG, set
> > gpg.format=ssh. I suggest the ssh key you sign with should be the same
> > key that you use to push to gcc.gnu.org / sourceware.org
> >
> > i.e.
> >
> > git config --global gpg.format ssh
> > git config user.signingKey ~/.ssh/id_your_gcc_key.pub
> > git config commit.gpgsign true
> >
> > More info online e.g.
> > https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html
>
> What is the benefit of having a SSH signature in addition to
> sourceware verifying
> the SSA key upon commit?

Great question! Most of the time they're the same person and the same
key, so the benefits aren't obvious.

One benefit is that the signature on the commit is recorded in the
repo itself, and can be inspected later. The SSH key used to do the
push is only used to authenticate your user to the server, but once
you're authenticated what goes into the repo is not associated with
that key. And I can authenticate to the server with my key, and then
push commits that "forge" your authorship, but setting my git config
user.email and user.name to pretend to be you.

My SSH key would let me push, but nothing verifies that the Author and
Committer fields match my "real" name, or match the SSH key's owner
(Git has to allow it so that people with write access to push patches
for people without write access). But if you routinely sign all your
own commits, then if I try to impersonate you the "forged" commit
wouldn't be signed by your key. Maybe not a big concern, because we
trust our committers to not do dumb or malicious things. But if
somebody does manage to compromise a sourceware account, they could
push something to our repo that has your name on it, and maybe people
wouldn't notice a problem ("oh, this commit was by Richi, I won't
check every line because I trust him to do good work and he knows what
he's doing"). If the commit isn't signed, and your other commits are
signed, that would be a red flag. Is this protecting against a real
threat? I dunno, but since it's easy to configure the signing once and
then forget about it, I decided to enable it as an extra layer of
integrity that takes no effort.

N.B. Frank also raised the topic of signing (and checking) last year:
https://sourceware.org/pipermail/overseers/2023q2/019288.html

Re: Resurrect PowrPC SPE port feasible?

[David Edelsohn via Gcc]

On Sun, Sep 15, 2024 at 7:29 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> the PowerPC SPE port was obsoleted in GCC 8. It was moved from the general
> PowerPC directory (gcc/config/rs6000) to a separate directory
> (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of
> maintenance.
>
> I am not a compiler expert, so I have no idea how much work it is to keep
> a back-end up to date. How much work would it be roughly to bring the
> PowerPC SPE port from GCC 8 to the current version? Is this in the range of
> person weeks, months, years?
>

Why do you wish to resurrect the port?

Thanks, David


>
> Kind regard, Sebastian
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>

Re: Resurrect PowrPC SPE port feasible?

[Sebastian Huber]

- Am 16. Sep 2024 um 15:02 schrieb David Edelsohn dje@gmail.com:

> On Sun, Sep 15, 2024 at 7:29 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
>> Hello,
>>
>> the PowerPC SPE port was obsoleted in GCC 8. It was moved from the general
>> PowerPC directory (gcc/config/rs6000) to a separate directory
>> (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of
>> maintenance.
>>
>> I am not a compiler expert, so I have no idea how much work it is to keep
>> a back-end up to date. How much work would it be roughly to bring the
>> PowerPC SPE port from GCC 8 to the current version? Is this in the range of
>> person weeks, months, years?
>>
> 
> Why do you wish to resurrect the port?

Some products using the PowerPC SPE are still in service for at least the next 
ten years. We probably have not enough funding to continuously maintain the 
port. I am looking for options to bring it back to GCC 15. Maybe this is not 
the right mailing list for this work.

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: Resurrect PowrPC SPE port feasible?

[David Edelsohn via Gcc]

On Mon, Sep 16, 2024 at 9:15 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> - Am 16. Sep 2024 um 15:02 schrieb David Edelsohn dje@gmail.com:
>
> > On Sun, Sep 15, 2024 at 7:29 PM Sebastian Huber <
> > sebastian.hu...@embedded-brains.de> wrote:
> >
> >> Hello,
> >>
> >> the PowerPC SPE port was obsoleted in GCC 8. It was moved from the
> general
> >> PowerPC directory (gcc/config/rs6000) to a separate directory
> >> (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of
> >> maintenance.
> >>
> >> I am not a compiler expert, so I have no idea how much work it is to
> keep
> >> a back-end up to date. How much work would it be roughly to bring the
> >> PowerPC SPE port from GCC 8 to the current version? Is this in the
> range of
> >> person weeks, months, years?
> >>
> >
> > Why do you wish to resurrect the port?
>
> Some products using the PowerPC SPE are still in service for at least the
> next ten years. We probably have not enough funding to continuously
> maintain the port. I am looking for options to bring it back to GCC 15


NXP did not have the financial motivation nor the will to maintain the
port.  NXP was free-riding on the IBM team.

Without analysis, it's difficult to estimate the amount of work.  A lot of
things in GCC between GCC 8 and GCC 15 -- both in the common parts of the
compiler and in the PowerPC port from which PowerPC SPE was split.  GCC 15
is an ambitious goal.


> Maybe this is not the right mailing list for this work.
>

This is an odd reply to a simple question.

David


>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>

Re: Resurrect PowrPC SPE port feasible?

[Sebastian Huber]

- Am 16. Sep 2024 um 15:24 schrieb David Edelsohn dje@gmail.com:

> On Mon, Sep 16, 2024 at 9:15 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
>> - Am 16. Sep 2024 um 15:02 schrieb David Edelsohn dje@gmail.com:
>>
>> > On Sun, Sep 15, 2024 at 7:29 PM Sebastian Huber <
>> > sebastian.hu...@embedded-brains.de> wrote:
>> >
>> >> Hello,
>> >>
>> >> the PowerPC SPE port was obsoleted in GCC 8. It was moved from the
>> general
>> >> PowerPC directory (gcc/config/rs6000) to a separate directory
>> >> (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of
>> >> maintenance.
>> >>
>> >> I am not a compiler expert, so I have no idea how much work it is to
>> keep
>> >> a back-end up to date. How much work would it be roughly to bring the
>> >> PowerPC SPE port from GCC 8 to the current version? Is this in the
>> range of
>> >> person weeks, months, years?
>> >>
>> >
>> > Why do you wish to resurrect the port?
>>
>> Some products using the PowerPC SPE are still in service for at least the
>> next ten years. We probably have not enough funding to continuously
>> maintain the port. I am looking for options to bring it back to GCC 15
> 
> 
> NXP did not have the financial motivation nor the will to maintain the
> port.  NXP was free-riding on the IBM team.

Yes, this was not really a great move from Freescale/NXP.

> 
> Without analysis, it's difficult to estimate the amount of work.  A lot of
> things in GCC between GCC 8 and GCC 15 -- both in the common parts of the
> compiler and in the PowerPC port from which PowerPC SPE was split.  GCC 15
> is an ambitious goal.

Thanks for your estimate, ambitious sounds not that good.

> 
> 
>> Maybe this is not the right mailing list for this work.
>>
> 
> This is an odd reply to a simple question.

Sorry, maybe my subject was a bit misleading. My intention was not to bring 
back the PowerPC SPE port as an official mainline GCC port. We definitely don't 
have the funding for this. I was hoping to get in contact with an individual or 
a company which may help us to get it from GCC 8 to a newer version.

> 
> David
> 
> 
>>
>> --
>> embedded brains GmbH & Co. KG
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: Resurrect PowrPC SPE port feasible?

[David Edelsohn via Gcc]

On Mon, Sep 16, 2024 at 9:40 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> - Am 16. Sep 2024 um 15:24 schrieb David Edelsohn dje@gmail.com:
>
> > On Mon, Sep 16, 2024 at 9:15 AM Sebastian Huber <
> > sebastian.hu...@embedded-brains.de> wrote:
> >
> >> - Am 16. Sep 2024 um 15:02 schrieb David Edelsohn dje@gmail.com
> :
> >>
> >> > On Sun, Sep 15, 2024 at 7:29 PM Sebastian Huber <
> >> > sebastian.hu...@embedded-brains.de> wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> the PowerPC SPE port was obsoleted in GCC 8. It was moved from the
> >> general
> >> >> PowerPC directory (gcc/config/rs6000) to a separate directory
> >> >> (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of
> >> >> maintenance.
> >> >>
> >> >> I am not a compiler expert, so I have no idea how much work it is to
> >> keep
> >> >> a back-end up to date. How much work would it be roughly to bring the
> >> >> PowerPC SPE port from GCC 8 to the current version? Is this in the
> >> range of
> >> >> person weeks, months, years?
> >> >>
> >> >
> >> > Why do you wish to resurrect the port?
> >>
> >> Some products using the PowerPC SPE are still in service for at least
> the
> >> next ten years. We probably have not enough funding to continuously
> >> maintain the port. I am looking for options to bring it back to GCC 15
> >
> >
> > NXP did not have the financial motivation nor the will to maintain the
> > port.  NXP was free-riding on the IBM team.
>
> Yes, this was not really a great move from Freescale/NXP.
>
> >
> > Without analysis, it's difficult to estimate the amount of work.  A lot
> of
> > things in GCC between GCC 8 and GCC 15 -- both in the common parts of the
> > compiler and in the PowerPC port from which PowerPC SPE was split.  GCC
> 15
> > is an ambitious goal.
>
> Thanks for your estimate, ambitious sounds not that good.
>
> >
> >
> >> Maybe this is not the right mailing list for this work.
> >>
> >
> > This is an odd reply to a simple question.
>
> Sorry, maybe my subject was a bit misleading. My intention was not to
> bring back the PowerPC SPE port as an official mainline GCC port. We
> definitely don't have the funding for this. I was hoping to get in contact
> with an individual or a company which may help us to get it from GCC 8 to a
> newer version.
>

If you wish to hire a company to perform this work, Baylibre is one place
to start.

You originally mentioned bringing it back and maintaining it.  Restoring it
without maintaining it in the FSF GCC repository increases the burden
because no other maintainers can try to test it, can help with regressions,
can check for use of internal APIs when making global changes, or can apply
global changes to the port.

David


>
> >
> > David
> >
> >
> >>
> >> --
> >> embedded brains GmbH & Co. KG
> >> Herr Sebastian HUBER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: sebastian.hu...@embedded-brains.de
> >> phone: +49-89-18 94 741 - 16
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>

Re: Signing your git commits

[Paul Koning via Gcc]

> On Sep 16, 2024, at 8:13 AM, Richard Biener via Gcc  wrote:
> 
> On Mon, Sep 16, 2024 at 1:37 PM Jonathan Wakely via Gcc  
> wrote:
>> 
>> Git supports signing commits with a GPG key, and more recently (since
>> Git 2.34) also started supporting signing with an SSH key. The latter
>> is IMHO much easier to set up, because anybody who can push to the GCC
>> repo already has an SSH key configured.
>> 
>> To start signing your git commits, just enable commit.gpgsign (which
>> also enables signing with SSH, despite the name) and tell Git where to
>> find your public key. To use SSH keys instead of GPG, set
>> gpg.format=ssh. I suggest the ssh key you sign with should be the same
>> key that you use to push to gcc.gnu.org / sourceware.org
>> 
>> i.e.
>> 
>> git config --global gpg.format ssh
>> git config user.signingKey ~/.ssh/id_your_gcc_key.pub
>> git config commit.gpgsign true
>> 
>> More info online e.g.
>> https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html
> 
> What is the benefit of having a SSH signature in addition to
> sourceware verifying
> the SSA key upon commit?
> 
> Richard.

I was wondering the same.  PGP/GPG has a public key infrastructure (the Web of 
Trust and the PGP key servers).  PGP signatures are valuable because anyone can 
check them, given a published public key -- which is the intended use of PGP.

SSH key pairs are authentication keys, but they aren't interesting as signing 
keys unless they are backed up by a public key 
publication/distribution/authentication scheme similar to the PGP web of trust 
(or, similar but different, the CA infrastructure of X.509 keys).

paul

Re: Signing your git commits

[Richard Biener via Gcc]

> Am 16.09.2024 um 14:45 schrieb Jonathan Wakely :
> 
> On Mon, 16 Sept 2024 at 13:13, Richard Biener
>  wrote:
>> 
>>> On Mon, Sep 16, 2024 at 1:37 PM Jonathan Wakely via Gcc  
>>> wrote:
>>> 
>>> Git supports signing commits with a GPG key, and more recently (since
>>> Git 2.34) also started supporting signing with an SSH key. The latter
>>> is IMHO much easier to set up, because anybody who can push to the GCC
>>> repo already has an SSH key configured.
>>> 
>>> To start signing your git commits, just enable commit.gpgsign (which
>>> also enables signing with SSH, despite the name) and tell Git where to
>>> find your public key. To use SSH keys instead of GPG, set
>>> gpg.format=ssh. I suggest the ssh key you sign with should be the same
>>> key that you use to push to gcc.gnu.org / sourceware.org
>>> 
>>> i.e.
>>> 
>>> git config --global gpg.format ssh
>>> git config user.signingKey ~/.ssh/id_your_gcc_key.pub
>>> git config commit.gpgsign true
>>> 
>>> More info online e.g.
>>> https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html
>> 
>> What is the benefit of having a SSH signature in addition to
>> sourceware verifying
>> the SSA key upon commit?
> 
> Great question! Most of the time they're the same person and the same
> key, so the benefits aren't obvious.
> 
> One benefit is that the signature on the commit is recorded in the
> repo itself, and can be inspected later. The SSH key used to do the
> push is only used to authenticate your user to the server, but once
> you're authenticated what goes into the repo is not associated with
> that key. And I can authenticate to the server with my key, and then
> push commits that "forge" your authorship, but setting my git config
> user.email and user.name to pretend to be you.

I think that particular hole could be closed by verifying the commit on the 
server.  At least committer should match the SSH key account owner (we’d have 
to allow some or a configured identity of course, not just x...@gcc.gnu.org).  
The author can be different when pushing for somebody else.

I was thinking that if my SSH key is compromised signing the commit with it 
doesn’t help.  Signing with a GPG key on the other hand would mean we have a 
second factor.

Richard 

> My SSH key would let me push, but nothing verifies that the Author and
> Committer fields match my "real" name, or match the SSH key's owner
> (Git has to allow it so that people with write access to push patches
> for people without write access). But if you routinely sign all your
> own commits, then if I try to impersonate you the "forged" commit
> wouldn't be signed by your key. Maybe not a big concern, because we
> trust our committers to not do dumb or malicious things. But if
> somebody does manage to compromise a sourceware account, they could
> push something to our repo that has your name on it, and maybe people
> wouldn't notice a problem ("oh, this commit was by Richi, I won't
> check every line because I trust him to do good work and he knows what
> he's doing"). If the commit isn't signed, and your other commits are
> signed, that would be a red flag. Is this protecting against a real
> threat? I dunno, but since it's easy to configure the signing once and
> then forget about it, I decided to enable it as an extra layer of
> integrity that takes no effort.
> 
> N.B. Frank also raised the topic of signing (and checking) last year:
> https://sourceware.org/pipermail/overseers/2023q2/019288.html
> 

Re: LTO progress indicator

[David Malcolm via Gcc]

On Sun, 2024-09-15 at 15:20 +0330, Ghorban M. Tavakoly via Gcc wrote:
> Hi
> 
> On Sun, Sep 15, 2024 at 11:59 AM Jan Hubicka  wrote:
> 
> > > On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
> > >  wrote:
> > > > 
> > > > > > Is there any change to have some LTO progress indicator
> > > > > > information
> > in
> > > > upstream GCC output? Do I need to report a bug?
> > > > Is there any chance ... (sorry for typo)
> > > 
> > > You can add -Q to the command line which makes GCC output some
> > > sort
> > > of progress indication.  Otherwise no - we do not really know how
> > > long a
> > > compile will take so a true progress indicator isn't possible.
> > 
> > For ltrans we do make estimate used by partitioning, so for large
> > projects that consits of many functions we may be able to do some
> > sort
> > of progress info on ltrans stage.
> > 
> > But indeed, when waiting for large copmiles, I use -Q to make
> > myself
> > entertained :)
> > 
> Actually my script on the first email creates a progressbar from
> /tmp/*ltrans* files.


FWIW there's an RFE in our bugzilla here:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
that captures some ideas about progress bars and "why is the compiler
taking so long?"  (I just added some more)

Dave

Re: LTO progress indicator

[Ghorban M. Tavakoly via Gcc]

Thank you for the BZ link. Actually my problem was configuring GCC build
with
--with-build-config=bootstrap-lto and --enable-lto. I'm researching
compiler theory (reading the Dragon book now) and I would like to contribute
to our
lovely compiler(s), specially gfortran.

On Mon, Sep 16, 2024 at 10:01 PM David Malcolm  wrote:

> On Sun, 2024-09-15 at 15:20 +0330, Ghorban M. Tavakoly via Gcc wrote:
> > Hi
> >
> > On Sun, Sep 15, 2024 at 11:59 AM Jan Hubicka  wrote:
> >
> > > > On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
> > > >  wrote:
> > > > >
> > > > > > > Is there any change to have some LTO progress indicator
> > > > > > > information
> > > in
> > > > > upstream GCC output? Do I need to report a bug?
> > > > > Is there any chance ... (sorry for typo)
> > > >
> > > > You can add -Q to the command line which makes GCC output some
> > > > sort
> > > > of progress indication.  Otherwise no - we do not really know how
> > > > long a
> > > > compile will take so a true progress indicator isn't possible.
> > >
> > > For ltrans we do make estimate used by partitioning, so for large
> > > projects that consits of many functions we may be able to do some
> > > sort
> > > of progress info on ltrans stage.
> > >
> > > But indeed, when waiting for large copmiles, I use -Q to make
> > > myself
> > > entertained :)
> > >
> > Actually my script on the first email creates a progressbar from
> > /tmp/*ltrans* files.
>
>
> FWIW there's an RFE in our bugzilla here:
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
> that captures some ideas about progress bars and "why is the compiler
> taking so long?"  (I just added some more)
>
> Dave
>
>

Re: gcc-15-20240915 is now available

[Alain Mosnier]

On Sun Sep 15 22:38:20 GMT 2024, GCC Administrator wrote:

> When a particular snapshot is ready for public consumption the LATEST-15
> link is updated

I'm new here. Where do I find the LATEST-15 link? Can I "safely" use the 
snapshot after the email I am replying to has been sent?


Thanks in advance,

Best regards,

Alain Mosnier

Re: gcc-15-20240915 is now available

[Alain Mosnier]

On 2024-09-16 23:54, Alain Mosnier wrote:

On Sun Sep 15 22:38:20 GMT 2024, GCC Administrator wrote:

> When a particular snapshot is ready for public consumption the 
LATEST-15

> link is updated

I'm new here. Where do I find the LATEST-15 link? Can I "safely" use 
the snapshot after the email I am replying to has been sent?


Answering my own question: the link can be found on the mirrors. E.g., 
at the time of writing: 
https://ftp.gwdg.de/pub/misc/gcc/snapshots/LATEST-15/.


Best regards,

Alain Mosnier

Re: gcc-15-20240915 is now available

[Jonathan Wakely via Gcc]

On Mon, 16 Sept 2024, 23:40 Alain Mosnier,  wrote:

> On 2024-09-16 23:54, Alain Mosnier wrote:
> > On Sun Sep 15 22:38:20 GMT 2024, GCC Administrator wrote:
> >
> > > When a particular snapshot is ready for public consumption the
> > LATEST-15
> > > link is updated
> >
> > I'm new here. Where do I find the LATEST-15 link? Can I "safely" use
> > the snapshot after the email I am replying to has been sent?
>
> Answering my own question: the link can be found on the mirrors. E.g.,
> at the time of writing:
> https://ftp.gwdg.de/pub/misc/gcc/snapshots/LATEST-15/.
>

And you can always use that link, the text you quoted just means it might
still point to last week's snapshot until the new one is uploaded.


>

Re: gcc-15-20240915 is now available

[Alain Mosnier]

On 2024-09-17 01:17, Jonathan Wakely via Gcc wrote:

On Mon, 16 Sept 2024, 23:40 Alain Mosnier,  wrote:


On 2024-09-16 23:54, Alain Mosnier wrote:

On Sun Sep 15 22:38:20 GMT 2024, GCC Administrator wrote:


When a particular snapshot is ready for public consumption the

LATEST-15

link is updated

I'm new here. Where do I find the LATEST-15 link? Can I "safely" use
the snapshot after the email I am replying to has been sent?

Answering my own question: the link can be found on the mirrors. E.g.,
at the time of writing:
https://ftp.gwdg.de/pub/misc/gcc/snapshots/LATEST-15/.


And you can always use that link, the text you quoted just means it might
still point to last week's snapshot until the new one is uploaded.
Thanks Jonathan. That's how I interpreted it initially, I just had not 
found the link. Everything is perfectly clear now. :-)