Hi All,
I had missed this one during the AMDGCN test failures.
Like vect-early-break_18.c this test is also scalaring the
loads and thus leading to unexpected vectorization for this
testcase.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Cross checked the failing case on amdgc
On Fri, Apr 18, 2025 at 05:48:46PM -0700, Jerry D wrote:
> I will be committing a fix for this to the 16 mainline tonight.
>
> I am requesting Release Manager approval to push to 15 release branch after
> full testing here.
>
> Regards,
>
> Jerry
>
> See attached diff.
>
> 2025-04-18 Steven G
Since match and simplify will simplify `bool_var != 0` to just `bool_var` and
this is inside a GIMPLE_COND, fold_stmt will return true but nothing has
changed.
So let's just reject the replacement if we are replacing with the same
simplification
inside replace_stmt_with_simplification. This can s
To speed up things slightly so not needing to call all the way through
to match and simplify, we should return early for true/false on GIMPLE_COND.
gcc/ChangeLog:
* gimple-fold.cc (fold_stmt_1): For GIMPLE_COND return early
for true/false.
Signed-off-by: Andrew Pinski
---
gcc/g
This moves the `(cmp (cond @0 @1 @2) @3)` simplifcation to be after the boolean
comparison
simplifcations so that we don't end up simplifing into the same thing for a
GIMPLE_COND.
gcc/ChangeLog:
* match.pd: Move `(cmp (cond @0 @1 @2) @3)` simplifcation after
the bool comparison
I noticed while improving forwprop, that fold_stmt sometimes would return true
even if there was no change that happened. These fixes 3 of those places.
In the first one we had:
```
tmp = a ? b : c
if (tmp != 0)
```
And match and simplify would return the same thing but that was just because of
t
On Wed, Jan 29, 2025 at 10:33:14AM +0100, Christoph Müllner wrote:
> 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.
>
> The assembly patterns in `bitfield-bitint-abi-align16.c` an
These patches LGTM from myside. But please wait for other folks to comment.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2025-04-23 09:28
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; ken.chen; hongtao.liu; Pan
Li
Subject: [PATCH v1 0/4] Refactor long function expand_const_
cat test.c
void
foo ()
{
__mmask8 mask1 = _mm_cmpeq_epu32_mask (pi128[0], pi128[1]);
a = mask1 & 15;
}
with -O2 -march=x86-64-v4, gcc generates
foo():
movqpi128(%rip), %rax
vmovdqa (%rax), %xmm0
vpcmpeqd16(%rax), %xmm0, %k0
kmovb %k0, %eax
On Mon, Apr 21, 2025 at 2:52 PM liuhongt wrote:
>
> Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
> or vpandn.
> Current register_operand/vector_operand could lose some optimization
> opportunity.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for tru
> The only thing I think we want for the patch (as Pan also raised last time)
> is
> the param to set those .vx costs to zero in order to ensure the tests test
> the
> right thing (--param=vx_preferred/gr2vr_cost or something).
I see, shall we start a new series for this? AFAIK, we may need so
From: Pan Li
Consider the expand_const_vector is quit long (about 500 lines)
and complicated, we would like to extract the different case
into different functions. For example, the const vector stepped
will be extracted into expand_const_vector_stepped.
The below test suites are passed for this
From: Pan Li
Consider the expand_const_vector is quit long (about 500 lines)
and complicated, we would like to extract the different case
into different functions. For example, the const vector duplicate
will be extracted into expand_const_vector_duplicate, and then
expand_const_vector_duplicate
From: Pan Li
Consider the expand_const_vector is quit long (about 500 lines)
and complicated, we would like to extract the different case
into different functions. For example, the const vec_series
will be extracted into expand_const_vec_series.
The below test suites are passed for this patch.
From: Pan Li
Consider the expand_const_vector is quit long (about 500 lines)
and complicated, we would like to extract the different case
into different functions. For example, the const vec_duplicate
will be extracted into expand_const_vec_duplicate.
The below test suites are passed for this p
From: Pan Li
Per discussion from PR118931 thread, the expand_const_vector is
quit long with more than 500 lines, which is unfriendly for debugging
and maintaince. Thus, we extract some sub functions to make it clear
and delicate the concrete const vector expanding into sub functions.
Aka:
expan
> > But vectorizer computes costs of vector load of off array, 4x moving vector
> > to
> > scalar and 4x stores. I wonder if generic code can match this better and
> > avoid
> > the vector load of addresses when open-coding gather/scatter?
>
> The vectorizer does not explicitly consider the low
On 4/22/25 1:21 PM, Tobias Burnus wrote:
Jason Merrill wrote:
On 4/22/25 11:04 AM, Tobias Burnus wrote:
The question is why does this code trigger at all, given
that there is OpenMP but no offload code at all? And how
to fix it in case there is offload code and modules are used.
This seems to
From: Andrew Pinski
There are GCN/C++ target as well as offloading codes, where the hard-coded
section names in 'gcn_hsa_declare_function_name' do not fit, and assembly thus
fails:
LLVM ERROR: Size expression must be absolute.
This commit progresses GCN target:
[-FAIL: g++.dg/init/call
On Tue, Apr 22, 2025 at 5:32 AM Richard Sandiford
wrote:
>
> The list is structured as:
>
> - new configurations
> - command-line changes
> - ACLE changes
> - everything else
>
> As usual, the list of new architectures, CPUs, and features is from a
> purely mechanical trawl of the associated .def
Tuesday, April 22, 2025
"Richard Sandiford" wrote:
> + Support has been added for the AArch64 MinGW target
> + (aarch64-w64-mingw32). At present, this target only
> + supports C, but further work is planned.
> +
Thank you for the release summary for AArch64 and for mentioning the new
HTEC Public
Hi,
> This is probably OK, but it's unclear to me if it's dependent upon any
> of the earlier changes. If it's independent of other changes, then it
> could go in now with a suitable ChangeLog entry.
> Jeff
I would like to inform you that the version 2 of this patch is available
at
On 4/22/25 11:00 AM, Indu Bhagat wrote:
On 4/15/25 8:35 AM, Richard Sandiford wrote:
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 regis
On Wed, Mar 26, 2025 at 09:01:43AM +0100, Jakub Jelinek wrote:
> The following testcase FAILs because the always_inline function can't
> be inlined.
> The rs6000 backend has similarly to other targets a hook which rejects
> inlining which would bring in new ISAs which aren't there in the caller.
>
Hi Andre,
Am 22.04.25 um 15:07 schrieb Andre Vehreschild:
Hi all,
attached patch fixes an illegal use of gfc_current_locus during the
check()-phase of several coarray functions. Instead gfc_current_intrinsic_where
needs to be used.
this is bordering on the obvious and thus OK, except for:
@@
HTEC Public
Hi,
> So I'm not at all concerned about the mips specific bits of this patch.
> After all, they only affect mips ports and the changes seem sensible.
> They would need a ChangeLog entry to go forward through.
> What is concerning is the config.ml change which has no comments about
>
On 4/15/25 11:52 AM, Richard Sandiford wrote:
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
On 4/15/25 9:21 AM, Richard Sandiford wrote:
Indu Bhagat writes:
Store Allocation Tags (st2g) is an Armv8.5-A memory tagging (MTE)
instruction. It stores an allocation tag to two tag granules of memory.
TBD:
- Not too sure what is the best way to generate the st2g yet; A
subsequent pat
On 4/15/25 8:35 AM, Richard Sandiford wrote:
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/aa
On Sun, 20 Apr 2025 at 10:03, ZENG Hao wrote:
>
> When building for 'i386-*' targets, all basic types are 'sometimes lock-free'
> and thus std::atomic_signed_lock_free and std::atomic_unsigned_lock_free are
> not declared. In the header , they are placed in preprocessor
> condition __cpp_lib_atomic
On Tue, Apr 22, 2025 at 07:21:14PM +0200, Tobias Burnus wrote:
> I currently do not see whether the code is needed in this case or not, but I
> assume it is, if we want to support static initializers?!?
>
> In any case, it seems as if the condition 'if (flag_openmp)' additionally
> requires '&& lo
Jason Merrill wrote:
On 4/22/25 11:04 AM, Tobias Burnus wrote:
The question is why does this code trigger at all, given
that there is OpenMP but no offload code at all? And how
to fix it in case there is offload code and modules are used.
This seems to be because of:
if (module_global_init
On 4/22/25 11:04 AM, Tobias Burnus wrote:
Jason Merrill wrote:
This is OK with a FIXME; presumably if we want to support running
static constructors on the offload target we will eventually want to
support that in modules as well.
Well, the code that added support for static constructors
on
Tested on x86_64-pc-linux-gnu, pushed to trunk and the 15 release branch with
pre-approval from Jonathan and Jakub.
-- >8 --
This non-standard optimization breaks real-world code that expects the
result of std::projected to always (be a class type and) have a value_type
member, which isn't true f
On Tue, Apr 22, 2025 at 05:22:47PM +0100, Richard Sandiford wrote:
> We implemented FAMINMAX ACLE support but failed to define the
> associated feature macro.
>
> Tested on aarch64-linux-gnu & pushed to trunk. OK for GCC 15 too?
>
> Sorry for the late patch. I only noticed this macro was missin
Ping! Can we backport this to 15 please?
Regards,
Jerry
On 4/18/25 6:35 PM, Jerry D wrote:
On 4/18/25 5:48 PM, Jerry D wrote:
I will be committing a fix for this to the 16 mainline tonight.
I am requesting Release Manager approval to push to 15 release branch
after full testing here.
Rega
Hi!
On Tue, 22 Apr 2025 at 13:55, Thomas Schwinge wrote:
>
> Hi!
>
> On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression
> wrote:
> > Our automatic CI has detected problems related to your patch(es). Please
> > find some details below.
> >
> > In bootstrap_check master-arm-check_boots
We implemented FAMINMAX ACLE support but failed to define the
associated feature macro.
Tested on aarch64-linux-gnu & pushed to trunk. OK for GCC 15 too?
Sorry for the late patch. I only noticed this macro was missing while
writing up the GCC 15 changes. It would be good to get it in for
15.1
Excerpts from Sam James's message of April 20, 2025 2:46 am:
> This bootstraps with some test failures but works well enough to build
> 11..15.
>
> libphobos/ChangeLog:
>
> * configure.tgt: Add sparc64-unknown-linux-gnu as a supported target.
> ---
> As discussed on IRC. OK? I'd like to bac
On Tue, 22 Apr 2025 at 13:53, Tomasz Kamiński wrote:
>
> As P2286R8 and P2585R1 as now fully implemented, we now define
> __cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges.
> This macro is provided only in .
>
> Uses of internal __glibcxx_format_ranges are also updated.
>
>
Hi,
I have met the following issue when I tried to implement the following into
tree-object-size.cc:
(And this took me quite some time, still don’t know what’s the best solution)
> On Apr 16, 2025, at 10:46, Qing Zhao wrote:
>
> 3. When generating the reference to the field member in tree-obje
On Mon, Apr 14, 2025 at 5:21 PM Jason Merrill wrote:
>
> 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.
> >>
> On 22 Apr 2025, at 15:31, Tamar Christina wrote:
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, April 22, 2025 2:28 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
>> ktkac...@nvidia.com
>> Subject: Re: [PATCH] Document AArch64 cha
/* TODO: We set RVV instruction cost as 1 by default.
Cost Model need to be well analyzed and supported in the future. */
+ int cost_val = 1;
+ enum rtx_code rcode = GET_CODE (x);
+
+ /* Aka (vec_duplicate:RVVM1DI (reg/v:DI 143 [ x ])) */
+ if (rcode == VEC_DUPLICATE && SCALAR_INT_MO
Jason Merrill wrote:
This is OK with a FIXME; presumably if we want to support running
static constructors on the offload target we will eventually want to
support that in modules as well.
Well, the code that added support for static constructors
on the offload target exposed the issue. Thus
On Tue, Apr 22, 2025 at 10:47:31AM -0400, Jason Merrill wrote:
> On 4/21/25 6:46 AM, Nathaniel Shead wrote:
> > I don't really know how OpenMP works, hopefully this makes sense.
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > And for 15 (I guess after release)?
>
> This is
On 4/21/25 6:46 AM, Nathaniel Shead wrote:
I don't really know how OpenMP works, hopefully this makes sense.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
And for 15 (I guess after release)?
This is OK with a FIXME; presumably if we want to support running static
constructor
On 4/17/25 10:06 AM, Patrick Palka wrote:
On Wed, 16 Apr 2025, Jason Merrill wrote:
If we already gave an error while parsing a function, we don't also need to
try to explain what's wrong with it when we later try to use it in a
constant-expression. In the new testcase explain_invalid_constexp
On Tue, Apr 22, 2025 at 3:54 PM Kyrylo Tkachov wrote:
>
> Hi all,
>
> We had not noticed that after g:299a8e2dc667e795991bc439d2cad5ea5bd379e2 the
> FP8FMA and FP8DOT4 features aren't implied by FP8FMA. The intent is for
> -mcpu=olympus to support all of them.
> Fix the definition to include the r
This updates the backported test.
Pushed.
PR tree-optimization/119706
* g++.target/aarch64/sve/pr119706.C: Adjust --param
aarch64-autovec-preference.
---
gcc/testsuite/g++.target/aarch64/sve/pr119706.C | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi all,
We had not noticed that after g:299a8e2dc667e795991bc439d2cad5ea5bd379e2 the
FP8FMA and FP8DOT4 features aren't implied by FP8FMA. The intent is for
-mcpu=olympus to support all of them.
Fix the definition to include the relevant sub-features explicitly.
Bootstrapped and tested on aarch64
On April 22, 2025 12:08:51 AM PDT, Sam James wrote:
>Kees Cook writes:
>
>> On Thu, Apr 10, 2025 at 05:17:51PM -0700, Keith Packard wrote:
>>> A target using 16-bit ints won't have enough bits to hold the whole
>>> flag_sanitize set. Be explicit about using uint32 for the attribute data.
>>>
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, April 22, 2025 2:28 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
> ktkac...@nvidia.com
> Subject: Re: [PATCH] Document AArch64 changes for GCC 15
>
> Tamar Christina writes:
> >> -Original
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, April 22, 2025 1:31 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Richard Earnshaw ; ktkac...@nvidia.com;
>> Tamar Christina
>> Subject: [PATCH] Document AArch64 changes for GCC 15
>>
>> The list is st
After reviewing the entire dependencies to get this enabled by
default, our current plan is as follows:
1. Send a v2 (there still were outstanding comments against some
testcases) of the "turn on by default for -O2" patch.
2. Address PR118873, PR119862, and PR119884 before merging the patch
that tu
On Tue, 22 Apr 2025, Richard Sandiford wrote:
> Ping, since it sounds from irc like the release is coming soon :)
Fine with me.
> Richard Sandiford writes:
> > gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed
> > in the PR trail. The fix didn't make it into GCC 15, so thi
On Tue, Apr 22, 2025 at 01:27:34PM +0200, Richard Biener wrote:
> I assume this passed bootstrap & regtest?
Yes it did
>
> This is OK for trunk after we've released GCC 15.1.
Thanks.
Andi
Hi all,
attached patch fixes an illegal use of gfc_current_locus during the
check()-phase of several coarray functions. Instead gfc_current_intrinsic_where
needs to be used. This error does not crash gfortran reliably. But valgrind
reports an access to uninitialized memory. I therefore do not know
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, April 22, 2025 1:31 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; ktkac...@nvidia.com;
> Tamar Christina
> Subject: [PATCH] Document AArch64 changes for GCC 15
>
> The list is structured as:
>
> - new configurat
We have sent a new version for this, with updated testcases
(https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681606.html).
Thanks,
Konstantinos
On Wed, Jan 29, 2025 at 8:32 PM Richard Sandiford
wrote:
>
> Christoph Müllner writes:
> > The avoid-store-forwarding pass is disabled by default
Ping, since it sounds from irc like the release is coming soon :)
Richard Sandiford writes:
> gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed
> in the PR trail. The fix didn't make it into GCC 15, so this patch
> XFAILs the test instead.
>
> Other targets might benefit fro
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.
The assembly patterns in `bitfield-bitint-abi-align16.c` and
`bitfield-bitint-abi-align8.c` have been updated to account for
the asf tra
As P2286R8 and P2585R1 as now fully implemented, we now define
__cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges.
This macro is provided only in .
Uses of internal __glibcxx_format_ranges are also updated.
PR libstdc++/109162
libstdc++-v3/ChangeLog:
* inclu
The list is structured as:
- new configurations
- command-line changes
- ACLE changes
- everything else
As usual, the list of new architectures, CPUs, and features is from a
purely mechanical trawl of the associated .def files. I've identified
features by their architectural name to try to impro
On Tue, 22 Apr 2025 at 12:19, Tomasz Kamiński wrote:
>
> This patch implements formatter specializations for standard container
> adaptors
> (queue, priority_queue and stack) from P2286R8.
>
> To be able to access the protected `c` member, the adaptors befriend
> corresponding formatter specializ
Hi!
On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression
wrote:
> Our automatic CI has detected problems related to your patch(es). Please find
> some details below.
>
> In bootstrap_check master-arm-check_bootstrap, after:
> | commit gcc-15-9463-gaa3e72f9430
> | Author: Thomas Schw
Hi,
Thanks for fixing this. I just checked glibc, which implements
__sigsetjmp as:
# define sigsetjmp(env, savemask) __sigsetjmp (env, savemask)
So I would think this is fine. I leave the ack to the Jakub, Richard et
al, of course.
Thanks,
Jørgen
On 2025-04-22 10:33, Rainer Orth wrote:
T
On Tue, Apr 22, 2025 at 01:26:44PM +0200, Rainer Orth wrote:
> fine with me. This way there's no hurry with the other patches for fear
> of either breaking the build on non-Linux platforms or impacting COBOL
> on Linux.
No rush, sure, on the other side, better resolve all those in stage1...
Jakub Jelinek writes:
> On Tue, Apr 22, 2025 at 01:26:44PM +0200, Rainer Orth wrote:
>> fine with me. This way there's no hurry with the other patches for fear
>> of either breaking the build on non-Linux platforms or impacting COBOL
>> on Linux.
>
> No rush, sure, on the other side, better reso
On Fri, Mar 14, 2025 at 11:51 PM H.J. Lu wrote:
>
> 1. Honor TARGET_PROMOTE_PROTOTYPES during RTL expand.
> 2. Drop targetm.promote_prototypes from C, C++ and Ada frontends.
> 3. Adjust tests for the C frontend promotion removal.
> 4. gcc.dg/tree-ssa/pr108357.c fails with the C frontend promotion
Hi Jakub,
> On Tue, Apr 22, 2025 at 01:14:51PM +0200, Rainer Orth wrote:
>> what about trunk then? Right now, cobol still doesn't build there on
>> Solaris/amd64 because 3 patches are missing:
>>
>> cobol: Don't require GLOB_BRACE etc. [PR119217]
>> https://gcc.gnu.org/pipermail/gcc
On Fri, Apr 11, 2025 at 6:10 PM Andi Kleen wrote:
>
> Right now ggc has a single free list for multiple sizes. In some cases
> the list can get mixed by orders and then the allocator may spend a lot
> of time walking the free list to find the right sizes.
>
> This patch splits the free list into m
On Tue, Apr 22, 2025 at 01:14:51PM +0200, Rainer Orth wrote:
> what about trunk then? Right now, cobol still doesn't build there on
> Solaris/amd64 because 3 patches are missing:
>
> cobol: Don't require GLOB_BRACE etc. [PR119217]
> https://gcc.gnu.org/pipermail/gcc-patches/2025-Apr
On Sat, Apr 12, 2025 at 5:09 PM Andi Kleen wrote:
>
> From: Andi Kleen
>
> ... that uses -march=native -mtune=native to build a compiler optimized
> for the host.
-march=native implies -mtune=native so I think the latter is redundant.
> config/ChangeLog:
>
> * bootstrap-native.mk: New f
This patch implements formatter specializations for standard container adaptors
(queue, priority_queue and stack) from P2286R8.
To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that such specialization
may be disable if the containe
Hi Jerry, hi Paul,
thanks for the review. Committed as gcc-16-79-g6e3b92848b5 (for the 6 of 5
commit) on mainline.
Thanks again for the fast review.
Regards,
Andre
On Fri, 18 Apr 2025 18:27:03 -0700
Jerry D wrote:
> On 4/18/25 9:13 AM, Paul Richard Thomas wrote:
> > Hi Andre,
> >
>
Hi Richard,
> On Tue, Apr 22, 2025 at 12:31 PM Sam James wrote:
>>
>> Jakub Jelinek writes:
>>
>> > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
>> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
>> >> >
>> >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wr
On 4/20/25 9:56 AM, Yixuan Chen wrote:
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE): Add xt-c908, xt-c908v,
xt-c910, xt-c910v2, xt-c920, xt-c920v2.
(RISCV_CORE): Add xt-c908, xt-c908v, xt-c910, xt-c910v2, xt-c920,
xt-c920v2
* config/riscv/riscv.cc: A
On Tue, Apr 22, 2025 at 12:31 PM Sam James wrote:
>
> Jakub Jelinek writes:
>
> > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
> >> >
> >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> >> > > That's o
On Tue, 22 Apr 2025 at 10:25, Andreas Schwab wrote:
>
> * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
OK for trunk and gcc-15 (confirmed by Jakub on IRC). Thanks.
> ---
> .../abi/post/m68k-linux-gnu/baseline_symbols.txt | 11 +++
> 1 file changed, 11 inser
On 22/04/25 09:38 +0200, Tomasz Kamiński wrote:
This patch implements formatter specializations for standard container adaptors
(queue, priority_queue and stack) from P2286R8.
To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that
On Tue, 22 Apr 2025 at 11:43, Andreas Schwab wrote:
>
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
OK for trunk and gcc-15 (confirmed by Jakub on IRC).
> ---
> .../post/riscv64-linux-gnu/baseline_symbols.txt | 15 +++
> 1 file changed, 15 insertions(+
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
---
.../post/riscv64-linux-gnu/baseline_symbols.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git
a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
b/libstdc++-v3/config/abi/post/
Jakub Jelinek writes:
> On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
>> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
>> >
>> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>> > > That's one option, but maybe it's better the other way round: instead of
>
On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
> >
> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> > > That's one option, but maybe it's better the other way round: instead of
> > > excluding known-bad targe
On Sun, Apr 20, 2025 at 11:26 PM H.J. Lu wrote:
>
> Don't assume that stack slots can only be accessed by stack or frame
> registers. We first find all registers defined by stack or frame
> registers. Then check memory accesses by such registers, including
> stack and frame registers.
>
> gcc/
>
On Tue, Apr 22, 2025 at 11:32:43AM +0200, Rainer Orth wrote:
> Hi Jonathan,
>
> > On Tue, 22 Apr 2025 at 09:47, Rainer Orth
> > wrote:
> >>
> >> Hi Jonathan,
> >>
> >> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth
> >> > wrote:
> >> >>
> >> >> The Linux/sparc64 libstdc++ baselines haven't been up
Hi Jonathan,
> On Tue, 22 Apr 2025 at 09:47, Rainer Orth
> wrote:
>>
>> Hi Jonathan,
>>
>> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth
>> > wrote:
>> >>
>> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
>> >> This patch fixes that.
>> >>
>> >> Tested on sparc64-unknown
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
---
.../abi/post/m68k-linux-gnu/baseline_symbols.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
b/libstdc++-v3/config/abi/post/m68k-li
On Tue, 22 Apr 2025 at 10:03, Tomasz Kamiński wrote:
>
> Test for format parse format string and compile time,
> flat_maps ones test all functionality in single test file.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/23_containers/flat_map/1.cc: Add dg-timeout-factor 2.
> * testsuit
On Tue, 22 Apr 2025 at 09:49, Jakub Jelinek wrote:
>
> On Tue, Apr 22, 2025 at 09:29:16AM +0100, Jonathan Wakely wrote:
> > On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek wrote:
> > > We forgot to update these timely, sorry for that, the following patch
> > > updates them from the 15.1-rc1 builds in
On Tue, 22 Apr 2025 at 09:47, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth
> > wrote:
> >>
> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
> >> This patch fixes that.
> >>
> >> Tested on sparc64-unknown-linux-gnu on both the gcc-1
On Thu, 17 Apr 2025, Robert Dubner wrote:
> Adds a COBOL section to htdocs/gcc-15/changes.html.
There was an extra in there which I just fixed (= pushed).
(The first hunk is just a whitespace change to align more closely with the
rest of the page; the fix is in the second hunk.)
Gerald
commi
Test for format parse format string and compile time,
flat_maps ones test all functionality in single test file.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/flat_map/1.cc: Add dg-timeout-factor 2.
* testsuite/23_containers/flat_multimap/1.cc: Likewise.
* testsuite/st
On Tue, 22 Apr 2025 at 08:28, Rainer Orth wrote:
>
> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
> This patch fixes that.
>
> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
>
> Ok for both?
This adds:
+TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
+T
On Tue, Apr 22, 2025 at 10:51 AM Kyrylo Tkachov wrote:
>
> Hi all,
>
> Filip Kastl pointed out that contrib/check-params-in-docs.py complains
> about params not documented in invoke.texi, so this patch adds the short
> explanation from params.opt for these to the invoke.texi section.
> Thanks for
Hi all,
Filip Kastl pointed out that contrib/check-params-in-docs.py complains
about params not documented in invoke.texi, so this patch adds the short
explanation from params.opt for these to the invoke.texi section.
Thanks for the reminder.
Ok for trunk and GCC 15 branch?
Kyrill
Signed-off-by:
On Thu, 17 Apr 2025, Robert Dubner wrote:
> In the absence of commentary, I have pushed those documentation changes.
This is fine. You can also copy me on wwwdocs changes, though that's
certainly not required (and I do have filters to focus on these on
gcc-patches).
Gerald
On Tue, Apr 22, 2025 at 09:29:16AM +0100, Jonathan Wakely wrote:
> On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek wrote:
> > We forgot to update these timely, sorry for that, the following patch
> > updates them from the 15.1-rc1 builds in Fedora.
> >
> > Ok for trunk and 15?
> >
> > 2025-04-22 Jaku
On Tue, 22 Apr 2025, Rainer Orth wrote:
> The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin:
>
> FAIL: gcc.misc-tests/gcov-31.c (test for excess errors)
>
> Excess errors:
> /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5:
> error: implicit declaration of fu
1 - 100 of 123 matches
Mail list logo
