On 4/24/25 12:22 PM, Dimitar Dimitrov wrote:
Testcases for musttail call optimization fail on pru-unknown-elf:
FAIL: c-c++-common/musttail14.c -std=gnu++17 (test for excess errors)
Excess errors:
.../gcc/gcc/testsuite/c-c++-common/musttail14.c:37:14: error: cannot
tail-call: caller
>> * lib/target-supports.exp
>> (check_effective_target_variadic_mi_thunk): New function.
>OK.
>jeff
>
Please document new effective_target checks in sourcebuild.texi
thanks
On 4/24/25 12:23 PM, Dimitar Dimitrov wrote:
Some backends do not define TARGET_ASM_OUTPUT_MI_THUNK. But the generic
thunk support cannot emit code for calling variadic methods of
multiple-inheritance classes. Example error for pru-unknown-elf:
.../gcc/gcc/testsuite/g++.dg/ipa/pr83549.C:7
Some backends do not define TARGET_ASM_OUTPUT_MI_THUNK. But the generic
thunk support cannot emit code for calling variadic methods of
multiple-inheritance classes. Example error for pru-unknown-elf:
.../gcc/gcc/testsuite/g++.dg/ipa/pr83549.C:7:24: error: generic thunk code
fails for method 'v
Testcases for musttail call optimization fail on pru-unknown-elf:
FAIL: c-c++-common/musttail14.c -std=gnu++17 (test for excess errors)
Excess errors:
.../gcc/gcc/testsuite/c-c++-common/musttail14.c:37:14: error: cannot
tail-call: caller uses sjlj exceptions
Silence these errors by disabli
On Wed, 23 Apr 2025, Tamar Christina wrote:
> Hi All,
>
> I had missed this one during the AMDGCN test failures.
>
> Like vect-early-break_18.c this test is also scalaring the
> loads and thus leading to unexpected vectorization for this
> testcase.
>
> Bootstrapped Regtested on aarch64-none-li
Hi All,
I had missed this one during the AMDGCN test failures.
Like vect-early-break_18.c this test is also scalaring the
loads and thus leading to unexpected vectorization for this
testcase.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Cross checked the failing case on amdgc
Hi,
Thanks for fixing this. I just checked glibc, which implements
__sigsetjmp as:
# define sigsetjmp(env, savemask) __sigsetjmp (env, savemask)
So I would think this is fine. I leave the ack to the Jakub, Richard et
al, of course.
Thanks,
Jørgen
On 2025-04-22 10:33, Rainer Orth wrote:
T
On Tue, 22 Apr 2025, Rainer Orth wrote:
> The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin:
>
> FAIL: gcc.misc-tests/gcov-31.c (test for excess errors)
>
> Excess errors:
> /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5:
> error: implicit declaration of fu
The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin:
FAIL: gcc.misc-tests/gcov-31.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5:
error: implicit declaration of function '__sigsetjmp'; did you mean
'sigsetjmp'? [-Wimp
On Apr 10, 2025, at 6:38 AM, Christophe Lyon wrote:
>
> On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
>>
>>> From: Christophe Lyon
>>> Date: Thu, 10 Apr 2025 15:21:23 +0200
>>
>> Not sure why I'm CC:ed on this one, not being a maintainer
>> of the testsuite or targets where gcov tes
On 1/29/25 11:35 AM, Dimitar Dimitrov wrote:
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 sug
This test is 'dg-do compile', so require tls instead of tls_runtime.
This enables it on targets such as arm-none-eabi configured with
--enable-threads=no.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/constinit16.C: Require tls.
---
gcc/testsuite/g++.dg/cpp2a/constinit16.C | 2 +-
1 file chan
Since this test is a 'dg-do run', it requires tls_runtime rather than
just tls.
This makes the test UNSUPPORTED on targets such as arm-non-eabi,
instead of FAIL/UNRESOLVED because __aeabi_read_tp is not provided
(e.g. when GCC is configured with --enable-threads=no.
gcc/testsuite/ChangeLog:
On 4/11/25 1:08 PM, Alexandre Oliva wrote:
>
> gcc.target/powerpc/power11-3.c uses target_clones, that depends on
> ifunc. Require ifunc support.
This looks "obvious" to me.
The only systems we (IBM) have access to build and test on all have ifunc
support, so we clearly didn't hit this ourselve
On 4/16/25 12:27 AM, Alexandre Oliva wrote:
> Since that sort of broad change will presumably not make gcc-15 (it
> wouldn't fix a regression, not even the problem addressed by the
> upthread patch),
Yes, the patch to change powerpc64 -> powerpc64_hw is definitely a
gcc-16 patch.
> ...may I un
On 4/15/25 11:44 PM, Alexandre Oliva wrote:
> On Apr 15, 2025, Peter Bergner wrote:
>> I have verified the modified test case ICEs with the exact same
>> error as the original test case using the commit immediately
>> before the commit the fixed the ICE.
>
> Awesome, thanks! I hereby withdraw th
On Wed, 16 Apr 2025 at 16:14, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Wed, 16 Apr 2025 14:41:17 +0200
>
> > ping?
>
> Since you directed it at me and CC:ed the list; in case that
> was deliberate: I can only repeat "still ok", but I don't
> have approval rights to the test
> From: Christophe Lyon
> Date: Wed, 16 Apr 2025 14:41:17 +0200
> ping?
Since you directed it at me and CC:ed the list; in case that
was deliberate: I can only repeat "still ok", but I don't
have approval rights to the testsuite parts.
>
> On Thu, 10 Apr 2025 at 15:48, Hans-Peter Nilsson wrot
ping?
On Thu, 10 Apr 2025 at 15:48, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Thu, 10 Apr 2025 15:38:48 +0200
>
> > On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
> > >
> > > > From: Christophe Lyon
> > > > Date: Thu, 10 Apr 2025 15:21:23 +0200
> > >
> > > Not su
On 16/04/2025 08:57, Tamar Christina wrote:
Hi All,
The given test is intended to test vectorization of a strided access done by
having a step of > 1.
GCN target doesn't support load lanes, so the testcase is expected to fail,
other targets create a permuted load here which we then then reject.
On Wed, 16 Apr 2025, Tamar Christina wrote:
> Hi All,
>
> The given test is intended to test vectorization of a strided access done by
> having a step of > 1.
>
> GCN target doesn't support load lanes, so the testcase is expected to fail,
> other targets create a permuted load here which we then
Hi All,
The given test is intended to test vectorization of a strided access done by
having a step of > 1.
GCN target doesn't support load lanes, so the testcase is expected to fail,
other targets create a permuted load here which we then then reject.
However some GCN arch don't seem to support
On Apr 14, 2025, Peter Bergner wrote:
> diff --git a/gcc/testsuite/g++.dg/pr112822.C b/gcc/testsuite/g++.dg/pr112822.C
> -typedef __attribute__((altivec(vector__))) double co;
> +typedef double co __attribute__ ((vector_size (16)));
FWIW, I've tested this change on gcc-14 powerpc-elf and I confi
On Apr 14, 2025, Peter Bergner wrote:
> On 4/11/25 1:03 PM, Alexandre Oliva wrote:
>> gcc.dg/pr87600.h and gcc.dg/pr89313.c test for __powerpc__ and
>> __POWERPC__ to choose ppc register names, but ppc-elf defines neither;
>> it defines __PPC__, so test for that as well.
> Is there a reason why
On Apr 15, 2025, Peter Bergner wrote:
> On 4/14/25 11:35 PM, Alexandre Oliva wrote:
>>> That said, that should be done in a separate patch.
>>
>> *nod*. Do you mean you're going to make that change, that I should, or
>> that you hope someone else will? I'd rather avoid duplication, and this
>>
On Apr 15, 2025, Peter Bergner wrote:
> On 4/15/25 9:36 AM, Peter Bergner wrote:
>> So what ABI does powerpc-elf use and what does it mandate?
That's not for me to decide, but to me the patch that introduced
OS_MISSING_POWERPC64 and the PR106680 coversation suggests that enabling
-mpowerpc64 wit
On Apr 15, 2025, Peter Bergner wrote:
> On 4/14/25 11:30 PM, Alexandre Oliva wrote:
>> On Apr 14, 2025, Peter Bergner wrote:
>>
>>> This is an architecture independent test case, so I'm surprised this
>>> doesn't FAIL on non-powerpc targets since they don't know anything
>>> about altivec.
>>
On 4/14/25 11:30 PM, Alexandre Oliva wrote:
> On Apr 14, 2025, Peter Bergner wrote:
>
>> This is an architecture independent test case, so I'm surprised this
>> doesn't FAIL on non-powerpc targets since they don't know anything
>> about altivec.
>
> AFAICT we ignore attributes we don't know abou
On 4/15/25 9:36 AM, Peter Bergner wrote:
> On 4/15/25 12:01 AM, Alexandre Oliva wrote:
>> On Apr 14, 2025, Peter Bergner wrote:
>>
>>> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles.
>>
>> Oh, is that so? It seems to have been the case for quite a long time.
>> I can trivia
On 4/15/25 12:01 AM, Alexandre Oliva wrote:
> On Apr 14, 2025, Peter Bergner wrote:
>
>> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles.
>
> Oh, is that so? It seems to have been the case for quite a long time.
> I can trivially see that GCC 9 already did that, but it may
On 4/14/25 11:35 PM, Alexandre Oliva wrote:
>> That said, that should be done in a separate patch.
>
> *nod*. Do you mean you're going to make that change, that I should, or
> that you hope someone else will? I'd rather avoid duplication, and this
> is likely a somewhat involved change, since th
On Apr 14, 2025, Peter Bergner wrote:
> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles.
Oh, is that so? It seems to have been the case for quite a long time.
I can trivially see that GCC 9 already did that, but it may have been
around for much longer than that.
And TBH i
On Apr 14, 2025, Peter Bergner wrote:
> That said, I hate the name "powerpc64" and it should probably be
> renamed to "powerpc64_hw" to be more clear about what it's testing.
Yeah, that would make sense.
> That said, that should be done in a separate patch.
*nod*. Do you mean you're going to
On Apr 14, 2025, Peter Bergner wrote:
> This is an architecture independent test case, so I'm surprised this
> doesn't FAIL on non-powerpc targets since they don't know anything
> about altivec.
AFAICT we ignore attributes we don't know about.
I'd think the following fix should help them too.
On 4/11/25 1:05 PM, Alexandre Oliva wrote:
> Multiple tests on ilp32 get TARGET_POWERPC64 enabled by -mdejagnu-cpu
> options, but the results they expect are only attained without
> enabling it, so disable it explicitly.
[snip]
> diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-
On 4/11/25 1:04 PM, Alexandre Oliva wrote:
> --- a/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
> +++ b/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
> @@ -1,6 +1,6 @@
> /* { dg-do run { target ilp32 } } */
> /* { dg-options "-O2 -mpowerpc64" } */
> -/* { dg-require-effective-target has_arch_p
On 4/11/25 1:03 PM, Alexandre Oliva wrote:
> gcc.dg/pr87600.h and gcc.dg/pr89313.c test for __powerpc__ and
> __POWERPC__ to choose ppc register names, but ppc-elf defines neither;
> it defines __PPC__, so test for that as well.
Is there a reason why powerpc-*-elf doesn't define __powerpc__ or
__P
On 4/11/25 1:01 PM, Alexandre Oliva wrote:
> Like other ppc targets, powerpc-*-elf needs -Wno-psabi to compile
> gcc.dg/ipa/ipa-sra-19.c without an undesired warning about vector
> argument passing.
>
> Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
> x86_64-linux-x-powerpc-elf.
On 4/11/25 12:57 PM, Alexandre Oliva wrote:
> diff --git a/gcc/testsuite/g++.dg/pr112822.C b/gcc/testsuite/g++.dg/pr112822.C
> index a8557522467d7..9ec5707eb4c4d 100644
> --- a/gcc/testsuite/g++.dg/pr112822.C
> +++ b/gcc/testsuite/g++.dg/pr112822.C
> @@ -1,6 +1,8 @@
> /* PR tree-optimization/11282
On Mon, Apr 14, 2025 at 07:47:21PM +0200, Thomas Schwinge wrote:
> gcc/testsuite/
> * lib/gcc-dg.exp (${tool}_load): Polish 'dg-output-file' test
> logs.
> ---
> gcc/testsuite/lib/gcc-dg.exp | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite
Hi!
On 2025-04-13T17:15:05+0200, I wrote:
> On 2025-03-18T14:54:23+0100, Jakub Jelinek wrote:
>> The following patch offers [...] dg-output-file
>> directive where one can supply a text file with expected output
>
>> --- gcc/doc/sourcebuild.texi.jj 2025-03-11 09:18:21.750133577 +0100
>> +++
Hi!
On 2025-03-18T14:54:23+0100, Jakub Jelinek wrote:
> The following patch offers [...] dg-output-file
> directive where one can supply a text file with expected output
> --- gcc/doc/sourcebuild.texi.jj 2025-03-11 09:18:21.750133577 +0100
> +++ gcc/doc/sourcebuild.texi 2025-03-18 14:41:5
When late combine was enabled for x86_64 (r15-1735-ge62ea4fb8ffcab),
these 2 testcases start to xpass in a similar fashion as when late
combine was added and the testcase was updated for aarch64 not to
xfail them there.
Pushed as obvious after a test to make sure the testcase no longer xpass.
gcc.dg/pr87600.h and gcc.dg/pr89313.c test for __powerpc__ and
__POWERPC__ to choose ppc register names, but ppc-elf defines neither;
it defines __PPC__, so test for that as well.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for
The overriding of dg-do in gcc.target/powerpc/vec-mul.c I put there
last year didn't quite work. It needed the newly-added dg-do-if to
work the way I wished. Fix it, and simplify it.
While at that, I found out that when target matched, dg-do-if didn't
call dg-do correctly, because it dropped t
The gcc.target/powerpc/vec-cmpne.c and .../vec-cmpne-runnable.c tests
need both vsx and vmx support, but vsx is taken for granted, which
doesn't hold on ppc-elf. Add the appropriate requirements and
options.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerp
gcc.target/powerpc/vsx-builtin-7.c uses fewer xxpermdi insns than
expected on ilp32. Adjust.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/vsx-builtin-7.c: Adjust xxpermdi
gcc.target/powerpc/pr99708.c uses -mfloat128, and that causes the
usual "may not be fully supported" warning that we need to prune on
such tests. Tolerate it.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/Chang
Testing ppc-elf with -mhard-float conflicts with explicit -msoft-float
in gcc.target/powerpc/ppc-fma-6.c and gcc.target/powerpc/pr105334.c.
Skip these tests under -mhard-float.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gc
gcc.target/powerpc/pr92661.c expects and tolerates errors about dfp
builtins when dfp is not supported, but the C front end no longer
accepts calls of undeclared functions by default, even with -w.
Adding -fpermissive would do, but I thought it would be too broad, so
I went for -Wno-error=implici
gcc.target/powerpc/pr111449-1.c's expected results only come about
without strict alignment, so disable it explicitly.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/pr1114
gcc.target/powerpc/power11-3.c uses target_clones, that depends on
ifunc. Require ifunc support.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/power11-3.c: Require ifunc
gcc.target/powerpc/pr111380-2.c requires altivec to be enabled to hit
the expected option mismatch and inline error, so enable it after
checking for compiler support.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuit
Below power7, it seems to be more profitable to compress the
floating-point constants and use an additional fp register move to
"extend" it. Only at power7 and above do we keep the constants
separate and load them, getting to the expected 'fmr' count.
Regstrapped on powerpc64le-linux-gnu. Also
gcc.target/powerpc/pr67808.c in some cases expects both 128-bit long
double types to be defined, but -mlong-double-128 doesn't guarantee
that without -mfloat128 on targets that would get the IEEE128 type as
long double. Add -mfloat128 to ensure the desired IBM 128-bit
floating-point type is avai
gcc.target/powerpc/block-cmp-8.c is an execution test on ilp32. It
tests for support for the 64-bit ISA in the compiler, but not for the
ability to execute powerpc64 instructions, so the test fails on 32-bit
hardware. Require powerpc64 instead.
Regstrapped on powerpc64le-linux-gnu. Also teste
Multiple tests on ilp32 get TARGET_POWERPC64 enabled by -mdejagnu-cpu
options, but the results they expect are only attained without
enabling it, so disable it explicitly.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/tes
The implementation of the fe*except primitives in newlib sets the
FE_VXSOFT bit when raising FE_INVALID, and the test doesn't expect
that. Skip it: the tested builtin expansions are for glibc only
anyway.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-e
Like pr91323.c, pr52451.c fails on all powerpc variants (except where
already skipped), because it uses fcmpu even when qNaNs should flag FP
exceptions.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
Some ppc bfp tests use __ieee128 without ensuring it's available.
Require ppc_ieee128_ok, add -mfloat128 to get the type defined,
and tolerate the warning that this option may trigger.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
Like other ppc targets, powerpc-*-elf needs -Wno-psabi to compile
gcc.dg/ipa/ipa-sra-19.c without an undesired warning about vector
argument passing.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
The rs6000.md copysign3 expander requires the mode to satisfy
FLOAT128_IEEE_P, so requiring float128 on ppc for ifn_copysign
effective target is hopefully a close-enough approximation.
gcc.dg/fold-copysign-1.c and gcc.dg/pr55152-2.c fail on ppc-elf
without this.
Regstrapped on powerpc64le-linux
g++.dg/pr112822.C uses altivec vectors explicitly, but it expects this
feature to be enabled by default on targets that recognize the
attribute, which is not a given on older ppc cpus, where the compiler
recommends recompiling with -mvsx.
Since it's just a compilation test, we don't seem to need t
The test was designed to pass with thumb2, but code generation changed
with the introduction of Low Overhead Loops, so the test can fail if
one overrides the flags when running the testsuite.
In addition, useless subtract / extension instructions require -O2 to
remove them (-O is not sufficient),
Hi!
On Thu, 10 Apr 2025 at 19:13, Richard Earnshaw (lists)
wrote:
>
> On 10/04/2025 14:55, Christophe Lyon wrote:
> > All arm effective-targets using check_runtime use the "_hw" or
> > "_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1_lob_hw for
> > consistency.
> >
> > gcc/testsuite/Ch
On 10/04/2025 14:55, Christophe Lyon wrote:
> All arm effective-targets using check_runtime use the "_hw" or
> "_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1_lob_hw for
> consistency.
>
> gcc/testsuite/ChangeLog
>
> * lib/target-supports.exp: Rename arm_v8_1_lob_ok into
>
On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Thu, 10 Apr 2025 15:21:23 +0200
>
> Not sure why I'm CC:ed on this one, not being a maintainer
> of the testsuite or targets where gcov tests are exercised,
Because you fixed a problem in r13-4103-ge91d
All arm effective-targets using check_runtime use the "_hw" or
"_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1_lob_hw for
consistency.
gcc/testsuite/ChangeLog
* lib/target-supports.exp: Rename arm_v8_1_lob_ok into
arm_v8_1_lob_hw.
* gcc.target/arm/lob1.c: Likew
> From: Christophe Lyon
> Date: Thu, 10 Apr 2025 15:38:48 +0200
> On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
> >
> > > From: Christophe Lyon
> > > Date: Thu, 10 Apr 2025 15:21:23 +0200
> >
> > Not sure why I'm CC:ed on this one, not being a maintainer
> > of the testsuite or target
> From: Christophe Lyon
> Date: Thu, 10 Apr 2025 15:21:23 +0200
Not sure why I'm CC:ed on this one, not being a maintainer
of the testsuite or targets where gcov tests are exercised,
but FWIW: LGTM except for the two nits:
> ping?
>
> On Tue, 1 Apr 2025 at 22:37, Christophe Lyon
> wrote:
> >
ping?
On Tue, 1 Apr 2025 at 22:37, Christophe Lyon wrote:
>
> After commit r15-8947-g8ed2d5d219e999, which added new tests using
> gcov, the CI noticed failures because it was calling 'gcov' instead of
> $target-gcov.
>
> This is because the CI scripts override GXX_UNDER_TEST, but still run
> the
Hi,
as usual, I forgot to add -mabi=lp64d to the test case. This patch adds
it. Going to push as obvious.
Regards
Robin
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/autovec/pr116595.C: Add -mabi.
---
gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C | 2 +-
1 file changed, 1 in
On 06/04/2025 19:49, Christophe Lyon wrote:
The previous version of this test required arch v6+ (for sxth), and
the number of vmov depended on the float-point ABI (where softfp
needed more of them to transfer floating-point values to and from
general registers).
With this patch we require arch v
The previous version of this test required arch v6+ (for sxth), and
the number of vmov depended on the float-point ABI (where softfp
needed more of them to transfer floating-point values to and from
general registers).
With this patch we require arch v7-a, vfp FPU and -mfloat-abi=hard, we
also use
> Am 06.04.2025 um 09:44 schrieb Iain Sandoe :
>
> Tested on x86_64, aarch64, powerpc64le - Linux; x86_64, aarch64 Darwin,
> OK for trunk?
Ok
Richard
> thanks
> Iain
>
> --- 8< ---
>
> The discovered paths already include the multilib and so there is
> no need to add an extra library to
Tested on x86_64, aarch64, powerpc64le - Linux; x86_64, aarch64 Darwin,
OK for trunk?
thanks
Iain
--- 8< ---
The discovered paths already include the multilib and so there is
no need to add an extra library to COBOL_UNDER_TEST. Doing so makes
a duplicate, which causes test fails on Darwin, where
On 3/31/25 12:59 PM, Alexandre Oliva wrote:
For the same reasons that affect alpha and other targets,
gcc.dg/tree-ssa/ssa-dom-cse-2.c fails to be optimized to the expected
return statement: the array initializer is vectorized into pairs, and
DOM cannot see through that.
Add riscv*-*-* to the
Jakub Jelinek writes:
> On Thu, Mar 27, 2025 at 12:05:21AM +, Sam James wrote:
>> The test was being ignored because dg.exp looks for .C in g++.dg/.
>>
>> gcc/testsuite/ChangeLog:
>> PR middle-end/112938
>>
>> * g++.dg/strub-internal-pr112938.cc: Move to...
>> * g++.dg/strub-
On Wed, Mar 26, 2025 at 02:24:04PM +0100, Rainer Orth wrote:
> 2025-03-25 Rainer Orth
>
> gcc/testsuite:
> * c-c++-common/gomp/metadirective-device.c
> (dg-additional-options): Use on all x86 targets. Restrict to lp64.
> * c-c++-common/gomp/metadirective-target-device-1
Christophe Lyon writes:
> Since r15-7878-ge1c49f413c8, these tests appear as XPASS on aarch64,
> so we can remove the xfails introduced by r12-102-gf31ddad8ac8f11.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/guality/pr90074.c: Remove xfail for aarch64.
> * gcc.dg/guality/pr90716.c: Likew
On Fri, Mar 21, 2025 at 01:10:44PM +0100, Tobias Burnus wrote:
> I tried to match in dg-warning the whole string, including [-OpenMP], but it
> failed.
>
> I turned out that that was because of -fdiagnostics-urls ...
>
> Solution do what other testsuites do: Use -fdiagnostics-plain-output.
>
>
Ping? It's been a week:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679330.html
> Three tests FAIL on Solaris/x86 in similar ways:
>
> FAIL: gcc.target/i386/pr111673.c check-function-bodies advance
> FAIL: gcc.target/i386/pr82142a.c check-function-bodies assignzero
> FAIL: gcc.t
Recent syntactic fixes enabled the test, but the result was failing.
It turns out it was missing a space between the register arguments in
the scan-assembler-times directives.
gcc/testsuite/ChangeLog:
PR target/119556
* gcc.target/arm/short-vfp-1.c: Add missing spaces.
---
gcc/t
Some of the tests regressed with a fix for the vectorization of
shifts. The riscv cost models need to be adjusted to avoid the
unprofitable optimization. The failure of these tests has been known
since 2024-03-13, without a forthcoming fix, so I suggest we consider
it expected by now. Adjust t
> From: Alexandre Oliva
> Date: Mon, 31 Mar 2025 20:59:23 -0300
> On Mar 31, 2025, Jeff Law wrote:
>
> >> PR tree-optimization/110628
> >> * gcc.dg/tree-ssa/update-threading.c: XFAIL on riscv.
> > ?!? This is passing on my tester:
>
> Indeed, despite the lack of any activity in the PR that cou
Since r15-7878-ge1c49f413c8, these tests appear as XPASS on aarch64,
so we can remove the xfails introduced by r12-102-gf31ddad8ac8f11.
gcc/testsuite/ChangeLog:
* gcc.dg/guality/pr90074.c: Remove xfail for aarch64.
* gcc.dg/guality/pr90716.c: Likewise.
---
gcc/testsuite/gcc.dg/gu
On Wed, Apr 2, 2025 at 11:02 AM Rainer Orth
wrote:
>
> Ping? It's been a week:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679330.html
>
> > Three tests FAIL on Solaris/x86 in similar ways:
> >
> > FAIL: gcc.target/i386/pr111673.c check-function-bodies advance
> > FAIL: gcc.
After commit r15-8947-g8ed2d5d219e999, which added new tests using
gcov, the CI noticed failures because it was calling 'gcov' instead of
$target-gcov.
This is because the CI scripts override GXX_UNDER_TEST, but still run
the testsuite in-tree, and gcc-transform-out-of-tree only depends on
TESTING
On 4/1/25 8:03 AM, Kito Cheng wrote:
On Tue, Apr 1, 2025 at 12:47 PM Jeff Law wrote:
On 3/31/25 7:03 PM, Alexandre Oliva wrote:
On Mar 31, 2025, Jeff Law wrote:
I don't immediately see anything in this test or its history to
indicate it's only supposed to work for rv64.
It's the 64-b
On Tue, Apr 1, 2025 at 12:47 PM Jeff Law wrote:
>
>
>
> On 3/31/25 7:03 PM, Alexandre Oliva wrote:
> > On Mar 31, 2025, Jeff Law wrote:
> >> I don't immediately see anything in this test or its history to
> >> indicate it's only supposed to work for rv64.
> >
> > It's the 64-bit integral argument
On 31/03/2025 20:04, Christophe Lyon wrote:
> Recent syntactic fixes enabled the test, but the result was failing.
>
> It turns out it was missing a space between the register arguments in
> the scan-assembler-times directives.
>
> gcc/testsuite/ChangeLog:
>
> PR target/119556
> * gc
Some of the tests regressed with a fix for the vectorization of
shifts. The riscv cost models need to be adjusted to avoid the
unprofitable optimization. The failure of these tests has been known
since 2024-03-13, without a forthcoming fix, so I suggest we consider
it expected by now. Adjust th
On 3/31/25 1:01 PM, Alexandre Oliva wrote:
Some of the tests regressed with a fix for the vectorization of
shifts. The riscv cost models need to be adjusted to avoid the
unprofitable optimization. The failure of these tests has been known
since 2024-03-13, without a forthcoming fix, so I su
On 3/31/25 7:03 PM, Alexandre Oliva wrote:
On Mar 31, 2025, Jeff Law wrote:
I don't immediately see anything in this test or its history to
indicate it's only supposed to work for rv64.
It's the 64-bit integral argument rs1.
Right, but ISTM we ought to be able to handle a vector of 64bit i
On Mar 31, 2025, Jeff Law wrote:
> On 3/31/25 1:05 PM, Alexandre Oliva wrote:
>> The desired vw{add,sub}.wx instructions don't come up on rv32 for
>> the
>> first two functions, we get v{add,sub}.vx instead.
>> I suppose this is an oversight, and something about the test is
>> meant
>> for rv64
On Mar 31, 2025, Jeff Law wrote:
>> PR tree-optimization/110628
>> * gcc.dg/tree-ssa/update-threading.c: XFAIL on riscv.
> ?!? This is passing on my tester:
Indeed, despite the lack of any activity in the PR that could suggest
it's fixed in the trunk, it no longer fails in the trunk, only gcc-14
On 3/31/25 1:02 PM, Alexandre Oliva wrote:
The testcase makes the -march option conditional on rv64, and #errors
out if the desired CPU properties are not active. This makes the test
fail on rv32. Arrange to skip the test on rv32 instead, moving the
rv64 conditional.
Tested on x86_64-linux
On 3/31/25 1:00 PM, Alexandre Oliva wrote:
The failure to adjust estimated profiling frequencies in reassoc noted
in PR110628 affects riscv as well. Add it to the XFAIL set.
Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?
for gcc/testsuite/ChangeLog
Christophe Lyon writes:
> Recent syntactic fixes enabled the test, but the result was failing.
>
> It turns out it was missing a space between the register arguments in
> the scan-assembler-times directives.
Great find, thanks.
>
> gcc/testsuite/ChangeLog:
>
> PR target/119556
> * g
1 - 100 of 1640 matches
Mail list logo
