On 22/10/25 13:38, [email protected] wrote:
External email: Use caution opening links or attachments
From: Dhruv Chawla
This patch aims to implement summary support in auto-profile, similar to
LLVM. The summary information stores various information about the
profile being read such as the nu
Ping
> On 9 Oct 2025, at 9:10 PM, Prachi Godbole wrote:
>
> This patch adds support to linker driven function reordering by creating
> function sections with a prefix '.text.sorted' which are then sorted using
> SORT in by the linker. Appropriate support for this is already present in
> binut
This patch introduces a new heuristics for reordering functions, to be used
in the absense of profile information. This approach uses C++ template
instantiation types to group functions together. Entry functions are sorted
in the beginning, and callees are sorted as part of partition_callchain ()
This patch attempts to reduce compile time for locality cloning pass by
reducing recursive calls to partition_callchain (). This is achieved by
precomputing caller callee information into locality_info. locality_info
stores all callees of a node, either directly or via inlined nodes thereby
avoid
So in the end I agree with Richi's comment at
https://gcc.gnu.org/pipermail/gcc-patches/2025-October/698856.html:
> I see. I wonder whether it would be better to leave __builtin_assume_aligned
> around then, because that inherently introduces the copy and it would show
> why.
> TER / SSA coalesci
Hi,
As discussed at Cauldron, I’m sending a 3 patch series that addresses the
review comments about the compile-time improvement and introduces C++ template
heuristics which requires the data structure support added in the compile-time
patch [2/3].
[Patch 1/3]
This patch turns off -fipa-reorde
{
"emoji": "👍",
"version": 1
}
Pinging this patch.
As a recap, so far I have fixed:
1) the builtin didn't the type of the argument
2) arguments with side effects had their side effects evaluated twice.
Anything else I should do?
Pushed to r16-4723.
Thanks.
在 2025/10/29 下午4:38, Guo Jie 写道:
The current implementation of the fnmam4 instruction template requires
the third source operand to be assigned the same hard register as the
target operand, but the constraint is not documented in the instruction
manual or standard te
Pushed to r16-4722.
在 2025/10/29 下午4:07, Jinyang He 写道:
It is wrong that optimize from `if (cond) dest op= 1 << shift` to
`dest op= (cond ? 1 : 0) << shift` when `dest op 0 != dest`.
Like `and`, `mul` or `div`.
And in this optimization `mul` and `div` is optimized to shift.
gcc/ChangeLog:
On Wed, Oct 29, 2025 at 2:19 PM Joseph Myers wrote:
>
> On Sun, 12 Oct 2025, Lewis Hyatt wrote:
>
> > > > One issue that came up is the treatment of command-line-defined macros.
> > > > From
> > > > the perspective of the generic line_map data structures, the
> > > > command-line
> > > > locatio
I know "vicuana" is the internal codename within Andes, so I would
suggest all vicuna from the change and rename that into
andes_25_series which is the external name, otherwise I think it might
confuse people when reading the code...
e.g. s/andes_vicuna/andes_25_series/
When I google with "Andes V
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE): Add andes-25-series.
(RISCV_CORE): Add Andes 25-series cpu list.
* config/riscv/riscv-opts.h
(enum riscv_microarchitecture_type): Add andes_vicuna.
* config/riscv/riscv.cc: Add andes_vicuna_tune_inf
The RISC-V ABI currently defines that empty unions and zero length array
in struct should be ignored, but the implementation in GCC is not
correct.
e.g. for the following code:
```
struct S2eu_2f {
union{} e1;
float f;
float g;
};
```
The RISC-V ABI defines that the layout of S2eu_2f
Hi, Wangrui:
Please double-check if the patch is available.
Thanks!
在 2025/10/29 下午6:49, chenxiaolong 写道:
gcc/ChangeLog:
* config/loongarch/lasx.md (vec_cast): New template
implemention.
(vec_insert_lo_): Dito.
(vec_insert_hi_): Dito.
* config/loongarch
在 2025/10/29 下午4:07, Jinyang He 写道:
It is wrong that optimize from `if (cond) dest op= 1 << shift` to
`dest op= (cond ? 1 : 0) << shift` when `dest op 0 != dest`.
Like `and`, `mul` or `div`.
And in this optimization `mul` and `div` is optimized to shift.
This is indeed a bug.
I have no objec
This is again an issue with multiple levels of nested instances, and it arises
because the qualified name of the problematic child generic unit is used (this
works fine with the direct name), exposing the rather questionable processing
implemented for instances in Find_Expanded_Name.
The patch
Aggregates used as actuals of formal object parameters are handled specially
by Instantiate_Object in Sem_Ch12 and qualifying them is sufficient to block
this special processing.
Tested on x86-64/Linux, applied on the mainline.
2025-10-29 Eric Botcazou
PR ada/54178
* sem_ch
512-bit vpdpwusd instruction requires AVX10.2, the iterator use VI2_AVX512F,
and condition is TARGET_AVXVNNIINT16 || TARGET_AVX10_2, so case
TARGET_AVXVNNIINT16 + TARGET_AVX512F meet the condition of the expander but
failed the condition of define_insn.
Tighten the dot_prod expander.
Bootstrapped
On Tue, Oct 28, 2025 at 1:20 AM Richard Biener
wrote:
>
> On Mon, Oct 27, 2025 at 9:41 PM Andrew Pinski
> wrote:
> >
> > On Mon, Oct 27, 2025 at 1:07 PM Andrew Pinski
> > wrote:
> > >
> > > On Mon, Oct 27, 2025 at 5:56 AM Richard Biener
> > > wrote:
> > > >
> > > > On Mon, Oct 27, 2025 at 10:22
On Thu, Oct 30, 2025 at 7:44 AM Andrew Pinski
wrote:
>
> On Wed, Oct 29, 2025 at 4:38 PM H.J. Lu wrote:
> >
> > On Tue, Oct 28, 2025 at 3:55 PM H.J. Lu wrote:
> > >
> > > On Tue, Oct 28, 2025 at 12:07 PM wrote:
> > > >
> > > > Dear contributor,
> > > >
> > > > Our automatic CI has detected prob
On Wed, Oct 29, 2025 at 4:38 PM H.J. Lu wrote:
>
> On Tue, Oct 28, 2025 at 3:55 PM H.J. Lu wrote:
> >
> > On Tue, Oct 28, 2025 at 12:07 PM wrote:
> > >
> > > Dear contributor,
> > >
> > > Our automatic CI has detected problems related to your patch(es). Please
> > > find some details below.
> >
On Tue, Oct 28, 2025 at 3:55 PM H.J. Lu wrote:
>
> On Tue, Oct 28, 2025 at 12:07 PM wrote:
> >
> > Dear contributor,
> >
> > Our automatic CI has detected problems related to your patch(es). Please
> > find some details below.
> >
> > In gcc_check master-aarch64, after:
> > | commit gcc-16-466
On Oct 29, 2025, "H.J. Lu" wrote:
> If bootstrap is used, it is the same as i686-linux with
> --with-multilib-list=m32,m64.
Perhaps. The above requires --enable-targets=all to enable 64-bit
multilibs AFAICT, and it only supports GNU/Linux/i686. We want such
64-to-32 cross-natives on/for mingw
It was noticed if we have `.VEC_SHL_INSERT ({ 0, ... }, 0)` it was not being
simplified to just `{ 0, ... }`. This was generated from the autovectorizer
(maybe even on accident, see PR tree-optmization/116081).
This adds a few SVE testcases to see if this is optimized since the
auto-vectorizer or
OK.
Thanks for the patch!
> The existing BTF pruning logic meant that an anonymous struct or
> union type hidden behind a typedef, such as in the common construct:
>
> typedef struct { ... } my_struct_type;
>
> could be pruned if 'my_struct_type' was only ever referenced via pointer
> members
The existing BTF pruning logic meant that an anonymous struct or
union type hidden behind a typedef, such as in the common construct:
typedef struct { ... } my_struct_type;
could be pruned if 'my_struct_type' was only ever referenced via pointer
members in other structs/unions types used in the
On Wed, 29 Oct 2025 at 20:04, Haochen Jiang wrote:
>
> On Linux/x86_64,
>
> c55c1de3a9adb241e3c0dabd7d1edd8ebe9c065f is the first bad commit
> commit c55c1de3a9adb241e3c0dabd7d1edd8ebe9c065f
> Author: Jonathan Wakely
> Date: Tue Oct 28 12:15:52 2025 +
>
> libstdc++: Simplify std::regex_
In r16-4709-gc55c1de3a9adb2 I meant to use the result of the
static_cast for the rest of the function following it, but I
accidentally used the original variable __ch. This causes
-Wunused-variable warnings for the __c initialized from the cast.
This fixes the rest of the function to use __c inste
On Wed, 29 Oct 2025, Qing Zhao wrote:
> The attribute is allowed for a pointer to void, However,
> Warnings will be issued for such cases when -Wpointer-arith is
> specified. When this attribute is applied on a pointer to void, the
> size of each element of this pointer array is treated as 1.
>
>
On Thu, Oct 30, 2025 at 2:42 AM Alexandre Oliva wrote:
>
> On Oct 27, 2025, Richard Biener wrote:
>
> > So on x86-64-linux this is a cross configuration?
>
> It's one of those cross-natives corner cases.
>
> > Or is this able to bootstrap itself but then resulting in a 32bit host
> > compiler?
>
Hi, Sid,
Really appreciate for your time to review this patch.
> On Oct 28, 2025, at 17:50, Siddhesh Poyarekar wrote:
>
> On 2025-10-20 12:16, Qing Zhao wrote:
>> Hi,
>> this is the version 4th of the patch, compared to V3, the major change
>> includes changes to address all Sid's comments for
On Linux/x86_64,
c55c1de3a9adb241e3c0dabd7d1edd8ebe9c065f is the first bad commit
commit c55c1de3a9adb241e3c0dabd7d1edd8ebe9c065f
Author: Jonathan Wakely
Date: Tue Oct 28 12:15:52 2025 +
libstdc++: Simplify std::regex_traits::value
caused
FAIL: g++.dg/warn/uninit-pr105562.C -std=gnu
Hi,
this is the 2nd version of the patch.
compared to the first version, the major change is the update based on
Joseph's comments:
support ???counted_by??? for VOID pointer by default, but
issue warnings when -Wpointer-arith is presenting.
the patch has been bootstrapped and regression tested
Hi,
When niter runs after the copy-header pass it sometimes fails to
simplify assumptions in a ctz loop.
As the assumption is a simple nonzero test here we can have
ranger get us the range of the shifted expression, then verify that
this range is nonzero.
This helps recognize a ctz loop in 502.gc
To reduce instantiation count, function_ref(nontype<&S::x>, r) previously
reused the invoker from function_ref(nontype<&S::x>, &r). This assumed r was
always a reference to S or a derived class. However, this constructor is also
valid for lvalues (but not rvalues) of reference_wrapper specializatio
So another case where we're indexing into the ira_reg_equiv array
without checking bounds. I sincerely hope we're not playing wack-a-mole
here, but two failures in a couple months for the same core problem is
worrisome.
Bootstrapped and regression tested on x86_64 and riscv64 as well as run
Paul-Antoine Arras wrote:
When a label is matched in the first statement after the end of a metadirective
body, it is bound to the associated region. However this prevents it from being
reference elsewhere.
This patch fixes it by rebinding such labels to the outer region.
This does not seem to
On Oct 27, 2025, Richard Biener wrote:
> So on x86-64-linux this is a cross configuration?
It's one of those cross-natives corner cases.
> Or is this able to bootstrap itself but then resulting in a 32bit host
> compiler?
Yeah, it can bootstrap. (It needs an additional tweak to fix multilibs
I just realized that unwrapping reference wrapper is observable, and not
permitted by standard,
for example this should pass
struct S { int x; };
S s1, s2;
std:::refernce_wrapper rw(s1);
std::function_ref fr(std::nontype<&S::x>, rw);
assert( &fr() == &s1.x );
rw = std::ref(s2); // rebind
assert( &f
On Sun, 12 Oct 2025, Lewis Hyatt wrote:
> > > One issue that came up is the treatment of command-line-defined macros.
> > > From
> > > the perspective of the generic line_map data structures, the command-line
> > > location is not distinguishable from other locations; it's just an
> > > ordinary
This clarifies the comment about the sizes difference
being about bytes (or units).
As shown by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122478#c3,
the implicit bytes/units was not always being thought of.
gcc/ChangeLog:
* tree.def (VIEW_CONVERT_EXPR): Clarify what size is being
On Oct 26, 2025, Uros Bizjak wrote:
>> * config.gcc [x86_64-*-*]: Match *m32 target, default to m32
>> abi and multilib. Accept 32 or m32 for --with-abi.
> Shouldn't this target be named x86_64-linux-gnu32?
In an ideal world, it should. m32 makes it easier to match,
distinguishing from x32, a
On Wed, 15 Oct 2025, Osama Abdelkader wrote:
> Passing a va_list to a variadic function like printf() instead of its
> v-variant (vprintf()) is a common programming error that can lead to
> undefined behavior. This adds a warning to detect such cases.
>
> The warning uses a multi-tiered detection
On Mon, 27 Oct 2025, [email protected] wrote:
> + fseek (fptr, 0, SEEK_END);
> + file_size = ftell (fptr);
> + rewind (fptr);
> + buf = (char *) xmalloc (file_size + 1);
> +
> + fread (buf, 1, file_size, fptr);
This is missing error checking on fseek, ftell, f
On Mon, 27 Oct 2025, [email protected] wrote:
> + fwrite (data_to_write, sizeof(char), strlen(data_to_write), fptr);
Missing spaces before '('
> + char *env_val = (char *) xmalloc (strlen (temp_file) + strlen(prefix)
> + 2);
Likewise.
> diff --git a/gcc/testsuite/gcc.dg/
So per the discussion in PR 116662, this adjusts the destructive
interference size for RISC-V to be more in line with current designs (64
bytes).
Getting this wrong is "just" a performance issue, so there's no
correctness concerns to be worried about. The only real worry is that
the value
When a label is matched in the first statement after the end of a metadirective
body, it is bound to the associated region. However this prevents it from being
reference elsewhere.
This patch fixes it by rebinding such labels to the outer region.
PR fortran/122369
gcc/fortran/ChangeLog:
For 42319.cc the PR says that reproduced the problem, so let's
include that instead. We should also use the no_pch option because
otherwise the test is including everything anyway, and so fails to check
that the char_traits.h header can be included in isolation. There's also
no reason to use an ex
On Thu, Oct 30, 2025 at 12:03 AM Tobias Burnus wrote:
>
> Hi Yuao, hi all,
>
> Yuao Ma wrote:
> > I think this patch explains itself. This is identified during working
> > on r16-4695-gb6146faae09bbc and should be safe to remove after
> > r16-4474-g2c1949bf152f8f landed.
> >
> > Regression tested
This patch completes the implementation of P2321R2, giving tuple proper proxy
reference semantics.
The assignment operator is implemented as a template constrained to accept only
tuple<>. Consequently, the language does not consider it a copy assignment
operator, which prevents tuple<> from losing
Hi,
this patch extends the ipa-devirt pass with the ability to add
speculative calls for indirect calls where the target was loaded from
a record_type data structure and we have seen writes of address of
only one particular function to the same offset of that record
type (including static initiali
In the case with EH, we end up with the following IR:
```
# .MEM_5 = VDEF <.MEM_4(D)>
inner = outer;
# .MEM_6 = VDEF <.MEM_5>
p (outer);
:
# .MEM_7 = VDEF <.MEM_6>
inner ={v} {CLOBBER(eos)};
...
:
:
# .MEM_9 = VDEF <.MEM_6>
inner ={v} {CLOBBER(eos)};
```
So when the simple
In this case we have a phi node for the use so we need to see if
the result of the phi is a single usage with the clobber.
That is the following IR:
```
# .MEM_6 = VDEF <.MEM_5(D)>
inner = outer;
# .MEM_7 = VDEF <.MEM_6>
p (outer);
:
...
# .MEM_8 = VDEF <.MEM_7>
g (_3, _2, _1);
Hi,
currently, an instance of cgraph_indirect_call_info is allocated for
each indirect call and it contains fields which are only usable for
some kinds of calls. The most special are polymorphic calls
representing calls of virtual methods through an OBJ_TYPE_REF and
which need the ipa_polymorphic
From: Osama Abdelkader
This patch adds support for constructing and assigning tuple<> from
other empty tuple-like types (e.g., array), completing the C++23
tuple-like interface for the zero-element tuple specialization.
The implementation includes:
- Constructor from forwarding reference to tupl
Hello,
in a follow-up patch, I have created a GTYed subclass which does not
have any garbage collectible fields, just integers (a "sibling"
subclass does). This leads to gengtype outputting code like this to
gtype-desc.cc:
2722 case CIIK_SIMPLE:
2723 {
2724
On Wed, Oct 29, 2025 at 4:53 PM Jonathan Wakely wrote:
> On Mon, 27 Oct 2025 at 15:11 +0100, Tomasz Kamiński wrote:
> >From: Osama Abdelkader
> >
> >This patch adds support for constructing and assigning tuple<> from
> >other empty tuple-like types (e.g., array), completing the C++23
> >tuple-li
Hi Yuao, hi all,
Yuao Ma wrote:
I think this patch explains itself. This is identified during working
on r16-4695-gb6146faae09bbc and should be safe to remove after
r16-4474-g2c1949bf152f8f landed.
Regression tested on x86_64-linux. Ok for trunk?
LGTM.
As you mentioned, r16-4474-g2c1949bf152
On Mon, 27 Oct 2025 at 15:11 +0100, Tomasz Kamiński wrote:
This patch completes the implementation of P2321R2, giving tuple proper proxy
reference semantics.
The assignment operator is implemented as a template constrained to accept only
tuple<>. Consequently, the language does not consider it a
On Mon, 27 Oct 2025 at 15:11 +0100, Tomasz Kamiński wrote:
From: Osama Abdelkader
This patch adds support for constructing and assigning tuple<> from
other empty tuple-like types (e.g., array), completing the C++23
tuple-like interface for the zero-element tuple specialization.
The implementat
Hi all,
I think this patch explains itself. This is identified during working
on r16-4695-gb6146faae09bbc and should be safe to remove after
r16-4474-g2c1949bf152f8f landed.
Regression tested on x86_64-linux. Ok for trunk?
PS: I will continue refining the .NIL. patch this weekend.
Yuao
0001-fo
On Tue, Oct 28, 2025 at 5:18 PM Jonathan Wakely wrote:
> We don't need to use an istringstream to convert a hex digit to its
> numerical value.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/regex.tcc (regex_traits::value): Implement
> without using istringstream.
> * incl
This is a long standing PR that shouldn't have languished this long.
The was a lack of clarity of what to do with VIEW_CONVERT_EXPR when it
did not meet the technical requirement of both arguments being the same
precision.
If the precision is the same, and both arguments are integral, then we
Hi all,
I’m sending a summary email with direct links to the latest version of
each patch from the mailing list. This should make it easier to access
them without searching through the archives manually.
Please let us know if you have any comments or suggestions regarding
these patches.
Best reg
Hi Jeff,
> This ought to work. Plan is to do a first pass through for things that
> are clearly safe and simple then work towards the more complex or
> controversial stuff. Hopefully I don't goof dependencies again.
Thanks a lot for merging the patches and for the detailed feedback.
> > [PATC
vect_build_slp_instance always releases the scalar stmts vector, so make sure
to mark it as released and actually release it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (vect_analyze_slp): Mark stmts in BB roots
as released after vect_build_slp
From: Loeka Rogge
V2HI vectors, explicitly or auto-generated, could be stored in memory wrongly
due to endianness. For example in the following c code stores to the struct
are SLP vectorized, causing them to be stored in the wrong order:
struct S {short a; short b;};
s.a = 520;
s.b = -1;
in the
> On Oct 29, 2025, at 01:08, Yeoul Na wrote:
>
> Is the reasoning that since it’s not a standard feature, a pedantic warning
> doesn’t make sense? And it’s still a warning with -Wpointer-arith.
Yeah, “counted_by” itself is not a standard feature already.
>
> If so, yes, it makes sense to me
> -Original Message-
> From: Richard Biener
> Sent: 29 October 2025 09:59
> To: [email protected]
> Cc: [email protected]; RISC-V CI
> Subject: [PATCH] tree-optimization/120687 - legitimise some permutes before
> optimizing
>
> The following does a simple legitimising atte
On Tue, Oct 28, 2025 at 6:35 PM Andrew Pinski
wrote:
> > > +(define_insn_and_split
> > > "*aarch64_plus_within_3_"
> > > + [(set (match_operand:GPI 0 "register_operand" "=r")
> > > + (UMAXMIN:GPI
> > > + (plus:GPI (match_operand:GPI 1 "register_operand" "r")
> > > + (m
On 29/10/2025 13:04, Richard Biener wrote:
On Wed, 29 Oct 2025, Christopher Bazley wrote:
I don't think this fix is sufficient. It may appear to "fix" a specific crash,
but only because it hides the symptom. I considered making this one-line
change but when I discovered how broken the error-h
Hi,
a gentle ping for this patch series:
https://gcc.gnu.org/pipermail/gcc-patches/2025-October/697994.html.
Patch 2 has already been approved and committed, but the rest of the
series is yet to be reviewed. Thanks :)
Best regards,
Josef
On Wed, 29 Oct 2025, Christopher Bazley wrote:
> I don't think this fix is sufficient. It may appear to "fix" a specific crash,
> but only because it hides the symptom. I considered making this one-line
> change but when I discovered how broken the error-handling
> of vect_build_slp_instance is, I
I don't think this fix is sufficient. It may appear to "fix" a specific
crash, but only because it hides the symptom. I considered making this
one-line change but when I discovered how broken the error-handling
of vect_build_slp_instance is, I rejected the idea.
Your proposed fix relies on an
Hi Yuao,
Yuao Ma wrote:
The updated patch will resolve the first two cases. Regarding the
coarray, if it's not causing an ICE, I'd prefer to postpone working on
it until we handle arrays.
Makes sense. Coarrays also behave strangely at times and
are not that widely used. Still, I want to mentio
On Fri, 29 Aug 2025 at 11:22, Jakub Jelinek wrote:
>
> On Fri, Aug 29, 2025 at 11:40:10AM +0200, Jason Merrill wrote:
> > > --- gcc/cp/semantics.cc.jj 2025-08-28 10:50:43.432763513 +0200
> > > +++ gcc/cp/semantics.cc 2025-08-28 16:52:48.006806831 +0200
> > > @@ -13591,6 +13591,38 @@ trait_exp
On Tue, 23 Sept 2025 at 08:15, Tomasz Kaminski wrote:
>
> The library side looks good to me, with two small comments:
> * removing version.cc file, that duplicates tests
> * removing copyright notice from second test (to be confirmed by Jonathan).
> The test covers all cases, that I could think
On 28-10-2025 21:26, David Faust wrote:
On 10/24/25 10:01, Cupertino Miranda wrote:
This patch corrects CO-RE generation for the cases where an expression
starts with a non-CO-RE access, but in the middle it requires to
generate CO-RE to correctly compute the access location.
It fixes it b
Hi Yury,
> -Original Message-
> From: Yury Khrustalev
> Sent: 16 October 2025 16:37
> To: [email protected]
> Cc: Tamar Christina ; Srinath Parvathaneni
> ; Tejas Belagod ;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: [PAT
We are now able to vectorize the PR70102 testcase using a SLP reduction chain.
Tested on x86_64-linux, pushed.
PR tree-optimization/70102
* gfortran.dg/vect/pr70102.f: New testcase.
---
gcc/testsuite/gfortran.dg/vect/pr70102.f | 21 +
1 file changed, 21 insert
gcc/ChangeLog:
* config/loongarch/lasx.md (vec_cast): New template
implemention.
(vec_insert_lo_): Dito.
(vec_insert_hi_): Dito.
* config/loongarch/lasxintrin.h (defined): Test for adding
the builtin function.
(__lasx_cast_128_s): Dito.
The following does a simple legitimising attempt on the SLP graph
permutations before trying to optimize them. For the case we have
a single non-zero layout we can force that to all partitions if
it is compatible. This way we end up with the most canonical
(and possibly no-op) load permutations a
Adding Joseph who's a reviewer for the driver
> -Original Message-
> From: [email protected]
> Sent: 27 October 2025 13:03
> To: [email protected]
> Cc: [email protected]; [email protected]; Ross Burton
> ; [email protected]; [email protected]
> Subject:
vect_build_slp_instance always releases the scalar stmts vector, so make sure
to mark it as released.
Bootstrapped and tested on x86_64-unknown-linux-gnu. This should fix
the observed double-free?
Thanks,
Richard.
* tree-vect-slp.cc (vect_analyze_slp): Mark stmts in BB roots
as
The current implementation of the fnmam4 instruction template requires
the third source operand to be assigned the same hard register as the
target operand, but the constraint is not documented in the instruction
manual or standard template definitions. The current constraint will
generate addition
It is wrong that optimize from `if (cond) dest op= 1 << shift` to
`dest op= (cond ? 1 : 0) << shift` when `dest op 0 != dest`.
Like `and`, `mul` or `div`.
And in this optimization `mul` and `div` is optimized to shift.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_expa
Hi Vijay,
Right now my comments are just limited to the spell check.
Fix the typo "elments" → "elements" before committing.
- emit_insn (gen_vcmpne (cmpz1_result, operands[1], vzero));
- emit_insn (gen_vcmpne (cmpz2_result, operands[2], vzero));
- emit_insn (gen_and3 (and_result, cmpz1_resu
Ping!
Please review.
Thanks & Regards
Kishan
On 09/09/25 2:04 pm, Kishan Parmar wrote:
> Hi All,
>
> The fallback expansion of __builtin_bswap16 on pre-Power10 used a
> sequence of multiple rlwinm/or instructions:
>
> mr r9,r3
> rlwinm r3,r9,24,24,31
> rlwinm r10,r9,8,16,23
> or
Hi Jeff and Segher,
Changes from v2:
* Code refactoring.
Changes from v1:
* Corrected commit message.
For a given rtx expression (and (lshiftrt (subreg X) shift) mask)
combine pass tries to simplify the RTL form to
(and (subreg (lshiftrt X shift)) mask)
where the SUBREG wraps
90 matches
Mail list logo
