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
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!
[ 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 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 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 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 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 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 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 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 specifier, to main format loop in
_M_format_to functions. This removes duplicated code repeated for specifiers.
Great, this is exactl
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: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
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 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
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
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
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.
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
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
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
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
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
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
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
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::__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 (__sample_fn::operator()):
Reimplement the forward_iterator branch directly.
* testsuite/25_algorithms/sample/constrained.cc (test02):
New test.
---
libstdc++-v3/include/bits/ranges_a
101 - 128 of 128 matches
Mail list logo
