This was added when invariants/externals outside of SLP didn't have
an easily accessible vector type. Now it's redundant so the
following removes it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vectorizer.h (stmt_vec_info_::reduc_vectype_in): Remove.
(STMT
On Mon, Aug 18, 2025 at 4:52 PM Hongtao Liu wrote:
>
> On Mon, Aug 11, 2025 at 8:57 PM Richard Biener wrote:
> >
> > On Sun, 10 Aug 2025, liuhongt wrote:
> >
> > > >
> > > > The comment doesn't match the bool type.
> > > >
> > > Fixed.
> > >
> > > >
> > > > is_gimple_assign (stmt_info->stmt)
> >
The __attribute__((__copy__)) functionality was crashing when copying
sanitizer-related attributes because these attributes violated the standard
GCC attribute infrastructure by storing INTEGER_CST values directly instead
of wrapping them in TREE_LIST like all other attributes.
Wrap sanitizer attr
On Mon, Aug 25, 2025 at 08:24:20PM +, Qing Zhao wrote:
> Hi, Kees,
>
> Is this patch for GCC14? I noticed that some codes have been changed in the
> latest trunk GCC already.
Oh, I may be a bit behind. My base commit was
3e4ced9de1f1c6444eae44c1fed493742c345bc6 (Aug 1st).
I will rebase...
On Mon, Aug 25, 2025 at 9:51 PM Sam James wrote:
>
> "H.J. Lu" writes:
>
> > PR tree-optimization/121656
> > * gcc.dg/pr121656.c: New file.
> >
> > Signed-off-by: H.J. Lu
> > ---
> > gcc/testsuite/gcc.dg/pr121656.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
"H.J. Lu" writes:
> PR tree-optimization/121656
> * gcc.dg/pr121656.c: New file.
>
> Signed-off-by: H.J. Lu
> ---
> gcc/testsuite/gcc.dg/pr121656.c | 21 +
> 1 file changed, 21 insertions(+)
> create mode 100644 gcc/testsuite/gcc.dg/pr121656.c
>
> diff --git a/g
The ARC builtin functions __builtin_arc_ffs and __builtin_arc_fls
perform pure mathematical operations equivalent to the standard
GCC __builtin_ffs function, which is marked with the const attribute.
However, the ARC target-specific versions were not marked as const,
preventing compiler optimizatio
On Tue, Aug 26, 2025 at 9:38 AM Andi Kleen wrote:
>
> From: Andi Kleen
>
> Make the expand pattern for operand 1 match the final instruction.
>
> PR 121658
>
> gcc/ChangeLog:
>
> * config/i386/sse.md ("3"): Use
> register_operand for rotate patterns.
>
> gcc/testsuite/Chan
On 8/25/25 00:13, Jakub Jelinek wrote:
Yes, GCC doesn't have it implemented fully, but that doesn't mean it should
be ripped off, the implementation should be simply finished.
Well, I have no idea how to make this work, nor any enthusiasm for
devoting a big block of time to this. So I've take
From: Andi Kleen
Make the expand pattern for operand 1 match the final instruction.
PR 121658
gcc/ChangeLog:
* config/i386/sse.md ("3"): Use
register_operand for rotate patterns.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr121658.c: New test.
---
gcc/config/
Ping
在 2025/8/21 下午8:37, Zhou Zhao 写道:
This patch is a respond of the patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673051.html
as some suggestion by Richard Biener, I have adopted these suggestions
and regenerated the patch.
In the 538.imagick_r benchmark of Spec2017,
On Tue, Aug 26, 2025 at 6:40 AM Jakub Jelinek wrote:
>
> Hi!
>
> The vgf2p8affineqb_ pattern uses "register_operand"
> predicate for the first input operand, so using "general_operand"
> for the rotate operand passed to it leads to ICEs, and so does
> the "nonimmediate_operand" in the v16qi3 defin
On 8/25/25 9:00 AM, Yoshinori Sato wrote:
The problem was caused by an erroneous note about creating a stack frame,
which caused the cur_cfa reg to fail to assert with a value other than
the frame pointer.
This fix will generate notes that correctly update cur_cfa.
gcc/config/rx/
* r
Hi!
The vgf2p8affineqb_ pattern uses "register_operand"
predicate for the first input operand, so using "general_operand"
for the rotate operand passed to it leads to ICEs, and so does
the "nonimmediate_operand" in the v16qi3 define_expand.
The following patch fixes it by using "register_operand"
Hi!
When expand_omp_for_init_counts is called from expand_omp_for_generic,
zero_iter1_bb is NULL and the code always creates a new bb in which it
clears fd->loop.n2 var (if it is a var), because it can dominate code
with lastprivate guards that use the var.
When called from other places, zero_iter
On Mon, Aug 25, 2025 at 03:49:56PM -0400, Jason Merrill wrote:
> On 8/25/25 10:53 AM, Jakub Jelinek wrote:
> > On Mon, Aug 25, 2025 at 09:44:29AM -0400, Jason Merrill wrote:
> > > > --- gcc/cp/pt.cc.jj 2025-08-23 15:00:04.262787988 +0200
> > > > +++ gcc/cp/pt.cc2025-08-23 15:51:08.72608
Hi, Kees,
Is this patch for GCC14? I noticed that some codes have been changed in the
latest trunk GCC already.
> On Aug 25, 2025, at 11:59, Kees Cook wrote:
>
> The __attribute__((__copy__)) functionality was crashing when copying
> sanitizer-related attributes because these attributes viola
When translating type bit sizes from DWARF, ctf_die_bitsize was
using uint32_t. For extremely large struct types, the bit size may be
larger than 32-bits and hence truncated, which caused incorrect encoding
for these huge structs rather than properly using CTF's large type size
encoding. Switchin
On 8/25/25 12:02 PM, Jakub Jelinek wrote:
On Mon, Aug 25, 2025 at 11:55:24AM -0400, Patrick Palka wrote:
The following patch fixes that by testing DECL_TEMPLATE_INFO, dunno
what else would be more appropriate for this function is a template,
maybe decl_dependent_p?
I was going to suggest just
On 8/25/25 10:53 AM, Jakub Jelinek wrote:
On Mon, Aug 25, 2025 at 09:44:29AM -0400, Jason Merrill wrote:
--- gcc/cp/pt.cc.jj 2025-08-23 15:00:04.262787988 +0200
+++ gcc/cp/pt.cc2025-08-23 15:51:08.726081054 +0200
@@ -22321,6 +22321,13 @@ tsubst_expr (tree t, tree args, tsubst_f
On 8/25/25 10:33, Indu Bhagat wrote:
> On 8/25/25 8:08 AM, David Faust wrote:
>>
>>
>> On 8/22/25 23:49, Indu Bhagat wrote:
>>> On 8/6/25 9:26 AM, David Faust wrote:
CTF array encoding uses uint32 for number of elements. This means there
is a hard upper limit on array types which the
Hi Tobias,
I addressed some review comments and included additional feedback.
On 8/22/2025 11:22 PM, Tobias Burnus wrote:
Hi Yuao,
Yuao Ma wrote:
Hi Paul,
On 7/31/2025 6:02 AM, Paul Richard Thomas wrote:
That's exactly how I had a mind to do it. You beat me to it 🙁
Just get on, polish the
On Mon, Aug 25, 2025 at 06:43:11PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 25, 2025 at 10:23:52AM -0600, Sandra Loosemore wrote:
> > On 8/25/25 09:29, Jakub Jelinek wrote:
> > > On Mon, Aug 25, 2025 at 09:13:58AM -0600, Sandra Loosemore wrote:
> > > > How? Declare variant substitution presently
On 8/25/25 8:08 AM, David Faust wrote:
On 8/22/25 23:49, Indu Bhagat wrote:
On 8/6/25 9:26 AM, David Faust wrote:
CTF array encoding uses uint32 for number of elements. This means there
is a hard upper limit on array types which the format can represent.
Hi David,
Thanks for the patch.
On Mon, Aug 25, 2025 at 10:23:52AM -0600, Sandra Loosemore wrote:
> On 8/25/25 09:29, Jakub Jelinek wrote:
> > On Mon, Aug 25, 2025 at 09:13:58AM -0600, Sandra Loosemore wrote:
> > > How? Declare variant substitution presently happens primarily during
> > > gimplification which is way before any v
Hi David,
This LGTM. Good catch!
Bruce McCulloch
On 8/6/25 9:26 AM, David Faust wrote:
CTF array encoding uses uint32 for number of elements. This means there
is a hard upper limit on array types which the format can represent.
GCC internally was also using a uint32_t for this, which would o
On 8/25/25 09:29, Jakub Jelinek wrote:
On Mon, Aug 25, 2025 at 09:13:58AM -0600, Sandra Loosemore wrote:
How? Declare variant substitution presently happens primarily during
gimplification which is way before any vectorization happens. And fixing
the various bugs esp in the C++ front end with
On Sun, Aug 24, 2025, at 12:33 PM, Joseph Myers wrote:
> On Thu, 21 Aug 2025, Pietro Monteiro wrote:
>
>> Both GCC and binutils/gdb trees do not use any of the macros defined
>> in these files. Removing them from both trees and regenerating the
>> build scripts results in no diff.
>
> Can you conf
On Mon, Aug 25, 2025 at 11:55:24AM -0400, Patrick Palka wrote:
> > The following patch fixes that by testing DECL_TEMPLATE_INFO, dunno
> > what else would be more appropriate for this function is a template,
> > maybe decl_dependent_p?
>
> I was going to suggest just replacing the !processing_temp
The __attribute__((__copy__)) functionality was crashing when copying
sanitizer-related attributes because these attributes violated the standard
GCC attribute infrastructure by storing INTEGER_CST values directly instead
of wrapping them in TREE_LIST like all other attributes.
Wrap sanitizer attr
On Mon, 25 Aug 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs during expansion, because cfun->returns_struct
> wasn't cleared, despite auto being deduced to int.
>
> The problem is that check_return_type -> apply_deduced_return_type
> is called when parsing the expansion stmt b
On Mon, Aug 25, 2025 at 05:29:13PM +0200, Jakub Jelinek wrote:
> That is not what should be done. The lookup should be done at the declare
> variant declaration side, that is how the design has been since that
> meeting. The compiler records the variants and later on just picks from
> that list o
On Mon, Aug 25, 2025 at 09:13:58AM -0600, Sandra Loosemore wrote:
> If it has always been the intent that "declare variant" substitution should
> do this SIMD replacement directly rather than it being a separate
> transformation, can you come up with some references that say this, or code
> example
PR tree-optimization/121656
* gcc.dg/pr121656.c: New file.
Signed-off-by: H.J. Lu
---
gcc/testsuite/gcc.dg/pr121656.c | 21 +
1 file changed, 21 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/pr121656.c
diff --git a/gcc/testsuite/gcc.dg/pr121656.c b/g
On 8/25/25 00:13, Jakub Jelinek wrote:
On Sun, Aug 24, 2025 at 08:16:32PM -0600, Sandra Loosemore wrote:
As noted in PR middle-end/121630, GCC seems to think that the "simd"
construct selector on "declare variant" implies that the variant
function accepts vectorized arguments, although this is n
On 8/22/25 23:49, Indu Bhagat wrote:
> On 8/6/25 9:26 AM, David Faust wrote:
>> CTF array encoding uses uint32 for number of elements. This means there
>> is a hard upper limit on array types which the format can represent.
>>
>
> Hi David,
>
> Thanks for the patch.
>
> Few nits. But otherwi
On Sun, Aug 24, 2025 at 2:31 PM Takayuki 'January June' Suwa
wrote:
>
> The use of compact syntax makes the relationship between asm output,
> operand constraints, and insn attributes easier to understand and modify,
> especially for "mov_internal".
>
> gcc/ChangeLog:
>
> * config/xtensa/x
The problem was caused by an erroneous note about creating a stack frame,
which caused the cur_cfa reg to fail to assert with a value other than
the frame pointer.
This fix will generate notes that correctly update cur_cfa.
gcc/config/rx/
* rx.cc (add_pop_cfi_notes): Release the frame poi
On Mon, Aug 25, 2025 at 09:44:29AM -0400, Jason Merrill wrote:
> > --- gcc/cp/pt.cc.jj 2025-08-23 15:00:04.262787988 +0200
> > +++ gcc/cp/pt.cc2025-08-23 15:51:08.726081054 +0200
> > @@ -22321,6 +22321,13 @@ tsubst_expr (tree t, tree args, tsubst_f
> > if (DECL_NAME (t) == this_identi
Thanks Piyush.
> Hi Jose,
>
> Thank you for the edit permission.
> I’ve updated the branch name in my repository to a clearer one and
> also updated the wiki. I’ll continue making edits to add more details
> about the tool.
>
> Best regards,
> Piyush
>
>
> On Tue, 19 Aug 2025 at 23:01, Jose E. M
On 8/23/25 2:34 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to introduce the combine of vec_dup + vmacc.vv
into vmacc.vx on the cost value of GR2VR. The late-combine will take
place if the cost of GR2VR is zero, or reject the combine if non-zero
like 1, 2, 15 in test.
F
> On Aug 25, 2025, at 04:13, Peter Zijlstra wrote:
>
> On Fri, Aug 22, 2025 at 03:29:11PM -0700, Kees Cook wrote:
>> On Fri, Aug 22, 2025 at 08:29:16PM +, Qing Zhao wrote:
On Aug 22, 2025, at 15:02, Kees Cook wrote:
Right, and sometimes we have to explicitly perform a no-op
On 8/25/25 2:52 AM, Jakub Jelinek wrote:
Hi!
The following testcase shows an ICE when a parameter of a non-template
function is referenced in expansion stmt body.
tsubst_expr in that case assumes that either the PARM_DECL has registered
local specialization, or is this argument or it is in unev
Hi Jennifer,
> On 25 Aug 2025, at 12:56, Jennifer Schmitz wrote:
>
> When op2 in SVE2 saturating add intrinsics (svuqadd, svsqadd) is a zero
> vector and predication is _z, an ICE in vregs occurs, e.g. for
>
> svuint8_t foo (svbool_t pg, svuint8_t op1)
> {
>return svsqadd_u8_z (pg, op1, svd
On 8/25/25 2:56 AM, Jakub Jelinek wrote:
Hi!
The following patch implements the proposed resolution of
https://cplusplus.github.io/CWG/issues/3048.html
Instead of rejecting structured binding size it just builds a normal
decl rather than structured binding declaration.
Bootstrapped/regtested on
>>/* Check error recovery for -fsanitize-recover option. */
>>for (int i = 0; sanitizer_opts[i].name != NULL; ++i)
>> if ((opts->x_flag_sanitize_recover & sanitizer_opts[i].flag)
>> @@ -2300,7 +2319,8 @@ parse_sanitizer_options (const char *p, location_t
>> loc, int scode,
>>
On Thu, Jun 26, 2025 at 3:32 PM H.J. Lu wrote:
>
> On Thu, May 8, 2025 at 11:11 AM H.J. Lu wrote:
> >
> > Conditional and unconditional branch targets can be either a label or
> > a symbol. For conditional jump:
> >
> > (jump_insn 7 6 14 2 (set (pc)
> > (if_then_else (eq (reg:CCZ 17 flag
On 8/25/25 2:48 AM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because the
/* Check we aren't dereferencing a null pointer when calling a non-static
member function, which is undefined behaviour. */
if (i == 0 && DECL_OBJECT_MEMBER_FUNCTION_P (fun)
On 8/23/25 1:24 AM, Eczbek wrote:
From 0210a1a410cfafd79521e15cd96682ed3d5b4943 Mon Sep 17 00:00:00 2001
From: Eczbek
Date: Thu, 5 Jun 2025 14:27:48 -0400
Subject: [PATCH] c++: [PR116928]
PR c++/116928
gcc/cp/ChangeLog:
* parser.cc (cp_parser_braced_list):
You're missing a descri
On 8/24/25 9:05 AM, Nathaniel Shead wrote:
On Sat, Aug 23, 2025 at 01:18:19PM -0400, Patrick Palka wrote:
On Fri, 22 Aug 2025, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In the PR, we're getting a linker error from _Vector_impl's destruct
On Fri, Jun 27, 2025 at 05:53:57AM +0800, H.J. Lu wrote:
> Here is the v3 patch. The difference from v2 is to use
>
> if (MEM_P (src)
> && MEM_EXPR (src)
> && (TREE_CODE (get_base_address (MEM_EXPR (src)))
> == PARM_DECL))
> cont
This patch introduces a new function, _M_fill_append, which is invoked when
copies of the same value are appended to the end of a vector. Unlike
_M_fill_insert(end(), n, v), _M_fill_append never permute elements in place,
so it does not require:
* vector element type to be assignable;
* a copy of t
The following fixes a missed SLP discovery of a live induction.
Our pattern matching of those fails because of the PR81529 fix
which I think was misguided and should now no longer be relevant.
So this essentially reverts that fix. I have added a GIMPLE
testcase to increase the chance the particula
On 8/22/25 4:23 PM, Richard Sandiford wrote:
> claudiu.zissulescu-iancule...@oracle.com writes:
>> From: Indu Bhagat
>>
>> gcc/Changelog:
>>
>> * asan.h (HWASAN_TAG_SIZE): Use targetm.memtag.tag_bitsize.
>> * config/i386/i386.cc (ix86_memtag_tag_size): Rename to
>> ix86_memtag_ta
From: Soumya AR
Signed-off-by: Soumya AR
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/aarch64-json-tunings/aarch64-json-tunings.exp: New
test.
* gcc.target/aarch64/aarch64-json-tunings/boolean-1.c: New test.
* gcc.target/aarch64/aarch64-json-tunings/boolean-1.json: Ne
From: Soumya AR
This commit introduces a Python maintenance script that generates C++ code
for parsing and serializing AArch64 JSON tuning parameters based on the
schema defined in aarch64-json-schema.h.
The script generates two include files:
- aarch64-json-tunings-parser-generated.inc
- aa
From: Soumya AR
This patch adds functionality to dump AArch64 CPU tuning parameters to a JSON
file. The new '-fdump-tuning-model=' flag allows users to export the current
tuning model configuration to a JSON file.
This patch was bootstrapped and regtested on aarch64-linux-gnu, no regression.
Si
From: Soumya AR
This patch adds support for loading custom CPU tuning parameters from a JSON
file for AArch64 targets. The '-muser-provided-CPU=' flag accepts a user
provided JSON file and overrides the internal tuning parameters at GCC runtime.
This patch was bootstrapped and regtested on aarch
From: Soumya AR
To allow runtime updates to tuning parameters, the const keyword is removed from
the members of the tune_params structure and the members of its nested
structures.
Since this patch also touches tuning structures in the arm backend, it was
bootstrapped on aarch64-linux-gnu as well
From: Soumya AR
This patch adds a get_map () method to the JSON object class to provide access
to the underlying hash map that stores the JSON key-value pairs.
To do this, we expose the map_t typedef, the return type of get_map().
This change is needed to allow traversal of key-value pairs when
From: Soumya AR
Hi,
This is a follow-up to suggestions given on v2 of the aarch64
user-defined tunings.
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689893.html
Attaching an updated patch series here.
Regarding some questions on this thread:
I've made the changes suggested by Andrew
When op2 in SVE2 saturating add intrinsics (svuqadd, svsqadd) is a zero
vector and predication is _z, an ICE in vregs occurs, e.g. for
svuint8_t foo (svbool_t pg, svuint8_t op1)
{
return svsqadd_u8_z (pg, op1, svdup_s8 (0));
}
The insn failed to match the pattern (aarch64-sve2.md):
;; Predic
Hi Yua,
Yuao Ma wrote:
I noticed that this patch was already committed as
r16-3154-g587b8a62f50179!
Sorry for the delay in committing. I committed it + wrote an email about
it during my vacation, but seemingly, I forgot to hit "send". (I found
it in my draft emails.)
Tobias
Sandra Loosemore wrote:
This patch fixes a number of problems with parser error checking of
"declare variant", especially in the C front end.
...
gcc/c/ChangeLog
* c-parser.cc (c_finish_omp_declare_variant): Rework diagnostic
code. Do not record variant if there are errors. Ma
On Mon, Aug 25, 2025 at 11:58:17AM +0200, Tobias Burnus wrote:
> Am 25.08.25 um 08:13 schrieb Jakub Jelinek:
> > On Sun, Aug 24, 2025 at 08:16:32PM -0600, Sandra Loosemore wrote:
> > > As noted in PR middle-end/121630, GCC seems to think that the "simd"
> > > construct selector on "declare variant"
On 21/08/25 16:38, Richard Biener wrote:
External email: Use caution opening links or attachments
On Thu, 21 Aug 2025, dhr...@nvidia.com wrote:
From: Dhruv Chawla
Bootstrapped and regtested on aarch64-linux-gnu.
Signed-off-by: Dhruv Chawla
gcc/ChangeLog:
* match.pd: New pattern.
From: Dhruv Chawla
For ==, < and <=, the fold is to 0. For !=, > and >=, the fold is to 1.
This only applies when C != 0.
Bootstrapped and regtested on aarch64-linux-gnu.
Signed-off-by: Dhruv Chawla
gcc/ChangeLog:
* match.pd: New patterns.
gcc/testsuite/ChangeLog:
* gcc.dg/
Am 25.08.25 um 08:13 schrieb Jakub Jelinek:
On Sun, Aug 24, 2025 at 08:16:32PM -0600, Sandra Loosemore wrote:
As noted in PR middle-end/121630, GCC seems to think that the "simd"
construct selector on "declare variant" implies that the variant
function accepts vectorized arguments, although this
Hi,
Gentle ping for below patch.
Kind regards,
Torbjörn
On 2025-08-10 13:51, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-15?
For releases/gcc-15, I would also want to cherry-pick r16-562-g20c25919132 that
converts
the test to use function body instead of three scan-assembler.
Chan
On Fri, Aug 22, 2025 at 03:29:11PM -0700, Kees Cook wrote:
> On Fri, Aug 22, 2025 at 08:29:16PM +, Qing Zhao wrote:
> > > On Aug 22, 2025, at 15:02, Kees Cook wrote:
> > > Right, and sometimes we have to explicitly perform a no-op
> > > address-taking to make sure a symbol gets generated:
> >
On Thu, Aug 21, 2025 at 9:30 AM Andrew Pinski
wrote:
>
> Just like r16-465-gf2bb7ffe84840d8 but this time
> instead of a VCE there is a full on load from a boolean.
> This showed up when trying to remove the extra copy
> in the testcase from the revision mentioned above (pr120122-1.c).
> So when m
On Thu, Aug 21, 2025 at 9:26 AM Andrew Pinski
wrote:
>
> When working on PR121279, I noticed that lim
> would create an uninitialized decl and marking
> it with supression for uninitialization warning.
> This is fine but then into ssa would just call
> get_or_create_ssa_default_def on that new dec
On Mon, Aug 25, 2025 at 2:48 AM Andrew Pinski
wrote:
>
> After the return type of remove_prop_source_from_use was changed to void,
> simplify_permutation only returns 1 or 0 so it can be boolified.
>
> Bootstrapped and tested on x86_64-linux-gnu.
OK.
Richard.
> gcc/ChangeLog:
>
> * tree
On Mon, Aug 25, 2025 at 2:49 AM Andrew Pinski
wrote:
>
> After changing the return type of remove_prop_source_from_use,
> forward_propagate_into_comparison will never return 2. So boolify
> forward_propagate_into_comparison.
>
> Bootstrapped and tested on x86_64-linux-gnu.
OK.
> gcc/ChangeLog:
>
On Mon, Aug 25, 2025 at 2:48 AM Andrew Pinski
wrote:
>
> Since r5-4705-ga499aac5dfa5d9, remove_prop_source_from_use has always
> return false. This removes the return type of remove_prop_source_from_use
> and cleans up the usage of remove_prop_source_from_use.
OK.
> Bootstrapped and tested on x8
Hi Pengfei,
we're seeing several dozens of ICEs in apply_scale since this patch (PR121523).
I didn't pay too much attention due to vacation etc. but now coming back to
this. Any specific spot I should start looking?
--
Regards
Robin
On Sun, Aug 24, 2025 at 5:12 PM Andrew Pinski
wrote:
>
> While looking at this code I noticed that we don't remove
> the old switch index assignment if it is only used in the switch
> after it is modified in simplify_gimple_switch.
> This fixes that by marking the old switch index for the dce work
Hi!
The following testcase ICEs during expansion, because cfun->returns_struct
wasn't cleared, despite auto being deduced to int.
The problem is that check_return_type -> apply_deduced_return_type
is called when parsing the expansion stmt body, at that time
processing_template_decl is non-zero an
78 matches
Mail list logo
