value support.
aarch64: Add masked-load else operands.
gcn: Add else operand to masked loads.
i386: Add else operand to masked loads.
RISC-V: Add else operand to masked loads [PR115336].
.../aarch64/aarch64-sve-builtins-base.cc | 46 ++-
gcc/config/aarch64/aarch64-sve-builtins.cc
this patch still had this handling in ifcvt but
the latest version defers it to the vectorizer.
gcc/ChangeLog:
* tree-if-conv.cc (predicate_load_or_store): Add zero else
operand and comment.
---
gcc/tree-if-conv.cc | 16 +++-
1 file changed, 11 insertions(+), 5 dele
From: Robin Dapp
This patch adds an undefined else operand to the masked loads.
gcc/ChangeLog:
* config/gcn/predicates.md (maskload_else_operand): New
predicate.
* config/gcn/gcn-valu.md: Use new predicate.
---
gcc/config/gcn/gcn-valu.md | 14 +-
gcc
From: Robin Dapp
This patch adds a zero else operand to masked loads, in particular the
masked gather load builtins that are used for gather vectorization.
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_expand_special_args_builtin):
Add else-operand handling
a I used a function call property to specify
whether a builtin needs an else operand or not. Somebody with better
knowledge of the aarch64 target can surely improve that.
gcc/ChangeLog:
* config/aarch64/aarch64-sve-builtins-base.cc: Add else
handling.
* config/aarch64/a
and uses that for the
maskload call. If necessary, i.e. if the mode has padding bits and if
the else operand is nonzero, a VEC_COND enforcing a zero else value is
emitted.
gcc/ChangeLog:
* optabs-query.cc (supports_vec_convert_optab_p): Return icode.
(get_supported_else_val
From: Robin Dapp
This patch amends the documentation for masked loads (maskload,
vec_mask_load_lanes, and mask_gather_load as well as their len
counterparts) with an else operand.
gcc/ChangeLog:
* doc/md.texi: Document masked load else operand.
---
gcc/doc/md.texi | 63
From: Robin Dapp
This patch adds else operands to masked loads. Currently the default
else operand predicate just accepts "undefined" (i.e. SCRATCH) values.
PR middle-end/115336
PR middle-end/116059
gcc/ChangeLog:
* config/riscv/autovec.md: Add el
From: Robin Dapp
This patch adds else-operand handling to the internal functions.
gcc/ChangeLog:
* internal-fn.cc (add_mask_and_len_args): Rename...
(add_mask_else_and_len_args): ...to this and add else handling.
(expand_partial_load_optab_fn): Use adjusted function
Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or
(a ? CST1 : CST2): Don't use build_nonstandard_type, just convert
to type. Use boolean_true_node instead of
constant_boolean_node (true, boolean_type_node). Formatting fixes.
--- gcc/match.pd.jj 2023-09-18 10:37:56.002965361 +0200
+++ gcc/match.pd2023-09-18 12
On Tue, 19 Sep 2023, Jakub Jelinek wrote:
> Hi!
>
> On Tue, Sep 12, 2023 at 05:27:30PM +, Joseph Myers wrote:
> > On Tue, 12 Sep 2023, Jakub Jelinek via Gcc-patches wrote:
> >
> > > And by ensuring we never create 1-bit signed BITINT_TYPE e.g. the backends
&
Hi!
clearenv function just sets environ to NULL (after sometimes freeing it),
rather than setting it to a pointer to NULL, and our code was assuming
it is always non-NULL.
Fixed thusly, the change seems to be large but actually is just
+ if (environ)
for (env = environ; *env != 0; env++)
pl
e I stumbled across two
> > > > optimizations where either my intuition about the representation of
> > > > unsigned integers via a const_int rtx is wrong, which then in turn would
> > > > probably also mean that this patch is wrong, or that the optimizations
Hi!
On Tue, Sep 12, 2023 at 05:27:30PM +, Joseph Myers wrote:
> On Tue, 12 Sep 2023, Jakub Jelinek via Gcc-patches wrote:
>
> > And by ensuring we never create 1-bit signed BITINT_TYPE e.g. the backends
> > don't need to worry about them.
> >
> > But I adm
Hi!
On Tue, Sep 12, 2023 at 09:02:55AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches
> > wrote:
> > &g
Hi!
I'd like to ping a couple of C++ patches. All of them together
with the 2 updated patches posted yesterday have been
bootstrapped/regtested on x86_64-linux and i686-linux again yesterday.
- c++: Implement C++26 P2361R6 - Unevaluated strings [PR110342]
https://gcc.gnu.org/pipermai
mov v0.8b, v1.8b
> ins v0.s[1], v2.s[0]
> ret
>
> but is now:
>
> f:
> zip1v0.2s, v1.2s, v2.2s
> ret
>
> > The attached patch adjusts the tests to reflect the change in code-gen
> > and the tests pass.
&g
Hi,
When commit the fix for pr111324, the test cases was named as pr111303.c
by mistake. Here, rename it to pr111324.c
Is this ok for trunk?
BR,
Jeff (Jiufu Guo)
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr111303.c: Rename to ...
* gcc.dg/tree-ssa/pr111324.c: ... this
Hi,
In r14-3582, an "overflow_free_p" interface is added.
The pattern of "(t * 2) / 2" in match.pd can be simplified
by using this interface.
Bootstrap & regtest pass on ppc64{,le} and x86_64.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeLog:
* match.pd
From: Tsukasa OI
We have the 'V' extension (RVV), not SVE from AArch64.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc
(builtin_decl, expand_builtin): Replace SVE with RVV.
---
gcc/config/riscv/riscv-vector-builtins.cc | 4 ++--
1 file changed, 2 insert
LGTM, thanks for fixing that :)
On Tue, Sep 19, 2023 at 8:54 AM Tsukasa OI via Gcc-patches
wrote:
>
> From: Tsukasa OI
>
> riscv-builtins.cc includes riscv-cmo.def and riscv-scalar-crypto.def
> (making dependencies) but their dependencies must be explicitly defined at
> the
On 9/18/23 13:45, Vineet Gupta wrote:
For the cases which do require sign extends, but not being eliminated
due to "missing definition(s)" I'm working on adapting Ajit's REE ABI
interfaces work [2] to work for RISC-V as well.
I wonder if we could walk the DECL_ARGUMENTS for current_functio
On 9/18/23 1:27 PM, Harald Anlauf via Fortran wrote:
Dear all,
as correctly analyzed by Jerry, the code for checking the consistency
of character lengths in array constructors did not properly initialize
the auxiliary variable used in "bounds checking". The attached patch
resolves this by initi
an lvalue-to-rvalue
conversion is applied to a discarded-value expression only if "the
expression is a glvalue of volatile-qualified type". This patch
restricts convert_to_void's type completion to match.
PR c++/111419
gcc/cp/ChangeLog:
* cvt.cc (convert_to
, and preserve the load.
gcc/cp/ChangeLog:
* cvt.cc (convert_to_void) : Remove warning
for an implicit load of a volatile reference. Simplify as if
is_reference is false. Check REFERENCE_REF_P in the test
guarding the -Wunused-value diagnostic.
gcc/testsuite/Chan
On 9/18/23 17:42, Marek Polacek wrote:
+ /* The purpose of this is not to emit errors for mce_unknown. */
+ const tsubst_flags_t complain = (data->flags == ff_fold_immediate
+ ? tf_none : tf_error);
Maybe check flags & ff_mce_false, instead? OK with that cha
From: Tsukasa OI
riscv-builtins.cc includes riscv-cmo.def and riscv-scalar-crypto.def
(making dependencies) but their dependencies must be explicitly defined at
the configuration file, t-riscv.
They were the last two .def files without correct dependency information.
gcc/ChangeLog
On Mon, Sep 18, 2023 at 12:09 AM Richard Biener via Gcc-patches
wrote:
>
> On Sat, Sep 16, 2023 at 7:50 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > Transforming `(a * b@[0,1]) != 0` into `((cast)b) & a != 0`
>
> that isn't strictly a simplification
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Monday, September 18, 2023 11:36 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Support VLS mode for vec_set
LGTM
On Mon, Sep 18, 2023 at 11
Committed, thanks Jeff and Robin.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, September 19, 2023 1:44 AM
To: Robin Dapp ; Li, Pan2 ;
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ;
kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Bugfix for scalar move
how that would be better than what I did.
> > >
> > > Callers of cp_fold_immediate don't need this because cp_fold_r isn't
> > > involved, so it isn't folding anything.
> >
> > This is true.
> > > cp_fold_r can walk the arms with cp_fold_r
On 9/18/23 13:45, Vineet Gupta wrote:
Hi Jeff, Andrew
I've been looking into redundant sign extension and while there are
things to be improved in REE, there's something I wanted to confirm
before heading off into the weeds.
Consider the test below:
int foo(int unused, int n, unsigned y,
inter the
storage is assigned to.
PR c/71219
gcc:
* doc/invoke.texi: Document -Walloc-size option.
gcc/c-family:
* c.opt (Walloc-size): New option.
gcc/c:
* c-typeck.cc (convert_for_assignment): Add warning.
gcc/testsuite:
* gcc.dg/Walloc-size-1.c: New tes
Hi Lehua,
> +(define_expand "vcond_mask_"
> + [(set (match_operand:V_VLS 0 "register_operand")
> +(if_then_else:V_VLS
> + (match_operand: 3 "register_operand")
> + (match_operand:V_VLS 1 "nonmemory_operand")
> + (match_operand:V_VLS 2 "vector_register_or_const_0
9d8133 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 18 Sep 2023 22:11:40 +0200
Subject: [PATCH] fortran: fix checking of CHARACTER lengths in array
constructors [PR70231]
gcc/fortran/ChangeLog:
PR fortran/70231
* trans-array.cc (trans_array_constructor): In absence of a typespec,
ing on adapting Ajit's REE ABI
> interfaces work [2] to work for RISC-V as well.
>
> Thx,
> -Vineet
>
> [1]
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc
> [2] https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630713.html
Tested on i686, x86_64 and aarch64 Darwin, also on x86_64 and aarch64
Linux. Having said this, some fallout might well be expected on Darwin
since the consumers have not had much use with GCC output where the
DWARF version is > 2, we will have to tackle that as it arises.
pushed to trunk, tha
lib= for Darwin targets where libc++ is the default on the
system (so that it is only necessary to provide the headers).
However, it seems that there are some cases where (external) config
scripts are using -stdlib (incorrectly) to determine if the compiler
in use is GCC or clang.
In order to allow
On 9/18/23 04:00, Robin Dapp wrote:
I must be missing something. Doesn't insn 10 broadcast the immediate
0x2 to both elements of r142?!? What am I missing?
It is indeed a bit misleading. The difference is in the mask which
is not displayed in the short form. So we actually use a vec_dup
f
Hi Richard,
> I was worried that reusing "dest" for intermediate results would
> prevent CSE for cases like:
>
> void g (long long, long long);
> void
> f (long long *ptr)
> {
> g (0xee11ee22ee11ee22LL, 0xdc23dc44ee11ee22LL);
> }
Note that aarch64_internal_mov_immediate may be called after relo
On Thu, Aug 24, 2023 at 04:30:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
> The following patch on top of PR110349 patch (weak dependency,
> only for -Wc++26-extensions, I could split that part into an independent
> patch) and PR110342 patch (again weak dependency, this time mainly
On Tue, Aug 22, 2023 at 09:39:11AM +0200, Jakub Jelinek via Gcc-patches wrote:
> The following patch implements the C++26 P2169R4 paper.
> As written in the PR, the patch expects that:
> 1) https://eel.is/c++draft/expr.prim.lambda.capture#2
>"Ignoring appearances in ini
as template. This patch applies the same optimization to
> >>> tsubst_template_decl when (partially) instantiating a function template,
> >>> which allows us to remove a check from register_specialization since
> >>> tsubst_function_decl no longer calls regist
t issue a warning, and preserve the load.
>
> gcc/cp/ChangeLog:
>
> * cvt.cc (convert_to_void) : Remove warning
> for an implicit load of a volatile reference. Simplify as if
> is_reference is false. Check REFERENCE_REF_P in the test
> guarding t
o-rvalue
> conversion is applied to a discarded-value expression only if "the
> expression is a glvalue of volatile-qualified type". This patch
> restricts convert_to_void's type completion to match.
>
> PR c++/111419
>
> gcc/cp/ChangeLog:
>
>
Jason pointed out that even implicit loads of volatile references need
to undergo lvalue-to-rvalue conversion, but we currently emit a warning
in this case and discard the load. This patch changes this behavior so
that we don't issue a warning, and preserve the load.
gcc/cp/Chan
an INDIRECT_REF or
> > > > > VAR_DECL expression, but according to [expr.context] an
> > > > > lvalue-to-rvalue
> > > > > conversion is applied to a discarded-value expression only if "the
> > > > > expre
quot;the
expression is a glvalue of volatile-qualified type". This patch
restricts convert_to_void's type completion to match.
PR c++/111419
gcc/cp/ChangeLog:
* cvt.cc (convert_to_void) : Only call
complete_type if the type is volatile.
: Only call complete_t
t; conversion is applied to a discarded-value expression only if "the
> > > > expression is a glvalue of volatile-qualified type". This patch
> > > > restricts
> > > > convert_to_void's type completion accordingly.
> > > >
>
I may missed that one time too, not on plane yet, but need to go bed
earlier due to my flight is in next day early morning...
On Mon, Sep 18, 2023 at 11:07 PM Palmer Dabbelt wrote:
>
> My flight to the Cauldron lands in the middle of the meeting, so I'm
> going to miss it. In theory it's all set
On Mon, Sep 18, 2023 at 4:46 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2023-09-15T15:33:59+0200, Robin Dapp wrote:
> > is there anything we can do to assist from the riscv side in order to help
> > with this? I haven't really been involved with it but was wondering
> > what's missing. If I under
> From: Sam James
> Date: Mon, 18 Sep 2023 08:21:45 +0100
> Hans-Peter Nilsson writes:
>
> >> From: Sam James
> >> Date: Sun, 17 Sep 2023 05:00:37 +0100
> >
> >> Hans-Peter Nilsson via Gcc-patches writes:
> >> > The situation was descr
On 9/15/23 10:48, Vladimir Makarov wrote:
On 9/14/23 06:45, Surya Kumari Jangala wrote:
ira: Consider save/restore costs of callee-save registers [PR110071]
In improve_allocation() routine, IRA checks for each allocno if spilling
any conflicting allocnos can improve the allocation of this al
Pushed to trunk.
-- >8 --
The row for P1466R3 was missing the info on when it was implemented.
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2020.xml: Tweak P1466R3 status.
* doc/html/manual/status.html: Regenerate.
---
libstdc++-v3/doc/html/manual/status.html | 2 +-
On 9/18/23 02:53, Richard Biener wrote:
On Fri, Sep 15, 2023 at 4:45 PM Andrew MacLeod wrote:
Ive been looking at __builtin_unreachable () regressions. The
fundamental problem seems to be a lack of consistent expectation for
when we remove it earlier than the final pass of VRP.After loo
> Thanks for finding that! I have made the recommended change and attached the
> revised patch, which is also rebased on trunk.
>
> Additionally, I have added the “Signed-off-by” tag for legal compliance to
> the patch, as well as the change log entry as follows:
Thank you, patch is therefore n
lls register_specialization for
a function template partial instantiation.
gcc/cp/ChangeLog:
* pt.cc (register_specialization): Remove now-unnecessary
early exit for FUNCTION_DECL partial instantiation.
(tsubst_template_decl): Pass use_spec_table=false
R c++/63198
PR c++/18474
gcc/cp/ChangeLog:
* semantics.cc (maybe_convert_cond): Look through implicit
INDIRECT_REF when deciding whether to issue a -Wparentheses
warning, and consider templated assignment expressions as well.
(finish_parenthesized_expr): L
Pushed to trunk. Most of this should be backported to gcc-13 too.
We also need a C++26 status page, which doesn't exist yet.
-- 8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/configure.xml: Use conventional option name.
* doc/xml/manual/status_cxx2020.xml: Update.
member from a uninstantiated const member function; naively fixed by
> > making the data member mutable.
> >
> > PR c++/63198
> > PR c++/18474
> >
> > gcc/cp/ChangeLog:
> >
> > * semantics.cc (maybe_convert_cond): Look through imp
Pushed to wwwdocs.
---
htdocs/gcc-14/changes.html | 48 +-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index eae25f1a..65382746 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc
ster_specialization since
> > tsubst_function_decl no longer calls register_specialization for
> > a function template partial instantiation.
> >
> > gcc/cp/ChangeLog:
> >
> > * pt.cc (register_specialization): Remove now-unnecessary
> > earl
LGTM.
Regards
Robin
On 8/9/23 19:14, Jakub Jelinek via Gcc-patches wrote:
It is enabled only on targets which have agreed on processor specific
ABI how to lay those out or pass as function arguments/return values,
which currently is just x86-64 I believe, would be nice if target maintainers
helped to get agreement
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/intro.xml: Clarify that building libstdc++
separately from GCC is not supported.
* doc/xml/manual/prerequisites.xml: Note msgfmt prerequisite for
testing.
* doc/html/manual/setup.h
Thanks Robin, let's wait Jeff's confirmation for this.
Pan
-Original Message-
From: Robin Dapp
Sent: Monday, September 18, 2023 6:01 PM
To: Jeff Law ; Li, Pan2 ;
gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; Wang, Yanzhang
; kito.ch...@gmail.com
S
Ping.
Regards
Robin
> I must be missing something. Doesn't insn 10 broadcast the immediate
> 0x2 to both elements of r142?!? What am I missing?
It is indeed a bit misleading. The difference is in the mask which
is not displayed in the short form. So we actually use a vec_dup
for a single-element move, essentially
Hi!
I'd like to ping this patch.
The C++ FE part has been approved by Jason already with a minor change
I've made in my copy.
Are the remaining parts ok for trunk?
On Fri, Aug 11, 2023 at 10:48:19AM +0200, Jakub Jelinek via Gcc-patches wrote:
> 2023-08-11 Jakub Jelin
On Sun, Sep 17, 2023 at 3:45 AM Andrew Pinski via Gcc-patches
wrote:
>
> So when VN finds a name which has a nop conversion, it says
> both names are equivalent to each other and the valuaization
> function for one will return the other. This normally does not
> cause any issues
On Mon, Sep 18, 2023 at 11:04:16AM +0200, Richard Biener via Gcc-patches wrote:
> > Note genmatch should warn (or error out) if this gets detected so I filed
> > PR 111446
> > which I will be looking into next week or the week after so we don't run
> &
://patchwork.sourceware.org/project/gcc/patch/5ad7cdca-63e1-73af-b38d-d58898e21...@linux.ibm.com/
[2]
https://patchwork.sourceware.org/project/gcc/patch/65ed79a3-9964-dd50-39cb-98d5dbc72...@linux.ibm.com/
--
Maxim Kuvyrkov
https://www.linaro.org
> On Sep 18, 2023, at 09:59, Ajit Agarwal via
On Sun, Sep 17, 2023 at 11:41 PM Andrew Pinski via Gcc-patches
wrote:
>
> So it turns out VN can't handle any kind of recusion for match. In this
> case we have `b = a & -1` and we try to match a as being zero_one_valued_p
> and VN returns b as being the value and we just go
On Mon, Sep 18, 2023 at 10:41 AM Richard Sandiford
wrote:
>
> Kewen Lin writes:
> > This costing adjustment patch series exposes one issue in
> > aarch64 specific costing adjustment for STP sequence. It
> > causes the below test cases to fail:
> >
> >
Hello Richard,
> I have added the required “Signed-off-by” tag to the patch and to the change
> log
> entry below. I believe for all other aspects I have followed the instructions.
Thanks for doing these modifications. I believe you have read the
Developer's Certificate of Origin (https://gcc.
Kewen Lin writes:
> This costing adjustment patch series exposes one issue in
> aarch64 specific costing adjustment for STP sequence. It
> causes the below test cases to fail:
>
> - gcc/testsuite/gcc.target/aarch64/ldp_stp_15.c
> - gcc/testsuite/gcc.target/aarch64/ldp_
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Monday, September 18, 2023 4:01 PM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; jeffreya...@gmail.com;
rdapp@gmail.com
Subject: Re: [PATCH] RISC-V
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Monday, September 18, 2023 4:20 PM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; jeffreya...@gmail.com;
rdapp@gmail.com
Subject: Re: [PATCH] RISC-V
1,.L12
>
> After this patch:
>
> vle32.v v2,0(a5)
> addia5,a5,16
> vadd.vv v1,v1,v2
> bne a5,a4,.L4
> li a5,0
> andia1,a1,-4
> vmv.s.x v2,a5
> vredsum.vs v1,v1,v2
> vmv.x.s
OK for backport now, steps for backport:
- checkout to releases/gcc-13 branch
- ./contrib/git-backport.py
- Make sure everything is alright, build-able, no extra regression.
- push releases/gcc-13 branch!
On Mon, Sep 18, 2023 at 3:54 PM Lehua Ding wrote:
>
> Hi Kito,
>
> Can th
; V_VLSI
> VF --> V_VLSF
>
> It makes no sense to have a separate file holding a very few VLS patterns
> that can not be extended from the current VLA patterns.
>
> So remove autovec-vls.md
>
> gcc/ChangeLog:
>
> * config/riscv/vector.md (mov): New pattern.
&g
On Mon, 18 Sep 2023, Jakub Jelinek wrote:
> On Thu, Sep 14, 2023 at 01:23:13PM +, Richard Biener via Gcc-patches
> wrote:
> > diff --git a/libgomp/team.c b/libgomp/team.c
> > index 54dfca8080a..e5a86de1dd0 100644
> > --- a/libgomp/team.c
> > +++ b/libgo
On Sun, Sep 17, 2023 at 9:47 PM Marc Poulhiès via Gcc-patches
wrote:
>
> Fix all occurences of varadic, except for Rust (will be part of another
> change).
OK.
> gcc/ChangeLog:
>
> * config/nvptx/nvptx.h (struct machine_function): Fix typo in
> variadic.
>
On Sat, Sep 16, 2023 at 6:00 PM Andrew Pinski via Gcc-patches
wrote:
>
> `(a == CST) & a` can be either simplified to simplying `a == CST`
> or 0 depending on the first bit of the CST.
> This is an extension of the already pattern of `X & !X` and allows
> us to remove the 2
this patch looks neutral, but for P8 and
later, it may cause some few differences in code gen. I'm curious that how
many total object files and different object files were checked and found
on P8? fmr or xxlor preference can be further considered along with existing:
https://gcc.gnu.org/pip
Hans-Peter Nilsson writes:
>> From: Sam James
>> Date: Sun, 17 Sep 2023 05:00:37 +0100
>
>> Hans-Peter Nilsson via Gcc-patches writes:
>>
>> >> Date: Tue, 29 Aug 2023 15:42:27 -0400
>> >> From: Marek Polacek via Gcc-patches
>> >
On Thu, Sep 14, 2023 at 01:23:13PM +, Richard Biener via Gcc-patches wrote:
> diff --git a/libgomp/team.c b/libgomp/team.c
> index 54dfca8080a..e5a86de1dd0 100644
> --- a/libgomp/team.c
> +++ b/libgomp/team.c
> @@ -756,8 +756,9 @@ gomp_team_start (void (*fn) (void *), void *da
On Sat, Sep 16, 2023 at 7:50 AM Andrew Pinski via Gcc-patches
wrote:
>
> Transforming `(a * b@[0,1]) != 0` into `((cast)b) & a != 0`
that isn't strictly a simplification (one more op), and your
alternate transform is even worse in this regard.
> will produce better code as a
On Fri, Sep 15, 2023 at 5:09 PM Marek Polacek via Gcc-patches
wrote:
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, powerpc64le-unknown-linux-gnu,
> and aarch64-unknown-linux-gnu; ok for trunk?
>
> -- >8 --
> In <https://gcc.gnu.org/pipermail/gcc-patches/2023-August/6
On Fri, Sep 15, 2023 at 4:45 PM Andrew MacLeod wrote:
>
> Ive been looking at __builtin_unreachable () regressions. The
> fundamental problem seems to be a lack of consistent expectation for
> when we remove it earlier than the final pass of VRP.After looking
> through them, I think this pro
I think it's not make too much sense to back port GCC14's change to
GCC 13, removing phase 6 optimization is reasonable to me, so LGTM :)
On Mon, Sep 18, 2023 at 2:44 PM juzhe.zh...@rivai.ai
wrote:
>
> Thanks for fixing it.
> I am ok remove phase 6 optimization which has m
On Thu, Sep 14, 2023 at 04:24:33PM +0200, Paul Iannetta wrote:
> Hi,
>
> This is a small patch so that both dg-extract-results.py and
> dg-extract-results.sh share the same header. In particular, it fixes
> the fact that the regexp r'^Test Run By (\S+) on (.*)$' was never
> matched in the python
gtested on powerpc64-linux-gnu P7/P8/P9
and powerpc64le-linux-gnu P9 and P10.
I'm going to push this soon.
BR,
Kewen
-
PR target/111366
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_update_ipa_fn_target_info): Skip
empty inline asm.
gcc/testsuite/ChangeL
werpc64-linux-gnu P7/P8/P9
and powerpc64le-linux-gnu P9 and P10.
I'm going to push this soon if no objections.
BR,
Kewen
-
PR target/111380
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_can_inline_p): Adopt
target_option_default_node when the callee has no option
see redundant zero and sign extension and done to
improve ree pass to eliminate such redundant zero and sign extension
using defined ABI interfaces.
2023-09-18 Ajit Kumar Agarwal
gcc/ChangeLog:
* ree.cc (combine_reaching_defs): Use of zero_extend and sign_extend
defined
(buff);
>
> "sldi 9,3,32 ; mtvsrd 1,9 ; xscvspdpn 1,1" is generated.
> A better one would be "mtvsrws 1,3 ; xscvspdpn 1,1".
>
> Compare with previous patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623533.html
> "highpart DI-->SF&qu
ogical shift for ":DI>>32".
>
> Pass bootstrap and regression on ppc64{,le}.
> Is this ok for trunk?
>
> BR,
> Jeff (Jiufu Guo)
>
> PR target/108338
>
> gcc/ChangeLog:
>
> * config/rs6000/predicates.md (lowpart_subreg_operator): New
&
vious patch more reasonable:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609504.html
>
> Bootstrap and regtest pass on ppc64{,le}.
> Is this ok for trunk?
>
> BR,
> Jeff (Jiufu)
>
> gcc/ChangeLog:
>
> * config/rs6000/rs6000.cc (rs6000_modes_tieable_p):
Applying to trunk as obvious (explaining existing behavior).
-- 8< --
gcc/ChangeLog:
* doc/gty.texi: Add discussion of cache vs. deletable.
---
gcc/doc/gty.texi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi
index 15f9fa07405..1dfe4652
1 - 100 of 6617 matches
Mail list logo
