On 8/6/25 9:26 AM, David Faust wrote:
CTF array encoding uses uint32 for number of elements. This means there
is a hard upper limit on array types which the format can represent.
Hi David,
Thanks for the patch.
Few nits. But otherwise the patch looks good. As you noted in the
bugzilla, mo
From 0210a1a410cfafd79521e15cd96682ed3d5b4943 Mon Sep 17 00:00:00 2001
From: Eczbek
Date: Thu, 5 Jun 2025 14:27:48 -0400
Subject: [PATCH] c++: [PR116928]
PR c++/116928
gcc/cp/ChangeLog:
* parser.cc (cp_parser_braced_list):
gcc/testsuite/ChangeLog:
* g++.dg/parse/template32.C: New
Pushed, thanks!
On 8/22/25 5:37 PM, John Ericson wrote:
From: John Ericson
The old C-style was cumbersome make making one responsible for manually
creating and passing in two parts a closure (separate function and
*_info class for closed-over variables).
With C++ lambdas, we can just:
- deri
Changes in v2:
* tai_clock and gps_clock remain "is_steady = false".
* Note adjustments to the exported global symbols list are
not yet included in this patch.
This moves std::tai_clock::now() and std::tai_clock::now()
definitions from header inlines to static members invoked via a
normal func
Changes in v2:
* tai_clock and gps_clock remain "is_steady = false".
* Note adjustments to the exported global symbols list are
not yet included in this patch.
This moves std::tai_clock::now() and std::tai_clock::now()
definitions from header inlines to static members invoked via a
normal func
Allow passing --with-tls= at configure-time to control the default value
of -mtls-dialect= for i386 and x86_64. The default itself (gnu) is not changed
unless --with-tls= is passed.
--with-tls= is already wired up for ARM and RISC-V.
gcc/ChangeLog:
PR target/120933
* config.gcc (
From: John Ericson
Now that `find_a_program` and `find_a_file` have been separated, we can
make a number of simplification in both of them. Most notably, we don't
need a mode parameter, because one is always doing `R_OK`, and the other
is always doing `X_OK`.
This change also proves that some of
Prefatory note:
I've since learned that this quite similar to
https://inbox.sourceware.org/gcc-patches/20240522095404.1825269-1-...@gcc.gnu.org/,
postdating my original patch series, but predating this version. See
that thread for additional motivation. That patch updated a few specific
callsite f
We will use this in the subsequent patch to control what filenames we
search for.
gcc/ChangeLog:
* gcc.cc (for_each_path): Pass an additional boolean argument to
the callback specifying whether the current directly being
searched is machine-specific, as described above.
Do this by inlining (a copy of) find_a_file into find_a_program.
This separation continues what I started in way back in
5fee8a0a9223d030c66d53c104fb0a431369248f --- there should be
executable-specific logic cluttering up find_a_file either, but instead
there is a clean separation.
This commit is
Now that Jason Merrill has soft-approved
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693141.html, I am
rebasing this series on top of that (they were touching the same code).
Note that I think the first two are good refactor regardless of whether we want
this new feature or not, so it
On Fri, Aug 22, 2025 at 08:29:16PM +, Qing Zhao wrote:
> > On Aug 22, 2025, at 15:02, Kees Cook wrote:
> > Right, and sometimes we have to explicitly perform a no-op
> > address-taking to make sure a symbol gets generated:
> >
> > /*
> > * Force the compiler to emit 'sym' as a symbol, so that
From: John Ericson
The old C-style was cumbersome make making one responsible for manually
creating and passing in two parts a closure (separate function and
*_info class for closed-over variables).
With C++ lambdas, we can just:
- derive environment types implicitly
- have fewer stray static f
On Fri, Aug 22, 2025, at 2:35 PM, Jason Merrill wrote:
> That looks fine to me. Please combine all three patches into one.
Great!
Also I remembered that since we're using templates now, I can also go ahead and
use a polymorphic return type to get rid of a pair of void* <-> char* casts. So
the
> On Aug 22, 2025, at 15:02, Kees Cook wrote:
>
> On Fri, Aug 22, 2025 at 03:11:16PM +, Qing Zhao wrote:
>>> On Aug 21, 2025, at 17:29, Kees Cook wrote:
>>> For non-static functions, we cannot know if other compilation units may
>>> make indirect calls to a given function, so those functi
Ping!
Please review.
Thanks & Regards
Kishan
On 24/07/25 8:48 pm, Kishan Parmar wrote:
> Hello,
>
> Changes from V1:
> Corrected Commit Message.
>
> Configure script previously accepted unsupported --with-long-double-64
> option without any warning, leading to confusion. This option wa
Support the btf_decl_tag and btf_type_tag attributes in BTF by creating
and emitting BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records,
respectively, for them.
Some care is required when -gprune-btf is in effect to avoid emitting
decl or type tags for declarations or types which have been pruned and
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
On Fri, Aug 22, 2025 at 08:53:27AM +0200, Richard Biener wrote:
> Thanks for the write-up. So I wonder whether a more general solution
> would be to detach "hash value" computation and assignment and leave
> that to external tooling that could do better than non-LTO can and
> the compiler working
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
BTF_KIND_TYPE_TAG records.
The new CTF kinds used to represent these annotations, CTF_K_DECL_T
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
[v8: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692443.html
Review status:
- Patch 1,5 have not yet been OK'd.
- Patch 2,3,4 have been OK'd in v6 and unchanged since apart from nits.
- Patch 6 adds two small BPF-specific tests that I'll count as obvious
without further review unle
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with attribute handlers for them. These attributes may be
used to annotate types or declarations respectively with arbitrary
strings, which will be recorded in DWARF and/or BTF information.
Both attributes accept exactly one
This patch adds missing guards on shift amounts to prevent UB when the
shift count equals or exceeds HOST_BITS_PER_WIDE_INT.
In the patch (r16-2666-g647bd0a02789f1), shift counts were only checked
for nonzero but not for being within valid bounds. This patch tightens
those conditions by enforcing
On Fri, Aug 22, 2025 at 03:11:16PM +, Qing Zhao wrote:
> > On Aug 21, 2025, at 17:29, Kees Cook wrote:
> > For non-static functions, we cannot know if other compilation units may
> > make indirect calls to a given function, so those functions must always
> > have their kcfi preamble added. For
On Fri, 22 Aug 2025, Yrong wrote:
> friendly ping~
>
> Yrong 于2025年8月19日周二 23:58写道：
> Thanks for the review! But I don't have a commit access, could you help
> me to commit this patch? Many thanks!
The patch will be pushed by one of us one it's approved by Jonathan
or another maintainer.
On 8/21/25 1:33 AM, John Ericson wrote:
From: John Ericson
This time use no classes, virtual methods. Just use higher order
functions using templates.
Now it's even shorter than before --- which is also shorter than the
no-lambda, pure OOP original --- but at the cost of some overkill
template
On 8/21/25 1:01 AM, John Ericson wrote:
A follow-up from "driver: Rework for_each_path using C++"
These types are, for all intents and purposes, single-use closure
environment types. It is much more ergonomic to juse use lambdas for
this.
On IRC there was concern about static dispatch and compi
From: Andi Kleen
[v3 version: Remove unnecessary _mask pattern.
Add extra FAIL case. Remove unnecessary AVX512F check.
Fix changelog.]
[v2 version: Split rotate patterns in V16QI and V32/64QI.
Add various AVX512F checks. Remove some unnecessary
masks. Add untested cond_ pattern (untested, couldn
On 8/22/25 2:02 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
In the PR, we're getting a linker error from _Vector_impl's destructor
never getting emitted. This is because of a combination of factors:
1. in imp-member-4_a, the dest
On 8/19/25 4:48 AM, Alfie Richards wrote:
This patch changes the semantics of target_version and target_clones attributes
to match the behavior described in the Arm C Language extension.
The changes to behavior are:
- The scope and signature of an FMV function set is now that of the default
On 8/19/25 4:47 AM, Alfie Richards wrote:
This patch is an overhaul of how FMV name mangling works. Previously
mangling logic was duplicated in several places across both target
specific and independent code. This patch changes this such that all
mangling is done in targetm.mangle_decl_assembler_
> > + else if (TARGET_GFNI && TARGET_AVX512F && CONST_INT_P (operands[2]))
> I don't think we need AVX512F here, and let's exclude >>7 cases here,
> so better be.
> else if (TARGET_GFNI
> && CONST_INT_P (operands[2])
> /* It's just vpcmpgtb against 0. */
> && !
Hi Yuao,
Yuao Ma wrote:
Hi Paul,
On 7/31/2025 6:02 AM, Paul Richard Thomas wrote:
That's exactly how I had a mind to do it. You beat me to it 🙁
Just get on, polish the patch and add more tests.
I've updated the patch with improvements to both the functionality and
test cases. It should now
> On Aug 21, 2025, at 17:29, Kees Cook wrote:
>
> On Thu, Aug 21, 2025 at 07:14:31PM +, Qing Zhao wrote:
>>
>>
>>> On Aug 21, 2025, at 12:16, Kees Cook wrote:
>>>
>>>
> + else if (TREE_CODE (fntype_or_fndecl) == FUNCTION_DECL)
> +{
> + tree fndecl = fntype_or_fnde
Claudiu Zissulescu Ianculescu writes:
> Hi Richard,
>
> On Thu, Aug 21, 2025 at 9:55 AM Richard Sandiford
> wrote:
>>
>> Today is my last working day at Arm, so this patch switches my
>> MAINTAINERS entries to my personal email address. (It turns out
>> that I never updated some of the later ent
friendly ping~
Yrong 于2025年8月19日周二 23:58写道：
> Thanks for the review! But I don't have a commit access, could you help me
> to commit this patch? Many thanks!
>
> > Perhaps we want to backport this, not sure how far back
>
> Is there anything I need to do about this?
>
> Best regards,
> Yihan
>
Claudiu Zissulescu-Ianculescu writes:
> Hi,
>
>>> +DEFHOOK
>>> +(compose_offset_tag,
>>> + "Return an RTX that represnts the result of composing
>>> @var{tag_offset} with\n\
>>> +the base tag @var{base_tag}.\n\
>>> +The default of this hook is to byte add @var{tag_offset} to
>>> @var{base_tag}.",
claudiu.zissulescu-iancule...@oracle.com writes:
> diff --git a/gcc/testsuite/gcc.target/aarch64/memtag/basic-1.c
> b/gcc/testsuite/gcc.target/aarch64/memtag/basic-1.c
> new file mode 100644
> index 000..70b790c6c3e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/memtag/basic-1.c
Hi,
>> +DEFHOOK
>> +(compose_offset_tag,
>> + "Return an RTX that represnts the result of composing @var{tag_offset}
>> with\n\
>> +the base tag @var{base_tag}.\n\
>> +The default of this hook is to byte add @var{tag_offset} to
>> @var{base_tag}.",
>> + rtx, (rtx base_tag, uint8_t tag_offset),
On Fri, Aug 22, 2025 at 03:43:48PM +0530, Surya Kumari Jangala wrote:
> On 01/08/25 4:48 am, Kishan Parmar wrote:
> > This patch adds missing guards on shift amounts to prevent UB when the
> > shift count equals or exceeds HOST_BITS_PER_WIDE_INT.
> >
> > Although the main undefined behavior issues
claudiu.zissulescu-iancule...@oracle.com writes:
> From: Claudiu Zissulescu
>
> Memory tagging is used for detecting memory safety bugs. On AArch64, the
> memory tagging extension (MTE) helps in reducing the overheads of memory
> tagging:
> - CPU: MTE instructions for efficiently tagging and unt
On 8/19/25 12:59 AM, Richard Biener wrote:
Apart from a missing ChangeLog this LGTM. I would expect this to also
trigger on x86, so I wonder what effect the patch has there on the
testcases you add for riscv?
Fair question. While I'd looked at other targets, particularly those
with inter
On Fri, 22 Aug 2025 at 16:41, Jonathan Wakely wrote:
>> It marks tai_clock and gps_clock "is_steady = true", as they
>> are not subject to adjudicated discontinuities, unlike civil
>> time with annual spring and fall changes, and UTC with
>
>
> Please revert this part. is_steady has nothing to do
So the current pass order is:
```
NEXT_PASS (pass_tail_recursion);
NEXT_PASS (pass_if_to_switch);
NEXT_PASS (pass_convert_switch);
NEXT_PASS (pass_cleanup_eh);
```
But nothing in if_to_switch nor convert_switch will change the IR
such that cleanup eh will tak
claudiu.zissulescu-iancule...@oracle.com writes:
> From: Claudiu Zissulescu
>
> Add a new target hook TARGET_MEMTAG_COMPOSE_OFFSET_TAG to perform
> addition between two tags.
>
> The default of this hook is to byte add the inputs.
>
> Hardware-assisted sanitizers on architectures providing instruc
We passed the reduc_info which is close, but the representative is
more spot on and will not collide with making the reduc_info a
distinct type.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-loop.cc (vectorizable_live_operation): Pass
the representative
claudiu.zissulescu-iancule...@oracle.com writes:
> From: Indu Bhagat
>
> Add new command line option -fsanitize=memtag-stack with the following
> new params:
> --param memtag-instrument-alloca [0,1] (default 1) to use MTE insns
> for enabling dynamic checking of stack allocas.
>
> Along with the n
STMT_VINFO_REDUC_VECTYPE_IN exists on relevant reduction stmts, not
the reduction info. And STMT_VINFO_DEF_TYPE exists on the
reduction info. The following fixes up a few places.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-loop.cc (vectorizable_lane_reducing
On Fri, 22 Aug 2025, 04:26 Nathan Myers, wrote:
> This moves std::tai_clock::now() and std::tai_clock::now()
> definitions from header inlines to static members invoked via a
> normal function call, in service of stabilizing the C++20 ABI.
>
> It marks tai_clock and gps_clock "is_steady = true",
claudiu.zissulescu-iancule...@oracle.com writes:
> From: Indu Bhagat
>
> gcc/Changelog:
>
> * asan.h (HWASAN_TAG_SIZE): Use targetm.memtag.tag_bitsize.
> * config/i386/i386.cc (ix86_memtag_tag_size): Rename to
> ix86_memtag_tag_bitsize.
> (TARGET_MEMTAG_TAG_SIZE): Renamed t
> -Original Message-
> From: H.J. Lu
> Sent: Friday, August 22, 2025 8:57 PM
> To: gcc-patches@gcc.gnu.org
> Cc: ubiz...@gmail.com; Liu, Hongtao ;
> sly...@gcc.gnu.org
> Subject: [PATCH] Emit the TLS call after NOTE_INSN_FUNCTION_BEG
>
> For the beginning basic block:
>
> (note 4 0 2
REDUC_GROUP_FIRST_ELEMENT is often checked to see whether we are
dealing with a SLP reduction or a reduction chain. When we are
in the context of analyzing the reduction (so we are sure
the SLP instance we see is correct), then we can use the SLP
instance kind instead.
Bootstrapped and tested on
For the beginning basic block:
(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 4 26 2 NOTE_INSN_FUNCTION_BEG)
emit the TLS call after NOTE_INSN_FUNCTION_BEG.
gcc/
PR target/121635
* config/i386/i386-features.cc (ix86_emit_tls_call): Emit the
TLS call after NOTE_INSN_
Tested on x86_64-pc-linux-gnu (with and without
--target_board=unix/-fshort-enums), committing as obvious.
-- >8 --
Linaro CI informed me that this test fails on ARM thumb-m7-hard-eabi.
This appears to be because the target defaults to -fshort-enums, and so
the mangled names are inaccurate.
This
The following removes the use of STMT_VINFO_REDUC_* from parloops,
also fixing a mistake with analyzing double reductions which rely
on the outer loop vinfo so the inner loop is properly detected as
nested.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-parloops.cc (p
Hi Kishan,
On 01/08/25 4:48 am, Kishan Parmar wrote:
> Hello,
>
> This patch adds missing guards on shift amounts to prevent UB when the
> shift count equals or exceeds HOST_BITS_PER_WIDE_INT.
>
> Although the main undefined behavior issues were addressed in a previous
> patch (r16-2666-g647bd0a
On Thu, Aug 21, 2025 at 10:15:31PM -0700, Kees Cook wrote:
> On Thu, Aug 21, 2025 at 06:09:08PM +, Qing Zhao wrote:
> > > On Aug 21, 2025, at 10:25, Peter Zijlstra wrote:
> > > kCFI changes every function to have a preamble like (with IBT and
> > > retpolines and all the modern crap on):
> >
On Fri, Aug 22, 2025 at 01:36:43AM -0700, Kees Cook wrote:
> On Fri, Aug 22, 2025 at 10:19:15AM +0200, Peter Zijlstra wrote:
> > Anyway, I might be able to deal with the indirect call not being r11,
> > but it'll take a bit of prodding. Also it will shatter my plans to move
> > the hash to eax to s
On Fri, Aug 22, 2025 at 10:24:20AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 22, 2025 at 09:51:15AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 21, 2025 at 02:22:30AM -0700, Andrew Pinski wrote:
> > > On Thu, Aug 21, 2025, 2:13 AM Peter Zijlstra wrote:
> > >
> > > > On Thu, Aug 21, 2025 at 01:1
On Fri, Aug 22, 2025 at 10:19:15AM +0200, Peter Zijlstra wrote:
> Anyway, I might be able to deal with the indirect call not being r11,
> but it'll take a bit of prodding. Also it will shatter my plans to move
> the hash to eax to save a few bytes in instruction encoding. Let me go
> poke around wi
On Fri, Aug 22, 2025 at 09:51:15AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 21, 2025 at 02:22:30AM -0700, Andrew Pinski wrote:
> > On Thu, Aug 21, 2025, 2:13 AM Peter Zijlstra wrote:
> >
> > > On Thu, Aug 21, 2025 at 01:16:56AM -0700, Andrew Pinski wrote:
> > >
> > > > > +/* Compute KCFI type I
On Thu, Aug 21, 2025 at 11:46:17AM -0700, Kees Cook wrote:
> On Thu, Aug 21, 2025 at 11:29:35AM +0200, Peter Zijlstra wrote:
> > The current kernel FineIBT code hard assumes r11 for now.
>
> Oh, it looked like it wasn't always r11. Does clang force the call
> register to be r11?
Yes. I'm not sur
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
Changes from v1:
- Use { xfail } in { dg-final } instead of { dg-xfail-if }, because it's
the thread simulation test that we know to fail with current GDB, not
the compile test.
Xi Ruoyao (3):
LoongArch: Fix the semantic of
Enable those tests so we won't make too stupid mistakes in 16B atomic
implementation anymore.
All these test passed on a Loongson 3C6000/S except
atomic-other-int128.c. With GDB patched to support sc.q
(https://sourceware.org/pipermail/gdb-patches/2025-August/220034.html)
this test also XPASS.
g
In a CAS operation, even if expected != *memory we still need to do an
atomic load of *memory into output. But I made a mistake in the initial
implementation, causing the output to contain junk in this situation.
Like a normal atomic load, the atomic load embedded in the CAS semantic
is required
Fix the ICE:
../gcc/gcc/testsuite/gcc.dg/atomic-compare-exchange-5.c:88:1: internal compiler
error: output_operand: invalid use of '%t'
88 | }
| ^
The ICE is because we have an incorrect condition
"GET_MODE (op) != TImode": we may use (const_int 0) here but it is in
VOIDmode.
Use reg_o
On Thu, Aug 21, 2025 at 02:22:30AM -0700, Andrew Pinski wrote:
> On Thu, Aug 21, 2025, 2:13 AM Peter Zijlstra wrote:
>
> > On Thu, Aug 21, 2025 at 01:16:56AM -0700, Andrew Pinski wrote:
> >
> > > > +/* Compute KCFI type ID for a function declaration or function type
> > > > (internal) */
> > > >
From: "Cui, Lili"
Hi,
This patch aims to remove issue code in improve_allocation that was causing
expensive allocno overflows.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Thanks,
Lili.
The original intention of this code was to allow more allocnos
to share the same reg
On Thu, 21 Aug 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, August 21, 2025 1:17 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; rdsandif...@googlemail.com; nd
> > Subject: RE: [PATCH 1/5]middle-end: Add scaffolding to supp
71 matches
Mail list logo
