On 2024-03-01 15:58, Richard Earnshaw (lists) wrote:
On 19/02/2024 09:13, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-13?
Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
Jakub has just pu
Ping!
Kind regards,
Torbjörn
On 2024-02-22 09:51, Torbjorn SVENSSON wrote:
Ping!
Kind regards,
Torbjörn
On 2024-02-07 17:21, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport 3cbab07b08d2f3a3ed34b6ec12e67727c59d285c to
releases/gcc-13?
Without this backport, I see these failures on
On 2024-03-12 14:21, Jason Merrill wrote:
On 3/11/24 06:23, Torbjörn SVENSSON wrote:
Changes compared to v1:
- Added reference to r14-6517-gb7e4a4c626e in dg-bogus comment
- Changed arm-*-* to short_enums in target selector
- Updated commit message to align with above changes
As the entire
Ping!
Kind regards,
Torbjörn
On 2024-03-08 10:14, Torbjorn SVENSSON wrote:
Ping!
Kind regards,
Torbjörn
On 2024-02-22 09:51, Torbjorn SVENSSON wrote:
Ping!
Kind regards,
Torbjörn
On 2024-02-07 17:21, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport
Ping!
Kind regards,
Torbjörn
On 2024-03-10 18:26, Torbjörn SVENSSON wrote:
Ok for trunk?
--
As the tests assume that strndup() is visible (only part of
POSIX.1-2008) define the guard to ensure that it's visible. Currently,
glibc appears to always have this defined in C++, newlib does not.
W
On 2024-03-17 18:48, Mike Stump wrote:
On Mar 10, 2024, at 10:26 AM, Torbjörn SVENSSON
wrote:
Ok for trunk?
Ok.
Pushed as basepoints/gcc-14-9513-g58753dba800 to trunk.
Kind regards,
Torbjörn
Ping!
Kind regards,
Torbjörn
On 2024-03-25 15:59, Yvan ROUX - foss wrote:
Ping!
Rgds,
Yvan
From: Torbjorn SVENSSON - foss
Sent: Friday, March 15, 2024 11:32 AM
To: David Malcolm; Alexandre Oliva
Cc: gcc-patches@gcc.gnu.org; Yvan ROUX - foss
Subject
Hi,
Is it okay to backport b7e4a4c626eeeb32c291d5bbbaa148c5081b6bfd to
releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL:
gcc.dg/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c
(test for excess errors)
FAIL: gcc.dg/analyzer/null-deref-pr108251-
Hi,
Is it okay to backport 3cbab07b08d2f3a3ed34b6ec12e67727c59d285c to
releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL: gcc.dg/analyzer/switch-enum-1.c (test for bogus messages, line 26)
FAIL: gcc.dg/analyzer/switch-enum-1.c (test for bogus messages, line
Hi,
Is it okay to backport 71804526d3a71a8c0f189a89ce3aa615784bfd8b to
releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL: g++.dg/contracts/contracts-ctor-dtor2.C(test for errors, line 23)
FAIL: g++.dg/contracts/contracts-ctor-dtor2.C(test for errors,
Hi,
Is it okay to backport 6e15e4e1abed02443a27a69455f4bfa49457c99e to
releases/gcc-13?
Without this backport, I see this failure on arm-none-eabi:
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C output pattern test
Kind regards,
Torbjörn
On 2023-11-26 03:57, Andrew Pinski wrote:
Since co
Hi,
Is it okay to backport 0d24289d129639efdc79338a64188d6d404375e8 to
releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL: g++.dg/warn/Wuse-after-free3.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/Wuse-after-free3.C -std=gnu++17 (test for excess
Hi,
Is it okay to backport e39b3e02c27bd771a07e385f9672ecf1a45ced77 to
releases/gcc-13?
Without this backport, I see this failure on arm-none-eabi:
FAIL: 23_containers/vector/bool/110807.cc (test for excess errors)
Kind regards,
Torbjörn
On 2023-11-09 02:22, Jonathan Wakely wrote:
On Th
Hi,
Is it okay to backport 62b29347c38394ae32858f2301aa9aa65205984e,
2a4d9e4f533c77870cc0eb60fbbd8047da4c7386 and
ba0cde8ba2d93b7193050eb5ef3cc6f7a2cdfe61 to releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL: 29_atomics/atomic/compare_exchange_padding.cc (te
On 2024-02-07 18:13, Andrew Pinski (QUIC) wrote:
-Original Message-
From: Torbjorn SVENSSON
Sent: Wednesday, February 7, 2024 8:23 AM
To: Andrew Pinski (QUIC) ; gcc-
patc...@gcc.gnu.org
Cc: Yvan Roux
Subject: Re: [PATCH 1/2] Fix contracts-tmpl-spec2.C on targets where plain
char is
On 2024-02-07 17:33, Jonathan Wakely wrote:
On Wed, 7 Feb 2024 at 16:31, Torbjorn SVENSSON
mailto:torbjorn.svens...@foss.st.com>>
wrote:
Hi,
Is it okay to backport 62b29347c38394ae32858f2301aa9aa65205984e,
2a4d9e4f533c77870cc0eb60fbbd8047da4c73
On 2024-02-07 20:46, Jason Merrill wrote:
On 2/7/24 11:22, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport 71804526d3a71a8c0f189a89ce3aa615784bfd8b to
releases/gcc-13?
OK.
Pushed as eae51472f68d9f922aa3a1a636f81467bfdae87a.
On 2024-02-09 01:07, Mike Stump wrote:
On Feb 8, 2024, at 9:44 AM, Torbjörn SVENSSON
wrote:
Changes since v1:
- Replaced .* with [^\r\n]* to avoid matching newline.
Ok for trunk and releases/gcc-13?
Ok.
Pushed as 1175d1b35ce7bf8ee7c9b37b334370f01eb95335 and
810b0b3f75c454da3f6b572287
On 2024-02-07 17:36, Jonathan Wakely wrote:
On Wed, 7 Feb 2024 at 16:25, Torbjorn SVENSSON
mailto:torbjorn.svens...@foss.st.com>>
wrote:
Hi,
Is it okay to backport e39b3e02c27bd771a07e385f9672ecf1a45ced77 to
releases/gcc-13?
It would als
Hi,
Is it okay to backport 2f20d6296087cae51f55eeecb3efefe786191fd6 to
releases/gcc-13?
Without this backport, I see about 150 failures on arm-none-eabi, an
example of them is:
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s000.c (test for excess errors)
Kind regards,
Torbjörn
On 2023-05-24 11:02, Ri
On 2024-02-09 11:34, Richard Biener wrote:
On Fri, Feb 9, 2024 at 11:33 AM Torbjorn SVENSSON
wrote:
Hi,
Is it okay to backport 2f20d6296087cae51f55eeecb3efefe786191fd6 to
releases/gcc-13?
Yes.
Pushed as 5b3dcff46780192a2e526bc434d61c8626898050.
On 2024-02-09 19:57, Jason Merrill wrote:
On 2/7/24 11:24, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport 0d24289d129639efdc79338a64188d6d404375e8 to
releases/gcc-13?
OK.
Pushed as 583bd84075d23cde5fd489ab726093060870d773.
On 2024-02-11 20:01, Mike Stump wrote:
On Feb 10, 2024, at 7:21 AM, Torbjörn SVENSSON
wrote:
I have confirmed that this updated pr97969.c file still hangs with
gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969.
Ok for trunk?
Ok.
Pushed as f85450819414700a7883a7de
On 2024-02-15 18:18, Mike Stump wrote:
On Feb 15, 2024, at 9:03 AM, Torbjörn SVENSSON
wrote:
Ok for trunk?
Ok.
Pushed as 8e8c2d2b34971bb29e74341a3efc625f1db06639.
gcc/testsuite/ChangeLog:
PR113278
* c-c++-common/analyzer/fileno-1.c: Define _POSIX_SOURCE.
* c
Ping!
Kind regards,
Torbjörn
On 2024-02-07 17:21, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport 3cbab07b08d2f3a3ed34b6ec12e67727c59d285c to
releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL: gcc.dg/analyzer/switch-enum-1.c (test for bogus messages
Ping!
Kind regards,
Torbjörn
On 2024-02-07 17:19, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport b7e4a4c626eeeb32c291d5bbbaa148c5081b6bfd to
releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL:
gcc.dg/analyzer/null-deref-pr108251
On 2024-07-10 18:41, Richard Earnshaw (lists) wrote:
On 10/07/2024 17:26, Torbjörn SVENSSON wrote:
Is this ok for the following branches?
- trunk
- releases/gcc-14
- releases/gcc-13
--
Since r13-1006-g2005b9b888eeac, the test case copysign_softfloat_1.c
no longer contains any lsr istruction,
On 2024-07-19 16:36, Richard Earnshaw (lists) wrote:
On 19/07/2024 14:07, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
On Cortex-A7 with -mfloat-abi=hard and -mfpu=neon, the following
instructions are generated for the test case:
vldrd16, .L3
vst1.32
Hi,
I'm not sure if the previous "ok" from Richard on the v1 is enough for
this or if there needs another approval.
Adding extra maintainers since Richard Earnshaw appears to be busy the
past weeks.
Kind regards,
Torbjörn
On 2024-05-06 13:50, Torbjorn SVENSSON wrote:
Gentle ping!
Kind regards,
Torbjörn
On 2024-05-14 13:01, Torbjorn SVENSSON wrote:
Hi,
I'm not sure if the previous "ok" from Richard on the v1 is enough for
this or if there needs another approval.
Adding extra maintainers since Richard Earnshaw appears to be busy the
pas
Kind regards,
Torbjörn
On 2024-05-22 12:55, Richard Earnshaw (lists) wrote:
On 06/05/2024 12:50, Torbjorn SVENSSON wrote:
Hi,
Forgot to mention when I sent the patch that I would like to commit it to the
following branches:
- releases/gcc-11
- releases/gcc-12
- releases/gcc-13
- releases/gcc-14
-
cc-12: d9c89402b54be4c15bb3c7bcce3465f534746204
releases/gcc-11: 08ca81e4b49bda153d678a372df7f7143a94f4ad
Kind regards,
Torbjörn
On 2024-05-22 13:54, Richard Earnshaw (lists) wrote:
On 22/05/2024 12:14, Torbjorn SVENSSON wrote:
Hello Richard,
Thanks for the reply.
From my point of view, at least the -fshort-
On 2024-08-16 16:07, Jeff Law wrote:
On 8/16/24 4:12 AM, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
Verified this on x86_64 and arm-none-eabi.
Don't know if the other "truth type" dg-lines can be removed as well.
--
On Cortex-M55 with MVE, the test case fails due to -INT_
On 2024-08-16 16:37, Jakub Jelinek wrote:
On Fri, Aug 16, 2024 at 04:15:10PM +0200, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
The test case assumes that sizeof(tree_code) >= 2. On some targets, like
Cortex-M on arm-none-eabi, -fshort-enums is enabled by default and in
th
On 2024-08-16 16:45, Jakub Jelinek wrote:
On Fri, Aug 16, 2024 at 03:51:01PM +0200, Torbjörn SVENSSON wrote:
gcc/testsuite/ChangeLog:
* g++.dg/warn/pr33738.C: Added -fno-short-enums.
* g++.dg/warn/pr33738-2.C: Duplicate g++.dg/warn/pr33738.C with
-fshort-enums and rem
On 2024-08-20 14:37, Tamar Christina wrote:
-Original Message-
From: Richard Biener
Sent: Tuesday, August 20, 2024 12:33 PM
To: Torbjorn SVENSSON
Cc: Jeff Law ; gcc-patches@gcc.gnu.org; Richard
Earnshaw ; quic_apin...@quicinc.com;
yvan.r...@foss.st.com; Tamar Christina
Subject: Re
Hi Andre,
Thanks for the review!
Please see my questions below.
On 2024-06-10 12:37, Andre Vieira (lists) wrote:
Hi Torbjorn,
Thanks for this, I have some comments below.
On 07/06/2024 09:56, Torbjörn SVENSSON wrote:
Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23
On 2024-06-11 16:00, Richard Earnshaw (lists) wrote:
On 10/06/2024 15:04, Torbjörn SVENSSON wrote:
For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.
gcc/testsuite/ChangeLog:
PR target/115253
* gcc.targe
On 2024-06-11 15:59, Richard Earnshaw (lists) wrote:
On 10/06/2024 15:04, Torbjörn SVENSSON wrote:
Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is an internal compiler error on Cortex-M23 for the
epilog pro
On 2024-07-19 17:22, Richard Earnshaw (lists) wrote:
On 19/07/2024 16:10, Torbjorn SVENSSON wrote:
On 2024-07-19 16:36, Richard Earnshaw (lists) wrote:
On 19/07/2024 14:07, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
On Cortex-A7 with -mfloat-abi=hard and -mfpu=neon
Gentle ping :)
As mentioned in the ticket, I would like to target this to trunk and
releases/gcc-14.
Kind regards,
Torbjörn
On 2024-07-15 12:16, Torbjörn SVENSSON wrote:
As the test case requires +-Inf and NaN to work and -ffast-math is added
by default for arm-none-eabi, re-enable non-finit
On 2024-07-23 09:59, Richard Biener wrote:
On Tue, 23 Jul 2024, Torbjorn SVENSSON wrote:
Gentle ping :)
As mentioned in the ticket, I would like to target this to trunk and
releases/gcc-14.
OK.
Richard.
Pushed as releases/gcc-14.1.0-331-ga544898f6dd and
basepoints/gcc-15-2224
Hi,
On 2024-04-24 17:55, Richard Ball wrote:
This patch makes the following changes:
1) When calling a secure function from non-secure code then any arguments
smaller than 32-bits that are passed in registers are zero- or
sign-extended.
2) After a non-secure function returns into secure co
Hi,
On 2024-04-25 16:25, Richard Ball wrote:
Hi Torbjorn,
Thanks very much for the comments.
I think given that the code that handles this, is within a
FOREACH_FUNCTION_ARGS loop.
It seems a fairly safe assumption that if the code works for one that it
will work for all.
To go back and add e
On 2024-04-30 17:11, Richard Earnshaw (lists) wrote:
On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
Add regression test to the existing zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
Test is done using -O0 to ensure the instructions are in
Hi,
Forgot to mention when I sent the patch that I would like to commit it
to the following branches:
- releases/gcc-11
- releases/gcc-12
- releases/gcc-13
- releases/gcc-14
- trunk
Kind regards,
Torbjörn
On 2024-05-02 12:50, Torbjörn SVENSSON wrote:
Add regression test to the existing zero
On 2024-09-03 20:23, Richard Biener wrote:
Am 03.09.2024 um 19:00 schrieb Tamar Christina :
Hi All,
The meaning of the testcase was changed by passing it -fwrapv. The reason for
the test failures on some platform was because the test was testing some
implementation defined behavior wrt
On 2024-09-05 01:02, Jeff Law wrote:
On 9/4/24 1:13 AM, Torbjorn SVENSSON wrote:
On 2024-09-03 20:23, Richard Biener wrote:
Am 03.09.2024 um 19:00 schrieb Tamar Christina
:
Hi All,
The meaning of the testcase was changed by passing it -fwrapv. The
reason for
the test failures
Hi,
Attached is a small patch that, in case of inline assembler code,
indicates that the function stack usage is uncertain due to inline
assembler.
The test suite are using "nop" as an assembler instruction on all
targets, is this acceptable or is there a better way to test this?
Patch has be
gcc.taget-tree).
Torbjörn
On 27/11/2018 19:40, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 26, 2018 at 02:02:49PM +, Torbjorn SVENSSON wrote:
>> Attached is a small patch that, in case of inline assembler code,
>> indicates that the function stack usage is uncertain due to
On 2024-10-08 01:30, Jonathan Yong wrote:
On 9/28/24 12:49, Torbjörn SVENSSON wrote:
Ok for trunk?
Changes since v1:
- Updated the commit message to mention the actual build error.
- Switch to checking the required define rather than the version
number of MinGW.
Patch looks OK to me.
T
On 2024-10-09 12:18, Richard Earnshaw (lists) wrote:
On 07/10/2024 20:04, Torbjorn SVENSSON wrote:
Hi Richard,
On 2024-10-07 12:45, Richard Earnshaw (lists) wrote:
On 07/10/2024 09:03, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Update test cases to use -mcpu=unset/-march=unset feature
Hello Andre,
Compared to a run without any of the 2 patches for PR 116444, I get this
diff:
--- base/m55hard/analysis.gcc2024-09-18 09:07:18.879493251 +
+++ pr116444/m55hard/analysis.gcc2024-10-05 11:44:05.261683071 +
+FAIL: gcc.target/arm/attr_thumb.c scan-assembler it
On 2024-10-07 10:53, Andre Vieira (lists) wrote:
Hi Torbjorn,
On 07/10/2024 09:08, Torbjorn SVENSSON wrote:
There are 3 test cases that are fixed with these 2 commits, but there
is also a bunch that is marked as new fails.
Looking at the test cases that fail, there are 2 different kinds
Hi Richard,
On 2024-10-07 12:45, Richard Earnshaw (lists) wrote:
On 07/10/2024 09:03, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Update test cases to use -mcpu=unset/-march=unset feature introduced in
r15-3606-g7d6c6a0d15c.
The acronym ET isn't one I recognize - I'm guessing you intend it to
Gentle ping :)
Kind regards,
Torbjörn
On 2024-09-28 14:49, Torbjörn SVENSSON wrote:
Ok for trunk?
Changes since v1:
- Updated the commit message to mention the actual build error.
- Switch to checking the required define rather than the version number of
MinGW.
--
The define ENABLE_VIRTUAL
Hello Andre,
On 2024-10-18 17:53, Andre Vieira (lists) wrote:
Sorry for the delay, some other work popped up in between and this had
some latent issues. They should all be addressed now in this new patch.
When not dealing with the special armv8.1-m.main conditional
instructions case make sur
Gentle ping :)
Kind regards,
Torbjörn
On 2024-10-13 19:50, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
Changes since v1:
- Dropped changes to dg- instructions. These will be addressed in a separate
set of patches later.
--
Some of the test cases were scanning for "bti", but
On 2024-10-22 13:34, Richard Earnshaw (lists) wrote:
On 20/10/2024 16:45, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Converted the tests to use check-function-bodies in order to ensure that
the sequence is correct.
This also allows both APSR_nzcvq and APSR_nzcvqg as targe
On 2024-10-22 13:37, Richard Earnshaw (lists) wrote:
On 20/10/2024 16:49, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Below -O2, lsls/lsrs are prefered. For -O2 and above, lsl/lsr are
prefered.
gcc/testsuite/ChangeLog:
* gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c
On 2024-10-22 13:36, Richard Earnshaw (lists) wrote:
On 20/10/2024 16:48, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Converted the tests to use check-function-bodies in order to ensure that
the sequence is correct.
gcc/testsuite/ChangeLog:
* gcc.target/arm/fp16-aapc
Gentle ping :)
Kind regards,
Torbjörn
On 2024-10-13 19:37, Torbjörn SVENSSON wrote:
Ok for trunk?
--
With the changes in r15-1579-g792f97b44ff, the constants have been
updated. This patch aligns the constants in the test cases with the
updated implementation.
gcc/testsuite/ChangeLog:
Hi Christophe,
On 2024-10-14 14:16, Christophe Lyon wrote:
Hi Torbjörn,
On 10/13/24 19:37, Torbjörn SVENSSON wrote:
Ok for trunk?
--
With the changes in r15-1579-g792f97b44ff, the constants have been
updated. This patch aligns the constants in the test cases with the
updated implementation.
On 2024-11-04 12:44, Richard Earnshaw (lists) wrote:
On 01/11/2024 19:18, Torbjorn SVENSSON wrote:
On 2024-11-01 19:40, Richard Earnshaw (lists) wrote:
On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
As these tests are set to execute and require neon
On 2024-11-04 17:03, Richard Earnshaw (lists) wrote:
On 31/10/2024 18:26, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Tests uses neon, so add effective-target arm_neon.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68620.c: Use effective-target arm_neon.
*
On 2024-11-04 14:37, Richard Earnshaw (lists) wrote:
On 04/11/2024 12:28, Torbjorn SVENSSON wrote:
On 2024-11-04 12:44, Richard Earnshaw (lists) wrote:
On 01/11/2024 19:18, Torbjorn SVENSSON wrote:
On 2024-11-01 19:40, Richard Earnshaw (lists) wrote:
On 24/10/2024 09:50, Torbjörn
On 2024-11-04 16:47, Richard Earnshaw (lists) wrote:
On 20/10/2024 16:51, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
The tests assume that a neon fpu is avialable and fails it not, so
explicitly require it.
diff --git a/gcc/testsuite/gcc.target/arm/attr-neon2.c
b/gcc/
On 2024-11-01 19:32, Richard Earnshaw (lists) wrote:
On 19/10/2024 19:11, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
The expected assembler in the test case assumes -marm, so explicily
require it.
gcc/testsuite/ChangeLog:
* gcc.target/arm/acle/data-intrinsics-as
On 2024-11-01 19:30, Richard Earnshaw (lists) wrote:
On 19/10/2024 18:23, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Similar to PR113502, but for non-aarch64 test.
The test started to fail after r14-7243-gafac1bd3365.
gcc/testsuite/ChangeLog:
* gcc.target/arm/ve
On 2024-11-04 16:51, Richard Earnshaw (lists) wrote:
On 31/10/2024 18:24, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
The test case is written in a way that it should be using hard float
ABI, but the use of -mfloat-abi=hard could be overriden by
dg-add-options arm_neon. En
On 2024-11-01 19:47, Richard Earnshaw (lists) wrote:
On 24/10/2024 20:12, Torbjörn SVENSSON wrote:
Ok for trunk?
--
With the changes in r15-1579-g792f97b44ff, the test_vmul_n_16x8 function
does not contain any vdup.16 q* r* instruction with -mfloat-abi=softfp.
The differnce between r15-157
On 2024-11-04 15:41, Richard Earnshaw wrote:
On 01/11/2024 18:40, Richard Earnshaw (lists) wrote:
On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
As these tests are set to execute and require neon hardware to do so,
add the missing dg-require-effective-ta
On 2024-11-05 16:37, Richard Earnshaw wrote:
On 05/11/2024 15:21, Richard Earnshaw (lists) wrote:
On 04/11/2024 20:34, Torbjorn SVENSSON wrote:
On 2024-11-04 17:03, Richard Earnshaw (lists) wrote:
On 31/10/2024 18:26, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Tests
On 2024-11-05 13:54, Richard Earnshaw (lists) wrote:
On 05/11/2024 07:49, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
The test case assumes that -mfp16-format=alternative is accepted for the
target, but not all targets support this flag. One such target is
Cortex-M85 that
On 2024-11-05 20:08, Richard Earnshaw (lists) wrote:
On 05/11/2024 18:26, Torbjörn SVENSSON wrote:
Changes since v1:
- Force arm_arch_v7a as a baseline for pr68620.c.
Ok for trunk and releases/gcc-14?
--
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68620.c: Use effective-target ar
On 2024-11-05 14:19, Christophe Lyon wrote:
Hi,
On Sat, 19 Oct 2024 at 19:20, Torbjörn SVENSSON
wrote:
With r15-1618-g9f168b412f4, I get the following asm generated for the test case:
.align 1
.align 2
.global test5
.syntax unified
.thumb
On 2024-11-01 19:40, Richard Earnshaw (lists) wrote:
On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
As these tests are set to execute and require neon hardware to do so,
add the missing dg-require-effective-target arm_neon_hw.
gcc/testsuite/ChangeLog:
On 2024-10-25 12:30, Richard Earnshaw (lists) wrote:
On 14/10/2024 13:23, Christophe Lyon wrote:
On 10/13/24 19:50, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
Changes since v1:
- Dropped changes to dg- instructions. These will be addressed in a separate
set of patches la
On 2024-11-08 15:30, Richard Earnshaw (lists) wrote:
On 14/10/2024 16:28, Christophe Lyon wrote:
On 10/14/24 16:40, Torbjorn SVENSSON wrote:
Hi Christophe,
On 2024-10-14 14:16, Christophe Lyon wrote:
Hi Torbjörn,
On 10/13/24 19:37, Torbjörn SVENSSON wrote:
Ok for trunk?
--
With the
On 2024-11-08 12:24, Richard Earnshaw (lists) wrote:
On 05/11/2024 20:06, Torbjörn SVENSSON wrote:
Based on how these functions are used in test cases, I think it's correct
to require 16-bit float support in both functions.
Without this change, the checks passes for armv8-m and armv8.1-m, bu
On 2024-11-11 13:43, Richard Biener wrote:
On Sun, Nov 10, 2024 at 2:55 PM Torbjörn SVENSSON
wrote:
Ok for trunk?
OK
Thanks Richard.
Pushed as r15-5104-ga2467372e72.
Kind regards,
Torbjörn
--
With the change in 15-3128-gde1923f9f4d, this test case no longer xfail.
gcc/testsuite/
On 2024-11-07 16:33, Richard Earnshaw (lists) wrote:
On 06/11/2024 19:50, Torbjorn SVENSSON wrote:
On 2024-11-06 19:06, Richard Earnshaw (lists) wrote:
On 06/11/2024 13:50, Torbjorn SVENSSON wrote:
On 2024-11-06 14:04, Richard Earnshaw (lists) wrote:
On 06/11/2024 12:23, Torbjorn
On 2024-11-06 12:26, Richard Earnshaw (lists) wrote:
On 06/11/2024 07:44, Christophe Lyon wrote:
On Wed, 6 Nov 2024 at 07:20, Torbjörn SVENSSON
wrote:
While the regression was reported on GCC15, I'm sure that same
regression will be seen on GCC14 when it's tested in the
arm-linux-gnueabihf
On 2024-11-07 11:40, Christophe Lyon wrote:
Hi Torbjörn,
On Thu, 31 Oct 2024 at 19:34, Torbjörn SVENSSON
wrote:
Ok for trunk and releases/gcc-14?
--
Test uses MVE, so add effective-target arm_fp requirement.
gcc/testsuite/ChangeLog:
* g++.target/arm/mve/general-c++/nomve_fp_1.
On 2024-11-06 14:04, Richard Earnshaw (lists) wrote:
On 06/11/2024 12:23, Torbjorn SVENSSON wrote:
On 2024-11-06 12:26, Richard Earnshaw (lists) wrote:
On 06/11/2024 07:44, Christophe Lyon wrote:
On Wed, 6 Nov 2024 at 07:20, Torbjörn SVENSSON
wrote:
While the regression was reported
On 2024-11-06 19:06, Richard Earnshaw (lists) wrote:
On 06/11/2024 13:50, Torbjorn SVENSSON wrote:
On 2024-11-06 14:04, Richard Earnshaw (lists) wrote:
On 06/11/2024 12:23, Torbjorn SVENSSON wrote:
On 2024-11-06 12:26, Richard Earnshaw (lists) wrote:
On 06/11/2024 07:44, Christophe
On 2024-11-07 23:14, Christophe Lyon wrote:
On Thu, 7 Nov 2024 at 19:09, Torbjorn SVENSSON
wrote:
On 2024-11-07 16:33, Richard Earnshaw (lists) wrote:
On 06/11/2024 19:50, Torbjorn SVENSSON wrote:
On 2024-11-06 19:06, Richard Earnshaw (lists) wrote:
On 06/11/2024 13:50, Torbjorn
On 2024-11-07 23:19, Christophe Lyon wrote:
On Thu, 7 Nov 2024 at 18:33, Torbjorn SVENSSON
wrote:
On 2024-11-07 11:40, Christophe Lyon wrote:
Hi Torbjörn,
On Thu, 31 Oct 2024 at 19:34, Torbjörn SVENSSON
wrote:
Ok for trunk and releases/gcc-14?
--
Test uses MVE, so add effective
On 2024-11-08 12:57, Richard Earnshaw (lists) wrote:
On 08/11/2024 11:48, Torbjörn SVENSSON wrote:
Changes since v1:
- Clarified the commit message to include where the descision is taken
and why it's a bad idea to use "dg-do run" in a test case.
Note: This does not only fix it for arm
On 2024-11-08 12:02, Richard Earnshaw (lists) wrote:
On 07/11/2024 17:15, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
When building the test case with neon, the 'vst1.32' instruction is used
instead of 'strd'. Allow both variants to make the test pass.
gcc/testsuite/Chang
On 2024-11-08 11:33, Richard Earnshaw (lists) wrote:
On 08/11/2024 08:54, Torbjörn SVENSSON wrote:
Changes since v1:
- Added generated assembler in commit message.
- Added comments in test case when each block is relevant.
Ok for trunk and releases/gcc-14?
This is OK. I'm not sure how u
On 2024-11-08 11:57, Richard Earnshaw (lists) wrote:
On 07/11/2024 17:48, Torbjörn SVENSSON wrote:
Changes since v1:
- Switch to arm_libc_fp_abi from arm_fp
@Christophe, can you test this patch in the linaro farm to ensure that
it does not fail again?
Ok for trunk and releases/gcc-14?
--
On 2024-11-19 18:57, Richard Earnshaw (lists) wrote:
On 19/11/2024 10:24, Torbjörn SVENSSON wrote:
Update test case to use -mcpu=unset/-march=unset feature introduced in
r15-3606-g7d6c6a0d15c.
gcc/testsuite/ChangeLog:
* gcc.target/arm/lto/pr96939_0.c: Use effective-target
ar
On 11/19/24 18:08, Richard Earnshaw (lists) wrote:
On 19/11/2024 10:24, Torbjörn SVENSSON wrote:
Update test cases to use -mcpu=unset/-march=unset feature introduced in
r15-3606-g7d6c6a0d15c.
gcc/testsuite/ChangeLog:
* g++.dg/other/pr56184.C: Use effective-target
arm_arch_v7
On 2024-11-19 18:51, Richard Earnshaw (lists) wrote:
On 19/11/2024 10:24, Torbjörn SVENSSON wrote:
The test case gcc.target/arm/its.c was created together with restriction
of IT blocks for Cortex-M7. As the test case fails on all tunes that
does not match Cortex-M7, explicitly test it for Cor
On 2024-11-19 14:42, Richard Earnshaw (lists) wrote:
On 18/11/2024 11:13, Torbjörn SVENSSON wrote:
Changes since v1:
- Replaced fragile checks on constants with check for literal pool
using "ldr r[0-9]+, \.L[0-9]+".
Ok for trunk?
--
With the changes in r15-1579-g792f97b44ff, the consta
On 2024-11-20 15:53, Richard Earnshaw (lists) wrote:
On 20/11/2024 13:00, Torbjorn SVENSSON wrote:
On 2024-11-19 18:57, Richard Earnshaw (lists) wrote:
On 19/11/2024 10:24, Torbjörn SVENSSON wrote:
Update test case to use -mcpu=unset/-march=unset feature introduced in
r15-3606
On 2024-11-08 18:44, Christophe Lyon wrote:
On Thu, 7 Nov 2024 at 18:05, Torbjörn SVENSSON
wrote:
Changes since v1:
- Updated the error message to mention that arm_mve_types.h needs to be
included.
- Corrected some spelling errors in commit message.
As the warning for pure functions re
On 2024-11-14 16:53, Christophe Lyon wrote:
On Sun, 10 Nov 2024 at 17:44, Torbjörn SVENSSON
wrote:
Ok for trunk and releases/gcc-14?
--
When the feature "needs_status_wrapper" in dejagnu is used, the
resulting gcc_tg.o file is a regular object file and thus the following
warning will be e
On 2024-11-08 20:37, Torbjorn SVENSSON wrote:
On 2024-11-08 12:24, Richard Earnshaw (lists) wrote:
On 05/11/2024 20:06, Torbjörn SVENSSON wrote:
Based on how these functions are used in test cases, I think it's
correct
to require 16-bit float support in both functions.
Without
1 - 100 of 212 matches
Mail list logo
