From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
bdad036da32 RISC-V: Support highpart register overlap for vwcvt
The below test suites are passed
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, April 24, 2024 2:46 PM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Robin Dapp ; Li,
Pan2
Subject: Re: [PATCH v1] RISC-V: Add xfail test case for highpart overlap of
vext.vf
LGTM
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-24 10:48
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for highpart overlap of vext.vf
From: Pan Li
We reverted below patch for register group overlap, add the related
From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
62685890d88 RISC-V: Support highpart overlap for vext.vf
The below test suites are passed
adding the same
>>> execution xfail marker to this test.
>
>> In my view, such an XFAIL (for a GCC bug as opposed to an environmental
>> issue) should have a comment pointing to a corresponding open bug in GCC
>> Bugzilla. In this case, that's bug 58684.
>
&g
on 2024/4/22 17:27, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566524.html
>
> The loop we're supposed to try to vectorize in
> gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset
> before the vectorizer runs.
>
> Various other tests
On Mar 10, 2021, Joseph Myers wrote:
> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>> operand exception for quiet NaN. I couldn't find any evidence that
>> the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same
>> execution xfail marker to this test.
> I
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566524.html
The loop we're supposed to try to vectorize in
gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset
before the vectorizer runs.
Various other tests in this set have already run into this, and the
solution
lgtm
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-22 16:27
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for highpart overlap
floating-point widen insn
From: Pan Li
We reverted below patch for register group overlap, add
From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
8614cbb2534 RISC-V: Support highpart overlap for floating-point widen
instructions
The below test
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-22 15:43
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v2] RISC-V: Add xfail test case for indexed load overlap with
SRC EEW < DEST EEW
From: Pan Li
Update in v2:
* Add change log to pr112431-3
From: Pan Li
Update in v2:
* Add change log to pr112431-34.c.
Original log:
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
4418d55bcd1 RISC-V: Support highpart
From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
4418d55bcd1 RISC-V: Support highpart overlap for indexed load with SRC EEW <
DEST EEW
The below t
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Monday, April 22, 2024 2:40 PM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Robin Dapp ; Li,
Pan2
Subject: Re: [PATCH v1] RISC-V: Add xfail test case for highest-number regno
ternary overlap
LGTM
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-22 14:35
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for highest-number regno
ternary overlap
From: Pan Li
We reverted below patch for register group overlap, add
From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
27fde325d64 RISC-V: Support highest-number regno overlap for widen ternary
The below test suites
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Monday, April 22, 2024 11:49 AM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Robin Dapp ; Li,
Pan2
Subject: Re: [PATCH v1] RISC-V: Add xfail test case for widening register
overlap of vf4/vf8
LGTM
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-22 11:19
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for widening register overlap
of vf4/vf8
From: Pan Li
We reverted below patch for register group overlap, add
From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
303195e2a6b RISC-V: Support widening register overlap for vf4/vf8
The below test suites are passed
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-21 13:01
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for highpart register overlap
of vx/vf widen
From: Pan Li
We reverted below patch for register group overlap, add
From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
a23415d7572 RISC-V: Support highpart register overlap for widen vx/vf
instructions
The below test
Committed, thanks Juzhe.
Pan
From: 钟居哲
Sent: Sunday, April 21, 2024 7:59 AM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; rdapp.gcc ; Li,
Pan2
Subject: Re: [PATCH v1] RISC-V: Add xfail test case for incorrect overlap on v0
lgtm
juzhe.zh...@rivai.ai
lgtm
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-20 23:21
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for incorrect overlap on v0
From: Pan Li
We reverted below patch for register group overlap, add the related
insn
From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
018ba3ac952 RISC-V: Fix overlap group incorrect overlap on v0
The below test suites are passed
Committed, thanks Robin.
Pan
-Original Message-
From: Robin Dapp
Sent: Saturday, April 20, 2024 7:46 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; kito.ch...@gmail.com
Subject: Re: [PATCH] RISC-V: Add xfail test case for wv insn highest
LGTM.
Regards
Robin
From: Pan Li
We reverted below patch for wv insn overlap, add the related wv
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
7e854b58084 RISC-V: Support highest overlap for wv instructions
The below test suites are passed
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Saturday, April 20, 2024 9:20 AM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Robin Dapp ; Li,
Pan2
Subject: Re: [PATCH v1] RISC-V: Add xfail test case for wv insn register overlap
LGTM.
juzhe.zh
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-20 09:04
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for wv insn register overlap
From: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112431-42.c: New
From: Pan Li
We reverted below patch for wv insn overlap, add the related wv
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
b3b2799b872 RISC-V: Support one more overlap for wv instructions
gcc/testsuite/ChangeLog
From: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112431-42.c: New test.
Signed-off-by: Pan Li
---
.../gcc.target/riscv/rvv/base/pr112431-42.c | 30 +++
1 file changed, 30 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base
Hi,
on 2024/4/17 13:12, HAO CHEN GUI wrote:
> Hi,
> This patch fixes loss of return statement in maxbcd of bcd-4.c. Without
> return statement, it returns an invalid bcd number and make the test
> noneffective. The patch also enables test to run on Power9 and Big Endian,
Hi,
This patch fixes loss of return statement in maxbcd of bcd-4.c. Without
return statement, it returns an invalid bcd number and make the test
noneffective. The patch also enables test to run on Power9 and Big Endian,
as all bcd instructions are supported from Power9.
Bootstrapped
FAIL: gcc.dg/vect/vect-early-break_124-pr114403.c execution test
FAIL: gcc.dg/vect/vect-early-break_124-pr114403.c -flto -ffat-lto-objects
execution test
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-9969/usr
--enable-clocale=gnu
On Mon, Apr 15, 2024 at 2:35 PM Jørgen Kvalsvik wrote:
>
> Guard the longjmp to not infinitely loop. The longjmp (jump) function is
> called unconditionally to make test flow simpler, but the jump
> destination would return to a point in main that would call longjmp
> again. The lo
Guard the longjmp to not infinitely loop. The longjmp (jump) function is
called unconditionally to make test flow simpler, but the jump
destination would return to a point in main that would call longjmp
again. The longjmp is really there to exercise the then-branch of
setjmp, to verify coverage
Hi Jørgen,
> The __sigsetjmp test was added as a regression test, which an early
> iteration of the MC/DC support caused an internal compiler error,
> triggered by a code path which did not make it through to the final
> revision. Since this test really only worked on linux and does
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-11 11:51
To: gcc-patches
CC: juzhe.zhong; kito.cheng; Pan Li
Subject: [PATCH v1] RISC-V: Remove -Wno-psabi for test build option [NFC]
From: Pan Li
Just notice there are some test case still have -Wno-psabi option,
which is deprecated
From: Pan Li
Just notice there are some test case still have -Wno-psabi option,
which is deprecated now. Remove them all for riscv test cases.
The below test are passed for this patch.
* The riscv rvv regression test.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/pr109244.C
Hi,
Michal Jireš found out that the link to Feature Test Macros on the
Porting to GCC 14 page was broken, it misses a "/latest/" directory in
the middle of the path.
I'll commit the following as obvious.
Thanks,
Martin
---
htdocs/gcc-14/porting_to.html | 2 +-
1 file changed, 1
On 4/8/24 2:01 PM, David Faust wrote:
This test failed on powerpc --target_board=unix'{-m32}' because two
variables were not placed in sections where the test silently (and
incorrectly) assumed they would be.
The important thing for the test is only that BTF_KIND_DATASEC entries
This test failed on powerpc --target_board=unix'{-m32}' because two
variables were not placed in sections where the test silently (and
incorrectly) assumed they would be.
The important thing for the test is only that BTF_KIND_DATASEC entries
are NOT generated for the extern variable declarations
"Swinney, Jonathan" writes:
> The test for this intrinsic was failing silently and so it failed to
> report the bug reported in 114521. This patch modifes the test to
> report the result.
>
> Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114521
>
>
The test for this intrinsic was failing silently and so it failed to
report the bug reported in 114521. This patch modifes the test to
report the result.
Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114521
Signed-off-by: Jonathan Swinney
---
.../gcc.target/aarch64/advsimd
The __sigsetjmp test was added as a regression test, which an early
iteration of the MC/DC support caused an internal compiler error,
triggered by a code path which did not make it through to the final
revision. Since this test really only worked on linux and does not
serve a purpose any more
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Fixed by r12-2975.
PR c++/91079
DR 1881
gcc/testsuite/ChangeLog:
* g++.dg/ext/is_std_layout5.C: New test.
---
gcc/testsuite/g++.dg/ext/is_std_layout5.C | 13 +
1 file changed, 13 insertions(+)
cre
Hi Jakub,
On 3/27/24 04:16, Jakub Jelinek wrote:
> On Wed, Mar 27, 2024 at 11:18:49AM +0100, Jakub Jelinek wrote:
>>> -/* The offset entry for each variable in a DATSEC should be 0 at compile
>>> time. */
>>> -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
>>> +/*
This patch to the Go testsuite updates issue16016.go. This backports
https://go.dev/cl/574536 into the GCC testsuite. This fixes PR
go/114453. Bootstrapped and ran test. Committed to mainline.
Ian
5b6f599670994bef957bd15c683102468a7104f1
diff --git a/gcc/testsuite/go.test/test/fixedbugs
On Wed, Mar 27, 2024 at 11:18:49AM +0100, Jakub Jelinek wrote:
> > -/* The offset entry for each variable in a DATSEC should be 0 at compile
> > time. */
> > -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
> > +/* The offset entry for each variable in a DATSEC should
-torture/execute/pr51.c -O0 execution test
FAIL: gcc.c-torture/execute/pr51.c -O1 execution test
FAIL: gcc.c-torture/execute/pr51.c -O2 execution test
FAIL: gcc.c-torture/execute/pr51.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.c-torture
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
We used to hit the "Error reporting routines re-entered." ICE here but
it was fixed by Patrick's r14-3809.
PR c++/100557
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr100557.C: New test.
---
.../g++.dg/c
ectly defines the macro become redundant, because the test won't
> even get run if it doesn't. But we won't use this dg-require for many
> tests, only the ones where support is target-dependent because it relies
> on something non-standard or not available on all targets (like
>
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> And this replaces an existing custom dg-require- directive with a use of
> the new one that checks for a standard feature test macro. I didn't see
> any other existing dg-require-xxx directives that can be r
Hi!
I've missed
FAIL: gcc.dg/torture/pr113126.c -O0 (test for excess errors)
etc. regressions on i686-linux since January. The problem is obvious
Excess errors:
.../gcc/testsuite/gcc.dg/torture/pr113126.c:11:1: warning: MMX vector return
without MMX enabled changes the ABI [-Wpsabi]
and I've
ncoding/requirements.cc
@@ -8,7 +8,7 @@
# error "Feature-test macro for text_encoding has wrong value in
"
#endif
-#undef __cpp_lib_expected
+#undef __cpp_lib_text_encoding
#include
#ifndef __cpp_lib_text_encoding
# error "Feature-test macro for text_encoding missing in "
--
2.44.0
And this replaces an existing custom dg-require- directive with a use of
the new one that checks for a standard feature test macro. I didn't see
any other existing dg-require-xxx directives that can be replaced like
this.
-- >8 --
Remove the dejagnu code for checking whether std::stacktr
is that it becomes harder to notice if a particular
feature is missing on all targets, because we don't get FAILs we just
skip all tests as UNSUPPORTED. And the checks for whether
correctly defines the macro become redundant, because the test won't
even get run if it doesn't. But we won't use this dg
or;
- values = {
-v = 202207;
-cxxmin = 23;
-extra_cond = "__glibcxx_coroutine";
- };
-};
-
-ftms = {
- name = tuple_like;
- values = {
-v = 202207;
-cxxmin = 23;
- };
-};
-
// Standard test specifications.
stds[97] = ">= 199711L";
stds[03] = ">=
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The preprocessor checks for __cplusplus in should
use the appropriate feature test macros instead of __cplusplus, namely
__glibcxx_raw_memory_algorithms and __cpp_constexpr_dynamic_alloc.
For the latter, we want to check the compiler ma
Hi!
While I've posted a patch to handle EXCESS_PRECISION_EXPR in C/C++
pretty printing, still we'd need to handle
(a + (float)5)
and
(float)(((long double)a) + (long double)5)
and possibly
(float)(((double)a) + (double)5)
too for s390?, so the following patch just uses -fexcess-precision=fast,
so
:
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Disable
scheduling
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: Update test expectancies
* gcc.target/riscv/rvv/base/pr108185-2.c: Ditto
* gcc.target/riscv/rvv/base
checked with
Clang 16 too.
-- >8 --
The preprocessor checks for __cplusplus in should
use the appropriate feature test macros instead of __cplusplus, namely
__glibcxx_raw_memory_algorithms and __cpp_constexpr_dynamic_alloc.
For the latter, we want to check the compiler macro not the librar
On 3/5/24 4:40 AM, Xi Ruoyao wrote:
Recently I've fixed two wrong FP vector negate implementation which
caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To
prevent a similar issue from happening again, add a test case.
Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F
/rvv/dynamic-lmul4-6.c: Disable scheduling
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: Update test expectancies
* gcc.target/riscv/rvv/base/pr108185-2.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-3.c: Ditto
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
On Mar 10, 2024, at 10:26 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk?
Ok.
> 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.
>
>
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.
On Linux/x86_64,
df483ebd24689a3bebfae2089637a00eca0e5a12 is the first bad commit
commit df483ebd24689a3bebfae2089637a00eca0e5a12
Author: Jonathan Wakely
Date: Mon Feb 26 13:17:13 2024 +
libstdc++: Add nodiscard in
caused
FAIL: g++.dg/torture/pr104601.C -O0 (test for excess
Tested with GDB 14.1 on x86_64-linux. I'll backport this too.
-- >8 --
A recent GDB change causes this test to fail due to missing RTTI for the
custom_cast type. This is presumably because the custom_cat type was
defined as a local class, so has no linkage. Moving it to local scope
seems to
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
Committed the blow as requested by Jason in the patch for releases/gcc-13.
--
On arm-none-eabi, the test case fails with below warning on GCC13
.../null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:63:65: warning:
converting a packed 'enum obj_type' pointer (alignment 1) to a 'struct
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: Update test expectancies
* gcc.target/riscv/rvv/base/pr108185-2.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-3.c: Ditto
* gcc.target/riscv/rvv/base/pr108185
On Mon, Mar 11, 2024 at 11:14:04AM +0100, Andreas Krebbel wrote:
> On 2/29/24 13:15, Stefan Schulze Frielinghaus wrote:
> > Starting with r14-8319-g86de9b66480b71 fwprop improved so that vpdi is
> > no longer required.
> >
> > gcc/testsuite/ChangeLog:
> >
> > *
in
r14-6517-gb7e4a4c626e, does it still make sense to add something to
trunk for the same line?
Do you want me to add the dg-bogus, but change "xfail" to "target" for
trunk?
Sounds good.
Is this patch ok for releases/gcc-13?
OK.
--
On arm-none-eabi, the test case fails
sense to add something to
trunk for the same line?
Do you want me to add the dg-bogus, but change "xfail" to "target" for
trunk?
Is this patch ok for releases/gcc-13?
--
On arm-none-eabi, the test case fails with
.../null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:63:65:
On 2/29/24 13:15, Stefan Schulze Frielinghaus wrote:
> Starting with r14-8319-g86de9b66480b71 fwprop improved so that vpdi is
> no longer required.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/vector/long-double-to-i64.c: Fix scan
> assembler directive.
Should we perhaps
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.
Without this patch, fails like this can be seen:
Testing analyzer/strndup-1.c,
xfail part).
Also makes sense to add a reference to r14-6517-gb7e4a4c626e to the
dg-bogus in the source too.
Thanks,
Andrew Pinski
>
> --
>
> On arm-none-eabi, the test case fails with
> .../null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:63:65: warning:
> converting a packed
I don't know if this affects other targets than arm-none-eabi, so I
used arm-*-*. If you think it should be *-*-* or some other target
selector, please let me know what to use instead.
Ok for releases/gcc-13?
--
On arm-none-eabi, the test case fails with
.../null-deref-pr108251
On Thumb-2 the use of CBZ blocks conditional execution, so change the
test to compare with a non-zero value.
gcc/testsuite/ChangeLog:
PR target/113915
* gcc.target/arm/builtin-bswap.x: Fix test to avoid emitting CBZ.
---
diff --git a/gcc/testsuite/gcc.target/arm/builtin-bswap.x
On Fri, 8 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The test attempts to link a shared library, and apparently Darwin doesn't
> allow by default for shared libraries to contain undefined symbols.
>
> The following patch just adds dummy definitions for the symbols, so that
>
Hi!
The test attempts to link a shared library, and apparently Darwin doesn't
allow by default for shared libraries to contain undefined symbols.
The following patch just adds dummy definitions for the symbols, so that
the library no longer has any undefined symbols at least in my linux
testing
Hi David.
OK. Thanks.
> The test was trying to do too much by both checking for an error, and
> checking the resulting assembly. Of course, due to the error no asm was
> produced, so the scan-asm went unresolved. Split it into two separate
> tests to fix the issue.
>
> Test
The test was trying to do too much by both checking for an error, and
checking the resulting assembly. Of course, due to the error no asm was
produced, so the scan-asm went unresolved. Split it into two separate
tests to fix the issue.
Tested on x86_64-linux-gnu host for bpf-unknown-none target
of the data at a time, so it replaces abs() with the llabs() function.
However, the following two problems may occur after modification:
1.FAIL in lasx-xvfrint_s.c and lsx-vfrint_s.c
The reason for the error is because vector test cases that use __m{128,256} to
define vector types are composed of 32
: mode == HImode
+ || mode == HImode
+ ? GEN_INT (16)
+ : NULL);
+ operands[2] = shiftwidth;
+
+if (!shiftwidth)
+ return "v_mov_b32 %0, %1";
+else if ( == extend || == trunc)
+ return "v_lshlrev_b32\t%0, %2, %1\;v_ashrrev_i32\t%0, %2, %0";
+else
+ return "v_lshlrev_b32\t%0, %2, %1\;v_lshrrev_b32\t%0, %2, %0";
+ }
+ [(set_attr "type" "mult")
+ (set_attr "length" "8")])
OK to push the attached
"amdgcn: additional gfx1030/gfx1100 support: adjust test cases"?
Tested 'gcn.exp' for all '-march'es.
LGTM.
Andrew
+enum {extend, zero_extend, trunc};
> +rtx shiftwidth = (mode == QImode
> + || mode == QImode
> + ? GEN_INT (24)
> + : mode == HImode
> + || mode == HImode
> + ? GEN_INT (16)
> +
() function.
However, the following two problems may occur after modification:
1.FAIL in lasx-xvfrint_s.c and lsx-vfrint_s.c
The reason for the error is because vector test cases that use __m{128,256} to
define vector types are composed of 32-bit primitive types, they should use
ASSERTEQ_32 instead
Recently I've fixed two wrong FP vector negate implementation which
caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To
prevent a similar issue from happening again, add a test case.
Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F), AArch64, MIPS
(with MSA), LoongArch
by Jan Tojnar, pass the -no-install
flag to libtool to avoid generating a shell script. Bootstrapped and
ran libbacktrace tests on x86_64-pc-linux-gnu. Committed to mainline.
Ian
* Makefile.am (libbacktrace_testing_ldflags): Define.
(*_LDFLAGS): Add $(libbacktrace_testing_ldflags) for test
definition
of worse). The way to reduce the number of vsetvls is to set the
load latency to a low value.
I think -fno-schedule-insns is a perfectly reasonable way to get rid of
the test failures in the short term.
Using -fno-schedule-insns doesn't really fix the core fragility of the
tests, though
Starting with r14-8319-g86de9b66480b71 fwprop improved so that vpdi is
no longer required.
gcc/testsuite/ChangeLog:
* gcc.target/s390/vector/long-double-to-i64.c: Fix scan
assembler directive.
---
.../gcc.target/s390/vector/long-double-to-i64.c | 13 +
1 file
On Thu, 2024-02-29 at 15:09 +0800, Xi Ruoyao wrote:
> Recently I've fixed two wrong FP vector negate implementation which
> caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To
> prevent a similar issue from happening again, add a test case.
>
> Tested on x86_64
Recently I've fixed two wrong FP vector negate implementation which
caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To
prevent a similar issue from happening again, add a test case.
Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F), AArch64, MIPS
(with MSA), LoongArch
> I suggest specify -fno-schedule-insns to force tests assembler never
> change for any scheduling model.
We already do that and that's the point - as I mentioned before, no
scheduling is worse than default scheduling here (for some definition
of worse). The way to reduce the number of vsetvls
Hi,
on 2024/2/21 01:58, Carl Love wrote:
> GCC maintainers:
>
> The patch changes the vec-cmpne.c from a compile only test to a runnable
> test. The macros to create the functions needed to test the built-ins and
> verify the restults are all there in the include file. T
Hi,
on 2024/2/21 01:57, Carl Love wrote:
> GCC maintainers:
>
> The patch adds test cases for the vec_cmpne of built-ins.
>
> The patch has been tested on Power 10 with no regressions.
>
> Please let me know if this patch is acceptable for mainline. Thanks.
>
>
Hi Carl,
on 2024/2/21 01:57, Carl Love wrote:
>
> GCC maintainers:
>
> The patch adds documentation and test case for the __builtin_vsx_xvcmpeq[sp,
> dp, sp_p] built-ins.
>
> The patch has been tested on Power 10 with no regressions.
>
> Please let me know
Hi Carl,
on 2024/2/21 01:57, Carl Love wrote:
> GCC maintainers:
>
> The patch adds documentation and test case for the __builtin_vsx_xxpermdi_1ti
> built-in.
>
> The patch has been tested on Power 10 with no regressions.
>
> Please let me know if this patch is
Hi,
on 2024/2/21 01:56, Carl Love wrote:
> GCC maintainers:
>
> The patch adds documentation and test cases for the __builtin_vsx_xvnegsp,
> __builtin_vsx_xvnegdp built-ins.
>
> The patch has been tested on Power 10 with no regressions.
>
> Please let me know if
201 - 300 of 6355 matches
Mail list logo
