Hi Harald,
I try to explain why I think my patch although solving the issue for this case,
does not do so in every case:
My patch lets dependency analysis figure that the two objects can not have any
dependencies on each other or memory they are pointing to when the types are
different. Lets assu
Hi all,
Implement partitioning and cloning in the callgraph to help locality.
A new -fipa-reorder-for-locality flag is used to enable this.
The majority of the logic is in the new IPA pass in ipa-locality-cloning.cc
The optimization has two components:
* Partitioning the callgraph so as to group c
On Wed Mar 5, 2025 at 10:32 PM CET, Jason Merrill wrote:
> On 3/5/25 6:58 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
>>> On 2/14/25 12:08 PM, Simon Martin wrote:
We have been miscompiling the following valid code since GCC8, and
r8
On 3/6/25 9:49 AM, Richard Biener wrote:
On Thu, 6 Mar 2025, Michal Jires wrote:
Incremental LTO disabled cleanup of output_files since they have to
persist in ltrans cache.
This unintetionally also kept temporary early debug "*.debug.temp.o"
files.
Bootstrapped/regtested on x86_64-linux.
Ok f
Hi Honza,
Thanks a lot for the review!
Answers inline.
I’ve resent an updated version of the patch incorporating the feedback:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676958.html
Thanks,
Kyrill
> On 5 Jan 2025, at 18:06, Jan Hubicka wrote:
>
>> Hi all,
>>
>> This is a patch submi
On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw wrote:
>
> The header file arm_neon.h provides the Advanced SIMD intrinsics that
> are available on armv7 or later A & R profile cores. However, they
> are not compatible with M-profile and we also need to ensure that the
> FP instructions are enabled
On Thu, 6 Mar 2025 at 11:03, Christophe Lyon wrote:
>
> On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw wrote:
> >
> > The header file arm_neon.h provides the Advanced SIMD intrinsics that
> > are available on armv7 or later A & R profile cores. However, they
> > are not compatible with M-profile
We need to include in C++23 and later, so that
__pair_like_convertible_from can use __pair_like.
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h: Include .
---
Very lightly tested on x86_64-linux.
I noticed this because I wanted to use ranges::subrange in a new header
which didn't
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Wednesday, March 5, 2025 11:27 AM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; ktkac...@gcc.gnu.org
>> Subject: Re: [1/3 PATCH]AArch64: add support for partial modes to
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, March 6, 2025 10:40 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [1/3 PATCH]AArch64: add support for partial modes to last
> extractions [PR118464]
>
The recently-approved Standard Library Hardening proposal (P3471R4)
gives pop_front and pop_back member functions hardened preconditions,
but std::list was missing assertions on them. Our other sequence
containers do have assertions on those members.
libstdc++-v3/ChangeLog:
* include/bits
The following makes sure to also walk CONSTRUCTOR element indexes
which can be FIELD_DECLs, referencing otherwise unused types we
need to clean. walk_tree only walks CONSTRUCTOR element data.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress, will
push when that succeeds.
Richard.
In a '-fno-exceptions' configuration:
In file included from
../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29:
[...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void
std::__throw_format_error(const char*)’:
[...]/build-gcc/[...]/libstdc++-v3/include/format:2
On Thu, 6 Mar 2025 at 11:36, Giuseppe D'Angelo
wrote:
>
> Hi,
>
> On 06/03/2025 12:26, Jonathan Wakely wrote:
> > The old COW std::string is not usable in constant expressions, so these
> > new tests fail with -D_GLIBCXX_USE_CXX11_ABI=0.
>
> LGTM; is there a specific incantation to run the testsui
The old COW std::string is not usable in constant expressions, so these
new tests fail with -D_GLIBCXX_USE_CXX11_ABI=0.
The parts of the tests using std::string can be conditionally skipped.
libstdc++-v3/ChangeLog:
*
testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.
Hi!
Starting with r15-4225 the loop in foo1 is vectorized even at -O2 and that
implies later some small unrolling, regardless of -funroll-loops flag being
added in
#pragma GCC optimize("O3,unroll-loops")
only for foo2.
My understanding of the intent of the test was that before r12-5920 test the
ba
On 3/5/25 8:00 AM, Nathaniel Shead wrote:
Ping for this. Or should this cleanup wait till GCC16?
OK, let's go ahead with it now.
On Wed, Feb 12, 2025 at 12:49:03AM +1100, Nathaniel Shead wrote:
On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
[snip]
@@ -18486,6 +18562,12 @@
The PR claims that pair-fusion has invalid uses of gcc_assert (such that
the pass will misbehave with --disable-checking). As noted in the
comments, in the case of the calls to restrict_movement, the only way we
can possibly depend on the side effects is if we call it with a
non-singleton move ran
Hi,
On 06/03/2025 12:26, Jonathan Wakely wrote:
The old COW std::string is not usable in constant expressions, so these
new tests fail with -D_GLIBCXX_USE_CXX11_ABI=0.
LGTM; is there a specific incantation to run the testsuite with both
libstdc++ ABIs? Clearly I just tested the new one...
T
This fixes the ping-ponging of live sets in ext-dce which is left
unresolved can lead to infinite loops in the ext-dce pass as seen by the
P1 regression 119099.
At its core instead of replacing the livein set with the just recomputed
data, we IOR in the just recomputed data to the existing liv
From: Jonathan Wakely
libstdc++-v3/
* src/c++20/tzdb.cc [__GTHREADS && !__GTHREADS_CXX0X]: Use
'__gnu_cxx::__mutex'.
Co-authored-by: Thomas Schwinge
---
libstdc++-v3/src/c++20/tzdb.cc | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libst
On 2/8/25 7:32 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
On 2/7/25 9:28 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
On 1/31/25 8:46 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-
The following testcase runs into a re-gimplification issue during
inlining when processing
MEM[(struct e *)this_2(D)].a = {};
where re-gimplification does not handle assignments in the same
way than the gimplifier but instead relies on rhs_predicate_for
and gimplifying the RHS standalone. This
On Thu, 6 Mar 2025, Michal Jires wrote:
> Incremental LTO disabled cleanup of output_files since they have to
> persist in ltrans cache.
> This unintetionally also kept temporary early debug "*.debug.temp.o"
> files.
>
> Bootstrapped/regtested on x86_64-linux.
> Ok for trunk?
So are the early de
On Thu, Mar 06, 2025 at 09:50:33AM +0100, Richard Biener wrote:
> The following testcase runs into a re-gimplification issue during
> inlining when processing
>
> MEM[(struct e *)this_2(D)].a = {};
>
> where re-gimplification does not handle assignments in the same
> way than the gimplifier but
On Linux/x86_64,
e836d80374aa03a5ea5bd6cca00d826020c461da is the first bad commit
commit e836d80374aa03a5ea5bd6cca00d826020c461da
Author: Richard Sandiford
Date: Thu Mar 6 11:06:25 2025 +
ira: Add new hooks for callee-save vs spills [PR117477]
caused
FAIL: 29_atomics/atomic_flag/test
Ping^6
On 19/02/2025 12:15, Alex Coplan wrote:
> Ping^5 for patches 2-4:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.html
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672679.html
>
> On 12/02/2025
The r15-2326-gea435261ad58ea change missed a static_assert for
is_move_constructible_v in expected::value()&&. When
exceptions are enabled, the program is ill-formed if the error type is
not move constructible, because we can't construct the
std::bad_expected_access. But when using -fno-exceptions,
Hi!
On 2025-02-26T23:08:29+, Jonathan Wakely wrote:
> On Wed, 26 Feb 2025 at 20:53, Thomas Schwinge wrote:
>> On 2025-02-26T10:50:11+, Jonathan Wakely wrote:
>> > On Wed, 26 Feb 2025 at 10:47, Jonathan Wakely wrote:
>> >> On Wed, 26 Feb 2025 at 10:19, Thomas Schwinge wrote:
>> >> > In
Hi,
Since I sent the patch series for “extend counted_by attribute to pointer
fields of structure” two months ago, a lot of discussion were invoked both in
GCC community and CLANG community:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673837.html
https://discourse.llvm.org/t/rfc-enfor
Hi Andre,
Am 06.03.25 um 09:15 schrieb Andre Vehreschild:
Hi Harald,
I try to explain why I think my patch although solving the issue for this case,
does not do so in every case:
My patch lets dependency analysis figure that the two objects can not have any
dependencies on each other or memory
Hi Steve,
Am 06.03.25 um 22:32 schrieb Steve Kargl:
On Thu, Mar 06, 2025 at 10:04:08PM +0100, Harald Anlauf wrote:
this patch fixes an interesting regression that prevented substring
bounds checks from being generated if the substring start was not a
variable, but rather a constant or an expre
On 3/5/25 6:34 PM, pan2...@intel.com wrote:
From: Pan Li
The changes to vsetvl pass since 14 result in the asm check failure,
update the asm check to meet the newest behavior.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
On Wed, Mar 05, 2025 at 05:28:49PM -0500, Jason Merrill wrote:
> On 3/5/25 4:00 PM, Marek Polacek wrote:
> > On Wed, Mar 05, 2025 at 03:31:59PM -0500, Jason Merrill wrote:
> > > On 3/5/25 12:09 PM, Marek Polacek wrote:
> > > > On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
> > > > >
On Wed, 5 Mar 2025 11:43:16 +0100
Richard Biener wrote:
> > In short, despite not trying to support DESTDIR, we do anyway, by
> > happy accident. And we are now better informed.
>
> Thanks. Checking cobol-patched again I see
Hi Richard,
I have regenerated and force-pushed cobol-patched. It
On Thu, Mar 6, 2025 at 8:53 AM Jonathan Wakely wrote:
>
> LWG 4172 was approved in Hagenberg, February 2025, fixing
> std::unique_lock and std::shared_lock to work correctly for
> self-move-assignment.
>
> Our std::shared_lock was already doing the right thing (contradicting
> the standard) so jus
On Thu, Mar 6, 2025 at 6:33 AM Jonathan Wakely wrote:
>
> This destructor declaration serves no purpose, as pointed out by LWG
> 3903 which was approved at Varna, June 2023.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/span (span::~span): Remove, as per LWG 3903.
LGTM
> ---
>
> Tested x
This test fails due to duplicate explicit instantiations on targets
where size_t and unsigned int are the same type. It also fails with
-D_GLIBCXX_USE_CXX11_ABI=0 due to using std::string in constexpr
functions, and with --disable-libstdcxx-pch due to not including
for ranges::fold_left.
libstdc+
Hi!
My r15-7822 PR118787 change unfortunately broke build on x86_64-w64-mingw32.
The reduced testcase below shows what is going on.
va_list on this target is char * with extra (non-dependent) attributes
on it.
Before my r15-7822 change, instantiation of such type used the fast path and
just return
On 2/9/25 6:38 AM, Nathaniel Shead wrote:
On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
passes?
-- >8 --
There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that
While investigating PR c++/99538 I noticed two comment typos: "delared"
and "paramter". The first has a single occurrence, but the second a few
more. This patch fixes all of them.
I'll commit it as obvious.
gcc/ChangeLog:
* config/i386/x86-tune-sched.cc (ix86_fuse_mov_alu_p): Fix
Dear all,
this patch fixes an interesting regression that prevented substring
bounds checks from being generated if the substring start was not a
variable, but rather a constant or an expression.
The fix I chose turned out to be a little larger than I anticipated:
handling the case of an express
On Thu, 6 Mar 2025, Filip Kastl wrote:
> I would like to gently ping this.
Ooops, sorry.
> > + GCC now supports generating vectorized math calls to the math library
> > +from AMD Optimizing CPU Libraries (AOCL LibM). This option is available
> > +through the -mveclibabi=aocl compiler swi
On 3/5/25 7:54 AM, Nathaniel Shead wrote:
On Wed, Feb 26, 2025 at 10:29:59AM -0500, Jason Merrill wrote:
On 2/21/25 6:05 AM, Nathaniel Shead wrote:
After seeing PR c++/118964 I'm coming back around to this [1] patch
series, since it appears that this can cause errors on otherwise valid
code by
Andre,
Here's a bit of wordsmith. I removed the abbreviation "Esp."
I'm not sure if there is additional markup needed; especially,
with the "-fcoarray=single" I inserted.
Coarray support has been reworked to allow access to components
in derived types that have not been compiled with coarray
On 3/6/25 10:02 AM, Steve Kargl wrote:
Andre,
Here's a bit of wordsmith. I removed the abbreviation "Esp."
I'm not sure if there is additional markup needed; especially,
with the "-fcoarray=single" I inserted.
Coarray support has been reworked to allow access to components
in derived typ
On Thu, 6 Mar 2025 at 14:28, Thomas Schwinge wrote:
>
> In a '-fno-exceptions' configuration:
>
> In file included from
> ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29:
> [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void
> std::__throw_format_error(const
On Linux/x86_64,
de231924b73bc120bf2b7ada4eeccd884c249ee1 is the first bad commit
commit de231924b73bc120bf2b7ada4eeccd884c249ee1
Author: Giuseppe D'Angelo
Date: Thu Feb 27 22:47:27 2025 +0100
libstdc++: implement tuple protocol for std::complex (P2819R2)
caused
FAIL: 26_numerics/complex
On Thu, 6 Mar 2025 at 19:48, Jonathan Wakely wrote:
>
> On Thu, 6 Mar 2025 at 14:28, Thomas Schwinge wrote:
> >
> > In a '-fno-exceptions' configuration:
> >
> > In file included from
> > ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29:
> > [...]/build-gcc/[...]/libstdc++-v3/
Hi!
The following testcases ICE during type verification, because TYPE_FIELDS
of e.g. S RECORD_TYPE in pr119123.C is different from TYPE_FIELDS of const S.
Various decls are added to S's TYPE_FIELDS first, then finish_struct
indirectly calls fixup_type_variants to sync the variant copies.
But late
Hi!
ICE on this test was fixed by r15-2131. This just adds test for it.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2025-03-06 Jakub Jelinek
PR fortran/104826
* gfortran.dg/gomp/pr104826.f90: New test.
--- gcc/testsuite/gfortran.dg/
On Feb 11, 2025, Richard Biener wrote:
> Alex, is this OK for trunk?
>> PR middle-end/118801
>> * tree-ssa-dce.cc (eliminate_unnecessary_stmts): Prune
>> sequences of uninterrupted DEBUG BEGIN_STMTs, keeping only
>> the last of a set with unique location.
It seems like a reasonable trade-off.
Hi Qing,
Thanks for writing up the RFC and keeping us in the loop. Are you planning to
add “__self.” to GCC's C++ compiler as well in the future? The problem we have
with “__self” being a default way of annotating bounds is that C++
compatibility because bounds annotations are supposed to work
在 2025/3/7 下午2:37, Lulu Cheng 写道:
在 2025/2/14 下午8:21, Xi Ruoyao 写道:
Despite it's just a special case of "a widening product of which the
result used for reduction," having these standard names allows to
recognize the dot product pattern earlier and it may be beneficial to
optimization. Also
> > diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-
> sve.md
> > index
> a93bc463a909ea28460cc7877275fce16e05f7e6..205eeec2e35544de848e0dbb
> 48e3f5ae59391a88 100644
> > --- a/gcc/config/aarch64/aarch64-sve.md
> > +++ b/gcc/config/aarch64/aarch64-sve.md
> > @@ -3107,12
Like r5-6912-g3dbb84276aca10 but this is for the C front-end.
Basically we have an error on a return statement, we just return
error_mark_node and then the warning happens as there is no return
statement. Anyways instead mark the current function for supression
of the warning instead.
PR c
The issue is the same as 12383255fe4e82c31f5e42c72a8fbcb1b5dea35d.
Neither is .REDUC_PLUS set for V2SImode on LoongArch, so add it
to the list of targets not expecting BB vectorization.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-77.c: Add loongarch*-*-* to the list
of expected
By default, vectorization is not enabled on LoongArch,
resulting in the failure of these two test cases.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr112325.c: Add the vector compilation
option '-mlsx' for LoongArch.
* gcc.dg/vect/pr117888-1.c: Likewise.
---
gcc/testsuite/gc
在 2025/2/14 下午8:21, Xi Ruoyao 写道:
Despite it's just a special case of "a widening product of which the
result used for reduction," having these standard names allows to
recognize the dot product pattern earlier and it may be beneficial to
optimization. Also fix some test failures with the test
This option can warn about things other than string and memory functions.
Say so explicitly, and give an example. I also did some copy-editing
of the text and added some paragraph breaks.
gcc/ChangeLog
PR c/113515
* doc/invoke.texi (Warning Options): Improve -Wstringop-overflow
60 matches
Mail list logo
