Update to GCC copyright assignment policy

great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/ > Sent: Wednesday, June 02, 2021 at 2:28 AM > From: "Mark Wielaard" > To: "David Edel

Re: Update to GCC copyright assignment policy

> > What about the parts of GCC with FSF copyrights that are not covered by > > the GPL, but the GPL with exceptions? How is it possible to move code > > between the parts if a contributor previously used DCO and thus gave > > only permission to license under the open sour

Re: Update to GCC copyright assignment policy

On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier wrote: > | From: Mark Wielaard > > | This seems a pretty bad policy to be honest. > | Why was there no public discussion on this? > > Agreed. I also agree with the rest of Mark's message. > > (Note: I haven&#x

Re: Update to GCC copyright assignment policy

> On Jun 1, 2021, at 11:08 AM, Jason Merrill via Gcc wrote: > > On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier wrote: > >> | From: Mark Wielaard >> >> | This seems a pretty bad policy to be honest. >> | Why was there no public discussion on this? &

Re: Update to GCC copyright assignment policy

On Tue, Jun 01, 2021 at 11:25:16AM -0400, Paul Koning via Gcc wrote: > GCC is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 3, or (at your option) > any l

Re: Update to GCC copyright assignment policy

> What is the rationale after these changes anyway? Development of new features for libstdc++ has already moved away from gcc.gnu.org to avoid the copyright assignment. Other contributors have expressed a desire to do the same.

Re: Update to GCC copyright assignment policy

"Jose E. Marchesi via Gcc" writes: >> GCC was created as part of the GNU Project but has grown to operate as >> an autonomous project. >> >> The GCC Steering Committee has decided to relax the requirement to >> assign copyright for all changes to th

Re: Update to GCC copyright assignment policy

Paul Koning via Gcc writes: >> GCC's license is "GPL version 3 or later", so if there ever needed to be a >> GPL v4, we could move to it without needing permission from anyone. > > I don't think that is what the license says. It says: > > GCC is f

Re: Update to GCC copyright assignment policy

On Tue, Jun 1, 2021 at 11:14 AM Jose E. Marchesi wrote: > > > > GCC was created as part of the GNU Project but has grown to operate as > > an autonomous project. > > > > The GCC Steering Committee has decided to relax the requirement to > > assign copyright

Re: Update to GCC copyright assignment policy

On Tue, Jun 1, 2021 at 11:15 AM Jose E. Marchesi via Gcc wrote: > > > GCC was created as part of the GNU Project but has grown to operate as > > an autonomous project. > > > > The GCC Steering Committee has decided to relax the requirement to > > assign copy

Re: Update to GCC copyright assignment policy

On Tue, Jun 1, 2021 at 10:40 AM Paul Koning wrote: > > > On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc wrote: > > > > The copyright author will be listed as "Free Software Foundation, > > Inc." and/or "The GNU Toolchain Authors", as appro

Update to GCC copyright assignment policy

> Sent: Wednesday, June 02, 2021 at 4:01 AM > From: "Maciej W. Rozycki" > To: "Paul Koning" > Cc: "Jakub Jelinek" , "GCC Development" > Subject: Re: Update to GCC copyright assignment policy > > On Tue, 1 Jun 2021, Paul Konin

Update to GCC copyright assignment policy

> Sent: Wednesday, June 02, 2021 at 4:09 AM > From: "Paul Smith" > To: gcc@gcc.gnu.org > Subject: Re: Update to GCC copyright assignment policy > > On Tue, 2021-06-01 at 11:50 -0400, David Edelsohn via Gcc wrote: > > The current, active license in GPL v3.0.

Re: Update to GCC copyright assignment policy

> So that cannot be the rationale for this. I do not want to contribute my work to a project that requires FSF copyright assignment to the rest of the project, even if it wouldn't be required for (some of) my own contributions. In any case, historically libstdc++ *does* require an assignment. If y

Re: Update to GCC copyright assignment policy

I see two cases here: 1. You release a modified copy of gcc, your parts can be whatever you want, sure, as long as it's GPLv3 compatible. 2. You're contributing *to* gcc, in which case, I'd hope that any attempts to impose a different license would be rejected at the patch review step.

Re: Update to GCC copyright assignment policy

> On Jun 1, 2021, at 12:09 PM, David Edelsohn via Gcc wrote: > > On Tue, Jun 1, 2021 at 10:40 AM Paul Koning wrote: >> >>> On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc wrote: >>> >>> The copyright author will be listed as "Free

Re: Update to GCC copyright assignment policy

> On Jun 1, 2021, at 12:44 PM, Joseph Myers wrote: > > On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote: > >> The copyright author will be listed as "Free Software Foundation, >> Inc." and/or "The GNU Toolchain Authors", as appropriate. > &g

Update to GCC copyright assignment policy

> Sent: Wednesday, June 02, 2021 at 4:24 AM > From: "Maciej W. Rozycki" > To: "Christopher Dimech" > Cc: "Paul Koning" , "Jakub Jelinek" > , "GCC Development" > Subject: Re: Update to GCC copyright assignment policy >

Update to GCC copyright assignment policy

://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/ > Sent: Wednesday, June 02, 2021 at 4:44 AM > From: "Joseph Myers" > To: "David Edelsohn" > Cc: "Jakub Jelinek" , "GCC Development" > Subject: Re: Update to GCC copyright assig

[PATCH] MAINTAINERS: create DCO section; add myself to it

On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: > GCC was created as part of the GNU Project but has grown to operate > as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to

Update to GCC copyright assignment policy

> Sent: Wednesday, June 02, 2021 at 4:20 AM > From: "Maciej W. Rozycki" > To: "DJ Delorie" > Cc: "Paul Koning" , gcc@gcc.gnu.org > Subject: Re: Update to GCC copyright assignment policy > > On Tue, 1 Jun 2021, DJ Delorie via Gcc wrote: > &

Re: [PATCH] MAINTAINERS: create DCO section; add myself to it

On June 1, 2021 7:30:54 PM GMT+02:00, David Malcolm via Gcc wrote: >On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: >> GCC was created as part of the GNU Project but has grown to operate >> as >> an autonomous project. >> >> The GCC Steering C

Update to GCC copyright assignment policy

> Sent: Wednesday, June 02, 2021 at 7:58 AM > From: "Thomas Rodgers" > To: "Mark Wielaard" > Cc: "GCC Development" > Subject: Re: Update to GCC copyright assignment policy > > On 2021-06-01 07:28, Mark Wielaard wrote: > > > Hi Davi

Re: Update to GCC copyright assignment policy

On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc wrote: > > GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to

Re: Update to GCC copyright assignment policy

On 6/1/2021 5:22 PM, Eric Gallager via Gcc wrote: On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc wrote: GCC was created as part of the GNU Project but has grown to operate as an autonomous project. The GCC Steering Committee has decided to relax the requirement to assign copyright

New vendor branch for RISC-V: integration and experimental branch

send patches to gcc-patc...@gcc.gnu.org as normal patch submission flow, but with [riscv/integration] or [riscv/experimental] tag in the title. # What if we want a stable release for integration and experimental branch We don't have that yet, but we intend to maintain two corresponding br

Does bootstrap make native compiler faster? Should I always use --disable-boostrap?

The document said yes. However, what does bootstrap actually do that can make compiler faster? Sent from Mail for Windows 10

Re: Update to GCC copyright assignment policy

On Wed, Jun 2, 2021 at 4:10 AM Mark Wielaard wrote: > On Tue, Jun 01, 2021 at 11:05:24AM -0400, Richard Kenner wrote: > > > > What about the parts of GCC with FSF copyrights that are not covered > by > > > > the GPL, but the GPL with exceptions? How is it possible

Update to GCC copyright assignment policy

> Sent: Thursday, June 03, 2021 at 2:36 AM > From: "Jason Merrill via Gcc" > To: "Mark Wielaard" > Cc: "Florian Weimer" , "gcc Mailing List" > > Subject: Re: Update to GCC copyright assignment policy > > On Wed, Jun 2, 2021 at 4

Re: Update to GCC copyright assignment policy

On Wed, Jun 2, 2021 at 4:18 AM Mark Wielaard wrote: > Hi Thomas, > > On Tue, Jun 01, 2021 at 12:58:12PM -0700, Thomas Rodgers wrote: > > On 2021-06-01 07:28, Mark Wielaard wrote: > > > If we no longer want the FSF to be the legal guardian and copyright > > > ho

Re: GCC documentation: porting to Sphinx

e level in the Spinx manual: -Wformat-overflow, -Wno-format-overflow When the /level/ is then discussed in the rest of the text it's not clear what it refers to. Martin Note the documentation is automatically ([1]) generated from texinfo with a GitHub workflow ([2]). It's built

Re: Update to GCC copyright assignment policy

On Thu, Jun 03, 2021 at 02:35:51PM +0200, Giacomo Tesio wrote: > > The GCC Steering Committee has decided to relax the requirement to > > assign copyright for all changes to the Free Software Foundation. GCC > > will continue to be developed, distributed, and licensed under t

Re: Update to GCC copyright assignment policy

nly includes changes under FSF copyright, possibly deferring the > > > introduction of non-fsf copyrighted code as much as technically > > > possible with git? > > > > No. > > May I ask why? Because it makes no sense, doing a GCC release is lots of work an

Re: Update to GCC copyright assignment policy

On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio wrote: > > I would have really appreciated if the GCC SC had announced such change > for the upcoming GCC 12 while sticking to the old policy in GCC 11. > That is how I was thinking of the change, but I agree that it needs clarification. Jason

Update to GCC copyright assignment policy

> Sent: Friday, June 04, 2021 at 2:45 AM > From: "Giacomo Tesio" > To: "Jakub Jelinek" > Cc: gcc@gcc.gnu.org > Subject: Re: Update to GCC copyright assignment policy > > On Thu, 3 Jun 2021 16:14:15 +0200 Jakub Jelinek wrote: > > > Becau

Update to GCC copyright assignment policy

> Sent: Friday, June 04, 2021 at 4:50 AM > From: "Daniel Pono Takamori" > To: gcc@gcc.gnu.org > Subject: Re: Update to GCC copyright assignment policy > > I'm joining this list just briefly to give some feedback and input on this > thread on behalf of So

Re: RFC: Sphinx for GCC documentation

> On Jun 4, 2021, at 3:55 AM, Tobias Burnus wrote: > > Hello, > > On 13.05.21 13:45, Martin Liška wrote: >> On 4/1/21 3:30 PM, Martin Liška wrote: >>> That said, I'm asking the GCC community for a green light before I >>> invest >>> m

Re: GCC documentation: porting to Sphinx

Martin Note the documentation is automatically ([1]) generated from texinfo with a GitHub workflow ([2]). It's built on the devel/sphinx GCC branch which I periodically with the master branch. One can see the current source .rst files here: [3]. Changes made since the last time: - a shared c

RFC: New mechanism for hard reg operands to inline asm

Hi, I wonder if we could replace the register asm construct for inline assemblies with something a bit nicer and more obvious. E.g. turning this (real world example from IBM Z kernel code): int diag8_response(int cmdlen, char *response, int *rlen) { register unsigned long reg2 asm ("2") =

Re: RFC: New mechanism for hard reg operands to inline asm

> On Jun 4, 2021, at 2:02 PM, Andreas Krebbel via Gcc wrote: > > Hi, > > I wonder if we could replace the register asm construct for > inline assemblies with something a bit nicer and more obvious. > E.g. turning this (real world example from IBM Z kernel code): >

Re: RFC: New mechanism for hard reg operands to inline asm

On 6/4/21 8:18 PM, Paul Koning wrote: ... > Yes, I would think this should be made a general mechanism that any target > could use. > > I wonder if instead of creating a new mechanism you could do this simply by > creating new constraint names, where each name matches exactly one hard > registe

Is NEGATE_EXPR gimple valid for pointer (and offset) types

While debugging PR 100925, I found that after my match.pd (for A?CST0:CST1) and phiopt patch to use match-and-simplify, gcc will produce an negate assignment gimple which has a pointer type (and offset type). Before we would produce "cond ? -1B : 0B" in this case but now we produce:

Can I add a new built-in macro __builtin_secure_generate_random(void* data, std::size_t size) for C and C++ on hosted GCC platforms that support it?

I think compiler time random number is useful for cryptography things like blinding. This built-in should also be constexpr. On platforms that does not support this feature (MSDOS) do not define this __builtin. Users can use #if __has_builtin(__builtin_secure_generate_random) #endif to dete

Re: Is NEGATE_EXPR gimple valid for pointer (and offset) types

On June 6, 2021 12:54:03 AM GMT+02:00, Andrew Pinski via Gcc wrote: >While debugging PR 100925, I found that after my match.pd (for >A?CST0:CST1) and phiopt patch to use match-and-simplify, gcc will >produce an negate assignment gimple which has a pointer type (and >offset type)

Re: Update to GCC copyright assignment policy

On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc wrote: > > On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio wrote: > > > > > I would have really appreciated if the GCC SC had announced such change > > for the upcoming GCC 12 while sticking to the old policy in GCC 11

Re: RFC: New mechanism for hard reg operands to inline asm

Paul Koning via Gcc writes: >> On Jun 4, 2021, at 2:02 PM, Andreas Krebbel via Gcc wrote: >> >> Hi, >> >> I wonder if we could replace the register asm construct for >> inline assemblies with something a bit nicer and more obvious. >> E.g. turning

Re: Update to GCC copyright assignment policy

On Mon, Jun 7, 2021 at 6:11 AM Giacomo Tesio wrote: > > Hi Richard, > > On June 7, 2021 7:35:01 AM UTC, Richard Biener > wrote: > > On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc > > wrote: > > > > > > On Thu, Jun 3, 2021 at 10:46 AM Giac

Re: Update to GCC copyright assignment policy

On Mon, Jun 7, 2021 at 3:10 PM Giacomo Tesio wrote: > > Hi Richard, > > On June 7, 2021 7:35:01 AM UTC, Richard Biener > wrote: > > On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc > > wrote: > > > > > > On Thu, Jun 3, 2021 at 10:46 AM Giac

Re: GCC 10.2: undefined reference to vtable: missing its key function

> On Jun 6, 2021, at 5:41 PM, Paul Smith wrote: > > I have a class which is NOT, as far as I can see, polymorphic. > > It doesn't inherit from any other class and none of its methods are > declared virtual. The class implementation and all its callers all > compile just fine. > > Is there s

Re: Update to GCC copyright assignment policy

On Mon, Jun 07, 2021 at 02:17:55PM +, Giacomo Tesio wrote: > Anyway, to most people it's just a matter of risk assesment. > > GCC will now come with a new legal risk that was absemt before, thus > it should be handled properly, with a proper notice and incapaulated > in

Re: Update to GCC copyright assignment policy

On Mon, Jun 7, 2021 at 11:23 AM Giacomo Tesio wrote: > On June 7, 2021 2:44:56 PM UTC, Jakub Jelinek wrote: > > > > Nonsense. GCC codebase doesn't have a single copyright holder for > > decades, just look at the source. > > > > libffi has various copyrig

Re: Update to GCC copyright assignment policy

On Mon, Jun 07, 2021 at 11:45:49AM -0400, Jason Merrill wrote: > The copyright troll risk is much, much lower for GCC than for Linux. > First, because GPL3 specifically addresses the over-strict automatic > termination rules in GPL2 that copyright trolls leverage. And also because &g

Re: Update to GCC copyright assignment policy

ntribution has been accepted (things and people change, > > > as you know) to cause demage to some users. > > > > The copyright troll risk is much, much lower for GCC than for Linux. > > In an ever changing world, this is very arguable. > > Yet I think you wi

Re: Incorrect linker paths for building gcc on 32-bit PowerPC

I believe that was recently fixed on trunk by fb6b24c66ea5a2ccbf6fb9f299c20a69f962ac9b On 6/3/21 4:59 AM, John Paul Adrian Glaubitz wrote: Hi! I'm currently building GCC from git on various Debian targets to help with the gccrs development effort a bit. On 32-bit PowerPC, I have run i

Re: Incorrect linker paths for building gcc on 32-bit PowerPC

I doubled checked and that commit was for a different 32 bit issue. What are you using for your build compiler?  binutils? On 6/7/21 2:19 PM, William Seurer via Gcc wrote: I believe that was recently fixed on trunk by fb6b24c66ea5a2ccbf6fb9f299c20a69f962ac9b On 6/3/21 4:59 AM, John Paul

Re: Update to GCC copyright assignment policy

> Sent: Tuesday, June 08, 2021 at 6:10 AM > From: "Giacomo Tesio" > To: "Jason Merrill" > Cc: "Jakub Jelinek" , "gcc Mailing List" > Subject: Re: Update to GCC copyright assignment policy > > Hi Jason, > > On June 7, 2021 5:

Update to GCC copyright assignment policy

> Sent: Tuesday, June 08, 2021 at 2:17 AM > From: "Giacomo Tesio" > To: "David Edelsohn" > Cc: "Jakub Jelinek" , "gcc Mailing List" > Subject: Re: Update to GCC copyright assignment policy > > Hi David, > > On June 7, 2021 1:2

Re: Update to GCC copyright assignment policy

for std::any_cast, which was accepted into the GCC tree within 24 hours of the patch being received. I consider this a great success for the project. I have more than 30 commits adding significant new C++23 features to libstdc++ which will be merged soon under the DCO.

Re: GCC 10.2: undefined reference to vtable: missing its key function

(This should have been on the gcc-help list.) > I may be remembering wrong, but -- doesn't dynamic_cast look for a vtable? It uses a vtable if one is present, it can't cause one to be introduced, so ... >So if you do a dynamic cast mentioning that class you'd get such a ref

Re: progress update after initial GSoC virtual meetup

the > analyzer subdirectory, rebuild, and rerun. With bootstrapping > disabled, if you run "make -jsome-number-of-cores" from the build > directory's "gcc" subdirectory, it should merely rebuild the .o file > for the .cc you touched, and do some relinking (and rerun

Re: progress update after initial GSoC virtual meetup

On Tue, 2021-06-08 at 21:20 +0530, Ankur Saini wrote: > > > > On 01-Jun-2021, at 6:38 PM, David Malcolm > > wrote: > > [...snip...] > > Maybe it's best to have an > > account on the GCC compile farm for this: > >  https://gcc.gnu.org/wiki/Compil

GCC Mission Statement

Hi. The Mission Statement of the GCC project recently changed without any announcement. I am not a contributor to GCC, merely a user. However, I'd like to understand more, especially about the transparency of the project. The GCC Steering Committee is supposed to follow the mission stateme

Re: GCC Mission Statement

Thank you. > Well there was an announcement; the changes in the mission statement reflect > the new reality introduced by that announcement: > > https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html > > Siddhesh I was aware of that announcement, but it doesn't mention t

Re: GCC Mission Statement

On 6/9/21 7:09 AM, Valentino Giudice via Gcc wrote: If the Steering Committee updates the mission statement, it may appear that the mission statement follows the decisions of the steering committee (in place of the contrary). In that case, what would be the purpose of a mission statement? In

replacing the backwards threader and more

Hi Jeff. Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite of the backwards threader code. I'd like to discuss the possibility of replacing the current backwards threader with a new one that gets far more threads and can p

Re: replacing the backwards threader and more

On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: > > Hi Jeff. Hi folks. > > What started as a foray into severing the old (forward) threader's > dependency on evrp, turned into a rewrite of the backwards threader > code. I'd like to discuss the possibil

Re: GCC Mission Statement

On 6/9/21 12:11 PM, Giacomo Tesio wrote: Hi Gabriel, On Wed, 9 Jun 2021 11:44:10 +0200 Gabriel Ravier via Gcc wrote: Speaking on the "change it recklessly" issue, I would personally say that SC has indeed arguably done this [...] some people threatened to pull away from GCC enti

Mission Statement

The recent changes in the control of Gcc have all been about survival. Although, the change in copyright assignment can prove beneficial to everybody, this assumes that the people in the Gcc Steering Committee are actually capable of formally understanding and operating the appropriate

Re: Mission Statement

On Jun 9, 2021, at 6:48 AM, Christopher Dimech via Gcc mailto:gcc@gcc.gnu.org>> wrote > All this could became meaningless in ten years time because major > changes have resulted from division. If we go on dividing the > world using a knife rather than stitching it together, every

Re: GCC Mission Statement

lore > different ways to implement a compiler collection cannot cause any harm. > > > > As for a lack of professionalism, I think it's pretty clear that GCC > > 11 is the cutoff point here > > May you point me to the line in the GCC 11.1's Changelog that > doc

Re: replacing the backwards threader and more

On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff. Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite of the backwards threader code. I'd like to d

GCC Mission Statement

> Sent: Thursday, June 10, 2021 at 3:26 AM > From: "Giacomo Tesio" > To: "Richard Biener" > Cc: "gcc@gcc.gnu.org" , "Valentino Giudice" > > Subject: Re: GCC Mission Statement > > Sure Richard, I know. > > On June 9, 2021

Re: Mission Statement

On Jun 9, 2021, at 8:30 AM, Christopher Dimech wrote: > > Besides inspiring a sceptic attitude, Cicero made the language of > the civilized world. Yes > This has nothing to do with any complaints > of mistreatment, but mostly about belief systems that have taken > over many people's lives. Tha

Re: replacing the backwards threader and more

On June 9, 2021 5:34:03 PM GMT+02:00, Aldy Hernandez wrote: > > >On 6/9/21 2:09 PM, Richard Biener wrote: >> On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc > wrote: >>> >>> Hi Jeff. Hi folks. >>> >>> What started as a foray into severi

Empty structures extensions

Should the docs at https://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html mention that you can use {} to initialize such structs?

Re: replacing the backwards threader and more

On 6/9/2021 9:34 AM, Aldy Hernandez wrote: On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff.  Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite o

Re: replacing the backwards threader and more

On 6/9/21 9:47 PM, Jeff Law wrote: On 6/9/2021 9:34 AM, Aldy Hernandez wrote: On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff.  Hi folks. What started as a foray into severing the old (forward) threader's dependen

Re: replacing the backwards threader and more

On 6/9/2021 2:39 PM, Aldy Hernandez wrote: On 6/9/21 9:47 PM, Jeff Law wrote: On 6/9/2021 9:34 AM, Aldy Hernandez wrote: On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff.  Hi folks. What started as a foray into severing

Mission Statement

> Sent: Thursday, June 10, 2021 at 3:49 AM > From: "Aaron Gyes via Gcc" > To: "GCC Administrator via Gcc" > Subject: Re: Mission Statement > > On Jun 9, 2021, at 8:30 AM, Christopher Dimech wrote: > > > > Besides inspiring a sceptic attit

Re: Mission Statement

> In this state of making something right, and making > something wrong, there is no way for inclusiveness. Are you familiar with the tolerance paradox? Aaron

Licensing Complications

A thing to seriously tackle is how the Gnu GPL permits making a modified version and letting the public access it on a server without ever releasing its source code. The focus must really be on ending any ownership on software. This problem necessitates the production of additional legal instrume

Mission Statement

> Sent: Thursday, June 10, 2021 at 9:07 AM > From: "Aaron Gyes via Gcc" > To: "GCC Administrator via Gcc" > Subject: Re: Mission Statement > > > In this state of making something right, and making > > something wrong, there is no way for inclusi

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

Sorry, should be sent to this mail-list. On 2021/6/10 11:31, Xionghu Luo via Gcc-patches wrote: Hi, I noticed that the "git gcc-commit-mklog" command doesn't extract PR number from title to ChangeLog automatically, then the committed patch doesn't update the related bugzi

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 2021/6/10 14:17, Martin Liška wrote: > On 6/10/21 7:22 AM, Xionghu Luo wrote: >> Sorry, should be sent to this mail-list. >> >> >> On 2021/6/10 11:31, Xionghu Luo via Gcc-patches wrote: >>> Hi, >>> I noticed that the "git gcc-commit-mklog&qu

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 2021/6/10 11:31, Xionghu Luo via Gcc-patches wrote: > Hi, > I noticed that the "git gcc-commit-mklog" command doesn't extract PR > number from title to ChangeLog automatically, then the committed patch > doesn't update the related bugzilla PR website after ch

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

> Quite interesting idea! Are you willing to prepare a patch for it? This works. diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py index bd8c1ff7af2..58aad8b7f26 100755 --- a/contrib/gcc-changelog/git_commit.py +++ b/contrib/gcc-changelog/git_commit

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py index bd8c1ff7af2..15b602595c4 100755 --- a/contrib/gcc-changelog/git_commit.py +++ b/contrib/gcc-changelog/git_commit.py @@ -157,6 +157,7 @@ author_line_regex = \ additional_author_regex = re.compile(r'^\t(

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote: > On 10/06/21 10:44 +0100, Jonathan Wakely wrote: > > > Quite interesting idea! Are you willing to prepare a patch for it? > > > > This works. > > And this works better, because it checks the

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote: > > On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote: > > On 10/06/21 10:44 +0100, Jonathan Wakely wrote: > > > > Quite interesting idea! Are you willing to prepare a patch for it? > > > &

Re: [Patch] contrig/gcc-changelog: Check that PR in subject in in changelog

* Tobias Burnus: > On 10.06.21 10:07, Martin Liška wrote: >> On 6/10/21 8:35 AM, Tobias Burnus wrote: >>> One options would be to require a 'PR /' line if there is >>> 'PRn+' in the commit title, rejecting the commit otherwise. >> >> Quite interesting idea! Are you willing to prepare a patch f

Re: [Patch] contrig/gcc-changelog: Check that PR in subject in in changelog

As well as the "contrig" typo that Florian noticed, the subject says "in in" which should be "is in". And it should be CC'd to gcc-patches. I like this more than my attempt, however ... >--- a/contrib/gcc-changelog/git_repository.py >+++ b/contrib/gcc-ch

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote: On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote: On 10/06/21 10:44 +0100, Jonathan Wakely wrote: Quite interesting idea! Are you willing to prepare a patch for it

[ranger-tech] How to use ranges within any pass with get_range_query()

As part of the ranger development we have found that there are various pieces of the infrastructure that can be used independently, and we’d like to document them in the hopes that they are useful to others. We will be contributing short posts documenting parts of the ranger, which we hope can

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote: > > On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote: > > On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote: > >> > >> On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote: > >>> On 1

Lack of latest binutils in gcc 11 docker image

HI team I am trying to use the gcc 11 docker hub image to build AMX code but it fails /usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h: Assembler messages: /usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h:42: Error: no such instruction: `ldtilecfg (%rdi)'

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, 10 Jun 2021 at 16:55, Tobias Burnus wrote: > Independent of the PR matching and checking issues, I think Jonathan was > thinking about extending the documentation (as I gathered from IRC > #gcc); Right. > I did not quite follow whether it is about best practice or > conta

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 9:56 AM, Jonathan Wakely wrote: On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote: On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote: On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote: On 10/06/21 10:44

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 11:06 AM, Martin Sebor wrote: On 6/10/21 9:56 AM, Jonathan Wakely wrote: On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote: On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote: On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 10, 2021 at 11:20:26AM -0600, Martin Sebor wrote: > One other note: you mention policy above, which suggests a requirement. > My understanding is that the format of a commit message is a convention > put in place to take some of the tedium out of creating ChangeLog > entries. If that's

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 11:30 AM, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 11:20:26AM -0600, Martin Sebor wrote: One other note: you mention policy above, which suggests a requirement. My understanding is that the format of a commit message is a convention put in place to take some of the tedium out of c

<    34   35   36   37   38   39   40   41   42   43   >