On Thu, 2023-11-02 at 09:19 -0400, David Malcolm wrote:
[...snip...]
I eliminated the dependency on the c-pragma.cc changes from this patch,
updated it for diagnostic_context becoming a class, and pushed it to
trunk as r14-5118-gc5db4d8ba5f3de (after re-testing it).
For reference, here's what I
Committed, thanks Juzhe.
Pan
From: 钟居哲
Sent: Saturday, November 4, 2023 9:43 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Remove HF modes of FP to INT rounding autovec
LGTM.
This patch:
- converts "struct diagnostic_context" to "class diagnostic_context".
- ensures all data members have an "m_" prefix, except for "printer",
which has so many uses that renaming would be painful.
- makes most of the data members private
- converts much of the diagnostic_* functions to
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-04 09:41
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Remove HF modes of FP to INT rounding autovec
From: Pan Li
The [i|l|ll][rint|round|ceil|floor] internal functions are
defined as
From: Pan Li
The [i|l|ll][rint|round|ceil|floor] internal functions are
defined as DEF_INTERNAL_FLT_FN instead of DEF_INTERNAL_FLT_FLOATN_FN.
Then the *f16 (N=16 of FLOATN) format of these functions are not
available when try to get the ifn from the given cfn in the
vectorizable_call. Aka:
LGTM but I'd like Marek to approve it.
On Fri, Nov 3, 2023, 3:12 PM Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because with -Wno-attributes=foo::no_sanitize
> (but generally any other non-gnu namespace and some gnu well known
> attribute
> name within that other namespace) the
On Thu, Oct 26, 2023 at 05:55:56PM +0200, Richard Biener wrote:
>
>
> > Am 24.10.2023 um 21:09 schrieb Marek Polacek :
> >
> > On Tue, Oct 24, 2023 at 09:22:25AM +0200, Richard Biener wrote:
> >>> On Mon, Oct 23, 2023 at 9:26 PM Marek Polacek wrote:
> >>>
> >>> On Thu, Oct 19, 2023 at
> Ah, OK. IMO it's better to keep the optab operands the same as the IFN
> operands, even if that makes things inconsistent with vcond_mask.
> vcond_mask isn't really a good example to follow, since the operand
> order is not only inconsistent with the IFN, it's also inconsistent
> with the
On Fri, Nov 03, 2023 at 07:56:20PM +0100, Harald Anlauf wrote:
> Dear all,
>
> this is a rather weird bug with a very simple fix. If a procedure pointer
> is referenced in a CALL, a symbol was created shadowing the original
> declaration if it was host-associated. Funnily, this affected only
>
On 3 November 2023 14:38:06 CET, Jeff Law wrote:
>
>
>On 11/3/23 06:54, Maxim Kuvyrkov wrote:
>> gotools/ChangeLog:
>>
>> * Makefile.am: Update "Running ..." output
>> * Makefile.in: Regenerate.
>OK. Thanks for running down the differences in the autogenerated bits.
Many thanks
On 17/10/2023 2:12 pm, Tobias Burnus wrote:
C++11 (and C23) attribute do not seem to be properly handled:
[[omp::decl (declare target,indirect(1))]]
int foo(void) { return 5; }
[[omp::decl (declare target indirect)]]
int bar(void) { return 8; }
[[omp::directive (begin declare
This patch implements a arc_fold_builtin target hook to allow ARC
builtins to be folded at the tree-level. Currently this function
converts __builtin_arc_swap into a LROTATE_EXPR at the tree-level,
and evaluates __builtin_arc_norm and __builtin_arc_normw of integer
constant arguments at
Yes, after today’s discussion, I think we agreed on
1. Passing the size field by reference to .ACCESS_WITH_SIZE as jakub suggested.
2. Then the compiler should be able to always use the latest value of size
field for the reference to FAM.
As a result, no need to add code for pointer
> On Nov 2, 2023, at 8:13 PM, Bill Wendling wrote:
>
> On Thu, Nov 2, 2023 at 1:00 AM Richard Biener
> wrote:
>>
>> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wrote:
>>>
>>>
>>>
On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
On Tue, 31 Oct 2023, Qing Zhao wrote:
Hi!
The following testcase ICEs, because with -Wno-attributes=foo::no_sanitize
(but generally any other non-gnu namespace and some gnu well known attribute
name within that other namespace) the FEs don't really parse attribute
arguments of such attribute, but lookup_attribute_spec is non-NULL
Hi,
The current codegen code to support VF's that are multiples of a
simdclone simdlen rely on BIT_FIELD_REF to create multiple input
vectors. This does not work for non-constant simdclones, so we should
disable using such clones when
the VF is a multiple of the non-constant simdlen until we
On Thu, Nov 02, 2023 at 10:23:27PM -0400, Jason Merrill wrote:
> Under the existing diagnostic I'd like to distinguish the different cases
> more, e.g.
>
> "multicharacter literal with %d characters exceeds 'int' size of %d bytes"
> "multicharacter literal cannot have an encoding prefix"
Ok.
Dear all,
this is a rather weird bug with a very simple fix. If a procedure pointer
is referenced in a CALL, a symbol was created shadowing the original
declaration if it was host-associated. Funnily, this affected only
references of the procedure pointer after the first CALL.
Regtested on
Am 02.11.23 um 12:54 schrieb Roger Sayle:
This patch provides non-looping implementations for more SImode (32-bit)
and PSImode (24-bit) shifts on AVR. For most cases, these are shorter
and faster than using a loop, but for a few (controlled by optimize_size)
Maybe this should also adjust
On 11/3/23 00:44, waffl3x wrote:
That leaves 2, 4, and 5.
2. I am pretty sure xobj functions should have the struct they are a
part of recorded as the method basetype member. I have already checked
that function_type and method_type are the same node type under the
hood and it does appear to
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-5112-gae8abcb81ed814.
gcc/ChangeLog:
* diagnostic.cc (diagnostic_initialize): Update for consolidation
of group-based fields.
On 11/2/23 11:28, Marek Polacek wrote:
On Sat, Oct 14, 2023 at 12:56:11AM -0400, Jason Merrill wrote:
On 10/10/23 13:20, Marek Polacek wrote:
On Tue, Aug 29, 2023 at 03:26:46PM -0400, Jason Merrill wrote:
On 8/23/23 15:49, Marek Polacek wrote:
+struct A {
+ int x;
+ int y = id(x);
+};
+
igen::half]':
:13:20: error: could not convert '0' from 'int' to 'const Eigen::half&'
13 | z1 = std::polar(one);
| ~~^
||
|int
:13:20: note: when instantiating default argument for call to
'std::complex<_Tp>
On Fri, 3 Nov 2023, Richard Biener wrote:
> The following tries to clarify the __builtin_constant_p documentation,
> stating that the argument expression is not evaluated and side-effects
> are discarded. I'm struggling to find the correct terms matching
> what the C language standard would call
When we compare a range against a constant for equality or inequality,
there is currently no attempt made to utilize the known bits.
This patch adds a method to the irange_bitmask class to ask if a
specific value satisfies the known bit pattern. Operators equal and
not_equal then utilize it
WHen we set bitmasks indicating known zero or one bits, we see some
"obvious" things once in a while that are easy to prevent. ie
unsigned int [2, +INF] MASK 0xfffe VALUE 0x1
the range [2, 2] is obviously impossible since the final bit must be a
one. This doesn't usually cause us too
> On Nov 3, 2023, at 12:30 PM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 04:20:57PM +, Qing Zhao wrote:
>> So, based on the discussion so far, We will define the .ACCESS_WITH_SIZE as
>> following:
>>
>> .ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, ACCESS_MODE)
>>
>> INTERNAL_FN
On Fri, Nov 03, 2023 at 04:20:57PM +, Qing Zhao wrote:
> So, based on the discussion so far, We will define the .ACCESS_WITH_SIZE as
> following:
>
> .ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, ACCESS_MODE)
>
> INTERNAL_FN (ACCESS_WITH_SIZE, ECF_LEAF | ECF_NOTHROW, NULL)
>
> which
So, based on the discussion so far, We will define the .ACCESS_WITH_SIZE as
following:
.ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, ACCESS_MODE)
INTERNAL_FN (ACCESS_WITH_SIZE, ECF_LEAF | ECF_NOTHROW, NULL)
which returns the “REF_TO_OBJ" same as the 1st argument;
1st argument “REF_TO_OBJ":
On Wed, Sep 27, 2023 at 03:27:30PM +0100, Alex Coplan wrote:
> Hi,
>
> This is a v4 patch to address Jason's feedback here:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630911.html
>
> w.r.t. v3 it just removes a comment now that some uncertainty around
> cxx_binary_literals has
The patch generalizes address register class handling to allow multiple
register classes. For APX EGPR targets, some instructions do not support
GPR32 registers, so it is necessary to limit address register set to
avoid them. The same situation happens for instructions with high registers,
where
The branch-protection types are target specific, not the same on arm
and aarch64. This currently affects pac-ret+b-key, but there will be
a new type on aarch64 that is not relevant for arm.
gcc/ChangeLog:
* config/aarch64/aarch64-opts.h (enum aarch64_key_type): Rename to ...
yn Sat, 28 Oct 2023, Feng Jisen wrote:
> This patch remove a redundant partial specialization in class _Nth_type.
> For the original metafunction _Nth_type code,
> # 0
> template struct _Nth_type<0, _Tp0,
> _Rest...>
> { using type = _Tp0; };
> # 1
> template
> struct
The tests manipulate the return address in abitest-2.h and thus not
compatible with -mbranch-protection=pac-ret+leaf or
-mbranch-protection=gcs.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/aapcs64/func-ret-1.c: Disable branch-protection.
*
EH returns no longer rely on clobbering the return address on the stack
so forcing a stack frame is not necessary.
This does not actually change the code gen for the unwinder since there
are calls before the EH return.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
Refactor the parsing to have a single API and fix a few parsing issues:
- Different handling of "bti+none" and "none+bti": these should be
rejected because "none" can only appear alone.
- Accepted empty strings such as "bti++pac-ret" or "bti+", this bug
was caused by using strtok_r.
-
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/eh_return-2.c: New test.
* gcc.target/aarch64/eh_return-3.c: New test.
---
v2: check-function-bodies in eh_return-3.c
(this is not very robust, but easier to read)
---
.../gcc.target/aarch64/eh_return-2.c | 9 ++
On aarch64 this caused ICE with pragma push_options since
commit ae54c1b09963779c5c3914782324ff48af32e2f1
Author: Wilco Dijkstra
CommitDate: 2022-06-01 18:13:57 +0100
AArch64: Cleanup option processing code
The failure is at pop_options:
internal compiler error: ‘global_options’
The expected way to handle eh_return is to pass the stack adjustment
offset and landing pad address via
EH_RETURN_STACKADJ_RTX
EH_RETURN_HANDLER_RTX
to the epilogue that is shared between normal return paths and the
eh_return paths. EH_RETURN_HANDLER_RTX is the stack slot of the
return
I'm working on Guarded Control Stack support for aarch64 and have a
set of patches that are needed for GCS but seem useful without it so
makes sense to review them separately from the rest of the GCS work.
previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628123.html
> On Nov 3, 2023, at 10:46 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 02:32:04PM +, Qing Zhao wrote:
>>> Why? It doesn't really matter. The options are
>>> A. p is at [2] associated with and int type (or size of int
>>> or whatever); .ACCESS_WITH_SIZE can't be pure,
>>
>>
On Tue, 3 May 2022, Jason Merrill wrote:
> On 5/2/22 14:50, Patrick Palka wrote:
> > Currently when checking the constraints of a class template, we do so in
> > the context of the template, not the specialized type. This is the best
> > we can do for a primary template since the specialized
Hi!
On 2019-06-07T15:39:36+0100, Andrew Stubbs wrote:
> This patch creates a new gthread model for AMD GCN devices.
>
> For now, there's just enough support for libgfortran to use mutexes in
> its I/O routines. The rest can be added at a later time, if at all.
Hmm, interestingly we don't have
Hello Richard:
On 03/11/23 7:06 pm, Richard Biener wrote:
> On Fri, Nov 3, 2023 at 11:20 AM Ajit Agarwal wrote:
>>
>> Hello Richard:
>>
>> On 03/11/23 12:51 pm, Richard Biener wrote:
>>> On Thu, Nov 2, 2023 at 9:50 PM Ajit Agarwal wrote:
Hello All:
> [...]
High
The following exercise otherwise not exercised paths in the
vectorizer peeling code, resulting in CPU 2017 build ICEs
when patching but no fallout in the testsuite.
tested on x86_64-unknown-linux-gnu, pushed.
* gfortran.dg/20231103-1.f90: New testcase.
* gfortran.dg/20231103-2
On Fri, Nov 03, 2023 at 02:32:04PM +, Qing Zhao wrote:
> > Why? It doesn't really matter. The options are
> > A. p is at [2] associated with and int type (or size of int
> > or whatever); .ACCESS_WITH_SIZE can't be pure,
>
> .ACCESS_WITH_SIZE will only load the size from its address, no
> On Nov 3, 2023, at 2:22 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 07:07:36AM +0100, Martin Uecker wrote:
>> Am Donnerstag, dem 02.11.2023 um 17:28 -0700 schrieb Bill Wendling:
>>> On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao wrote:
Thanks a lot for raising these issues.
On Fri, 3 Nov 2023 at 13:51, Ben Sherman wrote:
>
> > This was https://gcc.gnu.org/PR109703 (and several duplicates) and
> > should already be fixed in all affected branches. Where are you seeing
> > this?
>
> I saw this on 13.1.0 and could not find the bug report or fix for it, so I
> didn't
During analyzing PR111950 I found the loop live operation code-gen
odd, in particular only replacing a single PHI but then adjusting
possibly remaining PHIs afterwards where there shouldn't really
be any out-of-loop uses of the scalar in-loop def left.
Bootstrapped and tested together with
Jonathan Wakely writes:
> On Thu, 2 Nov 2023 at 19:58, Ben Sherman
> wrote:
>>
>> Tested on x86_64-pc-linux-gnu, please let me know if there's anything
>> else needed. I haven't contributed before and don't have write access, so
>> apologies if I've missed anything.
>
> This was
> This was https://gcc.gnu.org/PR109703 (and several duplicates) and
> should already be fixed in all affected branches. Where are you seeing
> this?
I saw this on 13.1.0 and could not find the bug report or fix for it, so I
didn't realize it had already been fixed. Sorry about that.
This
Success Your items will be delivered soon Verified Shipping details
Order status update Delighted
Invoice52377.pdf
Description: Binary data
On 11/3/23 06:54, Maxim Kuvyrkov wrote:
The only difference compared to v1 is using vanilla automake 1.15.1
to regenerate Makefile.in.
I'll merge this as obvious if no-one objects in a day.
===
... to restore compatability with validate_failures.py .
The testsuite script
On Fri, Nov 3, 2023 at 11:20 AM Ajit Agarwal wrote:
>
> Hello Richard:
>
> On 03/11/23 12:51 pm, Richard Biener wrote:
> > On Thu, Nov 2, 2023 at 9:50 PM Ajit Agarwal wrote:
> >>
> >> Hello All:
> >>
[...]
> >>
> >> High register pressure region is the region where there are live-in of
> >>
On Fri, Nov 3, 2023 at 2:21 PM Hongyu Wang wrote:
>
> Thanks for the fix and refinement!
>
> I think the addr attr looks more reasonable, just one small issue that
> EGPR was not only encoded with REX2 prefix, there are several
> instructions that encode EGPR using evex prefix. So I think
>
On 03.11.23 13:54, Martin Jambor wrote:
when developing an otherwise unrelated patch I've discovered that the
fnspec for the Fortran library function generate_error is wrong. It is
currently ". R . R " where the first R describes the first parameter
and means that it "is only read and does not
Thanks for the fix and refinement!
I think the addr attr looks more reasonable, just one small issue that
EGPR was not only encoded with REX2 prefix, there are several
instructions that encode EGPR using evex prefix. So I think
addr_rex2/addr_rex may be a misleading note. I'd prefer still using
The only difference compared to v1 is using vanilla automake 1.15.1
to regenerate Makefile.in.
I'll merge this as obvious if no-one objects in a day.
===
... to restore compatability with validate_failures.py .
The testsuite script validate_failures.py expects
"Running ..." to extract values,
Hi,
when developing an otherwise unrelated patch I've discovered that the
fnspec for the Fortran library function generate_error is wrong. It is
currently ". R . R " where the first R describes the first parameter
and means that it "is only read and does not escape." The function
itself,
On Fri, Nov 3, 2023 at 6:34 PM Uros Bizjak wrote:
>
> The patch generalizes address register class handling to allow multiple
> address register classes. For APX EGPR targets, some instructions can't be
> encoded with REX2 prefix, so it is necessary to limit address register
> class to avoid
On AArch64, can_change_mode_class and modes_tieable_p are
mostly answering the same questions:
(a) Do two modes have the same layout for the bytes that are
common to both modes?
(b) Do all valid subregs involving the two modes behave as
GCC would expect?
(c) Is there at least one
On Thu, Oct 26, 2023 at 07:41:09PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > This patch adds support for the "target_version" attribute to the middle
> > end and the C++ frontend, which will be used to implement function
> > multiversioning in the aarch64 backend.
> >
> > Note
This patch removes a can_create_pseudo_p condition from
*cmov_uxtw_insn_insv, bringing it in line with *cmov_insn_insv.
The constraints correctly describe the requirements.
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/
* config/aarch64/aarch64.md (*cmov_uxtw_insn_insv): Remove
Committed as passed the regression test of aarch64, thanks Richard.
Pan
-Original Message-
From: Richard Biener
Sent: Friday, November 3, 2023 3:36 PM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [tree-optimization/111721 V2] VECT: Support SLP
On Fri, Nov 03, 2023 at 12:03:06PM +0100, Thomas Schwinge wrote:
> --- a/gcc/testsuite/g++.dg/cpp0x/catch1.C
> +++ b/gcc/testsuite/g++.dg/cpp0x/catch1.C
> @@ -1,5 +1,6 @@
> // PR c++/53371
> // { dg-do compile { target c++11 } }
> +// Explicit { dg-require-effective-target exceptions_enabled }
Hi!
On 2023-06-15T18:04:04+0200, I wrote:
> [...], OK to push the attached
> "Skip a number of C++ 'g++.dg/tree-prof/' test cases for '-fno-exceptions'
> testing"?
Pushed to master branch commit 3881d010dca9b5db5301f28e4a1e3a8e4bc40faa
"Skip a number of 'g++.dg/tree-prof/' test cases for
Hi!
On 2023-06-15T17:47:57+0200, I wrote:
> [...], OK to push the attached
> "Skip a number of C++ "split files" test cases for '-fno-exceptions' testing"?
The 'g++.dg/lto/' parts of this pushed to master branch in
commit 94782ed70796427e6f4b15b1c2df91cd7bef28e8
"Skip a number of 'g++.dg/lto/'
Hi!
On 2023-06-15T17:47:57+0200, I wrote:
> [...], OK to push the attached
> "Skip a number of C++ "split files" test cases for '-fno-exceptions' testing"?
The 'g++.dg/compat/' parts of this pushed to master branch in
commit e5919951b8cb0dc8af5b80dc747416fb60a9835b
"Skip a number of
Hi!
On 2023-09-08T15:30:50+0200, I wrote:
> GCC/C++ front end maintainers, please provide input on the overall
> approach here:
Jason verbally ACKed this at the GNU Tools Cauldron 2023.
> On 2023-06-15T17:15:54+0200, I wrote:
>> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
>>> On Tue, 6
The following removes a bogus assert constraining the uses that
could appear when a built from scalar defs SLP node constrains
code generation in a way so earlier uses of the vector CTOR
components fail to get vectorized. We can't really constrain the
operation such use appears in.
Bootstrapped
Hi Jason,
On 26/10/2023 17:06, Jason Merrill wrote:
> On 10/25/23 06:28, Alex Coplan wrote:
> > On 11/10/2023 14:31, Alex Coplan wrote:
> > > On 27/09/2023 15:27, Alex Coplan wrote:
> > > > Hi,
> > > >
> > > > This is a v4 patch to address Jason's feedback here:
> > > >
The following avoids hoisting expressions that may invoke undefined
behavior and are not computed on all paths. This is realized by
noting that we have to avoid materializing expressions as part
of hoisting that are not part of the set of expressions we have
found eligible for hoisting. Instead
The patch generalizes address register class handling to allow multiple
address register classes. For APX EGPR targets, some instructions can't be
encoded with REX2 prefix, so it is necessary to limit address register
class to avoid REX2 registers. The same situation happens for instructions
Hello Richard:
On 03/11/23 12:51 pm, Richard Biener wrote:
> On Thu, Nov 2, 2023 at 9:50 PM Ajit Agarwal wrote:
>>
>> Hello All:
>>
>> Currently code sinking heuristics are based on profile data like
>> basic block count and sink frequency threshold. We have removed
>> such heuristics and added
On Fri, 3 Nov 2023, Andre Vieira (lists) wrote:
>
>
> On 03/11/2023 07:31, Richard Biener wrote:
>
> >
> > OK.
> >
> > I do wonder about the gfortran testsuite adjustments though.
> >
> > !GCC$ builtin (sin) attributes simd (inbranch)
> >
> >! this should not be using simd clone
> >
On 03/11/2023 07:31, Richard Biener wrote:
OK.
I do wonder about the gfortran testsuite adjustments though.
!GCC$ builtin (sin) attributes simd (inbranch)
! this should not be using simd clone
y4 = sin(x8)
previously we wouldn't vectorize this as no notinbranch simd function
is
gcc/ChangeLog:
* doc/md.texi: Add mask_len_strided_load/mask_len_strided_store optab.
* optabs.def (OPTAB_D): Ditto.
---
gcc/doc/md.texi | 27 +++
gcc/optabs.def | 2 ++
2 files changed, 29 insertions(+)
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
On Fri, 3 Nov 2023 at 03:04, Ian Lance Taylor wrote:
>
> The libbacktrace sources, as used by libstdc++-v3, fail to correctly
> determine whether the system supports dl_iterate_phdr. The issue is
> that the libbacktrace configure assumes that _GNU_SOURCE is defined
> during compilation, but the
Robin Dapp writes:
>> Could you explain why a special expansion is needed? (Sorry if you already
>> have and I missed it, bit overloaded ATM.) What does it do that is
>> different from what expand_fn_using_insn would do?
>
> All it does (in excess) is shuffle the arguments - vcond_mask_len has
Missed this one.
Ok, please proceed with the commit.
Thank you for your contribution,
Claudiu
On Sat, Oct 28, 2023 at 4:05 PM Roger Sayle wrote:
>
>
> This patch improves the code generated for X << 1 (and for X + X) when
> X is 64-bit DImode, using the same two instruction code sequence used
> Could you explain why a special expansion is needed? (Sorry if you already
> have and I missed it, bit overloaded ATM.) What does it do that is
> different from what expand_fn_using_insn would do?
All it does (in excess) is shuffle the arguments - vcond_mask_len has the
mask as third operand
gcc/ChangeLog:
* config/loongarch/lsx.md: Fix instruction name typo in
lsx_vreplgr2vr_ template.
---
gcc/config/loongarch/lsx.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/loongarch/lsx.md b/gcc/config/loongarch/lsx.md
index
Hi Simon,
In addition to the non portable issues already mentioned, this change isn't OK
also
for other reasons.
Basically this function is global and decides once for all on the case
sensitivity, while
the case sensitiviy is on a per filsystem basis as you noted.
So without changing
On Fri, 3 Nov 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> Is this following reasonable ?
>
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index fab2513105a..8d1cdad1607 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -5094,6 +5094,20 @@ Bit @var{i} of the mask is set if
On Fri, 3 Nov 2023, juzhe.zh...@rivai.ai wrote:
> Hi?Richi.
>
> >> Element @var{i}. I think we don't want to document 'undefined' but
> >> rather match mask_gather_load and say the result should be zero.
>
> I am confused here, will vectorizer depend on zero inactive value ?
I don't think it
Hi, Richi.
Is this following reasonable ?
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index fab2513105a..8d1cdad1607 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -5094,6 +5094,20 @@ Bit @var{i} of the mask is set if element @var{i} of the
result should
be loaded from memory and
Ping #2
| Date: Wed, 18 Oct 2023 20:06:20 -0400
| From: Michael Meissner
| Subject: [PATCH 6/6] PowerPC: Add support for 1,024 bit DMR registers.
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633516.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA,
Ping #2
| Date: Wed, 18 Oct 2023 20:04:44 -0400
| From: Michael Meissner
| Subject: [PATCH 5/6] PowerPC: Switch to dense math names for all MMA
operations.
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633515.html
--
Michael Meissner, IBM
PO Box 98, Ayer,
Ping #2
| Date: Wed, 18 Oct 2023 20:01:54 -0400
| From: Michael Meissner
| Subject: [PATCH 3/6] PowerPC: Add support for accumulators in DMR registers.
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633514.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts,
Ping #2
| Date: Wed, 18 Oct 2023 20:00:18 -0400
| From: Michael Meissner
| Subject: [PATCH 2/6] PowerPC: Make -mcpu=future enable
-mblock-ops-vector-pair.
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633512.html
--
Michael Meissner, IBM
PO Box 98, Ayer,
Hi，Richi.
>> Element @var{i}. I think we don't want to document 'undefined' but
>> rather match mask_gather_load and say the result should be zero.
I am confused here, will vectorizer depend on zero inactive value ?
Since RVV load/store doesn't touch the inactive(tail or unmasked) elements, I
Ping #2
| Date: Wed, 18 Oct 2023 19:58:56 -0400
| From: Michael Meissner
| Subject: Re: [PATCH 1/6] PowerPC: Add -mcpu=future option
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633511.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email:
Ping #2
| Date: Fri, 13 Oct 2023 19:41:13 -0400
| From: Michael Meissner
| Subject: [PATCH] Power10: Add options to disable load and store vector pair.
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632987.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts,
Hi Segher,
I have incorporated changes in the code as per the review comments provided by
you
for version 2 of the patch. Please review.
Regards,
Surya
rs6000/p8swap: Fix incorrect lane extraction by vec_extract() [PR106770]
In the routine rs6000_analyze_swaps(), special handling of
On Fri, 3 Nov 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> The following is strided load/store doc:
>
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index fab2513105a..4f0821a291d 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -5094,6 +5094,22 @@ Bit @var{i} of the mask
On Fri, 3 Nov 2023, Juzhe-Zhong wrote:
> This patch fixes following FAILs for RVV:
> FAIL: gcc.dg/vect/vect-gather-1.c -flto -ffat-lto-objects scan-tree-dump
> vect "Loop contains only SLP stmts"
> FAIL: gcc.dg/vect/vect-gather-1.c scan-tree-dump vect "Loop contains only SLP
> stmts"
>
>
On Thu, 2 Nov 2023, Andre Vieira (lists) wrote:
> Hi,
>
> In a previous patch I did most of the work for this, but forgot to change the
> check for number of arguments matching between call and simdclone. This check
> should accept calls without a mask to be matched against simdclones with mask
On Thu, Nov 2, 2023 at 9:50 PM Ajit Agarwal wrote:
>
> Hello All:
>
> Currently code sinking heuristics are based on profile data like
> basic block count and sink frequency threshold. We have removed
> such heuristics and added register pressure heuristics based on
> live-in and live-out of
The following tries to clarify the __builtin_constant_p documentation,
stating that the argument expression is not evaluated and side-effects
are discarded. I'm struggling to find the correct terms matching
what the C language standard would call things so I'd appreciate
some help here.
OK for
Hi, Richi.
The following is strided load/store doc:
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index fab2513105a..4f0821a291d 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -5094,6 +5094,22 @@ Bit @var{i} of the mask is set if element @var{i} of the
result should
be loaded from
1 - 100 of 107 matches
Mail list logo
