On Tue, Jul 15, 2025 at 12:18 PM Andrew Pinski wrote:
>
> The switch conversion code asks initializer_constant_valid_p
> if the expression is a valid initializer constant and for
> vector types which have a non-constant elements initializer_constant_valid_p
> would return it is valid. But it shou
This patch fixes an ICE which occurs if a constant char is assigned
into an integer array. The fix it to introduce type checking in
M2GenGCC.mod:CodeXIndr.
gcc/m2/ChangeLog:
PR modula2/120389
* gm2-compiler/M2GenGCC.mod (CodeXIndr): Check to see that
the type of left is
> 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 testsui
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In Jakub's patch for PR44677 he added code to prevent mark_exp_read on
e.g. (void)++i from marking i as read, but it seems to me that we can
generalize that to avoid looking any farther into any void expression;
you can't read a void value,
The switch conversion code asks initializer_constant_valid_p
if the expression is a valid initializer constant and for
vector types which have a non-constant elements initializer_constant_valid_p
would return it is valid. But it should be rejected as not being
valid for an initializer.
Build and
This is a minor compile-time optimization for C++20.
libstdc++-v3/ChangeLog:
* include/bits/move.h (swap): Replace enable_if with concepts
when available, and with __enable_if_t alias otherwise.
---
Here's what I pushed.
Tested x86_64-linux.
libstdc++-v3/include/bits/move.h |
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The offset-based partial specialization of _CachedPosition for
random-access iterators is currently only selected if the offset type is
smaller than the iterator type. Before r12-1018-g46ed811bcb4b86 this
made sense since the m
On Tue, Jul 15, 2025 at 08:11:05AM -0500, Segher Boessenkool wrote:
> 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 a
Pierre Ossman writes:
> 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 inte
r15-6789-ge7f98d9603808b added a new RTL pass for hardreg PRE for the hard
register
of FPM_REGNUM, but this pass does nothing if there can be any FPM_REGNUM
register in it.
So let's set HARDREG_PRE_REGNOS to include all zeros if !TARGET_FP8.
Now the pass will only run if there is a possibility of
On Tue, Jul 15, 2025 at 12:52 AM Rainer Orth
wrote:
>
> 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,
>
On Tue, Jul 15, 2025 at 9:51 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> The offset-based partial specialization of _CachedPosition for
> random-access iterators is currently only selected if the offset type is
> smaller than the iterator
On Tue, Jul 15, 2025 at 10:36 PM Jonathan Wakely wrote:
> 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
Since only gnu/x86 targets support -mfentry, add -mfentry -fno-pic only
on gnu/x86 targets.
PR target/120881
PR testsuite/121078
* gcc.dg/20021014-1.c (dg-additional-options): Add -mfentry
-fno-pic only on gnu/x86 targets.
* gcc.dg/aru-2.c (dg-additional-opt
On Tue, Jul 15, 2025 at 2:51 PM John Ericson
wrote:
>
> This dates back to the creation of top-level `libgcc` in
> fa9585134f6f58fa0d3da3ca4ad5493855aea2dc. I strongly suspect that this
> does nothing.
So looking into this further, MACHMODE_H used part of LIBGCC_DEPS
because of TM_H and r0-78222-
On Tue, Jul 15, 2025 at 6:13 PM Patrick Palka wrote:
> 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 specif
As a side note, I think the linkage model that is used for class-scope
static constexpr variables
is matching what we want to achieve here, i.e. we could have:
struct X {};
struct S {
static constexpr X x = 10;
};
And then, in the source file.
const X S::x;
Maybe we could achieve a similar resu
On Tue, Jul 15, 2025 at 2:04 PM Gerald Pfeifer wrote:
>
> 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
>
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
1 - 100 of 123 matches
Mail list logo
