The test case assumes that alignof(int)=sizeof(int). But for some
targets this is not valid. For example, for PRU target,
alignof(int)=1 but sizeof(int)=4.
Fix the test case to align to twice the size of int, as the expected
dg-error messages suggest.
This patch fixes the test failures for PRU
On 2025-01-27 14:37, Christophe Lyon wrote:
On Mon, 27 Jan 2025 at 13:30, Torbjorn SVENSSON
wrote:
Hi Christophe,
On 2025-01-27 13:07, Christophe Lyon wrote:
Hi Torbjorn,
On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
wrote:
Another ping... :)
Kind regards,
Torbjörn
On 2024-12-18 1
On Mon, 27 Jan 2025 at 13:30, Torbjorn SVENSSON
wrote:
>
> Hi Christophe,
>
> On 2025-01-27 13:07, Christophe Lyon wrote:
> > Hi Torbjorn,
> >
> > On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
> > wrote:
> >>
> >> Another ping... :)
> >>
> >> Kind regards,
> >> Torbjörn
> >>
> >> On 2024-12-18
Hi Christophe,
On 2025-01-27 13:07, Christophe Lyon wrote:
Hi Torbjorn,
On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
wrote:
Another ping... :)
Kind regards,
Torbjörn
On 2024-12-18 18:35, Torbjorn SVENSSON wrote:
Gentle ping :)
Kind regards,
Torbjörn
On 2024-11-14 17:16, Torbjorn SVEN
Hi Torbjorn,
On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
wrote:
>
> Another ping... :)
>
> Kind regards,
> Torbjörn
>
> On 2024-12-18 18:35, Torbjorn SVENSSON wrote:
> > Gentle ping :)
> >
> > Kind regards,
> > Torbjörn
> >
> > On 2024-11-14 17:16, Torbjorn SVENSSON wrote:
> >>
> >>
> >> On 2
Gentle ping 🙂
Kind regards,
Torbjörn
On 2024-12-18 11:46, Torbjorn SVENSSON wrote:
On 2024-12-12 15:50, Richard Earnshaw (lists) wrote:
On 12/12/2024 13:36, Torbjorn SVENSSON wrote:
On 2024-12-12 12:26, Richard Earnshaw (lists) wrote:
On 10/11/2024 13:38, Torbjörn SVENSSON wrote:
Hi Ric
Another ping... :)
Kind regards,
Torbjörn
On 2024-12-18 18:35, Torbjorn SVENSSON wrote:
Gentle ping :)
Kind regards,
Torbjörn
On 2024-11-14 17:16, Torbjorn SVENSSON wrote:
On 2024-11-14 16:32, Christophe Lyon wrote:
On Fri, 8 Nov 2024 at 19:49, Torbjörn SVENSSON
wrote:
Ok for trunk and
Another ping... :)
Kind regards,
Torbjörn
On 2024-12-19 20:22, Torbjorn SVENSSON wrote:
Gentle ping :)
Kind regards,
Torbjörn
On 2024-11-14 17:32, Torbjorn SVENSSON wrote:
On 2024-11-14 16:26, Christophe Lyon wrote:
On Fri, 8 Nov 2024 at 18:54, Torbjörn SVENSSON
wrote:
Ok for trunk and
On 2025-01-24 18:17, Richard Earnshaw (lists) wrote:
On 19/01/2025 16:34, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Using -std=c17 avoids excess errors like:
.../thumb-bitfld1.c:15:1: warning: old-style function definition
[-Wold-style-definition]
gcc/testsuite/ChangeLog:
* gcc.t
On 19/01/2025 16:34, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> Using -std=c17 avoids excess errors like:
> .../thumb-bitfld1.c:15:1: warning: old-style function definition
> [-Wold-style-definition]
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/thumb-bitfld1.c: Use -std=c17
On 2025-01-24 18:07, Richard Earnshaw (lists) wrote:
On 24/01/2025 17:01, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
gcc/testsuite/ChangeLog:
PR testsuite/116448
* gcc.target/arm/vfp-1.c: Use -Os -fno-math-errno.
Signed-off-by: Torbjörn SVENSSON
---
g
On 24/01/2025 17:01, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> gcc/testsuite/ChangeLog:
>
> PR testsuite/116448
> * gcc.target/arm/vfp-1.c: Use -Os -fno-math-errno.
>
> Signed-off-by: Torbjörn SVENSSON
> ---
> gcc/testsuite/gcc.target/arm/vfp-1.c | 2
Ok for trunk and releases/gcc-14?
--
gcc/testsuite/ChangeLog:
PR testsuite/116448
* gcc.target/arm/vfp-1.c: Use -Os -fno-math-errno.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target/arm/vfp-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gc
On Thu, Jan 23, 2025 at 10:38 AM Rainer Orth
wrote:
>
> The new gcc.target/i386/cmov12.c test FAILs on Solaris/x86 with the
> native as:
>
> FAIL: gcc.target/i386/cmov12.c scan-assembler-times cmovg 3
>
> This happens because as uses a different syntax for cmov:
>
> --- cmov12.s.bu243 2025-01
On 2025-01-22 22:15, Mike Stump wrote:
On Jan 19, 2025, at 12:47 PM, Torbjorn SVENSSON
wrote:
On 2025-01-19 21:20, Andrew Pinski wrote:
On Sun, Jan 19, 2025 at 12:17 PM Torbjörn SVENSSON
wrote:
Ok for trunk?
--
Most baremetal toolchains will not have an implementation for alarm and
s
The new gcc.target/i386/cmov12.c test FAILs on Solaris/x86 with the
native as:
FAIL: gcc.target/i386/cmov12.c scan-assembler-times cmovg 3
This happens because as uses a different syntax for cmov:
--- cmov12.s.bu243 2025-01-21 16:55:27.038829605 +0100
+++ cmov12.s.bu243902025-01-21 16:5
On Jan 19, 2025, at 12:47 PM, Torbjorn SVENSSON
wrote:
>
> On 2025-01-19 21:20, Andrew Pinski wrote:
>> On Sun, Jan 19, 2025 at 12:17 PM Torbjörn SVENSSON
>> wrote:
>>>
>>> Ok for trunk?
>>>
>>> --
>>>
>>> Most baremetal toolchains will not have an implementation for alarm and
>>> sigaction
On Tue, Jan 21, 2025 at 04:28:59PM +0100, Georg-Johann Lay wrote:
> Am 18.01.25 um 19:30 schrieb Dimitar Dimitrov:
> > This test fails on AVR.
> >
> > Debugging the test on x86 host, I noticed that u in function s sometimes
> > has value 16128. The "t <= 3 * u" expression in the same function
> >
Am 18.01.25 um 19:30 schrieb Dimitar Dimitrov:
This test fails on AVR.
Debugging the test on x86 host, I noticed that u in function s sometimes
has value 16128. The "t <= 3 * u" expression in the same function
results in signed integer overflow for targets with sizeof(int)=16.
Fix by requiring
On Mon, Jan 20, 2025 at 08:10:31PM +, Simon Martin wrote:
> Successfully tested on x86_64-pc-linux-gnu with "make check-c++-all".
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp1z/constexpr-asm-5.C: Pass -fno-implicit-constexpr.
LGTM.
Jakub
that and I can merge it later today if that works
> for
> you.
Here’s the updated patch, successfully tested on x86_64-pc-linux-gnu
with “make check-c++-all”. OK?
Thanks, Simon
From eccf73af1b3555be3e02ea2f3b1ca0be32c81cc1 Mon Sep 17 00:00:00 2001
From: Simon Martin
Date: Mon, 20 Jan 2025 20
Hi Jakub,
On 20 Jan 2025, at 10:15, Jakub Jelinek wrote:
> On Mon, Jan 20, 2025 at 08:52:17AM +, Simon Martin wrote:
>> On 12 Jan 2025, at 12:10, Simon Martin wrote:
>>
>>> While testing an unrelated C++ patch with "make check-c++-all", I
>>> noticed that r15-6760-g38a13ea4117b96 added a test
On Mon, Jan 20, 2025 at 08:52:17AM +, Simon Martin wrote:
> On 12 Jan 2025, at 12:10, Simon Martin wrote:
>
> > While testing an unrelated C++ patch with "make check-c++-all", I
> > noticed that r15-6760-g38a13ea4117b96 added a test case that fails
> > with
> > -fimplicit-constexpr.
> >
> > T
Hi,
On 12 Jan 2025, at 12:10, Simon Martin wrote:
> While testing an unrelated C++ patch with "make check-c++-all", I
> noticed that r15-6760-g38a13ea4117b96 added a test case that fails
> with
> -fimplicit-constexpr.
>
> The problem is that this test unconditionally expects an error stating
> t
On 2025-01-19 21:20, Andrew Pinski wrote:
On Sun, Jan 19, 2025 at 12:17 PM Torbjörn SVENSSON
wrote:
Ok for trunk?
--
Most baremetal toolchains will not have an implementation for alarm and
sigaction as they are target specific.
For arm-none-eabi with newlib, function signatures are expose
On Sun, Jan 19, 2025 at 12:17 PM Torbjörn SVENSSON
wrote:
>
> Ok for trunk?
>
> --
>
> Most baremetal toolchains will not have an implementation for alarm and
> sigaction as they are target specific.
> For arm-none-eabi with newlib, function signatures are exposed, but
> there is no implmentation
Ok for trunk?
--
Most baremetal toolchains will not have an implementation for alarm and
sigaction as they are target specific.
For arm-none-eabi with newlib, function signatures are exposed, but
there is no implmentation and thus the test cases causes a undefined
symbol link error.
gcc/testsuit
Ok for trunk?
--
Using -std=c17 avoids excess errors like:
.../thumb-bitfld1.c:15:1: warning: old-style function definition
[-Wold-style-definition]
gcc/testsuite/ChangeLog:
* gcc.target/arm/thumb-bitfld1.c: Use -std=c17.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target
On Sat, Jan 18, 2025 at 07:06:16PM +, Sam James wrote:
> Dimitar Dimitrov writes:
>
> > This test fails on AVR.
> >
> > Debugging the test on x86 host, I noticed that u in function s sometimes
> > has value 16128. The "t <= 3 * u" expression in the same function
> > results in signed integer
Dimitar Dimitrov writes:
> This test fails on AVR.
>
> Debugging the test on x86 host, I noticed that u in function s sometimes
> has value 16128. The "t <= 3 * u" expression in the same function
> results in signed integer overflow for targets with sizeof(int)=16.
>
> Fix by requiring int32 eff
This test fails on AVR.
Debugging the test on x86 host, I noticed that u in function s sometimes
has value 16128. The "t <= 3 * u" expression in the same function
results in signed integer overflow for targets with sizeof(int)=16.
Fix by requiring int32 effective target.
Also add return stateme
ifcombine depends on BRANCH_COST and the testcase relies on ifcombine
to fully optimize the function. But the important parts are optimized
everywhere, so the following delectively XFAILs the less important part.
Tested on aarch64 and x86_64-unknown-linux-gnu, pushed.
PR testsuite/117958
On Jan 16, 2025, at 11:46 AM, Alexandre Oliva wrote:
>
> Since the machine-independent widening multiply logic was improved
> PR113560, ARM's wmul-[567].c fail. AFAICT the logic takes advantage
> of the fact that, after zero-extending a narrow integral type to a
> wider type, further zero- or si
On Jan 16, 2025, at 11:43 AM, Alexandre Oliva wrote:
>
> The regexp that matches options that mess with multilibs matches
> -mfloat=abi=, but that's probably a typo for -mfloat-abi=. Fix that,
> and add -msoft-float and -mhard-float.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-eabi
On Jan 16, 2025, at 11:42 AM, Alexandre Oliva wrote:
>
> Tests that include need to be skipped when libstdc++ is built
> in freestanding mode.
Ok.
> for gcc/testsuite/ChangeLog
>
> PR rtl-optimization/113994
> * g++.dg/pr113994.C: Require hosted libstdc++.
On Jan 9, 2025, at 10:25 PM, Alexandre Oliva wrote:
>
> dfp.exp sets the default to compile when dfprt is not available, but
> some dfp bitint tests override the default without that requirement,
> and try to run even when dfprt is not available.
>
> Instead of overriding the default, rewrite th
The regexp that matches options that mess with multilibs matches
-mfloat=abi=, but that's probably a typo for -mfloat-abi=. Fix that,
and add -msoft-float and -mhard-float.
Regstrapped on x86_64-linux-gnu, also tested on arm-eabi and
aarch64-elf. Ok to install?
for gcc/testsuite/ChangeLog
Since the machine-independent widening multiply logic was improved
PR113560, ARM's wmul-[567].c fail. AFAICT the logic takes advantage
of the fact that, after zero-extending a narrow integral type to a
wider type, further zero- or sign-extending is equivalent, which
enables different instruction
Tests that include need to be skipped when libstdc++ is built
in freestanding mode.
for gcc/testsuite/ChangeLog
PR rtl-optimization/113994
* g++.dg/pr113994.C: Require hosted libstdc++.
---
gcc/testsuite/g++.dg/torture/pr113994.C |1 +
1 file changed, 1 insertion(+)
dif
On Jan 10, 2025, Alexandre Oliva wrote:
> dfp.exp sets the default to compile when dfprt is not available, but
> some dfp bitint tests override the default without that requirement,
> and try to run even when dfprt is not available.
> Instead of overriding the default, rewrite the requirements s
On Tue, Jan 14, 2025 at 2:35 PM Richard Biener wrote:
>
> On Tue, 14 Jan 2025, Christoph Müllner wrote:
>
> > On Tue, Jan 14, 2025 at 1:46 PM Richard Biener wrote:
> > >
> > > On Tue, 14 Jan 2025, Christoph Müllner wrote:
> > >
> > > > As reported in PR117079, commit ab18785840d7b8 broke the test
On Tue, 14 Jan 2025, Christoph Müllner wrote:
> On Tue, Jan 14, 2025 at 1:46 PM Richard Biener wrote:
> >
> > On Tue, 14 Jan 2025, Christoph Müllner wrote:
> >
> > > As reported in PR117079, commit ab18785840d7b8 broke the test pr105493.c.
> > > When looking at the generated code, we can see that
On Tue, Jan 14, 2025 at 1:46 PM Richard Biener wrote:
>
> On Tue, 14 Jan 2025, Christoph Müllner wrote:
>
> > As reported in PR117079, commit ab18785840d7b8 broke the test pr105493.c.
> > When looking at the generated code, we can see that the generated code
> > is vectorized differently, resultin
On Tue, 14 Jan 2025, Christoph Müllner wrote:
> As reported in PR117079, commit ab18785840d7b8 broke the test pr105493.c.
> When looking at the generated code, we can see that the generated code
> is vectorized differently, resulting in a reduction from 225 instructions
> down to 109. On the perfo
As reported in PR117079, commit ab18785840d7b8 broke the test pr105493.c.
When looking at the generated code, we can see that the generated code
is vectorized differently, resulting in a reduction from 225 instructions
down to 109. On the performance side, no changes were measured on a 5950X.
This
On Mon, 13 Jan 2025 at 11:12, Thomas Schwinge wrote:
>
> Hi!
>
> On 2025-01-13T11:04:50+, Jonathan Wakely wrote:
> > On Mon, 13 Jan 2025 at 11:03, Thomas Schwinge
> > wrote:
> >> On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON
> >> wrote:
> >> > On 2025-01-12 01:05, Jonathan Wakely wrote:
Hi!
On 2025-01-13T11:04:50+, Jonathan Wakely wrote:
> On Mon, 13 Jan 2025 at 11:03, Thomas Schwinge wrote:
>> On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON
>> wrote:
>> > On 2025-01-12 01:05, Jonathan Wakely wrote:
>> >> On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
>> >> mailto:torbjorn.
On Mon, 13 Jan 2025 at 11:03, Thomas Schwinge wrote:
>
> Hi!
>
> On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON
> wrote:
> > On 2025-01-12 01:05, Jonathan Wakely wrote:
> >> On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
> >> mailto:torbjorn.svens...@foss.st.com>>
> >> wrote:
> >>
> >> Ok for
Hi!
On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON
wrote:
> On 2025-01-12 01:05, Jonathan Wakely wrote:
>> On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
>> mailto:torbjorn.svens...@foss.st.com>>
>> wrote:
>>
>> Ok for trunk and releases/gcc-14?
>>
>> OK
>
> Pushed as r15-6828-g4b0ef49d02
On 2024-11-19 15:01, Richard Earnshaw (lists) wrote:
On 18/11/2024 12:00, Christophe Lyon wrote:
Hi Torbjörn,
On 11/18/24 10:37, Torbjorn SVENSSON wrote:
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 S
While testing an unrelated C++ patch with "make check-c++-all", I
noticed that r15-6760-g38a13ea4117b96 added a test case that fails with
-fimplicit-constexpr.
The problem is that this test unconditionally expects an error stating
that a non-constexpr function is called, but that function is
auto-
On 2025-01-12 01:04, Jonathan Wakely wrote:
On Sat, 11 Jan 2025, 19:14 Torbjorn SVENSSON,
mailto:torbjorn.svens...@foss.st.com>>
wrote:
On 2025-01-11 20:05, Jonathan Wakely wrote:
>
>
> On Sat, 11 Jan 2025, 18:31 Torbjörn SVENSSON,
> mailto:torbjorn.svens...@fos
On 2025-01-12 01:05, Jonathan Wakely wrote:
On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
mailto:torbjorn.svens...@foss.st.com>>
wrote:
Ok for trunk and releases/gcc-14?
OK
Pushed as r15-6828-g4b0ef49d02f and r14.2.0-680-gd82fc939f91.
Kind regards,
Torbjörn
--
Test
On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
wrote:
> Ok for trunk and releases/gcc-14?
>
OK
> --
>
> Test assumes libatomic.a is always available, but for some embedded
> targets, there is no libatomic.a and the test thus fail.
>
> libstdc++/ChangeLog:
>
> * 29_atomics/atomic_float/
On Sat, 11 Jan 2025, 19:14 Torbjorn SVENSSON,
wrote:
>
>
> On 2025-01-11 20:05, Jonathan Wakely wrote:
> >
> >
> > On Sat, 11 Jan 2025, 18:31 Torbjörn SVENSSON,
> > mailto:torbjorn.svens...@foss.st.com>>
> > wrote:
> >
> > Ok for trunk and releases/gcc-14?
> >
> >
> > OK, thanks
>
> Oh, mid-a
Gentle ping :)
Kind regards,
Torbjörn
On 2024-12-23 20:00, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Test assumes libatomic.a is always available, but for some embedded
targets, there is no libatomic.a and the test thus fail.
libstdc++/ChangeLog:
* 29_atomics/ato
On 2025-01-11 20:05, Jonathan Wakely wrote:
On Sat, 11 Jan 2025, 18:31 Torbjörn SVENSSON,
mailto:torbjorn.svens...@foss.st.com>>
wrote:
Ok for trunk and releases/gcc-14?
OK, thanks
Oh, mid-air-collision.
Thanks for the fast review Jonathan!
I suppose my v2 should also be ok as it
Changes since v1:
- Found out that 27_io/print/3.cc has the same kind of issue.
Ok for trunk and releases/gcc-14?
--
When running tests using the "sim" config, the command is launched in
non-readonly mode and the text retrieved from the expect command will
then replace all LF with CRLF. (The pr
On Sat, 11 Jan 2025, 18:31 Torbjörn SVENSSON,
wrote:
> Ok for trunk and releases/gcc-14?
>
OK, thanks
> --
>
> When running tests using the "sim" config, the command is launched in
> non-readonly mode and the text retrieved from the expect command will
> then replace all LF with CRLF. (The pr
Ok for trunk and releases/gcc-14?
--
When running tests using the "sim" config, the command is launched in
non-readonly mode and the text retrieved from the expect command will
then replace all LF with CRLF. (The problem can be found in sim_load
where it calls remote_spawn without an input file).
On 2025-01-10 16:46, Richard Earnshaw (lists) wrote:
On 07/01/2025 20:16, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
a pattern is needed that uses PUSH/BL/POP sequence instead of a single
B instruction
On 07/01/2025 20:16, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
> a pattern is needed that uses PUSH/BL/POP sequence instead of a single
> B instruction to reuse an already existing function in the
On 2025-01-06 11:34, Jakub Jelinek wrote:
That looks incorrect to me.
ppc_ieee128_ok just means that one can use the __ieee128 type (and only if
-mfloat128 option is passed).
What the tests care is whether real(16) is IEEE128 or IBM128.
That is dependent on what glibc gcc has been configured agai
On 2025-01-10 11:27, Richard Earnshaw (lists) wrote:
On 22/12/2024 15:35, Torbjorn SVENSSON wrote:
On 2024-12-19 12:48, Richard Earnshaw (lists) wrote:
On 18/12/2024 16:24, Torbjörn SVENSSON wrote:
Changes since v1:
- Updated the commit message to reflect the changes (including the subje
On 22/12/2024 15:35, Torbjorn SVENSSON wrote:
>
>
> On 2024-12-19 12:48, Richard Earnshaw (lists) wrote:
>> On 18/12/2024 16:24, Torbjörn SVENSSON wrote:
>>> Changes since v1:
>>>
>>> - Updated the commit message to reflect the changes (including the subject).
>>> - Replaced the POP/BEQ checks wi
dfp.exp sets the default to compile when dfprt is not available, but
some dfp bitint tests override the default without that requirement,
and try to run even when dfprt is not available.
Instead of overriding the default, rewrite the requirements so that
they apply even when compiling, since the
On 2025-01-09 12:42, Richard Earnshaw (lists) wrote:
On 22/12/2024 15:27, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
When the test was initially created, -fcommon was the default, but in
commit r10-4867-g6271dd984d7 the default value changed to -fno-common.
This change ma
On 2025-01-09 12:56, Richard Earnshaw (lists) wrote:
On 27/12/2024 17:01, Torbjörn SVENSSON wrote:
Ok for trunk?
--
This change will enforce that the expected instructions are generated
per function rather than allowing some other function to use the
expected instructions.
gcc/testsuite/Ch
While writing the summary for my push of r15-6745-g794f6721e0e, I
noticed the following typo.
Pushed this patch as obivous.
--
gcc/testsuite/ChangeLog:
* gcc.target/arm/armv8_2-fp16-conv-1.c: Fix typo.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target/arm/armv8_2-fp16-con
On 27/12/2024 17:01, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> This change will enforce that the expected instructions are generated
> per function rather than allowing some other function to use the
> expected instructions.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/armv
On 27/12/2024 08:32, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> The implementation of the functions in the test case expects there to be
> a few arguments to the helper functions, but the prototype does not have
> any arguments at all. Align these to avoid these errors:
>
> .../pr59858.
On 22/12/2024 15:27, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> When the test was initially created, -fcommon was the default, but in
> commit r10-4867-g6271dd984d7 the default value changed to -fno-common.
> This change made the test start failing. To counter the ove
Ok for trunk and releases/gcc-14?
--
Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
a pattern is needed that uses PUSH/BL/POP sequence instead of a single
B instruction to reuse an already existing function in the compile unit.
gcc/testsuite/ChangeLog:
* gcc.targe
On 1/7/25 8:35 AM, Andreas Schwab wrote:
* lib/target-supports.exp
(check_effective_target_sync_char_short): Enable for riscv*-*-*.
I went ahead and pushed this as well.
Thanks again,
jeff
On 1/7/25 8:35 AM, Andreas Schwab wrote:
* lib/target-supports.exp
(check_effective_target_sync_char_short): Enable for riscv*-*-*.
OK
jeff
* lib/target-supports.exp
(check_effective_target_sync_char_short): Enable for riscv*-*-*.
---
gcc/testsuite/lib/target-supports.exp | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 5ce7b7976f9.
On Jan 6, 2025, at 3:05 PM, Alexandre Oliva wrote:
>
> On Dec 22, 2024, Alexandre Oliva wrote:
>
>> for gcc/testsuite/ChangeLog
>
>> PR testsuite/118025
>> * gcc.dg/field-merge-1.c: Convert constants to desired types.
>> * gcc.dg/field-merge-3.c: Likewise.
>> * gcc.dg/fiel
On Dec 22, 2024, Alexandre Oliva wrote:
> for gcc/testsuite/ChangeLog
> PR testsuite/118025
> * gcc.dg/field-merge-1.c: Convert constants to desired types.
> * gcc.dg/field-merge-3.c: Likewise.
> * gcc.dg/field-merge-4.c: Likewise.
> * gcc.dg/field-merge-5.c: Likew
On Mon, Jan 06, 2025 at 11:01:18AM -0500, Siddhesh Poyarekar wrote:
> Ping!
>
> On 2024-12-19 08:16, Siddhesh Poyarekar wrote:
> > Denormal behaviour is well defined for IEEE128 long doubles, so don't
> > XFAIL some gfortran tests on ppc64le when configured with the IEEE128
> > long double ABI.
>
Ping!
On 2024-12-19 08:16, Siddhesh Poyarekar wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* gfortran.dg/default_f
On Fri, Jan 03, 2025 at 05:48:12PM +, Matthew Malcomson wrote:
> On 1/3/25 17:14, Joseph Myers wrote:
> > Does this patch cover everything dealt with by
> > <https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672242.html>
> > ([PATCH] testsuite: libitm: Remov
242.html>
([PATCH] testsuite: libitm: Remove build directory path from test names),
or would some separate fix for that issue still be needed in the presence
of this patch?
--
Joseph S. Myers
josmy...@redhat.com
Does this patch cover everything dealt with by
<https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672242.html>
([PATCH] testsuite: libitm: Remove build directory path from test names),
or would some separate fix for that issue still be needed in the presence
of this patch?
--
Jo
Mike Stump writes:
> On Jan 2, 2025, at 4:00 PM, Sam James wrote:
>>
>> This testcase came up in a recent LLVM bug report [0] for DSE vs
>> -ftrivial-auto-var-init=. Add it to our testsuite given that area
>> could do with better coverage.
>>
>> [0] https://github.com/llvm/llvm-project/issues/
f71221 Mon Sep 17 00:00:00 2001
From: Matthew Malcomson
Date: Wed, 11 Dec 2024 11:03:55 +
Subject: [PATCH] testsuite: libitm: Adjust how libitm.c++ passes link flags
For the `gcc` and `g++` tools we often pass -B/path/to/object/dir in via
`TEST_ALWAYS_FLAGS` (see e.g. asan.exp where this is
On Jan 2, 2025, at 4:00 PM, Sam James wrote:
>
> This testcase came up in a recent LLVM bug report [0] for DSE vs
> -ftrivial-auto-var-init=. Add it to our testsuite given that area
> could do with better coverage.
>
> [0] https://github.com/llvm/llvm-project/issues/119646
>
> gcc/testsuite/Cha
This testcase came up in a recent LLVM bug report [0] for DSE vs
-ftrivial-auto-var-init=. Add it to our testsuite given that area
could do with better coverage.
[0] https://github.com/llvm/llvm-project/issues/119646
gcc/testsuite/ChangeLog:
* gcc.dg/torture/dse-trivial-auto-var-init.c:
a way of handling this without the second variable would be to
make libitm_finish check whether TEST_ALWAYS_FLAGS is set. If it isn't,
then it must be the second call to libitm_finish.
OK that way if you agree, or OK as-is if you think it's better.
Richard
> Have attached the adju
17 00:00:00 2001
From: Matthew Malcomson
Date: Wed, 11 Dec 2024 11:03:55 +
Subject: [PATCH] testsuite: libitm: Adjust how libitm.c++ passes link flags
For the `gcc` and `g++` tools we often pass -B/path/to/object/dir in via
`TEST_ALWAYS_FLAGS` (see e.g. asan.exp where this is set).
In
writes:
> From: Matthew Malcomson
>
> For the `gcc` and `g++` tools we often pass -B/path/to/object/dir in via
> `TEST_ALWAYS_FLAGS` (see e.g. asan.exp where this is set).
> In libitm.c++/c++.exp we pass that -B flag via the `tool_flags` argument
> to `dg-runtest`.
>
> Passing as the `tool_flags`
From: Matthew Malcomson
For the `gcc` and `g++` tools we often pass -B/path/to/object/dir in via
`TEST_ALWAYS_FLAGS` (see e.g. asan.exp where this is set).
In libitm.c++/c++.exp we pass that -B flag via the `tool_flags` argument
to `dg-runtest`.
Passing as the `tool_flags` argument means that th
Happy new year!
Sorry it took so long.
On Tue, Oct 15, 2024 at 12:49:49PM +0530, jeevitha wrote:
> Hi All,
> options by removing -mpower9-misc and -mvsx, which are enabled by default with
> -mdejagnu-cpu=power9. The has_arch_pwr9 check is also true with
> -mdejagnu-cpu=power9, so it has been remo
Ping!
please review.
Thanks & Regards
Jeevitha
On 15/10/24 12:49 pm, jeevitha wrote:
> Hi All,
>
> Removed powerpc*-*-* from the target test as it is always true. Simplified
> options by removing -mpower9-misc and -mvsx, which are enabled by default with
> -mdejagnu-cpu=power9. The has_arch_pwr
Ok for trunk?
--
This change will enforce that the expected instructions are generated
per function rather than allowing some other function to use the
expected instructions.
gcc/testsuite/ChangeLog:
* gcc.target/arm/armv8_2-fp16-conv-1.c: Convert
scan-assembler-times to check-f
Torbjörn SVENSSON writes:
> Ok for trunk?
>
> --
>
> The implementation of the functions in the test case expects there to be
> a few arguments to the helper functions, but the prototype does not have
> any arguments at all. Align these to avoid these errors:
I'd just -std=gnu17 for these (give
Ok for trunk?
--
The implementation of the functions in the test case expects there to be
a few arguments to the helper functions, but the prototype does not have
any arguments at all. Align these to avoid these errors:
.../pr59858.c: In function 're_search_internal':
.../pr59858.c:95:17: error:
Hello-
This patch helps tools like contrib/compare_tests work out of the box for the
libitm testsuite. Without this change, compare_tests complains if the test
runs being compared were in different build directories.
I just moved the -B argument from one place to another, so the command line
exec
Ok for trunk and releases/gcc-14?
--
Test assumes libatomic.a is always available, but for some embedded
targets, there is no libatomic.a and the test thus fail.
libstdc++/ChangeLog:
* 29_atomics/atomic_float/compare_exchange_padding.cc: Use
effective-target libatomic_available.
On Sun, Dec 22, 2024 at 08:59:00PM -0300, Alexandre Oliva wrote:
> Hello, Dimitar,
>
> On Dec 22, 2024, Dimitar Dimitrov wrote:
>
> > On Sat, Dec 21, 2024 at 02:28:33AM -0300, Alexandre Oliva wrote:
> >> On Dec 20, 2024, Jakub Jelinek wrote:
> >>
> >> > On Wed, Dec 18, 2024 at 12:59:11AM -0300
On 12/22/24 6:19 PM, Hans-Peter Nilsson wrote:
I could do it just for target mmix, but that wouldn't help other
simulator targets. Using different primes is deliberate.
Ok to commit?
-- >8 --
Running tests in parallel on my 4.5y+ old laptop made this
test time out: the test itself runs in 9m
1 - 100 of 1457 matches
Mail list logo
