Re: Christophe Lyon as MVE reviewer for the AArch32 (arm) port.
> On 26 Sep 2024, at 19:22, Ramana Radhakrishnan > wrote: > > External email: Use caution opening links or attachments > > > I am pleased to announce that the GCC Steering Committee has appointed > Christophe Lyon as a MVE Reviewer for the AArch32 port. > > Please join me in congratulating Christophe on his new role. > Congratulations Christophe, well deserved! Kyrill > Christophe, please update your listings in the MAINTAINERS file. > > Regards, > Ramana
RFC: Update FSF (physical) mail address - in various files (COPYING, *.texi, ...)
Hi,
the FSF is located in Free Software Foundation, 31 Milk Street, #960789,
Boston, MA 02196 USA.
Older GPL licenses contained that mail address ("51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301 USA"), which is no longer valid.
Therefore, the FSF updated their licenses to point only to their webpage
has someone has noticed, cf:
https://gist.github.com/jwilk/435e32788d9d50aba7fc607a6e3d079f
While not mission critical, it seems to make sense to update (some of)
the files in GCC to fix that dangling reference.
It shows up in:
* license text (COPYPING, gcc/COPYING),
* in referrals to those files ("see file ... If not, write to") as
comments in several files
* as one-line copyright-owner statements
* as publisher address for documentation
In total, "Franklin Street" shows up (in GCC mainline) in 1632 files,
albeit only 212 files are not under an testsuite/ subdirectory.
It seems as if at least updating the documentation like
https://gcc.gnu.org/onlinedocs/gfc-internals.pdf (shows up on the second
page) - and the COPYPING + gcc/COPYING files would be sensible.
Thoughts?
Tobias
Stefan Schulze Frielinghaus appointed s390x port co-maintainer
I am pleased to announce that the GCC Steering Committee has appointed Stefan Schulze Frielinghaus as a s390x port co-maintainer. Please join me in congratulating Stefan on his new role. Stefan, please update your listing in the MAINTAINERS file. Cheers! David
Re: [CAULDRON] Topics for the Toolchain and Linux kernel BoF
"Jose E. Marchesi via Gcc" writes: > Hello people! > > This year we will be having a kernel BoF at Cauldron. It is scheduled > for Saturday from 15:30 to 16:30. There will be several kernel > maintainers and hackers in attendance, and the goal of the BoF is to > discuss and collect feedback about several toolchain-related issues that > are of current interest for the kernel. The output of the discussions > and the feedback collected will then be used as a basis for further > discussions at the Linux Plumbers conference that will be held the next > week in Vienna. The idea is to get kernel and toolchain hackers > together and advance on these topics. > > Find below some of the topics we will be discussing. Many of them are > relevant to GCC, and we ask you to consider attending if you are coming > to the Cauldron. The list of topics is of course not closed, and you > are very welcome to bring your own, specially if your work would benefit > from feedback from the kernel hackers. > > - LTO and inline asm symbols > > A lot of assembler statements reference C symbols, which need to be > externally_visible and global for GCC LTO, otherwise they can end up in the > wrong asm file and cause missing symbols. > > Goal of the discussion: > > Provide an assessment of the reported problem, and discuss the two > alternatives already proposed in the bugzillas below: one ad-hoc solution > based on parsing symbol references in inline asm strings, another is to > allow top-level extended asm that can get input arguments. > > References: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045 We didn't end up having time to discuss this in the BoF *but* the videos from this year's Cauldron are now available at https://www.youtube.com/@gnutoolscauldron7666. It looks like Honza's IPA/LTO/FDO BoF did cover this for a while and some interesting ideas came up -- see https://youtu.be/bWH4_in2s0o?t=1450 onwards. A lot of the discussion was around the biggest blocker (handling global asm) and the format of some possible gas extensions & diagnostics required. thanks, sam
Re: RFC: Update FSF (physical) mail address - in various files (COPYING, *.texi, ...)
On Mon, Sep 30, 2024, 5:53 AM Tobias Burnus wrote:
> Hi,
>
> the FSF is located in Free Software Foundation, 31 Milk Street, #960789,
> Boston, MA 02196 USA.
>
> Older GPL licenses contained that mail address ("51 Franklin Street
> ,
>
> Fifth Floor, Boston, MA 02110-1301 USA"), which is no longer valid.
>
> Therefore, the FSF updated their licenses to point only to their webpage
> has someone has noticed, cf:
> https://gist.github.com/jwilk/435e32788d9d50aba7fc607a6e3d079f
>
> While not mission critical, it seems to make sense to update (some of)
> the files in GCC to fix that dangling reference.
>
> It shows up in:
> * license text (COPYPING, gcc/COPYING),
> * in referrals to those files ("see file ... If not, write to") as
> comments in several files
> * as one-line copyright-owner statements
> * as publisher address for documentation
>
> In total, "Franklin Street" shows up (in GCC mainline) in 1632 files,
> albeit only 212 files are not under an testsuite/ subdirectory.
>
> It seems as if at least updating the documentation like
> https://gcc.gnu.org/onlinedocs/gfc-internals.pdf (shows up on the second
> page) - and the COPYPING + gcc/COPYING files would be sensible.
>
> Thoughts?
>
If the old address is always in a handful of forms, a script can handle the
change.
I've had good luck replacing licenses using blockrep.sed from Paolo
Bonzini. It
takes two blocks of text as input and generates the sed command. Combine
that
with something to identify the files that need the change applied and Bob's
your
uncle.
https://sed.sourceforge.io/grabbag/tutorials/sedfaq.txt
My notes say I applied a change from
http://sed-users.yahoogroups.narkive.com/dKa8Aba3/replace-block-of-text
--joel
> Tobias
>
Re: Stefan Schulze Frielinghaus appointed s390x port co-maintainer
Great job, Stefan! Congratulations! Thank you David! Bye, Andreas On 9/30/24 16:33, David Edelsohn via Gcc wrote: I am pleased to announce that the GCC Steering Committee has appointed Stefan Schulze Frielinghaus as a s390x port co-maintainer. Please join me in congratulating Stefan on his new role. Stefan, please update your listing in the MAINTAINERS file. Cheers! David
Sourceware infrastructure updates for Q3 2024
Sourceware infrastructure community updates for Q3 2024 Sourceware has provided the infrastructure for the core toolchain and developer tools for more than 25 years. https://sourceware.org/sourceware-25-roadmap.html The last couple of years it has transformed from a purely volunteer into a professional organization with an eight person strong Project Leadership Committee, monthly open office hours, multiple hardware services partners, expanded services, the Software Freedom Conservancy as fiscal sponsor and a more diverse funding model that allows us to enter into contracts with paid contractors or staff when appropriate. Every quarter we provide a summary of news about Sourceware, the core toolchain and developer tools infrastructure from the last 3 months. - Code snapshots for binutils and gdb - RISC-V Pioneer Box for builder.sourceware.org gcc CI - Sourceware @ Cauldron 2024 - A Sourceware Forge (an experiment with Forgejo) - Sourceware Open Office hours = Code snapshots for binutils and gdb binutils and gdb now also generate code snapshots on https://snapshots.sourceware.org Thanks to OSUOSL we now have snapshots.sourceware.org to publish static artifacts from current git repos created in isolated containers. It can be used as alternative to git hooks or cron jobs to generate snapshots for code, manuals, api or coverage reports. https://snapshots.sourceware.org/binutils/trunk https://snapshots.sourceware.org/gdb/trunk The container files and build steps are defined through the builder project. = RISC-V Pioneer Box for builder.sourceware.org gcc CI Thanks to RISC-V International and SOPHGO we got a Milk-V Pioneer Box for builder.sourceware.org that we can use for gcc CI. When originally setup a full gcc build and check took ~10 hours. After various bug fixes and tweaks to the build system it now takes ~4 hours. It has 64 cores, but single core performance isn't very fast. So fixing a few more parallelism bottlenecks could save even more build time. https://inbox.sourceware.org/20240801210720.gq24...@gnu.wildebeest.org/ = Sourceware @ Cauldron 2024 Various Sourceware Project Leadership committee members were present at the Cauldron and had an open discussion about services, plans, tips and tricks on using bugzilla and cgit, b4 and public-inbox, git-pw and patchwork, the snapshot builders and manual generation, wikis, buildbot and try-bots, ci-bots, full-builds and the bunsen testresults database and what makes developers most productive. BoF Report, Topics, and Notes: https://inbox.sourceware.org/20240925004343.gr21...@gnu.wildebeest.org/ = A Sourceware Forge (an experiment with Forgejo) In multiple discussions at the Cauldron various developers and maintainers indicated they really would like to do a serious experiment with a Forge and a pull-request workflow. There will be no drastic changes. We'll keep improving services to make the (email-based) workflows better and more efficient. But we will also do an experiment with Forgejo to let people try out a pull request workflow. We don't know if the experiment will be successful, nobody will be forced to participate, but volunteers to try it out (and help with the setup and configuration) are more than welcome. It might take up to a year to determine whether the experiment is a success or a failure. We secured a VM from Red Hat OSCI that should have enough resources for the initial experiment. The Sourceware PLC will discuss what resources are needed if we want to roll this out for all Sourceware projects. We already made anestimate for a larger gitolite server as part of the Security Vision document: https://sourceware.org/sourceware-security-vision.html Part of the Forgejo experiment will be making sure the resource estimates are correct. Sergio Durigan Junior and Mark J. Wielaard are currently setting up the Forge and hope to have a call for participation in ~2 weeks. = Sourceware Open Office hours Every second Friday of the month is the Sourceware Overseers Open Office hour in #overseers on irc.libera.chat from 16:00 till 17:00 UTC. Please feel free to drop by with any Sourceware services and hosting questions. 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 Sourceware PLC, Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard, Elena Zannoni
