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&#
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
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
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
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
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
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
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
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
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
On 19/01/16 14:42, Jeff Law wrote:
> On 01/19/2016 04:59 AM, Woon yung Liu wrote:
>>
>> In my current attempt at adding support for the TI mode, the MMI
>> definitions are added into a MD file for the R5900 and some functions
>> (i.e. mips_output_move) were modified to allow certain moves for the
>
On 09/02/16 14:56, Ilya Enkovich wrote:
> 2016-02-09 17:27 GMT+03:00 Bin.Cheng :
>> On Fri, Feb 5, 2016 at 10:32 AM, Ilya Enkovich
>> wrote:
>>> 2016-02-04 19:16 GMT+03:00 Bin.Cheng :
On Thu, Feb 4, 2016 at 3:18 PM, Ilya Enkovich
wrote:
> 2016-02-04 17:12 GMT+03:00 Bin.Cheng :
>>>
After discussion with the ARM port maintainers we have decided that now
is probably the right time to deprecate support for versions of the ARM
Architecture prior to ARMv4t. This will allow us to clean up some of
the code base going forwards by being able to assume:
- Presence of half-word data ac
On 24/02/16 17:38, Joseph Myers wrote:
> On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
>
>> After discussion with the ARM port maintainers we have decided that now
>> is probably the right time to deprecate support for versions of the ARM
>> Architecture prior to
On 25/02/16 13:32, Stefan Ring wrote:
> On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists)
> wrote:
>> The point is to permit the compiler to use interworking compatible
>> sequences of code when generating ARM code, not to force users to use
>> Thumb code. The n
On 25/02/16 14:15, David Brown wrote:
> On 25/02/16 14:32, Stefan Ring wrote:
>> On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists)
>> wrote:
>>> The point is to permit the compiler to use interworking compatible
>>> sequences of code when generating AR
On 24/02/16 13:59, Richard Earnshaw (lists) wrote:
> After discussion with the ARM port maintainers we have decided that now
> is probably the right time to deprecate support for versions of the ARM
> Architecture prior to ARMv4t. This will allow us to clean up some of
> the cod
On 29/07/16 20:01, Warren D Smith wrote:
> Similarly, when some twerp complained
Using terminology like this isn't acceptable on these lists. If that's
the way you want to treat people who disagree with you, please go elsewhere.
R.
On 29/08/16 08:52, Fredrik Hederstierna wrote:
>
>>> Couldn't this be compiled to as the following, with using r12 'ip':
>>>
>>> :
>>> 0: push {r4, lr}
>>> 4: mov r4, r0
>>> 8: ldr ip, [r0]
>>> c: bl 0
>>> 10: str ip, [r4]
>>> 14: pop
On 22/09/16 16:20, paul.kon...@dell.com wrote:
>
>> On Sep 22, 2016, at 11:16 AM, David Brown wrote:
>>
>> On 22/09/16 16:57, paul.kon...@dell.com wrote:
>>>
On Sep 22, 2016, at 6:17 AM, David Brown wrote:
...
Your trouble is that your two pointers, cur and end, are pointing
On 24/08/18 14:51, Akhilesh chirlancha wrote:
> Hello All,
>
> I'm using gcc 5.4.0 for armhf target.
>
> I was compiling simple stack over flow test code with '-mapcs-stack-check'
> option.
> # gcc -mapcs-stack-check test.c
> test.c:1:0: warning: -mapcs-stack-check incompatible with -mno-apcs-fra
This is the wrong place to report bugs. Please use bugzilla:
https://gcc.gnu.org/bugzilla/
You also need to include a *complete* description of the bug and provide
code that can be used to reproduce it. Your minimal description below
is completely inadequate.
R.
On 01/10/18 02:27, Jason A. Do
On 26/10/2018 00:46, Paul Koning wrote:
> In my target (pdp11) which has 16 bit words, I see some test suite failures
> because of unresolved references to __cmpsi2. The strange thing is that most
> of the time 32 bit compares are expanded by GCC into a sequence of word
> compares and branches.
On 18/12/2018 15:36, Richard Biener wrote:
>
> Hi,
>
> in the past weeks I've been looking into prototyping both spectre V1
> (speculative array bound bypass) diagnostics and mitigation in an
> architecture independent manner to assess feasability and some kind
> of upper bound on the performanc
On 19/12/2018 11:25, Richard Biener wrote:
> On Tue, 18 Dec 2018, Richard Earnshaw (lists) wrote:
>
>> On 18/12/2018 15:36, Richard Biener wrote:
>>>
>>> Hi,
>>>
>>> in the past weeks I've been looking into prototyping both spectre V1
On 19/12/2018 17:17, Richard Biener wrote:
> On Wed, 19 Dec 2018, Florian Weimer wrote:
>
>> * Peter Bergner:
>>
>>> On 12/19/18 7:59 AM, Florian Weimer wrote:
* Richard Biener:
> Sure, if we'd ever deploy this in production placing this in the
> TCB for glibc targets might be be
On 10/04/2019 10:16, Christophe Lyon wrote:
> On Wed, 10 Apr 2019 at 00:30, Richard Earnshaw
> wrote:
>>
>> On 09/04/2019 13:26, Christophe Lyon wrote:
>>> Hi,
>>>
>>> While building a newlib-based arm-eabi toolchain with
>>> --with-multilib
On 21/05/2019 21:18, Bill Schmidt wrote:
> On 5/21/19 11:47 AM, Martin Sebor wrote:
>> The GCC coding style says to use "floating-point" as an adjective
>> rather than "floating point." After enhancing the -Wformat-diag
>> checker to detect this I found a bunch of uses of the latter, such
>> as in
On 22/05/2019 13:17, Bill Schmidt wrote:
> On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote:
>> On 21/05/2019 21:18, Bill Schmidt wrote:
>>> On 5/21/19 11:47 AM, Martin Sebor wrote:
>>>> The GCC coding style says to use "floating-point" as an adjective
&
On 22/05/2019 13:17, Bill Schmidt wrote:
> "We should use floating point."
In fact, since we're compiler folk, we just say it's undefined behaviour
and optimize it to
"."
:-P
R.
On 06/06/2019 00:46, Segher Boessenkool wrote:
> On Wed, Jun 05, 2019 at 05:02:53PM -0600, Jeff Law wrote:
>> On 6/2/19 6:28 AM, Segher Boessenkool wrote:
>>> On Sat, Jun 01, 2019 at 11:41:30PM +, Fredrik Hederstierna wrote:
+(define_peephole2
+ [(set (match_operand:SI 0 "arm_general
On 06/06/2019 15:55, Fredrik Hederstierna wrote:
>> From: Segher Boessenkool
>> Sent: Thursday, June 6, 2019 4:02 PM
>> To: Richard Earnshaw (lists)
>> Cc: Jeff Law; Fredrik Hederstierna; gcc@gcc.gnu.org
>> Subject: Re: ARM peephole2 from 2003 never merged, still v
On 19/08/2019 14:57, Paul Koning wrote:
On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote:
All,
this is my first post on these lists, so please bear with me.
My question is about gcc's __attribute__((aligned()). Please consider the
following code:
#include
typedef uint32_t uuint32_t _
At the Cauldron this weekend the overwhelming view for the move to GIT
soon was finally expressed.
But we never discussed when and we didn't really decide which conversion
we would use from the three that we currently have on the table.
So during the cauldron dinner I discussed with several p
On 17/09/2019 13:24, Richard Biener wrote:
On Tue, Sep 17, 2019 at 2:02 PM Richard Earnshaw (lists)
wrote:
At the Cauldron this weekend the overwhelming view for the move to GIT
soon was finally expressed.
But we never discussed when and we didn't really decide which conversion
we woul
On 17/09/2019 17:35, Joseph Myers wrote:
> On Tue, 17 Sep 2019, Richard Biener wrote:
>
>> If stage3 ends on Dec 31st then stage1 ends Oct 31st to have a two-month
>> stage3. That's about two weeks earlier than in the past.
>
> I don't think the repository conversion should constrain the timing
On 19/09/2019 13:04, Janne Blomqvist wrote:
On Tue, Sep 17, 2019 at 3:02 PM Richard Earnshaw (lists)
wrote:
There should be NO CHANGE to the other processes and policies that we
have, eg patch reviews, ChangeLog policies etc at this time. Adding
requirements for this will just slow down the
On 01/10/2019 20:43, Jeff Law wrote:
On 9/20/19 7:18 PM, co...@sdf.org wrote:
On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote:
Introducing the reversed jbb* patterns doesn't seem to help with the
original issue. It crashes building libatomic.
My loose understanding of what is go
On 19/09/2019 18:04, Paul Koning wrote:
On Sep 17, 2019, at 8:02 AM, Richard Earnshaw (lists)
wrote:
...
So in summary my proposed timetable would be:
Monday 16th December 2019 - cut off date for picking which git conversion to use
Tuesday 31st December 2019 - SVN repo becomes read-only
On 19/09/2019 15:42, Damian Rouson wrote:
On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist
wrote:
One thing that's unclear to me is how should I actually make my stuff
appear in the public repo? Say I want to work on some particular
thing:
This is essentially a git workflow question. A sim
With the move to git fairly imminent now it would be nice if we could
agree on a more git-friendly style of commit messages; and, ideally,
start using them now so that the converted repository can benefit from this.
Some tools, particularly gitk or git log --oneline, can use one-line
summaries
On 04/11/2019 16:04, Jeff Law wrote:
On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote:
With the move to git fairly imminent now it would be nice if we could
agree on a more git-friendly style of commit messages; and, ideally,
start using them now so that the converted repository can benefit
On 04/11/2019 16:19, Jonathan Wakely wrote:
On Mon, 4 Nov 2019 at 10:29, Richard Earnshaw (lists)
wrote:
With the move to git fairly imminent now it would be nice if we could
agree on a more git-friendly style of commit messages; and, ideally,
start using them now so that the converted
On 05/11/2019 14:12, Marek Polacek wrote:
> On Tue, Nov 05, 2019 at 11:27:50AM +, Jason Merrill wrote:
>> On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely
>> wrote:
>>> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
On Mon, 4 Nov 2019, Segher Boessenkool wrote:
> On Mon, Nov 04
On 05/11/2019 02:51, Kewen.Lin wrote:
> Hi,
>
> on 2019/11/4 下午6:29, Richard Earnshaw (lists) wrote:
>> With the move to git fairly imminent now it would be nice if we could agree
>> on a more git-friendly style of commit messages; and, ideally, start using
>> the
On 07/11/2019 14:27, Eric S. Raymond wrote:
Jeff Law :
On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote:
With the move to git fairly imminent now it would be nice if we could
agree on a more git-friendly style of commit messages; and, ideally,
start using them now so that the converted
On 09/11/2019 06:01, Eric S. Raymond wrote:
Richard Earnshaw (lists) :
Which makes me wonder if, given a commit log of the form:
2019-10-30 Richard Biener
PR tree-optimization/92275
* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
Copy all loop
On 18/11/2019 15:55, Segher Boessenkool wrote:
Hi!
On Mon, Nov 18, 2019 at 03:32:06PM +, Richard Earnshaw (lists) wrote:
I wrote this script for two reasons
1) To learn some python (finally I had a good reason to go and do
this :)
So I am last now? Heh.
2) To try to improve
On 18/11/2019 17:11, Segher Boessenkool wrote:
Hi Richard,
On Mon, Nov 18, 2019 at 04:48:03PM +, Richard Earnshaw (lists) wrote:
On 18/11/2019 15:55, Segher Boessenkool wrote:
That immediately shows some of the shortcomings of this approach: the
subject line is much too long, but more
On 18/11/2019 17:25, Nicholas Krause wrote:
On 11/18/19 12:23 PM, Nicholas Krause wrote:
On 11/18/19 12:20 PM, Nicholas Krause wrote:
On 11/18/19 12:11 PM, Segher Boessenkool wrote:
Hi Richard,
On Mon, Nov 18, 2019 at 04:48:03PM +, Richard Earnshaw (lists)
wrote:
On 18/11/2019 15:55
On 18/11/2019 17:46, Richard Earnshaw (lists) wrote:
On 18/11/2019 17:25, Nicholas Krause wrote:
On 11/18/19 12:23 PM, Nicholas Krause wrote:
On 11/18/19 12:20 PM, Nicholas Krause wrote:
On 11/18/19 12:11 PM, Segher Boessenkool wrote:
Hi Richard,
On Mon, Nov 18, 2019 at 04:48:03PM +
On 18/11/2019 17:55, Nicholas Krause wrote:
On 11/18/19 12:46 PM, Richard Earnshaw (lists) wrote:
On 18/11/2019 17:25, Nicholas Krause wrote:
On 11/18/19 12:23 PM, Nicholas Krause wrote:
On 11/18/19 12:20 PM, Nicholas Krause wrote:
On 11/18/19 12:11 PM, Segher Boessenkool wrote:
Hi
On 18/11/2019 18:53, Segher Boessenkool wrote:
> On Mon, Nov 18, 2019 at 05:38:14PM +0000, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 17:11, Segher Boessenkool wrote:
>>> I think that non-obviously-wrong-but-still-wrong info is not something
>>> we should introdu
On 18/11/2019 18:53, Segher Boessenkool wrote:
> On Mon, Nov 18, 2019 at 05:38:14PM +0000, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 17:11, Segher Boessenkool wrote:
>>> I think that non-obviously-wrong-but-still-wrong info is not something
>>> we should introdu
On 18/11/2019 20:53, Jason Merrill wrote:
> On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
> seg...@kernel.crashing.org> wrote:
>
>> On Mon, Nov 18, 2019 at 07:21:22PM +0000, Richard Earnshaw (lists) wrote:
>>> On 18/11/2019 18:53, Segher Boessenkool wrote:
On 19/11/2019 11:24, Eric S. Raymond wrote:
Richard Earnshaw (lists) :
Well a lot of that is a property of the conversion tool. git svn does a
relatively poor job of anything other than straight history (I believe it
just ignores the non-linear information.
Yes, svn-git does a *terrible* job
On 19/11/2019 16:31, Segher Boessenkool wrote:
On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
Yep. I don't think we need to worry about getting optimal one-line
summaries for ancient commits; something reasonably unique should be plenty.
In that case, how about just "SVN rN
On 19/11/2019 11:45, Richard Earnshaw (lists) wrote:
> On 19/11/2019 11:24, Eric S. Raymond wrote:
>> Richard Earnshaw (lists) :
>>> Well a lot of that is a property of the conversion tool. git svn does a
>>> relatively poor job of anything other than straight history
On 19/11/2019 19:32, Eric S. Raymond wrote:
> Richard Earnshaw (lists) :
>> I was looking at the reposurgeon code last night, and I think I can see what
>> the problem *might* be, but I haven't had time to produce a testcase.
>>
>> Some of our commits have merg
On 19/11/2019 19:47, Richard Earnshaw (lists) wrote:
> On 19/11/2019 19:32, Eric S. Raymond wrote:
>> Richard Earnshaw (lists) :
>>> I was looking at the reposurgeon code last night, and I think I can see what
>>> the problem *might* be, but I haven't had time to
On 19/11/2019 22:14, Eric S. Raymond wrote:
> Richard Earnshaw (lists) :
>> Nope, that was from running the go version from yesterday. This one, to
>> be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>>
>> This pass used to be very fast a couple of weeks bac
27;ve very much enjoyed seeing the many contributions to
the AArch64 port over the past two years.
Kyrill Tkachov, Richard Earnshaw, Richard Sandiford and Marcus Shawcroft
make for a great team of maintainers - I fully expect the AArch64 to
continue to thrive under their watch.
Best Regards,
James
On 20/11/2019 11:27, Segher Boessenkool wrote:
On Wed, Nov 20, 2019 at 08:58:05AM +, Jonathan Wakely wrote:
Most of the time after I type "git log" I type "/\<123456\>". We need
to keep a way to easily map SVN revision ids to git commits, and
As a aside, I use these aliases often with the
On 19/11/2019 23:44, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Segher Boessenkool wrote:
>
>> Most of the time after I type "git log" I type "/\<123456\>". We need
>> to keep a way to easily map SVN revision ids to git commits, and
>> something a bit more elegant than the ugly git-svn footers wo
On 21/11/2019 16:40, Joseph Myers wrote:
On Tue, 19 Nov 2019, Eric S. Raymond wrote:
Richard Earnshaw (lists) :
Nope, that was from running the go version from yesterday. This one, to
be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
This pass used to be very fast a couple of weeks back
On 21/11/2019 16:40, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Eric S. Raymond wrote:
>
>> Richard Earnshaw (lists) :
>> > Nope, that was from running the go version from yesterday. This one, to
>> > be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>> &g
On 29/11/2019 16:14, Joseph Myers wrote:
# Tags for vendor releases.
tag/ARM/ delete
tag/apple/gcc/ delete
tag/csl/ delete
tag /linaro-/ delete
tag /microblaze-/ delete
tag/st/GCC/ delete
tag /ubuntu/gcc-/ delete
tag egcs_1_0_x_redhat5_1 delete
tag gcc-1766 delete
tag gcc-3_2-rhl8-3_2-7 delet
On 19/11/2019 14:56, Jason Merrill wrote:
On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) <
richard.earns...@arm.com> wrote:
On 18/11/2019 20:53, Jason Merrill wrote:
On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
On Mon, Nov 18
On 02/12/2019 15:35, Segher Boessenkool wrote:
> Hi,
>
> On Mon, Dec 02, 2019 at 10:54:17AM +, Richard Earnshaw (lists) wrote:
>> - author attributions are sometimes incorrect - reported
>
> This would disqualify that "conversion", for me at least. Keepi
On 02/12/2019 17:25, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 04:18:59PM +0000, Richard Earnshaw (lists) wrote:
>> On 02/12/2019 15:35, Segher Boessenkool wrote:
>>> On Mon, Dec 02, 2019 at 10:54:17AM +, Richard Earnshaw (lists) wrote:
>>>> - aut
On 02/12/2019 18:00, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 05:47:08PM +0000, Richard Earnshaw (lists) wrote:
>> On 02/12/2019 17:25, Segher Boessenkool wrote:
>>> On Mon, Dec 02, 2019 at 04:18:59PM +, Richard Earnshaw (lists) wrote:
>>>> On 02/12/
On 03/12/2019 00:56, Segher Boessenkool wrote:
On Mon, Dec 02, 2019 at 08:37:14PM +, Joseph Myers wrote:
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
Thanks for the list. As far as I can see all of those are no longer
useful, so they could be jut deleted from the SVN repo (if everyone
els
On 03/12/2019 00:47, Segher Boessenkool wrote:
On Mon, Dec 02, 2019 at 08:24:47PM +, Joseph Myers wrote:
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
Sure; I'm just saying rewriting old commit messages in such a style that
they keep standing out from new ones is a bit of a weird choice.
On 03/12/2019 09:44, Richard Earnshaw (lists) wrote:
On 03/12/2019 00:47, Segher Boessenkool wrote:
On Mon, Dec 02, 2019 at 08:24:47PM +, Joseph Myers wrote:
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
Sure; I'm just saying rewriting old commit messages in such a style
that
they
On 03/12/2019 15:05, Joseph Myers wrote:
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
a) Only live development branches get moved to the normal git namespace, but
see d) & e) below
Where do you suggest dead development branches should go? (We have
/branches/dead at present in SVN
On 03/12/2019 13:26, Joseph Myers wrote:
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
On Fri, Nov 29, 2019 at 10:31:22PM +, Joseph Myers wrote:
On Fri, 29 Nov 2019, Segher Boessenkool wrote:
Please post the full names of all the tags you want to delete?
Here is a list of 645 tags propo
On 03/12/2019 18:56, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
>> On 03/12/2019 00:56, Segher Boessenkool wrote:
>>> That sounds simpler than it is... After using this for a while you'll
>>> get names t
On 03/12/2019 22:43, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 08:10:37PM +, Richard Earnshaw (lists) wrote:
On 03/12/2019 18:56, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
But we could make an "old-svn" hierarchy
On 02/12/2019 10:54, Richard Earnshaw (lists) wrote:
> On 19/11/2019 14:56, Jason Merrill wrote:
>> On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) <
>> richard.earns...@arm.com> wrote:
>>
>>> On 18/11/2019 20:53, Jason Merrill wrote:
>>
On 05/12/2019 08:55, Maxim Kuvyrkov wrote:
On Dec 3, 2019, at 11:10 PM, Richard Earnshaw (lists)
wrote:
On 03/12/2019 18:56, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
On 03/12/2019 00:56, Segher Boessenkool wrote:
That sounds
On 05/12/2019 10:32, Jonathan Wakely wrote:
On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely wrote:
On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
I've just pushed a new trial conversion:
https://gitlab.com/rearnsha/gcc-trial2-20191130
The main differences between this an
On 11/12/2019 14:40, Maxim Kuvyrkov wrote:
>> On Dec 9, 2019, at 9:19 PM, Joseph Myers wrote:
>>
>> On Fri, 6 Dec 2019, Eric S. Raymond wrote:
>>
>>> Reposurgeon has been used for several major conversions, including groff
>>> and Emacs. I don't mean to be nasty to Maxim, but I have not yet seen
On 11/12/2019 15:19, Jonathan Wakely wrote:
> On Wed, 11 Dec 2019 at 15:03, Richard Earnshaw (lists) wrote:
>> I wouldn't bother with that. There are known defects in the version of
>> reposurgeon that I used to produce that which have since been fixed. It
>> was *never
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
301 - 400 of 503 matches
Mail list logo
