Hi All,
It seems that after my IVopts patches the function contain_complex_addr_expr
became unused and clang is rightfully complaining about it.
This removes the unused internal function.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLo
บริษัท เจริญทรัพย์ เครดิต
สินเชื่อเพื่อธุรกิจสำหรับเจ้าของกิจการ
- อนุมัติง่าย รู้ผลไว
(สอบถามฟรี)
LINE: big7809
In this PR, we used to generate:
.L6:
mov v30.16b, v31.16b
faddv31.4s, v31.4s, v27.4s
faddv29.4s, v30.4s, v28.4s
stp q30, q29, [x0]
add x0, x0, 32
cmp x1, x0
bne .L6
for an unrolled induction in
On 31/01/25 8:24 am, Michael Meissner wrote:
> Fix PR 118541, do not generate unordered fp cmoves for IEEE compares.
>
> In bug PR target/118541 on power9, power10, and power11 systems, for the
> function:
>
> extern double __ieee754_acos (double);
>
> double
> __acosp
On 06.02.25 00:36, Robert Dubner wrote:
-Original Message-
From: Matthias Klose
Sent: Tuesday, December 17, 2024 04:26
To: Joseph Myers
Cc: gcc-patches@gcc.gnu.org; James K. Lowden
Subject: Re: The COBOL front end, in 8 notes + toplevel patch
On 17.12.24 00:58, Joseph Myers wrote:
On
Pushed to r14-11275 and r15-7386.
在 2025/1/23 上午11:44, Lulu Cheng 写道:
PR target/118561
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc
(loongarch_expand_builtin_lsx_test_branch):
NULL_RTX will not be returned when an error is detected.
(loongarch
Some AVR devices support a Compact Vector Table.
The support is provided by means of a startup code file
crt-cvt.o from AVR-LibC that can be linked instead
of the traditional crt.o.
This patch adds a new command line option -mcvt that links
that CVT startup code (or issues an error when the devi
gcc.target/aarch64/pr108840.c has failed since r15-268-g9dbff9c05520
(which means that I really ought to have looked at it earlier).
The test wants us to fold an SImode AND into all shifts that use it.
This is something that late-combine is supposed to do, but:
(1) the pre-RA pass chickened out b
On Thu, 6 Feb 2025, Tamar Christina wrote:
> Hi All,
>
> It seems that after my IVopts patches the function contain_complex_addr_expr
> became unused and clang is rightfully complaining about it.
>
> This removes the unused internal function.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu
On Thu, 6 Feb 2025, Richard Sandiford wrote:
> In this PR, we used to generate:
>
> .L6:
> mov v30.16b, v31.16b
> faddv31.4s, v31.4s, v27.4s
> faddv29.4s, v30.4s, v28.4s
> stp q30, q29, [x0]
> add x0, x0, 32
> cmp x1, x0
On Wed, Feb 5, 2025 at 4:40 PM Qing Zhao wrote:
>
>
>
> > On Feb 5, 2025, at 07:46, Richard Biener wrote:
> >
> > On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wrote:
> >>
> >> Hi,
> >>
> >> One of our big application segv in libgcc code while unwinding the stack.
> >>
> >> This is a random crash wh
Hi!
The following testcase is miscompiled since r12-6325 stopped
preevaluating the initializers for new expression.
If evaluating the initializers throws, there is a correct cleanup
for that, but it is marked CLEANUP_EH_ONLY. While in standard
C++ that is just fine, if it has statement expression
Hi!
My r15-3046 change regressed the first half of the following testcase.
When it calls decl_attributes, it doesn't handle attributes with
dependent arguments correctly and so is now rejected that N is not
a constant integer during template parsing.
I've actually followed the pointer/reference c
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
BTF_KIND_TYPE_TAG records.
The new CTF kinds used to represent these annotations, CTF_K_DECL_T
On 2/6/25 9:30 AM, Craig Blackmore wrote:
stack_protect_{set,test}_ were showing up in RTL dumps as
UNSPEC_COPYSIGN and UNSPEC_FMV_X_W due to UNSPEC_SSP_SET and
UNSPEC_SSP_TEST being put in the unspecv enum instead of unspec.
gcc/ChangeLog:
* config/riscv/riscv.md: Move UNSPEC_SSP_SE
Support the btf_decl_tag and btf_type_tag attributes in BTF by creating
and emitting BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records,
respectively, for them.
Some care is required when -gprune-btf is in effect to avoid emitting
decl or type tags for declarations or types which have been pruned and
Hi Jason,
On 6 Feb 2025, at 16:48, Jason Merrill wrote:
> On 2/5/25 2:21 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 4 Feb 2025, at 21:23, Jason Merrill wrote:
>>
>>> On 2/4/25 3:03 PM, Jason Merrill wrote:
On 2/4/25 11:45 AM, Simon Martin wrote:
> On 4 Feb 2025, at 17:17, Jason Merril
Richard S's recent change to iv increment insertion removed a reg->reg
move (which was its intent AFAICT). This triggered a failure on a riscv
test.
That test was meant to verify that we didn't have an extraneous reg->reg
move due to a buglet in the risc-v splitters. Before the 2023 change w
gcc/
* doc/extend.texi (Common Variable Attributes): Document
btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 68 +
1 file changed, 68 insertions(+)
diff --git a/gcc/do
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with a simple shared handler for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_tag_attribute): New handler for both new attrib
[v1: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666911.html
Changes from v1:
- Fix a bug in v1 related to generating DWARF for type tags applied to
struct or union types, especially if the type had multiple type tags
or was also part of a typedef.
- Simplified the dwarf2ctf tra
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
A number of tls tests expect TLS-specific relocations, that are not
present when tls is emulated, as on e.g. leon3-elf. Skip the tests
when tls is emulated.
Regstrapped on x86_64-linux-gnu, also tested with gcc-14 targeting
leon3-elf. Ok to install?
for gcc/testsuite/ChangeLog
* gc
On Jan 31, 2025, Richard Biener wrote:
> On Thu, Jan 30, 2025 at 8:49 PM Alexandre Oliva wrote:
>> Split -Ofast out of the avx conditional, so that it is passed on the
>> same targets that expect the transformation.
> It effectively would require -Ofast on all targets (it's vectorizing a
> FP
On 1/28/25 1:11 PM, Surya Kumari Jangala wrote:
Hi,
The following patch has been bootstrapped and regtested on powerpc64le-linux,
aarch64-linux and x86_64-linux. This patch is a proposed fix for PR118533.
Request you to please review the patch.
Regards
Surya
lra: initialize allocated_hard_re
On 1/31/25 11:30 AM, Harald Anlauf wrote:
--- snip --
So either commit the current version and track this issue in
a PR if not yet done, or have a look if there is a quick fix.
Thanks for the work!
Harald
Committed as:
commit cfed99751c1a3b93ca66451eb1b62271e682f927 (HEAD -> master,
origin/
在 2025/1/20 上午9:30, Xi Ruoyao 写道:
For mask{eq,ne}z, rk is always compared with 0 in the full width, thus
the mode for rk should be X.
LGTM!
I agree with your point of view.
Thank you.
I found the issue reviewing a patch fixing a similar issue for RISC-V
XTheadCondMov [1], but interestin
> On Feb 6, 2025, at 04:36, Richard Biener wrote:
>
> On Wed, Feb 5, 2025 at 4:40 PM Qing Zhao wrote:
>>
>>
>>
>>> On Feb 5, 2025, at 07:46, Richard Biener wrote:
>>>
>>> On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wrote:
Hi,
One of our big application segv in libgcc
On 2/5/25 5:29 AM, Richard Biener wrote:
The PR shows fold-mem-offsets taking ages and a lot of memory computing
DU/UD chains as that requires the RD problem. The issue is not so much
the memory required for the pruned sets but the high CFG connectivity
(and that the CFG is cyclic) which make
On leon3-elf and presumably on other targets, the test fails due to
differences in calling conventions and other reasons, that add extra
gimple stmts that prevent the expected optimization at the expected
point. The optimization takes place anyway, just a little later, so
tolerate that.
Regstra
Added missing CC
On 05/02/2025 17:14, Richard Sandiford wrote:
Alfie Richards writes:
On 04/02/2025 10:03, Richard Sandiford wrote:
Alfie Richards writes:
+ return id;
+ else if (cgraph_node::get_create
(decl)->dispatcher_resolver_function)
+ id = clone_identifier (id, "resol
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
In a member-specification of a class, a noexcept-specifier is
a complete-class context. Thus we delay parsing until the end of
the class via our DEFERRED_PARSE mechanism; see cp_parser_save_noexcept
and cp_parser_late_noexcept_
On Thu, Feb 06, 2025 at 07:32:43PM +0100, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, https://eel.is/c++draft/conv.lval#note-1
> says that even volatile reads from std::nullptr_t typed objects actually
> don't read anything and https://eel.is/c++draft/expr.const#10.9
> says that even th
On Thu, Feb 06, 2025 at 01:45:59PM -0500, Marek Polacek wrote:
> > --- gcc/cp/constexpr.cc.jj 2025-02-05 13:14:34.771198185 +0100
> > +++ gcc/cp/constexpr.cc 2025-02-06 09:53:03.236587121 +0100
> > @@ -9717,7 +9717,8 @@ potential_constant_expression_1 (tree t,
> > return true;
> >
> >
On 1/19/25 7:32 AM, Jin Ma wrote:
gcc/ChangeLog:
* config/riscv/riscv.md: Change 'r' to 'p'.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/prefetch-zicbop-ice.c: New test.
I think that rather than adjusting the constraint we should probably
adjust the operand predicate. In
On 1/29/25 12:27 PM, Jakub Jelinek wrote:
I'd like to ping 4 C++ patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
P2552R3 - On
On 2/5/25 11:11 AM, Palmer Dabbelt wrote:
On Wed, 05 Feb 2025 09:57:56 PST (-0800), ja...@redhat.com wrote:
Hi!
The following test ICEs on RISC-V at least latently since
r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
RISC-V specific case to get_biv_step_1 to recognize also
({
stack_protect_{set,test}_ were showing up in RTL dumps as
UNSPEC_COPYSIGN and UNSPEC_FMV_X_W due to UNSPEC_SSP_SET and
UNSPEC_SSP_TEST being put in the unspecv enum instead of unspec.
gcc/ChangeLog:
* config/riscv/riscv.md: Move UNSPEC_SSP_SET and UNSPEC_SSP_TEST
to unspec enum.
-
Richard Biener writes:
> On Thu, Feb 6, 2025 at 2:41 PM Alexandre Oliva wrote:
>>
>> On Jan 27, 2025, Richard Biener wrote:
>>
>> > What I was saying that the conservative tree_could_trap_p could say
>> > 'yes' to a certain encoding of a ref but 'no' to another if in reality
>> > the ref can ne
Ping.
On Tue, Jan 21, 2025 at 11:05:46AM -0500, Marek Polacek wrote:
> Ping.
>
> On Fri, Jan 10, 2025 at 03:07:52PM -0500, Marek Polacek wrote:
> > Ping.
> >
> > On Fri, Dec 20, 2024 at 08:58:05AM -0500, Marek Polacek wrote:
> > > Ping.
> > >
> > > On Tue, Nov 26, 2024 at 05:35:50PM -0500, Mare
On Jan 27, 2025, Richard Biener wrote:
> What I was saying that the conservative tree_could_trap_p could say
> 'yes' to a certain encoding of a ref but 'no' to another if in reality
> the ref can never trap. We of course cannot (apart from bugs in
> tree_could_trap_p) turn a for-sure trap into a
vis3move-3.c expects fsmuld, that is not available on all variants of
sparc. Select a cpu that supports it for the test.
Now, -mfix-ut699 irrevocbly disables fsmuld, so skip the test if the
test configuration uses that option.
Regstrapped on x86_64-linux-gnu, also tested with gcc-14 targeting
If -mcpu=leon3 is present in the command line for a test run,
overriding it with -mcpu=niagara7 is not enough to override the tuning
for leon3 selected by the previous -mcpu option.
niagara7-align.c tests for niagara7 alignment tuning, so use -mtune
rather than -mcpu.
Regstrapped on x86_64-linu
On Thu, Feb 6, 2025 at 2:57 PM Qing Zhao wrote:
>
>
>
> > On Feb 6, 2025, at 04:36, Richard Biener wrote:
> >
> > On Wed, Feb 5, 2025 at 4:40 PM Qing Zhao wrote:
> >>
> >>
> >>
> >>> On Feb 5, 2025, at 07:46, Richard Biener
> >>> wrote:
> >>>
> >>> On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wr
On 1/31/25 11:30 AM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.25 um 21:50 schrieb Jerry D:
On 1/29/25 10:30 AM, Jerry D wrote:
Follow-up:
On 1/28/25 1:33 PM, Harald Anlauf wrote:
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NA
Vladimir Makarov writes:
> On 2/3/25 1:20 AM, H.J. Lu wrote:
>> commit 3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b
>> Author: Surya Kumari Jangala
>> Date: Tue Jun 25 08:37:49 2024 -0500
>>
>> ira: Scale save/restore costs of callee save registers with block
>> frequency
>>
>> scales the cos
For
---
int f(int);
int advance(int dz)
{
if (dz > 0)
return (dz + dz) * dz;
else
return dz * f(dz);
}
---
Before r15-1619-g3b9b8d6cfdf593
advance(int):
pushrbx
mov ebx, edi
testedi, edi
jle .L2
imulebx, edi
With release checking we get an uninitialization warning
inside aarch64_split_move because of jump threading for the case of `npieces==0`
but `npieces` is never 0 (but there is no way the compiler can know that.
So this fixes the issue by adding a `gcc_assert` to the function which asserts
that `np
On Thu, Feb 6, 2025 at 11:40 PM Vladimir Makarov wrote:
>
>
> On 2/6/25 4:54 PM, Richard Sandiford wrote:
>
> Vladimir Makarov writes:
>
> This is a complicated problem resulted in many tries to fix it in some
> general way.
>
> In general I am agree with Surya's approach to scale cost of reg
> s
> niagara7-align.c tests for niagara7 alignment tuning, so use -mtune
> rather than -mcpu.
>
> Regstrapped on x86_64-linux-gnu, also tested with gcc-14 targeting
> leon3-elf. Ok to install?
>
>
> for gcc/testsuite/ChangeLog
>
> * gcc.target/sparc/niagara7-align.c: Use -mtune.
OK.
--
> vis3move-3.c expects fsmuld, that is not available on all variants of
> sparc. Select a cpu that supports it for the test.
>
> Now, -mfix-ut699 irrevocbly disables fsmuld, so skip the test if the
> test configuration uses that option.
>
> Regstrapped on x86_64-linux-gnu, also tested with gcc-1
ROCm 6.3.2 does not like my patch for reasons that I do not understand;
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675200.html
Until that's sorted, I decided to split off two obvious fixes;
I might suggest some further changes, but the full patch has to
wait until generic really work
> Option -mfix-ut699 changes the set of instructions that can be placed
> in the delay slot, preventing the expected insn placement. Skip the
> test if the option is present.
>
> Regstrapped on x86_64-linux-gnu, also tested with gcc-14 targeting
> leon3-elf with -mfix-ut699. Ok to install?
>
>
On 1/19/25 7:32 AM, Jin Ma wrote:
gcc/ChangeLog:
* config/riscv/riscv.md: Change 'r' to 'p'.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/prefetch-zicbop-ice.c: New test.
As expected, there's more to this issue than just adjusting constraints
or predicates.
As Tsukasa note
> > +/* Implement TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE. */
> > +
> > +static int
> > +ix86_ira_callee_saved_register_cost_scale (int)
> > +{
> > + return 1;
> > +}
> > +
> > return cl;
> > }
> > +int
> > +default_ira_callee_saved_register_cost_scale (int)
> > +{
> > + return (opti
> A number of tls tests expect TLS-specific relocations, that are not
> present when tls is emulated, as on e.g. leon3-elf. Skip the tests
> when tls is emulated.
>
> Regstrapped on x86_64-linux-gnu, also tested with gcc-14 targeting
> leon3-elf. Ok to install?
>
>
> for gcc/testsuite/ChangeL
On 2/6/25 4:54 PM, Richard Sandiford wrote:
Vladimir Makarov writes:
This is a complicated problem resulted in many tries to fix it in some
general way.
In general I am agree with Surya's approach to scale cost of reg
saves/restores somehow. But the general approach, although solved some
prob
After spending some time with the debugger, I am now convinced that
ROCm 6.3.2 does not yet support generic. The amd-staging branch at
https://github.com/ROCm/ROCR-Runtime/ support does, albeit only after
the tag rocm-6.3.2. However, the released ROCm 6.3.2 does not match
that tagged commit as it
On Tue, Jan 21, 2025 at 04:59:16PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 07, 2025 at 01:49:04PM +0100, Jakub Jelinek wrote:
> > On Wed, Dec 18, 2024 at 12:15:15PM +0100, Jakub Jelinek wrote:
> > > On Fri, Dec 06, 2024 at 05:07:40PM +0100, Jakub Jelinek wrote:
> > > > I'd like to ping the
> > >
On 2/3/25 1:20 AM, H.J. Lu wrote:
commit 3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b
Author: Surya Kumari Jangala
Date: Tue Jun 25 08:37:49 2024 -0500
ira: Scale save/restore costs of callee save registers with block frequency
scales the cost of saving/restoring a callee-save hard regist
This regression must have been generated during my ASSOCIATE campaign; I am
not sure when or where. Fortunately the fix is extremely simple and is
explained in the ChangeLog.
Regression tests fine. OK for both affected branches?
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran
On 2/5/25 2:21 PM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 21:23, Jason Merrill wrote:
On 2/4/25 3:03 PM, Jason Merrill wrote:
On 2/4/25 11:45 AM, Simon Martin wrote:
On 4 Feb 2025, at 17:17, Jason Merrill wrote:
On 2/4/25 10:56 AM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at
> On Feb 6, 2025, at 09:25, Richard Biener wrote:
>
> On Thu, Feb 6, 2025 at 2:57 PM Qing Zhao wrote:
>>
>>
>>
>>> On Feb 6, 2025, at 04:36, Richard Biener wrote:
>>>
>>> On Wed, Feb 5, 2025 at 4:40 PM Qing Zhao wrote:
> On Feb 5, 2025, at 07:46, Richard Biener
>>
On 2/5/25 10:57 AM, Jakub Jelinek wrote:
Hi!
The following test ICEs on RISC-V at least latently since
r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
RISC-V specific case to get_biv_step_1 to recognize also
({zero,sign}_extend:DI (plus:SI op0 op1))
The reason for the ICE is t
Hi Paul,
looks fine to me.
Thanks for the patch,
Andre
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 178 3637538 * ve...@gmx.de
Am 6. Februar 2025 16:49:18 schrieb Paul Richard Thomas
:
This regression must have been generated during my ASSOCIATE campaign; I am
not sure when or
Georg-Johann Lay writes:
> Some AVR devices support a Compact Vector Table.
>
> The support is provided by means of a startup code file
> crt-cvt.o from AVR-LibC that can be linked instead
> of the traditional crt.o.
>
> This patch adds a new command line option -mcvt that links
> that CVT startu
Hi,
in PR115703 we fuse two vsetvls:
Fuse curr info since prev info compatible with it:
prev_info: VALID (insn 438, bb 2)
Demand fields: demand_ge_sew demand_non_zero_avl
SEW=32, VLMUL=m1, RATIO=32, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AV
Hi Andre,
Thanks for the review - pushed as commit r15-7389.
Paul
On Thu, 6 Feb 2025 at 16:22, Andre Vehreschild wrote:
> Hi Paul,
>
> looks fine to me.
>
> Thanks for the patch,
> Andre
> Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
> Tel.: +49 178 3637538 * ve...@gmx.de
>
> Am 6. Fe
Updated version; changes:
* Fixed SRAMECC setting for gfx906 - should be ANY (as in GCC 14)
not UNSUPPORTED. (Shows up as link error when compiling with '-g'.)
* Fixed generic handling for gfx9* - copy'n'paste bug: gfx11-generic
is clearly wrong.
* Implemented autoconvert from -march=gfx to
Option -mfix-ut699 changes the set of instructions that can be placed
in the delay slot, preventing the expected insn placement. Skip the
test if the option is present.
Regstrapped on x86_64-linux-gnu, also tested with gcc-14 targeting
leon3-elf with -mfix-ut699. Ok to install?
for gcc/test
On Thu, Feb 6, 2025 at 2:41 PM Alexandre Oliva wrote:
>
> On Jan 27, 2025, Richard Biener wrote:
>
> > What I was saying that the conservative tree_could_trap_p could say
> > 'yes' to a certain encoding of a ref but 'no' to another if in reality
> > the ref can never trap. We of course cannot (a
On 2/5/25 12:02 PM, Jakub Jelinek wrote:
Hi!
As the following testcase show (note, just for-{3,4,6,7,8}.C, constexpr-86769.C
and stmtexpr27.C FAIL without the patch, the rest is just that I couldn't
find coverage for some details and so added tests we don't regress or for5.C
is from Marek's atte
On Thu, Feb 06, 2025 at 10:40:52AM -0500, Jason Merrill wrote:
Thanks.
> > @@ -7202,6 +7210,28 @@ cxx_eval_loop_expr (const constexpr_ctx
> > cxx_eval_constant_expression (ctx, expr, vc_prvalue,
> > non_constant_p, overflow_p,
> >
Hi!
As mentioned in the PR, https://eel.is/c++draft/conv.lval#note-1
says that even volatile reads from std::nullptr_t typed objects actually
don't read anything and https://eel.is/c++draft/expr.const#10.9
says that even those are ok in constant expressions.
So, the following patch adjusts the r9
Hi!
cp_parser_range_for temporarily reverts IDENTIFIER_BINDING changes
to hide the decls from the structured bindings from lookup during
parsing of the expression after :
If there are 2 or more name independent decls, we undo IDENTIFIER_BINDING
for the same name multiple times, even when just one
75 matches
Mail list logo
