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
>
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 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
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
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 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
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,
>
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 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-
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
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
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
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
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
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 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
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
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
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
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
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 |
> 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.
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:
> >
> 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
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
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,
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
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
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 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
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
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
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
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
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
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
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 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_
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, 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
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, 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
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
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
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
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
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 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
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 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
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
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_
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/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 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
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
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 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
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.
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 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
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
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, 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
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
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 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
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
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
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 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
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
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:
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 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
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/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
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 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 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 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, 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 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
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, 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
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 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++.
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 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
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
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
> -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:
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
1 - 100 of 123 matches
Mail list logo
