On 28/06/2023 10:26, Christophe Lyon via Gcc-patches wrote:
If GCC is configured with the default (soft) -mfloat-abi, and we don't
override the target_board test flags appropriately,
gcc.target/arm/mve/general-c/nomve_fp_1.c fails for lack of
-mfloat-abi=softfp or -mfloat-abi=hard, because it
On 01/06/2023 05:26, YunQiang Su wrote:
speculation_barrier for MIPS needs sync+jr.hb (r2+),
so we implement __speculation_barrier in libgcc, like arm32 does.
gcc/ChangeLog:
* config/mips/mips-protos.h (mips_emit_speculation_barrier): New
prototype.
*
On 08/06/2023 11:00, Tamar Christina via Gcc-patches wrote:
Hi All,
This converts some patterns in the AArch64 backend to use the new
compact syntax.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64.md (arches):
On 08/06/2023 11:29, Richard Earnshaw (lists) via Gcc-patches wrote:
On 08/06/2023 11:12, Andreas Schwab wrote:
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
@@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
multi-alternative template:
@end group
@end smallexample
On 08/06/2023 11:12, Andreas Schwab wrote:
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
@@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
multi-alternative template:
@end group
@end smallexample
+@node Compact Syntax
+@section Compact Syntax
+@cindex compact
On 06/06/2023 13:49, Richard Sandiford via Gcc-patches wrote:
Tamar Christina writes:
int operand_number; /* Operand index in the big array. */
int output_format; /* INSN_OUTPUT_FORMAT_*. */
+ bool compact_syntax_p;
struct operand_data operand[MAX_MAX_OPERANDS];
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;
On 24/04/2023 09:33, Richard Sandiford via Gcc-patches wrote:
Richard Sandiford writes:
Tamar Christina writes:
Hi All,
This patch adds support for a compact syntax for specifying constraints in
instruction patterns. Credit for the idea goes to Richard Earnshaw.
I am sending up this RFC to
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
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
On 13/01/2023 22:12, Jakub Jelinek wrote:
On Fri, Jan 13, 2023 at 09:58:26PM +, Richard Earnshaw (lists) wrote:
> I'm afraid increasing number of DWARF registers is ABI incompatible change.
> E.g. libgcc __frame_state_for function fills in:
> typedef struct frame_state
> {
&g
On 13/01/2023 18:02, Jakub Jelinek via Gcc-patches wrote:
On Fri, Jan 13, 2023 at 05:44:15PM +, Srinath Parvathaneni via Gcc-patches
wrote:
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
updates the ".save", ".cfi_register",
Fix a signed vs unsigned comparison in last change.
gcc:
* common/config/arm/arm-common.c (arm_config_default): Change type
of 'i' to unsigned.
---
gcc/common/config/arm/arm-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 03/03/2021 14:11, Christophe Lyon via Gcc-patches wrote:
> On Wed, 3 Mar 2021 at 14:55, Richard Earnshaw (lists)
> wrote:
>>
>> Hopefully this change will reduce the number of times Christophe is
>> needing to tweak the testsuite.
>>
>
> Thanks!
>
Hopefully this change will reduce the number of times Christophe is
needing to tweak the testsuite.
--
Arm processors can support up to two instruction sets. Some early
cores only support the traditional A32 (Arm) instructions, while some
more recent devices only support T32 (Thumb)
Commit r10-6017 relaxed the constraint on thumb2 calls to
__gnu_cmse_nonsecure_call to allow any register for the call address.
Although the initial code expansion continues to use r4 with the FPCXT
extension is not enabled, the change was unsafe because subsequent
optimizations could use the
On 10/02/2021 17:44, Andrea Corallo via Gcc-patches wrote:
> Andrea Corallo via Gcc-patches writes:
>
>> "Richard Earnshaw (lists)" writes:
>>
>>> On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
>>>> Jakub Jelinek writes:
>>&
On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
> Jakub Jelinek writes:
>
>> On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches
>> wrote:
"TARGET_32BIT && TARGET_HAVE_LOB"
- "le\t%|lr, %l0")
+ "*
+ if (get_attr_length (insn) == 4)
+
On 26/11/2020 13:53, Andrea Corallo via Gcc-patches wrote:
> Hi all,
>
> I'd like to submit the following simple patch to clean some Low Loop
> Overhead test failing on hard float configurations.
>
> lob2.c and lob5.c are failing with: "'-mfloat-abi=hard': selected
> processor lacks an FPU".
>
arm_split_atomic_op handles subtracting a constant by converting it
into addition of the negated constant. But if the type of the operand
is int and the constant is -1 we currently end up generating invalid
RTL which can lead to an abort later on.
The problem is that in a HOST_WIDE_INT, INT_MIN
On 19/11/2020 14:40, Wilco Dijkstra via Gcc-patches wrote:
> Hi,
>
As for your second patch, --with-cpu-64 could be a simple alias indeed,
but what is the exact definition/expected behaviour of a --with-cpu-32
on a target that only supports 64-bit code? The AArch64
On 18/11/2020 17:16, Pop, Sebastian via Gcc-patches wrote:
> Hi,
>
> On 11/18/20, 10:17 AM, "Wilco Dijkstra" wrote:
>>I presume you're trying to unify the --with- options across most targets?
>
> Yes, my intention was to provide the same configure options on arm64
> as on x86, such that
On 17/11/2020 15:18, Bernd Edlinger wrote:
> On 11/17/20 1:44 PM, Richard Earnshaw (lists) wrote:
>> On 03/11/2020 15:08, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this fixes a problem with a missing symbol __sync_synchronize
>>> which happ
On 03/11/2020 15:08, Bernd Edlinger wrote:
> Hi,
>
> this fixes a problem with a missing symbol __sync_synchronize
> which happens when newlib is used together with libstdc++ for
> the non-threaded simulator target arm-none-eabi.
>
> There are several questions on stackoverflow about this issue.
On 14/09/2020 20:04, Wilco Dijkstra wrote:
> Hi Richard,
>
>> On 14/09/2020 15:19, Wilco Dijkstra wrote:
>>> The --with-cpu/--with-arch configure option processing not only checks
>>> valid arguments
>>> but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This
>>> isn't used
>>>
On 14/09/2020 13:01, Wilco Dijkstra wrote:
> Enable the fast shift feature in Neoverse N1 tuning - this means additions
> with
> a shift left by 1-4 are as fast as addition. This improves multiply by
> constant
> expansions, eg. x * 25 is now emitted using shifts rather than a multiply:
>
> add
On 14/09/2020 15:19, Wilco Dijkstra wrote:
> The --with-cpu/--with-arch configure option processing not only checks valid
> arguments
> but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This
> isn't used
> however since a --with-cpu is translated into a -mcpu option which is
>
On 20/08/2020 18:07, Vaseeharan Vinayagamoorthy wrote:
> Hi Szabolcs,
>
> In the top level gcc config.log, I see:
>
> configure:5541: checking whether aarch64-none-linux-gnu-g++ supports C++11
> features by default
> configure:5837: aarch64-none-linux-gnu-g++ -c -g -O2 conftest.cpp >&5
>
On 22/07/2020 13:24, Richard Biener via Gcc-patches wrote:
> On Wed, Jul 22, 2020 at 12:03 PM Andrea Corallo
> wrote:
>>
>> Hi all,
>>
>> I'd like to submit the following two patches implementing a new AArch64
>> specific back-end pass that helps optimize branch-dense code, which can
>> be a
On 06/04/2020 12:19, Richard Sandiford wrote:
> "Richard Earnshaw (lists)" writes:
>> On 03/04/2020 16:03, Richard Sandiford wrote:
>>> "Richard Earnshaw (lists)" writes:
>>>> On 03/04/2020 13:27, Richard Sandiford wrote:
>>>>&g
On 03/04/2020 16:03, Richard Sandiford wrote:
> "Richard Earnshaw (lists)" writes:
>> On 03/04/2020 13:27, Richard Sandiford wrote:
>>> "Richard Earnshaw (lists)" writes:
>>>> On 02/04/2020 19:53, Richard Henderson via Gcc-patches
On 03/04/2020 13:27, Richard Sandiford wrote:
> "Richard Earnshaw (lists)" writes:
>> On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
>>> This is attacking case 3 of PR 94174.
>>>
>>> In v2, I unify the various subtract-with-borrow an
On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
> This is attacking case 3 of PR 94174.
>
> In v2, I unify the various subtract-with-borrow and add-with-carry
> patterns that also output flags with unspecs. As suggested by
> Richard Sandiford during review of v1. It does seem
On 02/04/2020 17:52, Tamar Christina wrote:
> Hi All,
>
> It is currently impossible to use fp16 on any architecture higher than
> Armv8.3-a
> due to a bug in options canonization. This bug results in the fp16 flag not
> being emitted in the assembly when it should have been.
>
> This is
The recent patch to convert all thumb1 code in libgcc to unified syntax
ommitted the conditional code that is used only when building the
library for minimal size. This patch fixes this case.
I've also fixed the COND macro so that a single definition is always
used that is for unified syntax.
On 25/03/2020 07:21, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase ICEs, because arm_gen_discompare_reg creates invalid
> RTL which then propagates into DEBUG_INSNs and ICEs while handling them.
> The problem is that this function emits
> (insn 18 17 19 2 (set (reg:CC_DNE
On 12/03/2020 14:24, Jakub Jelinek via Gcc-patches wrote:
On Thu, Mar 12, 2020 at 12:27:48PM +0100, Andreas Schwab wrote:
I'm getting this ICE with -mabi=ilp32:
during RTL pass: fwprop1
/opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar':
On 11/03/2020 13:50, Szabolcs Nagy wrote:
On 10/03/2020 09:55, Andrea Corallo wrote:
Hi all,
second and last patch of the two reworking FPCR and FPSR builtins.
This rework __builtin_aarch64_set_fpcr (unsigned) and
__builtin_aarch64_set_fpsr (unsigned) to emit a read-modify-sequences
as:
Unified syntax has been the official syntax for thumb1 assembly for over
10 years now. It's time we made preparations for that becoming the
default in the assembler. But before we can start doing that we really
need to clean up some laggards from the olden days. Libgcc support for
thumb1 is
On 02/03/2020 16:44, Jeff Law wrote:
On Mon, 2020-03-02 at 16:40 +, Richard Earnshaw (lists) wrote:
On 02/03/2020 15:46, Jeff Law wrote:
More minor fallout from Vlad's IRA changes.
Previously this test used r3 to hold a value across a call (it's an ipa-ra
test). After Vlad's changes
On 02/03/2020 15:46, Jeff Law wrote:
More minor fallout from Vlad's IRA changes.
Previously this test used r3 to hold a value across a call (it's an ipa-ra
test). After Vlad's changes we're using r1 instead.
This patch makes the obvious change to pattern we can for which should bring
the
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 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 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
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
On 17/02/2020 17:54, Andrew Pinski wrote:
On Mon, Feb 17, 2020 at 7:56 AM Richard Earnshaw (lists)
wrote:
On 17/02/2020 15:42, Richard Sandiford wrote:
"Richard Earnshaw (lists)" writes:
On 14/02/2020 10:41, Andrew Pinski wrote:
On Fri, Feb 14, 2020 at 2:12 AM Richard Earns
On 17/02/2020 15:42, Richard Sandiford wrote:
"Richard Earnshaw (lists)" writes:
On 14/02/2020 10:41, Andrew Pinski wrote:
On Fri, Feb 14, 2020 at 2:12 AM Richard Earnshaw (lists)
wrote:
On 14/02/2020 03:18, apin...@marvell.com wrote:
From: Andrew Pinski
Right if someon
On 14/02/2020 10:41, Andrew Pinski wrote:
On Fri, Feb 14, 2020 at 2:12 AM Richard Earnshaw (lists)
wrote:
On 14/02/2020 03:18, apin...@marvell.com wrote:
From: Andrew Pinski
Right if someone supplies a -mcpu= option and then overrides
that option with -march=*, we get a warning when
On 14/02/2020 03:18, apin...@marvell.com wrote:
From: Andrew Pinski
Right if someone supplies a -mcpu= option and then overrides
that option with -march=*, we get a warning when they conflict.
What we need is a generic cpu for each arch level but that is not
that useful because the only
On 11/02/2020 10:14, Andrea Corallo wrote:
Hi all,
This patch enables the Armv8.1-M Mainline LOB (low overhead branch) extension
low overhead loops (LOL) feature by using the loop-doloop pass
that it shares with the Swing Modulo Scheduler.
bootstrapped arm-none-linux-gnueabihf, does not
On 10/02/2020 09:27, Christophe Lyon wrote:
On Fri, 7 Feb 2020 at 17:55, Richard Earnshaw (lists)
wrote:
On 07/02/2020 16:43, Christophe Lyon wrote:
On Fri, 7 Feb 2020 at 14:49, Richard Earnshaw (lists)
wrote:
On 07/02/2020 13:19, Christophe Lyon wrote:
When running the testsuite
On 01/02/2020 08:30, Jakub Jelinek wrote:
Hi!
The following testcase ICEs on arm. The problem is that the following
peephole tries to match adjacent *arm_movsi_insn + *arm_cmpsi_insn;
the *arm_movsi_insn uses =rk, rk constraints and *arm_cmpsi_insn
uses r, IL constraints for what is matched by
On 07/02/2020 16:43, Christophe Lyon wrote:
On Fri, 7 Feb 2020 at 14:49, Richard Earnshaw (lists)
wrote:
On 07/02/2020 13:19, Christophe Lyon wrote:
When running the testsuite with -fdisable-rtl-fwprop2 and -mpure-code
for cortex-m0, I noticed that some testcases were failing because we
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 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
On 07/02/2020 13:19, Christophe Lyon wrote:
When running the testsuite with -fdisable-rtl-fwprop2 and -mpure-code
for cortex-m0, I noticed that some testcases were failing because we
still generate "ldr rX, .LCY", which is what we want to avoid with
-mpure-code. This is latent since a recent
On 07/02/2020 02:12, Modi Mo via gcc-patches wrote:
I did a quick bootstrap, this shows several failures like:
gcc/builtins.c:9427:1: error: unrecognizable insn:
9427 | }
| ^
(insn 212 211 213 24 (set (reg:SI 207)
(zero_extract:SI (reg:SI 206)
(const_int 26
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 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
The t-arm make fragment currently uses 'mv' to update some files that
are automatically regenerated, but this causes problems on read-only
filesystems if the date stamps are incorrect and the files have not
really changed. So use move-if-change instead.
PR target/93548
*
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 to be the only person
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 to be the only person
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
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
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 another
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 another
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 to be the only person
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 to be the only person
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' (lowercase
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' (lowercase
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 all-caps seems
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 all-caps seems
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
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
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
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
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
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
As described in https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01660.html
I've had to change the personal branch space configuration slightly to
avoid problems with ambiguous refs. This patch updates wwwdocs to
reflect that change. It also adds documentation for the new
Whilst trying to convert the add vendor branch script to work with
personal branches I encountered a minor issue where git would report
ambiguous refs when checking out the new branch.
It turns out that this is because git considers / to be
ambiguous if both
refs/heads//
and
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
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
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
covers
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
covers
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 a complete
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 a complete
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.
On 22/01/2020 22:15, Joseph Myers wrote:
On Wed, 22 Jan 2020, Richard Earnshaw (lists) wrote:
Joseph, have I got all of these right?
refs/meta in that list should be refs/meta/config, there isn't anything
else under refs/meta/ at present.
I've pushed this version...
diff --git a/htdocs
[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
[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
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
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
The GCC git repository makes use of some non-standard refs so that by
default only the most active and useful branches and tags are fetched by
a git clone. This patch documents the additional branch and tag spaces
that exist on the server.
Joseph, have I got all of these right?
R.
diff
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.
+
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.
+
On 22/01/2020 10:04, Richard Earnshaw (lists) wrote:
On 21/01/2020 23:23, Hans-Peter Nilsson wrote:
From: "Richard Earnshaw (lists)"
Date: Tue, 21 Jan 2020 14:36:32 +0100
Correction, the branch should be named /, so the push
should be
git push vendors/ /
For example, for the
On 21/01/2020 23:23, Hans-Peter Nilsson wrote:
From: "Richard Earnshaw (lists)"
Date: Tue, 21 Jan 2020 14:36:32 +0100
Correction, the branch should be named /, so the push
should be
git push vendors/ /
For example, for the ARM vendor, the push would be
git push vendors/A
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
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
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 omp_code_to_statement
101 - 200 of 1127 matches
Mail list logo
