Re: New calling convention gotham_call

[Frederick Virchanza Gotham via Gcc]

On Tue, Aug 20, 2024 at 9:38 AM LIU Hao  wrote:
>
> 2024-08-20 16:13, Frederick Virchanza Gotham:
> >
> > I want to write a new calling convention into the GNU g++ compiler,
> > specifically for the x86_64 instruction set.
>
> The x64 calling convention is much more complex than x86. Each of the first 
> four parameter is not
> only assigned an integer register, but also an SSE register (XMM0 - XMM3) and 
> a shadow slot on the
> stack.


My understanding of the SystemV calling convention used on x86_64
Linux, Apple, FreeBSD, is that the RDI register is used for the first
integer parameter, and that the XMM0 register is used for the first
floating point parameter. That is to say, if the function doesn't take
any integer parameters, then RDI won't be used, and if the function
doesn't take any floating point parameters, then XMM0 won't be used.

If we change the first integer parameter register from RDI to RAX, I
don't see why this has to have any effect on the floating point
registers.

Can you please point me to the source/header file in GCC where I would
add a new calling convention? At first I just want to copy-paste the
SystemV calling convention code and give it a new name like
"gotham_call" to see if it works, and then  later I'll make small
changes to it such as changing RDI to RAX.

Re: On pull request workflows for the GNU toolchain

[Jeffrey Walton via Gcc]

On Mon, Sep 23, 2024 at 8:08 AM Thomas Koenig via Gdb
 wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The Fortran unsigned
> branch, which I managed to put into an unrepairable state
> despite considerable help from people who tried to help me
> fix it). This is especially true of volunteer maintainers,
> who are still the mainstay of gfortran.

++.

Thousands of upvotes on Stack Overflow questions about simple Git
tasks indicate usability problems in Git, and not a great question on
social media. Confer, .

> Whatever you end up doing, consider such maintainers, and
> if they still can contribute or would simply give up.
> If what you end up doing is too complicated, it may end up
> severely impacting the gfortran project (and possibly others).

Jeff

Re: On pull request workflows for the GNU toolchain

[Richard Earnshaw (lists) via Gcc]

On 19/09/2024 16:51, Joseph Myers via Gcc wrote:

1. Introduction

This message expands on my remarks at the Cauldron (especially the
patch review and maintenance BoF, and the Sourceware infrastructure
BoF) regarding desired features for a system providing pull request
functionality (patch submission via creating branches that are then
proposed using some kind of web interface or API, with a central
database then tracking the status of each pull request and review
comments thereon automatically), for use by the GNU toolchain (or one
or more components thereof - there is no need for each component to
make the same decision about moving to such software and workflow, and
indeed we have no mechanism to make such decisions for the toolchain
as a whole).

This does not advocate a particular choice of software for such
functionality (though much of the discussion seemed to suggest Forgejo
as the most likely starting point), or a particular choice of where to
host it.  Hosting would of course need to meet appropriate security
requirements, and to achieve a passing grade on the GNU Ethical
Repository Criteria, and the software would need to be entirely free
software.  Where relevant features are not already supported, it's
important that the software is receptive to the addition of such
features (including cases where part of the functionality is provided
by software specific to the GNU toolchain or parts thereof - such as
for the custom checks currently implemented with git hooks - and the
underlying software provides appropriate interfaces to allow
integration of such external pieces).  The list of features here may
be a good basis for reviewing what particular forge software supports
and whether other features can be added, directly or through use of
appropriate APIs.

Forge software may provide other pieces such as bug tracking or wikis
that we currently handle separately from git hosting.  In such cases,
we should be able to disable those pieces and keep using the existing
bug tracking and wiki software (while having the option to decide
independently to migrate those if desired).

I consider the overall benefits of such a move to be having more
structured data about all changes proposed for inclusion and their
status (needing review, needing changes from the author, under
discussion, needing merge from mainline, etc.), to help all people
involved in the patch submission and review process to track such
information and to find patches needing review as applicable, along
with providing a more familiar workflow for many people that avoids
many of the problems with email (which affect experienced contributors
working around corporate email systems, not just new contributors).
It would not of course by itself turn people with no interest in or
understanding of systems software development into contributors (for
example, people without knowledge of directories and hierarchical file
storage, or people who only understand software development as web
development).  Nor would it prevent the accumulation of large backlogs
of unreviewed patches, as is evident from many large and active
projects using PR workflows with large numbers of open PRs.

As Richard noted in his BoF, email sucks.  As I noted in reply, so do
the web and web browsers when trying to deal with large amounts of
patch review state (when one wishes to apply one's own view, not the
forge's, of what is resolved and what needs attention).  As I also
noted, in the Sourceware infrastructure BoF, tools such as patchwork
and b4 are the right answer to the wrong question: trying to get
structured data about patch submissions when working from the axiom
that emails on a mailing list should be the primary source of truth
for everything needing review, rather than starting from more
structured data and generating emails as one form of output.

Moving to a pull request system is not expected to change policies
regarding who can approve a change for inclusion, or the technical
limits on who can cause a change to enter mainline (e.g. all people
with commit access would be expected to be able to use a button in a
web interface to cause to PR to be merged, though policy might limit
when they should do so).  We can of course choose to change policies,
either as part of adopting a PR system or later.


2. Key features

(a) Some forges have a design that emphasises the tree you get after a
proposed contribution, but not the sequence of commits to get there.
For the toolchain, we care about the clean, logical sequence of
commits on the mainline branch.  (We also use linear history on
mainline, but that's a secondary matter - though certainly we'd want
any forge used to support such linear history so that property doesn't
need to change as part of adopting pull request workflow.)  Having a
clean sequence of commits has some implications for forge support:

* Support for reviewing the proposed commit message, not just the
   diffs, is important (and it should be clear what 

Office Hours for the GNU Toolchain on 2024-09-26 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-09-26 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos

Re: On pull request workflows for the GNU toolchain

[enh via Gcc]

it doesn't make the patch _management_ problem better ("now i have two
problems"), but https://github.com/landley/toybox takes the "why not both?"
approach --- you can use pull requests if you grew up with/adapted to
git/github, or you can use the mailing list otherwise ... taking into
account that what the "barriers" are depend on whose eye's you're looking
through.

somewhat related, Android's NDK uses github as their issue tracker [while
still having Google's usual "buganizer" issue tracker available] and we get
orders of magnitude more interaction with our users on github --- like it
or not, it's where the users are. anecdotally i notice people report
bugs/send patches to github _mirrors_ of AOSP projects, and have no idea
that's not the actual upstream.


On Mon, Sep 23, 2024 at 9:23 AM Jonathan Wakely 
wrote:

> On Mon, 23 Sept 2024 at 13:09, Thomas Koenig via Gcc 
> wrote:
> >
> > [For the fortran people: Discussion on gcc@]
> >
> > Just a general remark.
> >
> > There are people, such as myself, who regularly mess up
> > their git repositories because they have no mental model
> > of what git is doing
>
> I highly recommend https://www.youtube.com/watch?v=1ffBJ4sVUb4 which
> gives an excellent mental model for the basics (and everything else
> follows from those basic rules).
>
> > (case in point: The Fortran unsigned
> > branch, which I managed to put into an unrepairable state
> > despite considerable help from people who tried to help me
> > fix it). This is especially true of volunteer maintainers,
> > who are still the mainstay of gfortran.
> >
> > Whatever you end up doing, consider such maintainers, and
> > if they still can contribute or would simply give up.
> > If what you end up doing is too complicated, it may end up
> > severely impacting the gfortran project (and possibly others).
>
> We already use Git in all the toolchain projects and there's no
> suggestion to change that.
>
> The discussion is about how we do patch submission and patch review.
> The GitHub pull request workflow is widely seen as simpler than our
> current email-based workflow (not everybody agrees, of course). The
> idea is to *lower* the barrier of entry for contributors, not raise
> it.
>

Re: On pull request workflows for the GNU toolchain

[Jonathan Wakely via Gcc]

On Mon, 23 Sept 2024 at 16:20, Florian Weimer wrote:
>
> * Jonathan Wakely:
>
> > The discussion is about how we do patch submission and patch review.
> > The GitHub pull request workflow is widely seen as simpler than our
> > current email-based workflow (not everybody agrees, of course). The
> > idea is to *lower* the barrier of entry for contributors, not raise
> > it.
>
> It should also help those who feel unsure about their use of Git because
> the reviewers see exactly what ends up getting merged (at least with the
> default workflow).  With the email-based workflow, that isn't the case,
> and I know it makes some people feel nervous.


Yes, our current workflow is "the patch in your email looks good,
please push what you have in your tree", and what gets pushed could be
different from what was reviewed (probably unintentionally). I don't
think issues caused by this happen often, but a pull-based workflow
can avoid the problem.

Re: On pull request workflows for the GNU toolchain

[Iain Sandoe]

> On 23 Sep 2024, at 15:33, Jonathan Wakely  wrote:
> 
> On Mon, 23 Sept 2024 at 14:36, enh wrote:
>> 
>> it doesn't make the patch _management_ problem better ("now i have two 
>> problems"), but https://github.com/landley/toybox takes the "why not both?" 
>> approach --- you can use pull requests if you grew up with/adapted to 
>> git/github, or you can use the mailing list otherwise ... taking into 
>> account that what the "barriers" are depend on whose eye's you're looking 
>> through.
>> 
>> somewhat related, Android's NDK uses github as their issue tracker [while 
>> still having Google's usual "buganizer" issue tracker available] and we get 
>> orders of magnitude more interaction with our users on github --- like it or 
>> not, it's where the users are. anecdotally i notice people report bugs/send 
>> patches to github _mirrors_ of AOSP projects, and have no idea that's not 
>> the actual upstream.
> 
> We have the same problem with github's gcc-mirror/gcc repo which we
> don't even own and so can't do anything with.

Similatly..  I get waay more Darwin bug reports via the development branches on 
GH than I do directly (even when the bug applies totally to ‘upstream’).

Re: On pull request workflows for the GNU toolchain

[Florian Weimer via Gcc]

* Jonathan Wakely:

> The discussion is about how we do patch submission and patch review.
> The GitHub pull request workflow is widely seen as simpler than our
> current email-based workflow (not everybody agrees, of course). The
> idea is to *lower* the barrier of entry for contributors, not raise
> it.

It should also help those who feel unsure about their use of Git because
the reviewers see exactly what ends up getting merged (at least with the
default workflow).  With the email-based workflow, that isn't the case,
and I know it makes some people feel nervous.

Thanks,
Florian

Re: On pull request workflows for the GNU toolchain

[Eric Gallager via Gcc]

On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc  wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The Fortran unsigned
> branch, which I managed to put into an unrepairable state
> despite considerable help from people who tried to help me
> fix it).

As one such person who has messed up his fork of GCC, I'd just like to
note that in my particular case at least, I messed it up because I was
trying to apply GitHub's model for git usage, while the GCC project
has a very different model for git usage, and the two don't exactly
play very well with one another. I see switching to a pull request
model as reducing the chances of people getting their forks into
unusable states, rather than increasing it.

> This is especially true of volunteer maintainers,
> who are still the mainstay of gfortran.
>
> Whatever you end up doing, consider such maintainers, and
> if they still can contribute or would simply give up.
> If what you end up doing is too complicated, it may end up
> severely impacting the gfortran project (and possibly others).
>
> Best regards
>
> Thomas
>
>
>

Re: On pull request workflows for the GNU toolchain

[Arsen Arsenović via Gcc]

Thomas Koenig  writes:

> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The Fortran unsigned
> branch, which I managed to put into an unrepairable state
> despite considerable help from people who tried to help me
> fix it). This is especially true of volunteer maintainers,
> who are still the mainstay of gfortran.
>
> Whatever you end up doing, consider such maintainers, and
> if they still can contribute or would simply give up.
> If what you end up doing is too complicated, it may end up
> severely impacting the gfortran project (and possibly others).

Git is extremely helpful if one learns to wield it rather than fight it.
It is based on a very simple model also.  I strongly encourage going
over https://git-scm.com/book/en/v2 and/or
https://eagain.net/articles/git-for-computer-scientists/ as it might
help you even independent of collaboration (for instance, I scarcely do
any work _without_ git nowadays.. it helps me to find old revisions and
temporary unfinished work, to synchronize work across machines, to
triage bugs, context switch, ...).

The workflow change proposed would reduce sending and reviewing patches
to a push, and interaction via some different (perhaps web?) means.  It
should not be more complex than email.

If the gfortran project finds that such a workflow hinders it, I suggest
a hybrid approach, where maintainers still can send patches via current
means.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

GCC 14.2: Configuring with zstd support

[Paul Smith via Gcc]

Many of the GNU toolchain projects are adding zstd compression.  This
is good, but the configure support for this is not ideal.

In particular for GCC, there are a number of issues.

The first problem is that the two subdirectories that use zstd
(libbacktrace and gcc) use very different methods to detect and support
it.


In libbacktrace/configure.ac we have only:

  AC_CHECK_LIB([zstd], [ZSTD_compress],
  [AC_DEFINE(HAVE_ZSTD, 1, [Define if -lzstd is available.])])

This means that the only way to allow libbacktrace to locate the zstd
library, is if it's installed into the base system / sysroot, or else
figuring out what extra global CFLAGS/LDFLAGS/LIBS you need to add. 
And for GCC in particular, since it might be building both stage1 and
stage2, you need to work out how to manage that.

I tried for a number of days and just completely failed to find the
correct incantation, if there even is one: all attempts broke something
somewhere.  It seems that these global variables are not used
everywhere they are needed (during configure tests).  I ended up making
a copy of my sysroot, installing zstd into the copy, and building GCC
with that.


In gcc/configure.ac on the other hand we have:

  AC_ARG_WITH(zstd,
  [AS_HELP_STRING([--with-zstd=PATH],
  [specify prefix directory for installed zstd library.
   Equivalent to --with-zstd-include=PATH/include
   plus --with-zstd-lib=PATH/lib])])
  AC_ARG_WITH(zstd-include,
  [AS_HELP_STRING([--with-zstd-include=PATH],
  [specify directory for installed zstd include files])])
  AC_ARG_WITH(zstd-lib,
  [AS_HELP_STRING([--with-zstd-lib=PATH],
  [specify directory for the installed zstd library])])

which, if it worked, seems to give a lot of flexibility.

However, I've not been able to get this to work because it's not clear
to which stage these paths will be applied.  There's also a weird issue
where if you don't provide the PATH (e.g., just use --with-zstd) then
this code in gcc/configure.ac:

  case "x$with_zstd" in
x) ;;
xno)
  ZSTD_INCLUDE=
  ZSTD_LIB=
  ;;
*) ZSTD_INCLUDE=$with_zstd/include
   ZSTD_LIB=$with_zstd/lib
   ;;
  esac

does the wrong thing because $with_zstd is "yes", so it adds
"-Iyes/include" to the compile line etc.  I guess the idea here is that
the GCC configure script would detect zstd and use it if it's present
so you don't need --with-zstd if it's already in the sysroot, but
usually explicitly adding this allows the configure to fail if it's not
found instead of silently continuing.

It definitely breaks to use the sysroot: "--with-zstd=/sysroot/usr"
will cause the configure to fail with obscure errors because the
compile tests add -I/sysroot/usr/include; this doesn't use -isystem
which means that the fix-includes are searched AFTER this, and so the
un-fixed headers are searched first.


Beyond all that, there's the problem that if you build zstd as a static
library with threading support, you can't link it without -pthread on
the link line.  If you don't use -pthread you get linker errors for
pthread_* symbols and configure decides that zstd is not supported.  I
couldn't find any way to successfully pass this through the various
layers during bootstrap etc., so I had to just build zstd without
threading support for use with GCC.


A lot of these issues could be resolved if GCC's configure (both in
libbacktrace and in gcc) used pkg-config to detect zstd.  The
pkg-config files will give you info about the header file location, the
library location, AND the various linker flags like -pthread.

One issue with this is that when building a cross-compiler we'd need to
distinguish between pkg-config run for the host vs. pkg-config run for
the target.  It's not clear how to handle the standard PKG_CONFIG_*
variables in this situation; since it's peculiar to GCC I doubt the
pkg-config folks have an opinion.  Maybe the user would have to define
a _TARGET variation of these variables, and the makefile would have to
swap them so pkg-config finds the correct ones at the correct time.

Re: On pull request workflows for the GNU toolchain

[Jonathan Wakely via Gcc]

On Mon, 23 Sept 2024 at 19:00, Eric Gallager via Gcc  wrote:
>
> On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc  wrote:
> >
> > [For the fortran people: Discussion on gcc@]
> >
> > Just a general remark.
> >
> > There are people, such as myself, who regularly mess up
> > their git repositories because they have no mental model
> > of what git is doing (case in point: The Fortran unsigned
> > branch, which I managed to put into an unrepairable state
> > despite considerable help from people who tried to help me
> > fix it).
>
> As one such person who has messed up his fork of GCC, I'd just like to
> note that in my particular case at least, I messed it up because I was
> trying to apply GitHub's model for git usage, while the GCC project
> has a very different model for git usage, and the two don't exactly
> play very well with one another.

Only in the sense that the GCC project wants a linear history without
merge requests, and GitHub will happily let you create whatever mess
of merges and jumbled commits you choose to. Using pull requests won't
change that - you will need to sort your branch out before it will get
merged.


> I see switching to a pull request
> model as reducing the chances of people getting their forks into
> unusable states, rather than increasing it.

I don't think it will change it at all, you'll still be able to do
anything to your fork, it just won't get approved for merging if it's
a mess.

Re: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04)

[Richard Biener via Gcc]

On Fri, Sep 20, 2024 at 6:50 PM Thomas Schwinge  wrote:
>
> Hi!
>
> (This is orthogonal to yesterday's
> "GCC 15: nvptx '-mptx=3.1' multilib variants are deprecated".)
>
> We'd like to raise nvptx code generation from PTX ISA 6.0, sm_30 "Kepler"
> to default PTX ISA 7.3, sm_52 "Maxwell", therefore CUDA 11.3 (2021-04).
> This is, primarily, so that we're able to use 'alloca' and related stack
> manipulation instructions, and improve upon the current:
>
> sorry ("target cannot support alloca");
>
> I see, for example:
>
>   - Ubuntu 22.04 "jammy" LTS has 11.5.1-1ubuntu1 packaged
>   - Debian 12 "stable" ("bookworm", 2023-06) has 11.8.89~11.8.0-5~deb12u1 
> packaged
>
> ..., and sm_52 "Maxwell" has been supported as of CUDA 6.5 (2014-08), and
> thus supported by most Nvidia GPUs of the last decade, approximately.
>
> The question is, whether we continue to build by default also the current
> sm_30 "Kepler" multilib variants (to be available for use via
> building/linking with '-march=sm_30'), or if that's truly obsolete by
> now, and need no longer be available by default?  (It has been deprecated
> for a long time, and sm_3x "Kepler architecture support is removed from
> CUDA 12.0", 2022-12.)  There's always the 'configure'-time
> '--with-arch=sm_30' if you (additionally to sm_52) still need your target
> libraries built for sm_30 multilib variants; I would argue that's
> sufficient?

I seem to have Turing so the change works for me;  How would the user
experience be with using the sm_30 multilib?

Richard.

>
> Grüße
>  Thomas

[PATCH] Update email in MAINTAINERS file.

[Aldy Hernandez via Gcc]

From: Aldy Hernandez 

ChangeLog:

* MAINTAINERS: Update email and add myself to DCO.
---
 MAINTAINERS | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cfd96c9f33e..e9fafaf45a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -116,7 +116,7 @@ riscv port  Jim Wilson  

 rs6000/powerpc port David Edelsohn  
 rs6000/powerpc port Segher Boessenkool  
 rs6000/powerpc port Kewen Lin   
-rs6000 vector extns Aldy Hernandez  
+rs6000 vector extns Aldy Hernandez  
 rx port Nick Clifton
 s390 port   Ulrich Weigand  
 s390 port   Andreas Krebbel 
@@ -213,7 +213,7 @@ c++ runtime libsJonathan Wakely 

 c++ runtime libs special modes  Fran??ois Dumont 
 fixincludes Bruce Korb  
 *gimpl* Jakub Jelinek   
-*gimpl* Aldy Hernandez  
+*gimpl* Aldy Hernandez  
 *gimpl* Jason Merrill   
 gcse.cc Jeff Law
 global opt frameworkJeff Law
@@ -240,7 +240,7 @@ option handling Joseph Myers

 middle-end  Jeff Law
 middle-end  Ian Lance Taylor
 middle-end  Richard Biener  
-*vrp, rangerAldy Hernandez  
+*vrp, rangerAldy Hernandez  
 *vrp, rangerAndrew MacLeod  
 tree-ssaAndrew MacLeod  
 tree browser/unparser   Sebastian Pop   
@@ -518,7 +518,7 @@ Daniel Hellstromdanielh 

 Fergus Henderson-   
 Richard Henderson   rth 
 Stuart Hendersonshenders
-Aldy Hernandez  aldyh   
+Aldy Hernandez  aldyh   
 Philip Herron   redbrain
 Marius Hillenbrand  -   
 Matthew Hiller  -   
@@ -948,3 +948,4 @@ Jonathan Wakely 

 Alexander Westbrooks
 Chung-Ju Wu 
 Pengxuan Zheng  
+Aldy Hernandez  
-- 
2.43.0

GCC nvptx-none Target Testing (was: New page "nvptx" in the GCC wiki to document --target=nvptx-none configurations)

[Thomas Schwinge]

Hi!

On 2017-02-16T21:10:20+0100, I wrote:
> I created a new page "nvptx" in the GCC wiki to document
> --target=nvptx-none configurations: .

(I've revised that one -- it's been a few years... -- and in particular
then) I've added more details re "GCC nvptx-none Target Testing":
, which
Prathamesh was asking for at the recent GNU Tools Cauldron 2024.


Grüße
 Thomas

Re: On pull request workflows for the GNU toolchain

[Jonathan Wakely via Gcc]

On Mon, 23 Sept 2024 at 14:36, enh wrote:
>
> it doesn't make the patch _management_ problem better ("now i have two 
> problems"), but https://github.com/landley/toybox takes the "why not both?" 
> approach --- you can use pull requests if you grew up with/adapted to 
> git/github, or you can use the mailing list otherwise ... taking into account 
> that what the "barriers" are depend on whose eye's you're looking through.
>
> somewhat related, Android's NDK uses github as their issue tracker [while 
> still having Google's usual "buganizer" issue tracker available] and we get 
> orders of magnitude more interaction with our users on github --- like it or 
> not, it's where the users are. anecdotally i notice people report bugs/send 
> patches to github _mirrors_ of AOSP projects, and have no idea that's not the 
> actual upstream.

We have the same problem with github's gcc-mirror/gcc repo which we
don't even own and so can't do anything with.

Re: On pull request workflows for the GNU toolchain

[Joseph Myers via Gcc]

On Mon, 23 Sep 2024, Richard Earnshaw (lists) via Gcc wrote:

> One thing we must do, however, is break requirements into a number of
> categories: must haves (red lines, we can't transition without this); should
> haves (important, but we can likely find acceptable work-arounds); and would
> like (this would make things really nice, but they won't really block a
> transition).

The assessment of a forge against the criteria isn't expected to be simple 
yes/no; it's expected to involve more of an analysis/discussion of how 
criteria / underlying goals relate to the facilities provided by a 
particular forge.  And there isn't a very sharp line between "work-around" 
and "doing this in some external software hooked up to the forge with an 
API is the expected way of doing such things with the forge".  (Plenty of 
projects make extensive use of APIs to implement their own workflows on 
GitHub, for example.  That sort of thing works much better for e.g. CI or 
actions that are supposed to happen post-commit, than for something like 
support for dependencies / patch series which is more of a core feature 
needing to be present in the underlying software.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: On pull request workflows for the GNU toolchain

[Joseph Myers via Gcc]

On Mon, 23 Sep 2024, enh via Gcc wrote:

> it doesn't make the patch _management_ problem better ("now i have two
> problems"), but https://github.com/landley/toybox takes the "why not both?"
> approach --- you can use pull requests if you grew up with/adapted to
> git/github, or you can use the mailing list otherwise ... taking into
> account that what the "barriers" are depend on whose eye's you're looking
> through.

My expectation is that such a split would need to work for an initial 
transitional period at least (for reviews of patches posted before the 
move to the forge software without requiring all such under-review patches 
to go into PRs if people want review, if nothing else).  While I think 
there are advantages in terms of structured data if everything ends up 
using PRs (including people doing PRs that are immediately self-merged of 
changes in areas they maintain), it would be possible to do otherwise (at 
least until you get to wanting all merges to mainline to be done by a CI 
system that maintains a regression-free state for at least one 
configuration).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: On pull request workflows for the GNU toolchain

[Thomas Koenig via Gcc]

[For the fortran people: Discussion on gcc@]

Just a general remark.

There are people, such as myself, who regularly mess up
their git repositories because they have no mental model
of what git is doing (case in point: The Fortran unsigned
branch, which I managed to put into an unrepairable state
despite considerable help from people who tried to help me
fix it). This is especially true of volunteer maintainers,
who are still the mainstay of gfortran.

Whatever you end up doing, consider such maintainers, and
if they still can contribute or would simply give up.
If what you end up doing is too complicated, it may end up
severely impacting the gfortran project (and possibly others).

Best regards

Thomas

Re: On pull request workflows for the GNU toolchain

[Jonathan Wakely via Gcc]

On Mon, 23 Sept 2024 at 13:09, Thomas Koenig via Gcc  wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing

I highly recommend https://www.youtube.com/watch?v=1ffBJ4sVUb4 which
gives an excellent mental model for the basics (and everything else
follows from those basic rules).

> (case in point: The Fortran unsigned
> branch, which I managed to put into an unrepairable state
> despite considerable help from people who tried to help me
> fix it). This is especially true of volunteer maintainers,
> who are still the mainstay of gfortran.
>
> Whatever you end up doing, consider such maintainers, and
> if they still can contribute or would simply give up.
> If what you end up doing is too complicated, it may end up
> severely impacting the gfortran project (and possibly others).

We already use Git in all the toolchain projects and there's no
suggestion to change that.

The discussion is about how we do patch submission and patch review.
The GitHub pull request workflow is widely seen as simpler than our
current email-based workflow (not everybody agrees, of course). The
idea is to *lower* the barrier of entry for contributors, not raise
it.

Re: GCC Doxygen documentation

[David Malcolm via Gcc]

On Mon, 2024-09-23 at 15:45 -0700, Bryon Quackenbush via Gcc wrote:
> Greetings all,
> 
>    I am just starting the fun process of getting familiar with the
> GCC
> compiler and all it's various components (I'm starting out with
> LIBCPP,
> since that seems relatively small and simple)..

Welcome!

In case you haven't seen it, you might find this guide helpful:
  https://gcc-newbies-guide.readthedocs.io/en/latest/



> 
>    I've been poking around on the GCC Wiki and saw a reference on
> internal
> documentation that there was once web exposed Doxygen documentation
> of the
> GCC code which is currently marked as broken.  My question is: Is
> anyone
> aware of any Doxygen (or similarly generated) GCC code documentation
> that
> is exposed to the internet.

I believe that this page is regularly built from GCC's sources:
  https://gcc.opensuse.org/gcc-doxygen/index.html

Hope this is helpful
Dave

> 
>    Sadly, for the next 9 1/2 months I will not be in a position to be
> able
> to download / compile / test the code myself (long story).
> 
>    Thanks for the help.
> 
> - Bryon
> 

spelling of `side effects` vs `side-effects`

[Andrew Pinski via Gcc]

While working on the review from
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663418.html .
I noticed that there are places which use `side effects` and some use
`side-effects`. I assume we should follow a similar pattern as
`back-end` vs `back end`. That is `side effect` when used as a noun
and `side-effect` when used as an adjective (though I am not sure how
it would be used as an adjective).

Though we currently use both versions as nouns and almost evenly used
in just the sources:
apinski@xeond:~/src/upstream-gcc/gcc/gcc$ git grep "side effect" *.cc|wc -l
176
apinski@xeond:~/src/upstream-gcc/gcc/gcc$ git grep "side-effect" *.cc|wc -l
167

Note for my patch I am just going to use `side effect` when used as a noun.

Thanks,
Andrew

GCC Doxygen documentation

[Bryon Quackenbush via Gcc]

Greetings all,

   I am just starting the fun process of getting familiar with the GCC
compiler and all it's various components (I'm starting out with LIBCPP,
since that seems relatively small and simple)..

   I've been poking around on the GCC Wiki and saw a reference on internal
documentation that there was once web exposed Doxygen documentation of the
GCC code which is currently marked as broken.  My question is: Is anyone
aware of any Doxygen (or similarly generated) GCC code documentation that
is exposed to the internet.

   Sadly, for the next 9 1/2 months I will not be in a position to be able
to download / compile / test the code myself (long story).

   Thanks for the help.

- Bryon

RE: GCC nvptx-none Target Testing (was: New page "nvptx" in the GCC wiki to document --target=nvptx-none configurations)

[Prathamesh Kulkarni via Gcc]

> -Original Message-
> From: Thomas Schwinge 
> Sent: Monday, September 23, 2024 7:37 PM
> To: gcc@gcc.gnu.org; Prathamesh Kulkarni 
> Cc: Tom de Vries ; Roger Sayle
> 
> Subject: GCC nvptx-none Target Testing (was: New page "nvptx" in the GCC
> wiki to document --target=nvptx-none configurations)
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi!
> 
> On 2017-02-16T21:10:20+0100, I wrote:
> > I created a new page "nvptx" in the GCC wiki to document
> > --target=nvptx-none configurations: .
> 
> (I've revised that one -- it's been a few years... -- and in particular
> then) I've added more details re "GCC nvptx-none Target Testing":
> , which
> Prathamesh was asking for at the recent GNU Tools Cauldron 2024.
Hi Thomas,
This looks great, thanks a lot!

Best Regards,
Prathamesh
> 
> 
> Grüße
>  Thomas

RE: On pull request workflows for the GNU toolchain

[Jiang, Haochen via Gcc]

> From: Joseph Myers 
> Sent: Thursday, September 19, 2024 11:51 PM
> 

Hi Jospeh,

Thank for your overall introduction on the scope of the future PR
system. It will help the patches not flooded in mails. And keep merging
what we have got in PRs to the right branch to avoid some accidents.

I have several comments or maybe questions on that.

> 
> Forge software may provide other pieces such as bug tracking or wikis
> that we currently handle separately from git hosting.  In such cases,
> we should be able to disable those pieces and keep using the existing
> bug tracking and wiki software (while having the option to decide
> independently to migrate those if desired).

> 
> Similarly, commit emails should continue to go to the existing mailing
> lists for those.
>

Regarding this, it seems that we will still stick to Bugzilla, gcc-wwwdocs,
etc and also keep most of the current mailing threads.

I am running regression tests on x86_64 and sending the regressions to
gcc-regression mailing thread, will I need to send to another place or
using another API to do that?

Note: I am ok to change that if needed, but just in advance so that
I can have some time to test to avoid bugs in scripts.

> 
> Beyond putting everything through PRs, eventually I'd hope to have
> merges to mainline normally all go through a CI system that makes sure
> there are no regressions for at least one configuration before merging
> changes.
> 

CI might take long time if not just building but running regression tests
from my current experience, it might cause some inconvenience for
someone who only edits something like MAINTAINER lists.

Another question is should we also open a PR for backport commits?
I suppose we need that under current PR infrastructure to get it merged,
but it might be some redundancy. But it is definitely a good thing since
I once backported a patch a month earlier that I expected because I don't
notice I am on the wrong branch.

Also for the current commit for obvious, will that policy change?

Overall, I suppose the PR system will be better than current system, thanks
for all the efforts!

Thx,
Haochen

> 
> --
> Joseph S. Myers
> josmy...@redhat.com