On Thu, Aug 7, 2025 at 4:42 PM Gerald Pfeifer wrote:
>
> On Thu, 7 Aug 2025, Richard Biener wrote:
> > On Wed, Aug 6, 2025 at 9:19 PM Gerald Pfeifer wrote:
> >> In addition to gzip format our snapshots and releases have been using
> >> xz instead of bzip2 for a while.
> > Note download_prerequesi
* Gerald Pfeifer:
> diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
> index 52b10f33..48aeb9bd 100644
> --- a/htdocs/projects/cxx-status.html
> +++ b/htdocs/projects/cxx-status.html
> @@ -731,9 +731,6 @@
>extensions in addition to C++20 features,
> add -
On Fri, Aug 8, 2025 at 6:26 AM H.J. Lu wrote:
>
> When GNU binutils is configured with --enable-targets=all on Linux,
> "ld -V" will report both elf_x86_64_sol2 and elf_i386_sol2 as supported
> emulations. But they should only be used for Solaris 2 targets. Check
> for Solaris 2 targets before u
When GNU binutils is configured with --enable-targets=all on Linux,
"ld -V" will report both elf_x86_64_sol2 and elf_i386_sol2 as supported
emulations. But they should only be used for Solaris 2 targets. Check
for Solaris 2 targets before using sol2 linker emulations.
PR target/121457
PR 120618
gcc/cp/ChangeLog:
* constraint.cc (tsubst_compound_requirement): Return NULL_TREE when t1
is not a TEMPLATE_TYPE_PARM
(tsubst_requires_expr): Propagate failure when the compound
requirement has an ill-formed type-constraint
gcc/testsuite/ChangeLog:
On Thu, Aug 7, 2025, at 3:21 PM, Joseph Myers wrote:
> On Thu, 7 Aug 2025, John Ericson wrote:
>
> > I think upon further reflection, I have a slightly different read of
> > what's going on.
> >
> > See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html /
> > https://www.airs.com/ian/
On Thu, Aug 7, 2025 at 7:58 PM Andrew Pinski wrote:
>
> Now there are mergeable sections which have an entity size, we can place
> decls (constants) that are smaller in size in these sections.
> An example is an `long double` which has a size of 12 bytes on i686 and is
> placed in the 16 bytes sha
We increased the switch conversion array decl alignment
for better mergeability but it turns out that we increase
the alignment on targets which don't support mergeable sections
(e.g. NVPTX). Also after the fix for PR 121394, it becomes
obvious that we can place any sized into the mergeable section
Now there are mergeable sections which have an entity size, we can place
decls (constants) that are smaller in size in these sections.
An example is an `long double` which has a size of 12 bytes on i686 and is
placed in the 16 bytes shareable section.
For an example with the following C++ code:
``
Restrict the immediate range to the intersection of LT/GE and GT/LE
so that cfglayout can invert the condition to redirect any branch.
gcc:
* config/aarch64/aarch64.cc (aarch64_cb_rhs): Restrict the
range of LT/GE and GT/LE to their intersections.
* config/aarch64/aarch64.m
gcc:
* config/aarch64/aarch64.cc (aarch64_if_then_else_costs):
Use aarch64_cb_rhs to match CB insns.
---
gcc/config/aarch64/aarch64.cc | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 650da2ff95d..e7b17
The enable for the test was wrong, so it never ran.
gcc/testsuite:
* gcc.target/aarch64/cmpbr.c: Use dg-require-effective-target.
---
gcc/testsuite/gcc.target/aarch64/cmpbr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/cmpbr.c
b/gc
Two of the three uses of aarch64_imm24 included the important follow-up
tests vs aarch64_move_imm and aarch64_plus_operand. Lack of the exclusion
within aarch64_if_then_else_costs produced incorrect costing.
Since aarch64_split_imm24 has already matched a non-negative CONST_INT,
drill down from a
There is a conflict between aarch64_tbzltdi1 and aarch64_cbltdi
with respect to pnum_clobbers, resulting in a recog failure:
0xa1fffe fancy_abort(char const*, int, char const*)
../../gcc/diagnostics/context.cc:1640
0x81340e patch_jump_insn
../../gcc/cfgrtl.cc:1303
0xc0eafe redirect
gcc:
* config/aarch64/aarch64.cc (aarch64_if_then_else_costs): Remove
else after return and re-indent.
---
gcc/config/aarch64/aarch64.cc | 52 +--
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/con
The save/restore_stack_nonlocal patterns passed a DImode rtx
to gen_tbranch_neqi3 for a QImode compare. The tbranch expander
did not do what it said on the tin, that is: emit TBNZ.
It only made it as far as AND+CMP+B.cond.
But since we're seeding r16 with 1, GCSEnabled will clear the
only set bit
gcc:
* config/aarch64/aarch64.cc (aarch64_if_the_else_costs): Reorg to
include the cost of inner within TBZ sign-bit test, only match
CBZ/CBNZ with valid modes, and both for the aarch64_imm24 test.
---
gcc/config/aarch64/aarch64.cc | 55 ---
With -mtrack-speculation, the pattern that was directly expanded by
aarch64_restore_za is disabled. Use the helper function instead.
gcc:
* config/aarch64/aarch64.cc
(aarch64_gen_compare_zero_and_branch): Export.
* config/aarch64/aarch64-protos.h
(aarch64_gen_compa
Reject QI/HImode conditions, which would require extension in
order to compare. Fixes
z.c:10:1: error: unrecognizable insn:
10 | }
| ^
(insn 23 22 24 2 (set (reg:CC 66 cc)
(compare:CC (reg:HI 128)
(reg:HI 127))) "z.c":6:6 -1
(nil))
during RTL pass: vregs
gcc:
Both patterns used !reload_completed as a condition, which is
questionable at best. The branch pattern failed to include a
clobber of CC_REGNUM. Both problems were unlikely to trigger
in practice, due to how the optimization pipeline is organized,
but let's fix them anyway.
gcc:
* config
Version 1 regressed the expansion of atomics, which means the addition
of CC clobber to all conditional branches is flawed. Version 2 goes
the other way: remove CC clobber from all conditional branches.
This requires the out-of-range TBZ->TST+B.cond expansion be removed,
falling back to the far_b
With -mtrack-speculation, CC_REGNUM must be used at every
conditional branch.
gcc:
* config/aarch64/aarch64.h (TARGET_CMPBR): False when
aarch64_track_speculation is true.
---
gcc/config/aarch64/aarch64.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc
One kilobyte not one kilobit.
gcc:
* config/aarch64/aarch64.md (BRANCH_LEN_N_1KiB): Rename
from BRANCH_LEN_N_1Kib.
---
gcc/config/aarch64/aarch64.md | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/confi
Subject: [PATCH] cobol: Improve binary-to-string conversion.
COBOL often requires the conversion of binary integers to string of
characters.
These changes replace a naive routine that peels decimal digits from a
binary
value one digit at a time, with a divide-and-conquer algorithm that is
twice as
References to literal pool entries do not need to be reloaded or converted
to "(mem (reg X))" to load via base register.
gcc/ChangeLog:
* config/xtensa/constraints.md (T):
Change define_memory_constraint to define_special_memory_constraint.
---
gcc/config/xtensa/constraints.md |
On 8/7/25 23:35, Karl Meakin wrote:
I have updated the tests in `cmpbr.c` to reflect the fixes. There are a
few regressions, but they can be fixed later; let's just make GCC
crash-free first.
I should have replied sooner. The patch set breaks atomics.
I am re-working it not to do so and will
It's still experimental.
On Thu, 7 Aug 2025, 18:16 Gerald Pfeifer, wrote:
> Looking at projects/cxx-status.html I noticed we state
>
>Important: Because the ISO C++20 standard is recent, GCC's support
>is *experimental*.
>
> Do we still need/want this, or shall we drop it per the patch b
On Fri, 1 Aug 2025, Qing Zhao wrote:
> Currently, we generate a call to a .ACCESS_WITH_SIZE for a FAM with counted_by
> attribute for every component_ref that corresponds to such an object.
> Actually, such .ACCESS_WITH_SIZE calls are useless when they are generated
> for a written site or an addr
Pinging. Going twice
-Original Message-
From: Robert Dubner
Sent: Thursday, July 31, 2025 08:11
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] real: Eliminate access to uninitialized memory.
I have been running all of my extensive tests through valgrind and picking
off errors, one by
Hi Jerry et al.,
I attached an earlier version of the patch - apologies!
Please find the latest attached.
Paul
On Thu, 7 Aug 2025 at 17:07, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Jerry, Steve and co.,
>
> Thanks for the reviews.
>
> I have made extensive changes to t
On Thu, Aug 7, 2025 at 4:55 AM Wilco Dijkstra wrote:
>
>
> Add an optab for isnan. This requires changes to the existing folding code
> to extend the interclass_mathfn infrastructure to support BUILT_IN_ISNAN.
> It now checks for a valid optab before emitting the generic expansion.
> There is no
On Fri, 1 Aug 2025, Qing Zhao wrote:
> gcc/c-family/ChangeLog:
>
> * c-attribs.cc (handle_counted_by_attribute): Accept counted_by
> attribute for pointer fields.
>
> gcc/c/ChangeLog:
>
> * c-decl.cc (verify_counted_by_attribute): Change the 2nd argument
> to a vector of
On Thu, 7 Aug 2025, David Faust wrote:
> Changes from v6:
> - Patch 1: Check for and reject wide string arguments in the attribute
>handlers. Factor common argument checking shared by both attribute
>handlers to a small helper.
I think there should be testcases for this error (with L",
Hi!
I've realized I haven't added testsuite coverage for name independent
structured binding packs. And the
auto [i, ..._, j] = T {};
auto [k, ..._, l] = T {};
case shows a problem with that. The elements of the structured binding
pack have #i appended to their names, so for the _ case e.g.
Hi Pengfei,
> On 7 Aug 2025, at 18:45, Pengfei Li wrote:
>
> This patch fixes incorrect constraints in RTL patterns for AArch64 SVE
> gather/scatter with type widening/narrowing and vector-plus-immediate
> addressing. The bug leads to below "immediate offset out of range"
> errors during assembl
On Thu, 7 Aug 2025 at 20:59, Mike Stump wrote:
>
> On Aug 7, 2025, at 9:15 AM, Gerald Pfeifer wrote:
> >
> > Looking at projects/cxx-status.html I noticed we state
> >
> > Important: Because the ISO C++20 standard is recent, GCC's support
> > is *experimental*.
> >
> > Do we still need/want t
On Thu, 7 Aug 2025, John Ericson wrote:
> I think upon further reflection, I have a slightly different read of
> what's going on.
>
> See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html /
> https://www.airs.com/ian/configure/configure_8.html (rendering of
> since-deleted from the
Ping!
please review.
Thanks & Regards
Jeevitha
On 02/07/25 11:50 am, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> Changes from V3:
> * Replaced named operands with positional operands in inline assembly for
> better readabili
On Jul 17, 2025, at 5:48 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk, gcc-15 and gcc-14?
Ok.
> gcc/testsuite/ChangeLog:
>
> * lib/multiline.exp: Added pruning of .exe.
On Thu, 7 Aug 2025 at 21:07, Ville Voutilainen
wrote:
>
> On Thu, 7 Aug 2025 at 20:59, Mike Stump wrote:
> >
> > On Aug 7, 2025, at 9:15 AM, Gerald Pfeifer wrote:
> > >
> > > Looking at projects/cxx-status.html I noticed we state
> > >
> > > Important: Because the ISO C++20 standard is recent,
On Thu, Aug 07, 2025 at 10:57:49AM -0700, Mike Stump wrote:
> On Aug 7, 2025, at 9:15 AM, Gerald Pfeifer wrote:
> >
> > Looking at projects/cxx-status.html I noticed we state
> >
> > Important: Because the ISO C++20 standard is recent, GCC's support
> > is *experimental*.
> >
> > Do we sti
On Thu, Aug 7, 2025 at 12:00 AM Richard Biener
wrote:
>
> On Thu, Aug 7, 2025 at 8:37 AM Andrew Pinski wrote:
> >
> > Like r0-46282-gf41115930523b3, but this time for normal variables
> > rather than the constant pool.
> > With the simple C++ code on ia32:
> > ```
> > std::initializer_list a = {0
On Aug 7, 2025, at 9:15 AM, Gerald Pfeifer wrote:
>
> Looking at projects/cxx-status.html I noticed we state
>
> Important: Because the ISO C++20 standard is recent, GCC's support
> is *experimental*.
>
> Do we still need/want this, or shall we drop it per the patch below?
Drop it. Featur
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
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
[v6: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690141.html
Review Status:
- Patch 1,5 are changed based on v6 reviews.
- Patch 2,3 have been OK'd in v6 and are unchanged in v7.
- Patch 4 was OK'd in v6, small changes for 2 nits pointed out by Indu.
- Patch 6 adds two small BPF-specif
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 ++
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.
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
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with attribute handlers for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_decl_tag_attribute): New handler for btf_decl_tag.
This patch fixes incorrect constraints in RTL patterns for AArch64 SVE
gather/scatter with type widening/narrowing and vector-plus-immediate
addressing. The bug leads to below "immediate offset out of range"
errors during assembly, eventually causing compilation failures.
/tmp/ccsVqBp1.s: Assemble
> There are too many cases to enumerate... Compilers try hard to use all
> available registers and instructions - that's what they are supposed
> to do!
It sounds like I'd need a far broader change to ensure a 64-bit CPU
could guarantee support for nested interrupts with the low-latency that
savi
Looking at projects/cxx-status.html I noticed we state
Important: Because the ISO C++20 standard is recent, GCC's support
is *experimental*.
Do we still need/want this, or shall we drop it per the patch below?
Gerald
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-sta
Hi Jerry, Steve and co.,
Thanks for the reviews.
I have made extensive changes to this patch. Relative to the original
submission, the changes are:
(i) Cleaned up the comments in decl.cc. 'binding' removed from generic
statement comments;
(ii) 'generic_spec_name' used for formatted name instead o
Hi Richard,
On Thu, 2025-08-07 at 13:56 +0200, Richard Biener wrote:
> The following handles value-numbering of a BIT_FIELD_REF of
> a register that's defined by a load by looking up a subset
> load similar to how we handle bit-and masked loads. This
> allows the testcase to be simplified by two
The entire domain appears to be gone.
---
htdocs/news.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/news.html b/htdocs/news.html
index e41a5e25..bfae071e 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -247,7 +247,7 @@
enabling HSAIL finalization for
libstdc++-v3:
* doc/xml/manual/build_hacking.xml: Switch gcc.gnu.org installation
docs to https.
* doc/html/manual/appendix_porting.html: Regenerate.
---
libstdc++-v3/doc/html/manual/appendix_porting.html | 2 +-
libstdc++-v3/doc/xml/manual/build_hacking.xml | 2 +-
Interesting turns of history...
Pushed.
Gerald
---
htdocs/readings.html | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 251011e0..a27d7d22 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -370,9 +370,9 @@
On Wed, Aug 06, 2025 at 11:53:55AM -0700, Jason Merrill wrote:
> > And one thing still unresolved is debug info, I've just added DECL_IGNORED_P
> > on the structured binding pack VAR_DECL because there were ICEs with -g
> > for now, hope it can be fixed incrementally but am not sure what exactly
>
Hi Tobias,
On 8/7/2025 8:59 PM, Tobias Burnus wrote:
Yuao Ma wrote:
Given the "Fortran 2023:" prefix, I wonder whether the wording shouldn't
be tweaked:
+ call c_f_pointer(x, ptr_2d, shape=myshape_2d, lower=mylower_2d) !
{ dg-error "Fortran 2023: Unexpected LOWER argument at" }
It reads
Hi!
My C++26 P2686R4 PR117784 caused ICE on the following testcase.
While the earlier conditions guarantee decl2 is not error_mark_node,
decl can be (that is used when something erroneous has been seen earlier
and the whole structured bindings will be ignored after parsing).
So, the following pat
Hi!
My earlier r16-1886 PR120608 change incorrectly assumed that the
finally_tmp.N vars introduced by eh pass will be only initialized
to values 0 and 1 and there will be only EQ_EXPR/NE_EXPR comparisons
of those.
The following testcases show that is a bad assumption, the eh pass
sets finally_tmp
writes:
> From: Alfie Richards
>
> This patch introduces the TARGET_CHECK_TARGET_CLONE_VERSION hook
> which is used to determine if a target_clones version string parses.
>
> The hook has a flag to enable emitting diagnostics.
>
> This is as specified in the Arm C Language Extension. The purpose
On Thu, 7 Aug 2025, Richard Biener wrote:
> On Wed, Aug 6, 2025 at 9:19 PM Gerald Pfeifer wrote:
>> In addition to gzip format our snapshots and releases have been using
>> xz instead of bzip2 for a while.
> Note download_prerequesites pulls .bz2 tarballs.
Hmm, how do we best go about that?
I ha
Hi Keith,
Thanks for the explanation - however I'm afraid compilers don't have a concept
of implicit vs explicit use of operations or registers.
> I'm trying to find all cases where that happens for data types other
> than SIMD/FP. Do you know of other places where the compiler implicitly
> uses
On Thu, Aug 7, 2025 at 2:14 PM Richard Sandiford
wrote:
>
> simplify_gen_subreg rejected subregs of literal constants if
> MODE_COMPOSITE_P. This was added by the fix for PR96648 in
> g:c0f772894b6b3cd8ed5c5dd09d0c7917f51cf70f. Jakub said:
>
> As for the simplify_gen_subreg change, I think it
Hi Richard,
> Unlike base PCS functions, __arm_streaming and __arm_streaming_compatible
> functions allow/require PSTATE.SM to be 1 on entry, so they need to
> be treated as STO_AARCH64_VARIANT_PCS.
>
> Similarly, functions that share ZA or ZT0 with their callers require
> ZA to be active on entry
I have updated the tests in `cmpbr.c` to reflect the fixes. There are a
few regressions, but they can be fixed later; let's just make GCC
crash-free first.
---
gcc/testsuite/gcc.target/aarch64/cmpbr.c | 334 +--
1 file changed, 185 insertions(+), 149 deletions(-)
diff --git a
I pushed this for 15 as well, the only thing excluded is a typo fix in
a block that does not exist in 15.
Alex
On Thu, Jun 19, 2025 at 1:59 AM Tobias Burnus wrote:
>
> The attached patch does some cleanup to the memory allocation
> description, which I mainly started as I wondered myself about s
On 01/08/2025 13:27, Richard Biener wrote:
On Thu, Jul 31, 2025 at 11:44 AM Richard Biener
wrote:
On Mon, May 19, 2025 at 6:38 PM Richard Earnshaw wrote:
It's not enough to just check that a memory operand is of the form
mem(reg); after RA we also need to validate the register being used.
T
Yuao Ma wrote:
On 8/6/2025 10:57 PM, Yuao Ma wrote:
On 8/6/2025 4:32 PM, Tobias Burnus wrote:
Hi Yuao,
thanks for your patch. I have two nits:
* There is no diagnostic for -std=f2018 (or lower);
can you add the 'gfc_notify_std (GFC_STD_F2023' ?
Done. Testcase added.
Given the "Fortran
This one was forgotten. Also constants/externals are costed explicitly
with SLP.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vect-stmts.cc (vect_model_promotion_demotion_cost): Pass
in SLP node and drop unused dr argument. Use SLP node for
costin
The following avoids STMT_VINFO_VECTYPE usage in
vect_is_emulated_mixed_dot_prod and makes sure to register the SLP
node when costing in vectorizable_lane_reducing.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
* tree-vect-loop.cc (vect_is_emulated_mixed_dot_prod): Get
It was applied on the stmt_info rather than the slp_node.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vect-stmts.cc (vectorizable_store): Apply SLP_TREE_VECTYPE
to slp_node rather than stmt_info.
---
gcc/tree-vect-stmts.cc | 2 +-
1 file changed, 1 insertion
writes:
> From: Alfie Richards
>
> 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_n
writes:
> From: Alfie Richards
>
> This is similar to clone_function_name and its siblings but takes an
> identifier tree node rather than a function declaration.
>
> This is to be used in conjunction with the identifier node stored in
> cgraph_function_version_info::assembler_name to mangle FMV
Unlike base PCS functions, __arm_streaming and __arm_streaming_compatible
functions allow/require PSTATE.SM to be 1 on entry, so they need to
be treated as STO_AARCH64_VARIANT_PCS.
Similarly, functions that share ZA or ZT0 with their callers require
ZA to be active on entry, whereas the base PCS r
simplify_gen_subreg rejected subregs of literal constants if
MODE_COMPOSITE_P. This was added by the fix for PR96648 in
g:c0f772894b6b3cd8ed5c5dd09d0c7917f51cf70f. Jakub said:
As for the simplify_gen_subreg change, I think it would be desirable
to just avoid creating SUBREGs of constants on
The following handles value-numbering of a BIT_FIELD_REF of
a register that's defined by a load by looking up a subset
load similar to how we handle bit-and masked loads. This
allows the testcase to be simplified by two FRE passes,
the first one will create the BIT_FIELD_REF.
Bootstrapped and tes
Add an optab for isnan. This requires changes to the existing folding code
to extend the interclass_mathfn infrastructure to support BUILT_IN_ISNAN.
It now checks for a valid optab before emitting the generic expansion.
There is no change if no optab is defined. Update documentation, including
t
On Wed, Aug 6, 2025 at 7:34 PM Andrew Pinski wrote:
>
> This implements the simple copy prop of aggregates into
> arguments of function calls. This can reduce the number of copies
> done. Just like removing of an extra copy in general, this can and
> will help out SRA; since we might not need to d
On Wed, Aug 6, 2025 at 7:30 PM Andrew Pinski wrote:
>
> While looking into the gimple level after optimization of the highway code
> from google, I noticed in .optimized we still have:
> ```
> MEM [(short int *)&a] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> D.4398 = a;
> a ={v} {CLOBBER(eos)};
> D.4
Uros Bizjak writes:
> On Tue, Aug 5, 2025 at 1:32 PM Richard Sandiford
> wrote:
>> It's coming from:
>>
>> (define_split
>> [(set (match_operand:SWI 0 "register_operand")
>> (any_rotate:SWI
>> (match_operand:SWI 1 "const_int_operand")
>> (subreg:QI
>> (an
On Wed, Aug 6, 2025 at 7:30 PM Andrew Pinski wrote:
>
> In the testcase provided, currently we lose the landing pad for the exception
> that could
> throw from the aggregate load as we remove one copy and the second statement
> where load
> happens was not marked as throwable before so the landi
On Thu, Aug 7, 2025 at 1:22 PM Richard Biener
wrote:
>
> On Wed, Aug 6, 2025 at 7:29 PM Andrew Pinski wrote:
> >
> > One thing I noticed while working on copy prop for aggregates is that we
> > start with
> > a memcpy like statement and then walk backwards. This means we could have a
> > few wa
On Wed, Aug 6, 2025 at 7:29 PM Andrew Pinski wrote:
>
> One thing I noticed while working on copy prop for aggregates is that we
> start with
> a memcpy like statement and then walk backwards. This means we could have a
> few walks
> backwards to see there was no statement for zeroing. Instead t
On Wed, Aug 6, 2025 at 7:29 PM Andrew Pinski wrote:
>
> While thinking about how to implement the rest of the copy prop and makes
> sure not
> to introduce some compile time problems, optimize_agr_copyprop should be
> changed
> into a forwproping rather than looking backwards.
>
> Bootstrapped a
The following removes early setting of STMT_VINFO_VECTYPE and as
side-effect early failing if we fail to compute a vector type. The
latter is now ensured by SLP build. The former is still temporarily
copied from the SLP tree during stmt analysis, and data reference
stmts will still have STMT_VINF
ChangeLog:
* MAINTAINERS: Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6148ce069cb..bc607cb50f8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -628,6 +628,7 @@ James Lemke jwlemke
Ilya Leoshke
On 06/08/2025 12:47, Richard Henderson wrote:
On 8/6/25 00:45, Karl Meakin wrote:
Now that the body of `cbranch` and `cbranch` are the
same, could we merge them into one rule?
No, the bodies are the same but the predicates are not.
r~
Good point, I missed that
On 2025-08-04 12:33, Jan Beulich wrote:
On 04.08.2025 12:42, Matthieu Longo wrote:
On 2025-08-04 11:33, Richard Sandiford wrote:
Matthieu Longo writes:
On 2025-07-31 13:39, Jan Beulich wrote:
On 09.07.2025 14:48, Matthieu Longo wrote:
Those methods's implementation is relying on duck-typing
Committed as r16-3063-gb399a0084bc962 fix the file name in
download_prerequisites fixed.
And ...
Richard Biener wrote:
On Wed, 6 Aug 2025, Tobias Burnus wrote:
OK for mainline? (Requires a prior update of 'infrastructure').
-gmp='gmp-6.2.1.tar.bz2'
…
+gmp='gmp-6.3.0.tar.xz'
…
+++ b/contr
Ping patch:
| Date: Wed, 23 Jul 2025 15:17:41 -0400
| Subject: [PATCH, V4] Add -mcpu=future to the PowerPC
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690398.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On Wed, Aug 6, 2025 at 9:19 PM Gerald Pfeifer wrote:
>
> In addition to gzip format our snapshots and releases have been using
> xz instead of bzip2 for a while.
Note download_prerequesites pulls .bz2 tarballs.
>
> gcc:
> PR target/69374
> * doc/install.texi (Prerequisites): Repl
94 matches
Mail list logo
