From: Fangrui Song
--discard-locals (-X) instructs the linker to remove local .L* symbols,
which occur a lot due to label differences for linker relaxation. The
arm port has a similar need and passes -X to ld.
In contrast, the RISC-V port does not pass -X to ld and rely on the
default
---
htdocs/gcc-14/changes.html | 156 +
1 file changed, 156 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9509487c..f0f0efe0 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -877,6 +877,162
Pushed to r14-10083.
在 2024/4/23 上午10:42, Yang Yujie 写道:
These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the
Pushed to r14-10084.
在 2024/4/23 上午10:42, Yang Yujie 写道:
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
* config.gcc: Add loongarch-evolution.o.
*
On 4/21/24 19:59, Patrick Palka wrote:
On Sat, 20 Apr 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
A class allocation member function is implicitly 'static' by
[class.free] p3, so cannot have an explicit object parameter.
PR
On 4/22/24 08:42, Jakub Jelinek wrote:
On Wed, Apr 17, 2024 at 09:42:47AM +0200, Jakub Jelinek wrote:
When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors
On 4/22/24 08:54, Jakub Jelinek wrote:
Hi!
The following testcase is rejected with
error: inlining failed in call to 'always_inline' '...': call is unlikely and
code size would grow
errors. The problem is that starting with the r14-2149 change
we try to copy most of the attributes from the
On 4/22/24 15:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/13/12?
OK with a rationale comment.
-- >8 --
The object/offset canonicalization performed in cxx_fold_indirect_ref
is undesirable for union member accesses because it loses
v1 -> v2:
- Fixed build issues of runtime libraries caused by the new header.
- Restored the default ARCH of lp64f/lp64s ABI to "abi-default".
v2 -> v3:
- Fixed libobjc build.
- Modify "LoongArch v1.1 features" to "LoongArch v1.1 instructions"
in invoke.texi.
v3 -> v4:
- Do not define
These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
Thanks Patrick.
Turn out that the make report cannot tell the error like below and then the
graphite.exp test will never run.
That explains why I missed test failures, will take care of it ASAP.
sorry, unimplemented: Graphite loop optimizations cannot be used (isl is not
available)
Pan
> Sure, reverting something that has a bug is reasonable. The problem is
> how this happened: this code clearly did not get tested, as it doesn't
> even build and re-introduces a bunch of ICEs. We're very late in stage
> 4 and this is the second time the entire port has been broken in as many
On Mon, 22 Apr 2024 15:07:59 PDT (-0700), juzhe.zh...@rivai.ai wrote:
Apologize that we didn't post our (me, kito and Li Pan) disscussions.
Some amount of off-list discussion is inevitable, but as far as I can
tell here we ended up with some code committed that wasn't even posted
to the
This patch in particular does not cause any more regressions. It's one
of the other reverts from the weekend.
Before the reverts [1]:
| gcc |
g++ | gfortran |
rv64gcv/ lp64d/ medlow | 48/ 32 | 12/ 3| 12 /
Sure thing. Sorry for that Fortran is not fully tested for this change, will
take a look into it ASAP.
Pan
From: 钟居哲
Sent: Tuesday, April 23, 2024 6:06 AM
To: patrick ; Li, Pan2 ; gcc-patches
Cc: kito.cheng ; rdapp.gcc
Subject: Re: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/13/12?
-- >8 --
The object/offset canonicalization performed in cxx_fold_indirect_ref
is undesirable for union member accesses because it loses information
about the member being accessed which we may later need to
On Mon, 22 Apr 2024 14:30:21 PDT (-0700), ja...@redhat.com wrote:
Hi!
I've run aspell on gcc.pot (just quickly skimming, so pressing
I key hundreds of times and just stopping when I catch something that
looks like a misspelling).
I plan to commit this tomorrow as obvious unless somebody finds
Apologize that we didn't post our (me, kito and Li Pan) disscussions.
This is the story:
We found that my previous patches which support highpart register overlap with
register filter for instructions like (vwadd.wv)
cause ICE reported by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
and
I think the revert patch exposes latent bug, Li Pan will look into it.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2024-04-23 03:55
To: pan2.li; gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc
Subject: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d
and
Thanks a lot.
Qing
> On Apr 22, 2024, at 16:38, Joseph Myers wrote:
>
> This version of patch 1/5 is OK for GCC 15.
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? More tests
are needed but I figured I'd submit this now for possible consideration into
GCC 14 since we're getting close to release.. All changes are confined to
C++26.
-- >8 --
libstdc++-v3/ChangeLog:
*
Hi!
I've run aspell on gcc.pot (just quickly skimming, so pressing
I key hundreds of times and just stopping when I catch something that
looks like a misspelling).
I plan to commit this tomorrow as obvious unless somebody finds some
issues in it, you know, I'm not a native English speaker.
Yes,
On Mon, 22 Apr 2024, Christophe Lyon wrote:
> Hi Patrick,
>
> On Sat, 13 Apr 2024 at 22:12, Patrick Palka wrote:
> >
> > Pushed as obvious after verifying C++11 bootstrap is restored.
>
> I guess this also fixes the bootstrap_ubsan breakage on aarch64
> reported by Linaro CI?
> See
Looks like we had a bunch of commits over the weekend that didn't get
tested/reviewed. Some didn't even make it to the lists so it's hard to
tell exactly what happened, but the result was a trunk that doesn't even
build and a bunch of ICEs after some trivial fix ups landed on the
lists.
So let's
This version of patch 1/5 is OK for GCC 15.
--
Joseph S. Myers
josmy...@redhat.com
Hi Pan,
I was running the testsuite for this and noticed an ICE scroll by when
this patch is applied to cacc55a4c0be8d0bc7417b6a28924eadbbe428e3 for
rv64gcv:
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
On Mon, Apr 22, 2024 at 12:05 PM Alexandre Oliva wrote:
>
> Ping?-ish for the full version of the RFC posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566588.html
>
> On Mar 11, 2021, Richard Biener wrote:
>
> > On Thu, Mar 11, 2021 at 9:03 AM Alexandre Oliva wrote:
>
> >> So
On Mon, Apr 22, 2024 at 10:47 AM Andreas Krebbel wrote:
>
> Hi Stefan,
>
> due to that missed optimization we currently generate silly code for these
> two tests and should
> really fix this (after gcc entering stage1). So just skipping it on s390x
> would definitely be the
> wrong choice I
`param` is also inheriting from `lvalue`. I don't think adding this
check is a good idea
because it will not evolve nicely if more changes are done in libgccjit.
Le lun. 22 avr. 2024 à 17:19, Antoni Boucher a écrit :
>
> For your new API endpoint, please add a check like:
>
>RETURN_IF_FAIL
Hi Pan,
I'm not sure I'm following. Did we miss something that should have been
covered? Like only an overlap on the srcs but not the dest?
Are there testcases that fail? If so we should definitely have one.
Can you give some additional information on why these reverts are needed?
+1 to the
On Mon, 22 Apr 2024 06:47:34 PDT (-0700), pan2...@intel.com wrote:
From: Pan Li
After we reverted below 2 commits, the reference to attr need some
adjustment as the group_overlap is no longer available.
* RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
* RISC-V: Rename
lgtm
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-22 21:47
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and
e65aaf8efe1
From: Pan Li
After we reverted below 2 commits, the reference to attr need
> On Apr 19, 2024, at 16:54, Tom Tromey wrote:
>
>> Qing Zhao writes:
>
>> +The size of the union is as if the flexiable array member were omitted
>> +except that it may have more trailing padding than the omission would imply.
>> +
>> +If all the members of a union are flexiable array
Good point!
New patch attached.
Le lun. 22 avr. 2024 à 15:13, Antoni Boucher a écrit :
>
> Please move the function to be on lvalue since there are no rvalue types
> that are not lvalues that have a name.
>
> Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :
> > Hey Arthur :)
> >
> >> Is there
On Fri, Apr 19, 2024 at 05:54:11PM -0400, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> I can defer to 15 if needed, of course.
>
> -- >8 --
> When the compiler defaults to -freport-bug, a few dg-ice tests fail
> with:
>
> Excess errors:
> Preprocessed
From: Pan Li
After we reverted below 2 commits, the reference to attr need some
adjustment as the group_overlap is no longer available.
* RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
* RISC-V: Rename vconstraint into group_overlap
The below tests are passed for this patch.
... I most definitely forgot. Thanks! ^^'
Le lun. 22 avr. 2024 à 15:19, Antoni Boucher a écrit :
> I believe you forgot to regenerate the ChangeLog.
>
> Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :
> > Good point!
> >
> > New patch attached.
> >
> > Le lun. 22 avr. 2024 à 15:13, Antoni
On Mon, 22 Apr 2024 at 16:30, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?
OK, thanks
>
> - 8< -
>
>
> Avoid
> -Wnarrowing in C
On Mon, 22 Apr 2024 at 16:30, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?
OK
>
> - 8< -
>
> Signed-off-by: Matthias Kretz
>
>
Hi!
The following testcase is rejected with
error: inlining failed in call to 'always_inline' '...': call is unlikely and
code size would grow
errors. The problem is that starting with the r14-2149 change
we try to copy most of the attributes from the inherited to
inheriting ctor, but don't
On Wed, Apr 17, 2024 at 09:42:47AM +0200, Jakub Jelinek wrote:
> When expand_or_defer_fn is called at_eof time, it calls import_export_decl
> and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
> couple of places to try to optimize cdtors which are known to have the
> same
On Mon, 22 Apr 2024 at 16:37, Jakub Jelinek wrote:
>
> Hi!
>
> We see
> FAIL: 17_intro/headers/c++1998/all_attributes.cc (test for excess errors)
> FAIL: 17_intro/headers/c++2011/all_attributes.cc (test for excess errors)
> FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess
For your new API endpoint, please add a check like:
RETURN_IF_FAIL (lvalue->is_global () || lvalue->is_local (),
NULL,
NULL,
"lvalue should be a variable");
Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :
Good point!
New patch
I believe you forgot to regenerate the ChangeLog.
Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :
Good point!
New patch attached.
Le lun. 22 avr. 2024 à 15:13, Antoni Boucher a écrit :
Please move the function to be on lvalue since there are no rvalue types
that are not lvalues that
Hi!
We see
FAIL: 17_intro/headers/c++1998/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2011/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2017/all_attributes.cc (test
Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
linux-gnueabihf
OK for trunk and backports?
- 8< -
Signed-off-by: Matthias Kretz
libstdc++-v3/ChangeLog:
PR libstdc++/114803
*
Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
linux-gnueabihf
OK for trunk and backports?
- 8< -
Avoid
-Wnarrowing in C code;
-Wtautological-compare in unconditional static_assert (necessary for
faking a
Please move the function to be on lvalue since there are no rvalue types
that are not lvalues that have a name.
Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :
Hey Arthur :)
Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead
Hey Arthur :)
> Is there any reason for that getter to return a mutable pointer to the
> name? Would something like this work instead if you're just looking at
> getting the name?
>
> + virtual string * get_name () const { return NULL; }
>
> With of course adequate modifications to the
Am 22.04.24 um 12:04 schrieb Jonathan Wakely:
OK for wwwdocs?
For me it's ok (I am not a native speaker though,
which is the reason the typos are there to begin with).
Johann
htdocs/gcc-14/changes.html | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
Hi Andreas,
Ok then I will proceed with the patch as is. Opened PR114802.
Cheers,
Stefan
--
The tests fail on s390 since can_vec_perm_const_p fails and therefore
the bit insert/ref survive which r14-3381-g27de9aa152141e aims for.
Strictly speaking, the tests only fail in case the target
Ping?-ish
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619678.html
It's that time of the year again. The good news is that this is the
last patch in my ppc*-vxworks7* set ;-)
On May 25, 2023, Segher Boessenkool wrote:
> On Thu, May 25, 2023 at 10:55:37AM -0300, Alexandre Oliva wrote:
>>
Ping?-ish for the full version of the RFC posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566588.html
On Mar 11, 2021, Richard Biener wrote:
> On Thu, Mar 11, 2021 at 9:03 AM Alexandre Oliva wrote:
>> So I'm leaning towards this proposed change, just extended to other
>>
OK for wwwdocs?
---
htdocs/gcc-14/changes.html | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9509487c..21d33db8 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@
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.
> In my view, such an XFAIL
This patch takes feedback received for 3 earlier patches, and adopts a
simpler approach to skip the still-failing tests, that I believe to be
in line with ppc maintainers' expressed preferences.
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565939.html
Hey Guillaume :)
On 4/20/24 01:05, Guillaume Gomez wrote:
Hi,
I just encountered the need to retrieve the name of an `rvalue` (if
there is one) while working on the Rust GCC backend.
This patch adds a getter to retrieve the information.
Cordially.
virtual bool get_wide_int (wide_int *)
[Revamped version of this patch, combined with others, to follow]
On Mar 10, 2021, Hans-Peter Nilsson wrote:
> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>>
>> The test expects shrink-wrapping of the fsqrt call, but that will only
>> occur when there is a usable sqrt insn.
>>
>> Arrange for
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566530.html
(modified version follows)
We've observed failures of this test on powerpc configurations that
default to different calling conventions and alignment requirements.
Both settings are needed for the original expectations to be
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593947.html
vec-mul is an execution test, but it only requires a powerpc_vsx_ok
effective target, which is enough only for compile tests. In order to
To check for runtime and execution environment support, we need to
require vsx_hw. Make
From: Olivier Hainque
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/swaps-p8-20.c: Change powerpc_altivec_ok
require-effective-target test into
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566525.html
This test expects vectorization at power8+ because strict alignment is
not required for vectors. For power7, vectorization is not to take
place because it's not deemed profitable: 12 iterations would be
required to make it
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
These ppc lp64 tests check for errors or warnings on -mno-powerpc64.
On powerpc64-*-vxworks* we get the same errors as on most other
covered platforms, but the tests did not mark them as expected for
this target. On powerpc-*-vxworks*, the tests are skipped because
lp64 is not satisfied, so I'm
v1 -> v2:
- Fixed build issues of runtime libraries caused by the new header.
- Restored the default ARCH of lp64f/lp64s ABI to "abi-default".
v2 -> v3:
- Fixed libobjc build.
- Modify "LoongArch v1.1 features" to "LoongArch v1.1 instructions"
in invoke.texi.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
We currently enable the vector extensions also for -march=z13 -m31
mesa which is very wrong.
Not a regression but an obvious fix, so I've committed it to mainline
now. Will have to cherry-pick it for stable branches as well.
gcc/ChangeLog:
* config/s390/s390.cc
Hi all,
This patch fixes an bug in mapping which caused auto dispatch failed.
Sierra Forest is in processor_types enum, but not processor_subtypes.
Committed as obvious and backport to GCC13.
Thx,
Haochen
gcc/ChangeLog:
* common/config/i386/i386-common.cc (processor_alias_table):
On Sat, 2024-04-20 at 18:47 +0800, Yang Yujie wrote:
> +@item la664
> +LoongArch LA664-based processor with LSX, LASX and all LoongArch v1.1
> features.
I still prefer "v1.1 instructions" instead of "v1.1 features" because
LA664 (at least all launched LA664 CPUs) does not support HPTW, which
Hi Stefan,
due to that missed optimization we currently generate silly code for these two
tests and should
really fix this (after gcc entering stage1). So just skipping it on s390x would
definitely be the
wrong choice I think.
I think our vectorize_vec_perm_const correctly rejects this permute
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-34.c.
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 test
Hello Alex:
On 14/04/24 10:29 pm, Ajit Agarwal wrote:
> Hello Alex:
>
> On 12/04/24 11:02 pm, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 12/04/24 8:15 pm, Alex Coplan wrote:
>>> On 12/04/2024 20:02, Ajit Agarwal wrote:
Hello Alex:
On 11/04/24 7:55 pm, Alex Coplan wrote:
> On
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 the
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 are
On 4/22/24 08:01, Stefan Schulze Frielinghaus wrote:
> Starting with r14-9316-g7890836de20912 patterns for vpopct{b,h} are also
> detected. Thus, remove xfails.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/vxe/popcount-1.c: Remove xfail.
Ok. Thanks!
Andreas
> ---
> Ok for
The tests fail on s390 since can_vec_perm_const_p fails and therefore
the bit insert/ref survive which r14-3381-g27de9aa152141e aims for.
Strictly speaking, the tests only fail in case the target supports
vectors, i.e., for targets prior z13 or in case of -mesa the emulated
vector operations are
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.
Starting with r14-9316-g7890836de20912 patterns for vpopct{b,h} are also
detected. Thus, remove xfails.
gcc/testsuite/ChangeLog:
* gcc.target/s390/vxe/popcount-1.c: Remove xfail.
---
Ok for mainline?
gcc/testsuite/gcc.target/s390/vxe/popcount-1.c | 4 ++--
1 file changed, 2
85 matches
Mail list logo
