This fixes a bunch more tests that try to override the default architecture;
some partially used the framework for doing this, others just blindly
added a -march option, which was doomed to cause problems. In most cases
we can now run these tests regardless of the users testing options and
the ba
On 14/11/2023 16:23, Wilco Dijkstra wrote:
Hi,
I checked codesize on SPECINT2017, and 96 had practically identical size.
Using 128 would also be a reasonable Os value with a very slight size
increase,
and 384 looks good for O2 - however I didn't want to tune these values
as this
is a cleanup
On 14/11/2023 17:01, Christophe Lyon wrote:
Hi,
On 11/13/23 15:26, Richard Earnshaw wrote:
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 1a7bea96c1e..d414cddf4dc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib
My previous patch series added a new function to check for armv6t2
compatible hardware. But the test was not correctly implemented and
also did not follow the standard naming convention for Arm hw
compatibility tests. Fix both of these issues.
gcc/testsuite:
* lib/target-supports.exp (
On 16/11/2023 06:15, Philipp Tomsich wrote:
With the addition of CSSC (Common Short Sequence Compression)
instructions, a number of idioms match to single instructions (e.g.,
abs) that previously expanded to multi-instruction sequences.
This recognizes (some of) those idioms that are now misc
On 15/11/2023 17:07, Tamar Christina wrote:
Hi All,
In anticipation of adding new generic turning values this removes the hardcoding
of the "generic" CPU and instead just specifies it as a normal CPU.
No change in behavior is expected.
Bootstrapped Regtested on aarch64-none-linux-gnu and no
On 15/11/2023 17:07, Tamar Christina wrote:
Hi All,
This patch adds a new generic scheduling model "generic-armv8-a" and makes it
the default for all Armv8 architectures.
-mcpu=generic and -mtune=generic is kept around for those that really want the
deprecated cost model.
Rather than refer
On 15/11/2023 17:08, Tamar Christina wrote:
Hi All,
This patch adds a new generic scheduling model "generic-armv9-a" and makes it
the default for all Armv9 architectures.
-mcpu=generic and -mtune=generic is kept around for those that really want the
deprecated cost model.
Bootstrapped Regte
On 15/11/2023 17:08, Tamar Christina wrote:
Hi All,
At the moment we emit a warning whenever you specify both -march and -mcpu
and the architecture of them differ. The idea originally was that the user may
not be aware of this change.
However this has a few problems:
1. Architecture revis
On 16/11/2023 09:33, Tamar Christina wrote:
-Original Message-
From: Richard Earnshaw
Sent: Thursday, November 16, 2023 9:27 AM
To: Tamar Christina ; gcc-patches@gcc.gnu.org
Cc: nd ; Richard Earnshaw ;
Marcus Shawcroft ; Kyrylo Tkachov
; Richard Sandiford
Subject: Re: [PATCH 6/6
On 15/11/2023 17:08, Tamar Christina wrote:
Hi All,
At the moment we emit a warning whenever you specify both -march and -mcpu
and the architecture of them differ. The idea originally was that the user may
not be aware of this change.
However this has a few problems:
1. Architecture revis
On 20/11/2023 10:41, Christophe Lyon wrote:
Hi Richard,
On Mon, 13 Nov 2023 at 15:27, Richard Earnshaw wrote:
Add an arm-specific test to check_effective_target_hard_float for
Arm to handle cases where we only have single-precision FP in hardware.
gcc/testsuite:
* lib/target
On 20/11/2023 10:23, Christophe Lyon wrote:
Hi Richard,
On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw wrote:
A number of tests in the gcc testsuite, especially for arm-specific
targets, add various flags to control the architecture. These run
into problems when the compiler is
On 16/11/2023 15:19, Tamar Christina wrote:
Hi All,
This documents the behavior of the generic CPU options on AArch64.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* doc/invoke.texi (generic): Update defintion.
On 20/11/2023 13:36, Christophe Lyon wrote:
On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
wrote:
On 20/11/2023 10:23, Christophe Lyon wrote:
Hi Richard,
On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw wrote:
A number of tests in the gcc testsuite, especially for arm-specific
On 20/11/2023 14:24, Christophe Lyon wrote:
On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw
wrote:
On 20/11/2023 13:36, Christophe Lyon wrote:
On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
wrote:
On 20/11/2023 10:23, Christophe Lyon wrote:
Hi Richard,
On Mon, 13 Nov 2023 at 15:28
On 20/11/2023 14:39, Richard Earnshaw wrote:
On 20/11/2023 14:24, Christophe Lyon wrote:
On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw
wrote:
On 20/11/2023 13:36, Christophe Lyon wrote:
On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
wrote:
On 20/11/2023 10:23, Christophe Lyon
On 20/11/2023 14:50, Christophe Lyon wrote:
On Mon, 20 Nov 2023 at 15:39, Richard Earnshaw
wrote:
On 20/11/2023 14:24, Christophe Lyon wrote:
On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw
wrote:
On 20/11/2023 13:36, Christophe Lyon wrote:
On Mon, 20 Nov 2023 at 13:44, Richard
On 20/11/2023 21:49, Tamar Christina wrote:
-Original Message-
From: Richard Earnshaw
Sent: Monday, November 20, 2023 12:53 PM
To: Tamar Christina ; gcc-patches@gcc.gnu.org
Cc: nd ; Richard Earnshaw ;
Marcus Shawcroft ; Kyrylo Tkachov
; Richard Sandiford
Subject: Re: [PATCH]AArch64
I'm going to hold off for 24 hours on this to give some chance for
feedback before committing. Is using EXTRA_PARTS in this way
acceptable? If not, what method would you recommend? Is there a
better way of achieving this than using --defsym (which seems to have
the side effect of causing the tar
On 22/11/2023 01:40, Maciej W. Rozycki wrote:
Use non-capturing parentheses for the subexpressions used with
`scan-assembler-times', to avoid a quirk with double-counting.
gcc/testsuite/
* gcc.target/arm/pr53447-5.c: Use non-capturing parentheses with
`scan-assemble
On 21/11/2023 16:06, Richard Earnshaw wrote:
I'm going to hold off for 24 hours on this to give some chance for
feedback before committing. Is using EXTRA_PARTS in this way
acceptable? If not, what method would you recommend? Is there a
better way of achieving this than using --d
On 06/10/2023 12:55, ezra.sito...@arm.com wrote:
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1 intrinsic for arm32.
We avoid the terms arm32 and arm64 in the gnu toolchain because of the
potential for conflict with wild-card regexp
On 27/11/2023 14:56, Richard Earnshaw wrote:
On 06/10/2023 12:55, ezra.sito...@arm.com wrote:
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vst1 intrinsic for arm32.
We avoid the terms arm32 and arm64 in the gnu toolchain because of
On 06/10/2023 12:55, ezra.sito...@arm.com wrote:
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1 intrinsic for arm32.
This patch adds the _x3 variants of the vst1 intrinsic.
OK, but see comments on the first patch about naming and fo
On 06/10/2023 12:56, ezra.sito...@arm.com wrote:
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1 intrinsic for arm32.
This patch adds the _x4 variants of the vst1 intrinsic.
OK, but please see comment on first patch about naming and f
On 10/10/2023 15:04, ezra.sito...@arm.com wrote:
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1q intrinsic for AArch32.
This patch adds the _x2 variants of the vst1q intrinsic. Tests use xN so that
the latter variants (_x3, _x4) could
On 10/10/2023 15:04, ezra.sito...@arm.com wrote:
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1q intrinsic for AArch32.
This patch adds the _x3 variants of the vst1q intrinsic.
OK, but format lines to <= 70 columns please.
R.
ACLE
On 10/10/2023 15:04, ezra.sito...@arm.com wrote:
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1q intrinsic for AArch32.
This patch adds the _x4 variants of the vst1q intrinsic.
OK, but see earlier comments about formatting.
R.
AC
On 19/10/2023 14:41, ezra.sito...@arm.com wrote:
Add xN variants of vld1_types intrinsic for AArch32.
These patches are all OK, but please fix the commit message formatting
as with earlier series.
R.
On 06/10/2023 10:49, ezra.sito...@arm.com wrote:
Add xN variants of vld1q_types intrinsic.
These patches are all OK, but please fix commit message formatting in
line with the comments on the earlier series.
R.
My previous patch to add an implementation of __sync_syncrhonize with
a warning trips a testsuite failure in fortran (and possibly other
languages as well) as the framework expects no blank lines in the
output, but this warning was generating one. So remove the newline
from the end of the message
On 13/11/2023 11:37, Victor Do Nascimento wrote:
The introduction of further architectural-feature dependent ifuncs
for AArch64 makes hard-coding ifunc `_i' suffixes to functions
cumbersome to work with. It is awkward to remember which ifunc maps
onto which arch feature and makes the code har
On 13/11/2023 11:37, Victor Do Nascimento wrote:
The armv9.4-a architectural revision adds three new atomic operations
associated with the LSE128 feature:
* LDCLRP - Atomic AND NOT (bitclear) of a location with 128-bit
value held in a pair of registers, with original data loaded into
On 10/11/2023 11:22, Florian Weimer wrote:
This test looks like it intends to pass a small struct argument
through both a non-variadic and variadic argument, but due to
the typo, it does not achieve that.
gcc/testsuite/
* gcc.target/aarch64/aapcs64/ice_1.c (foo): Call named.
---
g
Support for the FPA on Arm was removed after gcc-4.7, but this little
bit of crufty code was left behind. In particular the code to support
the 'N' modifier in assembly code was left behind and this lead to a
trail of other code that depended on it, even though most of the
constants that it suppo
The arm 'pe' target was removed back in 2012 when the FPA support was
removed, but in a small number of places some conditional code was
accidentally left behind. It's no-longer needed, so remove it.
gcc/ChangeLog:
* config/arm/arm-protos.h (arm_dllexport_name_p): Remove prototype.
On 12/06/2024 11:35, Richard Earnshaw (lists) wrote:
> On 11/06/2024 17:35, Wilco Dijkstra wrote:
>> Hi Christophe,
>>
>>> PR target/115153
>> I guess this is typo (should be 115188) ?
>>
>> Correct.
>>
>>> +/* { dg-options
On Arm only r0-r3 (the argument registers) and IP are available for
use as an address for an indirect sibcall. But if all the argument
registers are used and IP is clobbered during the epilogue, or is used
to pass closure information, then there is no spare register to hold
the address and we must
haven't fixed all of the possible use cases with
this series, but I have converted some of the main tables in the
dejagnu target support.
Richard Earnshaw (2):
arm: Allow -mcpu and -march options to be unset
arm: testsuite: make use of -mcpu=unset/-march=unset
gcc/config/arm/
The compiler will warn if the architectural specification derived from
a -mcpu option is not the same as that specified by -march. This is
because it was never intended that the two should be used at the same
time: -mcpu= is supposed to be shorthand for -mtune=
-march=arch-of().
Unfortunately, th
This patch makes use of the new ability to unset the CPU or
architecture flags on the command line to enable several more tests on
Arm. It doesn't cover every case and it does enable some tests that
now fail for different reasons when the tests are no-longer skipped;
these were failing anyway for
On 08/08/13 14:38, Richard Earnshaw wrote:
> PR target/56979 is a bug where a parameter to a function has an
> alignment that is larger than its natural alignment. In this case this
> causes the mid-end to generate a mode for the argument that is
> incompatible with the regist
On 22/08/13 15:26, Julian Brown wrote:
> Hi,
>
> This patch fixes what I assume to be a simple omission from the
> configure test for debug_line assembler support in gcc/configure. This
> tripped an obscure corner-case test in our build infrastructure, which
> is fixed by the attached patch, but I
On 22/08/13 16:03, Jan Hubicka wrote:
> Hi,
> this patch fixes overflow happening in -ftime-report when printing memory
> usage
> of bigger WPA compilations.
>
> Honza
>
> * timevar.c (validate_phases): Use size_t for memory.
> * timevar.h (struct timevar_time_def): Use size_t for gg
On 27/08/13 12:10, Richard Biener wrote:
> What's this for and what's the desired semantics? I don't like having
> extra tree codes for this. Is this for a specific instruction set
> feature?
The background is to support the conditional compare instructions in ARM
(more effectively) and AArch64 a
On 28/08/13 08:00, bin.cheng wrote:
> Hi,
>
> This patch refines scaled address expression on ARM. It supports
> "base+index*scale" in arm_legitimate_address_outer_p. It also tries to
> legitimize "base + index * scale + offset" with "reg <- base + offset; reg
> + index * scale" by introducing
On 30/08/13 14:09, Yvan Roux wrote:
> Hi,
>
> here is a request for comments on the 2 attached patches which enable
> the build of GCC on ARM with LRA. The patches introduce a new
> undocumented option -mlra to use LRA instead of reload, as what was
> done on previous LRA support, which is here t
On 30/08/13 15:03, Tejas Belagod wrote:
> Hi,
>
> The attached patch removes dependency on stdint's macros used in arm_neon.h
> viz.
> UINT64_C() and INT64_C() making arm_neon.h more C++-friendly.
>
> Tested on aarch64-none-elf.
>
> OK for trunk?
>
> Thanks,
> Tejas Belagod.
> ARM.
>
> Chang
On 01/09/13 14:10, Bernd Edlinger wrote:
> IMHO the AAPCS forbids packed structures. Therefore we need not
> interfere with the C++ memory model if we have unaligned data.
The AAPCS neither forbids nor requires packed structures. They're a GNU
extension and as such not part of standard C++. Thus
On 04/09/13 14:12, James Greenhalgh wrote:
>
> The vaddvq_s64 and vaddvq_u64 intrinsics are defined to return 32-bit
> types. This is clearly wrong, so fix them to return int64_t and uint64_t
> as expected.
>
> Regression tested with a run through aarch64.exp and sanity checked.
>
> OK for trunk
On 19/08/13 13:46, James Greenhalgh wrote:
>
> Hi,
>
> This patch does two things:
>
> 1. Moves all the "neon_type" attribute values in the ARM backend into
> "type", and removes "neon_type".
>
> 2. Splits type f_2_r and r_2_f to enable them to be used in a similar
> way as neon_mcr et. al.
>
This patch slightly improves the code sequence generated when using STRD
instructions instead of PUSH. Rather than emit a stack decrement
operation followed by a sequence of STRDs and a final STR we merge the
stack decrement with the initial store.
Furthermore, we arrange the STR operation so tha
On 05/09/13 10:06, James Greenhalgh wrote:
>
> *PING*
>
> I've rebased this patch on to current trunk, the changes between this and
> the previous version are below:
>
>> @@ -3203,7 +3203,7 @@ (define_insn "*aarch64_ashl_sisd_or_int_
>> (set_attr "simd_type" "simd_shift_imm,simd_shift,*")
>>
On 05/09/13 15:07, Eric Botcazou wrote:
> Hi,
>
> in case the ip register needs to be saved before establishing an APCS frame,
> i.e. when it is used as the static chain register, the prologue tries various
> tricks in the following order:
>
> 1. The last argument register r3.
>
On 05/09/13 17:44, James Greenhalgh wrote:
>
> This patch changes the default type to be 'untyped' and then adds
> type information to everything in the ARM backend.
>
> To do this, we introduce three new types:
>
> * "multiple" which is used where an insn will be split, or
> where it will
On 06/09/13 14:24, James Greenhalgh wrote:
>
> This patch splits the f_cvt attribute to:
>
> * f_cvt conversions between float representations.
> * f_cvti2f conversions from int to float.
> * f_cvtf2i conversions from float to int.
>
> Then we update the pipeline descriptions to refelct this
On 06/09/13 14:27, James Greenhalgh wrote:
>
> Hi,
>
> The type attributes "fdivs,fdivd" should be split as:
>
> fdivs -> fsqrts, fdivs
> fdivd -> fsqrtd, fdivd
>
> Do this and update pipelines as needed.
>
> Regression tested on aarch64-none-elf and arm-none-eabi and
> bootstrapped in series
On 06/09/13 14:29, James Greenhalgh wrote:
>
> Hi,
>
> We don't really need to split the types on these
> instructions. The ARM backend already has suitable descriptions
> of things like mla and smlal. Use them.
>
> Regression tested on aarch64-none-elf with no regressions.
>
> OK?
>
> Thanks,
On 06/09/13 14:44, James Greenhalgh wrote:
>
> Hi,
>
> This patch updates the AArch64 backend such that floating point
> moves are correctly categorized with type "FMOV".
>
> Then in the ARM backend we rename "FCPYS" to "FMOV" everywhere
> where it is appropriate to do so.
>
> Regression tested
On 06/09/13 14:46, James Greenhalgh wrote:
>
> Hi,
>
> We could introduce a whole new type for insns which generate two moves,
> but we have already introduced a "multiple" classification for
> types in the ARM backend, so use that in place of "mov_reg" where
> appropriate.
>
> Regression tested
On 06/09/13 14:48, James Greenhalgh wrote:
>
> Hi,
>
> This patch adds an "mrs" type to be used to categorize instructions
> which read or write from a special/system/co-processor register.
>
> Then we add this type to all the pipeline descriptions. This probably
> ends up as a miscategorization
On 06/09/13 14:50, James Greenhalgh wrote:
>
> Hi,
>
> The final (!!!) patch in the series making types equivalent between
> AArch64 and ARM backends deals with insns in the AArch64 backend
> which generate ldp and stp. We could invent a new type for these and
> add that type to all the pipeline
On 09/09/13 13:50, Kyrylo Tkachov wrote:
> Hi Richard,
>
>> On 29/07/13 14:58, Kyrylo Tkachov wrote:
>>> Hi all,
>>>
>>> Now that combine emits the canonical form for (eq (neg x) (y)) instead
>> of (eq
>>> (x) (neg y)), this patch fixes up the corresponding pattern in aarch64
>> to
>>> match that.
On 09/09/13 17:32, Kyrylo Tkachov wrote:
> Hi all,
>
> Shift operations with an immediate can generate a 16-bit encoding when the
> immediate is 5-bit wide, i.e. in the range [0-31]. Therefore we can use them
> in IT blocks even with the -mrestrict-it rules.
>
> I decided to reuse the "N" constra
On 10/09/13 14:11, Kyrylo Tkachov wrote:
>> On 09/09/13 17:32, Kyrylo Tkachov wrote:
>>> Hi all,
>>>
>>> Shift operations with an immediate can generate a 16-bit encoding when
>>> the immediate is 5-bit wide, i.e. in the range [0-31]. Therefore we
>>> can use them in IT blocks even with the -mrestr
PR target/58361 is a wrong code bug where we treat an instruction as
conditional but fail to put the conditional marker on the assembly.
Since the instruction can be correctly executed as a conditional
instruction, the fix is to enable that and to put out the condition code
accordingly.
The partic
On 18/04/13 06:34, Bin Cheng wrote:
> Hi,
> Before thumb1_reorg, ARM backend uses peephole to save comparison
> instructions when a flag setting move is found before branch instruction.
> Since we are using thumb1_reog now, it can be extended to catch more
> opportunities by searching flag setting
On 17/09/13 03:16, bin.cheng wrote:
>
>
>> -Original Message-----
>> From: Richard Earnshaw
>> Sent: Thursday, September 12, 2013 11:24 PM
>> To: Bin Cheng
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH ARM]Extend thumb1_reorg to save more co
On 09/09/13 10:56, Kyrylo Tkachov wrote:
> [Resending, since I was away and not pinging it]
>
>
> Hi all,
>
> In PR58088 the constant folder goes into an infinite recursion and runs out of
> stack space because of two conflicting optimisations:
> (X * C1) & C2 plays dirty when nested inside an I
On 16/09/13 15:13, Richard Biener wrote:
> +void
> +get_range_info (tree name, double_int &min, double_int &max,
> +enum value_range_type &range_type)
>
> I'm not sure we want to use references. Well - first time.
Personally, I don't think we should ever allow non-const reference
then it is essential to ensure that the architecture also
has the instructions.
R.
2013-09-18 Richard Earnshaw
* arm.c (arm_get_frame_offsets): Validate architecture supports
LDRD/STRD before accepting the tuning preference.
(arm_expand_prologue): Lik
On 18/09/13 15:00, Richard Earnshaw wrote:
> On ARM targets that normally support LDRD/STRD there are tuning
> parameters that express the preference for using these instructions over
> LDM/STM. However, that's only a preference and when the architecture
> and tuning options di
On 18/09/13 10:45, Zhenqiang Chen wrote:
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, August 27, 2013 8:18 PM
>> To: Richard Earnshaw
>> Cc: Zhenqiang Chen; GCC Patches
>> Subject: Re: [PAT
On 23/09/13 09:11, Zhenqiang Chen wrote:
>
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Yufeng Zhang
>> Sent: Monday, September 23, 2013 3:16 PM
>> To: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH, ARM] Fix PR tar
On 23/09/13 14:42, Kyrill Tkachov wrote:
> Hi Renlin, all,
>
> On 20/09/13 15:30, Renlin Li wrote:
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -7016,10 +7016,10 @@ arm_legitimize_reload_address (rtx *p,
>>
>> /* Reload the high part into a base reg; leave the low p
On 23/09/13 13:07, Richard Biener wrote:
> What's the problem
> with arm supporting reg1 * scale? Why shouldn't it being able to handle
> the implicit zero offset?
Something like "we don't have an instruction that can do that"...
Valid addresses are of the general form
address:=
'[' base-r
On 24/09/13 11:12, Richard Biener wrote:
> Or even [reg*scale] (not sure about that). But yes, at least reg*scale +
> offset
> and reg*scale + reg.
I can't conceive of a realistic case where one would want to scale the
base address. Scaling the offset is fine, but never the base. So
reg*scale+
On 23/09/13 18:43, Steve Ellcey wrote:
> On Mon, 2013-09-23 at 16:26 +0100, Marcus Shawcroft wrote:
>> On 4 June 2013 20:49, Steve Ellcey wrote:
>>> This patch allows me to build libgfortran for a cross-compiling toolchain
>>> using newlib. Currently the checks done by AC_CHECK_FUNCS_ONCE fail wi
On 24/09/13 10:03, Yvan Roux wrote:
> Hi,
>
> The following patch switch LRA on for AArch64. The patch introduces
> an undocumented option -mlra to use LRA instead of reload, for a
> testing purpose. Please notice that this patch is dependent on the
> one submitted in the thread below:
>
> htt
On 26/09/13 09:50, Zhenqiang Chen wrote:
>
>
>> -Original Message-----
>> From: Richard Earnshaw
>> Sent: Monday, September 23, 2013 11:11 PM
>> To: Zhenqiang Chen
>> Cc: Yufeng Zhang; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH, ARM] Fix PR targe
On 30/09/13 09:52, James Greenhalgh wrote:
>
> Hi,
>
> Recently I've found myself getting a number of segfaults from
> code calling in to the arm_early_load/alu_dep functions in
> aarch64-common.c. These functions expect a particular form
> for the RTX patterns they work over, but some of them do
On 09/10/12 10:13, Sebastian Huber wrote:
On 10/09/2012 11:08 AM, Sebastian Huber wrote:
Hello,
this is an updated patch for the GCC 4.8. It renames the target
"arm-rtemseabi" to "arm-rtems" to bring the ARM tool chain back to the standard
RTEMS target pattern "$ARCH-rtems".
GCC test suite re
On 09/10/12 14:23, Sebastian Huber wrote:
Updated patch.
OK.
R.
0001-Rename-target-arm-rtemseabi-to-arm-rtems.patch
From b338cd309306c1540b2519188e83f76950755cc5 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Mon, 24 Sep 2012 17:49:36 +0200
Subject: [PATCH] Rename target arm-rtems
On 08/10/12 08:29, Terry Guo wrote:
Hi,
When running libstdc++ regression test on Cortex-M0, the case 49445.cc fails
with error message:
/tmp/ccMqZdgc.o: In function `std::atomic::load(std::memory_order)
const':^M
/home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/
libs
On 27/09/12 01:02, Janis Johnson wrote:
Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux
targets, as described in PR54732. This patch adds an XFAIL.
Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on trunk.
Janis
gcc-20120926-5
2012-09-26 Janis Johnson
On 10/10/12 02:32, Terry Guo wrote:
-Original Message-
From: Richard Earnshaw
Sent: Tuesday, October 09, 2012 10:01 PM
To: Terry Guo
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Patch ARM] Fix that miss DMB instruction for ARMv6-M
On 08/10/12 08:29, Terry Guo wrote:
Hi,
When running
On 10/10/12 03:11, Janis Johnson wrote:
On 10/09/2012 07:39 AM, Richard Earnshaw wrote:
On 27/09/12 01:02, Janis Johnson wrote:
Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux
targets, as described in PR54732. This patch adds an XFAIL.
Tested on arm-none-eabi and arm
On 21/09/12 03:51, Janis Johnson wrote:
This patch adds test directives to skip 5 tests in gcc.target/arm if the
flags specified for the test would be overridden by or conflict with
flags used for all tests, such as multilib flags.
Tested on arm-none-eabi with a variety of test flags. I'll wait
On 21/09/12 03:52, Janis Johnson wrote:
Tests in gcc.target/arm/aapcs check for floating-point arguments being
passed correctly, but the added flag "-mfloat-abi=hard" can be
overridden by another value in flags used for all tests (like multilib
flags), causing the tests to fail. The tests in tha
On 26/09/12 09:59, Chung-Lin Tang wrote:
On 2012/9/16 05:15 PM, Richard Sandiford wrote:
Second ping for the ARM part of Chung-Lin's __builtin_thread_pointer patch:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01914.html
I think this is the only part that hasn't been approved.
Thanks,
Ri
On 15/10/12 15:20, Matthias Klose wrote:
On 26.06.2012 11:10, Richard Earnshaw wrote:
On 25/06/12 22:30, Matthias Klose wrote:
On 25.06.2012 18:21, Matthias Klose wrote:
On 25.06.2012 15:22, Richard Earnshaw wrote:
On 25/06/12 13:08, Matthias Klose wrote:
gcc/config.gcc now allows matching
On 16/10/12 17:34, Ian Bolton wrote:
Subject: [PATCH][AArch64] Restrict usage of SBFIZ to valid range only
This fixes an issue where we were generating an SBFIZ with
operand 3 outside of the valid range (as determined by the
size of the destination register and the amount of shift).
My patch ch
additional patterns with identical NOP behaviour. Can't
you just rename the existing pattern? Something like "force_register_use"?
R.
Thanks,
Greta
-Original Message-
From: Greta Yorsh [mailto:greta.yo...@arm.com]
Sent: 10 October 2012 16:14
To: GCC Patches
Cc: Ramana Radhak
On 17/10/12 11:55, Matthew Gretton-Dann wrote:
All,
Ulrich posted the following patch in July:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01123.html
Richard E requested that it be left in testing on trunk for a couple of days
before being backported to 4.7. Three months seems to satisfy
From: Richard Earnshaw
Sent: 17 October 2012 11:14
To: Greta Yorsh
Cc: GCC Patches; Ramana Radhakrishnan; ni...@redhat.com;
p...@codesourcery.com
Subject: Re: [PING][Patch, ARM] cleanup prologue_use pattern
On 17/10/12 11:08, Greta Yorsh wrote:
Ping!
I've been pondering why this was being
On 10/10/12 16:03, Greta Yorsh wrote:
This patch adds define_insn patterns for LDRD and STRD in Thumb mode.
ChangeLog
gcc/
2012-09-13 Sameera Deshpande
Greta Yorsh
* config/arm/arm-protos.h (offset_ok_for_ldrd_strd): New
declaration.
(operands_ok_ldrd_strd)
On 10/10/12 16:03, Greta Yorsh wrote:
Generate prologue using STRD when prefer_ldrd_strd is set in tune_params.
ChangeLog
gcc/
2012-09-13 Sameera Deshpande
Greta Yorsh
* config/arm/arm.c (thumb2_emit_strd_push): New function.
(arm_expand_prologue): Use the n
On 10/10/12 16:03, Greta Yorsh wrote:
Generate epilogue using LDRD in Thumb mode when prefer_ldrd_strd is set in
tune_params.
ChangeLog
gcc/
2012-09-13 Sameera Deshpande
Greta Yorsh
* config/arm/arm.c (thumb2_emit_ldrd_pop): New function.
(arm_expand_epilogue): U
On 10/10/12 16:03, Greta Yorsh wrote:
As a result of adding LDRD/STRD patterns in Thumb mode, the compiler
generates LDRD/STRD instead of LDM/STM in some cases. This patch adjusts
existing tests to accept LDRD/STRD in addition to LDM/STM.
ChangeLog
gcc/testsuite
2012-09-13 Sameera Deshpande
101 - 200 of 2975 matches
Mail list logo
