On Apr 15, 2025, Peter Bergner wrote:
> On 4/14/25 11:35 PM, Alexandre Oliva wrote:
>>> That said, that should be done in a separate patch.
>>
>> *nod*. Do you mean you're going to make that change, that I should, or
>> that you hope someone else will? I'd rather avoid duplication, and this
>>
On Tue, 15 Apr 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Sandiford
> > Sent: Tuesday, April 15, 2025 10:52 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
> > Subject: Re: [PATCH]middle-end: Fix incorrect codegen with PFA and
On Tue, 15 Apr 2025, Jakub Jelinek wrote:
> Hi!
>
> Calls with musttail attribute don't really work with -fsanitize=thread in
> GCC. The problem is that TSan instrumentation adds
> __tsan_func_entry (__builtin_return_address (0));
> calls at the start of each instrumented function and
> __ts
On Tue, 15 Apr 2025, Jakub Jelinek wrote:
> On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
> > This patch just introduces a form of dumping of widest ints that only
> > have zeros in the lowest 128 bits so that instead of printing
> > thousands of f's the output looks like:
> >
>
On Tue, 15 Apr 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, April 15, 2025 12:50 PM
> > To: Tamar Christina
> > Cc: Richard Sandiford ; gcc-patches@gcc.gnu.org;
> > nd
> > Subject: RE: [PATCH]middle-end: Fix incorrect codegen with PFA a
On 4/14/25 7:44 PM, Kyrylo Tkachov wrote:
Hi Tejas,
On 14 Apr 2025, at 16:04, Tejas Belagod wrote:
The operand order to gen_vcond_mask call in the vec_extract pattern is wrong.
Fix the order where predicate is operand 3.
Tested and bootstrapped on aarch64-linux-gnu. OK for trunk?
gcc/Change
On Tue, 15 Apr 2025, Tamar Christina wrote:
> Hi All,
>
> The following example:
>
> #define N 512
> #define START 2
> #define END 505
>
> int x[N] __attribute__((aligned(32)));
>
> int __attribute__((noipa))
> foo (void)
> {
> for (signed int i = START; i < END; ++i)
> {
> if (x[i
Hi,
On Tue, Apr 15 2025, Jakub Jelinek wrote:
> On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
>> This patch just introduces a form of dumping of widest ints that only
>> have zeros in the lowest 128 bits so that instead of printing
>> thousands of f's the output looks like:
>>
>>
On Tue, 15 Apr 2025 at 09:48, Uros Bizjak wrote:
>
> On Thu, Apr 10, 2025 at 2:27 PM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic that emits mcount() / __fentry__() calls
> > in
On 4/14/25 5:22 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk and later 14?
OK.
-- >8 --
When remapping existing specializations of a hidden template friend from
a previous declaration to the new definition, we must remap only those
s
On Tue, Apr 15, 2025 at 2:35 PM Luc Grosheintz
wrote:
> Thank you! I left two comments. Everything not commented on, I'll just
> incorporate into the next iteration.
> On 4/15/25 11:18 AM, Tomasz Kaminski wrote:
>
>
>
> On Tue, Apr 15, 2025 at 10:43 AM Luc Grosheintz
> wrote:
>
>> This implement
On Tue, Apr 15, 2025 at 12:45 AM Uros Bizjak wrote:
>
> On Tue, Apr 15, 2025 at 1:06 AM H.J. Lu wrote:
> >
> > ix86_add_cfa_restore_note omits the REG_CFA_RESTORE REG note for registers
> > pushed in red-zone. Since
> >
> > commit 0a074b8c7e79f9d9359d044f1499b0a9ce9d2801
> > Author: H.J. Lu
> >
On Tue, Apr 15, 2025 at 01:56:25PM +0200, Richard Biener wrote:
> On Tue, 15 Apr 2025, Jakub Jelinek wrote:
>
> > On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
> > > This patch just introduces a form of dumping of widest ints that only
> > > have zeros in the lowest 128 bits so th
On Tue, 15 Apr 2025, Jakub Jelinek wrote:
> On Tue, Apr 15, 2025 at 01:56:25PM +0200, Richard Biener wrote:
> > On Tue, 15 Apr 2025, Jakub Jelinek wrote:
> >
> > > On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
> > > > This patch just introduces a form of dumping of widest ints th
Thank you! I left two comments. Everything not commented on, I'll just
incorporate into the next iteration.
On 4/15/25 11:18 AM, Tomasz Kaminski wrote:
On Tue, Apr 15, 2025 at 10:43 AM Luc Grosheintz
wrote:
This implements std::extents from according to N4950 and
contains partial
On Tue, Apr 15, 2025 at 02:33:23PM +0200, Richard Biener wrote:
> ISTR at least CCP _prints_ wide_int (or it's tree form), not widest_int
> (but the lattice has widest_int indeed). But CCP knows the precision
> of the lattice entry (which is for an SSA name), possibly IPA CP
> doesn't.
ipcp_bits_
On Tue, Apr 15, 2025 at 02:17:46PM +0200, Martin Jambor wrote:
> Hi,
>
> On Tue, Apr 15 2025, Jakub Jelinek wrote:
> > On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
> >> This patch just introduces a form of dumping of widest ints that only
> >> have zeros in the lowest 128 bits so
On 4/13/25 2:46 AM, Jonathan Yong wrote:
Attached patch OK for master branch?
Will push soon if there are no objections.
Pushed to master branch.
On 4/14/25 11:35 PM, Alexandre Oliva wrote:
>> That said, that should be done in a separate patch.
>
> *nod*. Do you mean you're going to make that change, that I should, or
> that you hope someone else will? I'd rather avoid duplication, and this
> is likely a somewhat involved change, since th
Hello,
On Mon, 14 Apr 2025, Bill Wendling wrote:
> Now, I don't think this will be necessarily confusing to the
> programmer, but it's inconsistent. In other words, either 'counted_by'
> *must* forward declare the in-structure identifier or neither must.
If that's your concern then both should r
Hi,
In my fix for PR 119318 I put mask calculation in
ipcp_bits_lattice::meet_with_1 above a final fix to value so that all
the bits in the value which are meaningless according to mask have
value zero, which has tripped a validator in PR 119803. This patch
fixes that by moving the adjustment dow
Hi,
This patch fixes the ICE in PR119817.
The ImportVisitor method for handling the importing of overload sets was
pushing NULL_TREE to the array of import decls, which in turn got passed
to `debug_hooks->imported_module_or_decl', triggering the observed
internal compiler error.
NULL_TREE is ret
Hi,
This patch fixes the ICE in PR119799.
This was caused by a check in the D front-end disallowing static
VAR_DECLs with a size `0'.
While empty structs in D are given the size `1', the same symbol coming
from ImportC modules do infact have no size, so allow C variables to
pass the check as wel
On Tue, Apr 15, 2025 at 03:14:49PM +0200, Martin Jambor wrote:
> In my fix for PR 119318 I put mask calculation in
> ipcp_bits_lattice::meet_with_1 above a final fix to value so that all
> the bits in the value which are meaningless according to mask have
> value zero, which has tripped a validator
On Tue, Apr 15, 2025 at 11:39:21PM +1000, Nathaniel Shead wrote:
> On Tue, Apr 15, 2025 at 09:16:46AM -0400, Jason Merrill wrote:
> > On 4/15/25 2:56 AM, Nathaniel Shead wrote:
> > > On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote:
> > > > On 4/13/25 6:32 AM, Nathaniel Shead wrote:
>
Ping.
If no obvious grammar errors are flagged, I'll likely just commit this
later today.
Thanks,
Iain.
Excerpts from Iain Buclaw's message of März 20, 2025 12:25 pm:
> Hi,
>
> This patch adds D front-end section to the GCC changes pages. When
> inspecting this, I noticed that the previous two
Hi,
On Tue, Apr 15 2025, Jakub Jelinek wrote:
> On Tue, Apr 15, 2025 at 02:17:46PM +0200, Martin Jambor wrote:
>> Hi,
>>
>> On Tue, Apr 15 2025, Jakub Jelinek wrote:
>> > On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
>> >> This patch just introduces a form of dumping of widest in
On 15/04/25 15:05 +0100, Jonathan Wakely wrote:
A few spelling and grammar fixes, and whitespace tweaks, but the only
significant thing is to qualify some calls to prevent ADL ...
Doh, as pointed out in chat the ADL thing is irrelevant because that's
not std::format.
So I think everything else
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, April 15, 2025 12:49 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH]middle-end: Fix incorrect codegen with PFA and VLS
> [PR119351]
>
> On Tue, 15 Apr 2025, Tamar Christina wrote:
>
> > Hi Al
On 4/15/25 12:01 AM, Alexandre Oliva wrote:
> On Apr 14, 2025, Peter Bergner wrote:
>
>> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles.
>
> Oh, is that so? It seems to have been the case for quite a long time.
> I can trivially see that GCC 9 already did that, but it may
On 4/15/25 7:57 AM, Andreas Schwab wrote:
* configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
64-bit multilib.
Can't say I'm happy with the amount of Cobol related churn at this phase
in our cycle. But this should be exceedingly safe. So OK.
jeff
Attached patch OK for master branch?
Will push soon if there are no objections.
From b329d899d07cda78bc44d88f81bdf10d5e2db302 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Tue, 15 Apr 2025 11:41:36 +
Subject: [PATCH] ref-temp1.C: Enable some tests for PE targets
Test
On 4/15/25 9:39 AM, Nathaniel Shead wrote:
On Tue, Apr 15, 2025 at 09:16:46AM -0400, Jason Merrill wrote:
On 4/15/25 2:56 AM, Nathaniel Shead wrote:
On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote:
On 4/13/25 6:32 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-p
This patch implements formatter specialization for input_ranges and
range_formatter class from P2286R8, as adjusted by P2585R1. The formatter
for pair/tuple is not yet provided, making maps not formattable.
This introduces an new _M_format_range member to internal __formatter_str,
that formats ran
On 4/9/25 2:53 PM, Vineet Gupta wrote:
Changes since v2
- Elide abnormal edges before LCM not after LCM
---
vsetvl phase4 uses LCM guided info to insert VSETVL insns, including a
straggler loop for "mising vsetvls" on certain edges. Currently it
asserts on encountering EDGE_ABNORMAL.
When
Hi!
The following testcase is miscompiled, because we emit a CLOBBER in a place
where it shouldn't be emitted.
Before lowering we have:
b_5 = 0;
b.0_6 = b_5;
b.1_1 = (unsigned _BitInt(129)) b.0_6;
...
= b_5;
The bitint coalescing assigns the same partition/underlying variable
for both b_5
On Apr 15, 2025, Peter Bergner wrote:
> On 4/14/25 11:30 PM, Alexandre Oliva wrote:
>> On Apr 14, 2025, Peter Bergner wrote:
>>
>>> This is an architecture independent test case, so I'm surprised this
>>> doesn't FAIL on non-powerpc targets since they don't know anything
>>> about altivec.
>>
Hi!
This testcase got fixed with r15-9397 PR119722 fix.
Tested on x86_64-linux -m32/-m64 with vanilla trunk as well
as with r15-9397 fix reverted (where it FAILs), committed
to trunk as obvious.
2025-04-16 Jakub Jelinek
PR tree-optimization/116093
* gcc.dg/bitint-122.c: New t
On Apr 15, 2025, Peter Bergner wrote:
> On 4/15/25 9:36 AM, Peter Bergner wrote:
>> So what ABI does powerpc-elf use and what does it mandate?
That's not for me to decide, but to me the patch that introduced
OS_MISSING_POWERPC64 and the PR106680 coversation suggests that enabling
-mpowerpc64 wit
On 4/15/25 1:56 PM, Richard Sandiford wrote:
Tejas Belagod writes:
The operand order to gen_vcond_mask call in the vec_extract pattern is wrong.
Fix the order where predicate is operand 3.
Tested and bootstrapped on aarch64-linux-gnu. OK for trunk?
gcc/ChangeLog
* config/aarch64/aarc
On Apr 14, 2025, Peter Bergner wrote:
> On 4/11/25 1:03 PM, Alexandre Oliva wrote:
>> gcc.dg/pr87600.h and gcc.dg/pr89313.c test for __powerpc__ and
>> __POWERPC__ to choose ppc register names, but ppc-elf defines neither;
>> it defines __PPC__, so test for that as well.
> Is there a reason why
On Apr 14, 2025, Peter Bergner wrote:
> diff --git a/gcc/testsuite/g++.dg/pr112822.C b/gcc/testsuite/g++.dg/pr112822.C
> -typedef __attribute__((altivec(vector__))) double co;
> +typedef double co __attribute__ ((vector_size (16)));
FWIW, I've tested this change on gcc-14 powerpc-elf and I confi
Thanks, committed to trunk :)
On Fri, Apr 11, 2025 at 12:27 PM Jesse Huang wrote:
>
> Codegen is incorrectly emitting a ".p2align 3" that coerces the
> alignment of the .note.gnu.property section from 4 to 8 on rv32.
>
> 2025-04-11 Jesse Huang
>
> gcc/ChangeLog
>
> * config/riscv/riscv
committed :)
On Mon, Apr 14, 2025 at 6:01 PM Kito Cheng wrote:
>
> This patch will be committed this week if CI passes and not strong
> objections since it's bug to large code model, also change is small
>
> On Mon, Apr 14, 2025 at 6:00 PM Kito Cheng wrote:
> >
> > Large code model assume the da
Alice Carlotti writes:
> This applies to the sysreg read/write intrinsics __arm_[wr]sr*. It does
> not depend on changes to Binutils, because GCC converts recognised
> sysreg names to an encoding based form, which is already ungated in Binutils.
>
> We have, however, agreed to make an equivalent
This is the 2nd version of the patch, the change is to replace "FALSE" with
"false" per Marek's comments.
C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
In c_fully_fold, it assumes that operands of function calls have already
been folded. However, when we build call to
Am Dienstag, dem 15.04.2025 um 14:50 +0200 schrieb Michael Matz:
> Hello,
...
> > struct A {
> > int *buf __counted_by(len); // 'len' *must* be in the struct.
> > int len;
> > };
>
> ... means that we would have to implement general delayed parsing for
> expressions in C parsers.
I have to
On Tue, Apr 15, 2025 at 5:02 AM LIU Hao wrote:
>
> 在 2025-4-14 04:10, Peter Damianov 写道:
> > diff --git a/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
> > b/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
> > index 9b2cd7e7b49..827215be3e2 100644
> > --- a/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
>
Hi,
I'd like to backport this testsuite enhancement to GCC 14 so that
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680896.html
can be backported to GCC 14 with testcases unchanged.
H.J.
---
As PR target/116174 shown, we may need to verify labels and the directive
order. Extend check-f
> Hi,
> > gcc/ChangeLog:
> >
> > PR tree-optimization/117790
> > * cfgloopmanip.cc (can_flow_scale_loop_freqs_p): New.
> > (flow_scale_loop_freqs): New.
> > (scale_loop_freqs_with_exit_counts): New.
> > (scale_loop_freqs_hold_exit_counts): New.
> > (scale_loop_profile): Ref
Hi,
> gcc/ChangeLog:
>
> PR tree-optimization/117790
> * cfgloopmanip.cc (can_flow_scale_loop_freqs_p): New.
> (flow_scale_loop_freqs): New.
> (scale_loop_freqs_with_exit_counts): New.
> (scale_loop_freqs_hold_exit_counts): New.
> (scale_loop_profile): Refactor
Hi,
> gcc/ChangeLog:
>
> PR tree-optimization/117790
> * tree-vect-loop.cc (scale_profile_for_vect_loop): Use
> scale_loop_profile_hold_exit_counts instead of scale_loop_profile. Drop
> the exit edge parameter, since the code now handles multiple exits.
> Adjust the
Hi!
Here is my attempt at the PR119614 LTO fix.
Of course, if Martin can come up with something cleaner, let's go with that
instead.
This patch just remembers when ipa_record_return_value_range was set
to a singleton range with CONSTANT_CLASS_P value and propagates that value
through LTO to ltran
On Tue, Apr 15, 2025 at 10:47:13AM -0500, Robert Dubner wrote:
> Speaking purely casually: I thought that that COBOL would be released with
> documented limited capability. "Yeah, it works on x86_64-linux and
> aarch64-linux. More to come.". We knew that we didn't know how to
> cross-compile
Tested the testcase fix with a Darwin cross-compiler.
Regression tested x86_64-pc-linux-gnu.
Applying to trunk.
-- 8< --
On Darwin and other targets with !can_alias_cdtor, we instead go to
maybe_thunk_ctor, which builds a thunk function that calls the general
constructor. And then cp_fold tries
On Tue, Apr 15, 2025 at 2:23 PM H.J. Lu wrote:
>
> On Tue, Apr 15, 2025 at 12:45 AM Uros Bizjak wrote:
> >
> > On Tue, Apr 15, 2025 at 1:06 AM H.J. Lu wrote:
> > >
> > > ix86_add_cfa_restore_note omits the REG_CFA_RESTORE REG note for registers
> > > pushed in red-zone. Since
> > >
> > > commit
There's a blurb at the top of the "Optimize Options" node telling
people that most optimization options are completely disabled at -O0
and a similar blurb in the entry for -Og, but nothing at the entry for
-O0. Since this is a continuing point of confusion it seems wise to
duplicate the informatio
This applies to the sysreg read/write intrinsics __arm_[wr]sr*. It does
not depend on changes to Binutils, because GCC converts recognised
sysreg names to an encoding based form, which is already ungated in Binutils.
We have, however, agreed to make an equivalent change in Binutils (which
would t
Tested on i686, x86_64 and aarch64 Darwin, plus x86_64, aarch64 and
powerpc64le Linux, pushed to trunk, thanks
Iain
--- 8 ---
The latest editions of XCode have altered the identify reported by 'ld -v'
(again). This means that GCC configure no longer detects the version.
Fixed by adding the new
Dear all,
the testcase in the PR shows a case where the pureness of a function
is not properly determined, even though the function is resolved, and
its attributes clearly show that it is pure, because gfc_pure_function
relies on isym or esym being set. This does not happen here, probably
becaus
Indu Bhagat writes:
> Using post-index stg is a faster way of memory tagging/untagging.
>
> TBD:
> - Currently generated by in the aarch64 backend. Not sure if this
> is the right way to do it.
> - Also not clear how to weave in the generation of stzg.
Similarly to patch 4, I think we sh
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, April 15, 2025 13:54
> To: Robert Dubner
> Cc: 'Jeff Law' ; gcc-patches@gcc.gnu.org; 'James
K.
> Lowden'
> Subject: Re: COBOL: Is anything stalled because of me?
>
> On Tue, Apr 15, 2025 at 10:47:13AM -0500, Robert Dubner wr
Indu Bhagat writes:
> Using post-index st2g is a faster way of memory tagging/untagging.
> Because a post-index 'st2g tag, [addr], #32' is equivalent to:
>stg tag, addr, #0
>stg tag, addr, #16
>add addr, addr, #32
>
> TBD:
> - Currently generated by in the aarch64 backend. Not sure
Hi Jason,
On Thu Apr 10, 2025 at 10:42 PM CEST, Jason Merrill wrote:
> On 9/6/24 7:15 AM, Simon Martin wrote:
>> We ICE upon the following *valid* code when mangling the requires
>> clause
>>
>> === cut here ===
>> template struct s1 {
>>enum { e1 = 1 };
>> };
>> template struct s2 {
>>
On Tue, Apr 15, 2025 at 06:46:26PM +, Qing Zhao wrote:
> This is the 2nd version of the patch, the change is to replace "FALSE" with
> "false" per Marek's comments.
>
> C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
> In c_fully_fold, it assumes that operands of fu
Alex wrote:
Tested on x86_64-pc-linux-gnu, this is only a library addition (and a
few tests) so it shouldn't cause any major impacts. I also tested
libgomp C to ensure the conditional compile was working.
Namely, the change is only to omp.h(.in) - effective for
__cplusplus >= 201103L.
Note th
On Sun, Mar 16, 2025 at 11:43 AM Jeff Law wrote:
>
>
>
> On 3/15/25 9:01 PM, Andrew Pinski wrote:
> > The problem here is there was a compare debug since the discriminators
> > would still take into account debug statements. For the edge we would look
> > at the first statement after the labels an
On Tue, Apr 15, 2025 at 09:07:44PM +0200, Martin Uecker wrote:
> Am Dienstag, dem 15.04.2025 um 14:50 +0200 schrieb Michael Matz:
> > Hello,
> ...
>
> > > struct A {
> > > int *buf __counted_by(len); // 'len' *must* be in the struct.
> > > int len;
> > > };
> >
> > ... means that we would hav
Thanks.
Pushed to trunk.
Qing
> On Apr 15, 2025, at 14:56, Marek Polacek wrote:
>
> On Tue, Apr 15, 2025 at 06:46:26PM +, Qing Zhao wrote:
>> This is the 2nd version of the patch, the change is to replace "FALSE" with
>> "false" per Marek's comments.
>>
>> C_MAYBE_CONST_EXPR is a C FE ope
This implements std::extents from according to N4950 and
contains partial progress towards PR107761.
If an extent changes its type, there's a precondition in the standard,
that the value is representable in the target integer type. This commit
uses direct initialization to perform the conversion,
在 2025-4-14 04:10, Peter Damianov 写道:
diff --git a/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
b/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
index 9b2cd7e7b49..827215be3e2 100644
--- a/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
+++ b/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
@@ -1,18 +1,46 @@
On 4/15/25 2:56 AM, Nathaniel Shead wrote:
On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote:
On 4/13/25 6:32 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Currently, pruned lambda captures are still leftover in the function's
Add logic for the case of two FMV annotated functions with identical
signature other than the return type.
Previously this was ignored, this changes the behavior to emit a diagnostic.
gcc/cp/ChangeLog:
PR c++/119498
* decl.cc (duplicate_decls): Change logic to not always exclude F
In r14-7153-gadbc46942aee75 we removed a duplicate definition of
__glibcxx_want_range_iota from , but __cpp_lib_ranges_iota
should be defined in at all.
libstdc++-v3/ChangeLog:
* include/std/ranges (__glibcxx_want_ranges_iota): Do not
define.
---
Tested x86_64-linux. Pushed to t
Move namespace ranges inside the feature test macro guard, because
'ranges' is not a reserved name before C++20.
libstdc++-v3/ChangeLog:
* include/std/numeric (ranges): Only declare namespace for C++23
and later.
(ranges::iota_result): Fix indentation.
* testsuite/
This testcase was fixed by r15-3052-gc7b76a076cb2c6ded but is
a testcase that failed in a different fashion and a much older
failure than the one added with r15-3052.
Pushed as obvious after a quick test.
PR tree-optimization/118476
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr11
A few spelling and grammar fixes, and whitespace tweaks, but the only
significant thing is to qualify some calls to prevent ADL ...
On 14/04/25 16:13 +0200, Tomasz Kamiński wrote:
This patch implements formatter specialization for input_ranges and
range_formatter class form P2286R8, as adjusted
> On 15 Apr 2025, at 15:42, Richard Biener wrote:
>
> On Mon, Apr 14, 2025 at 3:11 PM Kyrylo Tkachov wrote:
>>
>> Hi Honza,
>>
>>> On 13 Apr 2025, at 23:19, Jan Hubicka wrote:
>>>
+@opindex fipa-reorder-for-locality
+@item -fipa-reorder-for-locality
+Group call chains close
Speaking purely casually: I thought that that COBOL would be released with
documented limited capability. "Yeah, it works on x86_64-linux and
aarch64-linux. More to come.". We knew that we didn't know how to
cross-compile, and we knew that other platforms would have to come, in time.
It nev
On 3/30/25 6:12 PM, Jan Hubicka wrote:
Hi,
I noticed that this patch got forgotten and I think it may be useful to
solve this next stage 1.
cp_apply_type_quals_to_decl drops 'const' if the type has mutable members.
Unfortunately TREE_READONLY on the PARM_DECL isn't helpful in the case of an
inv
On Mon, Apr 14, 2025 at 08:28:55PM +, Qing Zhao wrote:
> C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
> In c_fully_fold, it assumes that operands of function calls have already
> been folded. However, when we build call to .ACCESS_WITH_SIZE, all its
> operands are
ix86_add_cfa_restore_note omits the REG_CFA_RESTORE REG note for registers
pushed in red-zone. Since
commit 0a074b8c7e79f9d9359d044f1499b0a9ce9d2801
Author: H.J. Lu
Date: Sun Apr 13 12:20:42 2025 -0700
APX: Don't use red-zone with 32 GPRs and no caller-saved registers
disabled red-zone,
This patch implements formatter specialization for input_ranges and
range_formatter class from P2286R8, as adjusted by P2585R1. The formatter
for pair/tuple is not yet provided, making maps not formattable.
This introduces an new _M_format_range member to internal __formatter_str,
that formats ran
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, April 15, 2025 12:50 PM
> To: Tamar Christina
> Cc: Richard Sandiford ; gcc-patches@gcc.gnu.org;
> nd
> Subject: RE: [PATCH]middle-end: Fix incorrect codegen with PFA and VLS
> [PR119351]
>
> On Tue, 15 Apr 2025, Tamar Christi
This is a reimplementation of get_target_clone_attr_len,
get_attr_str, and separate_attrs using string_slice and auto_vec to make
memory management and use simpler.
Adds get_target_version helper function to get the target_version string
from a decl.
gcc/c-family/ChangeLog:
* c-attribs.c
On 4/9/25 6:08 AM, Robin Dapp wrote:
Hi,
when lifting up a vsetvl into a block we currently don't consider the
block's transparency with respect to the vsetvl as in other parts of the
pass. This patch does not perform the lift when transparency is not
guaranteed.
This condition is more rest
On 4/13/25 1:56 PM, Patrick Palka wrote:
Alternatively, rather than passing the most general template + args to
push_tinst_level, we can pass the partially instantiated template +
innermost args via just:
gcc/cp/ChangeLog:
* constraint.cc (satisfy_declaration_constraints): Pass the
> On Apr 14, 2025, at 16:35, Marek Polacek wrote:
>
> On Mon, Apr 14, 2025 at 08:28:55PM +, Qing Zhao wrote:
>> C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
>> In c_fully_fold, it assumes that operands of function calls have already
>> been folded. However, wh
On 4/15/25 12:24 AM, Eikansh Gupta wrote:
The patterns can be simplified as shown below:
(a != b) & ((a|b) != 0) -> (a != b)
(a != b) | ((a|b) != 0) -> ((a|b) != 0)
The similar simplification can be there for (a == b). This patch adds
simplification for above patterns. The forwprop pass wa
Hi,
Indu Bhagat writes:
> subg (Subtract with Tag) is an Armv8.5-A memory tagging (MTE)
> instruction. It can be used to subtract an immediate value scaled by
> the tag granule from the address in the source register.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (subg): New definitio
Tested on x86_64-pc-linux-gnu, this is only a library addition (and a
few tests) so it shouldn't cause any major impacts. I also tested
libgomp C to ensure the conditional compile was working.
Okay for trunk?
From 1ef3fe0a1f026689e64963ec9ab0b04b7e6b1bde Mon Sep 17 00:00:00 2001
From: waffl3x
Da
Pushing as obvious.
Thanks,
Kyrill
Signed-off-by: Kyrylo Tkachov
* common.opt.urls: Regenerate.
0001-Regenerate-common.opt.urls.patch
Description: 0001-Regenerate-common.opt.urls.patch
On Tue, Apr 15, 2025 at 1:06 AM H.J. Lu wrote:
>
> ix86_add_cfa_restore_note omits the REG_CFA_RESTORE REG note for registers
> pushed in red-zone. Since
>
> commit 0a074b8c7e79f9d9359d044f1499b0a9ce9d2801
> Author: H.J. Lu
> Date: Sun Apr 13 12:20:42 2025 -0700
>
> APX: Don't use red-zone
On Thu, Apr 10, 2025 at 2:26 PM Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> -mnop-mcount can be trivially enabled for -fPIC codegen as long as PLTs
> are being used, given that the instruction encodings are identical, only
> the target may resolve differently depending on how the linker de
Hans-Peter Nilsson writes:
> Noticed while investigating a regression for cris-elf with
> r15-9239-g4d7a634f6d4102 "combine: Allow 2->2 combinations,
> but with a tweak [PR116398]" (to-be-reported).
>
> The comment was introduced when breaking out the
> combine_validate_cost function, in r0-59417-
On Thu, Apr 10, 2025 at 2:27 PM Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> __fentry__") updated the logic that emits mcount() / __fentry__() calls
> into function prologues when profiling is enabled, to avoid GOT-base
My recent r15-9381-g648d5c26e25497 change assumes that a contiguous
iterator with the correct value_type can be converted to a const charT*
but that's not true for volatile charT*. The optimization should only be
done if it can be converted to the right pointer type.
Additionally, some generic loo
A prior commit added std::extents, this commit adds the tests. The bulk
is focussed on testing the constructors. These are split into three
groups:
1. the ctor from other extents and the copy ctor,
2. the ctor from a pack of integer-like objects,
3. the ctor from shapes, i.e. span and array.
For
Uses the FTM infrastructure to create an internal feature testing macro
for partial availability of mdspan; which is then used to hide the
contents of the header mdspan when compiling against a standard prior to
C++23.
libstdc++-v3/ChangeLog:
* include/bits/version.def: Add internal featu
Hi!
Calls with musttail attribute don't really work with -fsanitize=thread in
GCC. The problem is that TSan instrumentation adds
__tsan_func_entry (__builtin_return_address (0));
calls at the start of each instrumented function and
__tsan_func_exit ();
call at the end of those and the latter
1 - 100 of 165 matches
Mail list logo
