RE: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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

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

2024-09-23 Thread 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 config

Re: GCC Doxygen documentation

2024-09-23 Thread 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!

GCC Doxygen documentation

2024-09-23 Thread 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 th

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

2024-09-23 Thread 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

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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 repositori

GCC 14.2: Configuring with zstd support

2024-09-23 Thread 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

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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 mana

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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 reque

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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 > >

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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 rais

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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 ma

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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

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

2024-09-23 Thread 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 Tar

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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 submiss

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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

Re: On pull request workflows for the GNU toolchain

2024-09-23 Thread 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

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

2024-09-23 Thread 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: New calling convention gotham_call

2024-09-23 Thread 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 fi

[PATCH] Update email in MAINTAINERS file.

2024-09-23 Thread 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 +

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

2024-09-23 Thread 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