On Thu, 6 Mar 2025 at 11:03, Christophe Lyon wrote:
>
> On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw wrote:
> >
> > The header file arm_neon.h provides the Advanced SIMD intrinsics that
> > are available on armv7 or later A & R profile cores. However, they
> > are not compatible with M-profile
On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw wrote:
>
> The header file arm_neon.h provides the Advanced SIMD intrinsics that
> are available on armv7 or later A & R profile cores. However, they
> are not compatible with M-profile and we also need to ensure that the
> FP instructions are enabled
Christophe Lyon writes:
> On Sun, 2 Feb 2025 at 21:18, Thiago Jung Bauermann
> wrote:
>>
>> Since commit r15-491-gc290e6a0b7a9de this failure happens on on
>> armv8l-linux-gnueabihf and arm-eabi:
>>
>> Running gcc:gcc.target/arm/simd/simd.exp ...
>> gcc.target/arm/simd/mve-vabs.c: memmove foun
On Sun, 2 Feb 2025 at 21:18, Thiago Jung Bauermann
wrote:
>
> Since commit r15-491-gc290e6a0b7a9de this failure happens on on
> armv8l-linux-gnueabihf and arm-eabi:
>
> Running gcc:gcc.target/arm/simd/simd.exp ...
> gcc.target/arm/simd/mve-vabs.c: memmove found 0 times
> FAIL: gcc.target/arm/simd/
On 06/12/2024 16:09, Christophe Lyon wrote:
> Like dlstp-compile-asm-1.c, this test would fail if GCC is configured
> with non-default options, such as -mtune=cortex-a9.
>
> Force -mtune=cortex-m55 to avoid this unexpected issue.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/mve/dlstp-
On 06/12/2024 16:09, Christophe Lyon wrote:
> Like dlstp-compile-asm-1.c, this test would fail if GCC is configured
> with non-default options, such as -mtune=cortex-a9.
>
> Force -mtune=cortex-m55 to avoid this unexpected issue.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/mve/dlstp-
On 06/12/2024 10:02, Christophe Lyon wrote:
> This test would fail if GCC is configured with non-default options,
> such as -mtune=cortex-a9.
>
> This 'unexpected' scheduling makes the DLSTP optimization generate
> subslr, #16
> bhi .L4
> lctp
> pop {r4, r5, pc}
FTR this patch is superseded by Andre's patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670378.html
On Thu, 28 Nov 2024 at 11:12, Christophe Lyon
wrote:
>
> After the recent c23, GCC complains because the testcase calls f()
> with a parameter whereas the prototype has none.
>
>
Sorry, I only just spotted this while looking at something else.
On 23/05/2023 15:41, Christophe Lyon via Gcc-patches wrote:
Glibc defines int32_t as 'int' while newlib defines it as 'long int'.
Although these correspond to the same size, g++ complains when using the
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
Ok.
Thanks,
Kyrill
From: Christophe Lyon
Sent: Tuesday, May 30, 2023 4:44 PM
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; Stam Markianos-Wright
Subject: Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c
libc-agnostic
Ping?
On Tue, 23 May 2023 at 16:59, Stamatis
Ping?
On Tue, 23 May 2023 at 16:59, Stamatis Markianos-Wright <
stam.markianos-wri...@arm.com> wrote:
>
> On 23/05/2023 15:41, Christophe Lyon wrote:
> > Glibc defines int32_t as 'int' while newlib defines it as 'long int'.
> >
> > Although these correspond to the same size, g++ complains when u
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, May 30, 2023 3:00 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Chris Sidebottom
> Cc: Christophe Lyon
> Subject: [PATCH] [arm][testsuite]: Fix ACLE data-intrinsics testcases
>
> data-intrinsics-assembly.c forces -ma
On 23/05/2023 15:41, Christophe Lyon wrote:
Glibc defines int32_t as 'int' while newlib defines it as 'long int'.
Although these correspond to the same size, g++ complains when using the
On Wed, 19 May 2021 at 16:40, Richard Earnshaw
wrote:
>
>
>
> On 19/05/2021 09:10, Christophe Lyon via Gcc-patches wrote:
> > Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1,
> > and since the testcase forces -march=armv8-m.base, we need to check
> > whether this option is actua
On 19/05/2021 09:10, Christophe Lyon via Gcc-patches wrote:
Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1,
and since the testcase forces -march=armv8-m.base, we need to check
whether this option is actually supported.
Using dg-add-options arm_arch_v8m_base ensure that we
Andrea Corallo via Gcc-patches writes:
> "Richard Earnshaw (lists)" writes:
>
>> 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.
>>>
>>> l
"Richard Earnshaw (lists)" writes:
> 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=ha
Hi Andrea,
> -Original Message-
> From: Andrea Corallo
> Sent: 26 November 2020 13:54
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; nd
> Subject: [PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard
>
> Hi all,
>
> I'd like to submit the following sim
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".
>
Hi Christophe,
On 7/2/19 3:41 PM, Christophe Lyon wrote:
Hi,
While running the GCC testsuite with an armv8-m target, I noticed that
a few tests where causing the BFD linker to crash. I opened PR
ld/24709 for this [1], but fixing it properly is tricky and not worth
the headache.
I "fixed" the l
ping?
I think that's almost obvious?
And maybe should be applied to release branches.
Christophe
On Tue, 2 Jul 2019 at 16:41, Christophe Lyon wrote:
>
> Hi,
>
> While running the GCC testsuite with an armv8-m target, I noticed that
> a few tests where causing the BFD linker to crash. I opened P
On 01/12/17 15:43, Charles Baylis wrote:
On 30 November 2017 at 15:56, Kyrill Tkachov
wrote:
So is it the case that you don't run any arm tests that include arm_neon.h
in your configuration?
No, it is only the case that any arm test which includes arm_neon.h
(in fact, any system header) *an
On 30 November 2017 at 15:56, Kyrill Tkachov
wrote:
>
> So is it the case that you don't run any arm tests that include arm_neon.h
> in your configuration?
No, it is only the case that any arm test which includes arm_neon.h
(in fact, any system header) *and* uses dg-add-options
-mfloat-abi=hard
On 27/11/17 19:23, Charles Baylis wrote:
On 27 November 2017 at 17:47, Kyrill Tkachov
wrote:
Hi Charles,
On 27/11/17 17:03, Charles Baylis wrote:
Some of the new tests in addr-modes-float.c, which were introduced for
the rework of addressing modes costs [1] fail when GCC is configured
to de
On 27 November 2017 at 17:47, Kyrill Tkachov
wrote:
> Hi Charles,
>
> On 27/11/17 17:03, Charles Baylis wrote:
>>
>> Some of the new tests in addr-modes-float.c, which were introduced for
>> the rework of addressing modes costs [1] fail when GCC is configured
>> to default to a softfp calling con
Hi Charles,
On 27/11/17 17:03, Charles Baylis wrote:
Some of the new tests in addr-modes-float.c, which were introduced for
the rework of addressing modes costs [1] fail when GCC is configured
to default to a softfp calling convention. Fix this by annotating the
test functions with __attribute__
Hi Christophe,
On 10/11/17 08:43, Christophe Lyon wrote:
Hi,
The attached testsuite patch makes
gcc.target/arm/copysign_softfloat_1.c UNSUPPORTED on
arm-none-linux-gnueabihf, rather than FAIL/UNRESOLVED because of a
link failure since the toolchain startup code is in hard-float ABI
while the te
Hi Christophe,
On 07/06/17 10:13, Christophe Lyon wrote:
Hi,
On 2 June 2017 at 16:19, Christophe Lyon wrote:
Hi,
I have recently updated the dejagnu version I use for
cross-testing arm and aarch64 toolchains to 1.6+. One of the side
effects was mentioned by Jonathan in
https://gcc.gnu.org/m
ping?
On 16 June 2017 at 17:39, Christophe Lyon wrote:
> ping?
>
> On 7 June 2017 at 11:13, Christophe Lyon wrote:
>> Hi,
>>
>>
>> On 2 June 2017 at 16:19, Christophe Lyon wrote:
>>> Hi,
>>>
>>> I have recently updated the dejagnu version I use for
>>> cross-testing arm and aarch64 toolchains t
ping?
On 7 June 2017 at 11:13, Christophe Lyon wrote:
> Hi,
>
>
> On 2 June 2017 at 16:19, Christophe Lyon wrote:
>> Hi,
>>
>> I have recently updated the dejagnu version I use for
>> cross-testing arm and aarch64 toolchains to 1.6+. One of the side
>> effects was mentioned by Jonathan in
>> htt
Hi,
On 2 June 2017 at 16:19, Christophe Lyon wrote:
> Hi,
>
> I have recently updated the dejagnu version I use for
> cross-testing arm and aarch64 toolchains to 1.6+. One of the side
> effects was mentioned by Jonathan in
> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01267.html. Since I
> use
Hi,
We have decided to backport this patch fixing testing for ARMv8-M Baseline to
our embedded-6-branch.
*** gcc/testsuite/ChangeLog ***
2016-07-15 Thomas Preud'homme
* lib/target-supports.exp (add_options_for_arm_arch_v6m): Add
-mfloat-abi=soft option.
(add_optio
On Nov 28, 2016, at 8:52 AM, Thomas Preudhomme
wrote:
>
> Ping?
Ok.
> On 17/11/16 20:42, Thomas Preudhomme wrote:
>> Ping?
>>
>> Best regards,
>>
>> Thomas
>>
>> On 08/11/16 13:35, Thomas Preudhomme wrote:
>>> Ping,
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>> On 02/11/16 10:04, Thomas P
Hi Richard,
Ping?
Best regards,
Thomas
On 17/11/16 20:42, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 08/11/16 13:35, Thomas Preudhomme wrote:
Ping,
Best regards,
Thomas
On 02/11/16 10:04, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 28/10/16 10:49, Thomas Preu
Ping?
Best regards,
Thomas
On 08/11/16 13:35, Thomas Preudhomme wrote:
Ping,
Best regards,
Thomas
On 02/11/16 10:04, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 28/10/16 10:49, Thomas Preudhomme wrote:
On 22/09/16 16:47, Richard Earnshaw (lists) wrote:
On 22/09/16 15:51, Th
Ping,
Best regards,
Thomas
On 02/11/16 10:04, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 28/10/16 10:49, Thomas Preudhomme wrote:
On 22/09/16 16:47, Richard Earnshaw (lists) wrote:
On 22/09/16 15:51, Thomas Preudhomme wrote:
Sorry, noticed an error in the patch. It was not ca
Ping?
Best regards,
Thomas
On 28/10/16 10:49, Thomas Preudhomme wrote:
On 22/09/16 16:47, Richard Earnshaw (lists) wrote:
On 22/09/16 15:51, Thomas Preudhomme wrote:
Sorry, noticed an error in the patch. It was not caught during testing
because GCC was built with --with-mode=thumb. Correct p
On 22/09/16 16:47, Richard Earnshaw (lists) wrote:
On 22/09/16 15:51, Thomas Preudhomme wrote:
Sorry, noticed an error in the patch. It was not caught during testing
because GCC was built with --with-mode=thumb. Correct patch attached.
Best regards,
Thomas
On 22/09/16 14:49, Thomas Preudhomme
On 22/09/16 17:15, Thomas Preudhomme wrote:
On 22/09/16 16:47, Richard Earnshaw (lists) wrote:
On 22/09/16 15:51, Thomas Preudhomme wrote:
Sorry, noticed an error in the patch. It was not caught during testing
because GCC was built with --with-mode=thumb. Correct patch attached.
Best regards,
On 22/09/16 16:47, Richard Earnshaw (lists) wrote:
On 22/09/16 15:51, Thomas Preudhomme wrote:
Sorry, noticed an error in the patch. It was not caught during testing
because GCC was built with --with-mode=thumb. Correct patch attached.
Best regards,
Thomas
On 22/09/16 14:49, Thomas Preudhomme
On 22/09/16 15:51, Thomas Preudhomme wrote:
> Sorry, noticed an error in the patch. It was not caught during testing
> because GCC was built with --with-mode=thumb. Correct patch attached.
>
> Best regards,
>
> Thomas
>
> On 22/09/16 14:49, Thomas Preudhomme wrote:
>> Hi,
>>
>> ARMv6-M and ARMv8
Sorry, noticed an error in the patch. It was not caught during testing because
GCC was built with --with-mode=thumb. Correct patch attached.
Best regards,
Thomas
On 22/09/16 14:49, Thomas Preudhomme wrote:
Hi,
ARMv6-M and ARMv8-M Baseline only support soft float ABI. Therefore, the
arm_arch_
On 6 July 2016 at 15:04, Wilco Dijkstra wrote:
> Fix prototype in vst1Q_laneu64-1.c to unsigned char* so it passes.
>
> Committed as trivial fix.
>
> ChangeLog
> 2016-07-06 Wilco Dijkstra
>
> gcc/testsuite/
> * gcc.target/arm/vst1Q_laneu64-1.c (foo): Use unsigned char*.
Thanks for
On Fri, Mar 18, 2016 at 10:31 AM, Andre Vieira (lists)
wrote:
> On 16/07/15 16:31, Kyrill Tkachov wrote:
>> Hi all,
>>
>> This scan-assembler test was failing for me when testing with an
>> explicit /-march=armv7-a variant because
>> it clashed with the -mcpu=cortex-m7 and overrode it.
>>
>> This
On 16/07/15 16:31, Kyrill Tkachov wrote:
> Hi all,
>
> This scan-assembler test was failing for me when testing with an
> explicit /-march=armv7-a variant because
> it clashed with the -mcpu=cortex-m7 and overrode it.
>
> This patch skips the test if the user forces an incompatible -march or
> -m
On 06/03/16 13:58, Christophe Lyon wrote:
Hi,
In commit r233654, Christian introduced a new test: pragma_cpp_fma.
Unfortunately, this test fails when gcc is configured --with-fpu >=
neonvfpv4: __ARM_FEATURE_FMA is still defined after the last
pop_options.
To address this, I propose to simply
On 13/07/15 17:01, Kyrill Tkachov wrote:
Hi Mantas,
On 05/03/15 10:14, Mantas Mikaitis wrote:
Hello,
Tests gcc.target/arm/macro_defs0.c and gcc.target/arm/macro_defs1.c fail
in multilib which forces -marm as pointed out in this message:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00483.html
Hi Mantas,
On 05/03/15 10:14, Mantas Mikaitis wrote:
Hello,
Tests gcc.target/arm/macro_defs0.c and gcc.target/arm/macro_defs1.c fail
in multilib which forces -marm as pointed out in this message:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00483.html .
This patch will cause these tests to be
On 16/06/15 11:09, Christophe Lyon wrote:
Hi,
Since Kyrill's r224367 (Restrict MAX_CONDITIONAL_EXECUTE when
-mrestrict-it is in place), gcc.target/arm/thumb-ifcvt.c fails when
testing a compiler configured to generate armv8 code by default (I
used --with-cpu=cortex-a57 for instance).
This is b
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Ramana Radhakrishnan
> Sent: Friday, January 23, 2015 6:35 PM
> To: Tony Liu
> Cc: gcc-patches; Ramana Radhakrishnan; Richard Earnshaw
> Subject: Re: [
On Thu, Jan 15, 2015 at 12:10 PM, Tony Liu wrote:
> Hi,
>
> This is the patch to improve the test case gcc.target/arm/scd42-1.c for both
> UAL and non-UAL. It now checks UAL format assembly code for Thumb1 and
> Thumb2 while non-UAL format assembly code for ARM mode.
OK.
Ramana
>
> With this pa
On 11.11.14 00:45, Mike Stump wrote:
On Nov 10, 2014, at 2:06 PM, Andreas Tobler wrote:
another one. Here I'm not really sure if there are EABI variants which do _not_
support these test cases.
I think the patch is fine, just watch for any follow-on comments from an
eabi/arm expert. Usuall
On Nov 10, 2014, at 2:06 PM, Andreas Tobler wrote:
> another one. Here I'm not really sure if there are EABI variants which do
> _not_ support these test cases.
I think the patch is fine, just watch for any follow-on comments from an
eabi/arm expert. Usually they are pretty responsive.
[ sorry for dup, if any ]
On Nov 10, 2014, at 1:12 PM, Andreas Tobler wrote:
> As I was told, arm*-*-symbianelf* should be EABI so we can use arm_eabi for
> all instead of listing each OS.
>
> Ok for trunk?
Ok.
On Nov 10, 2014, at 1:12 PM, Andreas Tobler wrote:
> As I was told, arm*-*-symbianelf* should be EABI so we can use arm_eabi for
> all instead of listing each OS.
>
> Ok for trunk?
Ok.
On Nov 9, 2014, at 12:33 PM, Andreas Tobler wrote:
> The upcoming FreeBSD ARM target does not have eabi in the target triplet. But
> it is EABI based.
> Ok for trunk?
Ok.
On 30 June 2014 09:03, Ramana Radhakrishnan wrote:
> + Move the tests to gcc.target/arm/ to gcc.target/aarch64 if the
> AArch64 maintainers agree. For the extra AArch64 variants guard them
> with #ifdef __aarch64__ #endif.
Given that the intrinsics in aarch64 are a superset of those in
aarch32
>> I'd rather drop the scan-assembler. I'm not convinced that the fragile
>> nature of this is required. Can you add a note to the README that says
>> that this is meant to be a complete execution test for the Advanced
>> SIMD intrinsics and does not cover all the assembler that is
>
> Sure.
>
>> g
On 27 June 2014 15:04, Christophe Lyon wrote:
> On 27 June 2014 14:52, Ramana Radhakrishnan wrote:
>> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
>> wrote:
>>>
>>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
>>> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unar
On 27 June 2014 14:55, Ramana Radhakrishnan wrote:
> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
> wrote:
>> vadd tests also show how to add directives to scan the assembly
>> output.
>>
>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
>> b/gcc/testsuite/gcc.target
On 27 June 2014 14:52, Ramana Radhakrishnan wrote:
> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
> wrote:
>>
>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
>> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
>> new file mode 100644
>> index 000..33f
On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
wrote:
> vadd tests also show how to add directives to scan the assembly
> output.
>
> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
> new file mode 100644
> i
On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
wrote:
>
> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
> new file mode 100644
> index 000..33f9b5f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/neo
On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
wrote:
> * documentation (README)
> * dejanu driver (neon-intrinsics.exp)
> * support macros (arm-neon-ref.h, compute-ref-data.h)
> * Tests for 2 intrinsics: vaba, vld1
>
> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/README
> b/gcc/te
On 11 June 2014 00:03, Ramana Radhakrishnan wrote:
> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
> wrote:
>> This is patch series is a more complete version of the patch I sent
>> some time ago:
>> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00624.html
>>
>> I have created a series of patc
On Jun 12, 2014, at 7:26 AM, Christophe Lyon wrote:
> On 12 June 2014 04:31, Mike Stump wrote:
>> On Jun 10, 2014, at 3:03 PM, Ramana Radhakrishnan
>> wrote:
>>> At this point I'm going to wait to see if any of the testsuite
>>> maintainers step in and comment
>>
>> [ ducks ] So, I wasn’t goin
On 12 June 2014 04:31, Mike Stump wrote:
> On Jun 10, 2014, at 3:03 PM, Ramana Radhakrishnan
> wrote:
>> I am a bit ambivalent between getting folks to add scan-assembler
>> tests here and worrying between this and getting the behaviour
>> correct. Additionally if you add the complexity of scann
On Jun 10, 2014, at 3:03 PM, Ramana Radhakrishnan
wrote:
> I am a bit ambivalent between getting folks to add scan-assembler
> tests here and worrying between this and getting the behaviour
> correct. Additionally if you add the complexity of scanning for
> aarch64 as well this starts getting mes
On 11 June 2014 00:03, Ramana Radhakrishnan wrote:
> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
> wrote:
>> This is patch series is a more complete version of the patch I sent
>> some time ago:
>> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00624.html
>>
>> I have created a series of patc
On 6 June 2014 22:15, Christophe Lyon wrote:
> On 6 June 2014 17:57, Ramana Radhakrishnan
> wrote:
>> On 06/06/14 15:40, Christophe Lyon wrote:
>>>
>>> On 6 June 2014 01:32, Joseph S. Myers wrote:
Have these been tested for both big and little endian (especially for
tests where m
On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
wrote:
> This is patch series is a more complete version of the patch I sent
> some time ago:
> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00624.html
>
> I have created a series of patches to help review. The 1st one adds
> some documentation, t
On 6 June 2014 17:57, Ramana Radhakrishnan wrote:
> On 06/06/14 15:40, Christophe Lyon wrote:
>>
>> On 6 June 2014 01:32, Joseph S. Myers wrote:
>>>
>>> Have these been tested for both big and little endian (especially for
>>> tests where memory layout matters - load / store / lane number tests -
On 06/06/14 15:40, Christophe Lyon wrote:
On 6 June 2014 01:32, Joseph S. Myers wrote:
Have these been tested for both big and little endian (especially for
tests where memory layout matters - load / store / lane number tests -
remembering that GNU C vector initializers always use array orderin
On 6 June 2014 01:32, Joseph S. Myers wrote:
> Have these been tested for both big and little endian (especially for
> tests where memory layout matters - load / store / lane number tests -
> remembering that GNU C vector initializers always use array ordering,
> which is not the same as the archi
Have these been tested for both big and little endian (especially for
tests where memory layout matters - load / store / lane number tests -
remembering that GNU C vector initializers always use array ordering,
which is not the same as the architecture-defined lane numbering for big
endian)?
-
On Sep 13, 2013, at 8:25 AM, Kyrill Tkachov wrote:
> gcc.target/arm/minmax_minus.c is really only valid when we have conditional
> execution available, that is non Thumb1-only targets. I've added an effective
> target check for that and used it in the test so that it does not get run and
> give
On 13/09/13 16:25, Kyrill Tkachov wrote:
Hi all,
gcc.target/arm/minmax_minus.c is really only valid when we have
conditional execution available, that is non Thumb1-only targets. I've
added an effective target check for that and used it in the test so that
it does not get run and give a false ne
On Jun 12, 2013, at 9:46 AM, Meador Inge wrote:
> This patch adds the needed 'dg-require-effective-target sync_*' lines to some
> of the atomic tests so that they will not be run if the appropriate atomic
> support is not available.
>
> OK for trunk?
Ok.
> 2013-06-12 Meador Inge
>
> *
Ping.
On 06/12/2013 11:46 AM, Meador Inge wrote:
> Hi All,
>
> This patch adds the needed 'dg-require-effective-target sync_*' lines to some
> of the atomic tests so that they will not be run if the appropriate atomic
> support is not available.
>
> OK for trunk?
>
> 2013-06-12 Meador Inge
>
On 12/04/13 15:19, Kyrylo Tkachov wrote:
Hi all,
This patch adds testsuite options to check for a neon-fp16
effective target and add appropriate options.
These are needed to test the half-precision NEON intrinsics that adding
with patch [1/2] of this set.
Tested on qemu with the tests added in p
Ping?
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 12 April 2013 15:19
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw; Ramana Radhakrishnan; mikest...@comcast.net
> Subject: [P
On Apr 5, 2013, at 7:05 AM, Ramana Radhakrishnan wrote:
> Ok by me but I'd like Mike to have another look.
Ok by me.
On 04/05/13 15:44, Kyrylo Tkachov wrote:
- -Original Message-
From: Ramana Radhakrishnan
Sent: 05 April 2013 15:06
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; mikest...@comcast.net
Subject: Re: [PATCH][ARM][testsuite] Fix testsuite options for testing
rounding vectorisation on ARMv8
- -Original Message-
> From: Ramana Radhakrishnan
> Sent: 05 April 2013 15:06
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; mikest...@comcast.net
> Subject: Re: [PATCH][ARM][testsuite] Fix testsuite options for testing
> rounding vectorisation on ARMv8
>
> O
On 04/05/13 14:06, Kyrylo Tkachov wrote:
Hi all,
With r197491 I added testsuite support for vectorisation of rounding
functions on ARMv8 NEON, but the options set up
for vect.exp results in the testsuite trying to test all the vect tests with
ARMv8 NEON which does not work on
ARMv7 targets and s
> -Original Message-
> From: Richard Earnshaw
> Sent: 17 December 2012 14:13
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan
> Subject: Re: [PATCH][ARM][testsuite] Add testsuite options for AArch32
> NEON
>
> On 11/12/12 12:30, Kyryl
On 11/12/12 12:30, Kyrylo Tkachov wrote:
Hi all,
Since the new AArch32 NEON instructions in arm_neon.h are predicated on
__ARM_ARCH 8 the testsuite add_options procedure should also include
-march=armv8-a to make these instructions available.
This makes the new vrnd* tests in gcc.target/arm/neo
Hi Richard,
On 21 September 2012 10:49, Richard Earnshaw wrote:
> On 21/09/12 09:47, Matthew Gretton-Dann wrote:
>> On 20 September 2012 23:06, Christophe Lyon
>> wrote:
>>> Hi,
>>>
>>> GCC for ARM does not support compiling in Thumb1 mode and
>>> float-abi=hard. But it does not fail unless
On 21 September 2012 10:47, Matthew Gretton-Dann
wrote:
> On 20 September 2012 23:06, Christophe Lyon
> wrote:
>> Hi,
>>
>> GCC for ARM does not support compiling in Thumb1 mode and
>> float-abi=hard. But it does not fail unless the program being
>> compiled actually contains a function with
On 21/09/12 09:47, Matthew Gretton-Dann wrote:
> On 20 September 2012 23:06, Christophe Lyon
> wrote:
>> Hi,
>>
>> GCC for ARM does not support compiling in Thumb1 mode and
>> float-abi=hard. But it does not fail unless the program being
>> compiled actually contains a function with parameters
On 20 September 2012 23:06, Christophe Lyon wrote:
> Hi,
>
> GCC for ARM does not support compiling in Thumb1 mode and
> float-abi=hard. But it does not fail unless the program being
> compiled actually contains a function with parameters and/or a return
> value.
>
> This is a (minor) problem i
On Sep 11, 2012, at 8:06 AM, Christophe Lyon wrote:
> Ping?
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00068.html
Since the arm people haven't rejected it… Ok.
Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00068.html
Thanks
Christophe.
On 3 September 2012 11:01, Christophe Lyon wrote:
> On 31 August 2012 18:14, Janis Johnson wrote:
>>
>> do something like
>>
>> /* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r0,\[\\t \]*r1,\[\\t
>> \]*d0" 2
On 31 August 2012 18:14, Janis Johnson wrote:
>
> do something like
>
> /* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r0,\[\\t \]*r1,\[\\t
> \]*d0" 2 } { target arm_little_endian } } */
> /* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r1,\[\\t \]*r0,\[\\t
> \]*d0" 2 } {target { ! arm
On 08/31/2012 05:05 AM, Christophe Lyon wrote:
> Hi,
>
> Tests gcc.target/arm/pr48252.c, gcc.target/arm/pr51835.c and
> gcc.target/arm/neon-vset_lanes8.c currently expect little-endian code
> and fail when compiled/executed in big-endian mode.
>
> The attached patch fixes them.
>
> Tested with
On 25 January 2012 20:55, Richard Henderson wrote:
> On 01/26/2012 02:35 AM, Greta Yorsh wrote:
>> Before the change, __sync_lock_release expanded into STRD, storing DI value
>> 0.
>
> The most important question is: Is STRD guaranteed to perform the store
> atomically? (And conversely, does LDR
On 01/26/2012 02:35 AM, Greta Yorsh wrote:
> Before the change, __sync_lock_release expanded into STRD, storing DI value 0.
The most important question is: Is STRD guaranteed to perform the store
atomically? (And conversely, does LDRD perform the load atomically?)
If so (even for a subset of arc
On 25 January 2012, at 18:14, Mike Stump wrote:
> On Jan 25, 2012, at 7:35 AM, Greta Yorsh wrote:
> > The test gcc.target/arm/di-longlong64-sync-withldrexd.c fails on
> > arm-none-eabi target, because gcc generates 48 LDREXD and 48 STREXD
> > instructions instead of the expected 46.
> >
> > FAIL: g
On Jan 25, 2012, at 7:35 AM, Greta Yorsh wrote:
> The test gcc.target/arm/di-longlong64-sync-withldrexd.c fails on
> arm-none-eabi target, because gcc generates 48 LDREXD and 48 STREXD
> instructions instead of the expected 46.
>
> FAIL: gcc.target/arm/di-longlong64-sync-withldrexd.c scan-assemble
1 - 100 of 103 matches
Mail list logo
