This is a quick refactor of the riscv target processing code
to take a string_slice rather than a decl.
The reason for this is to enable it to work with target_clones
where merging logic requires reasoning about each version string
individually in the front end.
This refactor primarily serves jus
gcc/ChangeLog:
* attribs.cc (make_attribute): Change arguments.
* attribs.h (make_attribute): Change arguments.
Approved by Richard Sandiford.
---
gcc/attribs.cc | 16 +---
gcc/attribs.h | 2 +-
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/gcc/att
PR c/117025
gcc/testsuite/ChangeLog:
* gcc.dg/countof-vla.c: Remove spurious comments.
* gcc.dg/countof-zero-compile.c: Remove spurious comments.
Fixes: 517c9487f8fd (2025-05-27; "c: Add _Countof operator [PR117025]")
Reported-by: Sam James
Signed-off-by: Alejandro Colom
Add support for a FMV set defined by a combination of target_clones and
target_version definitions.
Additionally, change is_function_default_version to consider a function
declaration annotated with target_clones containing default to be a
default version.
Lastly, add support for the case that a
Add tests covering many FMV errors for Aarch64, including
redeclaration, and mixing target_clones and target_versions.
gcc/testsuite/ChangeLog:
* g++.target/aarch64/mv-and-mvc-error1.C: New test.
* g++.target/aarch64/mv-and-mvc-error2.C: New test.
* g++.target/aarch64/mv-a
This patch is an overhaul of how FMV name mangling works. Previously
mangling logic was duplicated in several places across both target
specific and independent code. This patch changes this such that all
mangling is done in targetm.mangle_decl_assembler_name (including for the
dispatched symbol an
This patch changes the semantics of target_version and target_clones attributes
to match the behavior described in the Arm C Language extension.
The changes to behavior are:
- The scope and signature of an FMV function set is now that of the default
version.
- The FMV resolver is now created at
Add logic for the case of two FMV annotated functions with identical
signature other than the return type.
Previously this was ignored, this changes the behavior to emit a diagnostic.
gcc/cp/ChangeLog:
PR c++/119498
* decl.cc (duplicate_decls): Change logic to not always exclude F
Renames record_function_versions to add_function_version, and make it
explicit that it is adding a single version to the function structure.
Additionally, change the insertion point to always maintain priority ordering
of the versions.
This allows for removing logic for moving the default to the
This is a reimplementation of get_target_clone_attr_len,
get_attr_str, and separate_attrs using string_slice and auto_vec to make
memory management and use simpler.
Adds get_target_version helper function to get the target_version string
from a decl.
gcc/c-family/ChangeLog:
* c-attribs.c
This patch introduces the TARGET_REJECT_FUNCTION_CLONE_VERSION hook
which is used to determine if a target_clones version string parses.
If true is returned, a warning is emitted and from then on the version
is ignored.
This is as specified in the Arm C Language Extension. The purpose of this
is
I thought this issue should be fixed when we implement those
implication rules correctly? Does march=rv32imaf_zca/mabi=ilp32 still
not able select march=rv32imac/mabi=ilp32 still happen after this[1]
patch?
[1]
https://github.com/gcc-mirror/gcc/commit/42ce61eaefc4db70e2e7ea2d8ef091daa458eb48
On
This change refactors FMV handling in the frontend to allows greater
reasoning about versions in shared code.
This is needed for allowing target_clones and target_versions to be used
together in a function set, as there is then two distinct concerns when
encountering two declarations that previous
Add the assembler_name member to cgraph_function_version_info to store
the base assembler name of the funciton set, before FMV mangling. This is
used in later patches for refactoring FMV mangling.
gcc/ChangeLog:
* cgraph.cc (cgraph_node::insert_new_function_version): Record
assemb
Hi!
On 2025-05-28T09:18:29+0200, Richard Biener wrote:
> On Tue, 27 May 2025, Thomas Schwinge wrote:
>> "'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p'" isn't actually
>> a GIMPLE semantics invariant, thanks. I conclude that in case that this
>> "invariant" is violated, that's not a pr
Notably this respects target_version semantics where an unannotated
function can be the default version.
gcc/ChangeLog:
* attribs.cc (is_function_default_version): Add target_version logic.
Approved by Richard Sandiford.
---
gcc/attribs.cc | 27 ---
1 file change
This is similar to clone_function_name and its siblings but takes an
identifier tree node rather than a function declaration.
This is to be used in conjunction with the identifier node stored in
cgraph_function_version_info::assembler_name to mangle FMV functions in
later patches.
gcc/ChangeLog:
This patch removes the warning for target_version and target_clones
in aarch64 as it is now spec compliant.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_process_target_version_attr):
Remove warning.
* config/aarch64/aarch64.opt: Mark -Wno-experimental-fmv-target
Hi,
This patch makes auto-fdo more careful about keeping info we have
from static profile prediction.
If all counters in function are 0, we can keep original auto-fdo profile.
Having all 0 profile is not very useful especially becuase 0 in autofdo is not
very informative and the code still may hav
This patch adds a peephole2 optimization that combines a 'bclr' followed by
a 'binv' into a single 'bset' instruction when the Zbs extension is enabled.
The motivation for this patch is that PR116398 limits 2→2 RTL combinations,
which prevents certain simplifications in the combiner pass. As a res
> gcc/ChangeLog:
>
> * config/i386/i386-expand.cc (emit_reduc_half): Use shuffles to
> generate reduc half for V4SI, similar modes.
> * config/i386/i386.h (TARGET_SSE_REDUCTION_PREFER_PSHUF): New Macro.
> * config/i386/x86-tune.def (X86_TUNE_SSE_REDUCTION_PREFER_PSHUF):
>
On Wed, 28 May 2025, Thomas Schwinge wrote:
> Hi!
>
> On 2025-05-28T09:18:29+0200, Richard Biener wrote:
> > On Tue, 27 May 2025, Thomas Schwinge wrote:
> >> "'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p'" isn't actually
> >> a GIMPLE semantics invariant, thanks. I conclude that in c
Alejandro Colomar writes:
> [...]
> diff --git a/gcc/testsuite/gcc.dg/countof-vla.c
> b/gcc/testsuite/gcc.dg/countof-vla.c
> new file mode 100644
> index ..cc225df20689
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/countof-vla.c
> @@ -0,0 +1,35 @@
> +/* { dg-do compile } */
> +/* { dg
In AMD znver4, znver5 targets vpshufd, vpsrldq have latencies 1,2 and
throughput 4 (2 for znver4),2 respectively. It is better to generate
shuffles instead of shifts wherever possible. In this patch we try to
generate appropriate shuffle instruction to copy higher half to lower
half instead of a si
These are needed to correctly mangle FMV declarations.
gcc/ChangeLog:
* cgraph.h (struct cgraph_node): Add dispatcher_resolver_function and
is_target_clone.
---
gcc/cgraph.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
This patch adjust the passing of parameters for the move_only_function,
copyable_function and function_ref. For types that are declared as being passed
by value in signature template argument, the are passed by value to the invoker,
when they are small (at most two pointers), trivially move constru
Hi Yuta-san
> On 23 May 2025, at 07:49, Yuta Mukai (Fujitsu) wrote:
>
> Hello,
>
> We would like to enable features for FUJITSU-MONAKA that were implemented in
> GCC after we added support for FUJITSU-MONAKA.
> As the features were implemented in GCC15, we also want to backport it to
> GCC15.
> From: Jakub Jelinek
> Sent: Wednesday, May 28, 2025 3:41 PM
>
> On Wed, May 28, 2025 at 10:44:20AM +0800, Haochen Jiang wrote:
> > gcc/ChangeLog:
> >
> > * doc/extend.texi (C Extensions): Add missing menu items.
> > ---
> > gcc/doc/extend.texi | 1 +
> > 1 file changed, 1 insertion(+)
> >
On Tue, May 27, 2025 at 6:02 PM Robin Dapp wrote:
>
> This removes the non-SLP paths that were made unreachable in the
> previous patch.
This short series is OK. Please squash the two commits before pushing.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * tree-vect-stmts.cc (vectorizable_load)
From: Yunze Zhu
Currently when choosing multilib set for target like
march=rv32imaf_zca/mabi=ilp32,
gnu toolchain reports "Cannot find suitable multilib set".
This is because in current dependent extension zca implies c when has
combinations of extensions: Zca, F_Zca_Zcf or FD_Zca_Zcf_Zcd,
and
Hi all,
Reposting this as requested by Jeff Law.
-
Another update to this series.
This patch changes the version info structure to be sorted by
priority. This allows easier reasoning for optimisations and prevents having to
calculate the priority of functions repeatedly.
The other change i
The string_slice inherits from array_slice and is used to refer to a
substring of an array that is memory managed elsewhere without modifying
the underlying array.
For example, this is useful in cases such as when needing to refer to a
substring of an attribute in the syntax tree.
Adds some minim
This is a reimplementation of get_target_clone_attr_len,
get_attr_str, and separate_attrs using string_slice and auto_vec to make
memory management and use simpler.
Adds get_target_version helper function to get the target_version string
from a decl.
gcc/c-family/ChangeLog:
* c-attribs.c
Previously, the `record` argument in maybe_version_function allowed the
call to cgraph_node::record_function_versions to be skipped. However,
this was only skipped when both decls were already marked as versioned,
in which case we trigger the early exit in record_function_versions
instead. Therefo
On 28/05/2025 03:36, Jeff Law wrote:
On 5/27/25 2:36 AM, Alfie Richards wrote:
Hi Jeff,
On 22/05/2025 21:02, Jeff Law wrote:
On 5/22/25 9:05 AM, Alfie Richards wrote:
Hi Jeff,
I sent this patch with my implementation a while ago:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681
From: Alice Carlotti
This is for testing the x86 mangling of FMV versioned function
assembly names.
gcc/testsuite/ChangeLog:
* g++.target/i386/mv-symbols1.C: New test.
* g++.target/i386/mv-symbols2.C: New test.
* g++.target/i386/mv-symbols3.C: New test.
* g++.tar
From: Alice Carlotti
This tests the mangling of function assembly names when annotated with
target_clones attributes.
gcc/testsuite/ChangeLog:
* g++.target/powerpc/mvc-symbols1.C: New test.
* g++.target/powerpc/mvc-symbols2.C: New test.
* g++.target/powerpc/mvc-symbols3.
On Tue, 27 May 2025, Thomas Schwinge wrote:
> Hi!
>
> On 2025-05-23T17:01:31+0200, Richard Biener wrote:
> > Am 23.05.2025 um 16:49 schrieb Thomas Schwinge :
> >> This fell out of me looking into PR119835. This doesn't resolve the
> >> underlying
> >> issue, but instead of failing GIMPLE sema
Hi,
while looking into building GCC with 4 bytes alignment by default on
m68k, I ran into the following definition in gcc/config/m68k/linux.h:
/* For m68k SVR4, structures are returned using the reentrant
On Wed, May 28, 2025 at 10:44:20AM +0800, Haochen Jiang wrote:
> gcc/ChangeLog:
>
> * doc/extend.texi (C Extensions): Add missing menu items.
> ---
> gcc/doc/extend.texi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index edd3a0d96c5..
LGTM, thanks.
--
Regards
Robin
> I thought this issue should be fixed when we implement those
> implication rules correctly? Does march=rv32imaf_zca/mabi=ilp32 still
> not able select march=rv32imac/mabi=ilp32 still happen after this[1]
> patch?
>
> [1]
> https://github.com/gcc-mirror/gcc/commit/42ce61eaefc4db70e2e7ea2d8ef091d
On Mon, May 26, 2025 at 4:06 PM Luc Grosheintz
wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan(__mdspan::_ExtentsStorage): Change name
> of private member _M_dynamic_extens to _M_dyn_exts.
> * include/std/mdspan(extents): Change name of private member
> f
On Mon, May 26, 2025 at 4:15 PM Luc Grosheintz
wrote:
> Implements the parts of layout_left that don't depend on any of the
> other layouts.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan (layout_left): New class.
> * src/c++23/std.cc.in: Add layout_left.
>
> Signed-off-by:
Hi,
with normal profile feedback checking entry block count to be non-zero is quite
reliable check for presence of non-0 profile in the body since the function
body can only be executed if the entry block was executed. With autofdo this
is not true, since the entry block may just execute too few t
Hi Richard,
I've implemented some of your suggested changes, but I'm not entirely sure
there's an elegant way to handle the second one:
> "So here you'd want to verify we can to LT_EXPR for the types involved, and
> the cases which simplify to constant_boolean_node do not need any such check.
>
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Jan Hubicka
> Sent: Wednesday, May 28, 2025 3:52 PM
> To: Gorantla, Pranav
> Cc: gcc-patches@gcc.gnu.org; Kumar, Venkataramanan
> ; ubiz...@gmail.com
> Subject: Re: [PATCH] i386: Use Shuffles instead of
On Wed, 28 May 2025, Icen Zeyada wrote:
> Hi Richard,
> I've implemented some of your suggested changes, but I'm not entirely sure
> there's an elegant way to handle the second one:
> > "So here you'd want to verify we can to LT_EXPR for the types involved, and
> > the cases which simplify to co
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest version of this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Wednesday, May 14, 2025 4:06 PM
To: Sam James; Xi Ruoyao
Cc: Jeff Law; gcc-patches@gcc
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest reply on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Wednesday, May 14, 2025 3:55 PM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Djordje Todoro
On Thu, 22 May 2025, Nathaniel Shead wrote:
> This patch series adds support for streaming some internal declarations
> in C++20 modules that we previously would ICE on.
I like this patch series a lot, thanks for working on it! I can't
approve but it looks pretty good to me.
>
> The series h
On 5/28/25 10:09 AM, Steve Kargl wrote:
On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Yes, with one question.
commit 845768cbead03f76265e491bcf5ea6de7020
On 5/28/25 19:51, Tobias Burnus wrote:
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_e
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
This patch would like to introduce the combine of vec_dup + vmul.vv into
vmul.vx on the cost value of GR2VR. The late-combine will take place if
the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15
in test. There will be two cases for the combine:
OK.
--
Regards
Robin
On Tue, 27 May 2025, Nathaniel Shead wrote:
> On Wed, Nov 27, 2024 at 11:45:40AM -0500, Patrick Palka wrote:
> > On Fri, 8 Nov 2024, Nathaniel Shead wrote:
> >
> > > Does this approach seem reasonable? I'm pretty sure that the way I've
> > > handled the templating here is unideal but I'm not sur
On Sat, 24 May 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
LGTM FWIW
>
> -- >8 --
>
> When emitting a primary module interface, we must re-stream any TU-local
> entities that we saw in a partition. This patch adds the missing
> members fr
Change in this version:
* Add test using an integer-class distance type, based on views::iota.
-- >8 --
This implements ranges::starts_with and ranges::ends_with from the C++23
paper P1659R3. The logic of these algorithms is contained in an _S_impl
member function that takes optional size par
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest reply on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Wednesday, April 23, 2025 1:08 PM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Djordje Todo
We somehow missed to implement these OpenACC 2.6 functions (the
Fortran routines are newer: 3.3). It is actually used, at least,
by two SPEC hpc/accel (soma + lbm) tests (and OpenACC_VV) - and
it was trivial to implement, which was my workaround to make them
compile.
Besides adding the same-devic
On Wed, 28 May 2025, Tomasz Kaminski wrote:
>
>
> On Tue, May 27, 2025 at 7:08 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
>
> The 'volatile' issue from that PR Will be fixed in a separate patch as
> operator[] isn't the only opera
Tobias had noted that the C front end was not treating C23 constexprs
as constant in the user/condition selector property, which led to
missed opportunities to resolve metadirectives at parse time.
Additionally neither C nor C++ was permitting the expression to have
pointer or floating-point type -
On Wed, 28 May 2025, Tomasz Kamiński wrote:
> This patch adjust the passing of parameters for the move_only_function,
> copyable_function and function_ref. For types that are declared as being
> passed
> by value in signature template argument, the are passed by value to the
> invoker,
they
>
It's not clear whether a metadirective in a loop nest is supposed to
be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it
as an error.
gcc/c/ChangeLog
PR c/120180
* c-parser.cc (c_parser_omp_metadirective): Only consume the
token if it is the expected ')'.
This group of patches are for some lingering problems with
metadirective, which was a relatively late addition to GCC 15. The
first two address ICE-after-invalid problems in the C and C++ front
ends, and I think are suitable for backport to the GCC 15 branch as
well as trunk. The third patch addr
The new testcase included in this patch used to ICE in gcc after
diagnosing the first error, and in g++ it only diagnosed the error in
the first metadirective, ignoring the second one. The solution is to
make error recovery in the C front end more like that in the C++ front
end, and remove the cod
I have reviewed and posted feedback up to, but not including layout_stride
today.
Will try to finish tomorrow.
Thank you again for continuous work on the patches.
On Tue, May 27, 2025 at 4:40 PM Tomasz Kaminski wrote:
>
>
> On Tue, May 27, 2025 at 4:32 PM Luc Grosheintz
> wrote:
>
>> Since, I b
On Mon, May 26, 2025 at 4:13 PM Luc Grosheintz
wrote:
> Adds tests for layout_right and for the parts of layout_left that depend
> on layout_right.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
> tests for layout_stride.
>
On Wed, May 28, 2025 at 4:27 PM Patrick Palka wrote:
>
> >
> >
> > On Tue, May 20, 2025 at 6:32 PM Patrick Palka wrote:
> > On Tue, 20 May 2025, Tomasz Kaminski wrote:
> >
> > > I think I do not have any more suggestions for cases to check,
> so the impl LGTM.
> >
> > It's cool
On Mon, May 26, 2025 at 1:40 PM Andrew Pinski wrote:
>
> On Mon, May 26, 2025 at 5:36 AM Richard Biener
> wrote:
> >
> > On Sun, May 18, 2025 at 10:58 PM Andrew Pinski
> > wrote:
> > >
> > > This implements a simple copy propagation for aggregates in the similar
> > > fashion as we already do f
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3: error: 'mpfr_fmod_ui'
was not declared in this scop
Sandra Loosemore wrote:
It's not clear whether a metadirective in a loop nest is supposed to
be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it
as an error.
gcc/c/ChangeLog
PR c/120180
* c-parser.cc (c_parser_omp_metadirective): Only consume the
token i
On Mai 28 2025, John Paul Adrian Glaubitz wrote:
> Shouldn't the #undef in linux.h undefine DEFAULT_PCC_STRUCT_RETURN and not
> PCC_STATIC_STRUCT_RETURN?
No, they are separate target options. PCC_STATIC_STRUCT_RETURN is no
longer defined by default, so this is redundant now.
> And, secondly, sh
On 5/28/25 4:23 AM, Jiawei wrote:
This patch adds a peephole2 optimization that combines a 'bclr' followed by
a 'binv' into a single 'bset' instruction when the Zbs extension is enabled.
The motivation for this patch is that PR116398 limits 2→2 RTL combinations,
which prevents certain simplif
Richard Biener writes:
> On Thu, May 22, 2025 at 12:19 PM Richard Sandiford
> wrote:
>>
>> As the rtl.texi documentation of RTX_AUTOINC expressions says:
>>
>> If a register used as the operand of these expressions is used in
>> another address in an insn, the original value of the register i
Sandra Loosemore wrote:
The new testcase included in this patch used to ICE in gcc after
diagnosing the first error, and in g++ it only diagnosed the error in
the first metadirective, ignoring the second one. The solution is to
make error recovery in the C front end more like that in the C++ fro
Hi!
This is a v2 of the patch originally posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
It addresses Honza's feedback in this mail:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681119.html
It was approved with the requested changes above, but it only real
This is a v2. v1 was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.html
Changes since v1:
- Made epilog profile update code more resilient against
already-inconsistent profiles (e.g. PR120065), avoid ICEing in such a
situation.
Bootstrapped/regtested as a seri
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest reply on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Tuesday, April 22, 2025 9:34 PM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Djordje Todoro
On Wed, May 28, 2025 at 3:00 PM Patrick Palka wrote:
> On Wed, 28 May 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Tue, May 27, 2025 at 7:08 PM Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
> >
> > The 'volatile' issue from that PR Will be f
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Regards,
Jerrycommit 845768cbead03f76265e491bcf5ea6de7020ff39
Author: Jerry DeLisle
Date: Wed May 28 07:56:12 2025 -0700
Fortran: Adjust handling of optional com
From: Pan Li
This patch would like to combine the vec_duplicate + vmul.vv to the
vmul.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR. Then the late-combine will
take action if the cost of GR2VR is zero, and reject the combination
if the
On Wed, May 28, 2025 at 5:14 PM Tomasz Kaminski wrote:
>
>
> On Wed, May 28, 2025 at 4:53 PM Patrick Palka wrote:
>
>> On Wed, 28 May 2025, Tomasz Kamiński wrote:
>>
>> > This patch adjust the passing of parameters for the move_only_function,
>> > copyable_function and function_ref. For types th
From: Pan Li
Add asm dump check test for vec_duplicate + vmul.vv combine to vmul.vx,
with the GR2VR cost is 0, 1 and 2.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i16.c: Add as
From: Pan Li
Add asm dump check test for vec_duplicate + vmul.vv combine to vmul.vx,
with the GR2VR cost is 0, 2 and 15.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Add a
From: Pan Li
This patch would like to introduce the combine of vec_dup + vmul.vv into
vmul.vx on the cost value of GR2VR. The late-combine will take place if
the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15
in test. There will be two cases for the combine:
Case 0:
| .
On Wed, May 28, 2025 at 4:53 PM Patrick Palka wrote:
> On Wed, 28 May 2025, Tomasz Kamiński wrote:
>
> > This patch adjust the passing of parameters for the move_only_function,
> > copyable_function and function_ref. For types that are declared as being
> passed
> > by value in signature template
This patch adjust the passing of parameters for the move_only_function,
copyable_function and function_ref. For types that are declared as being passed
by value in signature template argument, they are passed by value to the
invoker,
when they are small (at most two pointers), trivially move const
On Wed, 28 May 2025, Tomasz Kaminski wrote:
>
>
> On Wed, May 28, 2025 at 4:53 PM Patrick Palka wrote:
> On Wed, 28 May 2025, Tomasz Kamiński wrote:
>
> > This patch adjust the passing of parameters for the
> move_only_function,
> > copyable_function and function_ref. For ty
Hi Tobias,
> you will notice that the PR is not recognized. The format as mentioned before
> is "PR component/number". Namely:
Thanks for the reminder! I'll use `-p` to double-check PR numbers going
forward.
> The second part is not what you are doing, you are actually changing the
> call from
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest reply on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Tuesday, April 22, 2025 9:00 PM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Djordje Todoro
This is just a rebase of the v1 patch, currently waiting on a conclusion
of the discussion here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682033.html
Tested as a series on aarch64-linux-gnu and x86_64-linux-gnu. OK for
trunk?
Thanks,
Alex
-- >8 --
This adjusts scale_profile_for_vec
On Mon, May 26, 2025 at 4:15 PM Luc Grosheintz
wrote:
> Implement the parts of layout_left that depend on layout_right; and the
> parts of layout_right that don't depend on layout_stride.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan (layout_right): New class.
> * src/c++23
>
>
> On Tue, May 20, 2025 at 6:32 PM Patrick Palka wrote:
> On Tue, 20 May 2025, Tomasz Kaminski wrote:
>
> > I think I do not have any more suggestions for cases to check, so the
> impl LGTM.
>
> It's cool how many optimizations we came up with for this algorithm :)
>
>
Sorry for the slow reply, had a few days off.
Xi Ruoyao writes:
> If we see a promoted subreg and TRULY_NOOP_TRUNCATION says the
> truncation is not a noop, then all bits of the inner reg are live. We
> cannot reduce the live mask to that of the mode of the subreg.
>
> gcc/ChangeLog:
>
> P
Add the `+cmpbr` option to enable the FEAT_CMPBR architectural
extension.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (cmpbr): New
option.
* config/aarch64/aarch64.h (TARGET_CMPBR): New macro.
* doc/invoke.texi (cmpbr): New option.
---
gcc/config
The `far_branch` attribute only ever takes the values 0 or 1, so make it
a `no/yes` valued string attribute instead.
gcc/ChangeLog:
* config/aarch64/aarch64.md (far_branch): Replace 0/1 with
no/yes.
(aarch64_bcond): Handle rename.
(aarch64_cbz1): Likewise.
Add rules for lowering `cbranch4` to CBB/CBH/CB when
CMPBR extension is enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.md (BRANCH_LEN_P_1Kib): New constant.
(BRANCH_LEN_N_1Kib): Likewise.
(cbranch4): Emit CMPBR instructions if possible.
(cbranch4): New expand rul
On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
> The attached patch is simple and self explanatory in the git log entry.
>
> Regression tested on X86_64-linux-gnu.
>
> OK for trunk?
>
Yes, with one question.
> commit 845768cbead03f76265e491bcf5ea6de7020ff39
> Author: Jerry DeLisle
>
Make the formatting of the RTL templates in the rules for branch
instructions more consistent with each other.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): Reformat.
(cbranchcc4): Likewise.
(condjump): Likewise.
(*compare_condjump): Likewise.
(aar
1 - 100 of 136 matches
Mail list logo
