Thanks Robin for comments.
> Where does the actual HI->SI extension happen then? No chance we see it
> during combine/late-combine?
There is no HI->SI extension from the 272.expand and combine dump, so there is
no change in RTL or
It is unsafe here. I think we need additional fix to make it wor
This patch implies zicsr for sdtrig and ssstrict extensions.
According to the riscv-privileged spec, the sdtrig and ssstrict extensions
are privileged extensions, so they should imply zicsr.
gcc/ChangeLog:
* config/riscv/riscv-ext.def: Imply zicsr.
---
gcc/config/riscv/riscv-ext.def | 4
On Fri, Sep 12, 2025 at 9:38 PM Alexandre Oliva wrote:
>
>
> This test requires a C++ compiler.
>
> This patch by Clément has been tested with multiple targets variants,
> including native aarch64-linux-gnu. Barring objections in the next few
> days, I'm going to put it in as obvious.
The patch
Hi Pan,
> The pattern of this patch only works on DImode, aka below pattern.
> v1:RVVM1DImode = (zero_extend:RVVM1DImode v2:RVVM1SImode)
> + (vec_dup:RVVM1DImode (zero_extend:DImode x2:SImode));
>
> Unfortunately, for uint16_t to uint32_t or uint8_t to uint16_t, we loss
> this extend op after ex
Add __get_errno_ptr() as yet another synonym for __errno_location.
This came up while updating a port for a target that uses this function
name in the implementation of errno. Tested on that target, and on
x86_64-linux-gnu and aarch64-linux-gnu natives. Ok to install?
for gcc/analyzer/Change
On 9/12/25 16:44, Gerald Pfeifer wrote:
I found an old patch on my system that had editorial changes around the
documentation of -fprofile-partial-training. Surprisingly it did not apply
cleanly any more. When digging into it I found that
commit b9857b78a4afb7ccdb8ff3858b48d25b1df5ceb3
From: Pan Li
Add asm dump check and run test for vec_duplicate + vwmulu.vv
combine to vwmulu.vx, with the GR2VR cost is 0, 2 and 15.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-u16.c: Add asm check
for vwmulu.vx.
* gcc.target/riscv/rvv/autovec/vx_v
This test requires a C++ compiler.
This patch by Clément has been tested with multiple targets variants,
including native aarch64-linux-gnu. Barring objections in the next few
days, I'm going to put it in as obvious.
for gcc/testsuite/ChangeLog
* gcc.target/aarch64/pr113356.C: Move to
> On Sep 10, 2025, at 23:05, Kees Cook wrote:
>
> On Tue, Sep 09, 2025 at 06:49:22PM +, Qing Zhao wrote:
>>
>>> On Sep 4, 2025, at 20:24, Kees Cook wrote:
>>> +For indirect call sites:
>>> +
>>> +- Keeping indirect calls from being merged (see above) by adding a
>>> + wrapping type so th
On Mon, 8 Sept 2025 at 15:19, Tomasz Kamiński wrote:
>
> From: Giuseppe D'Angelo
>
> Converting a weak_ptr to a weak_ptr requires calling
> lock() on the source object in the general case.
>
> Although the source weak_ptr does contain a raw pointer to
> Derived, we can't just get it and (up)cast
The use of the TLS register in a TOC/GOT address computation was
probably a cut&pasto or a thinko. It causes a linker warning and,
because the TLS access in the test is incomplete, may cause
significant confusion. Adjust to use the TOC/GOT register as base.
Tested manually with cross binutils
On 9/12/25 3:01 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK (obvious).
-- >8 --
My r16-3559-gc2e567a6edb563 reworked ADL for modules, including a change
to allow seeing module-linkage declarations if they only exist on the
instantiation path
N3517 (array subscripting without decay) has been added to C2y (via a
remote vote in May, not at a meeting). Implement this in GCC.
The conceptual change, that the array subscripting operator [] no
longer involves an array operand decaying to a pointer, is something
GCC has done for a very long t
From: Pan Li
This patch would like to introduce the combine of vec_dup + v{widen}u.vv
into v{widen}u.vx on the cost value of GR2VR. The late-combine will take
place if the cost of GR2VRlike 1, 2, 15 in test.
The below insn from uint32_t to uint64_t are included.
* vwaddu.vx
* vwsubu.vx
* vwmulu
From: Pan Li
Add asm dump check and run test for vec_duplicate + vwaddu.vv
combine to vwaddu.vx, with the GR2VR cost is 0, 2 and 15.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-u16.c: Add asm check
for vwaddu.vx.
* gcc.target/riscv/rvv/autovec/vx_v
From: Pan Li
Add asm dump check and run test for vec_duplicate + vwsubu.vv
combine to vwsubu.vx, with the GR2VR cost is 0, 2 and 15.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-u16.c: Add asm check
for vwsubu.vx.
* gcc.target/riscv/rvv/autovec/vx_v
From: Pan Li
This patch would like to combine the vec_duplicate + vwaddu.vv to the
vwaddu.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR. Then the late-combine will
take action if the cost of GR2VR is zero, and reject the combination
if
On 9/12/25 3:20 PM, Vladimir Makarov wrote:
On 9/12/25 1:01 PM, Jeff Law wrote:
Shreya's work to add the addptr pattern on the RISC-V port exposed a
latent bug in LRA.
We lazily allocate/reallocate the ira_reg_equiv structure and when we
do (re)allocation we'll over-allocate and zero-fill so
Le 11/09/2025 à 22:46, Harald Anlauf a écrit :
Am 11.09.25 um 22:27 schrieb Mikael Morin:
Le 11/09/2025 à 20:28, Harald Anlauf a écrit :
Dear all,
here's a - once found - seemingly simple and obvious fix for a memory
corruption happening when intrinsic assignment is used to set a scalar
alloca
On 9/12/25 1:01 PM, Jeff Law wrote:
Shreya's work to add the addptr pattern on the RISC-V port exposed a
latent bug in LRA.
We lazily allocate/reallocate the ira_reg_equiv structure and when we
do (re)allocation we'll over-allocate and zero-fill so that we don't
have to actually allocate an
Hello.
The previous patch depend on long double size change. Sending it as well.
Radek
---
>From b3295b9e3837da0afc882930dee2dd217ac85daf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Radek=20Barto=C5=88?=
Date: Tue, 28 Jan 2025 21:46:39 +0100
Subject: [PATCH 1/3] Change long double to 64bit (#3)
--
The following tries to do vect_transform_slp_perm_load exactly
once during analysis and once during transform. There's a 2nd
case left during analysis in get_load_store_type. Temporarily
this records n_perms in the load-store info and verifies that
against the value computed at transform stage.
On Fri, 12 Sep 2025, Patrick Palka wrote:
> On Fri, 12 Sep 2025, Jonathan Wakely wrote:
>
> > On Fri, 12 Sept 2025 at 18:39, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > > Patch generated with -w due to otherwise noisy whitespace changes.
> > >
Am 12.09.25 um 11:12 schrieb Mikael Morin:
Le 11/09/2025 à 22:46, Harald Anlauf a écrit :
Am 11.09.25 um 22:27 schrieb Mikael Morin:
Le 11/09/2025 à 20:28, Harald Anlauf a écrit :
Dear all,
here's a - once found - seemingly simple and obvious fix for a memory
corruption happening when intrins
Joseph Myers writes:
> This breaks building glibc with linker errors for some configurations in
> build-many-glibcs.py (loongarch64-linux-gnuf64 loongarch64-linux-gnusf
> m68k-linux-gnu-coldfire m68k-linux-gnu-coldfire-soft or1k-linux-gnu).
>
> Representative linker errors are as follows. Of c
Tested on x86-64/Linux, applied to mainline as obvious.
2025-09-12 Eric Botcazou
* ipa-pure-const.cc (check_stmt): Minor formatting tweaks.
(pass_data_nothrow): Fix pasto in description.
--
Eric Botcazoudiff --git a/gcc/ipa-pure-const.cc b/gcc/ipa-pure-const.cc
index 2519fb8
In tree-sra.cc, for the following stmt (initialization in source code):
s = {};
for the above lhs "s", the field "grp_assignment_write" of the created
struct access is 1;
however, for the following stmt (compiler added initialization):
s = .DEFERRED_INIT (size, init_type, &"s"[0]);
for the above
On Fri, Sep 12, 2025 at 11:43:00AM +0200, Ard Biesheuvel wrote:
> On Fri, 12 Sept 2025 at 11:08, Kees Cook wrote:
> >
> > On Fri, Sep 12, 2025 at 02:03:08AM -0700, Kees Cook wrote:
> > > On Thu, Sep 11, 2025 at 09:49:56AM +0200, Ard Biesheuvel wrote:
> > > > On Fri, 5 Sept 2025 at 02:24, Kees Cook
On Thu, 11 Sept 2025 at 22:41, Jonathan Wakely wrote:
>
> Whenever we use operator+ or similar operators on random access
> iterators we need to be careful to use the iterator's difference_type
> rather than some other integer type. It's not guaranteed that an
> expression with an arbitrary intege
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Patch generated with -w due to otherwise noisy whitespace changes.
-- >8 --
The ranges::shuffle optimization, copied from std::shuffle, has a
two-at-a-time PRNG optimization that considers the range of the
PRNG vs the size of the range.
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-3826-g85a97e1a8ee934.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/crash-test-write-though-null-sarif.c: Rename to...
* gcc.dg/plugin/crash-test-write-through-null-sarif.c: ...this.
* gcc.dg/plugin/crash-tes
This breaks building glibc with linker errors for some configurations in
build-many-glibcs.py (loongarch64-linux-gnuf64 loongarch64-linux-gnusf
m68k-linux-gnu-coldfire m68k-linux-gnu-coldfire-soft or1k-linux-gnu).
Representative linker errors are as follows. Of course assertion failures
indica
On Fri, 12 Sept 2025 at 13:37, H.J. Lu wrote:
>
> On Mon, Sep 8, 2025 at 5:54 AM Jonathan Wakely wrote:
>>
>> The standard requires that std::atomic::fetch_add does
>> not have undefined behaviour for signed overflow, instead it wraps like
>> unsigned integers. The compiler ensures this is true f
On Thu, 11 Sep 2025, Jonathan Wakely wrote:
> Using std::move(*it) is incorrect for iterators that use proxy refs, we
> should use ranges::iter_move(it) instead.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/121913
> * include/bits/ranges_algo.h (__rotate_fn::operator()): Use
>
Hello.
Sending also a git bundle containing the entire `woarm64` branch from
https://github.com/Windows-on-ARM-Experiments/gcc-woarm64.
Radek
woarm64.bundle
Description: woarm64.bundle
Shreya's work to add the addptr pattern on the RISC-V port exposed a
latent bug in LRA.
We lazily allocate/reallocate the ira_reg_equiv structure and when we do
(re)allocation we'll over-allocate and zero-fill so that we don't have
to actually allocate and relocate the data so often.
In the
On Fri, 12 Sep 2025, H.J. Lu wrote:
> On Fri, Sep 12, 2025 at 7:50 AM Joseph Myers wrote:
>
> > This breaks building glibc with linker errors for some configurations in
> > build-many-glibcs.py (loongarch64-linux-gnuf64 loongarch64-linux-gnusf
> > m68k-linux-gnu-coldfire m68k-linux-gnu-coldfire-
> I wonder in which cases we have misalignment == -1 but !is_packed?
Isn't that just the new case of gather_scatter (without punning and when we
couldn't analyze the dataref)? The dataref might be naturally aligned but we
explicitly set misalignment to -1.
In that case I relied on !is_packed f
UTF-8 characters in diagnostic output (such as the warning emoji ⚠️
used by fanalyzer) display as mojibake on Windows unless the utf8
code page is being used
This patch adds UTF-8 to UTF-16 conversion when outputting to a console
on Windows.
gcc/ChangeLog:
* pretty-print.cc (decode_utf8_c
On 9/9/25 8:19 AM, Matthias Kretz wrote:
Oh great, while replacing the '*' I messed up the indent. It's now using
spaces where it should use a Tab. OK for trunk like this?
OK (obvious).
--- 8< --
Signed-off-by: Matthias Kretz
gcc/cp/ChangeLog:
* mangle.cc
Hi All,
In the current Binutils we have disabled the feature gating for sysreg
by default and we have introduced a new flag "-meanble-sysreg-checking"
to renable some of this checking.
However in GCC, we have disabled the feature gating of sysreg to read/write
intrinsics __arm_[wr]sr* and we have
On Fri, Sep 12, 2025 at 12:09 PM Robin Dapp wrote:
>
> > I wonder in which cases we have misalignment == -1 but !is_packed?
>
> Isn't that just the new case of gather_scatter (without punning and when we
> couldn't analyze the dataref)? The dataref might be naturally aligned but we
> explicitly s
On Fri, Sep 12, 2025 at 4:58 AM Srinath Parvathaneni
wrote:
>
> Hi All,
>
> In the current Binutils we have disabled the feature gating for sysreg
> by default and we have introduced a new flag "-meanble-sysreg-checking"
> to renable some of this checking.
>
> However in GCC, we have disabled the
On Fri, Sep 12, 2025 at 8:18 AM H.J. Lu wrote:
> On Fri, Sep 12, 2025 at 7:50 AM Joseph Myers wrote:
>
>> This breaks building glibc with linker errors for some configurations in
>> build-many-glibcs.py (loongarch64-linux-gnuf64 loongarch64-linux-gnusf
>> m68k-linux-gnu-coldfire m68k-linux-gnu-c
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-3828-g259347de43e965.
gcc/ChangeLog:
PR diagnostics/120063
* diagnostics/context.cc (context::execution_failed_p): Also treat
any kind::fatal errors as leading to failed execution.
PR diagnostics/121876 tracks an issue inside our crash-handling, where
if an ICE happens when we're within a nested diagnostic, an assertion
fails inside diagnostic::context::set_diagnostic_buffer, leading to
a 2nd ICE. Happily, this does not infinitely recurse, but it obscures
the original ICE an
> -Original Message-
> From: Richard Biener
> Sent: Friday, September 12, 2025 1:40 PM
> To: Tamar Christina
> Cc: Robin Dapp ; GCC Patches patc...@gcc.gnu.org>; rdsandif...@googlemail.com
> Subject: RE: New optabs and IFN required for early break [bikeshed]
>
> On Thu, 11 Sep 2025, Tam
After late-combine is added, split1 can see an input like
(insn 56 55 169 5
(set (reg/v:DI 87 [ n ])
(ior:DI (and:DI (reg/v:DI 87 [ n ])
(const_int 281474976710655 [0x]))
(and:DI (reg:DI 131 [ _45 ])
(con
Hi H.J.,
> After
>
> commit 8cad8f94b450be9b73d07bdeef7fa1778d3f2b96
> Author: H.J. Lu
> Date: Fri Sep 5 15:40:51 2025 -0700
>
> c: Update TLS model after processing a TLS variable
>
> GCC will upgrade local-dynamic TLS model to local-exec without -fPIC.
> Compile TLS LD tests with -fPIC to
> On Sep 12, 2025, at 03:32, Kees Cook wrote:
>
> On Thu, Sep 11, 2025 at 03:04:01PM +, Qing Zhao wrote:
>>
>>
>>> On Sep 10, 2025, at 23:05, Kees Cook wrote:
>>>
>>> On Tue, Sep 09, 2025 at 06:49:22PM +, Qing Zhao wrote:
> On Sep 4, 2025, at 20:24, Kees Cook wrote:
>
Another lp64 vs lp64d issue. This time adjusting a #include in the test
isn't sufficient. So instead this sets the ABI to lp64d instead of
lp64. I don't think that'll impact the test materially.
Tested on the BPI and Pioneer systems where it fixes the failures with
the Andes tests. Pushing
Hi Yuao,
Yuao Ma wrote:
The following is might be an issue in the caller, but nonetheless
it fails with conditionals (gfc_match_omp_clauses [openmp.cc:2611]
calling gfc_extract_int) - while it works with arithmetic expressions
and named constants. (Compile with '-fopenmp'.)
...
!$omp do collap
The r16-3435-gbbc0e70b610f19 change (for LWG 4294) needs to be applied
to the debug mode __gnu_debug::bitset as well as the normal one.
libstdc++-v3/ChangeLog:
PR libstdc++/121046
* include/debug/bitset (bitset(const CharT*, ...)): Add
constraints on CharT type.
---
Teste
On 7/24/25 4:03 AM, Stefan Schulze Frielinghaus wrote:
It looks like we didn't have a test so far reaching this point which
changed with the new hard register constraint tests. Bootstrap and
regtest are still running on x86_64. If they succeed, ok for mainline?
-- >8 --
As noted by Sam in
On 9/11/25 11:14 PM, Max Filippov wrote:
Hi Suwa-san,
On Thu, Sep 11, 2025 at 1:48 PM Takayuki 'January June' Suwa
wrote:
If the Floating-Point Coprocessor option is configured and there are no
floating-point coprocessor instructions in the function, the unused
floating-point registers (f0
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
My r16-3559-gc2e567a6edb563 reworked ADL for modules, including a change
to allow seeing module-linkage declarations if they only exist on the
instantiation path. This caused a crash however as I neglected to
unwrap the st
Backport of upstream patch:
https://github.com/uxlfoundation/oneDPL/pull/1589
libstdc++-v3/ChangeLog:
PR libstdc++/117276
* include/pstl/parallel_backend_tbb.h (__func_task::finalize):
Make deallocation unconditional.
---
Tested x86_64-linux. Pushed to trunk. Backports ne
On 9/10/25 4:59 PM, David Malcolm wrote:
GCC has long supported the ability to selectively ignore warnings using
"#pragma GCC diagnostic ignored"; see:
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#index-pragma_002c-diagnostic
The SARIF standard supports capturing suppression in
On Mon, Sep 8, 2025 at 5:54 AM Jonathan Wakely wrote:
> The standard requires that std::atomic::fetch_add does
> not have undefined behaviour for signed overflow, instead it wraps like
> unsigned integers. The compiler ensures this is true for the atomic
> built-ins that std::atomic uses, but it'
Since IFUNC resolvers run early before the sanitizer run-time libraries
have a chance to set up the sanitizer infrastructure, disable sanitizer
in IFUNC resolver when the sanitizer infrastructure initialization is
needed.
gcc/
PR sanitizer/110442
* asan.h (sanitize_flags_p): Retur
This adds permute_info_type and removes the duplication from
vect_schedule_slp_node.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vectorizer.h (stmt_vec_info_type::permute_info_type): Add.
(vectorizable_slp_permutation): Declare.
* tree-vect-slp.cc (ve
The following makes us always use VMAT_STRIDED_SLP for negative
stride multi-element accesses. That handles falling back to
single element accesses transparently.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vect-stmts.cc (get_load_store_type): Use VMAT_STRIDED_SLP
The current implementation of generate_canonical yields NAN for float16_t and
fails to compile for float128_t on platforms where long double is IBM-128.
Indeed, it sets a long double variable based the provided RNG:
const long double __r = number_of_elements_in_the_range_of_the_RNG;
Later it mul
On 10/09/2025 20:03, David Malcolm wrote:
> On Wed, 2025-09-10 at 18:23 +0100, Richard Earnshaw (lists) wrote:
>> On 10/09/2025 14:06, Jeff Law wrote:
>>>
>>>
>>> On 9/10/25 4:23 AM, Iain Sandoe wrote:
>>>
Now we have this facility - and it is firing on my testboxes
(since i use this
On Fri, Sep 12, 2025 at 09:13:18AM +0200, Richard Biener wrote:
> On Fri, 12 Sep 2025, Nathaniel Shead wrote:
>
> > On Thu, Sep 11, 2025 at 11:08:54AM +0200, Richard Biener wrote:
> > > On Thu, 11 Sep 2025, Richard Biener wrote:
> > >
> > > > On Wed, 10 Sep 2025, Nathaniel Shead wrote:
> > > >
>
My r16-3810-g6456da6bab8a2c changes broke bootstrap for targets that use
the mutex-based atomic helpers. This fixes it by casting away the
unnecessary volatile-qualification on the _Atomic_word* before passing
it to __exchange_and_add_single.
libstdc++-v3/ChangeLog:
* config/cpu/generic/a
On Fri, 12 Sept 2025 at 11:08, Kees Cook wrote:
>
> On Fri, Sep 12, 2025 at 02:03:08AM -0700, Kees Cook wrote:
> > On Thu, Sep 11, 2025 at 09:49:56AM +0200, Ard Biesheuvel wrote:
> > > On Fri, 5 Sept 2025 at 02:24, Kees Cook wrote:
> > > >
> > > > Implement ARM 32-bit KCFI backend supporting ARMv
On Fri, Sep 12, 2025 at 02:03:08AM -0700, Kees Cook wrote:
> On Thu, Sep 11, 2025 at 09:49:56AM +0200, Ard Biesheuvel wrote:
> > On Fri, 5 Sept 2025 at 02:24, Kees Cook wrote:
> > >
> > > Implement ARM 32-bit KCFI backend supporting ARMv7+:
> > >
> > > - Function preamble generation using .word di
On Thu, Sep 11, 2025 at 09:49:56AM +0200, Ard Biesheuvel wrote:
> On Fri, 5 Sept 2025 at 02:24, Kees Cook wrote:
> >
> > Implement ARM 32-bit KCFI backend supporting ARMv7+:
> >
> > - Function preamble generation using .word directives for type ID storage
> > at -4 byte offset from function entr
> From: Robin Dapp
> Sent: Friday, September 12, 2025 2:53 PM
>
> > FAIL: gcc.target/i386/pr116896.c scan-assembler-times \tjp\t 2
> > FAIL: g++.target/i386/pr116896-1.C -std=gnu++20 scan-assembler-times
> \tjp\t 1
> > FAIL: g++.target/i386/pr116896-1.C -std=gnu++23 scan-assembler-times
> \tj
> -Original Message-
> From: Robin Dapp
> Sent: Thursday, September 11, 2025 3:03 PM
> To: Tamar Christina ; Robin Dapp
> ; Richard Biener
> Cc: gcc-patches@gcc.gnu.org; rdsandif...@googlemail.com; Robin Dapp
>
> Subject: Re: New optabs and IFN required for early break [bikeshed]
>
> >
Hello,
On Tue, 9 Sep 2025, Ville Voutilainen wrote:
> > But it would also be an invalid transformation of the compiler. So I
> > can't quite see the worry. The second check ("*p > 5") is conditional on
> > the first one:
> >
> > if (!p)
> > fail()
> > if (*p > 5)
> > fail2()
>
> Th
On Wed, Sep 10, 2025 at 11:23:42AM -0400, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk/15?
>
> -- >8 --
>
> We weren't explicitly treating a pack index specifier as a non-deduced
> context.
>
> PR c++/121795
>
> gcc/cp/ChangeLog:
The layout mapping test include a check that applies if is_exhaustive is
static. This commit introduces a concept to check if is_exhaustive is a
static member function that's compatible with the upcoming
layout_left_padded.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/
On Thu, Sep 11, 2025 at 03:04:01PM +, Qing Zhao wrote:
>
>
> > On Sep 10, 2025, at 23:05, Kees Cook wrote:
> >
> > On Tue, Sep 09, 2025 at 06:49:22PM +, Qing Zhao wrote:
> >>
> >>> On Sep 4, 2025, at 20:24, Kees Cook wrote:
> >>> +For indirect call sites:
> >>> +
> >>> +- Keeping indi
Hi,
Following is version 4 of the patch proposed for master to fix PR119702.
This patch has been bootstrapped and regtested on powerpc64le-linux.
Kindly review the patch.
Thanks and regards,
Avinash Jayakar
Changes from v3:
1. Add author information before changelog.
2. Right p
On Fri, 12 Sep 2025, Tamar Christina wrote:
> > 70a27555d900caf71932a2c794d9a77d06048b6a..b677a5308fb3498314cbbfc1
> > 865eae6bf1c815b9 100644
> > > --- a/gcc/doc/md.texi
> > > +++ b/gcc/doc/md.texi
> > > @@ -6087,6 +6087,25 @@ vectors with N signed/unsigned elements of size
> > S@. Find the abso
FYI: I have now committed it as 6c1d5b0f7d219dc11f32885b9931205e2fd6a015
Tobias Burnus wrote:
attached is a patch to update the Fortran section of the GCC 16
release notes. […] https://gcc.gnu.org/gcc-16/changes.html
Tobias
On Fri, 12 Sep 2025, Nathaniel Shead wrote:
> On Thu, Sep 11, 2025 at 11:08:54AM +0200, Richard Biener wrote:
> > On Thu, 11 Sep 2025, Richard Biener wrote:
> >
> > > On Wed, 10 Sep 2025, Nathaniel Shead wrote:
> > >
> > > > Does this fix seem reasonable, or is there something I've missed?
> > >
On Fri, 12 Sept 2025 at 06:44, Dimitar Dimitrov wrote:
>
> On Mon, Sep 08, 2025 at 01:35:59PM +0100, Jonathan Wakely wrote:
> > The standard requires that std::atomic::fetch_add does
> > not have undefined behaviour for signed overflow, instead it wraps like
> > unsigned integers. The compiler ens
On Mon, Sep 08, 2025 at 01:35:59PM +0100, Jonathan Wakely wrote:
> The standard requires that std::atomic::fetch_add does
> not have undefined behaviour for signed overflow, instead it wraps like
> unsigned integers. The compiler ensures this is true for the atomic
> built-ins that std::atomic uses
81 matches
Mail list logo
