Can I please get permission for fixing this ICE?
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616221.html
Martin
r14-172-g0368d169492017 use NO_REGS instead of GENERAL_REGS in memory cost
calculation when preferred register class is unkown.
+ /* Costs for NO_REGS are used in cost calculation on the
+1st pass when the preferred register classes are not
+known yet. In this case we take the
Hi,
On 2023-05-01 23:52, Segher Boessenkool wrote:
Hi!
On Fri, Mar 17, 2023 at 11:39:52AM +0800, Jiufu Guo wrote:
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr65421-1.c: New test.
* gcc.target/powerpc/pr65421.c: New test.
Please name the tests something else? -1.c and -2
Hi,
On 2023-05-01 03:00, Jeff Law wrote:
On 3/16/23 21:39, Jiufu Guo wrote:
Hi,
When assigning a parameter to a variable, or assigning a variable to
return value with struct type, and the parameter/return is passed
through registers.
For this kind of case, it would be better to use the nature
From: Juzhe-Zhong
This patch is fix patch of V2:
https://patchwork.sourceware.org/project/gcc/patch/20230419164214.1032017-3-juzhe.zh...@rivai.ai/.
Address comments from Kito && Robin, and fix issues && add testcases for them.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (preferred_si
[Ping]
From: Tejas Belagod
Date: Thursday, March 16, 2023 at 5:09 PM
To: gcc-patches@gcc.gnu.org
Cc: Tejas Belagod , Richard Sandiford
Subject: [PATCH] [PR96339] AArch64: Optimise svlast[ab]
From: Tejas Belagod
This PR optimizes an SVE intrinsics sequence where
svlasta (svptrue_pat_b8
On Thu, May 4, 2023 at 1:35 PM Hongtao Liu wrote:
>
> On Thu, Dec 22, 2022 at 4:04 PM Uros Bizjak wrote:
> >
> > On Thu, Dec 22, 2022 at 5:40 AM Hongtao Liu wrote:
> > >
> > > On Thu, Dec 22, 2022 at 6:46 AM Jakub Jelinek wrote:
> > > >
> > > > On Wed, Dec 21, 2022 at 02:43:43PM -0800, H.J. Lu
On Thu, Dec 22, 2022 at 4:04 PM Uros Bizjak wrote:
>
> On Thu, Dec 22, 2022 at 5:40 AM Hongtao Liu wrote:
> >
> > On Thu, Dec 22, 2022 at 6:46 AM Jakub Jelinek wrote:
> > >
> > > On Wed, Dec 21, 2022 at 02:43:43PM -0800, H.J. Lu wrote:
> > > > > > > > > > Target RejectNegative
> > > > > > > > >
This ideal of this patch looks good to me.
But I think this patch should be able to handle more cases (not only -16 ~ 15)
in case of CONST_VECTOR initialization.
Case 1 (Other constant value that is not -16 ~ 15):
void vmv_m##VAL (TYPE dst[], int n) \
{
Here's update patch with documents in md.texi.
Ok for trunk?
--
Use swap_communattive_operands_p for canonicalization. When both value
has same operand precedence value, then first bit in the mask should
select first operand.
The canonicalization should help backends for pattern match
On Tue, May 2, 2023 at 4:08 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The following testcase ICEs because STV replaces there
> (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
> (nil))
> with
> (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1
>
On Mon, May 1, 2023 at 3:37 AM Jeff Law wrote:
>
>
>
> On 4/19/23 21:58, liuhongt via Gcc-patches wrote:
> > Use swap_communattive_operands_p for canonicalization. When both value
> > has same operand precedence value, then first bit in the mask should
> > select first operand.
> >
> > The canonic
This kind of transformation seems pretty generic and might be a
candidate for adding to the middle-end, perhaps as part of combine.
I noticed these happened more often for LRA, which is the reason I
went on this track of low-hanging-fruit-microoptimizations that are
such an itch when noticing them
This has no effect on arith-rand-ll (which suffers badly from LRA) and
marginal effects (0.01% improvement) on coremark, but the size of
coremark shrinks by 0.2%. An earlier version was tested with a tree
around 2023-03 which showed (marginally) that ALL_REGS is preferable
to GENERAL_REGS.
Ping again.
> From: Hans-Peter Nilsson
> Date: Thu, 27 Apr 2023 01:55:24 +0200
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 19 Apr 2023 18:59:14 +0200
> [...]
>
> > So again: Approvers: pdf output reviewed. Ok to commit?
> > -- >8 --
> > I was a bit surprised when my newly-added define_peeph
On previous occasions when a general LRA transition has been
discussed, IIRC, the argument was used, that everything is ready for
targets and their maintainers to make the transition. As I pointed
out then (though more than a year ago last time, people forget) that's
still not true: LRA documentat
While improving replace_phi_edge_with_variable for the diamond formed bb
case, I need a way to copy phi entries from one edge to another as I am
removing a forwarding bb inbetween. I was pointed out that jump threading
code had copy_phi_arg_into_existing_phi which I can use.
I also noticed that bot
While looking at differences between what minmax_replacement
and match_simplify_replacement does. I noticed that they sometimes
chose different edges to remove. I decided we should be able to do
better and be able to remove both empty basic blocks in the
case of match_simplify_replacement as that m
When I added the dce_ssa_names argument, I didn't realize bitmap was a
pointer so I used the default argument value as auto_bitmap(). But
instead we could just use nullptr and check if it was a nullptr
before calling simple_dce_from_worklist.
OK? Bootstrapped and tested on x86_64-linux-gnu with no
> 2023年5月3日 22:04，Maciej W. Rozycki 写道：
>
> On Wed, 3 May 2023, Richard Sandiford wrote:
>
>>> speculation_barrier for MIPS needs sync+jr.hb (r2+),
>>> so we implement __speculation_barrier in libgcc, like arm32 does.
>>
>> Looks reasonable, but do you have a source for the fallback
>> pre-r
gcc/ChangeLog:
* doc/extend.texi: Replace @itemx not being preceded by @item.
---
Fixes errors raised by newer Texinfo.
Pushed as obvious.
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index d6093397a61.
On Wed, 3 May 2023, Richard Sandiford wrote:
> > speculation_barrier for MIPS needs sync+jr.hb (r2+),
> > so we implement __speculation_barrier in libgcc, like arm32 does.
>
> Looks reasonable, but do you have a source for the fallback
> pre-r2 handling? (Thanks for adding that btw, since I real
On Wed, 3 May 2023, Jason Merrill wrote:
> On 5/2/23 15:53, Patrick Palka wrote:
> > on Tue, 2 May 2023, Patrick Palka wrote:
> >
> > > On Tue, 2 May 2023, Jason Merrill wrote:
> > >
> > > > On 5/1/23 15:59, Patrick Palka wrote:
> > > > > Here we're incorrectly deeming the templated call a.g() i
On Wed, 3 May 2023 at 21:06, Jakub Jelinek wrote:
>
> On Wed, May 03, 2023 at 08:56:40PM +0100, Jonathan Wakely wrote:
> > Do we want a #pragma to suppress -Wattribute-alias here?
>
> I think that isn't needed, as the aliases use the same argument types
> as the functions they are aliasing (did th
On Wed, May 03, 2023 at 08:56:40PM +0100, Jonathan Wakely wrote:
> Do we want a #pragma to suppress -Wattribute-alias here?
I think that isn't needed, as the aliases use the same argument types
as the functions they are aliasing (did that because other
aliases in those files do it that way as well
On Wed, 3 May 2023 at 19:55, Jakub Jelinek via Libstdc++
wrote:
>
> Hi!
>
> This is an ABI problem on powerpc64le-linux, introduced in 13.1.
> When libstdc++ is configured against old glibc, the
> _ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31
> _ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.
On 5/2/23 15:53, Patrick Palka wrote:
on Tue, 2 May 2023, Patrick Palka wrote:
On Tue, 2 May 2023, Jason Merrill wrote:
On 5/1/23 15:59, Patrick Palka wrote:
Here we're incorrectly deeming the templated call a.g() inside b's
initializer as potentially constant, despite g being non-constexpr,
On Wed, 3 May 2023, 19:44 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi!
>
> As discussed ON IRC, my _Float128/_Float64x support changes broke
> abi.exp testing on powerpc64-linux.
>
> The
> _ZTIDF128_@@CXXABI_1.3.14
> _ZTIDF64x@@CXXABI_1.3.14
> _ZTIPDF128_@@CXXABI_1.3.14
> _ZT
On 5/2/23 17:13, Patrick Palka wrote:
constraints_satisfied_p already carefully checks dependence of template
arguments before proceeding with satisfaction, so the dependence check
in instantiate_alias_template is unnecessary and overly conservative.
Getting rid of it allows us to check satisfact
On 5/2/23 19:10, Marek Polacek wrote:
This PR points out that std::is_convertible has given the wrong answer
in
static_assert (!std::is_convertible_v , "");
since r13-2822 implemented __is_{,nothrow_}convertible.
std::is_convertible uses the imaginary
To test() { return std::declval();
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A bug in the simplification I did around 91618; at this point X::f has
DECL_IMPLICIT_INSTANTIATION set, but we've already identified what template
it corresponds to, so we don't want to call check_explicit_specialization.
To distinguish thi
Hi, Jan,
You added the following patch into gcc10:
>From 34fbe3f0946f88828765184ed6581bda62cdf49f Mon Sep 17 00:00:00 2001
From: Jan Hubicka
Date: Thu, 5 Dec 2019 19:12:51 +0100
Subject: [PATCH] cgraphclones.c (localize_profile): New function.
* cgraphclones.c (localize_profile): New fu
Richard Biener writes:
> On Fri, 28 Apr 2023, Andre Vieira (lists) wrote:
>
>> This patch replaces the existing tree_code widen_plus and widen_minus
>> patterns with internal_fn versions.
>>
>> DEF_INTERNAL_OPTAB_HILO_FN is like DEF_INTERNAL_OPTAB_FN except it provides
>> convenience wrappers for
Hi!
This is an ABI problem on powerpc64le-linux, introduced in 13.1.
When libstdc++ is configured against old glibc, the
_ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF
Hi!
As discussed ON IRC, my _Float128/_Float64x support changes broke
abi.exp testing on powerpc64-linux.
The
_ZTIDF128_@@CXXABI_1.3.14
_ZTIDF64x@@CXXABI_1.3.14
_ZTIPDF128_@@CXXABI_1.3.14
_ZTIPDF64x@@CXXABI_1.3.14
_ZTIPKDF128_@@CXXABI_1.3.14
_ZTIPKDF64x@@CXXABI_1.3.14
symbols only appear on power
YunQiang Su writes:
> speculation_barrier for MIPS needs sync+jr.hb (r2+),
> so we implement __speculation_barrier in libgcc, like arm32 does.
Looks reasonable, but do you have a source for the fallback
pre-r2 handling? (Thanks for adding that btw, since I realise
it's not your focus here.)
Nit
HI Kito,
I see there have been many comments on the
"riscv_vector_preferred_simd_mode" hook, is there an updated version?
On 5/3/23 06:53, Kito Cheng wrote:
@@ -176,6 +178,46 @@ calculate_ratio (unsigned int sew, enum vlmul_type vlmul)
return ratio;
}
+/* Implement TARGET_VECTORIZE_PRE
RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.
This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Behavior can be specified using the -minline-atomics and
-mno-inline-at
The old legacy code allowed building ranges of unknown types so passes
like IPA could build and propagate VARYING. For now it's easiest to
allow the old behavior, it's not like you can do anything with these
ranges except build them and copy them.
Eventually we should convert all users of set_var
On Tue, May 02, 2023 at 05:32:04PM -0500, Segher Boessenkool wrote:
> On Wed, Apr 26, 2023 at 12:18:36PM -0400, Michael Meissner wrote:
> > * gcc/config/rs6000/genfusion.pl (gen_ld_cmpi_p10): Improve generation
> > of the ld and lwa instructions which use the DS encoding instead of D.
> >
aarch64_function_arg_alignment has traditionally taken the alignment
of a scalar type T from TYPE_ALIGN (TYPE_MAIN_VARIANT (T)). This is
supposed to discard any user alignment and give the alignment of the
underlying fundamental type.
PR109661 shows that this did the wrong thing for enums with
a
aarch64_function_arg_alignment has two related abi_break
parameters: abi_break for a change in GCC 9, and abi_break_packed
for a related follow-on change in GCC 13. In a sense, abi_break_packed
is a "subfix" of abi_break.
PR109661 now requires a third ABI break that is independent
of the other tw
On 5/3/23 08:33, Palmer Dabbelt wrote:
On Wed, 03 May 2023 08:13:23 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/3/23 08:14, Palmer Dabbelt wrote:
On Wed, 03 May 2023 02:49:41 PDT (-0700), richard.guent...@gmail.com
wrote:
On Wed, May 3, 2023 at 8:33 AM Jeff Law via Gcc-patches
wrote:
On Wed, 03 May 2023 08:13:23 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/3/23 08:14, Palmer Dabbelt wrote:
On Wed, 03 May 2023 02:49:41 PDT (-0700), richard.guent...@gmail.com wrote:
On Wed, May 3, 2023 at 8:33 AM Jeff Law via Gcc-patches
wrote:
On 5/2/23 14:34, Patrick O'Neill wrote:
GCC maintainers:
The following patch cleans up the definition for the
__builtin_altivec_vcmpnet. The current implementation implies that the
builtin is only supported on Power 9 since it is defined under the
Power 9 stanza. However the builtin has no ISA restrictions as stated
in the Power Vecto
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Tamar
> Christina via Gcc-patches
> Sent: Tuesday, May 2, 2023 8:08 AM
> To: Jeff Law ; gcc-patches@gcc.gnu.org
> Cc: nd ; bonz...@gnu.org; nero...@gcc.gnu.org;
> aol...@gcc.gnu.org; ralf.wi
On 5/3/23 08:14, Palmer Dabbelt wrote:
On Wed, 03 May 2023 02:49:41 PDT (-0700), richard.guent...@gmail.com wrote:
On Wed, May 3, 2023 at 8:33 AM Jeff Law via Gcc-patches
wrote:
On 5/2/23 14:34, Patrick O'Neill wrote:
> Is this OK for a backport to GCC-13 as well?
Let me sync with Richi
On 5/2/23 17:04, Christophe Lyon via Gcc-patches wrote:
On 5/2/23 11:18, Kyrylo Tkachov wrote:
Hi Christophe,
-Original Message-
From: Christophe Lyon
Sent: Tuesday, April 18, 2023 2:46 PM
To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
Richard Earnshaw ; Richard Sandiford
Cc: Chr
On Wed, 03 May 2023 07:37:07 PDT (-0700), mli...@suse.cz wrote:
It's pre-approved by Jakub.
Cheers,
Martin
Fixes:
gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function
[-Werror=return-type]
66 | [(set (attr "length") (const_int 4))])
| ^
PR target/109713
> -Original Message-
> From: Christophe Lyon
> Sent: Wednesday, May 3, 2023 3:37 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH v2 03/22] arm: [MVE intrinsics] Rework vreinterpretq
>
> This patch imp
This patch implements vreinterpretq using the new MVE intrinsics
framework.
The old definitions for vreinterpretq are removed as a consequence.
2022-09-08 Murray Steele
Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vreinterpretq_impl): New class.
It's pre-approved by Jakub.
Cheers,
Martin
Fixes:
gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function
[-Werror=return-type]
66 | [(set (attr "length") (const_int 4))])
| ^
PR target/109713
gcc/ChangeLog:
* config/riscv/sync.md: Add gcc_unreachab
On Wed, 03 May 2023 02:49:41 PDT (-0700), richard.guent...@gmail.com wrote:
On Wed, May 3, 2023 at 8:33 AM Jeff Law via Gcc-patches
wrote:
On 5/2/23 14:34, Patrick O'Neill wrote:
> Is this OK for a backport to GCC-13 as well?
Let me sync with Richi & Jakub. They're the release managers and
On Wed, 3 May 2023, Patrick Palka wrote:
> This patch makes us coerce the arguments of a variable template-id ahead
> of time, as we do for other template-ids, which allows us to immediately
> diagnose template parameter/argument kind mismatches and arity mismatches.
>
> Unfortunately this causes
On 03.05.23 14:59, Julian Brown wrote:
How does this version look?
Retested with offloading to nvptx.
LGTM (for mainline + GCC 13 backporting) but I have two tiny comments:
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 86e4515..322856a 100644
--- a/gcc/fortran/openmp.cc
+++
This patch makes us coerce the arguments of a variable template-id ahead
of time, as we do for other template-ids, which allows us to immediately
diagnose template parameter/argument kind mismatches and arity mismatches.
Unfortunately this causes a regression in cpp1z/constexpr-if20.C: coercing
th
On Tue, 2 May 2023 12:29:22 +0200
Tobias Burnus wrote:
> On 29.04.23 12:57, Julian Brown wrote:
> > This patch moves several tests introduced by the following patch:
> >
> >https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html
> >
>
> I believe you intent this as git log entry.
The following renames last_stmt to last_nondebug_stmt which is
what it really does.
Bootstrapped and tested on x86_64-unknown-linux-gnu. I'm going to
push this tomorrow if there are no comments.
Richard.
* tree-cfg.h (last_stmt): Rename to ...
(last_nondebug_stmt): ... this.
This is the last set of changes removing calls to last_stmt in favor of
*gsi_last_bb where this is obviously correct. As with the last changes
I tried to cleanup the code as far as dependences are concerned.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-loop-spl
> -Original Message-
> From: Stam Markianos-Wright
> Sent: Wednesday, May 3, 2023 1:35 PM
> To: Kyrylo Tkachov ; Andrea Corallo
> ; gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw
> Subject: [PATCH 10/10] arm testsuite: Shifts and get_FPSCR ACLE optimisation
> fixes
>
> Hi Kyrill,
>
>
> -Original Message-
> From: Stam Markianos-Wright
> Sent: Wednesday, May 3, 2023 1:19 PM
> To: Kyrylo Tkachov ; Andrea Corallo
> ; gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw
> Subject: Re: [PATCH 04/10] arm: Stop vadcq, vsbcq intrinsics from overwriting
> the FPSCR NZ flags
>
>
>
Hi Kyrill,
On 28/04/2023 17:58, Kyrylo Tkachov wrote:
-Original Message-
From: Andrea Corallo
Sent: Friday, April 28, 2023 12:30 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Earnshaw
; Stam Markianos-Wright
Subject: [PATCH 10/10] arm testsuite: Shifts and get_FPSCR ACL
Le mer. 3 mai 2023 à 20:22, Jonathan Wakely a écrit :
>
>
> On Wed, 3 May 2023 at 03:17, Kefu Chai via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> Hi Jonathan,
>>
>> Thank you for your review and suggestion. The change looks great!
>> Assigning a value with an immediate zero is indeed much f
On Fri, 28 Apr 2023, Andre Vieira (lists) wrote:
> This is a rebase of Joel's previous patch.
>
> This patch removes the old widen plus/minus tree codes which have been
> replaced by internal functions.
I guess that's obvious then. I wonder what we do to internal
fns in debug stmts? Looks like
On Wed, 3 May 2023 at 03:17, Kefu Chai via Libstdc++
wrote:
> Hi Jonathan,
>
> Thank you for your review and suggestion. The change looks great!
> Assigning a value with an immediate zero is indeed much faster.
>
> in v2:
>
> * revised the commit message a little bit, I found it a little bit
>
On 5/3/23 14:18, Andreas Schwab via Gcc-patches wrote:
> ../../gcc/config/riscv/sync.md: In function 'const char*
> output_479(rtx_def**, rtx_insn*)':
> ../../gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void
> function [-Werror=return-type]
>66 | [(set (attr "length") (
On 28/04/2023 17:45, Kyrylo Tkachov wrote:
Hi Andrea, Stam,
-Original Message-
From: Andrea Corallo
Sent: Friday, April 28, 2023 12:30 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Earnshaw
; Stam Markianos-Wright
Subject: [PATCH 04/10] arm: Stop vadcq, vsbcq intrinsics
../../gcc/config/riscv/sync.md: In function 'const char* output_479(rtx_def**,
rtx_insn*)':
../../gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void
function [-Werror=return-type]
66 | [(set (attr "length") (const_int 4))])
| ^
--
Andreas Schwab, SUSE Labs, sch...@
On Fri, 28 Apr 2023, Andre Vieira (lists) wrote:
> This patch replaces the existing tree_code widen_plus and widen_minus
> patterns with internal_fn versions.
>
> DEF_INTERNAL_OPTAB_HILO_FN is like DEF_INTERNAL_OPTAB_FN except it provides
> convenience wrappers for defining conversions that requi
On Fri, 28 Apr 2023, Andre Vieira (lists) wrote:
> Hi,
>
> I'm posting the patches separately now with ChangeLogs.
>
> I made the suggested changes and tried to simplify the code a bit further.
> Where internal to tree-vect-stmts I changed most functions to use code_helper
> to avoid having to c
On Wed, 3 May 2023, Thomas Schwinge wrote:
> Hi!
>
> This very likely isn't the only instance of such a kind of problem in the
> GCC testsuite ;-) -- but it's one that I've run into, and analyzed:
>
> On 2011-09-27T19:23:22+0200, Jan Hubicka wrote:
> > this patch updates testsuite to cover both
[Andrew, since you suggested this, is this what you had in mind?].
The equal_p method in vrange_storage is only used to compare ranges
that are the same type. No sense passing the type if it can be
determined from the range being compared.
gcc/ChangeLog:
* gimple-range-cache.cc (sbr_spa
Thanks.
On Wed, May 3, 2023, 11:17 Martin Liška wrote:
> Pushed to master as obvious.
>
> Martin
>
> PR tree-optimization/109693
>
> gcc/ChangeLog:
>
> * value-range-storage.cc (vrange_allocator::vrange_allocator):
> Remove unused field.
> * value-range-storage.h:
Hi Julian!
On 2023-04-29T03:57:41-0700, Julian Brown wrote:
> This patch moves several tests introduced by the following patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html
>
> into the proper location for OpenACC testing (thanks to Thomas for
> spotting my mistake!), an
On Tue, 2 May 2023 at 18:22, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 2 May 2023 at 17:32, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 2 May 2023 at 14:56, Richard Sandiford
> >> > wrote:
> >> >> > [aarch64] Improve code-gen for
Thanks all for comments, will work with kito to make it happen.
Pan
-Original Message-
From: Jeff Law
Sent: Wednesday, May 3, 2023 12:28 AM
To: Kito Cheng
Cc: Li, Pan2 ; gcc-patches@gcc.gnu.org;
juzhe.zh...@rivai.ai; Wang, Yanzhang ; Andrew Waterman
Subject: Re: [PATCH] RISC-V: Allo
Hi!
This very likely isn't the only instance of such a kind of problem in the
GCC testsuite ;-) -- but it's one that I've run into, and analyzed:
On 2011-09-27T19:23:22+0200, Jan Hubicka wrote:
> this patch updates testsuite to cover both fat and slim LTO when linker plugin
> is used [...]
This
OK, thanks :)
On Wed, May 3, 2023 at 6:55 PM Andreas Schwab via Gcc-patches
wrote:
>
> Now that we have support for inline subword atomic operations, it is no
> longer necessary to link against libatomic. This also fixes testsuite
> failures because the framework does not properly set up the lin
> @@ -275,6 +284,9 @@ poly_uint16 riscv_vector_chunks;
> /* The number of bytes in a vector chunk. */
> unsigned riscv_bytes_per_vector_chunk;
>
> +/* Prefer vf for auto-vectorizer. */
> +unsigned riscv_vectorization_factor;
> +
Drop this, we have riscv_autovec_lmul
> /* Index R is the small
Now that we have support for inline subword atomic operations, it is no
longer necessary to link against libatomic. This also fixes testsuite
failures because the framework does not properly set up the linker flags
for finding libatomic.
The use of atomic operations is also independent of the use
> @@ -176,6 +178,46 @@ calculate_ratio (unsigned int sew, enum vlmul_type vlmul)
>return ratio;
> }
>
> +/* Implement TARGET_VECTORIZE_PREFERRED_SIMD_MODE for RVV. */
> +
> +machine_mode
> +riscv_vector_preferred_simd_mode (scalar_mode mode)
JuZhe's patch[1] has been implemented and his vers
Thanks, committed to trunk!
Thanks, committed to trunk!
Thanks, committed to trunk!
committed
On Thu, Apr 27, 2023 at 10:02 PM Kito Cheng via Gcc-patches
wrote:
>
> `vr`, `vm` and `vd` constarint for vector register constarint, those 3
> constarint has implemented on LLVM as well.
>
> gcc/ChangeLog:
>
> * doc/md.texi (RISC-V): Add vr, vm, vd constarint.
>
> ---
>
> V2 ch
FYI:
This PR described the syntax of fli instruction, which is implemented
in LLVM, and the latest binutils patch (IIRC :P):
https://github.com/riscv-non-isa/riscv-asm-manual/pull/85
On Fri, Feb 3, 2023 at 2:06 PM Richard Biener via Gcc-patches
wrote:
>
> When cse_insn prunes src{,_folded,_eqv_here,_related} with the
> equivalence set in the *_same_value chain it also searches for
> an equivalence to the destination of the instruction with
>
> /* This is the same as
On Fri, Feb 3, 2023 at 3:07 PM Richard Biener via Gcc-patches
wrote:
>
> The RTL CSE hash table has a fixed number of buckets (32) each
> with a linked list of entries with the same hash value. The
> actual hash values are computed using hash_rtx which uses adds
> for mixing and adds the rtx CODE
Hi all,
Further straightforward patch for the various halving intrinsics with or
without rounding, plus tests.
Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf.
Pushing to trunk.
Thanks,
Kyrill
gcc/ChangeLog:
PR target/99195
* config/aarch64/aarch64-simd
Hi all,
Continuing the, almost mechanical, series this patch adds annotation for some
of the simple
floating-point patterns we have, and adds testing to ensure that redundant
zeroing instructions
are eliminated.
Bootstrapped and tested on aarch64-none-linux-gnu and also aarch64_be-none-elf.
Pus
When backporting the PR109473 fix I failed to realize its testcase
will run into an unrelated similar bug. With GCC 12 the code has
seen substantial refactoring so the following applies a local fix
to make sure we are using the correct types when building initial
values for reductions.
Bootstrapp
On Wed, May 3, 2023 at 8:28 AM Andrew Pinski wrote:
>
> On Tue, May 2, 2023 at 11:14 PM Richard Biener
> wrote:
> >
> > On Wed, May 3, 2023 at 12:04 AM Andrew Pinski wrote:
> > >
> > > On Tue, May 2, 2023 at 5:26 AM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > On Sun, Apr 30, 202
On Wed, May 3, 2023 at 8:33 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/2/23 14:34, Patrick O'Neill wrote:
> > Is this OK for a backport to GCC-13 as well?
> Let me sync with Richi & Jakub. They're the release managers and this
> doesn't fall under the usual rules for things that can be backp
On Fri, 28 Apr 2023 at 22:19, Florian Weimer via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> GCC_11.0 is an aarch64-specific outlier.
>
> * doc/xml/manual/abi.xml (abi.versioning.history): Add
> GCC_7.0.0, GCC_9.0.0, GCC_11.0, GCC_12.0.0, GCC_13.0.0 for
> libgcc_s.
>
OK fo
Pushed to master as obvious.
Martin
PR tree-optimization/109693
gcc/ChangeLog:
* value-range-storage.cc (vrange_allocator::vrange_allocator):
Remove unused field.
* value-range-storage.h: Likewise.
---
gcc/value-range-storage.cc | 1 -
gcc/value-range-storage.h
On 5/2/23 18:31, Kyrylo Tkachov wrote:
-Original Message-
From: Christophe Lyon
Sent: Tuesday, April 18, 2023 2:46 PM
To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
Richard Earnshaw ; Richard Sandiford
Cc: Christophe Lyon
Subject: [PATCH 08/22] arm: [MVE intrinsics] rework vaddq v
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, April 18, 2023 2:46 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 21/22] arm: [MVE intrinsics] factorize several binary
> operations
>
>
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, April 18, 2023 2:46 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 20/22] arm: [MVE intrinsics] factorize several binary _m_n
> operations
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, April 18, 2023 2:46 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 19/22] arm: [MVE intrinsics] factorize several binary _n
> operations
>
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, April 18, 2023 2:46 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 18/22] arm: [MVE intrinsics] factorize several binary_m
> operations
>
1 - 100 of 104 matches
Mail list logo
