Re: Sourceware @ Conservancy - Year One

[Mark Wielaard]

Hi Maxim,

On Thu, May 30, 2024 at 12:18:38PM +0400, Maxim Kuvyrkov via Overseers wrote:
> > On May 29, 2024, at 23:02, Mark Wielaard  wrote:
> > And a special thanks to ARM who have been using
> > https://patchwork.sourceware.org/ to provide a pre-commit testing
> > service for various projects.
> 
> Thanks for the great update!
> 
> Minor nitpick: pre-commit testing for AArch64 and AArch32
> architectures is provided by Linaro Toolchain Working Group (Linaro
> TCWG).

Sorry for getting the credit wrong. Proper credit is important. And in
this case I really should have known. All pre-commit emails start with
[Linaro-TCWG-CI]. I did think about just mentioning the individuals
who made things happen. But then getting individual names wrong is
even worse than getting corporation names wrong...

Thanks Maxim for making the Linaro Toolchain Working Group pre-commit
testing for AArch64 and AArch32 happen!

Cheers,

Mark

Re: [committed v2 0/2] VAX: Fix issues with FP format option documentation

[Mark Wielaard]

Hi Maciej (Hi David, added to CC),

On Mon, 2024-05-27 at 05:19 +0100, Maciej W. Rozycki wrote:
>  As reported in PR target/79646 and fixed by a change proposed by Abe we 
> have a couple of issues with the descriptions of the VAX floating-point 
> format options in the option definition file.  Additionally most of these 
> options are not documented in the manual.
> 
>  This mini patch series addresses these issues, including Abe's change, 
> slightly updated, and my new change.  See individual change descriptions 
> for details.
> 
>  Verified by inspecting output produced by `vax-netbsdelf-gcc -v --help' 
> and by eyeballing `gcc.info' and `gcc.pdf' files produced.  Committed.

This broke the gcc-autoregen checker because the
gcc/config/vax/vax.opt.urls file wasn't regenerated:
https://builder.sourceware.org/buildbot/#/builders/269/builds/5347

Producing the following diff:

diff --git a/gcc/config/vax/vax.opt.urls b/gcc/config/vax/vax.opt.urls
index c6b1c418b61..ca78b31dd4c 100644
--- a/gcc/config/vax/vax.opt.urls
+++ b/gcc/config/vax/vax.opt.urls
@@ -1,7 +1,13 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/vax/vax.opt and 
generated HTML
 
+; skipping UrlSuffix for 'md' due to finding no URLs
+
+; skipping UrlSuffix for 'md-float' due to finding no URLs
+
 ; skipping UrlSuffix for 'mg' due to finding no URLs
 
+; skipping UrlSuffix for 'mg-float' due to finding no URLs
+
 ; skipping UrlSuffix for 'mgnu' due to finding no URLs
 
 ; skipping UrlSuffix for 'munix' due to finding no URLs

I am not completely clear on why though. Since it seems you actually
did add documentation for exactly these options.

David, should the above diff just be checked in, or do we need to
investigate why the URLs weren't found?

Cheers,

Mark

Re: FSF copyright assignment

[Mark Wielaard]

Hi Seyed,

On Sat, May 25, 2024 at 11:34:53AM +0100, Seyed Sajad Kahani via Gcc wrote:
> I am writing to request the FSF copyright assignment forms, as they
> are a legal requirement for contributing to GCC.

At https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright
you'll find the request-assign.changes file which you can sent to
ass...@gnu.org who will help you get the correct copyright assignment
and company disclaimer forms.

Cheers,

Mark

Re: Wrong date

[Mark Wielaard]

Hi Tony,

On Wed, May 22, 2024 at 06:58:34PM -0500, tony.antonucci--- via Gcc wrote:
> This was for the gcc 14.1 release.
> Sorry I omitted that in the first email.

Thanks for the notice, this has been fixed now:
https://gcc.gnu.org/cgit/gcc-wwwdocs/commit/?id=465817d0e0a96a1e1722a67383183dbec95ab21f

> > On May 22, 2024, at 6:57 PM, tony.antonu...@gmail.com wrote:
> > 
> > The date on the cool text graph of gcc releases is incorrect.
> > It says 2023, and should be 2024.
> > 
> > Tony

Re: [COMMITTED] Regenerate riscv.opt.urls and i386.opt.urls

[Mark Wielaard]

Hi,

On Mon, 2024-05-20 at 12:37 -0400, David Malcolm wrote:
> On Mon, 2024-05-20 at 16:19 +, Jiang, Haochen wrote:
> > Thanks for your help! I haven't noticed this file is newly added to
> > GCC.
> > I suppose that is why the buildbot is reporting something the whole
> > afternoon for me.
> > 
> > So just for confirm, does that mean we will always need to run
> > gcc/regenerate-opt-urls.py after adding or removing options in GCC?
> > My current understanding is yes.
> 
> Yes please (and make sure you've got a clean build of the HTML docs
> with the new options added when you do)
> 
> Though if you forget, the only problem will be some missing URLs at the
> command line, and complaints from the CI.

Also note that the CI will provide a diff that is most likely the
correct patch you need to apply. e.g. for the last issue:
https://builder.sourceware.org/buildbot/#/builders/269/builds/5194/steps/8/logs/stdio

It is still recommended you run regenerate-opt-urls yourself. But if
you just quickly want to shut up the buildbot then you cannot really go
wrong with just applying the diff it generated for you.

Cheers,

Mark

[COMMITTED] Regenerate riscv.opt.urls and i386.opt.urls

[Mark Wielaard]

risc-v added an -mfence-tso option. i386 removed Xeon Phi ISA support
options. But the opt.urls files weren't regenerated.

Fixes: a6114c2a6911 ("RISC-V: Implement -m{,no}fence-tso")
Fixes: e1a7e2c54d52 ("i386: Remove Xeon Phi ISA support")

gcc/ChangeLog:

* config/riscv/riscv.opt.urls: Regenerate.
* config/i386/i386.opt.urls: Likewise.
---
 gcc/config/i386/i386.opt.urls   | 15 ---
 gcc/config/riscv/riscv.opt.urls |  3 +++
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/gcc/config/i386/i386.opt.urls b/gcc/config/i386/i386.opt.urls
index 81c5bb9a9270..40e8a8449367 100644
--- a/gcc/config/i386/i386.opt.urls
+++ b/gcc/config/i386/i386.opt.urls
@@ -238,12 +238,6 @@ UrlSuffix(gcc/x86-Options.html#index-mavx2)
 mavx512f
 UrlSuffix(gcc/x86-Options.html#index-mavx512f)
 
-mavx512pf
-UrlSuffix(gcc/x86-Options.html#index-mavx512pf)
-
-mavx512er
-UrlSuffix(gcc/x86-Options.html#index-mavx512er)
-
 mavx512cd
 UrlSuffix(gcc/x86-Options.html#index-mavx512cd)
 
@@ -262,12 +256,6 @@ UrlSuffix(gcc/x86-Options.html#index-mavx512ifma)
 mavx512vbmi
 UrlSuffix(gcc/x86-Options.html#index-mavx512vbmi)
 
-mavx5124fmaps
-UrlSuffix(gcc/x86-Options.html#index-mavx5124fmaps)
-
-mavx5124vnniw
-UrlSuffix(gcc/x86-Options.html#index-mavx5124vnniw)
-
 mavx512vpopcntdq
 UrlSuffix(gcc/x86-Options.html#index-mavx512vpopcntdq)
 
@@ -409,9 +397,6 @@ UrlSuffix(gcc/x86-Options.html#index-mrdrnd)
 mf16c
 UrlSuffix(gcc/x86-Options.html#index-mf16c)
 
-mprefetchwt1
-UrlSuffix(gcc/x86-Options.html#index-mprefetchwt1)
-
 mfentry
 UrlSuffix(gcc/x86-Options.html#index-mfentry)
 
diff --git a/gcc/config/riscv/riscv.opt.urls b/gcc/config/riscv/riscv.opt.urls
index 2f01ae5d6271..e02ef3ee3dd9 100644
--- a/gcc/config/riscv/riscv.opt.urls
+++ b/gcc/config/riscv/riscv.opt.urls
@@ -91,3 +91,6 @@ UrlSuffix(gcc/RISC-V-Options.html#index-minline-strlen)
 
 ; skipping UrlSuffix for 'mtls-dialect=' due to finding no URLs
 
+mfence-tso
+UrlSuffix(gcc/RISC-V-Options.html#index-mfence-tso)
+
-- 
2.45.1

[gcc r15-692] Regenerate riscv.opt.urls and i386.opt.urls

[Mark Wielaard via Gcc-cvs]

https://gcc.gnu.org/g:591bc70139d898c06b1d605ff4fed591ffd2e2e7

commit r15-692-g591bc70139d898c06b1d605ff4fed591ffd2e2e7
Author: Mark Wielaard 
Date:   Mon May 20 13:13:02 2024 +0200

Regenerate riscv.opt.urls and i386.opt.urls

risc-v added an -mfence-tso option. i386 removed Xeon Phi ISA support
options. But the opt.urls files weren't regenerated.

Fixes: a6114c2a6911 ("RISC-V: Implement -m{,no}fence-tso")
Fixes: e1a7e2c54d52 ("i386: Remove Xeon Phi ISA support")

gcc/ChangeLog:

* config/riscv/riscv.opt.urls: Regenerate.
* config/i386/i386.opt.urls: Likewise.

Diff:
---
 gcc/config/i386/i386.opt.urls   | 15 ---
 gcc/config/riscv/riscv.opt.urls |  3 +++
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/gcc/config/i386/i386.opt.urls b/gcc/config/i386/i386.opt.urls
index 81c5bb9a9270..40e8a8449367 100644
--- a/gcc/config/i386/i386.opt.urls
+++ b/gcc/config/i386/i386.opt.urls
@@ -238,12 +238,6 @@ UrlSuffix(gcc/x86-Options.html#index-mavx2)
 mavx512f
 UrlSuffix(gcc/x86-Options.html#index-mavx512f)
 
-mavx512pf
-UrlSuffix(gcc/x86-Options.html#index-mavx512pf)
-
-mavx512er
-UrlSuffix(gcc/x86-Options.html#index-mavx512er)
-
 mavx512cd
 UrlSuffix(gcc/x86-Options.html#index-mavx512cd)
 
@@ -262,12 +256,6 @@ UrlSuffix(gcc/x86-Options.html#index-mavx512ifma)
 mavx512vbmi
 UrlSuffix(gcc/x86-Options.html#index-mavx512vbmi)
 
-mavx5124fmaps
-UrlSuffix(gcc/x86-Options.html#index-mavx5124fmaps)
-
-mavx5124vnniw
-UrlSuffix(gcc/x86-Options.html#index-mavx5124vnniw)
-
 mavx512vpopcntdq
 UrlSuffix(gcc/x86-Options.html#index-mavx512vpopcntdq)
 
@@ -409,9 +397,6 @@ UrlSuffix(gcc/x86-Options.html#index-mrdrnd)
 mf16c
 UrlSuffix(gcc/x86-Options.html#index-mf16c)
 
-mprefetchwt1
-UrlSuffix(gcc/x86-Options.html#index-mprefetchwt1)
-
 mfentry
 UrlSuffix(gcc/x86-Options.html#index-mfentry)
 
diff --git a/gcc/config/riscv/riscv.opt.urls b/gcc/config/riscv/riscv.opt.urls
index 2f01ae5d6271..e02ef3ee3dd9 100644
--- a/gcc/config/riscv/riscv.opt.urls
+++ b/gcc/config/riscv/riscv.opt.urls
@@ -91,3 +91,6 @@ UrlSuffix(gcc/RISC-V-Options.html#index-minline-strlen)
 
 ; skipping UrlSuffix for 'mtls-dialect=' due to finding no URLs
 
+mfence-tso
+UrlSuffix(gcc/RISC-V-Options.html#index-mfence-tso)
+

Re: [EXTERNAL] [COMMITTED] Regenerate cygming.opt.urls and mingw.opt.urls

[Mark Wielaard]

Hi Evgeny,

Adding David to the CC, who might know the details.

On Mon, May 13, 2024 at 08:44:12AM +, Evgeny Karpov wrote:
> Sunday, May 12, 2024
>
> Thank you for reviewing our changes related to the refactoring of
> extracting the MinGW implementation from ix64.
>
> It was expected to move the MinGW-related files without changes in
> this commit ("Reuse MinGW from i386 for AArch64") and apply the
> renaming in a follow-up commit, which has been done in 'Rename "x86
> Windows Options" to "Cygwin and MinGW Options"'.
>
> The script to update opt.urls files has been used.
> 
> > diff --git a/gcc/config/mingw/cygming.opt.urls
> > b/gcc/config/mingw/cygming.opt.urls
> > index c624e22e4427..af11c4997609 100644
> > --- a/gcc/config/mingw/cygming.opt.urls
> > +++ b/gcc/config/mingw/cygming.opt.urls
> > @@ -1,4 +1,4 @@
> 
> > -; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/cygming.opt
> > and generated HTML
> > +; Autogenerated by regenerate-opt-urls.py from
> > +gcc/config/mingw/cygming.opt and generated HTML
> 
> I am not sure why this comment has not been updated. Is it critical
> or it could be updated next time when it is needed?

Odd that the script didn't update this comment, it really should have.
It might be that running the script through make regenerate-opt-urls
inside the gcc build subdir invokes regenerate-opt-urls.py slightly
differently so that this line is updated.

> >  mconsole
> >  UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mconsole)
> > @@ -9,9 +9,8 @@ UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-
> > mdll)
> >  mnop-fun-dllimport
> >  UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-dllimport)
> > 
> > -; skipping UrlSuffix for 'mthreads' due to multiple URLs:
> > -;   duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1'
> > -;   duplicate: 'gcc/x86-Options.html#index-mthreads'
> > +mthreads
> > +UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
> 
> mthreads has the same issue before applying changes. Has something been 
> changed recently?
> This is the change in patch series in 'Rename "x86 Windows Options" to 
> "Cygwin and MinGW Options"' commit.
> 
> ; skipping UrlSuffix for 'mthreads' due to multiple URLs:
> +;   duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1'
>  ;   duplicate: 'gcc/x86-Options.html#index-mthreads'
> -;   duplicate: 'gcc/x86-Windows-Options.html#index-mthreads-1'

Again, it might be caused by invoking the script by hand vs with make
regenerate-opt-urls.py. I believe with the make option it will
renumber the suffixes making sure the urls are unique.

BTW. There is a CI buildbot that tries to regenerate all generated
files, which is how I spotted this:
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
(It should also sent email to the author of the patch on failure.)

Cheers,

Mark

[COMMITTED] Regenerate cygming.opt.urls and mingw.opt.urls

[Mark Wielaard]

The new cygming.opt.urls and mingw.opt.urls in the
gcc/config/mingw/cygming.opt.urls directory need to generated by make
regenerate-opt-urls in the gcc subdirectory. They still contained
references to the gcc/config/i386 directory from which they were
copied.

Fixes: 1f05dfc131c7 ("Reuse MinGW from i386 for AArch64")
Fixes: e8d003736e6c ("Rename "x86 Windows Options" to "Cygwin and MinGW 
Options"")

gcc/ChangeLog:

* config/mingw/cygming.opt.urls: Regenerate.
* config/mingw/mingw.opt.urls: Likewise.
---
 gcc/config/mingw/cygming.opt.urls | 7 +++
 gcc/config/mingw/mingw.opt.urls   | 2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/gcc/config/mingw/cygming.opt.urls 
b/gcc/config/mingw/cygming.opt.urls
index c624e22e4427..af11c4997609 100644
--- a/gcc/config/mingw/cygming.opt.urls
+++ b/gcc/config/mingw/cygming.opt.urls
@@ -1,4 +1,4 @@
-; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/cygming.opt and 
generated HTML
+; Autogenerated by regenerate-opt-urls.py from gcc/config/mingw/cygming.opt 
and generated HTML
 
 mconsole
 UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mconsole)
@@ -9,9 +9,8 @@ UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mdll)
 mnop-fun-dllimport
 UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-dllimport)
 
-; skipping UrlSuffix for 'mthreads' due to multiple URLs:
-;   duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1'
-;   duplicate: 'gcc/x86-Options.html#index-mthreads'
+mthreads
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
 
 mwin32
 UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwin32)
diff --git a/gcc/config/mingw/mingw.opt.urls b/gcc/config/mingw/mingw.opt.urls
index f8ee5be6a535..40fb086606b2 100644
--- a/gcc/config/mingw/mingw.opt.urls
+++ b/gcc/config/mingw/mingw.opt.urls
@@ -1,4 +1,4 @@
-; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw.opt and 
generated HTML
+; Autogenerated by regenerate-opt-urls.py from gcc/config/mingw/mingw.opt and 
generated HTML
 
 mcrtdll=
 UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mcrtdll)
-- 
2.39.3

[gcc r15-387] Regenerate cygming.opt.urls and mingw.opt.urls

[Mark Wielaard via Gcc-cvs]

https://gcc.gnu.org/g:a18c83b45c64ac7870f6e2acb0f23ae6090ed9cd

commit r15-387-ga18c83b45c64ac7870f6e2acb0f23ae6090ed9cd
Author: Mark Wielaard 
Date:   Sun May 12 14:37:58 2024 +0200

Regenerate cygming.opt.urls and mingw.opt.urls

The new cygming.opt.urls and mingw.opt.urls in the
gcc/config/mingw/cygming.opt.urls directory need to generated by make
regenerate-opt-urls in the gcc subdirectory. They still contained
references to the gcc/config/i386 directory from which they were
copied.

Fixes: 1f05dfc131c7 ("Reuse MinGW from i386 for AArch64")
Fixes: e8d003736e6c ("Rename "x86 Windows Options" to "Cygwin and MinGW 
Options"")

gcc/ChangeLog:

* config/mingw/cygming.opt.urls: Regenerate.
* config/mingw/mingw.opt.urls: Likewise.

Diff:
---
 gcc/config/mingw/cygming.opt.urls | 7 +++
 gcc/config/mingw/mingw.opt.urls   | 2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/gcc/config/mingw/cygming.opt.urls 
b/gcc/config/mingw/cygming.opt.urls
index c624e22e4427..af11c4997609 100644
--- a/gcc/config/mingw/cygming.opt.urls
+++ b/gcc/config/mingw/cygming.opt.urls
@@ -1,4 +1,4 @@
-; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/cygming.opt and 
generated HTML
+; Autogenerated by regenerate-opt-urls.py from gcc/config/mingw/cygming.opt 
and generated HTML
 
 mconsole
 UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mconsole)
@@ -9,9 +9,8 @@ UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mdll)
 mnop-fun-dllimport
 UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-dllimport)
 
-; skipping UrlSuffix for 'mthreads' due to multiple URLs:
-;   duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1'
-;   duplicate: 'gcc/x86-Options.html#index-mthreads'
+mthreads
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
 
 mwin32
 UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwin32)
diff --git a/gcc/config/mingw/mingw.opt.urls b/gcc/config/mingw/mingw.opt.urls
index f8ee5be6a535..40fb086606b2 100644
--- a/gcc/config/mingw/mingw.opt.urls
+++ b/gcc/config/mingw/mingw.opt.urls
@@ -1,4 +1,4 @@
-; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw.opt and 
generated HTML
+; Autogenerated by regenerate-opt-urls.py from gcc/config/mingw/mingw.opt and 
generated HTML
 
 mcrtdll=
 UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mcrtdll)

Sourceware Open Office, Friday 16:00 UTC

[Mark Wielaard]

Friday May 10, 16:00 UTC, irc.libera.chat #overseers
(Today in about 1 hour)

To get the right time in your local timezone:
$ date -d "Fri May 10 16:00:00 UTC 2024"

Lots of discussion topics:

- Sourceware 2024 - The Plan
https://inbox.sourceware.org/20240325095827.gi5...@gnu.wildebeest.org/

- Sourceware mitigating and preventing the next xz-backdoor
https://inbox.sourceware.org/20240401150617.gf19...@gnu.wildebeest.org/

Discussions are clearly still ongoing. But the Sourceware Project
Leadership Committee is already discussing which projects need (extra)
resources.

We also started the aging inactive users policy. Please let us know
your experiences.

Re: Updated Sourceware infrastructure plans

[Mark Wielaard]

Hi Jeff,

On Wed, 2024-05-01 at 15:38 -0600, Jeff Law wrote:
> What works well?  If you've wired up some CI bits, it's is extremely 
> useful to test an under development patch.  Develop, push a branch, 
> raise an MR.  At that point the CI system kicks in.  Subsequent pushes 
> to the branch trigger fresh CI runs.  This aspect I really like and if 
> you were to see internal flows, you'd see dev branches churning as a 
> patch gets iterated on.  It also has features like "when this passes CI, 
> automatically commit it", which we often use on the final patch 
> iteration if there was a nit of some kind.

Although not as sophisticated (there are no triggers, just reports),
builder.sourceware.org not only does normal CI runs, but does also
offer try-runs for various Sourceware projects (just binutils, gdb,
elfutils, libabigail and valgrind for now) when someone pushes to their
own users try-branch.

As the binutils wiki describes it:
https://sourceware.org/binutils/wiki/Buildbot

git checkout -b frob
hack, hack, hack... OK, looks good to submit
git commit -a -m "Awesome hack"
git push origin frob:users/username/try-frob
... wait for the emails to come in or watch buildbot try logs
or watch bunsen logs ...
Send in patches and mention what the try bot reported

This is pretty nice for developing patches that you aren't totally sure
yet are ready to submit.

And there is of course the Linaro buildbot that watches (and updates)
patchworks with results of various ARM systems. Which does something
similar but for already submitted (to the mailinglist) patches.

The idea is to provide something similar for GCC and RISC-V once we get
the larger Pioneer Box:
https://riscv.org/blog/2023/06/sophgo-donates-50-risc-v-motherboards-learn-more-about-the-pioneer-box/
But this has been postponed a few times now. Latest update (from about
a week ago) is: "The supplier has reached out to let us know that they
are still experiencing supply issues.  At the moment they are expecting
at least two months to get the hardware together."

Cheers,

Mark

Re: Updated Sourceware infrastructure plans

[Mark Wielaard]

Hi Jason,

On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote:
> On 5/1/24 12:15, Jeff Law wrote:
> >We're currently using patchwork to track patches tagged with
> >RISC-V.  We don't do much review with patchwork.  In that model
> >patchwork ultimately just adds overhead as I'm constantly trying
> >to figure out what patches have been integrated vs what are still
> >outstanding.
> >
> >Patchwork definitely isn't the answer IMHO.  Nor is gitlab MRs
> >which we use heavily internally.  But boy I want to get away from
> >email and to a pull request kind of flow.
> 
> Do you (or others) have any thoughts about GitLab FOSS?

The gitlab "community edition" still feels not very much "community".
We could run our own instance, but it will still be "open core" with
features missing to try to draw you towards the proprietary hosted
saas version. Also it seems to have way too much overhead. The focus
is clearly corporate developers where managers want assurances the
mandatory "pipelines" are executed and "workflows" followed exactly.

For now I am cleaning up Sergio's gerrit setup and upgrading it to the
latest version, so people can at least try it out. Although I must
admit that I seem to be the only Sourcewware PLC member that believes
this is very useful use of our resources. Even the biggest proponents
of gerrit seem to believe no project will actually adopt it. And on
irc there were some people really critical of the effort. It seems you
either love or really hate gerrit...

But the part that interests me most is the self-registration part that
Sergio setup. I believe we will need that for whatever system we end
up with to make it as easy to contribute as it is with email.
https://blog.sergiodj.net/posts/installing-gerrit-and-keycloak/

My personal favorite, if we really want a full "forge" would be
sourcehut. We already have mirrors of all projects at
https://sr.ht/~sourceware/ and there is a kind of sample "workflow"
(turning a "pull request" into an email thread) at
https://gnu.wildebeest.org/~mark/fsf-sourceware/presentation.html#slide18

At the moment though the only thing people seem to agree on is that
any system will be based on git. So the plan for now is to first setup
a larger git(olite) system so that every contributor (also those who
don't currently have commit access) can easily "post" their git
repo. This can then hopefully integrate with the systems we already
have setup (triggering builder CI, flag/match with patchwork/emails,
etc.) or any future "pull request" like system.

Cheers,

Mark

Re: Updated Sourceware infrastructure plans

[Mark Wielaard]

Hi Jonathan,

On Wed, May 01, 2024 at 08:38:26PM +0100, Jonathan Wakely wrote:
> On Wed, 1 May 2024 at 20:19, Jeff Law via Gcc  wrote:
> > We're currently using patchwork to track patches tagged with RISC-V.  We
> > don't do much review with patchwork.  In that model patchwork ultimately
> > just adds overhead as I'm constantly trying to figure out what patches
> > have been integrated vs what are still outstanding.
> 
> If patches sent by email exactly match what's committed, then the
> update_gcc_pw.sh script that I run will correctly update patchwork to
> say they're committed. I tend to only bother running that once a week,
> because it misses so many and so is of limited use. If we are now
> supposed to send generated files in the patches, and we discourage
> people from committing something close-but-not-identical to what they
> sent by email, then the script will do a better job of updating
> patchwork, and then we should look at running it automatically (not
> just when I think to run it manually).

See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997
We really should automate this. There are several people running
scripts by hand. The easiest would be to simply run it from a git
hook.  patchwork comes with a simple script that just calculates the
hash and pings patchwork, which can then mark the patch associated
with that hash as committed. If people really believe calculating a
hash is too much work from a git hook then we can also simply run it
from builder.sourceware.org. We already run a builder for each commit
anyway. It would just be one extra build step checking the commit
against patchwork.

Cheers,

Mark

Re: Updated Sourceware infrastructure plans

[Mark Wielaard]

Hi,

On Mon, Apr 22, 2024 at 11:51:00PM -0400, Jason Merrill wrote:
> On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey  wrote:
> > Jason> Someone mentioned earlier that gerrit was previously tried
> > Jason> unsuccessfully.
> >
> > We tried it and gdb and then abandoned it.  We tried to integrate it
> > into the traditional gdb development style, having it send email to
> > gdb-patches.  I found these somewhat hard to read and in the end we
> > agreed not to use it.
> >
> > I've come around again to thinking we should probably abandon email
> > instead.  For me the main benefit is that gerrit has patch tracking,
> > unlike our current system, where losing patches is fairly routine.
> 
> Indeed.  Though Patchwork is another option for patch tracking, that glibc
> seem to be having success with.

Patchworks works if you have people that like it and keep on top of
it. For elfutils Aaron and I are probably the only ones that use it,
but if we just go over it once a week it keeps being managable and
nobody else needs to care. That is also why it seems to work for
glibc. If you can carve out an hour a week going over the submitted
patches and delegate them then it is a really useful patch tracking
tool. Obviously that only works if the patch flow isn't overwhelming
to begin with...

I'll work with Sergio who setup the original gerrit instance to
upgrade it to the latest gerrit version so people try it out. One nice
thing he did was to automate self-service user registration. Although
that is one of the things I don't really like about it. As Tom said it
feels like gerrit is an all or nothing solution that has to be
mandated to be used and requires everybody to have a centralized
login. But if you do want that then how Sergio set it up is pretty
nice. It is just one more thing to monitor for spam accounts...

Cheers,

Mark

Re: Updated Sourceware infrastructure plans

[Mark Wielaard]

Hi Joseph,

On Thu, 2024-04-18 at 15:56 +, Joseph Myers wrote:
> On Thu, 18 Apr 2024, Mark Wielaard wrote:
> 
> > But we like to get more feedback on what people really think a
> > "pull-request" style framework should look like. We used to have a
> > gerrit setup which wasn't really popular. And we already have a
> > sourcehut mirror that can be used to turn your "pull-requests" into a
> > git send-email style submission (without having to setup any
> > email/smtp yourself): https://sr.ht/~sourceware/
> 
> The xz backdoor showed up one issue with some implementations of 
> pull-request systems: GitHub removed access to the repository, and with it 
> access to the past pull requests, so disrupting investigation into the 
> sequence of bad-faith contributions.

Agreed. I tried to analyze the valgrind issues after the fact (we
clearly missed them before, there were warning, but they were fixed so
quickly we didn't really look into them as we should have). And it was
a bit difficult because the github repository had disappeared. But
luckily the project did have a "real" git repo:
https://git.tukaani.org/
This obviously didn't contain any "pull requests" but I am not sure
they were used on the xz github mirror. Does github require pull
requests to keep around? What if someone closes/removes their own
fork/repo/account, do the commits transfer to the project?

>   I suggest that a basic principle for 
> such a system is that it should be *easy* to obtain and maintain a local 
> copy of the history of all pull requests.  That includes all versions of a 
> pull request, if it gets rebased, and all versions of comments, if the 
> system allows editing comments.

So in a somewhat crude form we now have that with our email workflow.
In theory every patch is posted and reviewed on one of the patches
mailinglists and the public-inbox instance at
https://inbox.sourceware.org/ allows you to git clone the whole archive
for local inspection.

>   A system that uses git as the source of 
> truth for all the pull request data and has refs through which all this 
> can be located (with reasonably straightforward, documented formats for 
> the data, not too closely tied to any particular implementation of a 
> pull-request system), so that a single clone --mirror has all the data, 
> might be suitable (people have worked on ensuring git scales well with 
> very large numbers of refs, which you'd probably get in such a system 
> storing all the data in git);

Yes, git is pretty nice for storing lots of variants of somewhat
identical sources/texts. But this also seems to imply that when we
offer a system to store "contributor" git trees/forks of projects to
easily create "pull requests" then we can never remove such users/forks
and must disallow rebasing any trees that have been "submitted".

That can probably be done, but it is different from what we now require
from user or devel branches in our git repos. Where we do allow users
to delete their branches and devel branches can be rebased. Should such
branches also become "immutable"?

Cheers,

Mark

Re: Sourceware mitigating and preventing the next xz-backdoor

[Mark Wielaard]

Hi Alejandro,

On Wed, Apr 10, 2024 at 06:30:42PM +0200, Alejandro Colomar wrote:
> It would also be interesting to require showing range-diffs between
> patch revisions.  They make it much more difficult to introduce a
> vulnerability after a reviewer has turned its mins into approving the
> patch.  Of course, the patch could go in if the submitter lies in the
> range-diff and the vuln is undetected, but then it can be verified a
> posteriory to prove that there was a lie.

Could you give an example of using git range-diff? How do you go from
v1 of a patch (series) to a v2? Normally when asked for changes to a
patch (series) I do an git rebase -i (on the local branch I used to
develop the feature/bug fix) and split/commit all requested changes
and then sent the new patches with git send-email again. But I guess
to use/combine that with git range-diffs I should start creating new
local branches for each patch (series) in development?

Thanks,

Mark

[COMMITTED] gcc-mingw don't enable rust

[Mark Wielaard]

gccrs now requires cargo to build
---
 builder/master.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builder/master.cfg b/builder/master.cfg
index c75b1622331f..97bf3703c019 100644
--- a/builder/master.cfg
+++ b/builder/master.cfg
@@ -3511,7 +3511,7 @@ gcc_mingw_configure_step = steps.Configure(
  '--disable-nls',
  '--without-included-gettext',
  '--disable-win32-registry',
- '--enable-languages=c,c++,fortran,rust',
+ '--enable-languages=c,c++,fortran',
  '--enable-threads=posix',
  '--with-sysroot=/usr/x86_64-w64-mingw32/sys-root',
  '--enable-libstdcxx-backtrace',
-- 
2.44.0

[COMMITTED] Regenerate c.opt.urls

[Mark Wielaard]

Fixes: df7bfdb7dbf2 ("c++: reference cast, conversion fn [PR113141]")

A new warning option -Wcast-user-defined was added to c.opt and
documented in doc/invoke.texi. But c.opt.urls wasn't regenerate.

gcc/c-family/ChangeLog:

* c.opt.urls: Regenerate.
---
 gcc/c-family/c.opt.urls | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls
index 631719863a5e..dd455d7c0dc7 100644
--- a/gcc/c-family/c.opt.urls
+++ b/gcc/c-family/c.opt.urls
@@ -208,6 +208,9 @@ 
UrlSuffix(gcc/Warning-Options.html#index-Wcast-function-type)
 Wcast-qual
 UrlSuffix(gcc/Warning-Options.html#index-Wcast-qual)
 
+Wcast-user-defined
+UrlSuffix(gcc/Warning-Options.html#index-Wcast-user-defined)
+
 Wcatch-value
 UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wcatch-value)
 
-- 
2.39.3

[gcc r14-9957] Regenerate c.opt.urls

[Mark Wielaard via Gcc-cvs]

https://gcc.gnu.org/g:a9d3b3caef87d76072c946145d21e7606b303e12

commit r14-9957-ga9d3b3caef87d76072c946145d21e7606b303e12
Author: Mark Wielaard 
Date:   Sat Apr 13 23:02:14 2024 +0200

Regenerate c.opt.urls

Fixes: df7bfdb7dbf2 ("c++: reference cast, conversion fn [PR113141]")

A new warning option -Wcast-user-defined was added to c.opt and
documented in doc/invoke.texi. But c.opt.urls wasn't regenerate.

gcc/c-family/ChangeLog:

* c.opt.urls: Regenerate.

Diff:
---
 gcc/c-family/c.opt.urls | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls
index 631719863a5..dd455d7c0dc 100644
--- a/gcc/c-family/c.opt.urls
+++ b/gcc/c-family/c.opt.urls
@@ -208,6 +208,9 @@ 
UrlSuffix(gcc/Warning-Options.html#index-Wcast-function-type)
 Wcast-qual
 UrlSuffix(gcc/Warning-Options.html#index-Wcast-qual)
 
+Wcast-user-defined
+UrlSuffix(gcc/Warning-Options.html#index-Wcast-user-defined)
+
 Wcatch-value
 UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wcatch-value)

Re: Patches submission policy change

[Mark Wielaard]

Hi Jonathan,

On Sun, Apr 07, 2024 at 03:20:42PM +0100, Jonathan Wakely wrote:
> On Sun, 7 Apr 2024, 15:02 Mark Wielaard,  wrote:
> > The jit mailinglist is the same. It only has one moderator
> > (David). Having a second/backup one would probably be nice. Are you ok
> > to be added there?
> 
> Sure! I imagine that one is quiet as well.

Yes, we like quiet :) It means the spam filters work correctly.

> > (I see that both the libstdc++ and jit mailinglist just allow up to
> > 5MB patches, which probably means they don't block any legitimate
> > ones, but might get a bit more spam than necessary).
> >
> > It isn't a patches mailinglist, so slightly less urgent, but the
> > gcc-help mailinglist doesn't have any moderators. Would you be willing
> > to help out with that one?
> 
> Sure, I'm subscribed and active there anyway.

Thanks for volunteering, you have been added to both as admin.

Cheers,

Mark

Re: Patches submission policy change

[Mark Wielaard]

Hi Jonathan,

On Sun, Apr 07, 2024 at 01:32:11PM +0100, Jonathan Wakely via Gdb wrote:
> On Thu, 4 Apr 2024, 22:36 Mark Wielaard,  wrote:
> > wrt to the mailinglists maybe getting larger patches, I think most
> > will still be under 400K and I wouldn't raise the limit (because most
> > such larger emails are really just spam). But we might want to get
> > more mailinglist moderators.
> >
> > gcc-patches, binutils and gdb-patches all have only one moderator
> > (Jeff, Ian and Thiago). It would probably be good if there were
> > more.
> >
> > Any volunteers? It shouldn't be more than 1 to 3 emails a week
> > (sadly most of them spam).
> 
> I'm happy to help moderating/spambusting for the GCC lists.

I see you are already doing that for the libstdc++ mailinglist, but
you are the only moderator. Maybe you want someone as backup there?

The jit mailinglist is the same. It only has one moderator
(David). Having a second/backup one would probably be nice. Are you ok
to be added there?

(I see that both the libstdc++ and jit mailinglist just allow up to
5MB patches, which probably means they don't block any legitimate
ones, but might get a bit more spam than necessary).

It isn't a patches mailinglist, so slightly less urgent, but the
gcc-help mailinglist doesn't have any moderators. Would you be willing
to help out with that one?

Thanks,

Mark

Re: Patches submission policy change

[Mark Wielaard]

Hi,

On Fri, 2024-04-05 at 09:17 +0200, Christophe Lyon wrote:
> On 4/4/24 23:35, Mark Wielaard wrote:
> > wrt to the mailinglists maybe getting larger patches, I think most
> > will still be under 400K and I wouldn't raise the limit (because most
> > such larger emails are really just spam). But we might want to get
> > more mailinglist moderators.
> > 
> > gcc-patches, binutils and gdb-patches all have only one moderator
> > (Jeff, Ian and Thiago). It would probably be good if there were
> > more.
> > 
> > Any volunteers? It shouldn't be more than 1 to 3 emails a week
> > (sadly most of them spam).
> > 
> I'm happy to help with moderation of any/all of these 3 lists.

I added Simon for gdb, Marc for gcc and you as admin for binutils.
So all three projects now have at least two moderators. Thanks so much
for volunteering.

And please reach out to overseers if this becomes too much of a burden
(it really should not be more than a handful of messages each week).
Then we'll see if we can adjust the (spam) settings so only oversized
messages reach the moderation queues (or raise the limits if that makes
more sense).

Thanks,

Mark

[COMMITTED] Regenerate common.opt.urls

[Mark Wielaard]

The new support for gcov modified condition/decision coverage
introduced two new flags for gcc, -Wcoverage-too-many-conditions and
-fcondition-coverage. But didn't regenerate the gcc/common.opt.urls.

Fixes: 08a52331803f ("Add condition coverage (MC/DC)")

gcc/ChangeLog:

* common.opt.urls: Regenerate.
---

Pushed as obvious.

 gcc/common.opt.urls | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls
index db4354989fcc..f71ed80a34b4 100644
--- a/gcc/common.opt.urls
+++ b/gcc/common.opt.urls
@@ -280,6 +280,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-mismatch)
 Wcoverage-invalid-line-number
 UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-invalid-line-number)
 
+Wcoverage-too-many-conditions
+UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-too-many-conditions)
+
 Wmissing-profile
 UrlSuffix(gcc/Warning-Options.html#index-Wmissing-profile)
 
@@ -1057,6 +1060,9 @@ 
UrlSuffix(gcc/Instrumentation-Options.html#index-fprofile-abs-path)
 ;   duplicate: 'gcc/Instrumentation-Options.html#index-fprofile-arcs'
 ;   duplicate: 'gcc/Other-Builtins.html#index-fprofile-arcs-1'
 
+fcondition-coverage
+UrlSuffix(gcc/Instrumentation-Options.html#index-fcondition-coverage)
+
 fprofile-dir=
 UrlSuffix(gcc/Instrumentation-Options.html#index-fprofile-dir)
 
-- 
2.44.0

[gcc r14-9812] Regenerate common.opt.urls

[Mark Wielaard via Gcc-cvs]

https://gcc.gnu.org/g:0c22f67526d72aa451633d5212259a8f75e59a44

commit r14-9812-g0c22f67526d72aa451633d5212259a8f75e59a44
Author: Mark Wielaard 
Date:   Fri Apr 5 17:22:16 2024 +0200

Regenerate common.opt.urls

The new support for gcov modified condition/decision coverage
introduced two new flags for gcc, -Wcoverage-too-many-conditions and
-fcondition-coverage. But didn't regenerate the gcc/common.opt.urls.

Fixes: 08a52331803f ("Add condition coverage (MC/DC)")

gcc/ChangeLog:

* common.opt.urls: Regenerate.

Diff:
---
 gcc/common.opt.urls | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls
index db4354989fc..f71ed80a34b 100644
--- a/gcc/common.opt.urls
+++ b/gcc/common.opt.urls
@@ -280,6 +280,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-mismatch)
 Wcoverage-invalid-line-number
 UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-invalid-line-number)
 
+Wcoverage-too-many-conditions
+UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-too-many-conditions)
+
 Wmissing-profile
 UrlSuffix(gcc/Warning-Options.html#index-Wmissing-profile)
 
@@ -1057,6 +1060,9 @@ 
UrlSuffix(gcc/Instrumentation-Options.html#index-fprofile-abs-path)
 ;   duplicate: 'gcc/Instrumentation-Options.html#index-fprofile-arcs'
 ;   duplicate: 'gcc/Other-Builtins.html#index-fprofile-arcs-1'
 
+fcondition-coverage
+UrlSuffix(gcc/Instrumentation-Options.html#index-fcondition-coverage)
+
 fprofile-dir=
 UrlSuffix(gcc/Instrumentation-Options.html#index-fprofile-dir)

Re: Patches submission policy change

[Mark Wielaard]

Hi Christophe,

On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote:
> TL;DR: For the sake of improving precommit CI coverage and simplifying
> workflows, I’d like to request a patch submission policy change, so
> that we now include regenerated files. This was discussed during the
> last GNU toolchain office hours meeting [1] (2024-03-28).
> 
> Benefits or this change include:
> - Increased compatibility with precommit CI
> - No need to manually edit patches before submitting, thus the “git
> send-email” workflow is simplified
> - Patch reviewers can be confident that the committed patch will be
> exactly what they approved
> - Precommit CI can test exactly what has been submitted
> 
> Any concerns/objections?

I am all for it. It will make testing patches easier for everyone.

I do think we still need a better way to make sure all generated files
can be regenerated. If only to check that the files were generated
correctly with the correct versions. The autoregen buildbots are able
to catch some, but not all such mistakes.

wrt to the mailinglists maybe getting larger patches, I think most
will still be under 400K and I wouldn't raise the limit (because most
such larger emails are really just spam). But we might want to get
more mailinglist moderators.

gcc-patches, binutils and gdb-patches all have only one moderator
(Jeff, Ian and Thiago). It would probably be good if there were
more.

Any volunteers? It shouldn't be more than 1 to 3 emails a week
(sadly most of them spam).

Cheers,

Mark

Re: Sourceware mitigating and preventing the next xz-backdoor

[Mark Wielaard]

Hi,

On Wed, 2024-04-03 at 08:42 -0600, Jeff Law wrote:
> On 4/3/24 8:04 AM, Tom Tromey wrote:
> > > > > > > "Florian" == Florian Weimer  writes:
> > 
> > Florian> Everyone still pushes their own patches, and there are no
> > Florian> technical countermeasures in place to ensure that the pushed 
> > version is
> > Florian> the reviewed version.
> > 
> > This is a problem for gdb as well.
> > 
> > Probably we should switch to some kind of pull-request model, where
> > patches can only be landed via the UI, after sufficient review; and
> > where all generated files are regenerated by the robot before checkin.
> > (Or alternatively some CI runs and rejects patches where they don't
> > match.)
> I've very much prefer to move to a pull-request model.

Do you need any infrastructure updates to help (experiment) with that?
Now would be a great time to request some updates to patchwork or get
us to resurrect the gerrit server if that would be helpful.

We just published the Sourceware 2024 infrastructure plan:
https://inbox.sourceware.org/20240325095827.gi5...@gnu.wildebeest.org/
Setting priorities for the infrastructure for 2024 (and beyond). We are
just now scheduling and budgeting that work. So please get your
requests in.

Cheers,

Mark

Re: Sourceware mitigating and preventing the next xz-backdoor

[Mark Wielaard]

Hi,

On Wed, 2024-04-03 at 08:53 -0500, Joel Sherrill wrote:
> On Wed, Apr 3, 2024, 3:09 AM Florian Weimer via Gdb  
> wrote:
> > * Guinevere Larsen via Overseers:
> > 
> > > Beyond that, we (GDB) are already experimenting with approved-by, and
> > > I think glibc was doing the same.
> > 
> > The glibc project uses Reviewed-by:, but it's completely unrelated to
> > this.  Everyone still pushes their own patches, and there are no
> > technical countermeasures in place to ensure that the pushed version is
> > the reviewed version.
> 
> Or that there isn't "collusion" between a malicious author and reviewer.
> Just tagging it approved or reviewed by just gives you two people to blame.
> It is not a perfect solution either.
> 
> But double checking and checklists are good practices.
> They are not foolproof if some bad actor is determined enough.

Agreed. If you just focus on completely fool proof technically
checkable measures then you end up doing nothing. But making things
like always getting a Reviewed-by or Tested-by tag in your commit
message does strengthen the social norms. And once they are common
practice you could even add some technical checks.

I am sure a really determined bad actor can always find some social or
technical engineering trick to "defeat" our project policies. But that
doesn't mean we shouldn't do things which are good practices anyway.

Cheers,

Mark

[COMMITTED] Regenerate i386.opt.urls

[Mark Wielaard]

LoongArch added an -mtls-dialect option, causing the similarly
named option for i386 get renumbered.

Fixes: b253b4695dda ("LoongArch: Add support for TLS descriptors.")

gcc/ChangeLog:

* config/i386/i386.opt.urls: Regenerate.
---

Pushed as obvious.

 gcc/config/i386/i386.opt.urls | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/i386/i386.opt.urls b/gcc/config/i386/i386.opt.urls
index fa821eba2006..81c5bb9a9270 100644
--- a/gcc/config/i386/i386.opt.urls
+++ b/gcc/config/i386/i386.opt.urls
@@ -128,7 +128,7 @@ mstackrealign
 UrlSuffix(gcc/x86-Options.html#index-mstackrealign)
 
 mtls-dialect=
-UrlSuffix(gcc/x86-Options.html#index-mtls-dialect-1)
+UrlSuffix(gcc/x86-Options.html#index-mtls-dialect-2)
 
 mtls-direct-seg-refs
 UrlSuffix(gcc/x86-Options.html#index-mtls-direct-seg-refs)
-- 
2.44.0

[gcc r14-9777] Regenerate i386.opt.urls

[Mark Wielaard via Gcc-cvs]

https://gcc.gnu.org/g:5c749db15fab032df757b72e8114b89572783a20

commit r14-9777-g5c749db15fab032df757b72e8114b89572783a20
Author: Mark Wielaard 
Date:   Wed Apr 3 17:35:25 2024 +0200

Regenerate i386.opt.urls

LoongArch added an -mtls-dialect option, causing the similarly
named option for i386 get renumbered.

Fixes: b253b4695dda ("LoongArch: Add support for TLS descriptors.")

gcc/ChangeLog:

* config/i386/i386.opt.urls: Regenerate.

Diff:
---
 gcc/config/i386/i386.opt.urls | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/i386/i386.opt.urls b/gcc/config/i386/i386.opt.urls
index fa821eba200..81c5bb9a927 100644
--- a/gcc/config/i386/i386.opt.urls
+++ b/gcc/config/i386/i386.opt.urls
@@ -128,7 +128,7 @@ mstackrealign
 UrlSuffix(gcc/x86-Options.html#index-mstackrealign)
 
 mtls-dialect=
-UrlSuffix(gcc/x86-Options.html#index-mtls-dialect-1)
+UrlSuffix(gcc/x86-Options.html#index-mtls-dialect-2)
 
 mtls-direct-seg-refs
 UrlSuffix(gcc/x86-Options.html#index-mtls-direct-seg-refs)

Sourceware mitigating and preventing the next xz-backdoor

[Mark Wielaard]

A big thanks to everybody working this long Easter weekend who helped
analyze the xz-backdoor and making sure the impact on Sourceware and
the hosted projects was minimal.

This email isn't about the xz-backdoor itself. Do see Sam James FAQ
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
(Sorry for the github link, but this one does seem viewable without
proprietary javascript)

We should discuss what we have been doing and should do more to
mitigate and prevent the next xz-backdoor. There are a couple of
Sourceware services that can help with that.

TLDR;
- Replicatable isolated container/VMs are nice, we want more.
- autoregen buildbots, it should be transparent (and automated) how to
  regenerate build/source files.
- Automate (snapshot) releases tarballs.
- Reproducible releases (from git).

The impact on Sourceware was minimal because we were able to just zap
the affected systems. That is because we started putting everything
into containers and isolated VMs that are easy to reinstall.

In this case we were prepared, but it was also luck that the systems
that were potentially affected were already setup this way. We would
like to be able to do this for any system we deploy. That is why the
Sourceware Project Leadership Committee together with the Software
Freedom Conservancy staff put together "Sourceware 2024 - The Plan"
with as main theme isolation.

https://inbox.sourceware.org/20240325095827.gi5...@gnu.wildebeest.org/

We should be proactive and make sure we are prepared. This will not
just help security of the systems. But by moving services into their
own container or VM will help scaling by making it easy to move
between separate physical machines. And it makes us provide services
that anybody can replicate and setup themselves.

A large part of the xz-backdoor was possible because of social
engineering, which is difficult to solve with technical measures. But
another part was because generation of some of the build/source files
and the release tarball was not transparent and not reproducible.

Having source files or release tarballs being hard to (re)generate
lowers our own trust and the trust that our users have that the
sources in git matches what the released software is build from. It
also makes reviews and automated (pre-commit) CI harder. We have been
working on these issues in two ways, creating automated release
snapshots and the autoregen buildbots.

For projects like gcc, gdb and binutils we have introduced autoregen
buildbots which warn when some generated files are not properly
regenerated from source.
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen
This has caught various issues, but isn't complete yet. Christophe
Lyon and Simon Marchi have been working on more generic make
regenerate targets.
https://inbox.sourceware.org/20240313080237.1143034-1-christophe.l...@linaro.org

See also Eric Gallager's discussion on automake make distcheck:
https://lists.gnu.org/archive/html/automake/2024-03/msg7.html

With the help of OSUOSL we have also introduced automated release
snapshots. Projects, like glibc, valgrind, libabigail have fully
automated release tarball (and documentation) generation against
current git. https://snapshots.sourceware.org/

This has caught some issues early which would otherwise only have been
detected at release time and has made sure the generation of other
release artifacts e.g. documentation keeps working. All this is done
in known containers, so also checks that releases can be made with
stable tools.

There are some possible future steps that we can do to make it easier
to check that the release tarballs are created from the actual git
sources. We can ask release managers to check release tarballs they
create against the automated snapshots releases. And/or ask them to
reuse the containers from snapshots or autoregen builders to create
releases. https://sourceware.org/cgit/builder/tree/README_containers

And we should try to work with the reproducible builds project to make
sure that release artifacts can be reproducibly created from the git
sources. https://reproducible-builds.org/ Reproducible builds is also
a Software Freedom Conservancy member project.

Re: [PATCH] Regenerate loongarch.opt.urls.

[Mark Wielaard]

Hi,

On Mon, Apr 01, 2024 at 11:08:08AM +0800, Lulu Cheng wrote:
> Fixes: d28ea8e5a704 ("LoongArch: Split loongarch_option_override_internal
> into smaller procedures")
> 
> gcc/ChangeLog:
> 
>   * config/loongarch/loongarch.opt.urls: Regenerate.

This looks OK to me. I cannot officially approve patches, but I think
this falls under the Obvious fixes rule.

Cheers,

Mark

Security warning about xz library compromise

[Mark Wielaard]

Sourceware hosts are not affected by the latest xz backdoor.

But we have reset the https://builder.sourceware.org containers of
debian-testing, fedora-rawhide and opensuse-tumbleweed. These
containers however didn't have ssh installed, were running on isolated
VMs on separate machines from our main hosts, snapshots and backup
servers.

If you are running one of these distros on your development machines
then please consult your distro security announcements:

https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
https://lists.debian.org/debian-security-announce/2024/msg00057.html
https://archlinux.org/news/the-xz-package-has-been-backdoored/
https://news.opensuse.org/2024/03/29/xz-backdoor/

Re: GNU Tools Cauldron 2024

[Mark Wielaard]

On Wed, 2024-03-06 at 12:47 -0800, Bradley M. Kuhn via Gcc wrote:
> Eric Gallager wrote:
> > Hi, I would greatly appreciate a US option, and having it in Portland
> > would be especially convenient for me, as then I could stay with
> > family, so I would like to express my interest in it and would hope
> > that such an option can go forwards
> 
> Excited to hear that!
> 
> To have a track at FOSSY, it is somewhat similar to FOSDEM in that regard —
> so it can be done grassroots.  The volunteer help SFC needs is minimal: we'd
> need some accomplished folks in the GNU toolchain projects to step forward to
> do review and selection of talks, and at least one person who is coming
> in-person that will coordinate with the speakers in the track for the day.
> SFC really took inspiration from FOSDEM in handling the logistics of the
> event so that Free Software communities could have a place to have an event
> without having to worry about the painful logistical parts.

This has been confirmed now:
https://sfconservancy.org/news/2024/mar/28/fossy-2024/
FOSSY is back in Portland - August 1-4th at Portland State University

To propose a GNU toolchain community track go here:
https://sfconservancy.org/fossy/community-tracks/

Sourceware 2024 - The Plan

[Mark Wielaard]

The Sourceware Project Leadership Committee in discussion with the
Software Freedom Conservancy staff came up with the Sourceware 2024
plan and is looking at longer term projects that would be needed to
keep your infrastructure running smoothly and securely for the next
couple of years. We are currently discussing how to distribute these
tasks over paid staff, overseers, project admin volunteers and
contractors.

We realize that our plans may not be your plans, so really like to get
feedback. It is our goal to offer a worry-free, friendly home for Free
Software core toolchain and developer tools projects. So please do
reach out and share your ideas on the overseers mailinglist, file
infrastructure bugs, join our channel #overseers on irc or join one of
the monthly open office hours:
https://sourceware.org/mission.html#organization

For 2024 we want to concentrate on isolating and scaling the
services. In the last two years we doubled the number of machines (and
more are on the way!) that we run the services on. And some of the new
services are already setup in containers or on isolated VMs. But most
of the services are still isolated through traditional unix
mechanisms.  Moving those into their own container or VM will help
scaling by making it easy to move between separate physical
machines. It will also provide security in depth.

It is our preference to run distro packaged software (e.g. mailman,
postfix, public-inbox, etc.). That way we have easy security updates.
But for some services we track an upstream stable branch (e.g.
buildbot, patchwork and bugzilla). While isolating/containerizing
these services we will also publish the internal git repos (if they
contain any local adjustments), so we can easier share patches with
other organizations. Ideally we'll also publish ansible playbooks.
That way, over time, we will provide services that anybody can
replicate and setup themselves.

Longer term we identified a couple of thing, mainly around isolation
(the theme of 2024), email, spam, mailinglists, search, AI bots and
services upgrades that we believe are important to prepare for.

Concretely we are looking at:

- mailman2 upgrade/replacement
  https://sourceware.org/bugzilla/show_bug.cgi?id=31545

- bugzilla upgrade
  https://sourceware.org/bugzilla/show_bug.cgi?id=31547

- (local) search and AI bot/spiders, sitemaps, ...
  https://sourceware.org/bugzilla/show_bug.cgi?id=31551
  https://sourceware.org/bugzilla/show_bug.cgi?id=31548
  https://sourceware.org/bugzilla/show_bug.cgi?id=30610
  https://sourceware.org/bugzilla/show_bug.cgi?id=31549

- Distributed spam fighting
  https://sourceware.org/bugzilla/show_bug.cgi?id=31550

- buildbot email templates, pre-commit testing, buildbot-travis, ...
  https://sourceware.org/bugzilla/show_bug.cgi?id=31552

More items can be found in the Sourceware infrastructure bugzilla
https://sourceware.org/bugzilla/buglist.cgi?component=Infrastructure=sourceware=---

If you read this far we really like your feedback, even if it is a
simple "OK!", Reply-To: overse...@sourceware.org Or add you comments
to the bugzilla items above. And take a look at other ways to
participate https://sourceware.org/mission.html#organization

You can also help by becoming a Conservancy Sustainer
https://sfconservancy.org/sustainer/ or donating directly to
Sourceware https://sourceware.org/donate.html

Thanks,

  Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor,
  Tom Tromey, Jon Turney, Mark J. Wielaard, Elena Zannoni

Sourceware 2024 - The Plan

[Mark Wielaard]

The Sourceware Project Leadership Committee in discussion with the
Software Freedom Conservancy staff came up with the Sourceware 2024
plan and is looking at longer term projects that would be needed to
keep your infrastructure running smoothly and securely for the next
couple of years. We are currently discussing how to distribute these
tasks over paid staff, overseers, project admin volunteers and
contractors.

We realize that our plans may not be your plans, so really like to get
feedback. It is our goal to offer a worry-free, friendly home for Free
Software core toolchain and developer tools projects. So please do
reach out and share your ideas on the overseers mailinglist, file
infrastructure bugs, join our channel #overseers on irc or join one of
the monthly open office hours:
https://sourceware.org/mission.html#organization

For 2024 we want to concentrate on isolating and scaling the
services. In the last two years we doubled the number of machines (and
more are on the way!) that we run the services on. And some of the new
services are already setup in containers or on isolated VMs. But most
of the services are still isolated through traditional unix
mechanisms.  Moving those into their own container or VM will help
scaling by making it easy to move between separate physical
machines. It will also provide security in depth.

It is our preference to run distro packaged software (e.g. mailman,
postfix, public-inbox, etc.). That way we have easy security updates.
But for some services we track an upstream stable branch (e.g.
buildbot, patchwork and bugzilla). While isolating/containerizing
these services we will also publish the internal git repos (if they
contain any local adjustments), so we can easier share patches with
other organizations. Ideally we'll also publish ansible playbooks.
That way, over time, we will provide services that anybody can
replicate and setup themselves.

Longer term we identified a couple of thing, mainly around isolation
(the theme of 2024), email, spam, mailinglists, search, AI bots and
services upgrades that we believe are important to prepare for.

Concretely we are looking at:

- mailman2 upgrade/replacement
  https://sourceware.org/bugzilla/show_bug.cgi?id=31545

- bugzilla upgrade
  https://sourceware.org/bugzilla/show_bug.cgi?id=31547

- (local) search and AI bot/spiders, sitemaps, ...
  https://sourceware.org/bugzilla/show_bug.cgi?id=31551
  https://sourceware.org/bugzilla/show_bug.cgi?id=31548
  https://sourceware.org/bugzilla/show_bug.cgi?id=30610
  https://sourceware.org/bugzilla/show_bug.cgi?id=31549

- Distributed spam fighting
  https://sourceware.org/bugzilla/show_bug.cgi?id=31550

- buildbot email templates, pre-commit testing, buildbot-travis, ...
  https://sourceware.org/bugzilla/show_bug.cgi?id=31552

More items can be found in the Sourceware infrastructure bugzilla
https://sourceware.org/bugzilla/buglist.cgi?component=Infrastructure=sourceware=---

If you read this far we really like your feedback, even if it is a
simple "OK!", Reply-To: overse...@sourceware.org Or add you comments
to the bugzilla items above. And take a look at other ways to
participate https://sourceware.org/mission.html#organization

You can also help by becoming a Conservancy Sustainer
https://sfconservancy.org/sustainer/ or donating directly to
Sourceware https://sourceware.org/donate.html

Thanks,

  Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor,
  Tom Tromey, Jon Turney, Mark J. Wielaard, Elena Zannoni

Re: CI for "Option handling: add documentation URLs"

[Mark Wielaard]

Hi YunQiang Su,

On Fri, Mar 15, 2024 at 03:33:28PM +0800, YunQiang Su wrote:
> Great work. The CI works well now: it blames me ;)
> https://builder.sourceware.org/buildbot/#/builders/269/builds/3846
> 
> When I add '-mstrict-align' option to MIPS,
> the riscv.opt.urls, sysv4.opt.urls, xtensa.opt.urls are changed also.
> (why they are effected?

They are effected because they also have a '-mstrict-align' option and
each option with the same name gets an unique number.

> So what's the best practice for this cases?
> Should I push a new commit? Or in fact a single commit is preferred?

I don't know if there is a rule for this. But I hope this falls under
the obvious rule. What I would do is simply take that diff the CI
produced.
https://builder.sourceware.org/buildbot/api/v2/logs/7798308/raw

Apply it and commit that with:

Regenerate opt.urls

Fixes: acc38ff59976 ("MIPS: Add -m(no-)strict-align option")

gcc/ChangeLog:

* config/riscv/riscv.opt.urls: Regenerated.
* config/rs6000/sysv4.opt.urls: Likewise.
* config/xtensa/xtensa.opt.urls: Likewise.

Cheers,

Mark

Re: About gsoc

[Mark Wielaard]

Hi Dave,

On Sun, Mar 10, 2024 at 08:17:31PM -0500, Dave Blanchard wrote:
> > > On Tue, 5 Mar 2024 at 01:59, Dave Blanchard  wrote:
> > > > Wow, what a fucking prick this guy is.
> > > > [...]
> You are one of the biggest assholes I've encountered in the open
> source world, and I've met some real dicks.

You have been warned before. Please stop sending these negative
unproductive messages to this list attacking well respected productive
maintainers of the project. Your attitude is not welcome.

Thanks,

Mark

Sourceware Open Office, Friday 18:00 UTC, don't feel isolated

[Mark Wielaard]

TL;DR; Friday March 8, 18:00 UTC, Sourceware Open Office discussion of
services priorities for 2024, irc.liberachat.org #overseers

To get the right time in your local timezone:
$ date -d "Fri Mar 8 18:00:00 UTC 2024"

In 2022 we published the Sourceware GNU Toolchain Infrastructure
Roadmap [1]. And showed we could provide new services like patchwork,
buildbot, public-inbox and the snapshots server to help the community
become more efficient.

In 2023 we celebrated the Sourceware 25 Roadmap [2] and joined the
Software Freedom Conservancy as member project [3]. Showing we could
grow while diversifying hardware and service partners and raising
funds with a fiscal sponsor.

For 2024 we [4] want to concentrate on isolating and scaling the
services. In the last two years we doubled the number of machines (and
more are on the way!) that we run the services on. And some of the new
services are already setup in containers or on isolated VMs. But most
of the services are still isolated through traditional unix
mechanisms. Moving those into their own container or VM will help
scaling by making it easy to move between separate physical machines.

But we of course want to do this in a way that doesn't disrupt any
services or causes a messy migration. And we want the projects to be
in control. So please come and discuss your projects priorities and
essentials.

For this meeting we will also have a BBB meeting room:
https://bbb.sfconservancy.org/b/mar-aom-dmo-fko
(But the real discussion will be in the irc channel)

[1] 
https://gnu.wildebeest.org/blog/mjw/2022/06/22/sourceware-gnu-toolchain-infrastructure-roadmap/
[2] https://sourceware.org/sourceware-25-roadmap.html
[3] https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/
[4] https://sourceware.org/mission.html#plc

Re: CI for "Option handling: add documentation URLs"

[Mark Wielaard]

On Tue, Mar 05, 2024 at 08:34:31AM -0500, David Malcolm wrote:
> > I committed that patch, but was not fast enough actually enabling the
> > buildbot and missed another fixlet needed first.
> > 
> > OK, to push the attached regeneration patch?
> 
> Yes

Thanks, pushed. And now also pushed the builder patch (attached) to
enable it in the CI autoregen checker. It already ran without finding
any issues.

https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen

Re: CI for "Option handling: add documentation URLs"

[Mark Wielaard]

Hi,

On Mon, 2024-03-04 at 08:48 -0500, David Malcolm wrote:
> > I have now regenerated the patch to also include the new avr mfuse-
> > add change. It would be nice to get this committed so we can turn on the
> > automatic checker.
> 
> Please go ahead with that.

I committed that patch, but was not fast enough actually enabling the
buildbot and missed another fixlet needed first.

OK, to push the attached regeneration patch?

Thanks,

Mark
From e5c2b9983d7c09e5a21fa587dc9cd03d53d67a23 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Tue, 5 Mar 2024 13:01:08 +0100
Subject: [PATCH] Regenerate c.opt.urls

Fixes: 08edf85f747b ("c++/modules: relax diagnostic about GMF contents")

gcc/c-family/ChangeLog:

	* c.opt.urls: Regenerate.
---
 gcc/c-family/c.opt.urls | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls
index 9f97dc61a778..631719863a5e 100644
--- a/gcc/c-family/c.opt.urls
+++ b/gcc/c-family/c.opt.urls
@@ -403,6 +403,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wformat)
 Wframe-address
 UrlSuffix(gcc/Warning-Options.html#index-Wframe-address)
 
+Wglobal-module
+UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wglobal-module)
+
 Wif-not-aligned
 UrlSuffix(gcc/Warning-Options.html#index-Wif-not-aligned)
 
-- 
2.44.0

Re: Help needed with maintainer-mode

[Mark Wielaard]

Hi Christophe,

On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> > > > And it was indeed done this way because that way the files are
> > > > regenerated in a reproducible way. Which wasn't the case when using 
> > > > --enable-maintainer-mode (and autoreconfig also doesn't work).
> > >
> > > I see. So it is possibly incomplete, in the sense that it may lack
> > > some of the steps that maintainer-mode would perform?
> > > For instance, gas for aarch64 has some *opcodes*.c files that need
> > > regenerating before committing. The regeneration step is enabled in
> > > maintainer-mode, so I guess the autoregen bots on Sourceware would
> > > miss a problem with these files?
> >
> > Yes, it is certainly incomplete. But it is done this way because it is
> > my understanding that even the gcc release maintainers do the
> > automake/autoconf invocations by hand instead of running with configure
> > --enable-maintainer-mode.
> 
> After a discussion on IRC, I read
> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
> which basically says "run autoreconf in every dir where there is a
> configure script"
> but this is not exactly what autoregen.py is doing. IIRC it is based
> on a script from Martin Liska, do you know/remember why it follows a
> different process?

CCing Sam and Arsen who helped refine the autoregen.py script, who
might remember more details. We wanted a script that worked for both
gcc and binutils-gdb. And as far as I know autoreconf simply didn't
work in all directories. We also needed to skip some directories that
did contain a configure script, but that were imported (gotools,
readline, minizip).

Cheers,

Mark

Re: CI for "Option handling: add documentation URLs"

[Mark Wielaard]

Hi,

On Sat, Feb 24, 2024 at 06:42:58PM +0100, Mark Wielaard wrote:
> On Thu, Feb 22, 2024 at 11:57:50AM +0800, YunQiang Su wrote:
> > Mark Wielaard  于2024年2月19日周一 06:58写道：
> > > So, I did try the regenerate-opt-urls locally, and it did generate the
> > > attached diff. Which seems to show we really need this automated.
> > >
> > > Going over the diff. The -Winfinite-recursion in rust does indeed seem
> > > new.  As do the -mapx-inline-asm-use-gpr32 and mevex512 for i386.  And
> > > the avr options -mskip-bug, -mflmap and mrodata-in-ram.  The change in
> > > common.opt.urls for -Wuse-after-free comes from it being moved from
> > > c++ to the c-family. The changes in mips.opt.urls seem to come from
> > > commit 46df1369 "doc/invoke: Remove duplicate explicit-relocs entry of
> > > MIPS".
> > 
> > For MIPS, it's due to malformed patches to invoke.text.
> > I will fix them.
> 
> Thanks. So with your commit 00bc8c0998d8 ("invoke.texi: Fix some
> skipping UrlSuffix problem for MIPS") pushed now, the attached patch
> fixes the remaining issues.
> 
> Is this OK to push?

Ping.

I have now regenerated the patch to also include the new avr mfuse-add
change. It would be nice to get this committed so we can turn on the
automatic checker.

Thanks,

Mark
>From 84373cd8045e67f0d1716dad899c3463b823ea97 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Sun, 3 Mar 2024 20:50:32 +0100
Subject: [PATCH] Regenerate opt.urls

There were several commits that didn't regenerate the opt.urls files.

Fixes: 438ef143679e ("rs6000: Neuter option -mpower{8,9}-vector")
Fixes: 50c549ef3db6 ("gccrs: enable -Winfinite-recursion warnings by default")
Fixes: 25bb8a40abd9 ("Move docs for -Wuse-after-free and -Wuseless-cast")
Fixes: 48448055fb70 ("AVR: Support .rodata in Flash for AVR64* and AVR128*")
Fixes: 42503cc257fb ("AVR: Document option -mskip-bug")
Fixes: 7de5bb642c12 ("i386: [APX] Document inline asm behavior and new switch")
Fixes: 49a14ee488b8 ("Add -mevex512 into invoke.texi")
Fixes: 4666cbde5e6d ("Sort warning options in c-family/c.opt.")
Fixes: cda383616183 ("AVR: target/114100 - Better indirect accesses for reduced 
Tiny")

gcc/config/
* rs6000/rs6000.opt.urls: Regenerate.
* avr/avr.opt.urls: Likewise.
* i386/i386.opt.urls: Likewise.
* pru/pru.opt.urls: Likewise.
* riscv/riscv.opt.urls: Likewise.

gcc/rust/
* lang.opt.urls: Regenerate.

gcc/
* common.opt.urls: Regenerate.

gcc/c-family/
* c.opt.urls: Regenerate.
---
 gcc/c-family/c.opt.urls   | 351 +++---
 gcc/common.opt.urls   |   4 +-
 gcc/config/avr/avr.opt.urls   |  15 ++
 gcc/config/i386/i386.opt.urls |   8 +-
 gcc/config/pru/pru.opt.urls   |   2 +-
 gcc/config/riscv/riscv.opt.urls   |   2 +-
 gcc/config/rs6000/rs6000.opt.urls |   3 -
 gcc/rust/lang.opt.urls|   3 +
 8 files changed, 206 insertions(+), 182 deletions(-)

diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls
index 5365c8e2bc54..9f97dc61a778 100644
--- a/gcc/c-family/c.opt.urls
+++ b/gcc/c-family/c.opt.urls
@@ -88,6 +88,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wabsolute-value)
 Waddress
 UrlSuffix(gcc/Warning-Options.html#index-Waddress)
 
+Waddress-of-packed-member
+UrlSuffix(gcc/Warning-Options.html#index-Waddress-of-packed-member)
+
 Waligned-new
 UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Waligned-new)
 
@@ -115,6 +118,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Walloc-zero)
 Walloca-larger-than=
 UrlSuffix(gcc/Warning-Options.html#index-Walloca-larger-than_003d) 
LangUrlSuffix_D(gdc/Warnings.html#index-Walloca-larger-than)
 
+Warith-conversion
+UrlSuffix(gcc/Warning-Options.html#index-Warith-conversion)
+
 Warray-bounds=
 UrlSuffix(gcc/Warning-Options.html#index-Warray-bounds)
 
@@ -122,13 +128,10 @@ Warray-compare
 UrlSuffix(gcc/Warning-Options.html#index-Warray-compare)
 
 Warray-parameter
-UrlSuffix(gcc/Warning-Options.html#index-Wno-array-parameter)
+UrlSuffix(gcc/Warning-Options.html#index-Warray-parameter)
 
 Warray-parameter=
-UrlSuffix(gcc/Warning-Options.html#index-Wno-array-parameter)
-
-Wzero-length-bounds
-UrlSuffix(gcc/Warning-Options.html#index-Wzero-length-bounds)
+UrlSuffix(gcc/Warning-Options.html#index-Warray-parameter)
 
 Wassign-intercept
 
UrlSuffix(gcc/Objective-C-and-Objective-C_002b_002b-Dialect-Options.html#index-Wassign-intercept)
@@ -148,9 +151,6 @@ UrlSuffix(gcc/Warning-Options.html#index-Wbool-compare)
 Wbool-operation
 UrlSuffix(gcc/Warning-Options.html#index-Wbool-operation)
 
-Wframe-address
-UrlSuffix(gcc/Warning-Options.html#index-Wframe-address)
-
 Wbuiltin-declaration-mismatch
 UrlSuffix(gcc/Warning-Options.html#index-Wbuiltin-declaration-mismatch) 
LangUrlSuffi

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

[Mark Wielaard]

Hi,

On Fri, Mar 01, 2024 at 11:24:00AM +0100, Arthur Cohen wrote:
> On 2/29/24 21:22, Mark Wielaard wrote:
> >I think what needs to happen is have a config check for the minimum
> >versions of cargo and rustc that are now needed for when configuring
> >for --enable-languages=rust.
> 
> Yes - sorry about that. I will spend some time trying to make it
> nice for the builders and users overall but I am currently trying to
> finish the implementation of format_args!() in time for 14.1. So
> this will take me a little bit of time.

So when you use --enable-languages=ada it says:
configure: error: GNAT is required to build ada

And with --enable-languages=d:
configure: error: GDC is required to build d

That comes from this bit in the top-level configure.ac:

# Disable Ada if no preexisting GNAT is available.
case ${add_this_lang}:${language}:${have_gnat} in
  yes:ada:no)
# Specifically requested language; tell them.
AC_MSG_ERROR([GNAT is required to build $language])
;;
  all:ada:no)
AC_MSG_WARN([GNAT is required to build $language])
add_this_lang=unsupported
;;
  *:ada:no)
# Silently disable.
add_this_lang=unsupported
;;
esac

# Disable D if no preexisting GDC is available.
case ${add_this_lang}:${language}:${have_gdc} in
  yes:d:no)
# Specifically requested language; tell them.
AC_MSG_ERROR([GDC is required to build $language])
   ;;
  all:d:no)
AC_MSG_WARN([GDC is required to build $language])
add_this_lang=unsupported
;;
  *:d:no)
# Silently disable.
add_this_lang=unsupported
;;
esac

have_gnat and have_gdc are set by ACX_PROG_GNAT and ACX_PROG_GDC
defined in config/acx.m4 and called earlier in configure.ac.

Cheers,

Mark

[COMMITTED htdocs] robots.txt: Disallow various wiki actions

[Mark Wielaard]

It is fine for robots to crawl the wiki pages, but they should perform
actions, generate huge diffs, search/highlight pages or generate
calendars.
---
 htdocs/robots.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index 057c5899..36be4d13 100644
--- a/htdocs/robots.txt
+++ b/htdocs/robots.txt
@@ -14,4 +14,8 @@ Disallow: /bugzilla/show_bug.cgi*ctype=xml*
 Disallow: /bugzilla/attachment.cgi
 Disallow: /bugzilla/showdependencygraph.cgi
 Disallow: /bugzilla/showdependencytree.cgi
+Disallow: /wiki/*?action=*
+Disallow: /wiki/*?diffs=*
+Disallow: /wiki/*?highlight=*
+Disallow: /wiki/*?calparms=*
 Crawl-Delay: 60
-- 
2.43.2

Re: Help needed with maintainer-mode

[Mark Wielaard]

Hi Christophe,

On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard  wrote:
> > That python script works across gcc/binutils/gdb:
> > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py
> > 
> > It is installed into a container file that has the exact autoconf and
> > automake version needed to regenerate the autotool files:
> > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools
> > 
> > And it was indeed done this way because that way the files are
> > regenerated in a reproducible way. Which wasn't the case when using 
> > --enable-maintainer-mode (and autoreconfig also doesn't work).
> 
> I see. So it is possibly incomplete, in the sense that it may lack
> some of the steps that maintainer-mode would perform?
> For instance, gas for aarch64 has some *opcodes*.c files that need
> regenerating before committing. The regeneration step is enabled in
> maintainer-mode, so I guess the autoregen bots on Sourceware would
> miss a problem with these files?

Yes, it is certainly incomplete. But it is done this way because it is
my understanding that even the gcc release maintainers do the
automake/autoconf invocations by hand instead of running with configure
--enable-maintainer-mode.

Note that another part that isn't caught at the moment are the
regeneration of the opt.urls files. There is a patch for that pending:
https://inbox.sourceware.org/buildbot/20231215005908.gc12...@gnu.wildebeest.org/

But that is waiting for the actual opt.urls to be regenerated correctly
first:
https://inbox.sourceware.org/gcc-patches/20240224174258.gd1...@gnu.wildebeest.org/
Ping David?

It would be nice to have all these "regeneration targets" in one script
that could be used by both the pre-commit and post-commit checkers.

Cheers,

Mark

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

[Mark Wielaard]

Hi,

On Thu, Feb 29, 2024 at 09:00:13PM +0100, Thomas Schwinge wrote:
> Three 'cargo' ('command not found') as well as
> one 'rustc' ('error[E0658]: `let...else` statements are unstable')
> errors:

Yeah, I noticed those earlier, but oddly the tree became compilable
again earlier today, then broke again?

I think what needs to happen is have a config check for the minimum
versions of cargo and rustc that are now needed for when configuring
for --enable-languages=rust.

Then we need to see for which builder arches/distros those versions of
cargo and rustc are available and install them there (and disable the
builders for which there is no good version available).

Cheers,

Mark

Re: Help needed with maintainer-mode

[Mark Wielaard]

Hi Christophe,

On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> I've noticed that sourceware's buildbot has a small script
> "autoregen.py" which does not use the project's build system, but
> rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way.
> Should we replicate that?

That python script works across gcc/binutils/gdb:
https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py

It is installed into a container file that has the exact autoconf and
automake version needed to regenerate the autotool files:
https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools

And it was indeed done this way because that way the files are
regenerated in a reproducible way. Which wasn't the case when using 
--enable-maintainer-mode (and autoreconfig also doesn't work).

It is run on all commits and warns if it detects a change in the
(checked in) generated files.
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen

Cheers,

Mark

Sourceware infrastructure updates for Q1 2024

[Mark Wielaard]

Sourceware infrastructure community updates for Q1 2024

A summary of news about Sourceware, the Free Software hosting project
for core toolchain and developer tools, from the last 3 months.

- Sourceware now has an official donation page
- StarFive VisionFive-2 RISC-V boards for builder.sourceware.org
- server2 and server3 disk drive updates
- Upgrading project websites from CVS to GIT
- Sourceware @ Fosdem
- Security policy updates for a CVE system out of control
- Summer of Code

= Sourceware now has an official donation page

  Sourceware is a Free Software hosting project for core toolchain and
  developer tools. Sourceware is maintained by volunteers. Hardware
  and bandwidth is provided by sponsors. Sourceware is a Software
  Freedom Conservancy member project. Conservancy handles all
  non-profit administrivia for Sourceware. Thanks to the Conservancy
  we already have collected enough money for an emergency hardware
  replacement fund. In case one of our hardware partners would
  suddenly and unexpectedly drop support we can now simply buy new
  hardware. And we now also have an official donation page to help
  fund accelerating tasks the community feels most useful.
  
  https://sourceware.org/donate.html

= StarFive VisionFive-2 RISC-V boards for builder.sourceware.org

  StarFive has donated 4 VisionFive-2 risc-v boards with 8GB, 4-core
  JH7110 supporting the RV64GC ISA for the CI running on
  builder.sourceware.org. Which has allowed us to setup CI (and try)
  builders for various projects: annobin, binutils(+try), bzip2,
  debugedit, dwz, elfutils(+try), glibc, poke and libabigail(+try).

  Please contact the builder project if you want to help out with the
  CI services. https://sourceware.org/mailman/listinfo/buildbot

= server2 and server3 disk drive updates

  One of the drives in server2 broke down. It was part of a 10 drive
  raid6 setup, which can take 2 bad disks before full failure. We also
  have a full mirror on server3, which has a similar raid6 setup. We
  ordered 3 new disks, one as replacement for the bad disk and a spare
  for server2 and server3 in case of future drive failures. The drive
  has been replaced and everything is running smoothly. We have a fund
  for replacing hardware when needed. But if you want to help out
  keeping everything running smoothly you can donate on our new
  donation page https://sourceware.org/donate.html

= Upgrading project websites from CVS to GIT.

  Various projects were still creating their project homepages from
  CVS. We upgraded both glibc and binutils to have a public git htdocs
  repository now to which the whole community can contribute.
  
  https://sourceware.org/cgit/binutils-htdocs/
  https://sourceware.org/cgit/glibc-htdocs/
  
  Please contact us if you want to upgrade how you publish your
  projects homepage. https://sourceware.org/mission.html#organization

= Sourceware @ Fosdem

  2024 started strong with various Sourceware core toolchain and
  developer tool projects presenting at Fosdem. If you missed the in
  person meetings, most talks have video recordings:

  https://fosdem.org/2024/schedule/track/gcc/
  https://fosdem.org/2024/schedule/track/debuggers-and-analysis/
  https://fosdem.org/2024/schedule/event/fosdem-2024-2207-the-plan-for-gccrs/

  Various Sourceware volunteers, overseers and project leadership
  committee members also met informally with FSF/GNU and SFC admins to
  coordinate cross free software infrastructure administration
  matters.

  And if you like to organize an online virtual mini-BoF around some
  topic or project then the Conservancy BBB server is available for
  all Sourceware projects. You can create your own account at
  https://bbb.sfconservancy.org/b/signup which we can then activate
  for you. Note: Anyone is able to join a meeting, accounts are only
  required to create new meetings.

= Security policy updates for a CVE system out of control

  The Common Vulnerabilities and Exposures (CVE) system seems broken
  and has been issuing more and more questionable advisories. Various
  Sourceware hosted projects have been writing security policies to
  help users know which bugs might have security implications.

  https://sourceware.org/cgit/elfutils/tree/SECURITY
  https://sourceware.org/cgit/binutils-gdb/tree/binutils/SECURITY.txt
  https://gcc.gnu.org/cgit/gcc/tree/SECURITY.txt

  The glibc project even setup their own security mailinglist and CNA
  (CVE Numbering Authority) publishing their own advisories:
  https://sourceware.org/glibc/security.html
  https://sourceware.org/cgit/glibc/tree/advisories

  If you need any help adding infrastructure services for your
  security projects, please reach out:
  https://sourceware.org/mission.html#organization

= Summer of Code

  Some Sourceware hosted projects will take part in Summer of Code
  2024. If you are interested in participating please see
  https://gcc.gnu.org/wiki/SummerOfCode
  

Sourceware infrastructure updates for Q1 2024

[Mark Wielaard]

Sourceware infrastructure community updates for Q1 2024

A summary of news about Sourceware, the Free Software hosting project
for core toolchain and developer tools, from the last 3 months.

- Sourceware now has an official donation page
- StarFive VisionFive-2 RISC-V boards for builder.sourceware.org
- server2 and server3 disk drive updates
- Upgrading project websites from CVS to GIT
- Sourceware @ Fosdem
- Security policy updates for a CVE system out of control
- Summer of Code

= Sourceware now has an official donation page

  Sourceware is a Free Software hosting project for core toolchain and
  developer tools. Sourceware is maintained by volunteers. Hardware
  and bandwidth is provided by sponsors. Sourceware is a Software
  Freedom Conservancy member project. Conservancy handles all
  non-profit administrivia for Sourceware. Thanks to the Conservancy
  we already have collected enough money for an emergency hardware
  replacement fund. In case one of our hardware partners would
  suddenly and unexpectedly drop support we can now simply buy new
  hardware. And we now also have an official donation page to help
  fund accelerating tasks the community feels most useful.
  
  https://sourceware.org/donate.html

= StarFive VisionFive-2 RISC-V boards for builder.sourceware.org

  StarFive has donated 4 VisionFive-2 risc-v boards with 8GB, 4-core
  JH7110 supporting the RV64GC ISA for the CI running on
  builder.sourceware.org. Which has allowed us to setup CI (and try)
  builders for various projects: annobin, binutils(+try), bzip2,
  debugedit, dwz, elfutils(+try), glibc, poke and libabigail(+try).

  Please contact the builder project if you want to help out with the
  CI services. https://sourceware.org/mailman/listinfo/buildbot

= server2 and server3 disk drive updates

  One of the drives in server2 broke down. It was part of a 10 drive
  raid6 setup, which can take 2 bad disks before full failure. We also
  have a full mirror on server3, which has a similar raid6 setup. We
  ordered 3 new disks, one as replacement for the bad disk and a spare
  for server2 and server3 in case of future drive failures. The drive
  has been replaced and everything is running smoothly. We have a fund
  for replacing hardware when needed. But if you want to help out
  keeping everything running smoothly you can donate on our new
  donation page https://sourceware.org/donate.html

= Upgrading project websites from CVS to GIT.

  Various projects were still creating their project homepages from
  CVS. We upgraded both glibc and binutils to have a public git htdocs
  repository now to which the whole community can contribute.
  
  https://sourceware.org/cgit/binutils-htdocs/
  https://sourceware.org/cgit/glibc-htdocs/
  
  Please contact us if you want to upgrade how you publish your
  projects homepage. https://sourceware.org/mission.html#organization

= Sourceware @ Fosdem

  2024 started strong with various Sourceware core toolchain and
  developer tool projects presenting at Fosdem. If you missed the in
  person meetings, most talks have video recordings:

  https://fosdem.org/2024/schedule/track/gcc/
  https://fosdem.org/2024/schedule/track/debuggers-and-analysis/
  https://fosdem.org/2024/schedule/event/fosdem-2024-2207-the-plan-for-gccrs/

  Various Sourceware volunteers, overseers and project leadership
  committee members also met informally with FSF/GNU and SFC admins to
  coordinate cross free software infrastructure administration
  matters.

  And if you like to organize an online virtual mini-BoF around some
  topic or project then the Conservancy BBB server is available for
  all Sourceware projects. You can create your own account at
  https://bbb.sfconservancy.org/b/signup which we can then activate
  for you. Note: Anyone is able to join a meeting, accounts are only
  required to create new meetings.

= Security policy updates for a CVE system out of control

  The Common Vulnerabilities and Exposures (CVE) system seems broken
  and has been issuing more and more questionable advisories. Various
  Sourceware hosted projects have been writing security policies to
  help users know which bugs might have security implications.

  https://sourceware.org/cgit/elfutils/tree/SECURITY
  https://sourceware.org/cgit/binutils-gdb/tree/binutils/SECURITY.txt
  https://gcc.gnu.org/cgit/gcc/tree/SECURITY.txt

  The glibc project even setup their own security mailinglist and CNA
  (CVE Numbering Authority) publishing their own advisories:
  https://sourceware.org/glibc/security.html
  https://sourceware.org/cgit/glibc/tree/advisories

  If you need any help adding infrastructure services for your
  security projects, please reach out:
  https://sourceware.org/mission.html#organization

= Summer of Code

  Some Sourceware hosted projects will take part in Summer of Code
  2024. If you are interested in participating please see
  https://gcc.gnu.org/wiki/SummerOfCode
  

Re: CI for "Option handling: add documentation URLs"

[Mark Wielaard]

Hi,

On Thu, Feb 22, 2024 at 11:57:50AM +0800, YunQiang Su wrote:
> Mark Wielaard  于2024年2月19日周一 06:58写道：
> > So, I did try the regenerate-opt-urls locally, and it did generate the
> > attached diff. Which seems to show we really need this automated.
> >
> > Going over the diff. The -Winfinite-recursion in rust does indeed seem
> > new.  As do the -mapx-inline-asm-use-gpr32 and mevex512 for i386.  And
> > the avr options -mskip-bug, -mflmap and mrodata-in-ram.  The change in
> > common.opt.urls for -Wuse-after-free comes from it being moved from
> > c++ to the c-family. The changes in mips.opt.urls seem to come from
> > commit 46df1369 "doc/invoke: Remove duplicate explicit-relocs entry of
> > MIPS".
> >
> 
> For MIPS, it's due to malformed patches to invoke.text.
> I will fix them.

Thanks. So with your commit 00bc8c0998d8 ("invoke.texi: Fix some
skipping UrlSuffix problem for MIPS") pushed now, the attached patch
fixes the remaining issues.

Is this OK to push?

> > The changes in c.opt.urls seem mostly reordering. The sorting makes
> > more sense after the diff imho. And must have come from commit
> > 4666cbde5 "Sort warning options in c-family/c.opt".
> >
> > Also the documentation for -Warray-parameter was fixed.
> >
> > So I think the regenerate-opt-urls check does work as intended. So
> > lets automate it, because it looks like nobody regenerated the
> > url.opts after updating the documentation.
> >
> > But we should first apply this diff. Could you double check it is
> > sane/correct?
> >
> > Thanks,
> >
> > Mark
> 
> 
> 
> -- 
> YunQiang Su
>From c019327e919fff87ffa94799e8f521bda707a883 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Sat, 24 Feb 2024 17:34:05 +0100
Subject: [PATCH] Regenerate opt.urls

There were several commits that didn't regenerate the opt.urls files.

Fixes: 438ef143679e ("rs6000: Neuter option -mpower{8,9}-vector")
Fixes: 50c549ef3db6 ("gccrs: enable -Winfinite-recursion warnings by default")
Fixes: 25bb8a40abd9 ("Move docs for -Wuse-after-free and -Wuseless-cast")
Fixes: 48448055fb70 ("AVR: Support .rodata in Flash for AVR64* and AVR128*")
Fixes: 42503cc257fb ("AVR: Document option -mskip-bug")
Fixes: 7de5bb642c12 ("i386: [APX] Document inline asm behavior and new switch")
Fixes: 49a14ee488b8 ("Add -mevex512 into invoke.texi")
Fixes: 4666cbde5e6d ("Sort warning options in c-family/c.opt.")

gcc/config/
* rs6000/rs6000.opt.urls: Regenerate.
* avr/avr.opt.urls: Likewise.
* i386/i386.opt.urls: Likewise.
* pru/pru.opt.urls: Likewise.
* riscv/riscv.opt.urls: Likewise.

gcc/rust/
* lang.opt.urls: Regenerate.

gcc/
* common.opt.urls: Regenerate.

gcc/c-family/
* c.opt.urls: Regenerate.
---
 gcc/c-family/c.opt.urls   | 351 +++---
 gcc/common.opt.urls   |   4 +-
 gcc/config/avr/avr.opt.urls   |   9 +
 gcc/config/i386/i386.opt.urls |   8 +-
 gcc/config/pru/pru.opt.urls   |   2 +-
 gcc/config/riscv/riscv.opt.urls   |   2 +-
 gcc/config/rs6000/rs6000.opt.urls |   3 -
 gcc/rust/lang.opt.urls|   3 +
 8 files changed, 200 insertions(+), 182 deletions(-)

diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls
index 5365c8e2bc54..9f97dc61a778 100644
--- a/gcc/c-family/c.opt.urls
+++ b/gcc/c-family/c.opt.urls
@@ -88,6 +88,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wabsolute-value)
 Waddress
 UrlSuffix(gcc/Warning-Options.html#index-Waddress)
 
+Waddress-of-packed-member
+UrlSuffix(gcc/Warning-Options.html#index-Waddress-of-packed-member)
+
 Waligned-new
 UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Waligned-new)
 
@@ -115,6 +118,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Walloc-zero)
 Walloca-larger-than=
 UrlSuffix(gcc/Warning-Options.html#index-Walloca-larger-than_003d) 
LangUrlSuffix_D(gdc/Warnings.html#index-Walloca-larger-than)
 
+Warith-conversion
+UrlSuffix(gcc/Warning-Options.html#index-Warith-conversion)
+
 Warray-bounds=
 UrlSuffix(gcc/Warning-Options.html#index-Warray-bounds)
 
@@ -122,13 +128,10 @@ Warray-compare
 UrlSuffix(gcc/Warning-Options.html#index-Warray-compare)
 
 Warray-parameter
-UrlSuffix(gcc/Warning-Options.html#index-Wno-array-parameter)
+UrlSuffix(gcc/Warning-Options.html#index-Warray-parameter)
 
 Warray-parameter=
-UrlSuffix(gcc/Warning-Options.html#index-Wno-array-parameter)
-
-Wzero-length-bounds
-UrlSuffix(gcc/Warning-Options.html#index-Wzero-length-bounds)
+UrlSuffix(gcc/Warning-Options.html#index-Warray-parameter)
 
 Wassign-intercept
 
UrlSuffix(gcc/Objective-C-and-Objective-C_002b_002b-Dialect-Options.html#index-Wassign-intercept)
@@ -148,9 +151,6 @@ UrlSuffix(gcc/Warning-Options.html#index-Wbool-compa

Re: Legal assignment forms for GCC

[Mark Wielaard]

Hi Robert,

On Thu, Feb 22, 2024 at 02:29:03PM -0600, Robert Dubner wrote:
> I anticipate making contributions to GCC on an ongoing basis, and
> according to https://gcc.gnu.org/contribute.html, there are some forms
> that need to be filled out by me and my employer for ".assignment.for all
> future changes, and an employer disclaimer.".
> 
> I hereby request those forms.

The request-assign.future form is here:
https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future
Please fill it out and email it to ass...@gnu.org

More background information can be found here:
https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/conditions.text

Cheers,

Mark

Re: CI for "Option handling: add documentation URLs"

[Mark Wielaard]

On Sun, 2024-02-18 at 23:58 +0100, Mark Wielaard wrote:
> So I think the regenerate-opt-urls check does work as intended. So
> lets automate it, because it looks like nobody regenerated the
> url.opts after updating the documentation.
> 
> But we should first apply this diff. Could you double check it is
> sane/correct?

And then I forgot to attach the diff. Attached now.
Hopefully it is identical for you after doing
  make html && cd gcc && make regenerate-opt-urls
(It is for me having now done it on a debian and fedora x86_64 setup.)

Cheers,

Mark
diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls
index 5365c8e2bc5..9f97dc61a77 100644
--- a/gcc/c-family/c.opt.urls
+++ b/gcc/c-family/c.opt.urls
@@ -88,6 +88,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wabsolute-value)
 Waddress
 UrlSuffix(gcc/Warning-Options.html#index-Waddress)
 
+Waddress-of-packed-member
+UrlSuffix(gcc/Warning-Options.html#index-Waddress-of-packed-member)
+
 Waligned-new
 UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Waligned-new)
 
@@ -115,6 +118,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Walloc-zero)
 Walloca-larger-than=
 UrlSuffix(gcc/Warning-Options.html#index-Walloca-larger-than_003d) LangUrlSuffix_D(gdc/Warnings.html#index-Walloca-larger-than)
 
+Warith-conversion
+UrlSuffix(gcc/Warning-Options.html#index-Warith-conversion)
+
 Warray-bounds=
 UrlSuffix(gcc/Warning-Options.html#index-Warray-bounds)
 
@@ -122,13 +128,10 @@ Warray-compare
 UrlSuffix(gcc/Warning-Options.html#index-Warray-compare)
 
 Warray-parameter
-UrlSuffix(gcc/Warning-Options.html#index-Wno-array-parameter)
+UrlSuffix(gcc/Warning-Options.html#index-Warray-parameter)
 
 Warray-parameter=
-UrlSuffix(gcc/Warning-Options.html#index-Wno-array-parameter)
-
-Wzero-length-bounds
-UrlSuffix(gcc/Warning-Options.html#index-Wzero-length-bounds)
+UrlSuffix(gcc/Warning-Options.html#index-Warray-parameter)
 
 Wassign-intercept
 UrlSuffix(gcc/Objective-C-and-Objective-C_002b_002b-Dialect-Options.html#index-Wassign-intercept)
@@ -148,9 +151,6 @@ UrlSuffix(gcc/Warning-Options.html#index-Wbool-compare)
 Wbool-operation
 UrlSuffix(gcc/Warning-Options.html#index-Wbool-operation)
 
-Wframe-address
-UrlSuffix(gcc/Warning-Options.html#index-Wframe-address)
-
 Wbuiltin-declaration-mismatch
 UrlSuffix(gcc/Warning-Options.html#index-Wbuiltin-declaration-mismatch) LangUrlSuffix_D(gdc/Warnings.html#index-Wbuiltin-declaration-mismatch)
 
@@ -217,6 +217,12 @@ UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wcatch-value)
 Wchar-subscripts
 UrlSuffix(gcc/Warning-Options.html#index-Wchar-subscripts)
 
+Wclass-conversion
+UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wclass-conversion)
+
+Wclass-memaccess
+UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wclass-memaccess)
+
 Wclobbered
 UrlSuffix(gcc/Warning-Options.html#index-Wclobbered)
 
@@ -298,6 +304,12 @@ UrlSuffix(gcc/Warning-Options.html#index-Wdiscarded-qualifiers)
 Wdiv-by-zero
 UrlSuffix(gcc/Warning-Options.html#index-Wdiv-by-zero)
 
+Wdouble-promotion
+UrlSuffix(gcc/Warning-Options.html#index-Wdouble-promotion)
+
+Wduplicate-decl-specifier
+UrlSuffix(gcc/Warning-Options.html#index-Wduplicate-decl-specifier)
+
 Wduplicated-branches
 UrlSuffix(gcc/Warning-Options.html#index-Wduplicated-branches)
 
@@ -307,6 +319,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wduplicated-cond)
 Weffc++
 UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Weffc_002b_002b)
 
+Welaborated-enum-base
+UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Welaborated-enum-base)
+
 Wempty-body
 UrlSuffix(gcc/Warning-Options.html#index-Wempty-body)
 
@@ -328,12 +343,18 @@ UrlSuffix(gcc/Warning-Options.html#index-Werror) LangUrlSuffix_D(gdc/Warnings.ht
 Wexceptions
 UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wexceptions)
 
+Wexpansion-to-defined
+UrlSuffix(gcc/Warning-Options.html#index-Wexpansion-to-defined)
+
 Wextra
 UrlSuffix(gcc/Warning-Options.html#index-Wextra) LangUrlSuffix_D(gdc/Warnings.html#index-Wextra)
 
 Wextra-semi
 UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wextra-semi)
 
+Wflex-array-member-not-at-end
+UrlSuffix(gcc/Warning-Options.html#index-Wflex-array-member-not-at-end)
+
 Wfloat-conversion
 UrlSuffix(gcc/Warning-Options.html#index-Wfloat-conversion)
 
@@ -355,6 +376,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wformat-nonliteral)
 Wformat-overflow
 UrlSuffix(gcc/Warning-Options.html#index-Wformat-overflow)
 
+Wformat-overflow=
+UrlSuffix(gcc/Warning-Options.html#index-Wformat-overflow)
+
 Wformat-security
 UrlSuffix(gcc/Warning-Options.html#index-Wformat-security)
 
@@ -364,6 +388,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wformat-signedness)
 Wformat-truncation
 UrlSuffix(gcc/Warning-Options.html#index-Wformat-truncation)
 
+Wformat-truncation=
+UrlSuffix(gcc/Warning-Options.html#index-Wformat-truncation)
+
 Wformat-y2k
 UrlSuffix(gcc/Warning-Options.html#index-Wformat-y2k)
 
@@ -373,14 +400,8 @@ UrlSuffix(gcc/Warning-Options.html#index-Wformat

Re: CI for "Option handling: add documentation URLs"

[Mark Wielaard]

Hi David,

On Thu, Jan 04, 2024 at 09:57:09AM -0500, David Malcolm wrote:
> I've pushed the .opt.urls patch kit to gcc trunk [1], so hopefully the
> CI check you wrote can go live now.

And then I was on vacation myself and forgot. I am sorry.

So, I did try the regenerate-opt-urls locally, and it did generate the
attached diff. Which seems to show we really need this automated.

Going over the diff. The -Winfinite-recursion in rust does indeed seem
new.  As do the -mapx-inline-asm-use-gpr32 and mevex512 for i386.  And
the avr options -mskip-bug, -mflmap and mrodata-in-ram.  The change in
common.opt.urls for -Wuse-after-free comes from it being moved from
c++ to the c-family. The changes in mips.opt.urls seem to come from
commit 46df1369 "doc/invoke: Remove duplicate explicit-relocs entry of
MIPS".

The changes in c.opt.urls seem mostly reordering. The sorting makes
more sense after the diff imho. And must have come from commit
4666cbde5 "Sort warning options in c-family/c.opt".

Also the documentation for -Warray-parameter was fixed.

So I think the regenerate-opt-urls check does work as intended. So
lets automate it, because it looks like nobody regenerated the
url.opts after updating the documentation.

But we should first apply this diff. Could you double check it is
sane/correct?

Thanks,

Mark

Sourceware Open Office, Friday February 9, 18:00 UTC

[Mark Wielaard]

Hi Sourceware projects hackers,

2024 started strong with various Sourceware core toolchain and
developer tool projects presenting at Fosdem. If you missed the in
person meetings, most talks have video recordings:

https://fosdem.org/2024/schedule/track/debuggers-and-analysis/
https://fosdem.org/2024/schedule/track/gcc/

Various Sourceware volunteers, overseers and project leadership
committee members also met informally with FSF/GNU and SFC admins to
coordinate cross free software infrastructure administration matters.

If you want to chat about any of this, please join us this Friday,
February 9, in #overseers on irc.libera.chat from 18:00 till 19:00 UTC.

Want to update your gitweb URLs to cgit? Need help adjusting
infrastructure tools for more efficient contributor workflows? Setting
up a git backed documentation/website? Have ideas or opinions on secure
supply chain and code signing? Want to take advantage of the new risc-v
VisionFive-2 boards that StarFive donated for buildbot CI runs?

In general for any questions or ideas about any Sourceware service
and/or integration of cgit, bugzilla, mailinglists, snapshots, mirrors,
archiving, gitsigur, public-inbox, b4, patchwork, bbb, buildbot, etc.
we are here to help.

For this meeting we will also have a BBB meeting room:
https://bbb.sfconservancy.org/b/mar-aom-dmo-fko
(But the real discussion will be in the irc channel)

If you want to run your own meetings for any Sourceware project you can
create your own account at https://bbb.sfconservancy.org/b/signup which
we can then activate for you. Note: Anyone is able to join a meeting,
accounts are only required to create new meetings.

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

Thanks to the Conservancy we now also have a donation page:
  https://sourceware.org/donate.html
to fund accelerating tasks the community feels most useful. More
details about our relationship with the Conservancy here:
https://sfconservancy.org/blog/2023/nov/27/sourceware-thanks-conservancy/

If you aren't already and want to keep up to date on Sourceware
infrastructure services then please also subscribe to the overseers
mailinglist. https://sourceware.org/mailman/listinfo/overseers

We are also on the fediverse these days:
https://fosstodon.org/@sourceware

The Sourceware Project Leadership Committee also meets once a month to
discuss all community input. The committee will set priorities and
decide how to spend any funds, negotiate with hardware and service
partners, create budgets together with the Conservancy, or decides when
a new fundraising campaign is needed. The current committee includes
Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor,
Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni.

Core Toolchain and Developer Tools at FOSDEM

[Mark Wielaard]

Fosdem is next weekend, February 3 & 4, in Brussels.  Guinevere,
Dodji, Jose, David and Thomas organized some great devroom talks:

On Saturday, 15:00 to 18:20, the Debugger and Analysis Devroom
https://fosdem.org/2024/schedule/track/debuggers-and-analysis/

  Debug your stage-1 systemd with GDB and the NixOS test framework
Ryan Lahfa, Julien Malka, Linus Heckemann
  Love rr, Love rr, you're so good to me
Vicențiu Ciorbaru
  Help us improve time manipulation with GDB
Guinevere Larsen
  ROCgdb, GDB and AMDGPU debugging
Lancelot SIX
  GDB on Windows: status & plans
Pedro Alves
  Online Debugging and ABI Data Services
Frank Ch. Eigler
  Poke all the microcontrollers!
Mohammad-Reza Nabipoor
  Verrou : a valgrind tool dedicated to floating point error diagnosis
LATHUILIERE Bruno

Also on Saturday from 11:40 to 12:20 in the Rust devroom Arthur Cohen
will talk about The plan for gccrs
https://fosdem.org/2024/schedule/event/fosdem-2024-2207-the-plan-for-gccrs/

On Sunday, from 9:00 to 12:45, the GCC devroom
https://fosdem.org/2024/schedule/track/gcc/

  Welcome to the GCC dev room
David Malcolm, Thomas Schwinge
  GCC for new contributors
David Malcolm
  How to bring up GCC for your new chip
Jeremy Bennett
  My experience as a first time contributor to GCC's LTO
Rishi Raj
  Unicode Support for GCC Rust
Raiki Tamura
  What can Compiler-Explorer do for GCC
Marc Poulhiès
  Unlocking Secret Analysis in GCC Static Analyzer
Pierrick Philippe
  Yacking about Bison
James Lowden
  Can the mold linker be /usr/bin/ld?
Rui Ueyama
  Build Distribution for Maintaining the Famous GCC 4.7
Oliver Reiche
  Sega Dreamcast Homebrew with GCC
Falco Girgis

Various Sourceware volunteers, overseers, PLC members and Software
Freedom Conservancy staff will also be around.

For those we cannot attend in person the talks will be recorded.

Sourceware Open Office, Friday January 12, 18:00 UTC

[Mark Wielaard]

Happy new year!
This Friday will be the first Sourceware Open Office of 2024.

Join us this Friday, January 12, in #overseers on irc.libera.chat
from 18:00 till 19:00 UTC. 

For any questions or ideas about any Sourceware service and/or
integration of cgit, bugzilla, mailinglists, snapshots, mirrors,
archiving, gitsigur, secure supply chains, public-inbox, b4,
patchwork, bbb, buildbot (now including a risc-v board), etc.

For this meeting we will also have a BBB meeting room:
https://bbb.sfconservancy.org/b/mar-aom-dmo-fko
(But the real discussion will be in the irc channel)

If you want to run your own meetings for any Sourceware project you
can create your own account at https://bbb.sfconservancy.org/b/signup
which we can then activate for you. Note: Anyone is able to join a
meeting, accounts are only required to create new meetings.

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

Thanks to the Conservancy we now also have a donation page:
  https://sourceware.org/donate.html
to fund accelerating tasks the community feels most useful.
More details about our relationship with the Conservancy here:
https://sfconservancy.org/blog/2023/nov/27/sourceware-thanks-conservancy/

If you aren't already and want to keep up to date on Sourceware
infrastructure services then please also subscribe to the overseers
mailinglist. https://sourceware.org/mailman/listinfo/overseers

We are also on the fediverse these days:
https://fosstodon.org/@sourceware

The Sourceware Project Leadership Committee also meets once a month
to discuss all community input. The committee will set priorities and
decide how to spend any funds, negotiate with hardware and service
partners, create budgets together with the Conservancy, or decides
when a new fundraising campaign is needed. Up till now we have been
able to add new services without needing to use any of the collected
funds. Our hardware partners have also been very generous with
providing extra servers when requested. The current committee includes
Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor,
Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni.

[COMMITTED] Regenerate libgomp/configure for copyright year update

[Mark Wielaard]

commit a945c346f57ba40fc80c14ac59be0d43624e559d updated
libgomp/plugin/configfrag.ac but didn't regenerate/update
libgomp/configure which includes that configfrag.

libgomp/Changelog:

* configure: Regenerate.
---
 libgomp/configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgomp/configure b/libgomp/configure
index c69a13cfe14..b3646c9936d 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15159,7 +15159,7 @@ _ACEOF
 
 # Plugins for offload execution, configure.ac fragment.  -*- mode: autoconf -*-
 #
-# Copyright (C) 2014-2023 Free Software Foundation, Inc.
+# Copyright (C) 2014-2024 Free Software Foundation, Inc.
 #
 # Contributed by Mentor Embedded.
 #
-- 
2.39.3

[COMMITTED] robots.txt: Disallow a few more bugzilla queries

[Mark Wielaard]

Some spiders are hitting bugzilla hard generating dependency trees
or graphs, downloading large attachements or requesting all bugs
in xml format. Disallow all that.
---
 htdocs/robots.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index b9fc830d..057c5899 100644
--- a/htdocs/robots.txt
+++ b/htdocs/robots.txt
@@ -10,4 +10,8 @@ Disallow: /cgit/
 Disallow: /svn
 Disallow: /cgi-bin/
 Disallow: /bugzilla/buglist.cgi
+Disallow: /bugzilla/show_bug.cgi*ctype=xml*
+Disallow: /bugzilla/attachment.cgi
+Disallow: /bugzilla/showdependencygraph.cgi
+Disallow: /bugzilla/showdependencytree.cgi
 Crawl-Delay: 60
-- 
2.39.3

Re: [PATCH 0/4] v3 of: Option handling: add documentation URLs

[Mark Wielaard]

Hi David,

On Thu, Dec 14, 2023 at 10:01:39AM -0500, David Malcolm wrote:
> > Once your patch is in please feel free to sent an email to
> > build...@sourceware.org
> > https://sourceware.org/mailman/listinfo/buildbot
> > And we'll add the above build steps and update the autotools
> > Containerfile to include the fortran (gfortran?) and d (gdc?) build
> > dependencies.
> 
> Joseph: it seems that we have a way to add CI for this.
> 
> I refreshed the patches and successfully bootstrapped & regrtested them
> on x86_64-pc-linux-gnu; here's the v3 version of them.
> 
> Are these OK for trunk, assuming I followup with adding CI for this?
> (that said, I disappear for the rest of 2023 at the end of this week, so
> I'd work on the CI in early January)

I will be around next week to fixup any CI issues.
But once you commit this we can immediate activate the check.

I have attached a patch for the gcc-autoregen builder to also do
regenerate-opt-urls. Since it is a --disable-bootstrap build and uses
ccache it should take just a few minutes. So can be done on every
commit.

Note that with you patch applied to master it does flag and generate
the attached diff (I assume that is expected).

Cheers,

Mark>From 83914698dfb77a85496e93e3faa5de9131347cb8 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Fri, 15 Dec 2023 01:43:27 +0100
Subject: [PATCH] Add regenerate-opt-urls to gcc-autoregen

Add gcc build dependencies and ccacheto Containerfile-autotools.
Add regenerate_opt_urls steps to gcc_autoregen_factory.
---
 builder/containers/Containerfile-autotools |  2 ++
 builder/master.cfg | 34 ++
 2 files changed, 36 insertions(+)

diff --git a/builder/containers/Containerfile-autotools 
b/builder/containers/Containerfile-autotools
index 1099986..8cc8a22 100644
--- a/builder/containers/Containerfile-autotools
+++ b/builder/containers/Containerfile-autotools
@@ -7,6 +7,8 @@ RUN apt-get update && \
 apt-get upgrade -y && \
 apt-get install -y \
   build-essential libtool perl python3-minimal bash \
+  libmpc-dev libgmp-dev libmpfr-dev gdc texinfo flex \
+  ccache \
   make git \
   gettext \
   m4 pkg-config \
diff --git a/builder/master.cfg b/builder/master.cfg
index 04c54da..0e5ce62 100644
--- a/builder/master.cfg
+++ b/builder/master.cfg
@@ -1200,6 +1200,35 @@ git_diff_step = steps.ShellCommand(
 name="git diff",
 haltOnFailure=True)
 
+# Note that the name of the default workdir is 'build'
+# 'build' is the name of the source checkout (yes, confusing).
+# So this creates 'build/objdir'.
+gcc_build_mkdir_step = steps.ShellCommand(
+command=['mkdir', '-p', 'objdir'],
+name='mkdir objdir',
+haltOnFailure=True)
+
+gcc_configure_opt_urls_step = steps.Configure(
+workdir='build/objdir',
+command=["../configure",
+ "--disable-multilib",
+ "--disable-bootstrap",
+ "--enable-languages=c,d,fortran"],
+name="configure",
+haltOnFailure=True)
+
+gcc_make_html_step = steps.Compile(
+workdir='build/objdir',
+command=['make', util.Interpolate('-j%(prop:ncpus)s'), 'html'],
+name='make html',
+haltOnFailure=True)
+
+gcc_make_regenerate_opt_urls_step = steps.Compile(
+workdir='build/objdir/gcc',
+command=['make', 'regenerate-opt-urls'],
+name='make regenerate-opt-urls',
+haltOnFailure=True)
+
 # Generic make clean step to be run at the end of a build
 make_clean_step = steps.ShellCommand(
 command=["make", "clean"],
@@ -3454,6 +3483,11 @@ gcc_autoregen_factory = util.BuildFactory()
 gcc_autoregen_factory.addStep(gcc_git_step)
 gcc_autoregen_factory.addStep(autoregen_step)
 gcc_autoregen_factory.addStep(git_diff_step)
+gcc_autoregen_factory.addStep(gcc_build_mkdir_step)
+gcc_autoregen_factory.addStep(gcc_configure_opt_urls_step)
+gcc_autoregen_factory.addStep(gcc_make_html_step)
+gcc_autoregen_factory.addStep(gcc_make_regenerate_opt_urls_step)
+gcc_autoregen_factory.addStep(git_diff_step)
 
 gcc_autoregen_builder = util.BuilderConfig(
 name="gcc-autoregen",
-- 
2.39.3

diff --git a/gcc/analyzer/analyzer.opt.urls b/gcc/analyzer/analyzer.opt.urls
index 9f7d33ff434..5fcab720582 100644
--- a/gcc/analyzer/analyzer.opt.urls
+++ b/gcc/analyzer/analyzer.opt.urls
@@ -48,6 +48,9 @@ 
UrlSuffix(gcc/Static-Analyzer-Options.html#index-Wanalyzer-free-of-non-heap)
 Wanalyzer-imprecise-fp-arithmetic
 
UrlSuffix(gcc/Static-Analyzer-Options.html#index-Wanalyzer-imprecise-fp-arithmetic)
 
+Wanalyzer-infinite-loop
+UrlSuffix(gcc/Static-Analyzer-Options.html#index-Wanalyzer-infinite-loop)
+
 Wanalyzer-infinite-recursion
 UrlSuffix(gcc/Static-Analyzer-Options.html#index-Wanalyzer-infinite-recursion)
 
@@ -111,6 +114,9

Re: [PATCH 0/4] v2 of Option handling: add documentation URLs

[Mark Wielaard]

Hi David,

On Fri, Dec 08, 2023 at 06:35:56PM -0500, David Malcolm wrote:
> On Tue, 2023-11-21 at 23:43 +, Joseph Myers wrote:
> > On Tue, 21 Nov 2023, Tobias Burnus wrote:
> > 
> > > On 21.11.23 14:57, David Malcolm wrote:
> > > > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
> > > > > Sorry for barging in though I did try finding the relevant
> > > > > discussion, but is committing this generated stuff necessary?
> > > > > Is it because we don't want to depend on Python being
> > > > > present at build time?
> > > > Partly, yes, [...]
> > > 
> > > I wonder how to ensure that this remains up to date. Should there
> > > be an item at
> > > 
> > > https://gcc.gnu.org/branching.html and/or
> > > https://gcc.gnu.org/releasing.html similar to the .pot generation?
> >
> > My suggestion earlier in the discussion was that it should be
> > added to the post-commit CI discussed starting at
> >  (I
> > think that CI is now in operation).  These are generated files
> > that ought to be kept up to date with each commit that affects
> > .opt files, unlike the .pot files where the expectation is that
> > they should be up to date for releases and updated from time to
> > time at other times for submission to the TP.
> > 
> I had a go at scripting the testing of this, but I am terrible at shell
> scripts (maybe I should use Python?).  Here's what I have so far:
> 
> $ cat contrib/regenerate-index-urls.sh
> 
> set -x
> 
> SRC_DIR=$1
> BUILD_DIR=$2
> NUM_JOBS=$3
> 
> # FIXME: error-checking!
> 
> mkdir -p $BUILD_DIR || exit 1
> cd $BUILD_DIR
> $SRC_DIR/configure --disable-bootstrap --enable-languages=c,d,fortran || exit 
> 2
> make html-gcc -j$NUM_JOBS || exit 3
> cd gcc || exit 4
> make regenerate-opt-urls || exit 5
> cd $SRC_DIR
> (git diff $1 > /dev/null ) && echo "regenerate-opt-urls needs to be run and 
> the results committed" || exit 6
> 
> # e.g.
> #  time bash contrib/regenerate-index-urls.sh $(pwd) $(pwd)/../build-ci 64
> 
> This takes about 100 seconds of wallclock on my 64-core box (mostly
> configuring gcc, which as well as the usual sequence of unparallelized
> tests seems to require building libiberty and lto-plugin).  Is that
> something we want to do on every commit?  Is implementing the CI a
> blocker for getting the patches in? (if so, I'll likely need some help)

The CI builers don't have 64-cores, but a couple of hundred seconds
shouldn't be an issue to do on each commit (OSUOSL just got us a
second x86_64 container builder for larger jobs). The above can easily
be added to the existing gcc-autoregen builder:
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
https://sourceware.org/cgit/builder/tree/builder/master.cfg#n3453

Once your patch is in please feel free to sent an email to
build...@sourceware.org
https://sourceware.org/mailman/listinfo/buildbot
And we'll add the above build steps and update the autotools
Containerfile to include the fortran (gfortran?) and d (gdc?) build
dependencies.

Cheers,

Mark

[gcc-wwwdocs COMMITTED] Disallow /cgit for web robots

[Mark Wielaard]

Although cgit is more efficient than gitweb it still is not great
for bots to go through it.
---
 htdocs/robots.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index c650057b..b9fc830d 100644
--- a/htdocs/robots.txt
+++ b/htdocs/robots.txt
@@ -6,6 +6,7 @@ User-agent: *
 Disallow: /viewvc/
 Disallow: /viewcvs
 Disallow: /git/
+Disallow: /cgit/
 Disallow: /svn
 Disallow: /cgi-bin/
 Disallow: /bugzilla/buglist.cgi
-- 
2.39.3

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

[Mark Wielaard]

Hi,

On Fri, 2023-12-01 at 13:09 +0100, Jakub Jelinek via Gcc wrote:
> On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote:
> > > On Dez 01 2023, Richard Biener via Gcc wrote:
> > > 
> > > > Hmm, so why's it then referenced and not "GCed"?
> > > 
> > > This has nothing to do with garbage collection.  It's just the way
> > > libgcc avoids having too many source files.  It would be exactly the
> > > same if every function were in its own file.
> > 
> > THe ifdef machinery makes every function to go insto its own .o file
> > which are then archived.  So if user code never calls to fork, the .o
> > file with fork wrapper should not be picked by linker and we should not
> > have link error.
> > 
> > If user code calls fork, then the .o file with wrapper should be picked
> > and we will get linker error on missing fork.  So I think it ought to
> > work as it is now.  Does mingw linker behave somehow differently with
> > archives?  Or is there problem with a libgcov being DLL or something?
> 
> The problem is that the changes to switch to modern C result in calls to
> unprototyped function being an error rather than just warning as before.
> int foo (void) { return fork (); }
> warning: implicit declaration of function ‘fork’ 
> [-Wimplicit-function-declaration]
> previously, now
> error: implicit declaration of function ‘fork’ 
> [-Wimplicit-function-declaration]
> (by default in C99+).
> 
> So, as has been discussed earlier, either we should use __builtin_fork ()
> rather than fork (), or we need in configure to test for fork prototype and
> if missing, prototype it ourselves, or ensure _gcov_fork.o is not compiled
> on targets which don't have fork prototyped.

BTW. The gcc-fedora-mingw buildbot has been broken because of this
issue for the last week:

https://builder.sourceware.org/buildbot/#/builders/gcc-fedora-mingw
../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit
declaration of function 'fork' [-Wimplicit-function-declaration]
  185 |   pid = fork ();
  | ^~~~
make[2]: *** [Makefile:935: _gcov_fork.o] Error 1

Cheers,

Mark

Sourceware infrastructure updates for Q4 2023

[Mark Wielaard]

Sourceware infrastructure community updates for Q4 2023

- 6 months with the Software Freedom Conservancy
- Sourceware @ Fosdem
- OSUOSL provides extra larger arm64 and x86_64 buildbot servers
- No more From rewriting for patches mailinglists

= 6 months with the Software Freedom Conservancy

Sourceware thanks Conservancy for their support and urges the
community to support Conservancy.

Sourceware has only been a Software Freedom Conservancy member project
for just 6 months. But the story started a long time ago and a lot has
happened in that time:

https://sfconservancy.org/blog/2023/nov/27/sourceware-thanks-conservancy/

We hope the community will support the Software Freedom Conservancy
2023 Fundraiser and become a Conservancy Sustainer
https://sfconservancy.org/sustainer

= Sourceware @ Fosdem 

Various Sourceware projects will be present at Fosdem plus some
overseers and of course Conservancy staff.

Get your talk submissions in before end of the week (December 1st) to
these developer rooms:

Debuggers and Analysis tools
gdb, libabigail, systemtap, valgrind, binutils, elfutils, gnupoke, cgen
https://inbox.sourceware.org/6a2e8cbf-0d63-24e7-e3c2-c3d286e2e...@redhat.com/

GCC compiler devroom
gcc, binutils, glibc, newlib
https://inbox.sourceware.org/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com/

And if you like to organize an online virtual mini-BoF around some
topic or project then the @conservancy BBB server is available for all
Sourceware projects.

https://inbox.sourceware.org/9ca90cd013675a960d47ee09fa4403f69405e9f2.ca...@klomp.org/

= OSUOSL provides extra larger arm64 and x86_64 buildbot servers

There have been complaints about overloaded builders. So OSUOSL have
provided us with another arm64 and x86_64 server. The new servers do
the larger gcc and glibc builds so the other builders can do quicker
(smaller) CI builds without having to wait on the big jobs.

This also frees up the other container builders to do more automated
jobs like the recently added autotools generated files checker for
gcc, binutils and gdb:
https://inbox.sourceware.org/20231115194803.gw31...@gnu.wildebeest.org/

Please contact the builder project build...@sourceware.org if you want
to run some automated jobs on https://builder.sourceware.org/

= No more From rewriting for patches mailinglists

Because of dkim, strict dmarc policies and an old mailman setup
Sourceware mailinglists used From rewriting.

No more! We upgraded mailman, gave up subject prefixes, mail footers,
html stripping and reply-to mangling.

After the libc-alpha and gcc-patches mailinglist tests to avoid From
rewriting worked out nicely we enabled the same settings to some other
mailinglists. The gcc patches lists for libstdc++, libgccjit, fortran
and gcc-rust. And for those projects that use patchwork, newlib,
elfutils, libabigail and gdb.

This hopefully makes mailing patches and using git am on them a bit
nicer. 

Outgoing sourceware email now also includes ARC headers.
https://en.wikipedia.org/wiki/Authenticated_Received_Chain
Feedback on whether this helps email delivery appreciated.

Please contact overseers if you would like the new setting for any
other Sourceware mailinglist.

Thanks to the FSF tech-team for walking us through their setup for
lists.gnu.org

Sourceware infrastructure updates for Q4 2023

[Mark Wielaard]

Sourceware infrastructure community updates for Q4 2023

- 6 months with the Software Freedom Conservancy
- Sourceware @ Fosdem
- OSUOSL provides extra larger arm64 and x86_64 buildbot servers
- No more From rewriting for patches mailinglists

= 6 months with the Software Freedom Conservancy

Sourceware thanks Conservancy for their support and urges the
community to support Conservancy.

Sourceware has only been a Software Freedom Conservancy member project
for just 6 months. But the story started a long time ago and a lot has
happened in that time:

https://sfconservancy.org/blog/2023/nov/27/sourceware-thanks-conservancy/

We hope the community will support the Software Freedom Conservancy
2023 Fundraiser and become a Conservancy Sustainer
https://sfconservancy.org/sustainer

= Sourceware @ Fosdem 

Various Sourceware projects will be present at Fosdem plus some
overseers and of course Conservancy staff.

Get your talk submissions in before end of the week (December 1st) to
these developer rooms:

Debuggers and Analysis tools
gdb, libabigail, systemtap, valgrind, binutils, elfutils, gnupoke, cgen
https://inbox.sourceware.org/6a2e8cbf-0d63-24e7-e3c2-c3d286e2e...@redhat.com/

GCC compiler devroom
gcc, binutils, glibc, newlib
https://inbox.sourceware.org/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com/

And if you like to organize an online virtual mini-BoF around some
topic or project then the @conservancy BBB server is available for all
Sourceware projects.

https://inbox.sourceware.org/9ca90cd013675a960d47ee09fa4403f69405e9f2.ca...@klomp.org/

= OSUOSL provides extra larger arm64 and x86_64 buildbot servers

There have been complaints about overloaded builders. So OSUOSL have
provided us with another arm64 and x86_64 server. The new servers do
the larger gcc and glibc builds so the other builders can do quicker
(smaller) CI builds without having to wait on the big jobs.

This also frees up the other container builders to do more automated
jobs like the recently added autotools generated files checker for
gcc, binutils and gdb:
https://inbox.sourceware.org/20231115194803.gw31...@gnu.wildebeest.org/

Please contact the builder project build...@sourceware.org if you want
to run some automated jobs on https://builder.sourceware.org/

= No more From rewriting for patches mailinglists

Because of dkim, strict dmarc policies and an old mailman setup
Sourceware mailinglists used From rewriting.

No more! We upgraded mailman, gave up subject prefixes, mail footers,
html stripping and reply-to mangling.

After the libc-alpha and gcc-patches mailinglist tests to avoid From
rewriting worked out nicely we enabled the same settings to some other
mailinglists. The gcc patches lists for libstdc++, libgccjit, fortran
and gcc-rust. And for those projects that use patchwork, newlib,
elfutils, libabigail and gdb.

This hopefully makes mailing patches and using git am on them a bit
nicer. 

Outgoing sourceware email now also includes ARC headers.
https://en.wikipedia.org/wiki/Authenticated_Received_Chain
Feedback on whether this helps email delivery appreciated.

Please contact overseers if you would like the new setting for any
other Sourceware mailinglist.

Thanks to the FSF tech-team for walking us through their setup for
lists.gnu.org

[COMMITTED] Regenerate libiberty/aclocal.m4 with aclocal 1.15.1

[Mark Wielaard]

There is a new buildbot check that all autotool files are generated
with the correct versions (automake 1.15.1 and autoconf 2.69).
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen

Correct one file that was generated with the wrong version.

libiberty/
* aclocal.m4: Rebuild.
---
 libiberty/aclocal.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4
index f327865aaf9..0757688d52a 100644
--- a/libiberty/aclocal.m4
+++ b/libiberty/aclocal.m4
@@ -1,6 +1,6 @@
-# generated automatically by aclocal 1.16.5 -*- Autoconf -*-
+# generated automatically by aclocal 1.15.1 -*- Autoconf -*-
 
-# Copyright (C) 1996-2021 Free Software Foundation, Inc.
+# Copyright (C) 1996-2017 Free Software Foundation, Inc.
 
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
-- 
2.39.3

Re: Checks that autotools generated files were re-generated correctly

[Mark Wielaard]

Hi! (adding gdb and binutils to the CC)

On Thu, Nov 09, 2023 at 12:30:59AM +0100, Mark Wielaard wrote:
> On Mon, Nov 06, 2023 at 06:04:48PM +0100, Martin Jambor wrote:
> > I have inherited Martin Liška's buildbot script that checks that all
> > sorts of autotools generated files, mainly configure scripts, were
> > re-generated correctly when appropriate.  While the checks are hopefully
> > useful, they report issues surprisingly often and reporting them feels
> > especially unproductive.
> 
> Cool! A small python script cannot replace him of course. But it is
> nice to get a small virtual mliska :)
> 
> > Could such checks be added to our server side push hooks so that commits
> > introducing these breakages would get refused automatically.  While the
> > check might be a bit expensive, it only needs to be run on files
> > touching the generated files and/or the files these are generated from.
> 
> So this doesn't just need that script, but also an execution
> environment that contains the right versions of the autotools. We
> could install those of course, but running them from a git hook on
> checkin indeed seems a little expensive.
> 
> Creating a container with the script and the right versions of all
> tools might be the best thing. Then the script can be run from a cron
> job or buildbot. Or even by someone hacking on the build/configure
> scripts to make sure they are generating with the right tools.
> 
> builder.sourceware.org already contains various of such containers:
> https://sourceware.org/cgit/builder/tree/builder/containers
> https://sourceware.org/cgit/builder/tree/README_containers
> 
> Friday is Sourceware Open Office hour (#overseers on irc.libera.chat
> at 18:00 UTC). We could hack something together then and see how to
> hook it up.

So we did indeed discuss and hack something together.

The container file is here:
https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools

The script is here:
https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py

A buildbot can then use that container to run that script and then
check that git diff is empty on every commit to binutils-gdb.git and
gcc.git. If it finds an issue it will sent email with the diff.

It already found issues in both gcc and binutils-gdb. All fixed now.

Thanks to Arsen and Sam for testing, fixing and updating the script
(it now also runs aclocal).

If you want to run this locally you can use the container file to
create an image and then run autoregen.py on your local tree by bind
mounting your git tree inside it.

$ git clone https://sourceware.org/git/builder.git
$ cd builder/
$ podman build -t autotools -f builder/containers/Containerfile-autotools \
  builder/containers
$ cd .. # assuming your binutils-gdb directory is here
$ podman run --privileged -u root -v $(pwd)/binutils-gdb:/binutils-gdb \
  -ti --entrypoint "/bin/bash" autotools
# then inside the container
 cd /binutils-gdb
 autoregen.py

Change binutils-gdb to gcc if you are working on gcc.
You should also be able to do the above with docker instead of podman.

Cheers,

Mark

Sourceware Open Office, Friday Novemer 10, 18:00 UTC

[Mark Wielaard]

Every second Friday of the month is the Sourceware Overseers Open
Office hour in #overseers on irc.libera.chat from 18:00 till 19:00
UTC. That is this Friday October 10th.

This time we will probably focus on integration of builder CI, Full,
Try builds and patchwork PreCommit-CI. But please feel free to drop by
with any Sourceware services and hosting questions. Or any services
that integrates with builder.sourceware.org, patchwork.sourceware.org
or snapshots.sourceware.org.

For this meeting we will also have a BBB meeting room:
https://bbb.sfconservancy.org/b/mar-aom-dmo-fko
(But the real discussion will be in the irc channel)

If you want to run your own meetings for any Sourceware project you
can create your own account at https://bbb.sfconservancy.org/b/signup
which we can then activate for you. Note: Anyone is able to join a
meeting, accounts are only required to create new meetings.

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

If you aren't already and want to keep up to date on Sourceware
infrastructure services then please also subscribe to the overseers
mailinglist. https://sourceware.org/mailman/listinfo/overseers

We are also on the fediverse these days:
https://fosstodon.org/@sourceware

The Sourceware Project Leadership Committee also meets once a month to
discuss all community input. The committee will set priorities and
decide how to spend any funds, negotiate with hardware and service
partners, create budgets together with the Conservancy, or decides
when a new fundraising campaign is needed. Up till now we have been
able to add new services without needing to use any of the collected
funds. Our hardware partners have also been very generous with
providing extra servers when requested. The current committee includes
Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor,
Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni.

Re: Checks that autotools generated files were re-generated correctly

[Mark Wielaard]

Hi Martin,

On Mon, Nov 06, 2023 at 06:04:48PM +0100, Martin Jambor wrote:
> I have inherited Martin Liška's buildbot script that checks that all
> sorts of autotools generated files, mainly configure scripts, were
> re-generated correctly when appropriate.  While the checks are hopefully
> useful, they report issues surprisingly often and reporting them feels
> especially unproductive.

Cool! A small python script cannot replace him of course. But it is
nice to get a small virtual mliska :)

> Could such checks be added to our server side push hooks so that commits
> introducing these breakages would get refused automatically.  While the
> check might be a bit expensive, it only needs to be run on files
> touching the generated files and/or the files these are generated from.

So this doesn't just need that script, but also an execution
environment that contains the right versions of the autotools. We
could install those of course, but running them from a git hook on
checkin indeed seems a little expensive.

Creating a container with the script and the right versions of all
tools might be the best thing. Then the script can be run from a cron
job or buildbot. Or even by someone hacking on the build/configure
scripts to make sure they are generating with the right tools.

builder.sourceware.org already contains various of such containers:
https://sourceware.org/cgit/builder/tree/builder/containers
https://sourceware.org/cgit/builder/tree/README_containers

Friday is Sourceware Open Office hour (#overseers on irc.libera.chat
at 18:00 UTC). We could hack something together then and see how to
hook it up.

Cheers,

Mark

Sourceware Open Office, Friday October 13, 18:00 UTC

[Mark Wielaard]

Every second Friday of the month is the Sourceware Overseers Open
Office hour in #overseers on irc.libera.chat from 18:00 till 19:00
UTC. That is this Friday October 13th.

Please feel free to drop by with any Sourceware services and hosting
questions. Some specific topics we will likely discuss:

- Mailinglists

  Last month we changed the settings on various project patches
  mailinglists to avoid From rewriting. We also got various requests
  for special security and code of conduct lists. If your project
  needs an extra mailinglist, or you have questions about settings,
  admin or moderation, please reach out.

- Online mini BoFs

  One item that came up at Cauldron last month was about meeting more
  frequently in smaller (virtual) groups.

  Thanks to our fiscal sponsor, Software Freedom Conservancy, all
  Sourceware projects can use their Big Blue Button instance to
  organize online mini BoFs or for having periodic meetings for their
  project.

  For this meeting we will also have a BBB meeting room:
  https://bbb.sfconservancy.org/b/mar-aom-dmo-fko

  Please participate to test it out. You can also create your own
  account at https://bbb.sfconservancy.org/b/signup which we can then
  activate for you. Note: Anyone is able to join a meeting, accounts
  are only required to create new meetings.

- Integrate builder CI, Full and Try builds and patchwork PreCommit-CI

  https://builder.sourceware.org/ runs CI, Full and Try builders for
  various projects, https://patchwork.sourceware.org/ collects patches
  and can run Pre-Commit CI for various projects. It should be
  possible to combine the two so the buildbot CI, Full and Try
  builders can also be triggered by new patchwork patches and
  patchwork receives Checks from builder for completed builds with all
  test results going into the bunsen database.

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

If you aren't already and want to keep up to date on Sourceware
infrastructure services then please also subscribe to the overseers
mailinglist. https://sourceware.org/mailman/listinfo/overseers

We are also on the fediverse these days:
https://fosstodon.org/@sourceware

The Sourceware Project Leadership Committee also meets once a month to
discuss all community input. The committee will set priorities and
decide how to spend any funds, negotiate with hardware and service
partners, create budgets together with the Conservancy, or decides
when a new fundraising campaign is needed. Up till now we have been
able to add new services without needing to use any of the collected
funds. Our hardware partners have also been very generous with
providing extra servers when requested. The current committee includes
Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor,
Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni.

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi Gerald,

On Wed, Oct 04, 2023 at 12:17:48AM +0200, Gerald Pfeifer wrote:
> On Tue, 19 Sep 2023, Mark Wielaard wrote:
> >> Although there were some positive responses (on list and on irc) it is
> >> sometimes hard to know if there really is consensus for these kind of
> >> infrastructure tweaks. But I believe there is at least no sustained
> >> opposition to changing the gcc-patches mailman setting as proposed
> >> above.
> > This change is now done for gcc-patches.
> 
> Yeah, yeah, yeah. Thank you!

Thanks to the fsf-tech team who explained the setup they are using for
lists.gnu.org and everybody helping to test in the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=29713

It seems to work well, but it does mean disabling most of the things
mailman can do, like filtering out HTML attachements, adjusting
headers, adding footers or subject prefixes, etc. And we did break at
least one workflow for people who were using DKIM signing and the
Errors-To header.

> >> And if there are no complaints at Cauldron we could do the same for
> >> the other patch lists the week after.
> 
> Sadly I missed Cauldron - have there been any complaints there?

No, the opposite. People seemed happy and there were some examples
shown where (on other lists, like binutils) From rewriting caused
issues for some tools relying on patchwork.sourceware.org.

> Can you adjust the g...@gcc.gnu.org list and others @gcc.gnu.org as well?
> I for one would love to see that.

Being somewhat conservative doing that in steps. Last week we switched
the other gcc lists that receive patches (gcc-rust, libstdc++, fortran
and jit). This week looking at non-gcc lists on sourceware that use
patchwork (newlib, binutils, elfutils-devel, gdb-patches and
libabigail). Then if nothing breaks horribly more general lists if
people want.

Cheers,

Mark

Re: gcc-patches From rewriting mailman settings

[Mark Wielaard]

Hi,

On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote:
> On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote:
> > We (Jeff or anyone else with mailman admin privs) could use the same
> > settings for gcc-patches. The settings that need to be set are in that
> > bug:
> > 
> > - subject_prefix (general): (empty)
> > - from_is_list (general): No
> > - anonymous_list (general): No
> > - first_strip_reply_to (general): No
> > - reply_goes_to_list (general): Poster
> > - reply_to_address (general): (empty)
> > - include_sender_header (general): No
> > - drop_cc (general): No
> > - msg_header (nondigest): (empty)
> > - msg_footer (nondigest): (empty)
> > - scrub_nondigest (nondigest): No
> > - dmarc_moderation_action (privacy): Accept
> > - filter_content (contentfilter): No
> > 
> > The only visible change (apart from no more From rewriting) is that
> > HTML multi-parts aren't scrubbed anymore (that would be a message
> > altering issue). The html part is still scrubbed from the
> > inbox.sourceware.org archive, so b4 works just fine. But I don't know
> > what patchwork.sourceware.org does with HTML attachements. Of course
> > people really shouldn't sent HTML attachments to gcc-patches, so maybe
> > this is no real problem.
> 
> Although there were some positive responses (on list and on irc) it is
> sometimes hard to know if there really is consensus for these kind of
> infrastructure tweaks. But I believe there is at least no sustained
> opposition to changing the gcc-patches mailman setting as proposed
> above.
> 
> So unless someone objects I like to make this change Tuesday September
> 19 around 08:00 UTC.
> 
> And if there are no complaints at Cauldron we could do the same for
> the other patch lists the week after.

Since there were no complaints (and some happy users) and we didn't
real issues (there was an issue when using the Errors-To header, which
might break your dkim signature, but the only user of Errors-To has
dropped it) the jit, libstdc++, fortran and gcc-rust lists now also
have the above mailman settings.

The admin email address for fortran was updated to Toon's new address
and the one for libstdc++ was changed from bkoz to jwakely.

If there are any issues with the list settings please discuss on the
overse...@sourceware.org mailinglist.

Cheers,

Mark

> > > [1] https://patchwork.sourceware.org/project/gcc/list/
> > > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Re: gcc-patches From rewriting mailman settings

[Mark Wielaard]

Hi,

On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote:
> On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote:
> > We (Jeff or anyone else with mailman admin privs) could use the same
> > settings for gcc-patches. The settings that need to be set are in that
> > bug:
> > 
> > - subject_prefix (general): (empty)
> > - from_is_list (general): No
> > - anonymous_list (general): No
> > - first_strip_reply_to (general): No
> > - reply_goes_to_list (general): Poster
> > - reply_to_address (general): (empty)
> > - include_sender_header (general): No
> > - drop_cc (general): No
> > - msg_header (nondigest): (empty)
> > - msg_footer (nondigest): (empty)
> > - scrub_nondigest (nondigest): No
> > - dmarc_moderation_action (privacy): Accept
> > - filter_content (contentfilter): No
> > 
> > The only visible change (apart from no more From rewriting) is that
> > HTML multi-parts aren't scrubbed anymore (that would be a message
> > altering issue). The html part is still scrubbed from the
> > inbox.sourceware.org archive, so b4 works just fine. But I don't know
> > what patchwork.sourceware.org does with HTML attachements. Of course
> > people really shouldn't sent HTML attachments to gcc-patches, so maybe
> > this is no real problem.
> 
> Although there were some positive responses (on list and on irc) it is
> sometimes hard to know if there really is consensus for these kind of
> infrastructure tweaks. But I believe there is at least no sustained
> opposition to changing the gcc-patches mailman setting as proposed
> above.
> 
> So unless someone objects I like to make this change Tuesday September
> 19 around 08:00 UTC.
> 
> And if there are no complaints at Cauldron we could do the same for
> the other patch lists the week after.

Since there were no complaints (and some happy users) and we didn't
real issues (there was an issue when using the Errors-To header, which
might break your dkim signature, but the only user of Errors-To has
dropped it) the jit, libstdc++, fortran and gcc-rust lists now also
have the above mailman settings.

The admin email address for fortran was updated to Toon's new address
and the one for libstdc++ was changed from bkoz to jwakely.

If there are any issues with the list settings please discuss on the
overse...@sourceware.org mailinglist.

Cheers,

Mark

> > > [1] https://patchwork.sourceware.org/project/gcc/list/
> > > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

After Cauldron - online mini BoFs and Fosdem

[Mark Wielaard]

Hi all,

Cauldron was really great. Seeing everybody in person again.
One item that came up was about meeting more frequently and/or in
smaller (virtual) groups.

If people want to have online mini BoFs to follow up on some discussion
they had at Cauldron, or for some periodic meetup, then please remember
that The Software Freedom Conservancy is extending the use of their Big
Blue Button instance https://bbb.sfconservancy.org/ to Sourceware
projects that want to host video meetings.

Please create an account at https://bbb.sfconservancy.org/b/signup then
contact admin-reque...@sourceware.org with the name and email you used
and the kind of project/BoF/meeting you want to run to activate the
account.

Note: Anyone is able to join a meeting, accounts are only required to
create new meetings.

Also Doji, Jose and Gwen (on CC) are trying to coordinate a Fosdem
devroom for the various projects. Please contact them if you want to
help out with that.

Cheers,

Mark

https://sfconservancy.org/news/2023/aug/15/exit-zoom/
https://fosdem.org/2024/

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi all,

On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote:
> > We (Jeff or anyone else with mailman admin privs) could use the same
> > settings for gcc-patches. The settings that need to be set are in that
> > bug:
> > 
> > - subject_prefix (general): (empty)
> > - from_is_list (general): No
> > - anonymous_list (general): No
> > - first_strip_reply_to (general): No
> > - reply_goes_to_list (general): Poster
> > - reply_to_address (general): (empty)
> > - include_sender_header (general): No
> > - drop_cc (general): No
> > - msg_header (nondigest): (empty)
> > - msg_footer (nondigest): (empty)
> > - scrub_nondigest (nondigest): No
> > - dmarc_moderation_action (privacy): Accept
> > - filter_content (contentfilter): No
> > 
> > The only visible change (apart from no more From rewriting) is that
> > HTML multi-parts aren't scrubbed anymore (that would be a message
> > altering issue). The html part is still scrubbed from the
> > inbox.sourceware.org archive, so b4 works just fine. But I don't know
> > what patchwork.sourceware.org does with HTML attachements. Of course
> > people really shouldn't sent HTML attachments to gcc-patches, so maybe
> > this is no real problem.
> 
> Although there were some positive responses (on list and on irc) it is
> sometimes hard to know if there really is consensus for these kind of
> infrastructure tweaks. But I believe there is at least no sustained
> opposition to changing the gcc-patches mailman setting as proposed
> above.
> 
> So unless someone objects I like to make this change Tuesday September
> 19 around 08:00 UTC.

This change is now done for gcc-patches.

> And if there are no complaints at Cauldron we could do the same for
> the other patch lists the week after.
> 
> > > [1] https://patchwork.sourceware.org/project/gcc/list/
> > > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi all,

On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote:
> Adding Jeff to CC who is the official gcc-patches mailinglist admin.
> [...] 
> Yes, it is expected for emails that come from domains with a dmarc
> policy. That is because the current settings of the gcc-patches
> mailinglist might slightly alter the message or headers in a way that
> invalidates the DKIM signature. Without From rewriting those messages
> would be bounced by recipients that check the dmarc policy/dkim
> signature.
> 
> As you noticed the glibc hackers have recently worked together with the
> sourceware overseers to upgrade mailman and alter the postfix and the
> libc-alpha mailinglist setting so it doesn't require From rewriting
> anymore (the message and header aren't altered anymore to invalidate
> the DKIM signatures).
> 
> We (Jeff or anyone else with mailman admin privs) could use the same
> settings for gcc-patches. The settings that need to be set are in that
> bug:
> 
> - subject_prefix (general): (empty)
> - from_is_list (general): No
> - anonymous_list (general): No
> - first_strip_reply_to (general): No
> - reply_goes_to_list (general): Poster
> - reply_to_address (general): (empty)
> - include_sender_header (general): No
> - drop_cc (general): No
> - msg_header (nondigest): (empty)
> - msg_footer (nondigest): (empty)
> - scrub_nondigest (nondigest): No
> - dmarc_moderation_action (privacy): Accept
> - filter_content (contentfilter): No
> 
> The only visible change (apart from no more From rewriting) is that
> HTML multi-parts aren't scrubbed anymore (that would be a message
> altering issue). The html part is still scrubbed from the
> inbox.sourceware.org archive, so b4 works just fine. But I don't know
> what patchwork.sourceware.org does with HTML attachements. Of course
> people really shouldn't sent HTML attachments to gcc-patches, so maybe
> this is no real problem.

Although there were some positive responses (on list and on irc) it is
sometimes hard to know if there really is consensus for these kind of
infrastructure tweaks. But I believe there is at least no sustained
opposition to changing the gcc-patches mailman setting as proposed
above.

So unless someone objects I like to make this change Tuesday September
19 around 08:00 UTC.

And if there are no complaints at Cauldron we could do the same for
the other patch lists the week after.

Cheers,

Mark

> > [1] https://patchwork.sourceware.org/project/gcc/list/
> > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi Richard,

On Thu, Sep 14, 2023 at 11:07:21AM +0200, Richard Biener wrote:
> On Tue, Sep 12, 2023 at 5:00 PM Mark Wielaard  wrote:
> > The only visible change (apart from no more From rewriting) is that
> > HTML multi-parts aren't scrubbed anymore (that would be a message
> > altering issue). The html part is still scrubbed from the
> > inbox.sourceware.org archive, so b4 works just fine. But I don't know
> > what patchwork.sourceware.org does with HTML attachements. Of course
> > people really shouldn't sent HTML attachments to gcc-patches, so maybe
> > this is no real problem.
> 
> Ick (to the HTML part).  I wonder if we can use From rewriting for those,
> still stripping the HTML part?

It is possible to mark some domains, like gmail.com which is used by a
lot of HTML posters, to always use From rewriting. But it isn't easy
to do it for emails containing HTML parts (and strip them).

>  Maybe we can also go back to rejecting
> mails that are not text/plain ...

Sadly people do seem to use these web email providers like gmail a
lot. Although not many people sent patches as email, reviews of those
patches do sometimes contain HTML parts.

Sorry,

Mark

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi Thomas,

On Thu, Sep 14, 2023 at 09:00:39AM +0200, Thomas Schwinge wrote:
> >> Let me know if you want Jeff (or me or one of the other overseers) make
> >> the above changes to the gcc-patches mailman settings.
> >
> > yes, please!
> 
> Yes, please!  For all mailing lists, globally.

Call me a little conservative, but lets do this in stages. Although I
believe this works as intended, it is email and email is finicky.
Lets try out gcc-patches first. Then if that works and nobody
complains in say two week switch over other lists that receive patches
(gcc-rust, libstdc++, fortran and jit). But maybe just keep the
discussion lists as is for now.

Cheers,

Mark

gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi Maxim,

Adding Jeff to CC who is the official gcc-patches mailinglist admin.

On Tue, 2023-09-12 at 11:08 +0400, Maxim Kuvyrkov wrote:
> Normally, notifications from Linaro TCWG precommit CI are sent only to
> patch author and patch submitter.  In this case the sender was rewritten
> to "Benjamin Priour via Gcc-patches ",
> which was detected by Patchwork [1] as patch submitter.

BTW. Really looking forward to your talk at Cauldron about this!

> Is "From:" re-write on gcc-patches@ mailing list a side-effect of [2]?
> I see that some, but not all messages to gcc-patches@ have their
> "From:" re-written.
> 
> Also, do you know if re-write of "From:" on gcc-patches@ is expected?

Yes, it is expected for emails that come from domains with a dmarc
policy. That is because the current settings of the gcc-patches
mailinglist might slightly alter the message or headers in a way that
invalidates the DKIM signature. Without From rewriting those messages
would be bounced by recipients that check the dmarc policy/dkim
signature.

As you noticed the glibc hackers have recently worked together with the
sourceware overseers to upgrade mailman and alter the postfix and the
libc-alpha mailinglist setting so it doesn't require From rewriting
anymore (the message and header aren't altered anymore to invalidate
the DKIM signatures).

We (Jeff or anyone else with mailman admin privs) could use the same
settings for gcc-patches. The settings that need to be set are in that
bug:

- subject_prefix (general): (empty)
- from_is_list (general): No
- anonymous_list (general): No
- first_strip_reply_to (general): No
- reply_goes_to_list (general): Poster
- reply_to_address (general): (empty)
- include_sender_header (general): No
- drop_cc (general): No
- msg_header (nondigest): (empty)
- msg_footer (nondigest): (empty)
- scrub_nondigest (nondigest): No
- dmarc_moderation_action (privacy): Accept
- filter_content (contentfilter): No

The only visible change (apart from no more From rewriting) is that
HTML multi-parts aren't scrubbed anymore (that would be a message
altering issue). The html part is still scrubbed from the
inbox.sourceware.org archive, so b4 works just fine. But I don't know
what patchwork.sourceware.org does with HTML attachements. Of course
people really shouldn't sent HTML attachments to gcc-patches, so maybe
this is no real problem.

Let me know if you want Jeff (or me or one of the other overseers) make
the above changes to the gcc-patches mailman settings.

Cheers,

Mark

> [1] https://patchwork.sourceware.org/project/gcc/list/
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Re: ☠ Buildbot (Sourceware): gccrust - failed '! grep ...' (failure) (master)

[Mark Wielaard]

Hi,

On Fri, 2023-08-18 at 16:07 +, builder--- via Gcc-rust wrote:
> A new failure has been detected on builder gccrust-debian-ppc64 while 
> building gccrust.
> 
> Full details are available at:
> https://builder.sourceware.org/buildbot/#builders/3/builds/1488
> 
> Build state: failed '! grep ...' (failure)
> Revision: b1dd53faa1aa9ebd935742e57166647c055bae2a
> Worker: debian-ppc64

So, this is "expected", the buildbot step is now more clear:

> - 6: grep FAIL or unexpected rust.sum ( failure )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/3/builds/1488/steps/6/logs/stdio

This now shows:

FAIL: rust/compile/builtin_macro_eager1.rs scan-tree-dump-times gimple 
""test1canary"" 1
FAIL: rust/compile/builtin_macro_recurse2.rs scan-tree-dump-times gimple 
""abheyho"" 1
FAIL: rust/compile/const-issue1440.rs  at line 52 (test for errors, line 51)
FAIL: rust/compile/const-issue1440.rs  at line 64 (test for errors, line 63)
FAIL: rust/compile/const-issue1440.rs (test for excess errors)
FAIL: rust/compile/issue-1446.rs (test for excess errors)
FAIL: rust/compile/torture/issue-1432.rs   -O0  (test for excess errors)
FAIL: rust/compile/torture/issue-1432.rs   -O1  (test for excess errors)
FAIL: rust/compile/torture/issue-1432.rs   -O2  (test for excess errors)
FAIL: rust/compile/torture/issue-1432.rs   -O3 -g  (test for excess errors)
FAIL: rust/compile/torture/issue-1432.rs   -Os  (test for excess errors)
FAIL: rust/compile/torture/issue-1432.rs   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
FAIL: rust/compile/torture/issue-1432.rs   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (test for excess errors)
# of unexpected failures13

> - 15: upload to bunsen ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/3/builds/1488/steps/15/logs/stdio

Also note that this step now shows the bunsen URL, which contains the
full testsuite logs:

https://builder.sourceware.org/testrun/ea54c760540e4fcb425d55a8da3b10cc77baa0b6

Look under the dejagnu tab, you can click through to the actual FAILs
in the .exp file and then get the log for an specific test. e.g. for
issue-1446.rs see:

https://builder.sourceware.org/testrun/ea54c760540e4fcb425d55a8da3b10cc77baa0b6?filename=gcc%2Ftestsuite%2Frust%2Frust.log=1817=20#line1817

Cheers,

Mark
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

[Mark Wielaard]

Hi,

On Sun, Jul 16, 2023 at 09:50:24AM +0200, FX Coudert via Gcc wrote:
> > Which is why people should just compare testsuite results from earlier run
> > on the same configuration to watch for regressions, especially in the
> > guality testsuite.
> 
> All this gives the idea of a test framework that is too rigid, or
> tests that are too fragile. I mean, The accumulation of noise just
> decreases the value of the the test results.

Note that one way to analyze whether tests are too fragile is to look
at the collected bunsen results:
https://builder.sourceware.org/testruns/?has_keyvalue_k=testrun.git_describe_keyvalue_op=glob_keyvalue_v=*gcc*

As far as I can see you are right that there are ~100 FAILs
(out of ~4700) in guality.exp on all arches/configs.

(CC Frank, the fedrawhide builder doesn't seem to include guality.exp,
do you know why?)

Cheers,

Mark

Re: Network Services Alert#489707

[Mark Wielaard]

Hi Dave,

On Wed, Jul 12, 2023 at 09:34:31AM -0500, Dave Blanchard wrote:
> You know, if you useless cocksuckers [...]

Please stop using this kind of language on this list.  I know it is
annoying if the spam filters didn't catch some obvious scam message.
But you are not helping anybody by replying to it.  And using
offensive language, even if you are annoyed, isn't acceptable.

Thanks,

Mark

Re: [PATCH] RISC-V: Fix compiler warning of riscv_arg_has_vector

[Mark Wielaard]

Hi all,

On Tue, 2023-06-20 at 07:11 -0600, Jeff Law wrote:
> On 6/20/23 04:56, Robin Dapp wrote:
> > > Could you merge it ?
> > > By the way, could Lehua get the write access?
> > 
> > IMHO nothing stands in the way but I'll defer to Jeff to have
> > the "official seal" :)
> > Once he ACKs Lehua needs to go the usual way of requesting
> > sourceware access via https://sourceware.org/cgi-bin/pdw/ps_form.cgi.
> Lehua fills out that form.  List me as the approver and the process will 
> run from there.  Takes a day or two for everything to get into place.

All done. Welcome Lehua.

> ps.  If Lehua has already filled out the form with Robin as the > approver, 
>that's fine too.  Might take a bit longer as I suspect the
> IT folks may not recognize Robin. 

Also Robin is right, you are on the hook as approver for the "official
seal" :) Because the "IT folks" check that the approver is listed as a
gcc maintainer and not just has write after approval status.

Cheers,

Mark

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Mark Wielaard]

Hi Arsen,

On Tue, Jun 06, 2023 at 08:43:05PM +0200, Arsen Arsenović via Gcc wrote:
> IMO, the sparing usage of this power on what are clearly purely abusive
> participants can only drive away users and contributors.  It seems
> reasonable to establish a process for dealing with incidents like this
> (and appeals, of course), especially given their frecency.

I completely agree. Having a clear code of conduct for participants on
this list and procedures for when people don't stop harassing others
would be really welcome.

Thanks,

Mark

Re: Imagination Technologies Limited - FSF copyright assignment forms

[Mark Wielaard]

Hi Ed,

On Thu, Jun 08, 2023 at 10:32:15AM +, Ed Crothall wrote:
> Could you please send across the relevant copyright assignment forms
> to enable contributions to GCC from Imagination Technologies
> Limited?

At https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright
you'll find the request-assign.changes file which you can sent to
ass...@gnu.org who will help you get the correct copyright assignment
and company disclaimer forms.

Cheers,

Mark

Re: Who cares about performance (or Intel's CPU errata)?

[Mark Wielaard]

Hi Stefan,

On Sun, May 28, 2023 at 12:52:30AM +0200, Stefan Kanthak wrote:
> >> Just to show how SLOPPY, INCONSEQUENTIAL and INCOMPETENT GCC's developers 
> >> are:

This is totally not constructive. You should stop attacking others
like that on this list.

> OUCH, my fault; sorry for the confusion and the wrong accusation.

Thanks for apologizing.

There is a system for reporting bugs. As others have requested, please
use that: https://gcc.gnu.org/bugs/#where

Please stop ranting on this list and report bugs in bugzilla. Or you
might get banned from the list.

Thanks,

Mark

Re: Will GCC eventually support SSE2 or SSE4.1?

[Mark Wielaard]

Stefan,

On Fri, 2023-05-26 at 14:22 +0200, Stefan Kanthak wrote:
> "Jonathan Wakely"  wrote:
> > And when did you report it to bugzilla?
> > 
> > Nobody reads your silly webpage.
> 
> Thanks stupid. I don't read your silly bugzilla!

Stop calling people stupid or dumbass.

People are trying to help you understand your issues and explaining
your mistakes and asking you to please report any real issues to
bugzilla for proper triage. Which you have refused to do for a couple
of years now.

It is totally inappropriate to respond to such requests with insults
(even if they call your website silly, others also shouldn't use such
denigrating language).

Thanks,

Mark

Sourceware joins Software Freedom Conservancy

[Mark Wielaard]

https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

After various discussions and lots of positive feedback [1] [2] [3] [4]
Software Freedom Conservancy and Sourceware proudly announce that
Sourceware today joins SFC as a member project!

As the fiscal host of Sourceware, Software Freedom Conservancy will
provide a home for fundraising, legal protection and governance that
will benefit all projects under Sourceware's care.  We share one mission:
developing, distributing and advocactingfor Software Freedom.  Together
we will offer a worry-free, friendly home for core toolchain and
developer tool projects.

We are happy to discuss this in #overseers on irc.libera.chat now
18:00-19:00 UTC. And we will also start regular Overseers Open Office
Hours every second Friday of the month on irc at the same time.

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

To support the Software Freedom Conservancy, please become a Sustainer
https://sfconservancy.org/sustainer

You can also donate directly to Sourceware:
https://sfconservancy.org/members/current/#Sourceware
as a directed donation (mention Sourceware in the comment or memo line)

See https://sfconservancy.org/donate/ for other ways to donate.

[1] https://sourceware.org/pipermail/overseers/2022q3/018802.html
[2] https://sourceware.org/pipermail/overseers/2022q3/018804.html
[3] https://sourceware.org/pipermail/overseers/2022q3/018834.html
[4] 
https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a

https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

Sourceware, one of the longest standing Free Software hosting platforms,
joins SFC

Important Free Software infrastructure project finds non-profit home

   May 15, 2023

   As a home for Free Software projects since 1998, Sourceware is a
   keystone in Free Software infrastructure. For almost 25 years
   Sourceware has been the long-time home of various core toolchain
   project communities. Projects like Cygwin, a UNIX API for Win32
   systems, the GNU Toolchain, including GCC, the GNU Compiler Colection,
   two C libraries, glibc and newlib, binary tools, binutils and elfutils,
   debuggers and profilers, GDB, systemtap and valgrind. Sourceware also
   hosts standard groups like gnu-gabi and the DWARF Debugging Standard.
   See the full list project hosted and services provided on the
   [1]Sourceware projects page.

   Becoming an SFC member project will improve future operations carried
   out by dedicated volunteers to and furthering the mission of Free
   Software hosting. This will accelerate the Sourceware [2]technical
   roadmap to improve and modernize the infrastructure.

   As the fiscal host of Sourceware, Software Freedom Conservancy will
   provide a home for fundraising, legal assistance and governance that
   will benefit all projects under Sourceware's care. We share one
   mission: developing, distributing and advocating for Software Freedom.
   And to offer a worry-free, friendly home for Free Software communities.
   We see a bright future working together. With Conservancy as fiscal
   sponsor, Sourceware will also be able to fundraise and have the
   community of volunteers work together with paid contractors and enter
   into contracts for managed infrastructure where appropriate.

   SFC looks to Sourceware's years of experience in providing outstanding
   infrastructure as an inspiration for improving the Free Software
   ecosystem both for other SFC projects, and also in furthering SFC's
   mission around campaigns to promote Software Freedom Infrastructure.
   For decades, Sourceware has shown that hosting Free Software projects
   with Free Software infrastructure is not only possible, but helps
   create and fosters the growth of relationships and networks within the
   Free Software communities. SFC is thrilled to join the powerful history
   of demonstrable experience to grow hosting options that are 100% free
   software, in the future to bring in new ideas, communities, and
   projects!

   Projects hosted by Sourceware are part of the core toolchain for
   GNU/Linux distros, embedded systems, the cloud and, through Cygwin,
   Windows. Back in 1984 Ken Thompson's Reflections on Trusting Trust
   already described how making the source code for these tools available
   is essential to create what today we call secure software supply
   chains. Sourceware provides robust infrastructure and services for
   projects to adopt secure collaboration and release policies. We forsee
   future cooperation with other Conservancy member projects, such as the
   [3]Reproducible Builds project which provides an
   independently-verifiable path to supply chain security. Additionally,
   Sourceware will leverage Conservancy advisory role in how community
   projects are impacted by and can comply with regulations 

Sourceware joins Software Freedom Conservancy

[Mark Wielaard]

https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

After various discussions and lots of positive feedback [1] [2] [3] [4]
Software Freedom Conservancy and Sourceware proudly announce that
Sourceware today joins SFC as a member project!

As the fiscal host of Sourceware, Software Freedom Conservancy will
provide a home for fundraising, legal protection and governance that
will benefit all projects under Sourceware's care.  We share one mission:
developing, distributing and advocactingfor Software Freedom.  Together
we will offer a worry-free, friendly home for core toolchain and
developer tool projects.

We are happy to discuss this in #overseers on irc.libera.chat now
18:00-19:00 UTC. And we will also start regular Overseers Open Office
Hours every second Friday of the month on irc at the same time.

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

To support the Software Freedom Conservancy, please become a Sustainer
https://sfconservancy.org/sustainer

You can also donate directly to Sourceware:
https://sfconservancy.org/members/current/#Sourceware
as a directed donation (mention Sourceware in the comment or memo line)

See https://sfconservancy.org/donate/ for other ways to donate.

[1] https://sourceware.org/pipermail/overseers/2022q3/018802.html
[2] https://sourceware.org/pipermail/overseers/2022q3/018804.html
[3] https://sourceware.org/pipermail/overseers/2022q3/018834.html
[4] 
https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a

https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

Sourceware, one of the longest standing Free Software hosting platforms,
joins SFC

Important Free Software infrastructure project finds non-profit home

   May 15, 2023

   As a home for Free Software projects since 1998, Sourceware is a
   keystone in Free Software infrastructure. For almost 25 years
   Sourceware has been the long-time home of various core toolchain
   project communities. Projects like Cygwin, a UNIX API for Win32
   systems, the GNU Toolchain, including GCC, the GNU Compiler Colection,
   two C libraries, glibc and newlib, binary tools, binutils and elfutils,
   debuggers and profilers, GDB, systemtap and valgrind. Sourceware also
   hosts standard groups like gnu-gabi and the DWARF Debugging Standard.
   See the full list project hosted and services provided on the
   [1]Sourceware projects page.

   Becoming an SFC member project will improve future operations carried
   out by dedicated volunteers to and furthering the mission of Free
   Software hosting. This will accelerate the Sourceware [2]technical
   roadmap to improve and modernize the infrastructure.

   As the fiscal host of Sourceware, Software Freedom Conservancy will
   provide a home for fundraising, legal assistance and governance that
   will benefit all projects under Sourceware's care. We share one
   mission: developing, distributing and advocating for Software Freedom.
   And to offer a worry-free, friendly home for Free Software communities.
   We see a bright future working together. With Conservancy as fiscal
   sponsor, Sourceware will also be able to fundraise and have the
   community of volunteers work together with paid contractors and enter
   into contracts for managed infrastructure where appropriate.

   SFC looks to Sourceware's years of experience in providing outstanding
   infrastructure as an inspiration for improving the Free Software
   ecosystem both for other SFC projects, and also in furthering SFC's
   mission around campaigns to promote Software Freedom Infrastructure.
   For decades, Sourceware has shown that hosting Free Software projects
   with Free Software infrastructure is not only possible, but helps
   create and fosters the growth of relationships and networks within the
   Free Software communities. SFC is thrilled to join the powerful history
   of demonstrable experience to grow hosting options that are 100% free
   software, in the future to bring in new ideas, communities, and
   projects!

   Projects hosted by Sourceware are part of the core toolchain for
   GNU/Linux distros, embedded systems, the cloud and, through Cygwin,
   Windows. Back in 1984 Ken Thompson's Reflections on Trusting Trust
   already described how making the source code for these tools available
   is essential to create what today we call secure software supply
   chains. Sourceware provides robust infrastructure and services for
   projects to adopt secure collaboration and release policies. We forsee
   future cooperation with other Conservancy member projects, such as the
   [3]Reproducible Builds project which provides an
   independently-verifiable path to supply chain security. Additionally,
   Sourceware will leverage Conservancy advisory role in how community
   projects are impacted by and can comply with regulations 

Re: More C type errors by default for GCC 14

[Mark Wielaard]

Hi Po,

On Fri, May 12, 2023 at 09:53:30PM +0800, Po Lu via Gcc wrote:
> I don't want anything, seeing as I've been using GCC less and less over
> the years (for this and other reasons.)  I'm just throwing in my two or
> so cents.

I think you have contributed more than two cents and it time to stop
repeating your opinion over and over again (and for others to stop
replying to your posts). You have posted more than anybody else to
this thread and it is not contributing anything new. Please let the
actual gcc maintainers work out the technical details of the default
diagnostics.

Thanks,

Mark

Re: PR109439 - Terminate analysis path when OOB detected

[Mark Wielaard]

Hi Benjamin,

On Mon, May 01, 2023 at 02:43:13PM +0200, Benjamin Priour via Gcc wrote:
> I believe I still don't have the right to commit it directly to the repo,
> and honestly even if I would using my fresh gcc account, I would prefer not
> to commit it myself for the first patch, I don't wanna mess with anything
> because of an oversight.

An account has been setup for you, you can try it out by doing:

  ssh vultk...@gcc.gnu.org alive

Some other helpful info can be found at:

  https://sourceware.org/sourceware/accountinfo.html

If anything seems wrong, please contact admin-reque...@sourceware.org

And please coordinate actually pushing patches with David and the
other gcc developers on gcc-patc...@gcc.gnu.org

Cheers,

Mark

Re: Hosting our gfortran MatterMost workspace

[Mark Wielaard]

Hi Jerry, Hi Andrew,

On Fri, Apr 28, 2023 at 09:16:12AM -0700, Andrew Pinski via Gcc wrote:
> On Fri, Apr 28, 2023 at 8:32 AM Jerry D via Fortran  
> wrote:
> >
> > Hello all and gcc overseers,
> >
> > I received a notice that the MasterMost server providers decided to drop
> > their free service. Unfortunate and understandable.
> >
> > I plan to contact the Open Software Lab folks at Oregon State University
> > to see if they can host for us.
> >
> > If anyone else has any suggestions of possible places we can host an
> > instance, please let me know.  The software for the platform is open
> > source many folks self host, so we can do this.
> >
> > I am not sure where gcc.gnu.org is hosted, but that might be a logical
> > place.
> 
> Take a look at https://sourceware.org/bugzilla/show_bug.cgi?id=29853 .
> gcc.gnu.org is currently hosted as part of sourceware so ...

OSUOSL already provides some machines for sourceware/gcc. If you could
put a bit more technical details into that bugzilla issue, with expected usage
(how many people, groups, moderation?) then we can coordinate and put
it on the overseers agenda.

Thanks,

Mark

Re: [pushed] wwwdocs: gcc-4.7: Adjust dwarfstd.org links

[Mark Wielaard]

On Wed, 2023-03-29 at 15:40 -0700, Andrew Pinski wrote:
> On Wed, Mar 29, 2023 at 3:08 PM Gerald Pfeifer  wrote:
> > 
> > Business as usual - 301 Moved Permanently.
> 
> Just FYI, dwarfstd is now hosted by sourceware too. So I doubt these
> URLs will change after this.

Indeed, see
https://inbox.sourceware.org/overseers/20230327222524.ga20...@gnu.wildebeest.org/


And thanks for taking care of these new redirects. Please do let us
(dwarf-disc...@lists.dwarfstd.org) know if any old URL is broken. With
the move the site was changed (twice). From php to static html and then
to being generated statically from markdown files. All old URLs should
redirect to the new setup, but we might have missed something.

Cheers,

Mark

Re: Website https://gcc.gnu.org/ down

[Mark Wielaard]

Hi Damian,

On Sat, Mar 25, 2023 at 07:30:14AM +0100, Damian Tometzki wrote:
> the website and git https://gcc.gnu.org/ is down ?
> 
> Any info about it ?

The site isn't down, but there is an issue (ddos?) with the fsf dns
servers for gnu.org. The FSF tech team announces downtime and
temporary issues with their network at
https://hostux.social/@fsfstatus or
https://hostux.social/@fsfstatus.rss

gcc.gnu.org is hosted at sourceware.org so if dns doesn't resolve for
you, you might be able to add the following addresses to your
/etc/hosts file:

8.43.85.97 gcc.gnu.org
2620:52:3:1:0:246e:9693:128c gcc.gnu.org

If you need access to git then you might also be able to clone the
repository through git clone https://sourceware.org/git/gcc.git

There is also the sourceware git backups at sourcehut:
https://sr.ht/~sourceware/gcc/

Cheers,

Mark

Re: [GSoC] gccrs Unicode support

[Mark Wielaard]

Hi,

On Thu, 2023-03-16 at 10:28 +0100, Thomas Schwinge wrote:
> I'm now also putting Mark Wielaard in CC; he once also started discussing
> this topic, "thinking of importing a couple of gnulib modules to help
> with UTF-8 processing [unless] other gcc frontends handle [these things]
> already in a way that might be reusable".  See the thread starting at
> <https://inbox.sourceware.org/gcc/ypqrmbhyu3wrp...@wildebeest.org>
> "rust frontend and UTF-8/unicode processing/properties".

Thanks. BTW. I am not currently working on this.
Note the responses in the above thread by Ian and Jason who pointed out
that some of the requirements of the gccrs frontend might be covered in
the go frontend and libcpp, but not really in a reusable way.

One other thing you might want to coordinate on is NFC normalization
and Confusable Detection for identifiers.
https://unicode.org/reports/tr39/#Confusable_Detection
There has been some work on this by David Malcolm and Marek Polacek
https://developers.redhat.com/articles/2022/01/12/prevent-trojan-source-attacks-gcc-12
But that is on a slightly higher source level (not specific to
identifiers).

You might want to research whether NFC normalization of identifiers is
required to be done by the lexer or parser in Rust and how it interacts
with proc macros.

Cheers,

Mark

Re: [GSoC] gccrs Unicode support

[Mark Wielaard]

Hi,

On Thu, 2023-03-16 at 10:28 +0100, Thomas Schwinge wrote:
> I'm now also putting Mark Wielaard in CC; he once also started discussing
> this topic, "thinking of importing a couple of gnulib modules to help
> with UTF-8 processing [unless] other gcc frontends handle [these things]
> already in a way that might be reusable".  See the thread starting at
> <https://inbox.sourceware.org/gcc/ypqrmbhyu3wrp...@wildebeest.org>
> "rust frontend and UTF-8/unicode processing/properties".

Thanks. BTW. I am not currently working on this.
Note the responses in the above thread by Ian and Jason who pointed out
that some of the requirements of the gccrs frontend might be covered in
the go frontend and libcpp, but not really in a reusable way.

One other thing you might want to coordinate on is NFC normalization
and Confusable Detection for identifiers.
https://unicode.org/reports/tr39/#Confusable_Detection
There has been some work on this by David Malcolm and Marek Polacek
https://developers.redhat.com/articles/2022/01/12/prevent-trojan-source-attacks-gcc-12
But that is on a slightly higher source level (not specific to
identifiers).

You might want to research whether NFC normalization of identifiers is
required to be done by the lexer or parser in Rust and how it interacts
with proc macros.

Cheers,

Mark
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Sourceware infrastructure updates Q1 2023

[Mark Wielaard]

Sourceware infrastructure community updates for Q1 2023.

= New cgit setup

gitweb has been working out pretty nicely for many years, but cgit is
cgit is nicer looking, has easier to understand URLs and is much
faster. The first experimental setup can be found here:

https://cygwin.com/cgit/
https://gcc.gnu.org/cgit/
https://sourceware.org/cgit/

Thanks to Jon Turney for the cygwin work.

If this works out, we would like to deploy a script written by Arsen
Arsenović to switch the main /git/ to cgit while keeping all old
gitweb URLs working.

See https://sourceware.org/bugzilla/show_bug.cgi?id=29769

= New sparc builder for builder.sourceware.org

Thanks to the Gentoo Foundation and OSUOSL [*] there is now a
large (and small) gentoo-sparc worker:

https://builder.sourceware.org/buildbot/#/workers/35
https://builder.sourceware.org/buildbot/#/workers/36

Please contact the buildbot mailinglis if you want to do specific
builds on it: https://sourceware.org/mailman/listinfo/buildbot

= AI comes to the bunsen test results

It isn't a large language model chatbot, but probably more
useful. https://builder.sourceware.org/testruns/ will now predict what
it believes the the dejagnu test results should be. It will give a
score for what it expected a result to be.  e.g for a new FAIL it
could say: mispredicted PASS 81% which means in 81% of similar test
runs that test PASSed.  So you can concentrate on those FAILing tests
that have a high PASSing score.

For more info see:
https://inbox.sourceware.org/buildbot/20230206160507.ga31...@redhat.com/

= openssh update produces misleading invalid key length warning

Connecting to sourceware through ssh with a newer openssh or crypto
policy might produce a misleading warning about the key length being
too short:

  Bad server host key: Invalid key length

Please don't try to replace your ssh key, there is nothing wrong with
it. The issue is that you might have an old server key in your
~/.ssh/known_hosts file. Simply remove it and reconnect to get the new
server key:

ssh-keygen -R sourceware.org
ssh-keygen -R cygwin.com
ssh-keygen -R gcc.gnu.org

See also https://bugzilla.redhat.com/show_bug.cgi?id=2164016

= inbox.sourceware.org and '/' in Message-ID

Those using public-inbox might have noticed that when a Message-ID
contains a slash character '/' it is not always correctly encoded or
decoded as %2F in the inbox.sourceware.org path URLs. If you are using
a newer mutt as email client then you might want to make sure that
your Message-ID doesn't contain any characters that might need URL
encoding. For mutt 2.2 you might want to set the following in your
~/.muttrc to produce a uuid-like Message-ID as other email clients do:

set message_id_format="<%x%x%x%x-%x%x-%x%x-%x%x-%x%x%x%x%x%x@%f>"

For older mutt, and some more background, see:
https://people.kernel.org/monsieuricon/fix-your-mutt

= Happy hacking

And as always please feel free join the overseers mailinglist
https://sourceware.org/mailman/listinfo/overseers
file infrastructure issues in bugzilla
https://sourceware.org/bugzilla/describecomponents.cgi?product=sourceware
or join us in #overseers on irc.libera.chat

[*] But specifically Sam James.

We should also thank the following other individuals and
organisations for maintaining and/or providing hardware for
builder.sourceware.org Brno University, Dan Horák, Marist University,
Thomas Fitzsimmons, Mark Wielaard, Frank Eigler, IBM, Carl Love,
The Works on Arm initiative, Christophe Lyon, and Red Hat
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Sourceware infrastructure updates Q1 2023

[Mark Wielaard]

Sourceware infrastructure community updates for Q1 2023.

= New cgit setup

gitweb has been working out pretty nicely for many years, but cgit is
cgit is nicer looking, has easier to understand URLs and is much
faster. The first experimental setup can be found here:

https://cygwin.com/cgit/
https://gcc.gnu.org/cgit/
https://sourceware.org/cgit/

Thanks to Jon Turney for the cygwin work.

If this works out, we would like to deploy a script written by Arsen
Arsenović to switch the main /git/ to cgit while keeping all old
gitweb URLs working.

See https://sourceware.org/bugzilla/show_bug.cgi?id=29769

= New sparc builder for builder.sourceware.org

Thanks to the Gentoo Foundation and OSUOSL [*] there is now a
large (and small) gentoo-sparc worker:

https://builder.sourceware.org/buildbot/#/workers/35
https://builder.sourceware.org/buildbot/#/workers/36

Please contact the buildbot mailinglis if you want to do specific
builds on it: https://sourceware.org/mailman/listinfo/buildbot

= AI comes to the bunsen test results

It isn't a large language model chatbot, but probably more
useful. https://builder.sourceware.org/testruns/ will now predict what
it believes the the dejagnu test results should be. It will give a
score for what it expected a result to be.  e.g for a new FAIL it
could say: mispredicted PASS 81% which means in 81% of similar test
runs that test PASSed.  So you can concentrate on those FAILing tests
that have a high PASSing score.

For more info see:
https://inbox.sourceware.org/buildbot/20230206160507.ga31...@redhat.com/

= openssh update produces misleading invalid key length warning

Connecting to sourceware through ssh with a newer openssh or crypto
policy might produce a misleading warning about the key length being
too short:

  Bad server host key: Invalid key length

Please don't try to replace your ssh key, there is nothing wrong with
it. The issue is that you might have an old server key in your
~/.ssh/known_hosts file. Simply remove it and reconnect to get the new
server key:

ssh-keygen -R sourceware.org
ssh-keygen -R cygwin.com
ssh-keygen -R gcc.gnu.org

See also https://bugzilla.redhat.com/show_bug.cgi?id=2164016

= inbox.sourceware.org and '/' in Message-ID

Those using public-inbox might have noticed that when a Message-ID
contains a slash character '/' it is not always correctly encoded or
decoded as %2F in the inbox.sourceware.org path URLs. If you are using
a newer mutt as email client then you might want to make sure that
your Message-ID doesn't contain any characters that might need URL
encoding. For mutt 2.2 you might want to set the following in your
~/.muttrc to produce a uuid-like Message-ID as other email clients do:

set message_id_format="<%x%x%x%x-%x%x-%x%x-%x%x-%x%x%x%x%x%x@%f>"

For older mutt, and some more background, see:
https://people.kernel.org/monsieuricon/fix-your-mutt

= Happy hacking

And as always please feel free join the overseers mailinglist
https://sourceware.org/mailman/listinfo/overseers
file infrastructure issues in bugzilla
https://sourceware.org/bugzilla/describecomponents.cgi?product=sourceware
or join us in #overseers on irc.libera.chat

[*] But specifically Sam James.

We should also thank the following other individuals and
organisations for maintaining and/or providing hardware for
builder.sourceware.org Brno University, Dan Horák, Marist University,
Thomas Fitzsimmons, Mark Wielaard, Frank Eigler, IBM, Carl Love,
The Works on Arm initiative, Christophe Lyon, and Red Hat

Re: Missed warning (-Wuse-after-free)

[Mark Wielaard]

On Fri, 2023-02-17 at 08:38 -0500, Siddhesh Poyarekar wrote:
> On 2023-02-17 06:22, Alejandro Colomar wrote:
> > Hi Siddhesh,
> > 
> > On 2/17/23 04:48, Siddhesh Poyarekar wrote:
> > > On 2023-02-16 10:15, David Malcolm via Gcc wrote:
> > > > I'm not convinced that it's useful to the end-user to warn about the
> > > > "use of q itself" case.
> > > 
> > > FWIW, -Wuse-after-free=3 already should do this:
> > 
> > Thanks!  It works.  I would have expected such a warning to be included
> > in -Wextra.  Does it have any false positives (or maybe too many false
> > negatives?) that make it unsuitable for -Wextra?
> 
> I don't know why it isn't enabled in -Wextra, it seems like the right 
> thing to do.

Interesting warning flag I didn't know about. It seems to have found an
issue in some code trying to free a circular single linked list:
https://inbox.sourceware.org/elfutils-devel/20230217140027.125332-1-m...@klomp.org/

The reason people might not know about it, is that the documentation is
somewhat unclear. -Wall says it already includes -Wuse-after-free=3:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wall

But the -Wuse-after-free option itself says -Wall only enables -Wuse-
after-free=2:
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wuse-after-free

Also note that it is listed under "Options Controlling C++ Dialect" so
it wasn't immediately clear to me that it also works for C.

Cheers,

Mark

Re: Stepping down as gcov maintainer and callgraph reviewer

[Mark Wielaard]

Hi Martin,

On Thu, 2023-02-16 at 16:54 +0100, Martin Liška wrote:
> After spending last decade (including my diploma thesis even more)
> of my life working on GCC, I decided to leave the project and try
> a different job. I would like to thank all the community members I had
> change to interact with, I learned so much and enjoyed the journey!
> I'll be leaving somewhen at the beginning of May.
> 
> That said, I'm stepping down from my 2 positions as I won't have a time
> for proper patch review and bugs in the area I'm responsible for.

Thanks so much for all your work. I hope you aren't going too far away.
It is always a pleasure to work with you.

Cheers,

Mark