Hi!
On Mon, Sep 16, 2024 at 11:40:45PM -0400, Michael Meissner wrote:
> With this patch, GCC now realizes that the vector shift instructions will look
> at the bottom 6 bits for the shift count, and it can use either a VSPLTISW or
> XXSPLTIB instruction to load the shift count.
Do we do something
From: kelefth
The following function:
int foo(int *a, int j)
{
int k = j - 1;
return a[j - 1] == a[k];
}
does not fold to `return 1;` using -O2 or higher. The cause of this is that
the expression `4 * j + (-4)` for the index computation is not folded to
`4 * (j - 1)`. Existing simplificatio
Thanks for the feedback.
I have sent a new version (
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663104.html).
On Tue, Sep 10, 2024 at 2:53 PM Richard Biener
wrote:
> On Fri, Sep 6, 2024 at 2:44 PM wrote:
> >
> > From: kelefth
> >
> > The following function:
> >
> > int foo(int *a
> On 16 Sep 2024, at 16:32, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> "Pengxuan Zheng (QUIC)" writes:
>>> On Thu, Sep 12, 2024 at 2:53 AM Pengxuan Zheng
>>> wrote:
SVE's INDEX instruction can be used to populate vectors by values
Hi Richard,
> On 10 Sep 2024, at 9:33 pm, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Thu, Sep 5, 2024 at 3:19 AM Kugan Vivekanandarajah
> wrote:
>>
>> Thanks for the explanation.
>>
>>
>>> On 2 Sep 2024, at 9:47 am, Andrew Pinski wrote:
>>>
Hi Jason,
Apologies for the back and forth and thanks for your patience!
On 5 Sep 2024, at 19:00, Jason Merrill wrote:
> On 9/5/24 7:02 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 4 Sep 2024, at 18:09, Jason Merrill wrote:
>>
>>> On 9/1/24 2:51 PM, Simon Martin wrote:
Hi Jason,
On Tue, Sep 17, 2024 at 9:57 AM Kyrylo Tkachov wrote:
>
>
>
> > On 16 Sep 2024, at 16:32, Richard Sandiford
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > "Pengxuan Zheng (QUIC)" writes:
> >>> On Thu, Sep 12, 2024 at 2:53 AM Pengxuan Zheng
> >>> wrote:
The Combine Pass may generate zero_extract instructions that are out of range.
Drawing from other architectures like AArch64, we should impose restrictions
on the "*th_extu4" pattern.
gcc/
* config/riscv/thead.md (*th_extu4): Fix th.extu
operands exceeding range on rv32.
*
> On 17 Sep 2024, at 10:52, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, Sep 17, 2024 at 9:57 AM Kyrylo Tkachov wrote:
>>
>>
>>
>>> On 16 Sep 2024, at 16:32, Richard Sandiford
>>> wrote:
>>>
>>> External email: Use caution opening lin
On Sat, Sep 14, 2024 at 08:58:28PM +0200, Jakub Jelinek wrote:
> if (has_counted_by_object (e_p->value))
> expr.value = get_counted_by_ref (e_p->value);
> else if (in_typeof && TREE_CODE (e_p->value) == COMPONENT_REF)
> {
> tree counted_by_t
As recently implemented for svdiv, this patch folds svmul to a zero
vector if one of the operands is a zero vector. This transformation is
applied if at least one of the following conditions is met:
- the first operand is all zeros or
- the second operand is all zeros, and the predicate is ptrue or
The following restores the use of .SELECT_VL for testcases where it
is safe to use even when using SLP. I've for now restricted it
to single-lane SLP plus optimistically allow store-lane nodes
and assume single-lane roots are not widened but at most to
load-lane who should be fine.
Bootstrap and
On Tue, Sep 17, 2024 at 10:31 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> > On 10 Sep 2024, at 9:33 pm, Richard Biener
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Thu, Sep 5, 2024 at 3:19 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Than
Hi Tobias!
On 2024-09-15T00:32:21+0200, Tobias Burnus wrote:
> The idea of link variables is to replace he full device variable by a
> pointer, permitting to map only parts of the variable to the device,
> saving memory.
>
> However, having a pointer permits for (unified) shared memory to point
This patch updates more web links from nongnu to Github.
The http://www.nongnu.org/avr links still worked, but the
"super project" seems to be deserted. Instead, it now links:
*
https://avrdudes.github.io/avr-libc/avr-libc-user-manual/install_tools.html
*
https://github.com/sprintersb/atest?ta
On Tue, Sep 17, 2024 at 11:13:09AM +0200, Jakub Jelinek wrote:
> So maybe better
> tree arg = e_p->value;
> tree f;
> if ((in_typeof || in_alignof)
> && TREE_CODE (arg) == COMPONENT_REF
> && (f = TREE_OPERAND (arg, 1))
> && TRE
The following restores the use of .SELECT_VL for testcases where it
is safe to use even when using SLP. I've for now restricted it
to single-lane SLP plus optimistically allow store-lane nodes
and assume single-lane roots are not widened but at most to
load-lane who should be fine.
v2 fixes laten
The patch optimizes code generated for comparisons of the form x > y ? 2 : 3
(x <= y ? 3 : 2) and x < y ? 2 : 3 (x >= y ? 3 : 2).
For the following C code:
long f1(long x, long y) {
return (x > y) ? 2 : 3;
}
long f2(long x, long y) {
return (x < y) ? 2 : 3;
}
Before the patch, the gene
The invalid test case in this PR highlights a bad interaction between
the tentative_firewall and error recovery in cp_parser_decltype: the
firewall makes cp_parser_skip_to_closing_parenthesis a no-op, and the
parser does not make any progress, running "forever".
This patch calls cp_parser_commit_t
Pengxuan Zheng writes:
> We can still use SVE's INDEX instruction to construct vectors even if not all
> elements are constants. For example, { 0, x, 2, 3 } can be constructed by
> first
> using "INDEX #0, #1" to generate { 0, 1, 2, 3 }, and then set the elements
> which
> are non-constants sepa
Here is a fix for a mistake I made when recursively checking for
type compatibility.
Bootstrapped and regression tested on x86-64.
c: fix crash when checking for compatibility of structures [PR116726]
When checking for compatibility of structure or union types in
tagged_types
On Mon, 16 Sep 2024, Patrick Palka wrote:
> On Mon, 16 Sep 2024, Andrew Pinski wrote:
>
> > On Mon, Sep 16, 2024 at 8:12 AM Patrick Palka wrote:
> > >
> > > Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look
> > > OK for trunk? Sadly the prerequisity patch r15-2331-g523836716137d0
The current copysign pattern has a mismatch in the predicates and constraints -
operand[2] is a register_operand but also has an alternative X which allows any
operand. Since it is a floating point operation, having an integer alternative
makes no sense. Change the expander to always use the vec
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
-- >8 --
r12-3495 added maybe_warn_about_constant_value which will crash if
it gets a nameless VAR_DECL, which is what happens in this PR.
We created this VAR_DECL in cp_parser_decomposition_declaration.
PR c++/116676
gc
On 2024-08-06 11:06, Richard Sandiford wrote:
Sorry for the slow review.
Matthieu Longo writes:
This patch is only a refactoring of the existing implementation
of PAuth and returned-address signing. The existing behavior is
preserved.
_Unwind_FrameState already contains several CIE and FDE in
Kyrylo Tkachov writes:
> Hi Saurabh,
>
>> On 13 Sep 2024, at 11:06, saurabh@arm.com wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
>> The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
>> mandatory from Armv9.5-a. It introduces instructions for c
On 2024-08-06 11:21, Richard Sandiford wrote:
Matthieu Longo writes:
This patch provides a new handler MD_ARCH_FRAME_STATE_T to hide an
architecture-specific structure containing CIE and FDE data related
to DWARF architecture extensions.
Hiding the architecture-specific attributes behind a han
On 2024-08-13 16:31, Richard Sandiford wrote:
Matthieu Longo writes:
Architecture-specific CFI directives are currently declared an processed
among others architecture-independent CFI directives in gcc/dwarf2* files.
This approach creates confusion, specifically in the case of DWARF
instruction
On 2024-08-13 16:53, Richard Sandiford wrote:
Matthieu Longo writes:
gcc/testsuite/ChangeLog:
* g++.target/aarch64/pr94515-1.C: Improve test documentation.
* g++.target/aarch64/pr94515-2.C: Same.
The patch is OK as-is, since it's clearly a strict improvement over
the status
On 2024-08-06 15:28, Jakub Jelinek wrote:
On Tue, Aug 06, 2024 at 03:07:44PM +0100, Matthieu Longo wrote:
On AArch64, the RA state informs the unwinder whether the return address
is mangled and how, or not. This information is encoded in a boolean in
the CFI row. This binary approach prevents fr
Hi Thomas,
short version: I think the patch as posted is fine and no action beyond
is needed for this one issue.
See below for the long version.
Possibly modifications (now or as follow up):
- using memcpy + or let the plugin do it
- not adding link variables to the splay tree with 'USM'.
Th
Hi -
> [...]
> I pretty much only use `contrib/test_summary` via the
> `mail-report.log` target in the top-level Makefile; maybe add a
> `bunsen` target to the top-level Makefile, too, to simplify invoking
> it?
Something like this: ?
diff --git a/Makefile.in b/Makefile.in
index 966d60454960..4
On 9/17/24 3:26 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
OK.
-- >8 --
r12-3495 added maybe_warn_about_constant_value which will crash if
it gets a nameless VAR_DECL, which is what happens in this PR.
We created this VAR_DECL in cp_parser_dec
On Tue, 17 Sep 2024, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
Why not backport this to 12 as well?
>
> -- >8 --
> r12-3495 added maybe_warn_about_constant_value which will crash if
> it gets a nameless VAR_DECL, which is what happens in this PR.
Hi Jason,
gentle ping for this one.
> On 29 Aug 2024, at 20:10, Iain Sandoe wrote:
>
> Hi Jason,
>
>>> - char *buf = xasprintf ("_Coro_unnamed_parm_%d", no_name_parm++);
>>> + char *buf = xasprintf ("anon%d", parm_num);
>
>> Why the reduction in verbosity here?
> I was getting ahead o
Hi Jason,
gentle ping for this one
> On 29 Aug 2024, at 16:22, Iain Sandoe wrote:
>
> Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
> thanks,
> Iain
>
> --- >8 ---
>
> Awaiters always need to have a coroutine state frame copy since
> they persist across potential supensions.
On Tue, Sep 17, 2024 at 12:13:29PM -0400, Patrick Palka wrote:
> On Tue, 17 Sep 2024, Marek Polacek wrote:
>
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
>
> Why not backport this to 12 as well?
It didn't seem important enough but I've backported it to 12 as well.
Mare
> Pengxuan Zheng writes:
> > We can still use SVE's INDEX instruction to construct vectors even if
> > not all elements are constants. For example, { 0, x, 2, 3 } can be
> > constructed by first using "INDEX #0, #1" to generate { 0, 1, 2, 3 },
> > and then set the elements which are non-constants
On 9/17/24 10:38 AM, Simon Martin wrote:
Hi Jason,
Apologies for the back and forth and thanks for your patience!
No worries.
On 5 Sep 2024, at 19:00, Jason Merrill wrote:
On 9/5/24 7:02 AM, Simon Martin wrote:
Hi Jason,
On 4 Sep 2024, at 18:09, Jason Merrill wrote:
On 9/1/24 2:51 PM,
> > On 16 Sep 2024, at 16:32, Richard Sandiford
> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > "Pengxuan Zheng (QUIC)" writes:
> >>> On Thu, Sep 12, 2024 at 2:53 AM Pengxuan Zheng
> >>> wrote:
>
> SVE's INDEX instruction can be used to populate ve
> > > On 16 Sep 2024, at 16:32, Richard Sandiford
> wrote:
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > "Pengxuan Zheng (QUIC)" writes:
> > >>> On Thu, Sep 12, 2024 at 2:53 AM Pengxuan Zheng
> > >>> wrote:
> >
> > SVE's INDEX instruction can be
On 9/16/24 7:14 PM, Marek Polacek wrote:
On Fri, Sep 13, 2024 at 06:43:06PM +0200, Jason Merrill wrote:
On 9/12/24 3:12 PM, Marek Polacek wrote:
On Wed, Sep 11, 2024 at 10:25:34PM -0400, Jason Merrill wrote:
On 9/11/24 4:08 PM, Marek Polacek wrote:
@@ -6503,10 +6504,17 @@ check_bases_and_memb
On Tue, Sep 17, 2024 at 11:13 AM Frank Ch. Eigler wrote:
>
> Hi -
>
> > [...]
> > I pretty much only use `contrib/test_summary` via the
> > `mail-report.log` target in the top-level Makefile; maybe add a
> > `bunsen` target to the top-level Makefile, too, to simplify invoking
> > it?
>
> Something
On 9/16/24 7:08 PM, Marek Polacek wrote:
On Tue, Sep 10, 2024 at 10:37:31AM -0400, Jason Merrill wrote:
On 8/29/24 12:23 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
Pre r14-4793, we'd call warn_tautological_cmp -> operand_equal_p
with opera
On 8/29/24 5:22 PM, Iain Sandoe wrote:
Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
thanks,
Iain
--- >8 ---
Awaiters always need to have a coroutine state frame copy since
they persist across potential supensions. It simplifies the later
analysis considerably to assign these
On Tue, Sep 17, 2024 at 3:40 AM Dora, Sunil Kumar
wrote:
>
> Hi Andrew,
>
> Initially, I thought to address long command line options (when exceeding
> 128KB) without disrupting the existing GCC driver behavior.
>
> As you suggested, I implemented changes to use the response file format
> (@file
writes:
> The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
> mandatory from Armv9.5-a. It introduces instructions for computing the
> floating point absolute maximum and minimum of the two vectors element-wise.
>
> This patch introduces AdvSIMD faminmax intrinsics. The intrinsics
writes:
> The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
> mandatory from Armv9.5-a. It introduces instructions for computing the
> floating point absolute maximum and minimum of the two vectors
> element-wise.
>
> This patch adds code generation support for famax and famin in
> On 17 Sep 2024, at 18:24, Jason Merrill wrote:
>
> On 8/29/24 5:22 PM, Iain Sandoe wrote:
>> Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
>> thanks,
>> Iain
>> --- >8 ---
>> Awaiters always need to have a coroutine state frame copy since
>> they persist across potential su
On 9/17/24 8:26 PM, Iain Sandoe wrote:
On 17 Sep 2024, at 18:24, Jason Merrill wrote:
On 8/29/24 5:22 PM, Iain Sandoe wrote:
Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
thanks,
Iain
--- >8 ---
Awaiters always need to have a coroutine state frame copy since
they persist a
> On 17 Sep 2024, at 20:06, Jason Merrill wrote:
>
> On 9/17/24 8:26 PM, Iain Sandoe wrote:
>>> On 17 Sep 2024, at 18:24, Jason Merrill wrote:
>>>
>>> On 8/29/24 5:22 PM, Iain Sandoe wrote:
Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
thanks,
Iain
--- >
On 9/17/24 9:26 PM, Iain Sandoe wrote:
On 17 Sep 2024, at 20:06, Jason Merrill wrote:
On 9/17/24 8:26 PM, Iain Sandoe wrote:
On 17 Sep 2024, at 18:24, Jason Merrill wrote:
On 8/29/24 5:22 PM, Iain Sandoe wrote:
Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
thanks,
Iain
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
The result of build_fold_indirect_ref can be a COMPONENT_REF in
which case using DECL_SOURCE_LOCATION will crash. Look at its op1
instead.
PR c++/116741
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_
On Tue, Sep 17, 2024 at 12:53:25PM -0400, Jason Merrill wrote:
> On 9/16/24 7:08 PM, Marek Polacek wrote:
> > On Tue, Sep 10, 2024 at 10:37:31AM -0400, Jason Merrill wrote:
> > > On 8/29/24 12:23 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
> > >
On 9/17/24 10:32 PM, Marek Polacek wrote:
On Tue, Sep 17, 2024 at 12:53:25PM -0400, Jason Merrill wrote:
On 9/16/24 7:08 PM, Marek Polacek wrote:
On Tue, Sep 10, 2024 at 10:37:31AM -0400, Jason Merrill wrote:
On 8/29/24 12:23 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-
On 9/17/24 10:30 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
OK.
-- >8 --
The result of build_fold_indirect_ref can be a COMPONENT_REF in
which case using DECL_SOURCE_LOCATION will crash. Look at its op1
instead.
PR c++/116741
gcc/cp/Cha
On 8/29/24 9:10 PM, Iain Sandoe wrote:
Hi Jason,
- char *buf = xasprintf ("_Coro_unnamed_parm_%d", no_name_parm++);
+ char *buf = xasprintf ("anon%d", parm_num);
Why the reduction in verbosity here?
I was getting ahead of myself; not intended in this patch. Fixed.
+ p =
On 9/17/24 3:22 PM, Patrick Palka wrote:
On Mon, 16 Sep 2024, Patrick Palka wrote:
On Mon, 16 Sep 2024, Andrew Pinski wrote:
On Mon, Sep 16, 2024 at 8:12 AM Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look
OK for trunk? Sadly the prerequisity patch r15
Tested x86_64-pc-linux-gnu. Marek, any concerns?
-- 8< --
We can't have a dangling reference to an empty class unless it's
specifically to that class or one of its bases. This was giving a
false positive on the _ExtractKey pattern in libstdc++ hashtable.h.
This also adjusts the order of argume
Tested x86_64-pc-linux-gnu. Marek, thoughts?
-- 8< --
The -Wdangling-reference diagnostic talks about the full-expression, but
prints one call, while the full-expression in a declaration is the entire
initialization. It seems more useful to point out the temporary that the
compiler thinks we mi
On Tue, Sep 17, 2024 at 05:16:47PM -0400, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu. Marek, any concerns?
LGTM, thanks. The ChangeLog may not pass the hook because it's
missing some entries.
> -- 8< --
>
> We can't have a dangling reference to an empty class unless it's
> specifically
On Tue, Sep 17, 2024 at 05:16:48PM -0400, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu. Marek, thoughts?
Makes sense. OK, thanks.
> -- 8< --
>
> The -Wdangling-reference diagnostic talks about the full-expression, but
> prints one call, while the full-expression in a declaration is the e
LGTM. Thanks for supporting it :).
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-09-12 11:19
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Implement SAT_ADD for signed integer vector
From: Pan Li
This patch would like to implement th
This C++ify cond_if_else_store_replacement by using range fors
and changing using a std::pair instead of 2 vecs.
I had a hard time understanding the code when there was 2 vecs
so having a vec of a pair makes it easier to understand the relationship
between the 2.
gcc/ChangeLog:
* tree-ssa
While trying to debug PR 116747, I noticed there was no dump
saying what was done. So this adds the debug dump and it helps
debug what is going on in PR 116747 too.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (cond_if_else_store_replacement_1): Add de
The RISC-V vector machine description relies on the helper function
`sew64_scalar_helper` to emit actual insns for the DI variants of
vssub.vx and vssubu.vx. This works with vssub.vx, but can cause
problems with vssubu.vx with the scalar operand being constant zero,
because `has_vi_variant_p` retu
Hi all,
Since r15-3539, there are requests coming in to add other alias option
documentation. This patch will add all ot them, including corei7, corei7-avx,
core-avx-i, core-avx2, atom, slm, gracemont and emerarldrapids.
Also in the patch, I reordered that part of documentation, currently all
the
Hi all,
Since commit r15-3594, we fixed the bugs in MASK_TYPE for AVX10.2
testcases, but we missed the following four.
The tests are not FAIL since the binutils part haven't been merged
yet, which leads to UNSUPPORTED test. But the avx512f-mask-type.h
needs to be included, otherwise, it will be c
Hi all,
For AVX10.2 convert tests, all of them are missing mask tests
previously, this patch will add them in the tests.
Tested on sde with assembler with these insts. Ok for trunk?
Thx,
Haochen
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx10_2-512-vcvt2ps2phx-2.c: Enhance mask test.
On Tue, Sep 17, 2024 at 02:33:09AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Sep 16, 2024 at 11:40:45PM -0400, Michael Meissner wrote:
> > With this patch, GCC now realizes that the vector shift instructions will
> > look
> > at the bottom 6 bits for the shift count, and it can use eithe
On Tue, Sep 17, 2024 at 4:36 AM Andrew Pinski wrote:
>
> This adds simple_dce_worklist to both the SLP vectorizer and the loop based
> vectorizer.
> This is a step into removing the dce after the loop based vectorizer. That
> DCE still
> does a few things, removing some of the induction variable
The pattern `a rrotate (32-b)` should be optimized to `a lrotate b`.
The same is also true for `a lrotate (32-b)`. It can be optimized to
`a rrotate b`.
This patch adds following patterns:
a rrotate (32-b) -> a lrotate b
a lrotate (32-b) -> a rrotate b
PR tree-optimization/109906
gcc/Cha
On Tue, Sep 17, 2024 at 11:23 PM Eikansh Gupta
wrote:
>
> The pattern `a rrotate (32-b)` should be optimized to `a lrotate b`.
> The same is also true for `a lrotate (32-b)`. It can be optimized to
> `a rrotate b`.
>
> This patch adds following patterns:
> a rrotate (32-b) -> a lrotate b
> a lrota
The pattern `a rrotate (32-b)` should be optimized to `a lrotate b`.
The same is also true for `a lrotate (32-b)`. It can be optimized to
`a rrotate b`.
This patch adds following patterns:
a rrotate (32-b) -> a lrotate b
a lrotate (32-b) -> a rrotate b
PR tree-optimization/109906
gcc/Cha
On Wed, Sep 18, 2024 at 5:08 AM Andrew Pinski wrote:
>
> While trying to debug PR 116747, I noticed there was no dump
> saying what was done. So this adds the debug dump and it helps
> debug what is going on in PR 116747 too.
>
> Bootstrapped and tested on x86_64-linux-gnu.
OK
> gcc/ChangeLog:
>
On Wed, Sep 18, 2024 at 5:08 AM Andrew Pinski wrote:
>
> This C++ify cond_if_else_store_replacement by using range fors
> and changing using a std::pair instead of 2 vecs.
> I had a hard time understanding the code when there was 2 vecs
> so having a vec of a pair makes it easier to understand the
> From: Haochen Jiang
> Sent: Wednesday, September 18, 2024 1:38 PM
>
> Hi all,
>
> For AVX10.2 convert tests, all of them are missing mask tests previously, this
> patch will add them in the tests.
>
> Tested on sde with assembler with these insts. Ok for trunk?
Please ignore this patch, I mi
77 matches
Mail list logo
