On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> When writing the gcc-15/changes.html patch posted earlier, I've been
> wondering where significant part of the Basic asm chapter went and the
> problem was the insertion of a new @node in the middle of the Basic Asm
> @node, plus not mentioning
On Wed, 15 Jan 2025, Christoph Müllner wrote:
> As reported in PR118487, it is possible that the mask parameter
> of a __builtin_shuffle() is not a VECTOR_CST.
> If this is the case and checking is enabled then an ICE is triggered.
> Let's add a check to fix this issue.
OK.
Thanks,
Richard.
>
On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> For T with non-trivial destructors, we were destructing objects in the
> vector on release only when not using auto storage of auto_vec.
>
> The following patch calls truncate (0) instead of m_vecpfx.m_num clearing,
> and truncate takes care of
On Wed, 15 Jan 2025, Christoph Müllner wrote:
> When extracting the amount of vector elements, we currently
> first check if the value is a contant with is_constant(),
> followed by obtaining the value with to_constant(),
> which internally calls is_constant() again.
> We can address this by using
Hi Tobias,
the patch looks reasonable to me. I wouldn't know where to get the "correct"
charlen either. In fact I have the same problem at the moment with an array
spec. Anyway, one small question: Your testcase does not have a dg-do line. Is
this intentional?
Thanks for the patch,
Andre
Richard Sandiford writes:
> Tamar Christina writes:
>> Ok for master? and how do you feel about a backport for the two patches to
>> help
>> distros?
>
> Backporting to GCC 14 & GCC 13 sounds good. Not so sure about GCC 12,
> since I think we should be extra cautious with the "most stable" bran
On Wed, Jan 15, 2025 at 2:30 AM Richard Biener wrote:
>
> The following adds /* */ to dbg_line_numbers so there's the chance
> to more easily lookup the ID of the match.pd line number used for
> dumping when you want to debug a speicific replacement. It also cuts
> the lines down to 10 entries.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/118489
* config/i386/sse.md (VF1_AVX512BW): Fix typo.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr118489.c: New test.
---
gcc/config/i386/sse.md |
I agree with your point of view. Currently, there is a proposal under
discussion, and everyone tends to favor using GNU Properties.
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/417
On Wed, Jan 15, 2025 at 6:16 AM Greg McGary wrote:
> The RISCV psABI already specifies ELF attributes
On 11/29/24 2:15 AM, Stefan Schulze Frielinghaus wrote:
Ping.
On Fri, Oct 25, 2024 at 11:57:16AM +0200, Stefan Schulze Frielinghaus wrote:
This is a follow-up to
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663238.html
The primary changes are about error handling and documentati
On 1/14/25 11:14 PM, Keith Packard wrote:
lm32 is currently scheduled to be deprecated as it hasn't been converted
to use LRA instead of reload. Deprecation would happen with the gcc-15
release and removal in gcc-16 if nobody steps forward to do the
conversion.
I kinda wondered. Frankly,
On Wed, 2025-01-15 at 18:54 +, Tamar Christina wrote:
>
> Re-reading again I realize I misread cache size from your question
> with cache line size.
>
> Cache size can be whatever yes. Cache line size must match.
>
> But that doesn't change the fact that this patch is correct.
Yes it's c
From: Andi Kleen
Committed as obvious.
gcc/ChangeLog:
* config/i386/x86-tune-sched-core.cc: Fix incorrect comment.
---
gcc/config/i386/x86-tune-sched-core.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/i386/x86-tune-sched-core.cc
b/gcc/config/i386/x8
I committed the patch to trunk. Is it ok to backport to gcc-12, gcc-13, and
gcc-14?
-Original Message-
From: Richard Biener
Sent: Monday, January 13, 2025 11:22 PM
To: Eugene Rozenfeld
Cc: GCC-Patches-ML ; Jan Hubicka ;
rvmal...@amazon.com
Subject: [EXTERNAL] Re: [PATCH] Fix setting o
MIPS16e2 ASE is a superset of MIPS16e ASE, which is again a superset
of MIPS16 ASE. Later, all of them are forbidden in Release 6.
Make -mmips16e2 imply -mips16 as the ASE requires, so users won't
be surprised even if they expect it to. Meanwhile, check if
mips_isa_rev <= 5 when -mips16 is effecti
On 1/15/25 1:13 PM, Thomas Koenig wrote:
Am 09.01.25 um 14:36 schrieb Thomas Koenig:
Am 09.01.25 um 14:34 schrieb Thomas Koenig:
This patch fixes and reorganizes dumping C prototypes.
And here is the "five seconds later, I realized I had forgotten
to attach the patch" e-mail...
... with the
This patch only support landing pad value is 0.
The next version will implement function signature based labeling
scheme.
RISC-V CFI SPEC: https://github.com/riscv/riscv-cfi
gcc/ChangeLog:
* gcc/common/config/riscv/riscv-common.cc: Add ZICFILP ISA
string.
* gcc/config.gc
> On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
>> From: yxj-github-437 <2457369...@qq.com>
>>
>> This patch attempts to fix an error when build module std. The reason for the
>> error is __builrin_va_list (aka struct __va_list) is an internal linkage. so
>> attempt to handle this builtin ty
gcc/ChangeLog:
* gcc/config/riscv/riscv.cc
(is_zicfilp_p): New function.
(is_zicfiss_p): New function.
* gcc/config/riscv/riscv-zicfilp.cc: Update.
* gcc/config/riscv/riscv.h: Update.
* gcc/config/riscv/riscv.md: Update.
gcc/testsuite/ChangeLog:
gcc/ChangeLog:
* gcc/config/riscv/riscv.cc
(riscv_file_end_indicate_exec_stack): Add .note.gnu.property.
* gcc/config/riscv/linux.h (TARGET_ASM_FILE_END): Define.
libgcc/ChangeLog:
* libgcc/config/riscv/crti.S: Add lpad instructions.
* libgcc/config/riscv/cr
This patch is implemented according to the RISC-V CFI specification.
It supports the generation of shadow stack instructions in the prologue,
epilogue, non-local gotos, and unwinding.
RISC-V CFI SPEC: https://github.com/riscv/riscv-cfi
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc:
On Wed, 15 Jan 2025, David Malcolm wrote:
> I've never managed to build MetaHTML and have always just
> crossed my fingers and hoped when making edits to the GCC
> website; bin/preprocess just errors out for me immediately
> due to not finding mhc.
I think that replacing MetaHTML with a Python sc
This test should use __cpp_lib_ios_noreplace rather than the internal
__glibcxx_ios_noreplace macro.
libstdc++-v3/ChangeLog:
* testsuite/27_io/ios_base/types/openmode/case_label.cc: Use
standard feature test macro not internal one.
---
Tested x86_64-linux. Pushed to trunk.
.../
The alloc_ptr.cc test for std::set tries to use C++17 features
unconditionally, and tries to use the C++23 range members which haven't
been implemented for std::set yet.
Some of the range checks are left in place but commented out, so they
can be added after the ranges members are implemented. Oth
Sandra Loosemore wrote:
gcc/testsuite/ChangeLog
* c-c++-common/gomp/adjust-args-6.c: New.
* c-c++-common/gomp/attrs-metadirective-1.c: New.
* c-c++-common/gomp/attrs-metadirective-2.c: New.
* c-c++-common/gomp/attrs-metadirective-3.c: New.
* c-c++-common/go
On 1/15/25 2:41 PM, Andrew Pinski wrote:
This in this PR we have missed optimization where we miss that,
`1 >> x` and `(1 >> x) ^ 1` can't be equal. There are a few ways of
optimizing this, the easiest and simpliest is to simplify `1 >> x` into
just `x == 0` as those are equivalant (if we igno
On Wed, Jan 15, 2025 at 10:41:11PM +0100, Jakub Jelinek wrote:
> Hi!
>
> When writing the gcc-15/changes.html patch posted earlier, I've been
> wondering where significant part of the Basic asm chapter went and the
> problem was the insertion of a new @node in the middle of the Basic Asm
> @node,
We say 'a constant .. expression' elsewhere. Fix the grammar.
gcc/ChangeLog:
* doc/extend.texi: Add 'a' for grammar fix.
---
Committed as obvious.
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 1e1b
gcc/ChangeLog:
* doc/extend.texi: Cleanup trailing whitespace.
---
Committed as obvious.
gcc/doc/extend.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 84894efc2ea4..52ba78b80361 100644
--- a/gcc/doc/extend.te
As shown in the PR, updating the function declaration
for _gfortran_pack_char could leak into the character
typespec back-end declaration to the the caller by
setting the backend declaration of the caller.
The problem is that that function returns a character string
and in trans-intrinsic.cc, we
The heading elements in our website contain "id" information,
but currently to find them you to look at the page source,
whereas in the generated HTML for the manual we have e.g.:
¶
which shows up nicely in the browser in e.g.
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
as a pilcrow c
On Wed, Jan 15, 2025 at 04:48:59PM -0500, Jason Merrill wrote:
> > --- a/gcc/cp/decl.cc
> > +++ b/gcc/cp/decl.cc
> > @@ -11686,6 +11686,7 @@ fold_sizeof_expr (tree t)
> > false, false);
> > if (r == error_mark_node)
> > r = size_one_node;
> > + r = cp_fold
On 11/29/24 9:33 AM, Simon Martin wrote:
We currently ICE upon the following code, that is valid under
-Wno-pointer-arith:
=== cut here ===
int main() {
decltype( [](auto) { return sizeof(void); } ) x;
return x.operator()(0);
}
=== cut here ===
The problem is that "fold_sizeof_expr (sizeo
On 12/12/24 2:07 PM, Simon Martin wrote:
We currently ICE upon the following valid (under -Wno-vla) code
=== cut here ===
void f(int c) {
constexpr int r = 4;
[&](auto) { int t[r * c]; }(0);
}
=== cut here ===
The problem is that when parsing the lambda body, and more specifically
the mul
Hi!
When writing the gcc-15/changes.html patch posted earlier, I've been
wondering where significant part of the Basic asm chapter went and the
problem was the insertion of a new @node in the middle of the Basic Asm
@node, plus not mentioning the new @node in the @menu. So the asm constexpr
node
This in this PR we have missed optimization where we miss that,
`1 >> x` and `(1 >> x) ^ 1` can't be equal. There are a few ways of
optimizing this, the easiest and simpliest is to simplify `1 >> x` into
just `x == 0` as those are equivalant (if we ignore out of range values for x).
we already have
On Wed, Jan 15, 2025 at 10:27:56AM -0500, Jason Merrill wrote:
> > @@ -7432,12 +7426,18 @@ reshape_init_r (tree type, reshape_iter
> > {
> > vec *v = 0;
> > CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, init);
> > - tree raw_init = cp_maybe_split_raw_data (d);
> > + bool inc_cur;
>
libstdc++-v3/ChangeLog:
PR libstdc++/109849
* include/bits/vector.tcc (vector::_M_range_insert): Fix
reversed args in length calculation.
---
Tested x86_64-linux, pushed to trunk. Backport to gcc-14 to follow after
testing.
libstdc++-v3/include/bits/vector.tcc | 2 +-
1
Hi!
For T with non-trivial destructors, we were destructing objects in the
vector on release only when not using auto storage of auto_vec.
The following patch calls truncate (0) instead of m_vecpfx.m_num clearing,
and truncate takes care of that destruction:
unsigned l = length ();
gcc_checki
Hi!
This is something we should have done when -std=c++23 was made the
primary option and -std=c++2b turned into undocumented alias.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-15 Jakub Jelinek
gcc/cp/
* parser.cc (cp_parser_lambda_declarator_opt,
On 1/15/25 10:13 AM, Patrick Palka wrote:
On Mon, 1 May 2023, Jason Merrill wrote:
On 4/28/23 15:40, Patrick Palka wrote:
On Fri, 28 Apr 2023, Patrick Palka wrote:
On Fri, 28 Apr 2023, Patrick Palka wrote:
After mechanically replacing RESULT_DECL within a constexpr call result
(for sake of R
On 1/15/25 10:19 AM, yxj-github-437 wrote:
On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
From: yxj-github-437 <2457369...@qq.com>
This patch attempts to fix an error when build module std. The reason for the
error is __builrin_va_list (aka struct __va_list) is an internal linkage. so
att
On 1/15/25 12:55 PM, Marek Polacek wrote:
On Wed, Jan 15, 2025 at 09:39:41AM -0500, Jason Merrill wrote:
On 11/15/24 9:08 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
The error here should also check that we aren't nested in another
lambda; in
Am 09.01.25 um 14:36 schrieb Thomas Koenig:
Am 09.01.25 um 14:34 schrieb Thomas Koenig:
This patch fixes and reorganizes dumping C prototypes.
And here is the "five seconds later, I realized I had forgotten
to attach the patch" e-mail...
... with the original text:
Hello world,
This patch
On Mon, 23 Dec 2024 at 01:56, Gerald Pfeifer wrote:
>
> On Wed, 9 Oct 2024, Jonathan Wakely wrote:
> > How about this?
> >
> > +C
> > +
> > +New options -std=c17, to select support for the 2018
> > +edition of the ISO C standard, and -std=gnu17, for C17
> > +with GNU extensions.
> > +
On Wed, 2025-01-15 at 18:22 +, Joseph Myers wrote:
> On Wed, 15 Jan 2025, David Malcolm wrote:
>
> > Here's an updated version of the patch
> >
> > OK to push? (we could tweak it in followups)
>
> This will need updating to work together with Jakub's patch that also
> adds
> the C section t
On 1/8/2025 11:13 AM, Richard Sandiford wrote:
writes:
This patch introduces support for LUTI2/LUTI4 ACLE for SVE2.
LUTI instructions are used for efficient table lookups with 2-bit
or 4-bit indices. LUTI2 reads indexed 8-bit or 16-bit elements from
the low 128 bits of the table vector usin
This patch introduces support for LUTI2/LUTI4 ACLE for SVE2.
LUTI instructions are used for efficient table lookups with 2-bit
or 4-bit indices. LUTI2 reads indexed 8-bit or 16-bit elements from
the low 128 bits of the table vector using packed 2-bit indices,
while LUTI4 can read from the low 128
My tests showed the removal of internal uses of from
stdlibc++ usually manifests in complaints about unqualified types like
"uint8_t", rather than "std::uint8_t" (and unfortunately the fix-it
hint gets this wrong; see PR c++/110930).
I've taken the liberty of pushing this patch to the website to
On Wed, 2025-01-15 at 18:25 +, Joseph Myers wrote:
> On Wed, 15 Jan 2025, David Malcolm wrote:
>
> > +
> > + In C99 and later you can use #include
> >
> > + which provides a definition of bool compatible with
> > C23.
> > +
> > + Note that the bool type is not the same
> > + as
On Wed, 2025-01-15 at 18:22 +, Joseph Myers wrote:
> On Wed, 15 Jan 2025, David Malcolm wrote:
>
> > Here's an updated version of the patch
> >
> > OK to push? (we could tweak it in followups)
>
> This will need updating to work together with Jakub's patch that also
> adds
> the C section t
As reported in PR118487, it is possible that the mask parameter
of a __builtin_shuffle() is not a VECTOR_CST.
If this is the case and checking is enabled then an ICE is triggered.
Let's add a check to fix this issue.
PR tree-optimization/118487
gcc/ChangeLog:
* tree-ssa-forwprop.
When extracting the amount of vector elements, we currently
first check if the value is a contant with is_constant(),
followed by obtaining the value with to_constant(),
which internally calls is_constant() again.
We can address this by using is_constant (T*), which also
provides the constant value
Sandra Loosemore wrote:
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
LGTM.
Thanks,
Tobias
gcc/cp/ChangeLog
PR middle-end/112779
PR middle-end/113904
* cp-tree.h (struct saved_scope): Add new field
x_processing_omp_trait
Dear all,
I've committed the attached obvious patch to reject an invalid NULL
in ALLOCATE after it was OK'ed in the PR by Steve.
Regtested on x86_64-pc-linux-gnu. Pushed as r15-6925-g892304f1fe .
Thanks,
Harald
From 892304f1fe3e808b9f498353c144f1ae0591 Mon Sep 17 00:00:00 2001
From: H
Sandra Loosemore wrote:
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target tra
Re-reading again I realize I misread cache size from your question with cache
line size.
Cache size can be whatever yes. Cache line size must match.
But that doesn't change the fact that this patch is correct.
Thanks,
Tamar
From: Tamar Christina
Sent: Wednesday
On Wed, Jan 15, 2025 at 04:33:26PM +0100, Jakub Jelinek wrote:
> I vaguely remember from writing the original patch (which introduced
> cp_maybe_split_raw_data) that here it actually mattered whether
> in the error case we move the reshape_iter or not and that it broke
> some tests, but I no longer
On Wed, 15 Jan 2025, David Malcolm wrote:
> +
> + In C99 and later you can use #include
> + which provides a definition of bool compatible with C23.
> +
> + Note that the bool type is not the same
> + as int at ABI level, and so care may be needed porting
> + declarations that app
On Wed, 15 Jan 2025, David Malcolm wrote:
> Here's an updated version of the patch
>
> OK to push? (we could tweak it in followups)
This will need updating to work together with Jakub's patch that also adds
the C section to changes.html.
> +Function declarations without
> parameters
> +
> +
On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> The following patch attempts to document in similar style to last years
> new C++23/26 papers and DRs implemented in GCC 15 (for
> the papers I've used https://gcc.gnu.org/projects/cxx-status.html
> as source, for DRs skimmed gcc-cvs commits wit
On Wed, Jan 15, 2025 at 09:39:41AM -0500, Jason Merrill wrote:
> On 11/15/24 9:08 AM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > The error here should also check that we aren't nested in another
> > lambda; in it, at_function_scope_p(
> On 14 Jan 2025, at 20:45, Iain Buclaw wrote:
>
> Excerpts from Iain Sandoe's message of Januar 14, 2025 9:10 pm:
>> Tested on x86_64, i686 darwin17 and aarch64 darwin21,
>> OK for trunk, or alternate solution?
>> thanks,
>> Iain
>>
> Could a pull request be made upstream here?
>
> https:/
OK to push?
---
htdocs/gcc-15/porting_to.html | 28
1 file changed, 28 insertions(+)
diff --git a/htdocs/gcc-15/porting_to.html b/htdocs/gcc-15/porting_to.html
index 385fa141..53512250 100644
--- a/htdocs/gcc-15/porting_to.html
+++ b/htdocs/gcc-15/porting_to.html
@@
On 1/10/25 6:46 AM, Jakub Jelinek wrote:
Hi!
The following patch on top of
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673177.html
(in review currently)
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672055.html
(acked but waiting for the former)
https://gcc.gnu.org/pipermail
Wilco Dijkstra writes:
> Hi Richard,
>
>> Sorry to be awkward, but I don't think we should put
>> AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT in base.
>> CHEAP_SHIFT_EXTEND is a good base flag because it means we can make full
>> use of a certain group of instructions. FULLY_PIPELINED_FMA simila
On 1/15/25 9:43 AM, Jason Merrill wrote:
On 11/25/24 4:46 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
In a template, for
union {
union {
T d;
};
};
build_anon_union_vars crates a malformed COMPONENT_REF: we have no
D
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, January 15, 2025 3:23 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: have -mcpu=native detect architecture extensions
> for unknown non-
Wilco Dijkstra writes:
> ping
>
>
> Add FULLY_PIPELINED_FMA to tune baseline - this is a generic feature that is
> already enabled for some cores, but benchmarking it shows it is faster on all
> modern cores (SPECFP improves ~0.17% on Neoverse V1 and 0.04% on Neoverse N1).
>
> Passes regress & b
On Mon, 2024-12-09 at 20:58 +0100, Jakub Jelinek wrote:
> On Mon, Dec 09, 2024 at 02:44:42PM -0500, David Malcolm wrote:
> > +C23 brings the following changes:
> > +
> > +Function prototypes
> > with empty params change from implicit int to
> > void
> > +
> > + In C23 () in a function declaration m
Richard Biener writes:
> The following addresses the fact that with loop masking (or regular
> mask loads) we do not implement load shortening but we override
> the case where we need that for correctness. Likewise when we
> attempt to use loop masking to handle large trailing gaps we cannot
> do
Thanks! Added changelog and Pushed!
On 14-10-2024 19:08, Cupertino Miranda wrote:
On 30-09-2024 18:47, David Faust wrote:
On 9/27/24 09:49, Cupertino Miranda wrote:
CO-RE accesses with non pointer struct variables will also generate a
"0" string access within the CO-RE relocation.
The firs
Thanks! Added changelog and Pushed!
On 30-09-2024 18:39, David Faust wrote:
On 9/27/24 09:49, Cupertino Miranda wrote:
When traversing gimple to introduce CO-RE relocation entries to
expressions that are accesses to attributed perserve_access_index types,
the access is likely to be split in m
Thanks! Added changelog and Pushed!
On 15-10-2024 19:51, David Faust wrote:
On 10/14/24 11:04, Cupertino Miranda wrote:
Hi everyone,
Here is the v2 for the patch in this thread:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665378.html
Please noticed that commit message was adapte
On 1/3/25 3:52 AM, Jakub Jelinek wrote:
Hi!
As the following testcases show (mangle80.C only after reversion of the
temporary reversion of C++ large array speedup commit), RAW_DATA_CST can
be seen during mangling of some templates and we ICE because
the mangler doesn't handle it.
The following
On Wed, Jan 15, 2025 at 10:27:56AM -0500, Jason Merrill wrote:
> > @@ -7432,12 +7426,18 @@ reshape_init_r (tree type, reshape_iter
> > {
> > vec *v = 0;
> > CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, init);
> > - tree raw_init = cp_maybe_split_raw_data (d);
> > + bool inc_cur;
>
On 1/2/25 4:28 AM, Jakub Jelinek wrote:
Hi!
The embed-17.C testcase is miscompiled and pr118214.C testcase used to be
miscompiled on the trunk before I've temporarily reverted the
r15-6339 C++ large initializer speed-up commit in r15-6448.
The problem is that reshape_* is only sometimes allowed
Tamar Christina writes:
> Ok for master? and how do you feel about a backport for the two patches to
> help
> distros?
Backporting to GCC 14 & GCC 13 sounds good. Not so sure about GCC 12,
since I think we should be extra cautious with the "most stable" branch,
but let's see what others think.
>On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
>> From: yxj-github-437 <2457369...@qq.com>
>>
>> This patch attempts to fix an error when build module std. The reason for the
>> error is __builrin_va_list (aka struct __va_list) is an internal linkage. so
>> attempt to handle this builtin typ
On Wed, Jan 15, 2025 at 03:17:22PM +0100, Richard Biener wrote:
> On Wed, 15 Jan 2025, Jakub Jelinek wrote:
>
> > On Wed, Jan 15, 2025 at 11:46:28AM +0100, Jakub Jelinek wrote:
> > > BTW, I think we don't optimize returns-arg stuff like that at least right
> > > now, and if we did, it wouldn't be
On Mon, 1 May 2023, Jason Merrill wrote:
> On 4/28/23 15:40, Patrick Palka wrote:
> > On Fri, 28 Apr 2023, Patrick Palka wrote:
> >
> > > On Fri, 28 Apr 2023, Patrick Palka wrote:
> > >
> > > > After mechanically replacing RESULT_DECL within a constexpr call result
> > > > (for sake of RVO), we
On Wed, Jan 15, 2025 at 03:16:04PM +0100, Richard Biener wrote:
> > + /* If IPA-VRP proves called function always returns a singleton
> > range,
> > +the return value is replaced by the only value in that range.
> > +For tail call purposes, pretend such replacement didn't happen. */
On 1/15/25 7:24 AM, Simon Martin wrote:
Hi,
On 14 Jan 2025, at 23:31, Jason Merrill wrote:
On 1/14/25 2:13 PM, Simon Martin wrote:
On 10 Jan 2025, at 19:10, Andrew Pinski wrote:
On Fri, Jan 10, 2025 at 3:18 AM Simon Martin
wrote:
We currently accept the following invalid code (EDG and MSV
On 12/20/24 12:53 PM, Marek Polacek wrote:
On Fri, Dec 20, 2024 at 12:51:02PM -0500, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Compiling this test, we emit:
error: 'static void CW::operator=(int) requires
requires(typename'decltype_type' not
Hello,
On Mon, 23 Dec 2024, Robert Dubner wrote:
> > +static tree
> > +gg_get_larger_type(tree A, tree B)
> > + {
> > + tree larger = TREE_TYPE(B);
> > + if( TYPE_SIZE(TREE_TYPE(A)) > TYPE_SIZE(TREE_TYPE(B)) )
> > +{
> > +larger = TREE_TYPE(A);
> >
> > that doesn't work - TYPE_SIZE is
> -Original Message-
> From: Xi Ruoyao
> Sent: Wednesday, January 15, 2025 1:40 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> ktkac...@gcc.gnu.org; Richard Sandiford
> Subject: Re: [PATCH]AArch64: have -mcpu=native detect architecture extensions
> for
On 11/25/24 4:46 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
In a template, for
union {
union {
T d;
};
};
build_anon_union_vars crates a malformed COMPONENT_REF: we have no
DECL_NAME for the nested anon union so we c
On 11/15/24 9:08 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
The error here should also check that we aren't nested in another
lambda; in it, at_function_scope_p() will be false.
PR c++/117602
gcc/cp/ChangeLog:
* parser.cc (cp
libstdc++-v3/ChangeLog:
* testsuite/28_regex/traits/char/transform_primary.cc: Fix
subclause numbering in references to the standard.
---
Pushed to trunk.
.../testsuite/28_regex/traits/char/transform_primary.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
dif
Sandra Loosemore wrote:
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
LGTM – thanks for the patch!
Tobias
gcc/c-family/ChangeLog
PR middle-end/112779
PR middle-end/113904
* c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_ME
On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> On Wed, Jan 15, 2025 at 10:42:12AM +0100, Richard Biener wrote:
> > Yes. I'll note there's a PR (or a bunch of) which are about
> >
> > x = FOO (y, ..);
> >
> >
> > vs.
> >
> > FOO (y, ..);
> >
> >
> > for FOO returning an argument (like for examp
On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> On Wed, Jan 15, 2025 at 11:46:28AM +0100, Jakub Jelinek wrote:
> > BTW, I think we don't optimize returns-arg stuff like that at least right
> > now, and if we did, it wouldn't be through IPA-VRP, most of the returns-arg
> > functions actually return a p
Ping
> -Original Message-
> From: Alex Coplan
> Sent: Monday, January 6, 2025 11:35 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Biener ; Jan Hubicka ; Tamar
> Christina
> Subject: [PATCH 3/4] vect: Ensure profile consistency when adding epilog guard
> [PR117790]
>
> This patch tries
Ping
> -Original Message-
> From: Alex Coplan
> Sent: Monday, January 6, 2025 11:35 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Biener ; Jan Hubicka ; Tamar
> Christina
> Subject: [PATCH 2/4] cfgloopmanip: Add infrastructure for scaling of
> multi-exit
> loops [PR117790]
>
> As it s
Ping
> -Original Message-
> From: Alex Coplan
> Sent: Monday, January 6, 2025 11:36 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Biener ; Jan Hubicka ; Tamar
> Christina
> Subject: [PATCH 4/4] vect: Fix scale_profile_for_vect_loop for multiple exits
> [PR117790]
>
> This adjusts scale
Ping
> -Original Message-
> From: Alex Coplan
> Sent: Monday, January 6, 2025 11:34 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Biener ; Jan Hubicka ; Tamar
> Christina
> Subject: [PATCH 1/4] vect: Set counts of early break exit blocks correctly
> [PR117790]
>
> This adds missing cod
On 1/14/25 9:46 PM, Patrick Palka wrote:
On Tue, 14 Jan 2025, Jason Merrill wrote:
On 1/10/25 1:36 PM, Patrick Palka wrote:
On Tue, 1 Oct 2024, Patrick Palka wrote:
On Mon, 16 Sep 2024, Patrick Palka wrote:
On Thu, 30 Nov 2023, Patrick Palka wrote:
On Fri, 3 Nov 2023, Patrick Palka wrote:
On Wed, 2025-01-15 at 13:34 +, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Xi Ruoyao
> > Sent: Wednesday, January 15, 2025 1:29 PM
> > To: Tamar Christina ; gcc-patches@gcc.gnu.org
> > Cc: nd ; Richard Earnshaw ;
> > ktkac...@gcc.gnu.org; Richard Sandiford
> > Subjec
On Wed, 15 Jan 2025, Tamar Christina wrote:
> Hi All,
>
> In g:3c32575e5b6370270d38a80a7fa8eaa144e083d0 I made a mistake and incorrectly
> replaced the type of the arguments of an expression with the type of the
> expression. This is of course wrong.
>
> This reverts that change and I have also
> -Original Message-
> From: Xi Ruoyao
> Sent: Wednesday, January 15, 2025 1:29 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> ktkac...@gcc.gnu.org; Richard Sandiford
> Subject: Re: [PATCH]AArch64: have -mcpu=native detect architecture extensions
> fo
1 - 100 of 130 matches
Mail list logo
