Re: Memory alignment for arrays in GCC for ARM

On 02/11/2024 00:55, Oren Zvi via Gcc wrote: > Hi, > > Was wondering about a curious thing that the compiler does. > For the code > > static void createX() > { > static char ; > static uint8_t y; > > printf("%c %c\r\n", y, ); > } > > I am getting the following lines in the m

Re: Automatic URLs in forgejo? (was Re: Sourceware forge experiment)

On 24/10/2024 16:29, David Malcolm wrote: > On Mon, 2024-10-21 at 03:22 +0200, Mark Wielaard wrote: >> As an experiment Sourceware is now running an forgejo v9 instance at >> https://forge.sourceware.org >> >> Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org >> address >> can register

Re: Is there a need to sometimes change gcc/config/t-* files when building a cross compiler?

On 27/09/2024 10:03, David Brown via Gcc wrote: > On 27/09/2024 10:13, Dennis Luehring via Gcc wrote: >> Am 27.09.2024 um 09:56 schrieb Jonathan Wakely: >>> On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote: >>> >>> > Am 27.09.2024 um 09:34 schrieb Jonathan Wakely: >>> > >>> > >>> > > They might

Re: On pull request workflows for the GNU toolchain

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: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On 05/07/2024 17:11, Jonathan Wakely via Gcc wrote: > On Fri, 5 Jul 2024 at 16:54, Alejandro Colomar via Gcc > wrote: >> At least, I hope there's consensus that while current GCC doesn't warn >> about this, ideally it should, which means it should warn for valid uses >> of strtol(3), which means

Re: [RFC] MAINTAINERS: require a BZ account field

On 25/06/2024 20:08, Arsen Arsenović via Gcc wrote: > Hi, > > Richard Biener writes: > >> [snip] >>> I was also proposing (and would like to re-air that here) enforcing >>> that the committer field of each commit is a (valid) @gcc.gnu.org >>> email. This can be configured repo-locally via: >>>

Re: [RFC] MAINTAINERS: require a BZ account field

On 27/06/2024 13:29, Sam James via Gcc wrote: > "Richard Earnshaw (lists)" writes: > >> On 24/06/2024 22:34, Sam James via Gcc wrote: >>> Hi! >>> >>> This comes up in #gcc on IRC every so often, so finally >>> writing an RFC. >>&g

Re: [RFC] MAINTAINERS: require a BZ account field

On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote: > Hi, > > Sam James via Gcc writes: > >> Hi! >> >> This comes up in #gcc on IRC every so often, so finally >> writing an RFC. >> >> What? >> --- >> >> I propose that MAINTAINERS be modified to be of the form, >> adding an extra field for their

Re: [RFC] MAINTAINERS: require a BZ account field

On 24/06/2024 22:34, Sam James via Gcc wrote: > Hi! > > This comes up in #gcc on IRC every so often, so finally > writing an RFC. > > What? > --- > > I propose that MAINTAINERS be modified to be of the form, > adding an extra field for their GCC/sourceware account: >a

Re: gcc git locked out for hours second day in a row

On 12/06/2024 14:23, Mikael Morin via Gcc wrote: > Le 12/06/2024 à 14:58, Jonathan Wakely a écrit : >> On Wed, 12 Jun 2024 at 13:57, Mikael Morin via Gcc wrote: >>> >>> Le 12/06/2024 à 13:48, Jakub Jelinek a écrit : Hi! Yesterday the gcc git repository was locked for 3 hours lo

Re: Updated Sourceware infrastructure plans

On 23/04/2024 09:56, Mark Wielaard wrote: > 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

Re: Updated Sourceware infrastructure plans

On 23/04/2024 04:24, 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

Re: Patches submission policy change

On 03/04/2024 14:23, Christophe Lyon via Gcc wrote: > On Wed, 3 Apr 2024 at 14:59, Joel Sherrill wrote: >> >> Another possible issue which may be better now than in years past >> is that the versions of autoconf/automake required often had to be >> installed by hand. I think newlib has gotten bett

Re: Help needed with maintainer-mode

On 06/03/2024 15:04, Andrew Carlotti via Gcc wrote: > On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote: >> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote: >>> >>> Hi Christophe, >>> >>> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote: I've not

Re: Help needed with maintainer-mode

On 04/03/2024 20:04, Jonathan Wakely wrote: > On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev > wrote: >> >> >> >> On 3/4/24 09:38, Richard Earnshaw (lists) wrote: >>> Tools like git (and svn before it) don't try to maintain time-stamps on >>

Re: Help needed with maintainer-mode

On 04/03/2024 16:42, Christophe Lyon wrote: > On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw > wrote: >> >> >> >> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote: >> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote: >> >> On Mon,

Re: Help needed with maintainer-mode

On 04/03/2024 14:46, Christophe Lyon via Gcc wrote: > On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote: >> >> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote: >>> >>> Hi! >>> >>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote: Hi! On 2024-03-04T00:30:05+,

Re: Help needed with maintainer-mode

On 29/02/2024 10:22, Christophe Lyon via Gcc wrote: > Hi! > > Sorry for cross-posting, but I'm not sure the rules/guidelines are the > same in gcc vs binutils/gdb. > > TL;DR: are there some guidelines about how to use/enable maintainer-mode? > > In the context of the Linaro CI, I've been looking

Re: Discussion about arm/aarch64 testcase failures seen with patch for PR111673

On 14/12/2023 07:17, Surya Kumari Jangala via Gcc wrote: > Hi Richard, > Thanks a lot for your response! > > Another failure reported by the Linaro CI is as follows: > > Running gcc:gcc.dg/dg.exp ... > FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue > "Performing shrink-wrapp

Re: Register allocation cost question

On 11/10/2023 09:58, Andrew Stubbs wrote: > On 11/10/2023 07:54, Chung-Lin Tang wrote: >> >> >> On 2023/10/10 11:11 PM, Andrew Stubbs wrote: >>> Hi all, >>> >>> I'm trying to add a new register set to the GCN port, but I've hit a >>> problem I don't understand. >>> >>> There are 256 new registers (

Re: Documenting common C/C++ options

On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote: > On 10/10/2023 10:47, Florian Weimer via Gcc wrote: >> Currently, -fsigned-char and -funsigned-char are only documented as C >> language options, although they work for C++ as well (and Objective-C >> and Objective

Re: Documenting common C/C++ options

On 10/10/2023 10:47, Florian Weimer via Gcc wrote: > Currently, -fsigned-char and -funsigned-char are only documented as C > language options, although they work for C++ as well (and Objective-C > and Objective-C++, I assume, but I have not tested this). There does > not seem to be a place for thi

Re: Cauldron schedule: diagnostics and security features talks

On 08/09/2023 19:18, Siddhesh Poyarekar wrote: > Hello, > > I want to begin by apologizing because I know from first hand experience that > scheduling can be an immensely painful job. > > The Cauldron 2023 schedule[1] looks packed and I noticed that Qing and > David's talks on security features

Re: Question on aarch64 prologue code.

On 06/09/2023 15:03, Iain Sandoe wrote: > Hi Richard, > >> On 6 Sep 2023, at 13:43, Richard Sandiford via Gcc wrote: >> >> Iain Sandoe writes: > >>> On the Darwin aarch64 port, we have a number of cleanup test fails (pretty >>> much corresponding to the [still open] >>> https://gcc.gnu.org/bu

Re: There Might a Bug in the Compiler: When Calling Weak Defined Function

On 07/08/2023 16:51, Şahin Duran via Gcc wrote: Dear GCC Developers, I think I've just discovered a bug/ undefined situation in the compiler. When I try to call a weakly defined function, compiler successfully generates the code of calling procedure. However, this calling procedure is nothing bu

Re: GNU Tools Cauldron 2023

We have now finalized the ticket price for this year's Cauldron at £75. Sarah is now contacting those who have already registered to arrange payment. If you have not yet registered then there is still time. Registration closes at 12 Noon BST (7am EDT) on Friday 1st September, and all tickets mu

Re: wishlist: support for shorter pointers

On 03/07/2023 17:42, Rafał Pietrak via Gcc wrote: Hi Ian, W dniu 3.07.2023 o 17:07, Ian Lance Taylor pisze: On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc wrote: [] I was thinking about that, and it doesn't look as requiring that deep rewrites. ABI spec, that  could accomodat

Re: gcc tricore porting

On 03/07/2023 15:34, Joel Sherrill wrote: On Mon, Jul 3, 2023, 4:33 AM Claudio Eterno wrote: Hi Joel, I'll give an answer ASAP on the newlib and libgloss... I supposed your question were about the licences question on newlib, instead you were really asking what changed on the repo libs... I

Re: wishlist: support for shorter pointers

On 28/06/2023 17:07, Martin Uecker wrote: Am Mittwoch, dem 28.06.2023 um 16:44 +0100 schrieb Richard Earnshaw (lists): On 28/06/2023 15:51, Rafał Pietrak via Gcc wrote: Hi Martin, W dniu 28.06.2023 o 15:00, Martin Uecker pisze: Sounds like named address spaces to me: https://gcc.gnu.org

Re: wishlist: support for shorter pointers

On 28/06/2023 15:51, Rafał Pietrak via Gcc wrote: Hi Martin, W dniu 28.06.2023 o 15:00, Martin Uecker pisze: Sounds like named address spaces to me: https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html Only to same extend, and only in x86 case. The goal of the wish-item I've describ

Re: Wrong cost computation / conclusion ins insn combine?

On 23/05/2023 19:41, Georg-Johann Lay wrote: For some time now I am staring at the following test case and what combine does with it: typedef struct {     unsigned b0 : 1;     unsigned b1 : 1;     unsigned b2 : 1;     unsigned b3 : 1;     unsigned b4 : 1;     unsigned b5 : 1;     unsigned

Re: More C type errors by default for GCC 14

On 12/05/2023 13:30, Jakub Jelinek via Gcc wrote: On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote: One fairly big GCC-internal task is to clear up the C test suite so that it passes with the new compiler defaults. I already have an offer of help for that, so I think we can complet

Re: More C type errors by default for GCC 14

On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote: From: Arsen Arsenović Cc: Eli Zaretskii , Jakub Jelinek , jwakely@gmail.com, gcc@gcc.gnu.org Date: Tue, 09 May 2023 22:21:03 +0200 The concern is using the good will of the GNU Toolchain brand as the tip of the spear or battering ram to m

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 02/03/2020 14:41, Jonathan Wakely wrote: On Mon, 2 Mar 2020 at 14:31, Nathan Sidwell wrote: On 3/2/20 8:01 AM, Richard Earnshaw (lists) wrote: On 27/02/2020 13:37, Nathan Sidwell wrote: On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote: On 22/01/2020 17:45, Richard Earnshaw (lists

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 27/02/2020 13:37, Nathan Sidwell wrote: On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote: On 22/01/2020 17:45, Richard Earnshaw (lists) wrote: [updated based on v2 discussions] This patch proposes some new (additional) rules for email subject lines when contributing to GCC.  The goal is

Re: Git ChangeLog policy for GCC Testsuite inquiry

On 07/02/2020 15:32, Segher Boessenkool wrote: On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote: On 07/02/2020 13:48, Segher Boessenkool wrote: Should we require some simple markup in the commit message before the changelogs? Maybe CL gcc/ * blablalba etc. CL

Re: Git ChangeLog policy for GCC Testsuite inquiry

On 07/02/2020 13:48, Segher Boessenkool wrote: Hi! On Fri, Feb 07, 2020 at 10:19:56AM +0100, Richard Biener wrote: On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool wrote: Yeah, don't look at me then :-) I *like* having most of those steps, most of this should only be done by people who are

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 17:48, Michael Matz wrote: Hi, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: The idea is that the [...] part is NOT part of the commit, only part of the email. I understand that, but the subject line of this thread says "e-mail subject lines", so I thoug

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 17:31, Michael Matz wrote: Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: Where does your '50 chars' limit come from? It's not in the glibc text, and it's not in the linux kernel text either. AFAICT this is your invention and you seem t

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 15:13, Richard Earnshaw (lists) wrote: On 03/02/2020 14:10, Jason Merrill wrote: On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: Upper case is what glibc has, though it appears that it's a rule that is

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 14:10, Jason Merrill wrote: On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: Upper case is what glibc has, though it appears that it's a rule that is not strictly followed. If we change it, then it becomes an

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 14:13, Jonathan Wakely wrote: On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote: Where does your '50 chars' limit come from? It's not in the glibc text, and it's not in the linux kernel text either. AFAICT this is your invention and you seem t

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 13:54, Segher Boessenkool wrote: On Mon, Feb 03, 2020 at 02:54:05PM +0300, Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: I've not seen any follow-up to this version. Should we go ahead and adopt this? Can we please go with 'committed&#

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 11:54, Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: I've not seen any follow-up to this version. Should we go ahead and adopt this? Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED? Spelling this with

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 17:45, Richard Earnshaw (lists) wrote: [updated based on v2 discussions] This patch proposes some new (additional) rules for email subject lines when contributing to GCC.  The goal is to make sure that, as far as possible, the subject for a patch will form a good summary when the

Re: Git ChangeLog policy for GCC Testsuite inquiry

On 25/01/2020 16:11, Jeff Law wrote: On Sat, 2020-01-25 at 10:50 -0500, Nathan Sidwell wrote: On 1/24/20 4:36 PM, Jeff Law wrote: On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote: I strongly prefer to move towards relying on the git log. In my experience the output of git log is a tota

Re: GCC Multi-Threading Ideas

On 24/01/2020 10:27, Jonathan Wakely wrote: On Fri, 24 Jan 2020 at 03:39, Nicholas Krause wrote: Sorry for the second message Allan but make -j does not scale well beyond 4 or 8 threads and that's considering a 4 core or 8 machine. The problem has to do with large build machines with CPUs with

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

On 24/01/2020 15:12, Jonathan Wakely wrote: On 24/01/20 15:09 +, Jonathan Wakely wrote: On 24/01/20 13:55 +, Richard Earnshaw (lists) wrote: On 24/01/2020 12:19, Jonathan Wakely wrote: On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

On 24/01/2020 12:19, Jonathan Wakely wrote: On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server.  It also c

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server.  It also covers some of the other features that those scripts enable, so that it's all in one place.  This is

Re: Wrong GCC PR2020 annotated for "[committed, libgomp,amdgcn] Fix plugin-gcn.c bug"

On 23/01/2020 15:28, Jakub Jelinek wrote: On Thu, Jan 23, 2020 at 04:23:01PM +0100, Thomas Schwinge wrote: Hi! On 2020-01-23T12:46:24+, Andrew Stubbs wrote: I've committed this patch to fix a bug in the OpenMP argument parsing.

[PATCH, v3] wwwdocs: e-mail subject lines for contributions

[updated based on v2 discussions] This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as possible, the subject for a patch will form a good summary when the message is committed to the repository if applied with

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 16:28, Marek Polacek wrote: On Wed, Jan 22, 2020 at 04:05:37PM +, Richard Sandiford wrote: "Richard Earnshaw (lists)" writes: On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrot

Add News-feed item for git transition

We're missing a statement on the main news feed about the git transition. diff --git a/htdocs/index.html b/htdocs/index.html index 41bcfe18..ef85cc97 100644 --- a/htdocs/index.html +++ b/htdocs/index.html @@ -54,6 +54,10 @@ mission statement. News +GCC source repository converted to git. +

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 19:26, Segher Boessenkool wrote: Hi! Thanks for doing this. On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 09:07, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 06:50:13PM +, Richard Earnshaw (lists) wrote: Doesn't this use of [] have the same problem with git am? No, because only 'leading' [] blocks are removed - git mailinfo --help I've used openmp: Teach o

[PATCH] wwwdocs: document scripts to access personal and vendor spaces

This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you

Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

On 21/01/2020 16:43, Nathan Sidwell wrote: On 1/21/20 11:38 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 16:14, Jonathan Wakely wrote: On Tue, 21 Jan 2020 at 16:03, Martin Liška wrote: Can you please remove the hook for user branches likes: $ git push origin me/filter-non-common

Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

On 21/01/2020 16:14, Jonathan Wakely wrote: On Tue, 21 Jan 2020 at 16:03, Martin Liška wrote: Can you please remove the hook for user branches likes: $ git push origin me/filter-non-common Enumerating objects: 27, done. Counting objects: 100% (27/27), done. Delta compression using up to 16 th

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want the PR number to be appended, shall it be something: whatever words describe it PR12345 or some

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:04, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: [updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes

[PATCH, v2] wwwdocs: e-mail subject lines for contributions

[updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as possible, the subject

Re: gcc-cvs mails for personal/vendor branches for merge commits

On 16/01/2020 14:11, Jakub Jelinek wrote: On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote: I think there's a similar issue not just for merges but for non-fast-forward pushes as well. As a glibc example, consider and the

Re: gcc-cvs mails for personal/vendor branches for merge commits

On 15/01/2020 16:30, Joseph Myers wrote: On Wed, 15 Jan 2020, Jason Merrill wrote: On 1/15/20 9:56 AM, Joseph Myers wrote: On Wed, 15 Jan 2020, Jakub Jelinek wrote: Or, if that is not possible, disable gcc-cvs mail for vendor and private branches altogether? I think this is desirable. gcc

Re: Proposal for the transition timetable for the move to GIT

as well. All that can be left is nit-picking, and that is not worth it anyway:" Jeff Law "When Richard and I spoke we generally agreed that we felt a reposurgeon conversion, if it could be made to work was the preferred solution, followed by Maxim's approach and lastly the existin

Re: Proposal for the transition timetable for the move to GIT

On 09/01/2020 02:38, Segher Boessenkool wrote: On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote: As noted on overseers, once Saturday's DATESTAMP update has run at 00:16 UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk and change the SVN hooks to make SVN read

Re: GIT conversion: question about tags & release branches

On 09/01/2020 11:57, Richard Earnshaw (lists) wrote: On 09/01/2020 11:45, Martin Jambor wrote: Hi, On Thu, Jan 09 2020, Martin Liška wrote: Hi. I have question about release branches and release tags. For the current git mirror, we do have release tags living on release branches. Example

Re: GIT conversion: question about tags & release branches

On 09/01/2020 11:45, Martin Jambor wrote: Hi, On Thu, Jan 09 2020, Martin Liška wrote: Hi. I have question about release branches and release tags. For the current git mirror, we do have release tags living on release branches. Example: commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66 Author:

Re: GIT conversion: question about tags & release branches

On 09/01/2020 09:44, Martin Liška wrote: Hi. I have question about release branches and release tags. For the current git mirror, we do have release tags living on release branches. Example: commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66 Author: jakub Date:   Mon Aug 12 08:40:24 2019 +

Re: [ARM] LLVM's -arm-assume-misaligned-load-store equivalent in GCC?

On 07/01/2020 15:57, Christophe Lyon wrote: Hi, I've received a support request where GCC generates strd/ldrd which require aligned memory addresses, while the user code actually provides sub-aligned pointers. The sample code is derived from CMSIS: #define __SIMD32_TYPE int #define __SIMD32(add

Re: Test GCC conversion with reposurgeon available

On 06/01/2020 22:09, Loren James Rittle wrote: On Fri, 3 Jan 2020, Joseph Myers wrote: git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7a.git git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7b.git I have not had a substantial commit to gcc [or, likely, post to this list] in a decade T

Re: Proposal for the transition timetable for the move to GIT

On 02/01/2020 02:58, Alexandre Oliva wrote: > On Dec 30, 2019, "Richard Earnshaw (lists)" wrote: > >> Right, (and wrong). You have to understand how the release branches and >> tags are represented in CVS to understand why the SVN conversion is done >> this

Re: Proposal for the transition timetable for the move to GIT

On 31/12/2019 13:42, Joseph Myers wrote: > On Mon, 16 Dec 2019, Jeff Law wrote: > >>> Joseph Myers has made his choice. He has said repeatedly that he >>> wants to follow through with the reposurgeon conversion, and he's >>> putting his effort behind that by writing tests and even contributing >>

Re: Proposal for the transition timetable for the move to GIT

On 30/12/2019 15:49, Maxim Kuvyrkov wrote: >> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists) >> wrote: >> >> On 30/12/2019 13:00, Maxim Kuvyrkov wrote: >>>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists) >>>> wrote: >>>>

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 22:56, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> Weak in the sense that it isn't proof given that the user name is >> partially redacted. There's nothing in the gcc archives that gives a >> full name either, unfortunately. >> &g

Re: Proposal for the transition timetable for the move to GIT

On 29/12/2019 23:13, Segher Boessenkool wrote: > On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote: >> fixups in bugdb.py - and that way benefit both from reposurgeon making >> choices that are as conservatively safe as possible, which seems a >> desirable property for problem cases th

Re: Proposal for the transition timetable for the move to GIT

On 30/12/2019 13:00, Maxim Kuvyrkov wrote: >> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists) >> wrote: >> >> On 29/12/2019 18:30, Maxim Kuvyrkov wrote: >>> Below are several more issues I found in reposurgeon-6a conversion >>> comparing it aga

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 22:24, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> Also, for this one: >> >> # "47044": "", >> >> There's some (relatively weak) evidence that this is Bjørn Wennberg (eg >> https://groups.google.com/forum/

Re: Proposal for the transition timetable for the move to GIT

On 29/12/2019 18:30, Maxim Kuvyrkov wrote: > Below are several more issues I found in reposurgeon-6a conversion comparing > it against gcc-reparent conversion. > > I am sure, these and whatever other problems I may find in the reposurgeon > conversion can be fixed in time. However, I don't see

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 12:32, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> I've just commented that one out for now; if anybody knows the correct >> addresses, please let me know.  Also, there's one joint list that I've >> not attempted to fix at this time.

Re: Git conversion: fixing email addresses from ChangeLog files

On 27/12/2019 19:47, Richard Earnshaw (lists) wrote: > Email addresses from the ChangeLog files are not validated during > commits, so a number of typos exist in the extracted data. I've > extracted the 'Author:' entry from a prototype conversion and then piped > th

Re: Git conversion: fixing email addresses from ChangeLog files

On 28/12/2019 20:11, Segher Boessenkool wrote: > On Sat, Dec 28, 2019 at 04:34:20PM +0000, Richard Earnshaw (lists) wrote: >> On 28/12/2019 14:54, Segher Boessenkool wrote: >>> On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote: >>>> On Sat, 28 Dec

Re: Git conversion: fixing email addresses from ChangeLog files

On 28/12/2019 17:14, Joseph Myers wrote: > On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote: > >> My suggestion would be that we try to canonicalize all the author >> entries to UTF-8 as that avoids the limitations of ISO-8859-1, but that >> would probably need furt

Re: Proposal for the transition timetable for the move to GIT

On 28/12/2019 12:19, Segher Boessenkool wrote: > Branch merges do not mesh well with our commit policies, fwiw: > everything should normally be posted for public review on the mailing > lists. This does not really work for commits that have been set in > stone months before. > I disagree. The r

Re: Git conversion: fixing email addresses from ChangeLog files

On 28/12/2019 12:04, Jakub Jelinek wrote: > On Fri, Dec 27, 2019 at 07:47:02PM +0000, Richard Earnshaw (lists) wrote: >> Email addresses from the ChangeLog files are not validated during >> commits, so a number of typos exist in the extracted data. I've >> extracted

Re: Git conversion: fixing email addresses from ChangeLog files

On 28/12/2019 14:54, Segher Boessenkool wrote: > On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote: >> On Sat, 28 Dec 2019, Segher Boessenkool wrote: >> >>> On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote: >>>> 1 Autho

Git conversion: fixing email addresses from ChangeLog files

Email addresses from the ChangeLog files are not validated during commits, so a number of typos exist in the extracted data. I've extracted the 'Author:' entry from a prototype conversion and then piped that through sort and uniq -c. Subsequent analysis shows the following addresses/names that ar

Re: Proposal for the transition timetable for the move to GIT

On 27/12/2019 11:35, Joseph Myers wrote: > On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote: > >> I'm not really sure I understand why we don't want merge commits into >> trunk, especially for large changes. Performing archaeology on a change >> is just

Re: Proposal for the transition timetable for the move to GIT

On 26/12/2019 18:59, Joseph Myers wrote: > On Thu, 26 Dec 2019, Jakub Jelinek wrote: > >> On Thu, Dec 26, 2019 at 04:58:22PM +, Joseph Myers wrote: >>> If we don't want merge commits on git master for the cases where people >>> put merge properties on trunk in the past, we can use a reposurge

Re: Commit messages and the move to git

On 19/12/2019 16:00, Joseph Myers wrote: On Thu, 19 Dec 2019, Jonathan Wakely wrote: It might be reasonable to assume rtl-optimization and tree-optimization are aliases, and not treat it as suspicious if those two appear mixed up. And anything where bugzilla has component debug or lto and the c

Re: Test GCC conversions (publicly) available

On 19/12/2019 16:00, Eric S. Raymond wrote: Joseph Myers : On Thu, 19 Dec 2019, Eric S. Raymond wrote: There are other problems that might cause a delay beyond the 31st, however. Best if I let Joseph nd Richard explain those. I presume that's referring to the checkme: bug annotations where t

Re: Commit messages and the move to git

On 19/12/2019 15:44, Jonathan Wakely wrote: These scraped "INVALID" as the component from the changelog, because it said "libgfortran/24685": revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142840]) reve

Re: Commit messages and the move to git

On 19/12/2019 15:17, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 14:29, Joseph Myers wrote: On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote: Best of all would be a pull request on https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly. Note if doing that, it

Re: Commit messages and the move to git

On 19/12/2019 11:16, Jakub Jelinek wrote: On Thu, Dec 19, 2019 at 12:01:28AM +, Joseph Myers wrote: re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277822]) re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tr

Re: Commit messages and the move to git

On 19/12/2019 12:35, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists) wrote: On 19/12/2019 12:23, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists) wrote: On 19/12/2019 09:27, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 00:02

Re: Commit messages and the move to git

On 19/12/2019 12:23, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists) wrote: On 19/12/2019 09:27, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote: On Wed, 18 Dec 2019, Joseph Myers wrote: On Mon, 18 Nov 2019, Richard Earnshaw (lists

Re: Commit messages and the move to git

On 19/12/2019 11:50, Richard Earnshaw (lists) wrote: On 19/12/2019 09:27, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote: On Wed, 18 Dec 2019, Joseph Myers wrote: On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: I've attached a sample from the start o

Re: Commit messages and the move to git

On 19/12/2019 09:27, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote: On Wed, 18 Dec 2019, Joseph Myers wrote: On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: I've attached a sample from the start of the fixed list - the full list is far too big to po

  1   2   >