The following fixes the computation of supports_partial_vectors which
is used to prune the set of modes to iterate over for epilog
vectorization. The used partial_vectors_supported_p predicate
only looks for while_ult while also support predication when
mask modes are integer modes as for AVX512.
On Fri, 27 Jun 2025, Richard Biener wrote:
> On Thu, 26 Jun 2025, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > The following fixes the computation of supports_partial_vectors which
> > > is used to prune the set of modes to iterate over for epilog
> > > vectorization. The used pa
On Thu, Jun 26, 2025 at 3:40 PM Luc Grosheintz
wrote:
>
>
> On 6/13/25 12:40, Luc Grosheintz wrote:
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/mdspan (default_accessor): New class.
> > * src/c++23/std.cc.in: Register default_accessor.
> > * testsuite/23_containers/mdspan/
Fixes incorrect SP-addresses used in CFA notes for the stack probes
unrelative to the frame's top. It applied to the RISC-V targets code
generation when the stack-clash protection is enabled.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_allocate_and_probe_stack_space):
Fix SP-a
Hi Pan,
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vx_vf/vx_binary.h
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vx_vf/vx_binary.h
index 2932e189186..0af8b969f47 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vx_vf/vx_binary.h
+++ b/gcc/testsuite/gcc.target/riscv/rvv/auto
On Thu, 26 Jun 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > The following fixes the computation of supports_partial_vectors which
> > is used to prune the set of modes to iterate over for epilog
> > vectorization. The used partial_vectors_supported_p predicate
> > only looks for w
On Thu, 26 Jun 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > The following avoids re-analyzing the loop as epilogue when not
> > using partial vectors and the mode is the same as the autodetected
> > vector mode and that has a too high VF for a non-predicated loop.
> > This situatio
Hi Yuao,
Yuao Ma wrote:
>//but the testcases don't seem to be conditionalized on this. Would the
>//new tests fail if gcc is built against an insufficiently recent version
>//of mpfr,
…
The test case is indeed conditionalized, though in a different manner
than you
might expect. The condition
Since after a tail call function (even if it is tail called in the end),
the current function does not care about the local memory any more so
there is no reason to do a copy of the argument. This is only true for the
first usage of the decl, the rest requires a copy (c-c++-common/pr42909-3.c
chec
On Fri, Jun 27, 2025 at 7:27 AM Andi Kleen wrote:
>
> Uros Bizjak writes:
>
> > Introduce crc_revsi4 expanders to generate CRC32 instruction when
> > using
> > __builtin_rev_crc32_data* builtins with 0x1EDC6F41 poylnomial and -mcrc32.
> >
> > PR target/120719
> >
> > gcc/ChangeLog:
> >
> >
Uros Bizjak writes:
> Introduce crc_revsi4 expanders to generate CRC32 instruction when using
> __builtin_rev_crc32_data* builtins with 0x1EDC6F41 poylnomial and -mcrc32.
>
> PR target/120719
>
> gcc/ChangeLog:
>
> * config/i386/i386.md (crc_revsi4): New expander.
>
> gcc/testsuite/Change
Hi Dave,
> but the testcases don't seem to be conditionalized on this. Would the
> new tests fail if gcc is built against an insufficiently recent version
> of mpfr, and is/should there be some kind of dg-requires for this, so
> that the new tests gracefully are "UNSUPPORTED" on such configuration
On 6/26/25 10:51 AM, Stefan Schulze Frielinghaus wrote:
I didn't do any demotion of clobbers since I didn't see any value in it.
If a clobbered register gets accidentally clobbered as e.g. by an
implicitly introduced call, I wouldn't mind.
ACK. I hadn't really thought much about it, just so
On 6/26/25 10:46 AM, Stefan Schulze Frielinghaus wrote:
On Sat, Jun 21, 2025 at 09:18:43AM -0600, Jeff Law wrote:
On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
This implements error handling for hard register constraints including
potential conflicts with register asm operands.
I
On 6/26/25 10:38 AM, Stefan Schulze Frielinghaus wrote:
So you need a ChangeLog, but this is OK once the ChangeLog is cobbled
together. I think you should wait to commit until all 4 patches in this
series are ACK'd though.
Thanks for reviewing/commenting all four patches. Very much apprec
On 6/26/25 3:27 AM, Kito Cheng wrote:
Pipeline checker utility for RISC-V architecture that validates processor
pipeline models. This tool analyzes machine description files to ensure all
instruction types are properly handled by pipeline scheduling models.
I write this tool since I am implme
On 6/26/25 7:51 AM, Raphael Moreira Zinsly wrote:
The CFI output for when we do stack probing in a loop were not
accounting for the first sp adjustments, we can fix that by using the
frame's total size.
This is already being tested by g++.dg/torture/pr119610.C.
gcc/ChangeLog:
gcc/conf
From: Pan Li
Add asm dump check and run test for vec_duplicate + vssubu.vv
combine to vssubu.vx, with the GR2VR cost is 0, 2 and 15.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-u16.c: Add asm check.
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-u32.c: Ditto.
From: Pan Li
Add asm dump check test for vec_duplicate + vssubu.vv combine to
vssubu.vx, with the GR2VR cost is 0, 1 and 2.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-4-u16.c: Add asm check
for vssubu.vx combine.
* gcc.target/riscv/rvv/autovec/vx_vf
From: Pan Li
The cost model change will make the default cost of vx to 2, thus
reconcile the asm check for this change.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/sat/vec_sat_u_sub_trunc-1-u16.c:
Update the asm check due to cost model change.
* gcc.target/ri
From: Pan Li
This patch would like to combine the vec_duplicate + vssubu.vv to the
vssubu.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
From: Pan Li
This patch would like to introduce the combine of vec_dup + vssubu.vv
into vssubu.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, 2, 15 in test. There will be two cases for the combine:
Case 0:
On Thu, 26 Jun 2025, Patrick Palka wrote:
> PR libstdc++/100795
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_algo.h (__sample_fn::operator()):
> Reimplement the forward_iterator branch directly.
> * testsuite/25_algorithms/sample/constrained.cc (test02):
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
15/14?
-- >8 --
PR libstdc++/120789
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__unique_fn::operator()): Use
ranges::iter_move(iter) instead of std::move(*iter).
* testsuite/25_algo
PR libstdc++/120789
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__remove_if_fn::operator()): Use
ranges::iter_move(iter) instead of std::move(*iter).
* testsuite/25_algorithms/remove_if/120789.cc: New test.
---
libstdc++-v3/include/bits/ranges_algo.h
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__introselect): New,
based on the stl_algo.h implementation.
(nth_element_fn::operator()): Reimplement in terms of the above.
* testsuite/25_algorithms/nth_element/constrain
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__sample_fn::operator()):
Reimplement the forward_iterator branch directly.
* testsuite/25_algorithms/sample/constrained.cc (test02):
New test.
---
libstdc++-v3/include/bits/ranges_a
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__find_if_not_n): New,
based on the stl_algo.h implementation.
(__detail::__stable_partition_adaptive): Likewise.
(__stable_partition_fn::operator()): Reimplement in terms o
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (shuffle_fn::operator()):
Reimplement directly.
* testsuite/25_algorithms/shuffle/constrained.cc (test02):
---
libstdc++-v3/include/bits/ranges_algo.h | 58 ++-
.../25_a
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__move_merge): New,
based on the stl_algo.h implementation.
(__detail::__merge_sort_loop): Likewise.
(__detail::__chunk_insertion_sort): Likewise.
(__detail::__merge
As with the previous patch, this patch reimplements ranges::sort
directly instead of incorrectly forwarding to std::sort. In addition to
the compatibility changes listed in the previous patch we also:
- use ranges::iter_swap instead of std::iter_swap
- use ranges::move_backward instead of std
As with the previous patch, this patch reimplements ranges::inplace_merge
directly instead of incorrectly forwarding to std::inplace_merge. In
addition to the compatibility changes listed in the previous patch we
also:
- explicitly cast the difference type (which can be an integer class) to
ranges::push_heap, ranges::pop_heap, ranges::make_heap and
ranges::sort_heap are currently defined in terms of the corresponding
STL-style algorithms, but this is incorrect because the STL-style
algorithms rely on the legacy iterator system, and so misbehave when
passed a narrowly C++20 random acce
On Thu, Jun 26, 2025 at 2:17 PM H.J. Lu wrote:
>
> On Thu, Jun 26, 2025 at 2:11 PM Hongtao Liu wrote:
> >
> > On Thu, Jun 26, 2025 at 1:59 PM H.J. Lu wrote:
> > >
> > > Use the inner scalar mode of vector broadcast source in:
> > >
> > > (set (reg:V8DF 394)
> > >(vec_duplicate:V8DF (re
On Jun 26, 2025, Vladimir Makarov wrote:
> This patch is ok for me. I am a big fan of asserts. They helped to
> catch so many bugs on early stages.
That makes it two of us ;-)
Thanks a lot for the reviews.
Since this PR is now presumed solved, I've filed PR120838 for the
remaining issue with
Hi Honza,
> On 27 Jun 2025, at 1:03 am, Jan Hubicka wrote:
>
> External email: Use caution opening links or attachments
>
>
>>
>>
>>> On 24 Jun 2025, at 7:43 pm, Jan Hubicka wrote:
>>>
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Hi,
>>> this pass removes earl
LGTM, but please add some words to indicate what you have done for changelog.
You can find the examples from the previous PATCH(es) I bet.
> * gcc.target/riscv/sat/sat_arith.h:
Pan
-Original Message-
From: Ciyan Pan
Sent: Tuesday, June 24, 2025 11:13 AM
To: gcc-patches@gcc.gnu.o
Hi Honza,
> On 24 Jun 2025, at 4:37 pm, Jan Hubicka wrote:
>
> External email: Use caution opening links or attachments
>
>
>>>
>>> With part suffixes we also may want to merge specially, since the
>>> entry_count of the split part does not correspond to entry_count of the
>>> original function.
Hi,
I'm bumping this patch.
Jeremy
On Mon, Jun 9, 2025 at 8:00 PM Jeremy Rifkin wrote:
>
> Hi,
> This fixes PR c/82134 which concerns gcc emitting an incorrect unused
> result diagnostic for empty types. This diagnostic is emitted from
> tree-cfg.cc because of a couple code paths which attempt t
On Thu, May 8, 2025 at 11:11 AM H.J. Lu wrote:
>
> Conditional and unconditional branch targets can be either a label or
> a symbol. For conditional jump:
>
> (jump_insn 7 6 14 2 (set (pc)
> (if_then_else (eq (reg:CCZ 17 flags)
> (const_int 0 [0]))
> (label_ref
On Thu, 26 Jun 2025, Richard Biener wrote:
> The following prototypes diagnostics for conversions to/from time_t
> where the source/destination does not have sufficient precision for it.
> I've lumped this into -Wconversion for the moment and didn't bother
> fixing up the testcase for !ilp32 or th
On Mon, May 5, 2025 at 7:32 AM H.J. Lu wrote:
> Here is the v2 patch. ix86_get_small_integer_argument_value was moved to
> calls.cc. I added a target hook, TARGET_SAME_FUNCTION_ARGUMENT_ORDER_P,
> to verify that caller and callee have the same incoming argument
> order. The default returns
>
On 26/06/2025 21:47, Jonathan Wakely wrote:
On 26/06/25 19:30 +0200, François Dumont wrote:
I find it quite convenient so maybe you'll accept it.
Note that looking for existence of this macro I noticed that
ChangeLog-2024 is wrongly talking about
_GLIBCXX_USE_ALLOC_PTR_FOR_LIST in header.
On Wed, Jun 25, 2025 at 03:13:25PM -0400, Jason Merrill wrote:
> On 6/25/25 1:28 PM, Marek Polacek wrote:
> > @@ -24604,7 +24604,7 @@ resolve_nondeduced_context (tree orig_expr,
> > tsubst_flags_t complain)
> > }
> > if (good == 1)
> > {
> > - mark_used (goodfn);
> > + mark
On 26/06/25 19:30 +0200, François Dumont wrote:
I find it quite convenient so maybe you'll accept it.
Note that looking for existence of this macro I noticed that
ChangeLog-2024 is wrongly talking about
_GLIBCXX_USE_ALLOC_PTR_FOR_LIST in header. Should it be
fixed ?
No, I don't see any poi
The 64-bit register-to-register moves on PRU are implemented with two
instructions moving 32-bit registers. Defining a split for the 64-bit
moves allows this to be described in RTL, and thus one of the 32-bit
moves to be eliminated if the destination register is dead.
Also, split the loading of n
On Wed, Jun 25, 2025 at 1:37 PM Bill Wendling wrote:
>
> I posted this on the LLVM Discourse forum[1] and got some traction, so
> I want to get the GCC community's input. (My initial proposal is
> replicated here.)
>
> I had already mentioned this in previous emails in this thread, so
> it's nothi
On Thu, 2025-06-26 at 17:45 +, Yuao Ma wrote:
> Hi all,
>
> This patch, a follow-up to r16-1652-g0606d2b979f401, implements
> middle-end
> optimizations (e.g., constant folding) for our trigonometric pi-based
> function
> built-ins.
>
> This patch is part of
> https://gcc.gnu.org/pipermail/fo
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1715-g0e7296540be358.
gcc/ChangeLog:
PR analyzer/120809
* diagnostic-format-html.cc
(html_builder::maybe_make_state_diagram): Bulletproof against the
SVG generation failing.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1716-gc4d211bba2a86b.
gcc/ada/ChangeLog:
* gcc-interface/misc.cc (gnat_init): Use
diagnostic_context::set_internal_error_callback.
gcc/c-family/ChangeLog:
Ping for the series
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686373.html
Thanks
On 6/10/25 14:41, David Faust wrote:
> [v3: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html
> Changes v3->v4:
> - Only patch 2 (DWARF generation) is changed; update based on Richard's
>
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1714-g5bf213d4ad648f.
gcc/ChangeLog:
* diagnostic-output-spec.cc (sarif_scheme_handler::make_sink):
Split out creation of sarif_generation_options and
sarif
Hi all,
This patch, a follow-up to r16-1652-g0606d2b979f401, implements middle-end
optimizations (e.g., constant folding) for our trigonometric pi-based function
built-ins.
This patch is part of
https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj
Please take a look
Hi all,
This patch, a follow-up to r16-1652-g0606d2b979f401, implements middle-end
optimizations (e.g., constant folding) for our trigonometric pi-based function
built-ins.
This patch is part of
https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj
Please take a look
Hi Jerry,
for the moment only the static library is configured in the build scripts.
Therefore only that is build named libcaf_shmem.a That's completely correct
and desired.
I have asked the same question about performance or stress tests and got
only the coarray_icar (link in the 0/6 mail).
No chance to just answer to the question below about how conservative I
should be ?
Thanks
On 02/06/2025 07:07, François Dumont wrote:
Hi
It would be nice if someone got some time to review this PR.
Compared to other containers for which support of fancy allocator
pointer type have been add
I find it quite convenient so maybe you'll accept it.
Note that looking for existence of this macro I noticed that
ChangeLog-2024 is wrongly talking about _GLIBCXX_USE_ALLOC_PTR_FOR_LIST
in header. Should it be fixed ?
libstdc++: Add _GLIBCXX_USE_ALLOC_PTR macro to rule them all
Pro
On Thu, Jun 26, 2025 at 01:33:08PM +0200, Jakub Jelinek wrote:
> I get some regressions (which I didn't get with the earlier patch, but
> it isn't obvious by what it has been caused):
It ICEs were caused by the canonicalize_obj_off change and indeed
> The ICEs are all in the same spot:
>
On 6/26/25 12:22 AM, Andre Vehreschild wrote:
Hi Jerry,
thanks for testing. I have fixed IMO most of the whitespace issues in the
patch attached to this mail:
https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html
About the 32 vs. 64 bit versions of the libraries: I never got in touch with
On Sat, Jun 21, 2025 at 09:18:43AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > This implements error handling for hard register constraints including
> > potential conflicts with register asm operands.
> >
> > In contrast to register asm operands, hard
On Mon, Jun 23, 2025 at 07:12:58PM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > Currently a register asm already materializes during expand. This
> > means, a hard register is allocated for the very first access of a
> > register asm as e.g. in an assig
On Sat, Jun 21, 2025 at 09:06:42AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > Implement hard register constraints of the form {regname} where regname
> > must be a valid register name for the target. Such constraints may be
> > used in asm statements
On Fri, Jun 20, 2025 at 10:17:20AM -0400, Vladimir Makarov wrote:
>
> On 5/20/25 3:22 AM, Stefan Schulze Frielinghaus wrote:
> > Implement hard register constraints of the form {regname} where regname
> > must be a valid register name for the target. Such constraints may be
> > used in asm statem
On 6/26/25 1:51 AM, Alexandre Oliva wrote:
On Jun 25, 2025, Vladimir Makarov wrote:
This patch is ok for me. I am a big fan of asserts. They helped to
catch so many bugs on early stages.
Thank you, Alex.
for gcc/ChangeLog
PR rtl-optimization/120424
* lra-elimination
On 2025-04-30 16:37, Joseph Myers wrote:
> On Sat, 26 Apr 2025, Florian Weimer wrote:
>
>> Builtins defined with BT_FN_INT_VAR etc. show as functions without
>> a prototype and trigger the warning.
>>
>> gcc/c/
>>
>> PR c/119950
>> * c-typeck.cc (convert_arguments): Check for built-in
Hi!
[ Please don't say "patch v1", it's just clutter. ]
The point of the patch is to improve some code that evokes undefined
behaviour. The sanitizer for that is how these problems were found,
you can remark that somewhere later in the message, but ubsan is not
what this patch is about, it does
On 6/23/25 12:00 AM, Alexandre Oliva wrote:
And here's a followup to clean up the mess I made in
lra_update_fp2sp_elimination, without any functional changes.
The various recent additions to lra_update_fp2sp_elimination rendered
it somewhat confusing, with intermixed groups of statements pert
Hi,
I found a bug in the module cleanup expression at the end of the test. In the
attached patch it is corrected.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
On Wed, 25 Jun 2025 15:48:11 +0200
Andre Vehreschild wrote:
> Hi,
>
> Antony Lewis reported this
On 6/23/25 12:01 AM, Alexandre Oliva wrote:
When attempting to bootstrap arm-linux-gnueabihf with
{BOOT_C,T}FLAGS='-g -O2 -fnon-call-exceptions
-fstack-clash-protection', gmp fails to build in stage2: gen-fac's
mpz_and gets miscompiled.
A pseudo is initialized before a loop and used in a PRE_I
>
>
> > On 24 Jun 2025, at 7:43 pm, Jan Hubicka wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi,
> > this pass removes early-inlining from afdo pass since all inlining
> > should now happen from early inliner. I tedted this on spec and there
> > are 3 i
On 6/22/25 11:59 PM, Alexandre Oliva wrote:
On Jun 13, 2025, Vladimir Makarov wrote:
* lra-eliminations.cc (lra_update_fp2sp_elimination):
Inactivate the unused fp2sp elimination right away.
Alas, this seems to cause trouble on arm-linux-gnueabihf bootstraps.
This is OK. In many cases It is
On 6/22/25 11:54 PM, Alexandre Oliva wrote:
Regstrapped on x86_64-linux-gnu, bootstrapped on arm-linux-gnueabihf
(arm and thumb modes), also tested with gcc-14 on arm-vx7r2 and
arm-linux-gnueabihf. Ok to install?
It is OK for me. Thank you, Alex
for gcc/ChangeLog
PR rtl-optimiza
On Thu, 26 Jun 2025 at 15:38, Jonathan Wakely wrote:
>
> On Thu, 26 Jun 2025 at 11:33, Jakub Jelinek wrote:
> >
> > On Wed, Jun 25, 2025 at 10:58:59PM +0200, Maciej Cencora wrote:
> > > update of std module is missing.
> >
> > Here is an updated patch which adds the std module part and while I wa
This pattern enables the combine pass (or late-combine, depending on the case)
to merge a vec_duplicate into a (possibly negated) minus-mult RTL instruction.
Before this patch, we have two instructions, e.g.:
vfmv.v.fv6,fa0
vfnmacc.vv v2,v6,v4
After, we get only one:
vfnmacc.vf
On 21/06/2025 12:35, Filip Kastl wrote:
> On Fri 2025-06-20 10:46:08, Alex Coplan wrote:
> > Hi,
> >
> > This adds a main() function to mklog.py (like e.g. check_GNU_style.py
> > has), which makes it easier to import and invoke from another python
> > script. This is useful when using a wrapper s
On Thu, 26 Jun 2025 at 11:33, Jakub Jelinek wrote:
>
> On Wed, Jun 25, 2025 at 10:58:59PM +0200, Maciej Cencora wrote:
> > update of std module is missing.
>
> Here is an updated patch which adds the std module part and while I was
> changing the patch, I've also added value_type/type and the 2 op
On Wed, Jun 25 2025, Martin Jambor wrote:
> Hi,
>
> when compiling
> gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
> with clang, it emits the following warning:
>
> gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc:145:46:
> warning: non-constant-expression
Hello Piyush.
I have a few high-level comments and questions, inlined below.
Thanks!
> This patch adds the vmtest-tool subdirectory under contrib which tests
> BPF programs under a live kernel using a QEMU VM. It automatically
> builds the specified kernel version with eBPF support enabled
> a
Hi Kito,
This patch adds a comment to the riscv.md file to clarify the purpose of
the file and reorders the include files for better organization.
this seems to have broken the build. I believe that's due to
-(include "vector.md")
(include "vector-crypto.md")
because vector crypto depend
Hello Piyush.
Sorry for the delay in reviewing. It's been quite a busy week at
work...
> This patch adds initial version of vmtest-tool script to test BPF
> programs on live kernel
>
> For now, the tool is standalone, but it is intended to be integrated with the
> DejaGnu testsuite to run BPF
I guess I missed it when I first ran the testsuite before sending the patch
for review. I rebased and re-ran the testsuite after getting approved and saw
the regression. But at that point I realised Jeff had already merged it.
Anyway, I'll regtest more carefully next time!
The CI helps with th
Introduce crc_revsi4 expanders to generate CRC32 instruction when using
__builtin_rev_crc32_data* builtins with 0x1EDC6F41 poylnomial and -mcrc32.
PR target/120719
gcc/ChangeLog:
* config/i386/i386.md (crc_revsi4): New expander.
gcc/testsuite/ChangeLog:
* gcc.target/i386/crc-builti
The CFI output for when we do stack probing in a loop were not
accounting for the first sp adjustments, we can fix that by using the
frame's total size.
This is already being tested by g++.dg/torture/pr119610.C.
gcc/ChangeLog:
gcc/config/riscv/riscv.cc
(riscv_allocate_and_probe_sta
On 26/06/2025 15:35, Robin Dapp wrote:
This is a followup to 92e1893e0 "RISC-V: Add patterns for vector-scalar
multiply-(subtract-)accumulate" that caused an ICE in some cases where
the mult
operands were wrongly swapped.
This patch ensures that operands are not swapped in the vector-scalar
ca
On 6/13/25 12:40, Luc Grosheintz wrote:
libstdc++-v3/ChangeLog:
* include/std/mdspan (default_accessor): New class.
* src/c++23/std.cc.in: Register default_accessor.
* testsuite/23_containers/mdspan/accessors/default.cc: New test.
Signed-off-by: Luc Grosheintz
---
This patch converts the fold-mem-offsets pass from DF to RTL-SSA.
Along with this conversion, the way the pass collects information
was completely reworked. Instead of visiting each instruction multiple
times, this is now down only once.
Most significant changes are:
* The pass operates mainly on
This is a followup to 92e1893e0 "RISC-V: Add patterns for vector-scalar
multiply-(subtract-)accumulate" that caused an ICE in some cases where the mult
operands were wrongly swapped.
This patch ensures that operands are not swapped in the vector-scalar case.
This looks reasonable, so OK for the
On Thu, 26 Jun 2025 at 14:19, Tomasz Kamiński wrote:
>
> This patch extract calls to _M_locale_fmt and construction of the struct tm,
> from the functions dedicated to each specifier, to main format loop in
> _M_format_to functions. This removes duplicated code repeated for specifiers.
>
> To allo
This patch extract calls to _M_locale_fmt and construction of the struct tm,
from the functions dedicated to each specifier, to main format loop in
_M_format_to functions. This removes duplicated code repeated for specifiers.
To allow _M_locale_fmt to only be called if localized formatting is enab
This patch reworks the formatting for the chrono types, such that they are all
formatted in terms of _ChronoData class, that includes all required fields.
Populating each required field is performed in formatter for specific type,
based on the chrono-spec used.
To facilitate above, the _ChronoSpec
Currently, GCC accepts an allocate clause (to use a specific memory
allocator and alignment) on the OpenMP target construct, but it has no
effect - memory is always allocated with the defaults.
This patch causes memory for privatized variables (i.e. variables in
private and firstprivate clause
On Thu, 26 Jun 2025 at 13:52, Tomasz Kaminski wrote:
>
>
>
> On Thu, Jun 26, 2025 at 2:26 PM Jonathan Wakely wrote:
>>
>> On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
>> >This patch reworks the formatting for the chrono types, such that they are
>> >all
>> >formatted in terms of _ChronoData c
On Thu, Jun 26, 2025 at 2:52 PM Jonathan Wakely wrote:
> On Thu, 26 Jun 2025 at 13:30, Tomasz Kaminski wrote:
> >
> >
> >
> > On Thu, Jun 26, 2025 at 2:13 PM Tomasz Kaminski
> wrote:
> >>
> >>
> >>
> >> On Thu, Jun 26, 2025 at 2:09 PM Jonathan Wakely
> wrote:
> >>>
> >>> On 26/06/25 11:39 +020
On Thu, 26 Jun 2025 at 11:35, Jakub Jelinek wrote:
>
> On Wed, Jun 25, 2025 at 08:20:55PM +0100, Jonathan Wakely wrote:
> > This won't work for -fno-rtti
>
> I've missed the || __cpp_exceptions part in there, thought it is &&.
>
> Here is an updated patch which uses just one definition of
> std::e
On Thu, 26 Jun 2025 at 13:30, Tomasz Kaminski wrote:
>
>
>
> On Thu, Jun 26, 2025 at 2:13 PM Tomasz Kaminski wrote:
>>
>>
>>
>> On Thu, Jun 26, 2025 at 2:09 PM Jonathan Wakely wrote:
>>>
>>> On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
>>> >This patch extract calls to _M_locale_fmt and constr
On Thu, 26 Jun 2025 at 11:33, Jakub Jelinek wrote:
>
> On Wed, Jun 25, 2025 at 10:58:59PM +0200, Maciej Cencora wrote:
> > update of std module is missing.
>
> Here is an updated patch which adds the std module part and while I was
> changing the patch, I've also added value_type/type and the 2 op
+ bool is_misaligned = scalar_align < inner_vectype_sz;
+ bool is_packed = scalar_align > 1 && is_misaligned;
+
+ *misalignment = !is_misaligned ? 0 : inner_vectype_sz -
scalar_align;
+
+ if (targetm.vectorize.support_vector_misalignment
+ (TYPE_MODE (vectype), inner_
Hi @Jeff Lawand all,
Please have a look at the below changes that were suggested and tested.
Thank you
~U
On Fri, Jun 13, 2025 at 8:31 PM Umesh Kalappa
wrote:
> Addressed the most of comments and tried to refactor the
> riscv_expand_conditional_move() to some extent.
>
> No regressions are
On Thu, Jun 26, 2025 at 2:13 PM Tomasz Kaminski wrote:
>
>
> On Thu, Jun 26, 2025 at 2:09 PM Jonathan Wakely
> wrote:
>
>> On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
>> >This patch extract calls to _M_locale_fmt and construction of the struct
>> tm,
>> >from the functions dedicated to each
On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
This patch reworks the formatting for the chrono types, such that they are all
formatted in terms of _ChronoData class, that includes all required fields.
Populating each required field is performed in formatter for specific type,
based on the chron
1 - 100 of 128 matches
Mail list logo
