On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> On Wed, Jan 15, 2025 at 10:05:35AM +0100, Richard Biener wrote:
> > > When we have return somefn (whatever); where somefn is normally tail
> > > callable and IPA-VRP determines somefn returns a singleton range, VRP
> > > just changes the IL to
> > > so
Richard Biener writes:
> [...]. It also cuts the lines down to 10 entries.
(This version doesn't ;))
>
> static int dbg_line_numbers[1267] = {
> /* 0 */ 161, 164, 173, 175, 178, 181, 183, 189, 197, 195,
> /* 10 */ 199, 201, 205, 923, 921, 2060, 2071, 2052, 2058, 2063,
> ...
>
On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> And here is incremental (for now tested just on the new testcases)
> patch to avoid VRP etc. to replace lhs of musttail call with something else.
OK.
Thanks,
Richard.
> 2025-01-15 Jakub Jelinek
>
> PR tree-optimization/118430
>
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 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:
OK with few minor comments
> This patch only support landing pad value is 1.
Should be 0?
> --- /dev/null
> +++ b/gcc/config/riscv/riscv-zicfilp.cc
> @@ -0,0 +1,169 @@
> +/* Branch Target Identification for RISCV architecture.
> + Copyright (C) 2019-2024 Free Software Foundation, Inc.
2025
>
OK with one minor comment:
> diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> index 9060c940a44..c1cfa9bf28a 100644
> --- a/gcc/config/riscv/linux.h
> +++ b/gcc/config/riscv/linux.h
> @@ -61,6 +61,8 @@ along with GCC; see the file COPYING3. If not see
> -dynamic-linker "
On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> When we have return somefn (whatever); where somefn is normally tail
> callable and IPA-VRP determines somefn returns a singleton range, VRP
> just changes the IL to
> somefn (whatever);
> return 42;
> (or whatever the value in that range is
On 64-bit capable LoongArch hardware, alsl.wu is similar to alsl.w but
zero-extending the 32-bit result.
gcc/ChangeLog:
* config/loongarch/loongarch.md (alslsi3_extend): Add alsl.wu.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/alsl_wu.c: New test.
---
gcc/config/loongarch/l
Our cost model for alsl was wrong: it matches (a + b * imm) where imm is
1, 2, 3, or 4 (should be 2, 4, 8, or 16), and it does not match
(a + (b << imm)) at all. For the test case:
a += c << 3;
b += c << 3;
it caused the compiler to perform a CSE and make one slli and two add,
but we jus
On Wed, 15 Jan 2025, Sam James wrote:
> Richard Biener writes:
>
> > [...]. It also cuts the lines down to 10 entries.
>
> (This version doesn't ;))
Yeah - the one pushed did, I failed to commit & squash that additional
change ...
Richard.
> >
> > static int dbg_line_numbers[1267] = {
> >
On Fri, 13 Dec 2024 at 14:01, Jan Hubicka wrote:
>
> Hi,
> this patch improves code generation on string constructors. We currently have
> _M_construct which takes as a parameter two iterators (begin/end pointers to
> other string) and produces new string. This patch adds special case of
> const
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 MSVC do as
well)
>>>
>
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 with /DRs/ and left out those
that just committed a testca
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 double checked the other replacements
and they are fine.
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, January 13, 2025 8:55 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-ho
On Sat, 2025-01-11 at 15:18 +, Tamar Christina wrote:
> However the same thing works for big.LITTLE as in such system the cores must
> have the same extensions otherwise it doesn't fundamentally work.
>
> i.e. task migration from one core to the other wouldn't work.
See https://gcc.gnu.org/PR
> -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
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
> Hi!
>
> Other spots in cgraphunit.cc already call bitmap_obstack_initialize (NULL);
> before running a pass list and bitmap_obstack_release (NULL); after that,
> while process_new_functions wasn't doing that and with the new r15-130
> bitmap_alloc checking that results in ICE.
>
> Fixed thusly,
The innocent looking code in the testcase failed with a
surprising 'error: could not find variant declaration'.
It turned out that calling it involves a TARGET_EXPR that
the variant-resolving/checking routine did not handle.
Comments, remarks, suggestions before I commit it?
Tobias
OpenMP/C++:
Hi!
When we have return somefn (whatever); where somefn is normally tail
callable and IPA-VRP determines somefn returns a singleton range, VRP
just changes the IL to
somefn (whatever);
return 42;
(or whatever the value in that range is). The introduction of IPA-VRP
return value tracking then
On Tue, 14 Jan 2025 at 14:11, Christophe Lyon
wrote:
>
> If the target does not support floating-point, we register FP vector
> types as 'void' (see register_vector_type).
>
> The leads to warnings about 'pure attribute on function returning
> void' when we declare the various load intrinsics beca
On Mon, 30 Dec 2024 at 02:37, Aditya K wrote:
>
> From db5036e40ed7ac43b66ca74c44ec8d0bdc934b07 Mon Sep 17 00:00:00 2001
> From: AdityaK <1108430...@users.noreply.github.com>
> Date: Sun, 29 Dec 2024 18:14:29 -0800
> Subject: [PATCH] libstdc++: Use string::push_back instead of
> string::operator+
Hi!
Other spots in cgraphunit.cc already call bitmap_obstack_initialize (NULL);
before running a pass list and bitmap_obstack_release (NULL); after that,
while process_new_functions wasn't doing that and with the new r15-130
bitmap_alloc checking that results in ICE.
Fixed thusly, bootstrapped/re
On Wed, 15 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> Other spots in cgraphunit.cc already call bitmap_obstack_initialize (NULL);
> before running a pass list and bitmap_obstack_release (NULL); after that,
> while process_new_functions wasn't doing that and with the new r15-130
> bitmap_alloc check
On Wed, Jan 15, 2025 at 10:05:35AM +0100, Richard Biener wrote:
> > When we have return somefn (whatever); where somefn is normally tail
> > callable and IPA-VRP determines somefn returns a singleton range, VRP
> > just changes the IL to
> > somefn (whatever);
> > return 42;
> > (or whatever th
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
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: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: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
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
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 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
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
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
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
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
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 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,
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
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
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
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 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
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:
> 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
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
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
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.
.../
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/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 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 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.
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
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
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
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 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
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 |
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:
> 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, 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 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
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
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
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
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 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
>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
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
> -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-
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, 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
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, 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
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
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
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 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
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
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 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
> -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
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
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. */
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/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
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/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
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 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 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, 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, 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 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
1 - 100 of 130 matches
Mail list logo
