On Wed, Nov 12, 2025 at 11:50 PM Andrew Pinski
wrote:
>
> On Wed, Nov 12, 2025 at 11:30 PM Evgeny Karpov wrote:
> >
> > Saurabh Jha wrote:
> > > In v3, removed libgfortran changes in response to this comment:
> > > https://forge.sourceware.org/gcc/gcc-TEST/pulls/118#issuecomment-3894
> >
> > It l
On Wed, Nov 12, 2025 at 11:30 PM Evgeny Karpov wrote:
>
> Saurabh Jha wrote:
> > In v3, removed libgfortran changes in response to this comment:
> > https://forge.sourceware.org/gcc/gcc-TEST/pulls/118#issuecomment-3894
>
> It leads to the error below without changes to libgfortran/configure*
> and
Saurabh Jha wrote:
> In v3, removed libgfortran changes in response to this comment:
> https://forge.sourceware.org/gcc/gcc-TEST/pulls/118#issuecomment-3894
It leads to the error below without changes to libgfortran/configure*
and works fine after applying them.
gcc/libgfortran/kinds-override.h:29
Committed v2 to trunk.
On Wed, Nov 12, 2025 at 4:54 PM KuanLin Chen wrote:
>
> > >std::unique_ptr buf (new char[len+1]);
> > >char *str_to_check = buf.get ();
> > > + memset(str_to_check + len, 0, 1);
> >
> > aka. str_to_check[len] = '\0'
> It seems more readable. I'll resend the patch.
Am Mittwoch, dem 12.11.2025 um 22:07 + schrieb Joseph Myers:
> On Wed, 12 Nov 2025, Qing Zhao wrote:
>
> > > There are the various extensions (-fms-extensions / -fplan9-extensions)
> > > to
> > > consider as well, but it might be reasonable to say that only genuinely
> > > anonymous struct
For instruction sequence like
kmovb %k0, %edx
kmovb %k1, %ecx
orb %cl, %dl
je .L5
if only CCZ is cared, it can be optimized to
kortestb %k1, %k0
je .L5
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32}.
Ready push to trunk.
Forgot to add [PATCH] in the subject and didn't want to
accidentally miss people's inboxes.
Thanks,
Soumya
> On 13 Nov 2025, at 11:43 AM, Soumya AR wrote:
>
> AArch64: Add RTL pass to narrow 64-bit GP reg writes to 32-bit
>
> This patch adds a new AArch64 RTL pass that optimizes 64-bit
> gene
AArch64: Add RTL pass to narrow 64-bit GP reg writes to 32-bit
This patch adds a new AArch64 RTL pass that optimizes 64-bit
general purpose register operations to use 32-bit W-registers when the
upper 32 bits of the register are known to be zero.
This is beneficial for the Olympus core, which ben
So when we using the newly mapped location, we should check if
it is not unknown location and if so just use the original location.
Note this is a latent bug in remove_forwarder_block_with_phi code too.
This fixes gcc.dg/uninit-pr40635.c when doing more mergephi.
gcc/ChangeLog:
* tree-cf
This adds support for merging forwarder blocks with phis in cleanupcfg.
This patch might seem small but that is because the previous patches were
done to build up to make it easier to add this support.
There is still one more patch to merge remove_forwarder_block
and remove_forwarder_block_with_ph
It was always kinda of odd that while remove_forwarder_block used
an edge iterator, remove_forwarder_block_with_phi used a while loop.
remove_forwarder_block_with_phi was added after remove_forwarder_block too.
Anyways this changes remove_forwarder_block_with_phi into use the same
form of loop so
This moves the ei definition directly into for loo
like was done for remove_forwarder_block_with_phi.
gcc/ChangeLog:
* tree-cfgcleanup.cc (remove_forwarder_block): Move
variable declaration ei into for loop.
Signed-off-by: Andrew Pinski
---
gcc/tree-cfgcleanup.cc | 4 ++--
1 fi
Since at least r9-1005-gb401e50fed4def, dominator information is
available in remove_forwarder_block so there is no reason to have a
check on if we should update the dominator information, always do it.
This is one more step into commoning remove_forwarder_block and
remove_forwarder_block_with_ph
This moves the checks that were in pass_merge_phi::execute into
remove_forwarder_block_with_phi
or tree_forwarder_block_p to make easier to merge
remove_forwarder_block_with_phi with remove_forwarder_block.
This also simplifies the code slightly because we can do `return false` rather
than break
copy_phi_arg_into_existing_phi was added in r14-477-g78b0eea7802698
and used in remove_forwarder_block but since
remove_forwarder_block_with_phi needed to use the redirect edge var
map, it was not moved over. This extends copy_phi_arg_into_existing_phi
to have the ability to optional use the mapper
I noticed this check was in both remove_forwarder_block and
remove_forwarder_block_with_phi but
were slightly different in that eh landing pad was not being checked for
remove_forwarder_block_with_phi
when it definite should be.
This folds the check into tree_forwarder_block_p instead as it is ca
While moving mergephi's forwarder block removal over to cfgcleanup,
I noticed a few regressions due to removal of a forwarder block (correctly)
but the counts were not updated, instead let these blocks be handled by the
merge_blocks
cleanup code.
gcc/ChangeLog:
* tree-cfgcleanup.cc (tree
This is the last cleanup in this area. Merges the splitting functionality
of remove_forwarder_block_with_phi into remove_forwarder_block.
Now mergephi still has the ability to split the edges when merging the forwarder
block with a phi. But this reduces the non-shared code a lot.
gcc/ChangeLog:
Since removing the worklist for both mergephi and cfglceanup
(r0-80545-g672987e82f472b), these
two functions are now called right after tree_forwarder_block_p so there is no
reason to the
extra check for infinite loop nor the current loop on the headers check as it
is already
handled in tree_for
This moves most of mergephi functionality to cfgcleanup. The only thing
mergephi does that is not done in cfgcleanup is the ability to split edges in
some cases.
This includes many cleanups to the code that were missing over the years.
Including removing the worklist from mergephi which was never n
Since the worklist was never added to and the anlysis part can benifit
from the work part, we can combine the analayis part with the work part.
This should get a small speedup for this pass
Looking into the history here, remove_forwarder_block used to add to the
worklist
but remove_forwarder_bloc
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 31 October 2025 00:44
> To: Prathamesh Kulkarni ; gcc-
> [email protected]; Jan Hubicka
> Subject: RE: [RFC] Enable time profile function reordering with
> AutoFDO
>
>
>
> > -Original Message-
> > From: Prathamesh Ku
On 2025-11-12 11:26, Konstantinos Eleftheriou wrote:
This patch checks for the reordering cost on the target, for each
store,
using `avoid_store_forwarding_reorder_cost_p` before applying the
transformation.
It, also, updates the x86_64 testcases to set
`asf-default-cost-value=1`,
in order fo
On Wed, 12 Nov 2025, Alejandro Colomar wrote:
> > You can have multiple dg-error directives referencing the same line. E.g.
> >
> > /* { dg-error "expected" "syntax error" { target *-*-* } .-1 } */
> >
> > on the next line (here "expected" is the regular expression to test for,
> > "syntax err
Hi!
Here is a slightly updated version of the patch.
Fixes the mce_unknown case (sets *non_constant_p in that
case so that we e.g. don't try to cache results without emitting
diagnostics), the previous patch was incorrect in that part
and returned the CALL_EXPR instead of void_node while not setti
On Tue, Nov 11, 2025 at 5:15 AM Karl Meakin wrote:
>
>
> On 10/11/2025 23:06, Andrew Pinski wrote:
> > On Mon, Nov 10, 2025 at 10:28 AM Karl Meakin via Sourceware Forge
> > wrote:
> >> Hi gcc-patches mailing list,
> >> Karl Meakin has requested that the following
> >> forgejo pull request
> >>
Hi Joseph,
On Wed, Nov 12, 2025 at 10:03:09PM +, Joseph Myers wrote:
> > _Maxof (static int); /* { dg-error "to something not a type" } */
> >
> > trigger excess errors that I don't know how to deal with.
> >
> > c.c:12:16: error: invalid application of ‘_Maxof’ to something not a
Hi!
I've noticed that in many spots of the expansion statement handling I've
handled incorrectly the creation of VAR_DECLs which are constexpr
in the spec (or can be constexpr when user writes it that way).
All I've done was set DECL_DECLARED_CONSTEXPR_P and TREE_READONLY
flags on the VAR_DECL, bu
On Wed, 12 Nov 2025, Qing Zhao wrote:
> > There are the various extensions (-fms-extensions / -fplan9-extensions) to
> > consider as well, but it might be reasonable to say that only genuinely
> > anonymous struct / union members get the special counted_by handling,
>
> So, in C FE, what’s the
On Wed, 12 Nov 2025, Jasper Niebuhr wrote:
> Hi all,
> Gentle ping — this patch has been pending for review for about two weeks.
>
> Since GCC 16 is approaching Stage 3 in a few days, I’d like to get
> this reviewed and merged before the window closes, if possible.
Have plugin experts reviewed t
On Wed, 2025-11-12 at 22:16 +0100, Evgeny Karpov wrote:
> Hello,
>
> Thank you for reviewing v1.
> v2 contains the minimal changes.
>
> Changes in v2 2025-11-12:
> - Move the required socket library from LINK_SPEC to the host file.
> Adding the
> library to LINK_SPEC leads to HAVE_GETHOSTNAME det
On Wed, 12 Nov 2025, Alejandro Colomar wrote:
> > but you may be able to reduce the number of
> > diagnostics, by using the matching_parens machinery (with
> > skip_until_found_close) to go to the closing ')' after parsing the type
> > name (successfully or unsuccessfully).
>
> Okay, thanks.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-5207-ge7e1f2e40a2d1c.
gcc/ChangeLog:
PR diagnostics/115970
* diagnostics/sarif-sink.cc (maybe_open_sarif_sink_for_socket):
Add "%m" to error messages, so that we print the string form of
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-5206-g69b484f9481f53.
gcc/ChangeLog:
* diagnostics/sarif-sink.cc (class unique_fd): New.
(sarif_socket_sink::sarif_socket_sink): Convert "fd" arg and m_fd
f
Fix this warning:
warning: format not a string literal and no format arguments [-Wformat-security]
1498 | logger->log (name);
| ^~
Note that this is only ever called with string literal values for "name".
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
P
From: Evgeny Karpov
Subject: [PATCH v2 1/1] Support experimental SARIF JSON-RPC notifications on
MinGW host
[PATCH] diagnostics: add experimental SARIF JSON-RPC notifications for IDEs
[PR115970]
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=8a155c170b443e332b3db4922f0f0d588a17604f
introdu
Hello,
Thank you for reviewing v1.
v2 contains the minimal changes.
Changes in v2 2025-11-12:
- Move the required socket library from LINK_SPEC to the host file. Adding the
library to LINK_SPEC leads to HAVE_GETHOSTNAME detection, which requires
changes in the codebase.
Validated by
https://githu
Saurabh Jha wrote:
>>> +case $host in
>>> + aarch64-*-mingw* | aarch64-*-cygwin*)
>>> +LIBGOMP_CHECKED_REAL_KINDS="4 8" ;;
>>> + *)
>>
>> It looks like the first introduction of aarch64-*-cygwin in the GNU
>> toolchain.
>> The work on preparing the introduction of aarch64-pc-cygwin in binut
Hi Yuao,
Am 12.11.25 um 15:39 schrieb Yuao Ma:
Hi Tobias, hi Harald,
The attached patch resolves the issue introduced in
r14-8400-g186ae6d2cb93ad. Reproducer: https://godbolt.org/z/3aGM6enjv.
I believe the root cause is that, for an allocatable argument, we need
to first check if it is nullptr
The fix for PR122175 slightly changed the output for 16-bit constants
(no # prefix), and I forgot to add the updated tests with the fix.
gcc/testsuite/ChangeLog:
PR target/122175
* gcc.target/arm/mve/intrinsics/vbicq_m_n_s16.c: Adjust expected
output.
* gcc.target/
Hi Segher and All,
GCC currently emits three instructions (rldic/rldic/or) for RTL of the
form:
(ior (and (ashift S1 sh1) mask1)
(and (ashift S2 sh2) mask2))
even when the two masks select disjoint bitfields that can be merged
using a single `rldic` (rotate-and-mask) followed by an `rld
> -Original Message-
> From: Wilco Dijkstra
> Sent: 12 November 2025 16:55
> To: GCC Patches
> Cc: Alex Coplan ; Alice Carlotti
> ; Andrew Pinski
> ; Kyrylo Tkachov
> ; Tamar Christina
> Subject: [PATCH] AArch64: Use dmb ishld+ishst for release fence
>
>
> Use dmb ishld and dmb ishst f
From: Arthur Cohen
There was a typo in the original commit where the diagnostic context was not
being popped,
however popping the context still causes issues while bootstrapping.
For now, just mark -Warray-bounds as a warning to fix bootstrap on trunk and
think about
a proper fix (probably add
From: Arthur Cohen
Since this warning is not easily fixable, avoid it for now and wait for
the underlying issue to be resolved.
gcc/rust/ChangeLog:
PR rust/122498
* ast/rust-fmt.h: Add -Warray-bounds pragma to avoid the issue during
bootstraps
Co-authored-by: Thomas Sch
Applied to trunk with the requested fixup. Thanks!
--Philipp.
On Sat, 8 Nov 2025 at 06:40, Andrew Pinski
wrote:
>
> On Fri, Nov 7, 2025 at 8:06 AM Philipp Tomsich
> wrote:
> >
> > This adds support for the Ampere1c core to the AArch64 backend. The
> > initial patch only adds the core feature s
> -Original Message-
> From: Wilco Dijkstra
> Sent: 12 November 2025 17:03
> To: GCC Patches
> Cc: Alex Coplan ; Alice Carlotti
> ; Andrew Pinski
> ; Kyrylo Tkachov
> ; Tamar Christina
> Subject: [PATCH] AArch64: Improve ctz and ffs
>
>
> Use the ctz insn in the ffs expansion so it use
Use the ctz insn in the ffs expansion so it uses ctz if CSSC
is available. Rather than splitting, keep ctz as a single
insn for simplicity and possible fusion opportunities.
Move clz, ctz, clrsb, rbit and ffs instructions together.
Passes regress, OK for commit?
gcc:
* config/aarch64/aar
Use dmb ishld and dmb ishst for a release fence since this is less
restrictive than dmb ish.
Passes regress, OK for commit?
gcc:
* config/aarch64/atomics.md (*dmb): Expand release fence into dmb ishld
and dmb ishst.
---
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aa
> On Nov 10, 2025, at 16:56, Joseph Myers wrote:
>
> On Mon, 10 Nov 2025, Qing Zhao wrote:
>
>>> struct { int a; char b[] __attribute__ ((counted_by (a))); } *x;
>>
>> For such case, usually how to initialize the above x?
>> Since the anonymous structure has a FAM field, usually we need to u
Sometimes, `store_bit_field` copies the destination register into a new one,
which leads to the old register being used in the instructions that follow
the ones generated by `store_bit_field`, while the bit field insertion is
performed on the new register.
This patch copies back the new destinatio
This patch adds a new cost function so that the targets can decide if the
store/load reordering will be profitable. It also adds the
`asf-default-cost-value` parameter, which is used as the default return
value for the cost function.
gcc/ChangeLog:
* doc/tm.texi: Regenerate.
* doc
This patch adds an implementation for the
`avoid_store_forwarding_reorder_cost_p`
function on AArch64, which always returns `true`, as we have observed that in
most cases the ASF tranformation is profitable on this target.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_avoid
This patch checks for the reordering cost on the target, for each store,
using `avoid_store_forwarding_reorder_cost_p` before applying the
transformation.
It, also, updates the x86_64 testcases to set `asf-default-cost-value=1`,
in order for the transformations to be applied.
gcc/ChangeLog:
From: kelefth
This patch enables the avoid-store-forwarding patch by default at O2 or
higher.
The assembly patterns in `bitfield-bitint-abi-align16.c` and
`bitfield-bitint-abi-align8.c` have been updated to account for
the asf transformations.
Co-Authored-By: Christoph Müllner
gcc/ChangeLog:
The avoid-store-forwarding pass is disabled by default and therefore
in the risk of bit-rotting. This patch addresses this by enabling
the pass at O2 or higher.
We are, also, adding the target-specific cost function
`avoid_store_forwarding_reorder_cost_p`. There is no specific implementation
fo
Hi Andre,
> Expands the use of eor3 where we'd otherwise use two vector eor's.
>
> Bootstrapped and regression tested on aarch64-none-linux-gnu.
>
> OK for trunk?
OK. Simple and effective!
Cheers,
Wilco
>+(define_insn "*eor3q4"
>+ [(set (match_operand:ALLI 0 "register_operand" "=w")
>+
On Wed, 2025-11-12 at 15:05 +0100, Arsen Arsenović wrote:
> gcc/ChangeLog:
>
> * doc/invoke.texi (Diagnostic Message Formatting Options):
> Add
> index entries for SARIF and HTML output formats.
> ---
>
> OK for trunk? Tested by building the HTML documentation.
Thanks; looks reasona
Hi Jason,
On Mon, Nov 10, 2025 at 04:03:21PM +0530, Jason Merrill wrote:
> On 11/10/25 2:59 AM, Mark Wielaard wrote:
> >Ping again. Please let us know if there are any other tweaks needed to
> >the text or if it is good to go now.
>
> To be clear, my understanding of this wording is that e.g. whe
On Wed, 5 Nov 2025 at 11:29, Xavier Bonaventura
wrote:
>
> SIG_IGN also needs to be defined according to the C++ standard.
> This was missing in the test.
>
> libstdc++-v3/testsuite/ChangeLog:
>
> * 18_support/headers/csignal/macros.cc: New test.
>
> Signed-off-by: Xavier Bonaventura
> ---
>
On Wed, 2025-11-12 at 15:50 +0100, Evgeny Karpov wrote:
>
> [PATCH] diagnostics: add experimental SARIF JSON-RPC notifications
for IDEs [PR115970]
>
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=8a155c170b443e332b3db4922f0f0d588a17604f
> introduces a regression when building the toolchain for
Andrew Stubbs wrote:
For dev == omp_initial_device (on a Linux host):
* default device == an nvidia device
→ managed memory is used (honoring the alignment)
* default device != nvidia device (e.g. the host)
→ fall back is used → ABORT
(with default_fb, 'malloc' would be used but
with
This is a new updated patch for OpenMP uses_allocators support.
The last one was submitted by Tobias:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637415.html
This new version is a combination of all our patches and fixes during this
period, now including:
1. C/C++ front-end parts re-w
On 11/12/25 09:28, Richard Biener wrote:
On Wed, 12 Nov 2025, Richard Biener wrote:
On Tue, 11 Nov 2025, Victor Do Nascimento wrote:
Sorry about delayed reply,I've been obsessing on trying to solve one
last snag in the peeling for alignment implementation.
The reduction work was done tryi
This patch reworks construction and assigment of function_ref from
other function_ref specialization:
* the constructor is implicit, and have rebinding semantic if
signatures are compatible (__is_funcref_convertible is true)
* the cosntructor is explicit and assigment is deleted, if
signatu
On 11/11/2025 11:57, Tobias Burnus wrote:
Andrew Stubbs wrote:
On 10/11/2025 10:44, Tobias Burnus wrote:
There is still no clear note in the documentation that
this allocator uses the default device when doing the
allocation – and even less so that it must be the same
device (actually: device r
From: Evgeny Karpov
Subject: [PATCH] Support experimental SARIF JSON-RPC notifications on MinGW
host
[PATCH] diagnostics: add experimental SARIF JSON-RPC notifications for IDEs
[PR115970]
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=8a155c170b443e332b3db4922f0f0d588a17604f
introduces a r
The following ensures we still apply a runtime costmodel check even
when not peeling for niters. This is relevant for fully masked
loop vectorization and in this case triggers versioning of the loop.
Given the condition on whether we apply epilog peeling (not to mention
the condition determining w
Hi Tobias, hi Harald,
The attached patch resolves the issue introduced in
r14-8400-g186ae6d2cb93ad. Reproducer: https://godbolt.org/z/3aGM6enjv.
I believe the root cause is that, for an allocatable argument, we need
to first check if it is nullptr before validating the inner value.
Regression te
On Tue, 11 Nov 2025, Christopher Bazley wrote:
>
> On 07/11/2025 13:53, Richard Biener wrote:
> > On Thu, 6 Nov 2025, Christopher Bazley wrote:
> >
> >> On 05/11/2025 12:25, Richard Biener wrote:
> >>> On Tue, 4 Nov 2025, Christopher Bazley wrote:
> >>>
> On 28/10/2025 13:29, Richard Biener
This is a test-case-only issue, already fixed by:
r16-5195-g2de6462c3800ff
libgomp.{c-c++-common,fortran}/target-is-accessible-1.c: Fix testcases for
omp_default_device [P119677]
https://gcc.gnu.org/pipermail/gcc-patches/2025-November/700325.html
I forgot to update the two tests – and the fai
On Tue, 11 Nov 2025, Christopher Bazley wrote:
>
> On 05/11/2025 12:08, Richard Biener wrote:
> > On Tue, 4 Nov 2025, Christopher Bazley wrote:
> >
> >> On 04/11/2025 13:57, Christopher Bazley wrote:
> >>> On 28/10/2025 13:29, Richard Biener wrote:
> Isn't SLP_TREE_CAN_USE_PARTIAL_VECTORS_P
On Linux/x86_64,
5da963d988e8ea3a13bd8dca87c6cec943af7b56 is the first bad commit
commit 5da963d988e8ea3a13bd8dca87c6cec943af7b56
Author: Tobias Burnus
Date: Wed Nov 12 10:18:18 2025 +0100
OpenMP: Add omp_default_device named constant [PR119677]
caused
FAIL: libgomp.fortran/target-is-acc
On Wed, 12 Nov 2025, Richard Sandiford wrote:
> As a general comment, we do already support constructors of
> variable-length vectors, thanks to Tejas's earlier ACLE work.
> For example: https://godbolt.org/z/Eqd8sM4cv . The quality
> of the output is awful, but it does look correct.
>
> Sorry i
gcc/ChangeLog:
* doc/invoke.texi (Diagnostic Message Formatting Options): Add
index entries for SARIF and HTML output formats.
---
OK for trunk? Tested by building the HTML documentation.
gcc/doc/invoke.texi | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/doc/i
The categorization of uncounted loops as
LOOP_VINFO_EARLY_BREAKS_VECT_PEELED disables prolog peeling by
default. This is due to the assumption that you have early break
exits following the IV counting main exit. For such loops, prolog
peeling is indeed problematic.
For enabling prolog peeling in
On 12/11/2025 13:46, Christophe Lyon wrote:
> On Wed, 12 Nov 2025 at 14:40, Christophe Lyon
> wrote:
>>
>> On Wed, 12 Nov 2025 at 14:33, Christophe Lyon via Sourceware Forge
>> wrote:
>>>
>>> Hi gcc-patches mailing list,
>>> Christophe Lyon has requested that the following
>>> forgejo pull requ
On Wed, 12 Nov 2025 at 14:40, Christophe Lyon
wrote:
>
> On Wed, 12 Nov 2025 at 14:33, Christophe Lyon via Sourceware Forge
> wrote:
> >
> > Hi gcc-patches mailing list,
> > Christophe Lyon has requested that the following
> > forgejo pull request
> > be published on the mailing list.
> >
> > C
The following adds POINTER_DIFF_EXPR handling to SCEV stmt analysis,
mapping to conversions and MINUS_EXPR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/122653
* tree-scalar-evolution.cc (interpret_rhs_expr): Handle
POINTER_DIFF_EXPR.
On Wed, 12 Nov 2025 at 14:33, Christophe Lyon via Sourceware Forge
wrote:
>
> Hi gcc-patches mailing list,
> Christophe Lyon has requested that the following forgejo
> pull request
> be published on the mailing list.
>
> Created on: 2025-11-10 16:24:10+00:00
> Latest update: 2025-11-12 13:32:09+
From: Christophe Lyon
A constant value with the top bit of a 16-bit const passed to vbicq_n_u16 will
generate invalid assembly. Avoid this by masking the constant during assembly
generation.
The same applies to vorrq_n and vmvnq_n.
gcc/ChangeLog:
PR target/122175
* config/arm
Hi gcc-patches mailing list,
Christophe Lyon has requested that the following forgejo
pull request
be published on the mailing list.
Created on: 2025-11-10 16:24:10+00:00
Latest update: 2025-11-12 13:32:09+00:00
Changes: 3 changed files, 50 additions, 4 deletions
Head revision: clyon/gcc-TEST re
Those two tests slipped through the cracks as they happen to
work if offloading is enabled.
(That's a deficit in the current is-accessible
implementation as my system has USM, i.e. they would be
device accessible; I think we have a PR about this.)
In any case, the patch now uses again an invalid
From: Stefan Schulze Frielinghaus
Add documentation for options -mstack-protector-guard= and
-mstack-protector-guard-record which were added in commit
r16-5192-g0cd1f03939d and regenerate .opt.urls.
gcc/ChangeLog:
* config/i386/i386.opt.urls: Regenerate.
* config/s390/s390.opt.u
Hi Joseph,
On Tue, Nov 11, 2025 at 06:21:00PM +, Joseph Myers wrote:
> On Tue, 11 Nov 2025, Alejandro Colomar wrote:
>
> > I've significantly simplified this. However, the diagnostics are a bit
> > worse. For example:
> >
> > c.c:9:16: error: invalid application of ‘_Maxof’ to somethin
This implements P3913R1: Optimize for std::optional in range adaptors.
Specifically, for an opt of type optional that is a view:
* views::reverse(opt), views::take(opt, n), and views::drop(opt, n) returns
optional.
* views::as_const(opt), optional is converted into optional.
optional is not u
On 07/11/2025 13:26, Christophe Lyon wrote:
> Hi,
>
> Is this combination of commits
> 027205879733933ec991c230795da6c01ac50029 and
> 697ccadd7217316ea91ddd978ddc944e6df09522 OK for gcc-15?
>
> Thanks,
>
> Christophe
>
> The vadcq and vsbcq patterns had two problems:
> - the adc / sbc part of t
Currently because all the standard OpenMP/OpenACC headers and modules (omp.h,
openacc.h, omp_lib, etc.) are all part of libgomp, the compiler scan tests in
gcc/testsuite/*/gomp or gcc/testsuite/*/goacc cannot use them.
This became somewhat pronounced when several Fortran uses_allocators tests th
As a general comment, we do already support constructors of
variable-length vectors, thanks to Tejas's earlier ACLE work.
For example: https://godbolt.org/z/Eqd8sM4cv . The quality
of the output is awful, but it does look correct.
Sorry if that was already common ground -- just mentioning it
beca
Committed as r16-5192-g0cd1f03939d and also mentioned in www docs in
commit 87741e98fd7b6ecc5b51aff9be2629e147d01724.
On Thu, Jul 10, 2025 at 04:16:44PM +0200, Stefan Schulze Frielinghaus wrote:
> So far only a per thread canary in the TLS block is supported. This
> patch adds support for a globa
The addressed regression is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122584.
On Wed, Nov 12, 2025 at 11:21 AM Tomasz Kamiński
wrote:
> For non-templated tests, a volatile_ alias is used. This alias expands
> to
> volatile T if std::atomic_ref::is_always_lock_free is true, and to T
> otherwis
The following adds missing support for bool to float conversion which
can be exposed via C++ __builtin_bit_cast. It also corrects a too
lose check in vectorizable_conversion which would have resolved the
ICE but left us with the missed optimization.
Bootstrapped and tested on x86_64-unknown-linux
For non-templated tests, a volatile_ alias is used. This alias expands to
volatile T if std::atomic_ref::is_always_lock_free is true, and to T
otherwise. For templated functions, testing is controlled using if constexpr.
PR libstdc++/115402
libstdc++-v3/ChangeLog:
* testsuite/29_
Hi all,
Gentle ping — this patch has been pending for review for about two weeks.
Since GCC 16 is approaching Stage 3 in a few days, I’d like to get
this reviewed and merged before the window closes, if possible.
Thanks a lot,
Jasper
On Thu, Oct 30, 2025 at 10:00 PM York Jasper Niebuhr
wrote:
>
This syncs https://gcc.gnu.org/projects/gomp/ with
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Implementation-Status.html
by adding the TR 14 implementation status.
Some generic proof reading of both documents and filling in of
gaps wouldn't harm - as always.
I think some items might be by now
Thank you for the contribution, the patch looks good, but I have few
comments.
Also could you consider using git-send patch, so the patch content is
included in the e-mail?
Just to confirm, you are using the Signed-off tag in the meaning described
here: https://gcc.gnu.org/contribute.html#legal?
> -Original Message-
> From: Tamar Christina
> Sent: 12 November 2025 08:49
> To: Alice Carlotti
> Cc: [email protected]; Richard Earnshaw
> ; Kyrylo Tkachov ; Alex
> Coplan ; Andrew Pinski
> ; Wilco Dijkstra
> ; Alfie Richards
> Subject: RE: [PATCH] aarch64: Extend syntax for cpui
From: Saurabh Jha
The aarch64-w64-mingw32 target is different from aarch64-**-linux-gnu
targets with respect to how arguments for variadic functions are
handled. Specifically:
1. Homogeneous Floating-Point Aggregate (HFA) and Homogeneous Vector
Aggregate (HVA) are not handled in a special wa
From: Saurabh Jha
For mingw targets, there is no way to identify the end of function using
assembly directives right now.
This patch adds such directive as a comment. This is not a real
directive because some other things, like Structured Exception Handling
(SEH), needs to be supported before w
From: Saurabh Jha
On windows targets, the size of long double is 64 bits. Therefore,
unlike aarch64-**-linux-gnu, where the size of long double is 128
bits, the size of long double for aarch64-w64-mingw32 has to be 64
bits.
This commit makes changes to gcc so that long double is 64 bits for
aar
Hi gcc-patches mailing list,
Saurabh Jha has requested that the following
forgejo pull request
be published on the mailing list.
Created on: 2025-10-28 12:52:52+00:00
Latest update: 2025-11-12 09:44:17+00:00
Changes: 14 changed files, 716 additions, 27 deletions
Head revision: saurabh.jha/gcc-TE
1 - 100 of 113 matches
Mail list logo
