On Mon, Jul 14, 2025 at 10:38 PM Jonathan Wakely wrote:
> This is a minor compile-time optimization for C++20.
>
Please mention that you also replaced _GLIBCXX20_CONSTEXPR, with
constexpr under __glibcxx_concepts (that is >= c++ 20).
Otherwise LGTM.
>
> libstdc++-v3/ChangeLog:
>
> * inc
On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> 15? Not sure if this corner case is worth backporting any further.
>
> Can we just use direct-list-initialization via {} instead of '= T()'
> here? I wasn't sure so I
On Mon, Jul 14, 2025 at 10:58 PM Jonathan Wakely wrote:
> We pre-emptively implemented part of LWG 2766, which still hasn't been
> approved. Add comments to the deleted swap overloads saying why they're
> there, because the standard doesn't require them.
>
> libstdc++-v3/ChangeLog:
>
> *
Hi,
r16-2175-g5aa21765236730 introduced an assert for floating-point modes
when expanding an RDIV_EXPR but forgot fixed-point modes. This patch
adds ALL_FIXED_POINT_MODE_P to the assert.
Bootstrap and regtest running on x86, aarch64, and power10. Regtested
on rv64gcv. Regtest on arm running,
On Tue, 15 Jul 2025 at 09:25, Tomasz Kaminski wrote:
>
>
>
> On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely wrote:
>>
>> The standard specifies some of the effects of ranges::advance in terms
>> of "Equivalent to:" and it's observable that our current implementation
>> deviates from the precise
> On 8 Jul 2025, at 17:43, Richard Sandiford wrote:
>
> Kyrylo Tkachov writes:
>> Thanks for your comments, do you mean something like the following?
>
> Yeah, the patch LGTM, thanks.
So it turned out that doing this in the EOR3 pattern in patch 4/7 caused
wrong-code in 531.deepsjeng_r:
[(s
On 08/07/25 18:01, Jan Hubicka wrote:
External email: Use caution opening links or attachments
Hi Honza,
On 8 Jul 2025, at 2:26 am, Jan Hubicka wrote:
External email: Use caution opening links or attachments
Hi,
as discussed also on the autofdo pull request, LLVM solves the same
problem
On 7/14/25 08:57, Tomasz Kaminski wrote:
Hi Luc,
While running the libc++ test on libstdc++ we have found the following
issue in our implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121061
Would you be interested in looking into fixing this?
Yes, I'll take care of this. Do you k
Hi Richard, thanks for the review!
We've tested the pre-patch version on PowerPC and there was indeed an
issue, which is now fixed with the patched version.
Konstantinos
On Fri, Jul 4, 2025 at 9:34 AM Richard Sandiford
wrote:
>
> Konstantinos Eleftheriou writes:
> > On Wed, May 7, 2025 at 11:2
On Tue, Jul 15, 2025 at 12:37 PM Jonathan Wakely wrote:
> On Tue, 15 Jul 2025 at 08:10, Tomasz Kaminski wrote:
> >
> >
> >
> > On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely
> wrote:
> >>
> >> This makes it possible to use `new(std::nothrow) X` without linking to
> >> libsupc++ or libstdc++.
On 14/07/2025 14:13, Jeff Law wrote:
Paul-Antoine''s patches don't have the leading "a" and "b" component
typically seen in a patch from git diff. I wonder if that's why pre-
commit testing isn't picking them up properly.
It's something I noticed when adding them to my system.
Yes, I have t
On Tue, 15 Jul 2025 at 08:10, Tomasz Kaminski wrote:
>
>
>
> On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely wrote:
>>
>> This makes it possible to use `new(std::nothrow) X` without linking to
>> libsupc++ or libstdc++.
>>
>> To ensure we still export the symbol from the library we need to
>> su
On Tue, Jul 15, 2025 at 1:35 PM Jonathan Wakely wrote:
> OK here are the details for all of the failing tests ...
>
> std/containers/views/mdspan/aligned_accessor/access.pass.cpp
>
> std/containers/views/mdspan/aligned_accessor/ctor.conversion.from.default_accessor.pass.cpp
> std/containers/views
On Thu, 10 Jul 2025 at 09:06, Jakub Jelinek wrote:
>
> On Wed, Jul 09, 2025 at 06:45:41PM -0400, Jason Merrill wrote:
> > > + && reduced_constant_expression_p (val))
> >
> > And a value doesn't need to be constant to be printable, we should be able
> > to print it unconditionally.
>
> Sure, the
On Tue, 15 Jul 2025 at 12:44, Tomasz Kaminski wrote:
>
>
>
> On Tue, Jul 15, 2025 at 1:35 PM Jonathan Wakely wrote:
>>
>> OK here are the details for all of the failing tests ...
>>
>> std/containers/views/mdspan/aligned_accessor/access.pass.cpp
>> std/containers/views/mdspan/aligned_accessor/cto
On Tue, Jul 15, 2025 at 12:56 PM Luc Grosheintz
wrote:
>
>
> On 7/14/25 08:57, Tomasz Kaminski wrote:
> > Hi Luc,
> >
> > While running the libc++ test on libstdc++ we have found the following
> > issue in our implementation.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121061
> > Would you b
On Mon, Jul 14, 2025 at 11:58:32PM -0400, Jason Merrill wrote:
> Coming back to this comment, it still seems to me that we can generalize
> this and ignore anything cast to void here, as in the below; after something
> has been cast to void, it can no longer be read. I don't get any
> regressions
On Tue, 15 Jul 2025 at 08:29, Tomasz Kaminski wrote:
>
>
>
> On Mon, Jul 14, 2025 at 10:38 PM Jonathan Wakely wrote:
>>
>> This is a minor compile-time optimization for C++20.
>
> Please mention that you also replaced _GLIBCXX20_CONSTEXPR, with
> constexpr under __glibcxx_concepts (that is >= c+
Soumya AR writes:
> One additional change with this patch is that I had to update ldapr-sext.c
> too.
>
> During the combine pass, cases of UNSPECV_LDAP (with an offset) + sign_extend
> transform to LDAPUR + SEXT, and later to LDAPURS (with address folding).
>
> The aarch64 tests run with -moverr
On Tue, 15 Jul 2025 at 12:26, Jonathan Wakely wrote:
>
> On Tue, 15 Jul 2025 at 11:57, Luc Grosheintz wrote:
> >
> >
> >
> > On 7/14/25 08:57, Tomasz Kaminski wrote:
> > > Hi Luc,
> > >
> > > While running the libc++ test on libstdc++ we have found the following
> > > issue in our implementation.
On Tue, 15 Jul 2025 at 11:57, Luc Grosheintz wrote:
>
>
>
> On 7/14/25 08:57, Tomasz Kaminski wrote:
> > Hi Luc,
> >
> > While running the libc++ test on libstdc++ we have found the following
> > issue in our implementation.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121061
> > Would you be
On Tue, Jul 15, 2025 at 11:56 AM Jonathan Wakely wrote:
> On Tue, 15 Jul 2025 at 09:25, Tomasz Kaminski wrote:
> >
> >
> >
> > On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely
> wrote:
> >>
> >> The standard specifies some of the effects of ranges::advance in terms
> >> of "Equivalent to:" and
OK here are the details for all of the failing tests ...
std/containers/views/mdspan/aligned_accessor/access.pass.cpp
std/containers/views/mdspan/aligned_accessor/ctor.conversion.from.default_accessor.pass.cpp
std/containers/views/mdspan/aligned_accessor/ctor.conversion.pass.cpp
std/containers/vie
On Tue, 15 Jul 2025 at 12:06, Tomasz Kaminski wrote:
>
>
>
> On Tue, Jul 15, 2025 at 12:37 PM Jonathan Wakely wrote:
>>
>> On Tue, 15 Jul 2025 at 08:10, Tomasz Kaminski wrote:
>> >
>> >
>> >
>> > On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely
>> > wrote:
>> >>
>> >> This makes it possible to
On Tue, 15 Jul 2025 at 08:26, Tomasz Kaminski wrote:
>
>
>
> On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote:
>>
>> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
>> 15? Not sure if this corner case is worth backporting any further.
>>
>> Can we just use direct-list-i
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 15, 2025 9:41 AM
> To: Tamar Christina
> Cc: Yury Khrustalev ; gcc-patches@gcc.gnu.org; Mark
> Rutland
> Subject: Re: [PATCH 1/1] aarch64: Adapt unwinder to linux's SME signal
> behaviour
>
> Tamar Christina writes:
Alfie Richards writes:
> Hi all,
>
> This is a minor fixup to the previous patch I committed fixing Spencers
> comments.
>
> Bootstrapped and reg tested for Aarch64.
>
> Thanks,
> Alfie
>
> -- >8 --
>
> Fixup to the SME2+FAMINMAX intrinsics commit.
>
> gcc/ChangeLog:
>
> * config/aarch64/aar
Applied to trunk (with fixups to up the Changelog and after checking
again that the subreg_size_lowpart_offset is included). Thanks!
--Philipp.
On Tue, 15 Jul 2025 at 15:43, Richard Sandiford
wrote:
>
> Konstantinos Eleftheriou writes:
> > Hi Richard, thanks for the review!
> >
> > We've teste
> On 15 Jul 2025, at 3:24 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Soumya AR writes:
>> One additional change with this patch is that I had to update ldapr-sext.c
>> too.
>>
>> During the combine pass, cases of UNSPECV_LDAP (with an
Kwok Cheung Yeung wrote:
This patch fixes an ICE due to a null-pointer dereference when finding
the symbol for the procedure name in a declare variant directive,
which occurs because the result of gfc_find_sym_tree is being
dereferenced unconditionally. The result is now checked, and the
symbo
> On Jul 15, 2025, at 02:32, Richard Biener wrote:
>
> On Mon, Jul 14, 2025 at 10:58 PM Qing Zhao wrote:
>>
>>
>>> On Jul 7, 2025, at 13:07, Qing Zhao wrote:
>>>
>>> As I mentioned in the latest email I replied to the thread, the original
>>> implementation of the counted_by for pointer w
Konstantinos Eleftheriou writes:
> Hi Richard, thanks for the review!
>
> We've tested the pre-patch version on PowerPC and there was indeed an
> issue, which is now fixed with the patched version.
Thanks for the extra testing. The patch is ok for trunk and for
any necessary backports with the s
On 14/07/2025 22:24, Sam James wrote:
A patch rebased against trunk would also be appreciated. See
https://gcc.gnu.org/contribute.html for the needed format.
The patch applies cleanly against trunk, so nothing is needed there.
I was hoping to get the interest of someone more familiar with gc
Hi Tamar,
On Tue, Jul 15, 2025 at 07:00:02AM +, Tamar Christina wrote:
> Hi Yury,
>
> Thanks for the clear comments!
Thanks goes to Richard!
> > -Original Message-
> > From: Yury Khrustalev
> > Sent: Thursday, June 19, 2025 2:40 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Richard Sa
On Tue, Jul 15, 2025 at 3:55 PM Patrick Palka wrote:
> On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
>
> > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only
> > (since it impacts ABI)?
> >
> > In theory an Iterator
Define a fallback implementation of the __promoted_t alias for
hypothetical C++17 compilers which don't define __cpp_fold_expressions.
Without this, can't be compiled by such compilers, because the
3-arg form of std::hypot uses the alias.
libstdc++-v3/ChangeLog:
PR libstdc++/121097
LGTM. Thanks for fixing my issue.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-07-14 21:55
To: gcc-patches
CC: kito.ch...@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com;
pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Fix vsetvl merge rule.
Hi,
In PR120297 we fus
On Tue, 15 Jul 2025, Uros Bizjak wrote:
> LGTM for content, but let's ask Gerald to proofread the entry.
Happy to!
+ The --enable-x86-64-mfentry configure option is
+ added to enable -mfentry for x86-64 by default to use
+ __fentry__, instead of mcount for
+ profiling. This optio
This dates back to the creation of top-level `libgcc` in
fa9585134f6f58fa0d3da3ca4ad5493855aea2dc. I strongly suspect that this
does nothing.
(For context, my overall goal here is hoping libgcc can depend on
fewer/no stuff that is generated by `gcc/Makefile`. This is me trying to
pluck some low-ha
On Sun, Jul 13, 2025 at 10:59:32AM +0200, Mikael Morin wrote:
>
> Regression tested on x86_64-pc-linux-gnu.
> OK for master?
>
Yes, with one observation below.
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
> index 1561936daf1..af62e17442b 100644
> --- a/gcc/fortran/tran
> As we discussed, it would be good to have a page in the wiki to document
> this effort, something like https://gcc.gnu.org/wiki/BPFRunTimeTests.
The page now exists.
This patch extends libgdiagnostics to provide a way to capture
the pp tokens making up a message string, so that SARIF and
HTML sinks can retain information such as event IDs and URLs.
As well as richer output, this improves the round-tripping of such
information through sarif-replay.
This also al
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-2275-g1f0d76d61b94ac.
gcc/ChangeLog:
* spellcheck.cc: Define INCLUDE_ALGORITHM.
(CASE_COST, BASE_COST): Convert to...
(case_cost, base_cost): ...these, in a
On Tue, Jul 15, 2025 at 5:43 PM Patrick Palka wrote:
> On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Tue, Jul 15, 2025 at 3:55 PM Patrick Palka wrote:
> > On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
> >
> > > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka
> wrote:
> >
On 7/15/25 9:04 AM, Jakub Jelinek wrote:
On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
Given the above that seems rather unlikely, but I suppose it's fine if you
want to do it that way. The patch is OK either way.
Committed just the v2 patch. I can test your patch next with
Hi Alex,
> On 15 Jul 2025, at 14:59, Alex Coplan wrote:
>
> Hi,
>
> The predication of the SVE2 FP8 dot product insns was relying on the
> architectural dependency:
>
> FEAT_FP8DOT2 => FEAT_FP8DOT4
>
> which was relaxed in GCC as of
> r15-7480-g299a8e2dc667e795991bc439d2cad5ea5bd379e2, thus l
On Tue, Jul 15, 2025 at 08:30:33AM -0400, Jason Merrill wrote:
> > The diagnostic only changed for C++26, and I'm not sure why (the _S_at
> > function isn't constexpr, so why wasn't it failing there before?)
>
> In C++23, we could see that the outermost thing in the expression is a call
> to _M_er
On 7/10/25 8:44 AM, Dusan Stojkovic wrote:
This peephole pattern combines the following instructions:
bswap8:
rev8a5,a0
-> li a4,-65536
-> sraia5,a5,32
-> and a5,a5,a4
-> roriw a5,a5,16
and a0,a0,a4
or a
On 7/15/25 08:57, Kyrylo Tkachov wrote:
> External email: Use caution opening links or attachments
>
>
> Hi all,
>
> We already have patterns to use the NBSL instruction to implement vector
> NOR and NAND operations for SVE types and modes. It is straightforward to
> have similar patterns for the
On 7/15/25 5:26 AM, Jakub Jelinek wrote:
On Mon, Jul 14, 2025 at 11:58:32PM -0400, Jason Merrill wrote:
Coming back to this comment, it still seems to me that we can generalize
this and ignore anything cast to void here, as in the below; after something
has been cast to void, it can no longer be
On 7/15/25 7:49 AM, Jonathan Wakely wrote:
On Thu, 10 Jul 2025 at 09:06, Jakub Jelinek wrote:
On Wed, Jul 09, 2025 at 06:45:41PM -0400, Jason Merrill wrote:
+ && reduced_constant_expression_p (val))
And a value doesn't need to be constant to be printable, we should be able
to print it un
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/copy/debug/constexpr_neg.cc:
* testsuite/25_algorithms/copy_backward/debug/constexpr_neg.cc:
* testsuite/25_algorithms/equal/debug/constexpr_neg.cc:
*
testsuite/25_algorithms/lower_bound/debug/constexpr_partitioned_
Yes Ok to push. Thanks. Jerry
On Tue, Jul 15, 2025, 9:44 AM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Dear All,
>
> The failure that Steve mentioned below is fixed. ChangeLogs and patch are
> self-describing.
>
> Regtests fine - OK for mainline?
>
> Paul
>
> On Sat, 12 Jul 202
Hi!
On Tue, Jul 01, 2025 at 12:14:32PM -0400, Michael Meissner wrote:
> This patch adds the support that can be used in developing GCC support
> for potential future PowerPC processors.
>
> These changes are being added so that hardware designers can evaluate
> potential new features to be added
Kyrylo Tkachov writes:
> Hi all,
>
> SVE2 BSL2N (x, y, z) = (x & z) | (~y & ~z). When x == y this computes:
> (x & z) | (~x & ~z) which is ~(x ^ z).
> Thus, we can use it to match RTL patterns (not (xor (...) (...))) for both
> Advanced SIMD and SVE modes when TARGET_SVE2.
> This patch does that.
On Tue, 15 Jul 2025 at 13:55, Jakub Jelinek wrote:
>
> On Tue, Jul 15, 2025 at 08:30:33AM -0400, Jason Merrill wrote:
> > > The diagnostic only changed for C++26, and I'm not sure why (the _S_at
> > > function isn't constexpr, so why wasn't it failing there before?)
> >
> > In C++23, we could see
Tested on x86_64-pc-linux-gnu, does this look OK for trunk only
(since it impacts ABI)?
Changes in v2:
- Condition on forward_iterator instead of default_initializable.
-- >8 --
LWG 3569 adjusted join_view's iterator specification to handle non
default-constructible iterators by wrapping the c
For aarch64, libgcc is built with -Werror, after the latest
-Wunused-but-set* commit (r16-2258-g0eac9cfee8cb0b21d), a new warning
showed up:
```
../../../gcc/libgcc/config/libbid/bid_binarydecimal.c: In function
‘__binary32_to_bid128’:
../../../gcc/libgcc/config/libbid/bid_binarydecimal.c:130:31: e
At first this PR looked as if it was going to be one of those horrible
typebound procedure/operator tangles. However, it turned out that this was
entirely down to the attempt to extract the specific procedure for the
ASSOCIATE name during parsing. Returning NULL before expression resolution
fixed
Hi all,
SVE2 BSL2N (x, y, z) = (x & z) | (~y & ~z). When x == y this computes:
(x & z) | (~x & ~z) which is ~(x ^ z).
Thus, we can use it to match RTL patterns (not (xor (...) (...))) for both
Advanced SIMD and SVE modes when TARGET_SVE2.
This patch does that. The tied register requirements of BSL
Hi all,
We already have patterns to use the NBSL instruction to implement vector
NOR and NAND operations for SVE types and modes. It is straightforward to
have similar patterns for the fixed-width Advanced SIMD modes as well, though
it requires combine patterns without the predicate operand and an
This patch fixes an ICE due to a null-pointer dereference when finding
the symbol for the procedure name in a declare variant directive, which
occurs because the result of gfc_find_sym_tree is being dereferenced
unconditionally. The result is now checked, and the symbol is set to
NULL if it can
> On 15 Jul 2025, at 15:01, Alex Coplan wrote:
>
> Hi,
>
> This relaxes an overzealous assert that required the fpm_t argument to
> be in DImode when expanding FP8 intrinsics. Of course this fails to
> account for modeless const_ints.
>
> Bootstrapped/regtested on aarch64-linux-gnu, OK for
On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
> On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk only
> (since it impacts ABI)?
>
> In theory an Iterator that meets all semantic requirements of the
> input_iterator
> con
On 14/07/2025 15:26, Kyrylo Tkachov wrote:
+/* ARM EABI dummy unwinding routines.
+ Copyright 2014 Pierre Ossman for Cendio AB
+
+ This file is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software F
Kyrylo Tkachov writes:
> From 930789b3c366777c49d4eb2f4dc84b0374601504 Mon Sep 17 00:00:00 2001
> From: Kyrylo Tkachov
> Date: Fri, 11 Jul 2025 02:50:32 -0700
> Subject: [PATCH 1/2] aarch64: Use SVE2 NBSL for vector NOR and NAND for
> Advanced SIMD modes
>
> We already have patterns to use the N
Commit the test file `mask_load_2.c` before the vectorisation analysis
is changed, so that the changes in codegen are more obvious in the next
commit.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/mask_load_2.c: New test.
---
.../gcc.target/aarch64/sve/mask_load_2.c | 23
The function `vect_check_gather_scatter` requires the `base` of the load
to be loop-invariant and the `off`set to be not loop-invariant. When faced
with a scenario where `base` is not loop-invariant, instead of giving up
immediately we can try swapping the `base` and `off`, if `off` is
actually loo
On Tue, Jul 15, 2025 at 6:06 AM Jakub Jelinek wrote:
>
> On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
> > Given the above that seems rather unlikely, but I suppose it's fine if you
> > want to do it that way. The patch is OK either way.
>
> Committed just the v2 patch. I can te
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This was failing for two reasons:
1) We were wrongly treating the basic_string constructor as
zero-initializing the object, which it doesn't.
2) Given that, when we went to look for a value for the anonymous union,
we concluded that it was
On Tue, 15 Jul 2025, Patrick Palka wrote:
> On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Tue, Jul 15, 2025 at 3:55 PM Patrick Palka wrote:
> > On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
> >
> > > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka
> > wrote:
> >
On Tue, Jul 15, 2025 at 08:36:46AM -0700, Andrew Pinski wrote:
> On Tue, Jul 15, 2025 at 6:06 AM Jakub Jelinek wrote:
> >
> > On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
> > > Given the above that seems rather unlikely, but I suppose it's fine if you
> > > want to do it that way
On Tue, Jul 15, 2025 at 09:02:09AM -0700, Andrew Pinski wrote:
> For aarch64, libgcc is built with -Werror, after the latest
> -Wunused-but-set* commit (r16-2258-g0eac9cfee8cb0b21d), a new warning
> showed up:
> ```
> ../../../gcc/libgcc/config/libbid/bid_binarydecimal.c: In function
> ‘__binary32_
Resending this patch series because it seems the v2 patch didn't go through
properly (commit v2 1/2 is missing on sourceware). No changes from v2.
I also forgot to mention I do not have commit rights to the repo yet. So I will
need someone else to merge this for me. Thanks
Changelog:
* v3: No cha
On 7/14/25 11:34 PM, Umesh Kalappa wrote:
Updated the test for rv32 accordingly and no regress found for runs like
"runtest --tool gcc
--target_board='riscv-sim/-march=rv32gc_zba_zbb_zbc_zbs/-mabi=ilp32d/-mcmodel=medlow'
riscv.exp" and
"runtest --tool gcc
--target_board='riscv-sim/-march=rv
OK Paul, thanks. We probably ought to back port it to 15
On Tue, Jul 15, 2025, 9:22 AM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> At first this PR looked as if it was going to be one of those horrible
> typebound procedure/operator tangles. However, it turned out that this was
Dear All,
The failure that Steve mentioned below is fixed. ChangeLogs and patch are
self-describing.
Regtests fine - OK for mainline?
Paul
On Sat, 12 Jul 2025 at 19:57, Steve Kargl
wrote:
> All, Paul,
>
> In testing Paul's recent addition of support for IMPORT,
> I have uncovered an ICE due t
Hi,
The predication of the SVE2 FP8 dot product insns was relying on the
architectural dependency:
FEAT_FP8DOT2 => FEAT_FP8DOT4
which was relaxed in GCC as of
r15-7480-g299a8e2dc667e795991bc439d2cad5ea5bd379e2, thus leading to
unrecognisable insn ICEs when compiling a two-way FDOT with just
+fp8
Hi,
This relaxes an overzealous assert that required the fpm_t argument to
be in DImode when expanding FP8 intrinsics. Of course this fails to
account for modeless const_ints.
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk and backport
to GCC 15?
Thanks,
Alex
gcc/ChangeLog:
On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
> Given the above that seems rather unlikely, but I suppose it's fine if you
> want to do it that way. The patch is OK either way.
Committed just the v2 patch. I can test your patch next with other patches,
or do you want to test/com
Kyrylo Tkachov writes:
>> On 15 Jul 2025, at 15:50, Richard Sandiford
>> wrote:
>>
>> Kyrylo Tkachov writes:
>>> Hi all,
>>>
>>> SVE2 BSL2N (x, y, z) = (x & z) | (~y & ~z). When x == y this computes:
>>> (x & z) | (~x & ~z) which is ~(x ^ z).
>>> Thus, we can use it to match RTL patterns (not
On Tue, Jul 15, 2025 at 11:32 AM Robin Dapp wrote:
>
> Hi,
>
> r16-2175-g5aa21765236730 introduced an assert for floating-point modes
> when expanding an RDIV_EXPR but forgot fixed-point modes. This patch
> adds ALL_FIXED_POINT_MODE_P to the assert.
>
> Bootstrap and regtest running on x86, aarch
The avg3_floor pattern leverage the add and shift rtl
with the DOUBLE_TRUNC mode iterator. Aka, RVVDImode
iterator will generate avg3rvvsimode_floor, only the
element size QI, HI and SI are allowed.
Thus, this patch would like to support the DImode by
the standard name, with the iterator V_VLSI_
On 7/14/25 7:55 AM, Robin Dapp wrote:
Hi,
In PR120297 we fuse
vsetvl e8,mf2,...
vsetvl e64,m1,...
into
vsetvl e64,m4,...
Individually, that's ok but we also change the new vsetvl's demand to
"SEW only" even though the first original one demanded SEW >= 8 and
ratio = 16.
As we forget t
When we opportunistically mask an operand of a AND with an already
available loop mask we need to query that set with the correct number
of masks we expect.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/121059
* tree-vect-stmts.cc (vectorizable_
On Tue, 15 Jul 2025, Jonathan Wakely wrote:
> On Tue, 15 Jul 2025 at 08:26, Tomasz Kaminski wrote:
> >
> >
> >
> > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote:
> >>
> >> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> >> 15? Not sure if this corner case is worth
During the base register initialization, in the case that we are
eliminating the load instruction, we are using `offset == 0` in order
to find the store instruction that has the same offset as the load. This
would not work on big-endian targets where byte 0 would be the MS byte.
This patch updates
> On 15 Jul 2025, at 15:50, Richard Sandiford wrote:
>
> Kyrylo Tkachov writes:
>> Hi all,
>>
>> SVE2 BSL2N (x, y, z) = (x & z) | (~y & ~z). When x == y this computes:
>> (x & z) | (~x & ~z) which is ~(x ^ z).
>> Thus, we can use it to match RTL patterns (not (xor (...) (...))) for both
>> Ad
On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Jul 15, 2025 at 3:55 PM Patrick Palka wrote:
> On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
>
> > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka
> wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for t
Hi Piyush.
This form of the script looks generally good to me.
May be a good time to move to the second stage of the project, which if
I am not mistaken consists in creating some dejagnu infrastructure so we
can get testsuites running the script on the test sources.
At this point it would be g
On 7/10/25 10:21, Piyush Raj wrote:
> Hi David,
>
> On 09/07/25 03:33, David Faust wrote:
>>> diff --git a/contrib/bpf-vmtest-tool/.gitignore
>>> b/contrib/bpf-vmtest-tool/.gitignore
>>> new file mode 100644
>>> index 000..723dfe1d0f4
>>> --- /dev/null
>>> +++ b/contrib/bpf-vmtest-tool
Hi,
I wrote a small writeup to summarize the two approaches to generate
.ACCESS_WITH_SIZE for pointers with counted_by,
In this writeup, I described the major issue for the approach we agreed on last
week to fix PR120929, due to the problem,
the previous implementation in the committed (and rev
Hi Jose,
On 15/07/25 22:55, Jose E. Marchesi wrote:
Hi Piyush.
This form of the script looks generally good to me.
May be a good time to move to the second stage of the project, which if
I am not mistaken consists in creating some dejagnu infrastructure so we
can get testsuites running the scr
On Mon, Jul 14, 2025 at 10:41 PM Jonathan Wakely wrote:
> The new test is currently marked as XFAIL because PR c++/102284 means
> that GCC doesn't notice that the lifetimes have ended.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/121024
> * include/bits/ranges_uninitialized.h (ran
commit 4d7baa94a48c27030c8ffcfaf3dd187be09903a9
Author: Andrew Pinski
Date: Sun Jul 13 11:56:03 2025 -0700
tree: Add include to tm_p.h to tree.cc [PR120866]
broke SPARC bootstrap:
In file included from ./tm_p.h:4,
from /vol/gcc/src/hg/master/local/gcc/tree.cc:35:
/vol/gcc
On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely wrote:
> The standard specifies some of the effects of ranges::advance in terms
> of "Equivalent to:" and it's observable that our current implementation
> deviates from the precise specification in the standard. This was
> causing some failures i
On Mon, Jul 14, 2025 at 2:00 PM Jonathan Wakely wrote:
> I've just created LWG 4295 proposing this change, and am implementing it
> via this patch.
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/memory (swap, make_observer_ptr): Add
> constexpr.
> (operator==, oper
Hi @Jeff Law and all,
https://patchwork.sourceware.org/project/gcc/patch/20250715053410.557741-1-ukalappa.m...@gmail.com/
looks ok to us ,please let me any comments for your end ,
Thank you
~U
On Tue, Jul 15, 2025 at 11:04 AM Umesh Kalappa
wrote:
> Updated the test for rv32 accordingly and
Hi Yury,
This looks in general OK to me (Thanks for the clear comments!), but had some
questions:
> -Original Message-
> From: Yury Khrustalev
> Sent: Thursday, June 19, 2025 2:40 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Mark Rutland
>
> Subject: [PATCH 1/1] aarch64:
On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely wrote:
> This makes it possible to use `new(std::nothrow) X` without linking to
> libsupc++ or libstdc++.
>
> To ensure we still export the symbol from the library we need to
> suppress the inline variable in libsupc++/new_handler.cc which is done
1 - 100 of 123 matches
Mail list logo
