在 2024/4/19 下午10:27, Xi Ruoyao 写道:
On Fri, 2024-04-19 at 19:04 +0800, Yang Yujie wrote:
@table @samp
@item native
-This selects the CPU to generate code for at compilation time by determining
-the processor type of the compiling machine. Using @option{-march=native}
-enables all
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.
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
> 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.
> If something is broken then indeed we should revert it.
Yes, we may need to support
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.
From d2ddeec950f23533e5e18bc0c10c4b49eef3cda3 Mon Sep 17 00:00:00 2001
From: Guillaume Gomez
Date: Sat,
Hi!
The r14-4456 change (part of APX EGPR support) seems to have mistakenly
changed in the
@@ -16831,7 +16831,7 @@ (define_insn "*avx2_eq3"
[(set (match_operand:VI_256 0 "register_operand" "=x")
(eq:VI_256
(match_operand:VI_256 1 "nonimmediate_operand" "%x")
-
On Fri, Apr 19, 2024 at 06:43:13PM +, Qing Zhao wrote:
> Therefore, GCC needs to explicitly allow such extensions directly for C99
> flexible arrays, since flexable array member in unions or alone in structs
> are common code patterns in active use by the Linux kernel (and other
> projects).
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 source stored into /tmp/cc6hldZ0.out file, please attach this to
your bugreport.
rs6000, remove vector set and vector init built-ins.
The vector init built-ins:
__builtin_vec_init_v16qi, __builtin_vec_init_v8hi,
__builtin_vec_init_v4si, __builtin_vec_init_v4sf,
__builtin_vec_init_v2di, __builtin_vec_init_v2df,
__builtin_vec_set_v1ti
perform the same operation as
rs6000, remove __builtin_vsx_xvcmpeqsp built-in
The built-in __builtin_vsx_xvcmpeqsp is a duplicate of the overloaded
vec_cmpeq built-in. The built-in is undocumented. The built-in and
the test cases are removed.
gcc/ChangeLog:
* config/rs6000/rs6000-builtins.def
rs6000, remove __builtin_vsx_vperm_* built-ins
The undocumented built-ins:
__builtin_vsx_vperm_16qi_uns,
__builtin_vsx_vperm_1ti,
__builtin_vsx_vperm_1ti_uns,
__builtin_vsx_vperm_2df,
__builtin_vsx_vperm_2di,
__builtin_vsx_vperm_2di_uns,
__builtin_vsx_vperm_4sf,
rs6000, remove the vec_xxsel built-ins, they are duplicates
The following undocumented built-ins are covered by the existing overloaded
vec_sel built-in definitions.
const vsc __builtin_vsx_xxsel_16qi (vsc, vsc, vsc);
same as vsc __builtin_vec_sel (vsc, vsc, vuc); (overloaded vec_sel)
rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in
The built-in __builtin_vsx_xvcmpeqsp_p is a duplicate of the overloaded
__builtin_altivec_vcmpeqfp_p built-in. The built-in is undocumented and
there are no test cases for it. The patch removes built-in
__builtin_vsx_xvcmpeqsp_p.
gcc/ChangeLog:
rs6000, remove duplicated built-ins of vecmergl and vec_mergeh
The following undocumented built-ins are same as existing documented
overloaded builtins.
const vf __builtin_vsx_xxmrghw (vf, vf);
same as vf __builtin_vec_mergeh (vf, vf); (overloaded vec_mergeh)
const vsi
rs6000, extend the current vec_{un,}signed{e,o} built-ins
The built-ins __builtin_vsx_xvcvspsxds and __builtin_vsx_xvcvspuxds
convert a vector of floats to signed/unsigned long long ints. Extend the
existing vec_{un,}signed{e,o} built-ins to handle the argument
vector of floats to return the
rs6000, extend vec_xxpermdi built-in for __int128 args
Add a new overloaded instance for vec_xxpermdi
__int128 vec_xxpermdi (__int128, __int128, const int);
Update the documentation to include a reference to the new built-in
instance.
gcc/ChangeLog:
*
rs6000, remove __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp built-ins
The undocumented __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp are
redundant. The overloaded vec_neg built-in provides the same
functionality. The two buit-ins are not documented nor are there any
test cases for them.
rs6000, fix error in unsigned vector float to unsigned int built-in definitions
The built-ins __builtin_vsx_vunsigned_v2df and__builtin_vsx_vunsigned_v4sf
are supposed to take a vector of floats and return a vector of unsigned
long long ints. The definitions are using the signed version of the
rs6000, add overloaded vec_sel with int128 arguments
Extend the vec_sel built-in to take three signed/unsigned int128 arguments
and return a signed/unsigned int128 result.
Extending the vec_sel built-in makes the existing buit-ins
__builtin_vsx_xxsel_1ti and __builtin_vsx_xxsel_1ti_uns obsolete.
rs6000, Remove __builtin_vsx_xvcvspsxws built-in
The built-in __builtin_vsx_xvcvspsxws is a duplicate of the vec_signed
built-in that is documented in the PVIPR. The __builtin_vsx_xvcvspsxws
built-in is not documented and there are no test cases for it.
This patch removes the redundant
rs6000, Remove __builtin_vsx_cmple* builtins
The built-ins __builtin_vsx_cmple_u16qi, __builtin_vsx_cmple_u2di,
__builtin_vsx_cmple_u4si and __builtin_vsx_cmple_u8hi should take
unsigned arguments and return an unsigned result. The current definitions
take signed arguments and return signed
GCC maintainers:
The following patch series removes duplicate built-ins. There are patches to
extend an existing overloaded built-in to cover additional input types. The
final patch removes built-ins to set and initialize vectors. The code
generated by these built-ins with the default
On Fri, 19 Apr 2024, Jakub Jelinek wrote:
> Ok for trunk and later 13.3 if it passes bootstrap/regtest (so far just
> checked on the sentinel related C/C++ tests)?
>
> 2024-04-19 Jakub Jelinek
>
> PR c/114780
> * c-common.cc (check_function_sentinel): Allow as sentinel any
>
> 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 member, the size of
There's a couple of spots that say
On Mon, 15 Apr 2024, Jakub Jelinek wrote:
> 2024-04-15 Martin Uecker
> Jakub Jelinek
>
> PR lto/114574
> PR c/114361
> gcc/c/
> * c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not
> ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY.
>
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Instead of constraining these overloads in terms of synth-three-way we
can just check that the value_type is less-than-comparable, which is
what synth-three-way's constraints check.
The reason that I implemented these with constraints has now been
On Fri, 19 Apr 2024 at 10:08, Jonathan Wakely wrote:
>
> On Fri, 19 Apr 2024 at 07:14, Richard Biener
> wrote:
> >
> > On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely wrote:
> > >
> > > This would fix the but, how do people feel about it this close to the
> > > gcc-14 release?
> >
> > Guess
gcc/testsuite/ChangeLog:
* c-c++-common/builtin-clear-padding-3.c: Adjust testcase.
* g++.dg/ext/flexary12.C: Likewise.
* g++.dg/ext/flexary19.C: Likewise.
* g++.dg/ext/flexary2.C: Likewise.
* g++.dg/ext/flexary3.C: Likewise.
*
gcc/testsuite/ChangeLog:
* gcc.dg/flex-array-in-union-1.c: New test.
* gcc.dg/flex-array-in-union-2.c: New test.
---
gcc/testsuite/gcc.dg/flex-array-in-union-1.c | 37 +
gcc/testsuite/gcc.dg/flex-array-in-union-2.c | 42
2 files changed, 79
for allow flexible array members in unions and alone in structures [PR53548]
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has
gcc/c/ChangeLog:
* c-decl.cc (finish_struct): Change errors to pedwarns for the cases
flexible array members in union or alone in structures.
gcc/cp/ChangeLog:
* class.cc (diagnose_flexarrays): Change error to pdewarn for the case
flexible array members alone in
Hi,
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a struct has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
Hi Paul,
the patch is OK, but I had to manually fix it. I wonder how you managed
to produce:
diff --git a/gcc/testsuite/gfortran.dg/pr93484.f90
b/gcc/testsuite/gfortran.dg/pr93484.f90
new file mode 100644
index 000..4dcad47e8da
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103471.f90
The patch does not cause failures on AIX. Is it removing explicit
references to /lib and /usr/lib?
It seems more appropriate for GCC 15.
Thanks for alerting me to the patch to test on AIX. AIX is in CFarm.
Thanks David
On Tue, Apr 16, 2024 at 7:49 PM Andrew Pinski (QUIC) <
Hi All,
This is a more or less obvious patch. The action is in resolve.cc. The
chunk in symbol.cc is a tidy up of a diagnostic marker to distinguish where
the 'no IMPLICIT type' error was coming from and the chunk in trans-decl.cc
follows from discussion with Harald on the PR.
Regtests fine. OK
Hello, Richard,
Thanks, your response was very informative.
Here's a revised patch.
arm pac and bti tests that use -march=armv8.1-m.main get an implicit
-mthumb, that is incompatible with vxworks kernel mode. Declaring the
requirement for a 8.1-m.main-compatible toolchain is enough to avoid
On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:
> On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:
> > On Mon, 15 Apr 2024, Nathaniel Shead wrote:
> >
> > > I'm not a huge fan of always streaming 'imported_temploid_friends' for
> > > all decls, but I don't think it
On Mon, Apr 15, 2024 at 02:49:35PM +1000, Nathaniel Shead wrote:
> I took another look at this patch and have split it into two, one (this
> one) to standardise the error messages used and prepare
> 'module_may_redeclare' for use with temploid friends, and another
> followup patch to actually
Hi!
During backporting I've noticed I've missed one return spot for the
restoration of the original flag_trapv flag value.
Tested on x86_64-linux, committed to trunk as obvious. Sorry.
2024-04-19 Jakub Jelinek
PR middle-end/114753
* internal-fn.cc (expand_arith_overflow):
Hi Pan,
> The RVV register overlap requires both the dest, and src operands.
> Thus the rigister filter in constraint cannot cover the fully sematics
> of the vector register overlap.
I'm not sure I'm following. Did we miss something that should have been
covered? Like only an overlap on the
From: Pan Li
The RVV register overlap requires both the dest, and src operands.
Thus the rigister filter in constraint cannot cover the fully sematics
of the vector register overlap.
Thus, revert these overlap patches list and xfail the related test
cases. This patch would like to revert
On Fri, 2024-04-19 at 19:04 +0800, Yang Yujie wrote:
> @table @samp
> @item native
> -This selects the CPU to generate code for at compilation time by determining
> -the processor type of the compiling machine. Using @option{-march=native}
> -enables all instruction subsets supported by the
On Fri, Apr 19, 2024 at 3:29 PM Tamar Christina wrote:
>
> Hi All,
>
> As the reporter in PR114769 points out the control flow for the abd detection
> is hard to follow. This is because vect_recog_absolute_difference has two
> different ways it can return true.
>
> 1. It can return true when the
Hi All,
As the reporter in PR114769 points out the control flow for the abd detection
is hard to follow. This is because vect_recog_absolute_difference has two
different ways it can return true.
1. It can return true when the widening operation is matched, in which case
unprom is set,
On 19/04/2024 13:45, Alexandre Oliva wrote:
> On Apr 16, 2024, "Richard Earnshaw (lists)" wrote:
>
>> The require-effective-target flags test whether a specific set of
>> flags will make the compilation work, so they need to be used in
>> conjunction with the corresponding dg-add-options flags
On Fri, Apr 19, 2024 at 07:34:33PM +0800, Xi Ruoyao wrote:
> On Fri, 2024-04-19 at 19:04 +0800, Yang Yujie wrote:
> > These ISA versions are defined as -march= parameters and
> > are recommended for building binaries for distribution.
> >
> > Detailed description of these definitions can be found
On Apr 16, 2024, "Richard Earnshaw (lists)" wrote:
> The require-effective-target flags test whether a specific set of
> flags will make the compilation work, so they need to be used in
> conjunction with the corresponding dg-add-options flags that then
> apply those options.
*nod*, that's the
David: Ping.
Le 2024-02-29 à 10 h 34, Antoni Boucher a écrit :
David: Ping.
On Thu, 2024-02-15 at 09:32 -0500, Antoni Boucher wrote:
David: Ping
On Thu, 2024-02-08 at 08:59 -0500, Antoni Boucher wrote:
David: Ping.
On Wed, 2024-01-10 at 18:58 -0500, Antoni Boucher wrote:
Here it is:
David: Ping.
Le 2024-04-09 à 09 h 21, Antoni Boucher a écrit :
David: Ping.
Le 2024-04-01 à 08 h 20, Antoni Boucher a écrit :
David: Ping.
Le 2024-03-19 à 07 h 03, Arthur Cohen a écrit :
Hi,
On 3/5/24 16:09, David Malcolm wrote:
On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:
On Fri, 2024-04-19 at 19:04 +0800, Yang Yujie wrote:
> 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
>
Hi!
While in C++ the ellipsis argument conversions include
"An argument that has type cv std::nullptr_t is converted to type void*"
in C23 a nullptr_t argument is not promoted in any way, but va_arg
description says:
"the type of the next argument is nullptr_t and type is a pointer type that has
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
Hi!
On 2024-04-19T12:30:25+0200, Jakub Jelinek wrote:
> On Fri, Apr 19, 2024 at 12:23:03PM +0200, Thomas Schwinge wrote:
>> On 2024-04-19T08:24:03+0200, Jakub Jelinek wrote:
>> > --- gcc/testsuite/gcc.dg/pr114768.c.jj 2024-04-18 15:37:49.139433678
>> > +0200
>> > +++
On Fri, Apr 19, 2024 at 12:23:03PM +0200, Thomas Schwinge wrote:
> On 2024-04-19T08:24:03+0200, Jakub Jelinek wrote:
> > --- gcc/testsuite/gcc.dg/pr114768.c.jj 2024-04-18 15:37:49.139433678
> > +0200
> > +++ gcc/testsuite/gcc.dg/pr114768.c 2024-04-18 15:43:30.389730365 +0200
> > @@ -0,0
Hi Jakub!
On 2024-04-19T08:24:03+0200, Jakub Jelinek wrote:
> --- gcc/testsuite/gcc.dg/pr114768.c.jj2024-04-18 15:37:49.139433678
> +0200
> +++ gcc/testsuite/gcc.dg/pr114768.c 2024-04-18 15:43:30.389730365 +0200
> @@ -0,0 +1,10 @@
> +/* PR rtl-optimization/114768 */
> +/* { dg-do
David Faust writes:
> Hi Cupertino,
>
> On 4/18/24 13:58, Cupertino Miranda wrote:
>> Hi David, everyone,
>>
>> Following Davids last review I decided to properly detect error cases,
>> as suggested.
>> The error however should be reported earlier in compilation in
>> pack_enum_valud function,
Thanks! Pushed!
Jose E. Marchesi writes:
> Hi Cupertino.
> OK for master.
> Thanks!
>
>> BPF supports multiple instructions to be CO-RE relocatable regardless of
>> the position of the immediate field in the encoding.
>> In particular, not only the MOV instruction allows a CO-RE
>> relocation
Hi everyone,
This patch checks for the presence of dlopen and pthread_create in libc. If
that is not the
case, we check for the existence of -ldl and -lpthread, as these libraries are
required to
link the Rust runtime to our Rust frontend.
If these libs are not present on the system, then we
On Thu, 18 Apr 2024 at 22:59, Patrick Palka wrote:
>
> On Wed, 17 Apr 2024, Michael Levine (BLOOMBERG/ 919 3RD A) wrote:
>
> > This patch fixes GCC Bug 108760:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
> > Before this patch, using std::ranges::iota required including
> > when it
Hi,
This regression in the D front-end was found to be caused by in some
cases the hidden closure parameter type being generated too early for
nested functions. Better to update the type after the local
closure/frame type has been completed.
Bootstrapped and regression tested on
On Fri, 19 Apr 2024 at 07:14, Richard Biener wrote:
>
> On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely wrote:
> >
> > This would fix the but, how do people feel about it this close to the
> > gcc-14 release?
>
> Guess we'll have to fix it anyway, so why not now ...
Yeah, I don't think Debian
On Fri, 19 Apr 2024 at 11:03, Christophe Lyon
wrote:
>
> This script is a copy of the current script used by Sourceware's
> autoregen buildbots.
>
> It is intended as a helper to regenerate files managed by autotools
> (autoconf, automake, aclocal, ), as well as the toplevel
> Makefile.in
This script is a copy of the current script used by Sourceware's
autoregen buildbots.
It is intended as a helper to regenerate files managed by autotools
(autoconf, automake, aclocal, ), as well as the toplevel
Makefile.in which is created by autogen.
Other files can be updated when using
Hi Claudiu,
On 9/7/23 12:15, Claudiu Zissulescu Ianculescu wrote:
> OK,
>
> Thank you for your contribution,
> Claudiu
Could you commit this patch?
>
> On Wed, Sep 6, 2023 at 3:50 PM Shahab Vahedi
> wrote:
>>
>> This patch covers signed and unsigned subtractions. The generated code
>>
Hi Clauudiu,
On 9/7/23 12:15, Claudiu Zissulescu Ianculescu wrote:
> Ok.
>
> Thank you for your contribution,
> Claudiu
Could you commit this patch?
>
> On Wed, Sep 6, 2023 at 3:50 PM Shahab Vahedi
> wrote:
>>
>> This patch covers signed and unsigned additions. The generated code
>> would
On Fri, 19 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase, combine propagates the mem/v load into mem store
> with the same address and then removes it, because noop_move_p says it is a
> no-op move. If it was the other way around, i.e. mem/v store and mem load,
> or both
On Fri, 19 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled because the code to decrement
> vn on negative value with all ones in most significant limb (even partial)
> and 0 in most significant bit of the second most significant limb doesn't
> take into account the
---
htdocs/gcc-13/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 4384c329..15a309d6 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -625,7 +625,7 @@ You may also want to
Hi!
On the following testcase, combine propagates the mem/v load into mem store
with the same address and then removes it, because noop_move_p says it is a
no-op move. If it was the other way around, i.e. mem/v store and mem load,
or both would be mem/v, it would be kept.
The problem is that
Hi!
The following testcase is miscompiled because the code to decrement
vn on negative value with all ones in most significant limb (even partial)
and 0 in most significant bit of the second most significant limb doesn't
take into account the case where all bits below the most significant limb
On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely wrote:
>
> This would fix the but, how do people feel about it this close to the
> gcc-14 release?
Guess we'll have to fix it anyway, so why not now ... (what could go wrong..)
Richard.
> Tested x86_64-linux.
>
> -- >8 --
>
> Since 2022 the TZif
75 matches
Mail list logo
