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
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 (with -mfloat-abi=softfp/hard). That
leads to some complicated
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/
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/mve-vabs.c scan-assembler-times memmove 3
In PR PR target/116010, Andre
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-
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-int8x16.c: Add -mtune=cortex-m55
---
gcc/testsuite/gcc.ta
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}
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}
.L4:
sub ip, ip, #16
b
i
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.
>
>
After the recent c23, GCC complains because the testcase calls f()
with a parameter whereas the prototype has none.
gcc/testsuite/ChangeLog
* gcc.target/arm/mve/dlstp-loop-form.c: Fix f() prototype.
---
gcc/testsuite/gcc.target/arm/mve/dlstp-loop-form.c | 2 +-
1 file changed, 1 i
The v*_fp16_xN_1.c tests on Arm have been unstable since they were
added. This is not a problem with the tests themselves, or even the
patches that were added, but with the testsuite infrastructure. It
turned out that another set of dg- tests for fp16 were corrupting the
cached set of options us
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
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-assembler-times'.
---
Hi,
The `scan-assembler-times' quirk
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-i
data-intrinsics-assembly.c forces -march=armv6 using dg-add-options
arm_arch_v6, which implicitly adds -mfloat-abi=softfp.
However, for a toolchain configured for arm-linux-gnueabihf and
--with-arch=armv7-a, the testcase will fail when including arm_acle.h
(which includes stdint.h, which will fail
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
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
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 pass -mthumb as
needed too.
2021-05-19 Christophe Lyon
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,
>
>
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".
>
nd -mfloat-abi=hard may not
be used together".
Okay for trunk?
Thanks
Andrea
>From ac47dfed0230d9fe596d27331b04ef194633927d Mon Sep 17 00:00:00 2001
From: Andrea Corallo
Date: Thu, 26 Nov 2020 12:33:18 +0100
Subject: [PATCH] arm: [testsuite] fix lob tests for -mfloa
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
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 linker so that it emits a useful error message instead
of cr
Hi all,
There is a typo in the armv8.1-a and armv8.2-a effective target check
generators.
They are not actually used anywhere in the testsuite as far as I can tell, but
the fix is obvious.
Committing to trunk.
Thanks,
Kyrill
2018-01-17 Kyrylo Tkachov
* lib/target-supports.exp: Fix -ma
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__
_STORE_VEC): Likewise.
(PRE_LOAD): Likewise.
(POST_LOAD): Likewise.
(POST_LOAD_VEC): Likewise.
From c8743026e53429131e6677aaca7b0840ecc11e25 Mon Sep 17 00:00:00 2001
From: Charles Baylis
Date: Fri, 24 Nov 2017 16:24:18 +
Subject: [PATCH] [ARM] testsuite: force hardfp in
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,
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 testcase is compiled with -mfloat-abi=soft.
Tested on arm* co
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,
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 multilibs to test many configurations, I noticed several
changes in
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:42, Thomas Preudhomme wrote:
Hi,
We've decided to apply the following patch to ARM/embedded-6-branch.
Sorry, I meant ARM/embedded-5-branch.
Best regards,
Thomas
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,
Hi,
We've decided to apply the following patch to ARM/embedded-6-branch.
Best regards,
Thomas
--- Begin Message ---
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
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_
Hi,
ARMv6-M and ARMv8-M Baseline only support soft float ABI. Therefore, the
arm_arch_v8m_base add option should pass -mfloat-abi=soft, much like -mthumb is
passed for architectures that only support Thumb instruction set. This patch
adds -mfloat-abi=soft to both arm_arch_v6m and arm_arch_v8m_
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
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*.
---
diff --git a/gcc/testsuite/gcc.target/arm/vst1Q_laneu64-1.c
b/gcc/tes
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
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 force fpu=vfp via a pragma at the
beginning o
On 09/11/15 08:21, Thomas Preud'homme wrote:
[Forwarding to gcc-patches, doh!]
Best regards,
Thomas
[PATCH, ARM/testsuite] Fix thumb2-slow-flash-data.c failures.eml
Subject:
[PATCH, ARM/testsuite] Fix thumb2-slow-flash-data.c failures
From:
Thomas Preud'homme
Date:
09/11/15
[Forwarding to gcc-patches, doh!]
Best regards,
Thomas
--- Begin Message ---
Hi,
ARM-specific thumb2-slow-flash-data.c testcase shows 2 failures when running
for arm-none-eabi with -mcpu=cortex-m7:
FAIL: gcc.target/arm/thumb2-slow-flash-data.c (test for excess errors)
FAIL: gcc.target/arm/thu
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 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 -mcpu
option.
The test now appears as UNSUPPORTED in the
Hi all,
This patch adds -mfloat-abi=softfp to a couple of tests that check xscale
functionality
and an appropriate skipping directive.
This helps avoid "unimplemented Thumb-1 hard float ABI" errors when testing the
arm-none-linux-gnueabihf/-mthumb variant.
With this patch the two tests PASS on
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
Pinging this patch.
Thank you,
- 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 patc
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
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 because -mrestrict-it is on by default for arm
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 classified as unsupported rather
than FAIL.
Ok f
> -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
Ping
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On Behalf Of Tony Liu
Sent: Thursday, January 15, 2015 8:10 PM
To: gcc-patches@gcc.gnu.org
Cc: Ramana Radhakrishnan; Richard Earnshaw
Subject: [PATCH, ARM, testsuite] Improve scd42-1.c for
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.
With this patch, the test passes for both cases.
Thanks,
Tony
2015-01-15 Tony Liu
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.
Hi all,
another one. Here I'm not really sure if there are EABI variants which
do _not_ support these test cases.
My target succeeds with this patch.
Comments?
If no (comments), ok for trunk?
TIA,
Andreas
2014-11-10 Andreas Tobler
* g++.old-deja/g++.jason/enum6.C: Use arm_eabi
[ 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.
Hi all,
here a second chunk which uses arm_eabi instead of arm*-*-*eabi* and
arm*-*-symbianelf*.
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?
TIA,
Andreas
2014-11-10 Andreas Tobler
* gcc.target/arm/ea
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.
Hi,
the subject says it already.
The upcoming FreeBSD ARM target does not have eabi in the target
triplet. But it is EABI based.
Patching these test cases makes them work under arm*-*-freebsd*.
I have not tested them under arm*-*-*eabi*, yet.
If a kind sould could help me out here? Would be
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
The current set of flags used in this test cause issues with multilib
testing where there is no neon vs neon support. Thereby adding neon
specific flags through the proper interfaces.
Applied to trunk after testing on arm-none-eabi with a multilib target
list of {-marm/-march=armv7-a/-mfpu=vfp
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
1 - 100 of 171 matches
Mail list logo
