Hi Andre,
The next lines, immediately after the chunk in trans-decl.cc are:
/* Dummy variables should already have been created. */
gcc_assert (sym->backend_decl);
It's taken care of :-)
Thanks for the review.
Paul
On Wed, 22 Jan 2025 at 14:21, Andre Vehreschild wrote:
> Hi Pau
Hi Damian,
Damian Rouson wrote:
As shown below, using associate eliminates the first error, but I'm
still confused by the remaining error message. Are locality
specifiers actually supported yet?
The lion share of support is in, but not not yet the code-generation
changes.
For local and lo
The new gcc.target/i386/cmov12.c test FAILs on Solaris/x86 with the
native as:
FAIL: gcc.target/i386/cmov12.c scan-assembler-times cmovg 3
This happens because as uses a different syntax for cmov:
--- cmov12.s.bu243 2025-01-21 16:55:27.038829605 +0100
+++ cmov12.s.bu243902025-01-21 16:5
On Thu, Jan 23, 2025 at 1:08 AM Alexandre Oliva wrote:
>
> On Jan 21, 2025, Richard Biener wrote:
>
> > So - your fix looks almost good, I'd adjust it to
>
> >> +case BIT_FIELD_REF:
> >> + if (DECL_P (TREE_OPERAND (expr, 0))
> >> + && !bit_field_ref_in_bounds_p (expr))
> >> +
Hi!
After committing the append_ctor_to_tree_vector patch, I've realized
that for the larger constructors make_tree_vector_from_ctor unnecessarily
wastes one GC vector; make_tree_vector () / release_tree_vector () only
caches GC vectors from 4 to 16 allocated tree elements, so in the likely
case o
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673336.html
Am 11.01.25 um 14:09 schrieb Georg-Johann Lay:
The patch below is for trunk.
Andrew Pinski says he has a patch to fix it, bit that won't materialize
before v16.
AVR: PR118012 - Try to work around sick code from match.p
On 2025-01-22 22:15, Mike Stump wrote:
On Jan 19, 2025, at 12:47 PM, Torbjorn SVENSSON
wrote:
On 2025-01-19 21:20, Andrew Pinski wrote:
On Sun, Jan 19, 2025 at 12:17 PM Torbjörn SVENSSON
wrote:
Ok for trunk?
--
Most baremetal toolchains will not have an implementation for alarm and
s
On Wed, Jan 22, 2025 at 10:03:40PM -0500, Jason Merrill wrote:
> On 1/6/25 7:21 AM, Nathaniel Shead wrote:
> > Something like this should probably be backported to GCC 14 too, since
> > my change in r14-9232-g3685fae23bb008 inadvertantly caused ICEs that
> > this fixes. But without the previous pa
Hi!
As can be seen on the testcase, when array_expr is type dependent, assuming
it has non-NULL TREE_TYPE is just wrong, it can often have NULL type, and even
if not, blindly assuming it is a pointer or array type is also wrong.
So, like in many other spots in the C++ FE, for type dependent expre
On Thu, Jan 23, 2025 at 6:58 AM Alexandre Oliva wrote:
>
> On Jan 22, 2025, Alexandre Oliva wrote:
>
> > I have another patch coming up that doesn't raise concerns for me, so
> > I'll hold off from installing the above, in case you also prefer the
> > other one.
>
> Unlike other access patterns,
Hi!
The assume_query constructor does
assume_query::assume_query (function *f, bitmap p) : m_parm_list (p),
m_func (f)
where m_parm_list is bitmap &. This is compile time UB, because
as soon as the constructor returns, m_parm_list reference is
On 1/22/25 4:37 PM, Jakub Jelinek wrote:
On Wed, Jan 22, 2025 at 04:19:37PM +0530, Tejas Belagod wrote:
On 1/21/25 10:16 PM, Jakub Jelinek wrote:
On Fri, Oct 18, 2024 at 11:52:22AM +0530, Tejas Belagod wrote:
Currently poly-int type structures are passed by value to OpenMP runtime
functions fo
On Thu, Jan 23, 2025 at 11:37 AM Jakub Jelinek wrote:
>
> Hi!
>
> The assume_query constructor does
> assume_query::assume_query (function *f, bitmap p) : m_parm_list (p),
> m_func (f)
> where m_parm_list is bitmap &. This is compile time UB, b
On Thu, Jan 23, 2025 at 8:43 AM Alexandre Oliva wrote:
>
>
> When comparing a signed narrow variable with a wider constant that has
> the bit corresponding to the variable's sign bit set, we would check
> that the constant is a sign-extension from that sign bit, and conclude
> that the compare fai
Earlier, we were gating SVE2 faminmax behind sve+faminmax. This was
incorrect and this patch changes it so that it is gated behind
sve2+faminmax.
gcc/ChangeLog:
* config/aarch64/aarch64-sve2.md:
(*aarch64_pred_faminmax_fused): Fix to use the correct flags.
* config/aarch6
On Wed, Jan 22, 2025 at 12:49 AM Andrew MacLeod wrote:
>
> This patch simply adds an op2_range to operator_div which returns
> non-zero if the LHS is not undefined. This means given and integral
> division:
>
> x = y / z
>
> 'z' will have a range of [-INF, -1] [1, +INF] after execution
On Thu, Jan 23, 2025 at 7:43 AM Alexandre Oliva wrote:
>
> On Jan 22, 2025, Alexandre Oliva wrote:
>
> > I have another patch coming up that doesn't raise concerns for me, so
> > I'll hold off from installing the above, in case you also prefer the
> > other one.
>
> And here's an unrelated bit th
On Thu, Jan 23, 2025 at 10:38 AM Rainer Orth
wrote:
>
> The new gcc.target/i386/cmov12.c test FAILs on Solaris/x86 with the
> native as:
>
> FAIL: gcc.target/i386/cmov12.c scan-assembler-times cmovg 3
>
> This happens because as uses a different syntax for cmov:
>
> --- cmov12.s.bu243 2025-01
Hi!
Some clang analyzer warned about
if (!strcmp (p, "when") == 0 && !default_p)
which really looks weird, it is better to use strcmp (p, "when") != 0
or !!strcmp (p, "when"). Furthermore, as a micro optimization, it is cheaper
to evaluate default_p than calling strcmp, so that can be put first i
rtl-ssa uses degenerate phis to maintain an RPO list of
accesses in which every use is of the RPO-previous definition.
Thus, if it finds that a phi is always equal to a particular
value V, it sometimes needs to keep the phi and make V the
single input, rather than replace all uses of the phi with V
writes:
> Earlier, we were gating SVE2 faminmax behind sve+faminmax. This was
> incorrect and this patch changes it so that it is gated behind
> sve2+faminmax.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sve2.md:
> (*aarch64_pred_faminmax_fused): Fix to use the correct flags.
>
Hi, this is Ping #2 for a patch from 2024.
It adds a new target hook that allows to output
assembly code for a VAR_DECL in a custom way.
The default action is an obvious no-op,
i.e. assemble_variable() behaves like before.
This hook is needed in the avr backend to properly implement
some varia
Hello,
On Wed, 22 Jan 2025, Martin Uecker wrote:
> > > > If y is not a member it must be an expression, true. But if it's
> > > > a member you don't know, it may be a designation or an expression.
> > >
> > > In an initializer I know all the members.
> >
> > My sentence was ambiguous :-) Try
> Am 23.01.2025 um 19:32 schrieb Jakub Jelinek :
>
> Hi!
>
> vectorizable_{store,load} does roughly
> tree offvar;
> tree running_off;
> if (!costing_p)
>{
> ... initialize offvar ...
>}
> running_off = offvar;
> for (...)
>{
> if (costing_p)
>
Hi!
vectorizable_{store,load} does roughly
tree offvar;
tree running_off;
if (!costing_p)
{
... initialize offvar ...
}
running_off = offvar;
for (...)
{
if (costing_p)
{
...
continue;
Le 2025-01-23 à 13 h 13, David Malcolm a écrit :
On Wed, 2025-01-22 at 08:47 -0500, Antoni Boucher wrote:
Hi David.
Hi Antoni
I went ahead and pushed this patch since without it even simple unit
tests like test-factorial.c were failing for me on aarch64; in
particular, the build of emacs w
Am 23.01.25 um 14:58 schrieb Richard Biener:
On Thu, Jan 23, 2025 at 2:23 PM Georg-Johann Lay wrote:
Hi, this is Ping #2 for a patch from 2024.
It adds a new target hook that allows to output
assembly code for a VAR_DECL in a custom way.
The default action is an obvious no-op,
i.e. assemble
Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao:
>
> > On Jan 22, 2025, at 12:20, Martin Uecker wrote:
> >
> > Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker:
> > > Am Mittwoch, dem 22.01.2025 um 16:37 + schrieb Qing Zhao:
> > > >
> > > > > On Jan 22, 2025,
Hi Jason,
On 20 Jan 2025, at 22:49, Jason Merrill wrote:
> On 1/20/25 2:11 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 15 Jan 2025, at 22:42, Jason Merrill wrote:
>>
>>> On 12/12/24 2:07 PM, Simon Martin wrote:
We currently ICE upon the following valid (under -Wno-vla) code
=== c
On 11.01.25 01:02, Jeff Law wrote:
On 1/7/25 7:24 PM, YunQiang Su wrote:
Jeff Law 于2025年1月8日周三 07:06写道：
On 1/1/25 6:42 PM, YunQiang Su wrote:
Matthias Klose 于2025年1月1日周三
22:37写道：
in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641619.html
there are two typos in the patch, c
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fixes ICEs where unattached lambdas at class scope (for instance,
in member template instantiations) are streamed. This is only possible
in header units, as in named modules attempting to stream such lambdas
will be a
Hi Mikael,
Am 23.01.25 um 15:00 schrieb Mikael Morin:
Le 22/01/2025 à 22:55, Harald Anlauf a écrit :
Dear all,
while looking at details of a related but slightly different PR, I found
that we did evaluate the arguments to MINLOC/MAXLOC too often in the
inlined version.
The attached patch crea
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This is a step closer to implementing the suggested changes for
https://github.com/itanium-cxx-abi/cxx-abi/pull/85. Most lambdas
defined within a class should have an extra scope of that class so that
uses across different
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
detection of TU-local lambdas. Now that LAMBDA_EXPR_EXTRA_SCOPE is
properly set for most lambdas we can use it to detect lambdas that are
TU-local.
Lam
On Sat, Jan 18, 2025 at 09:36:14AM -0700, Jeff Law wrote:
[...]
> > > Do we detect conflicts between a hard register constraint and another
> > > constraint which requires a singleton class? That's going to be an error
> > > I
> > > suspect, but curious if it's handled.
> >
> > That is a good po
On 1/22/25 6:11 PM, Jason Merrill wrote:
On 1/16/25 7:24 PM, Nathaniel Shead wrote:
On Thu, Jan 16, 2025 at 07:09:33PM -0500, Jason Merrill wrote:
On 1/6/25 7:22 AM, Nathaniel Shead wrote:
I'm not 100% sure I've handled this properly, any feedback welcome.
In particular, maybe should I use `DE
Am 23.01.25 um 14:58 schrieb Richard Biener:
On Thu, Jan 23, 2025 at 2:23 PM Georg-Johann Lay wrote:
Hi, this is Ping #2 for a patch from 2024.
It adds a new target hook that allows to output
assembly code for a VAR_DECL in a custom way.
The default action is an obvious no-op,
i.e. assemble
>On 1/15/25 7:36 PM, 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 a
Excerpts from Maciej W. Rozycki's message of Januar 23, 2025 6:29 pm:
> On Tue, 21 Jan 2025, Iain Buclaw wrote:
>
>> This patch adds a MIPS64 implementation of `fiber_switchContext',
>> replacing the generic implementation. The `core.thread.fiber' module
>> already defines version=AsmExternal on
Ping patches 1-2 to separate PowerPC ISA bits from architecture bits set by
-mcpu=.
Message-ID
Explanation of the patch set:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669108.html
Patch #1, add rs6000 architecture masks:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/66910
Ping patch for PR target/108958, Use mtvsrdd to zero extend GPR DImode to VSX
TImode
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669242.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On Wed, Jan 22, 2025 at 04:19:38PM -0500, Jason Merrill wrote:
> > @@ -4482,6 +4536,7 @@ emit_partial_init_fini_fn (bool initp, u
> > /* Do one initialization or destruction. */
> > one_static_initialization_or_destruction (initp, decl, init);
> > }
> > + decomp_finalize_var
On Thu, Jan 23, 2025 at 02:40:09PM +, Simon Martin wrote:
> Hi Jason,
>
> On 20 Jan 2025, at 22:49, Jason Merrill wrote:
>
> > On 1/20/25 2:11 PM, Simon Martin wrote:
> >> Hi Jason,
> >>
> >> On 15 Jan 2025, at 22:42, Jason Merrill wrote:
> >>
> >>> On 12/12/24 2:07 PM, Simon Martin wrote:
>
Hi Marek,
On 23 Jan 2025, at 16:45, Marek Polacek wrote:
> On Thu, Jan 23, 2025 at 02:40:09PM +, Simon Martin wrote:
>> Hi Jason,
>>
>> On 20 Jan 2025, at 22:49, Jason Merrill wrote:
>>
>>> On 1/20/25 2:11 PM, Simon Martin wrote:
Hi Jason,
On 15 Jan 2025, at 22:42, Jason Merril
Noticed by inspection. Committed to active branches.
Dave
---
hppa: Fix typo in ADDITIONAL_REGISTER_NAMES in pa32-regs.h
2025-01-23 John David Anglin
gcc/ChangeLog:
* config/pa/pa32-regs.h (ADDITIONAL_REGISTER_NAMES): Change
register 86 name to "%fr31L".
diff --git a/gcc/c
This patch defines spaceship{sf,df,si,di} for AArch64. This is a fix
for the poor codegen on floating-point types raised by the PR, and
an improvement to that for integers where this optab applies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117013.
Successfully bootstrapped and regtested on aar
This expansion ensures that exactly one comparison is emitted for
spacesip-like sequences on floating-point operands, including when
the result of such sequences are compared against members of
std.
For both integer and floating-point types, we optimize for the case
in which the result of a sp
Hi Jason,
On 21 Jan 2025, at 22:51, Jason Merrill wrote:
> On 1/3/25 3:00 PM, Simon Martin wrote:
>> We currently accept this code with c++ <= 17 even though it's invalid
>> since the base is not initialized (we properly reject it with c++ >=
>> 20)
>>
>> === cut here ===
>> struct NoMut1 { int
Georg-Johann Lay writes:
> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673336.html
>
> Am 11.01.25 um 14:09 schrieb Georg-Johann Lay:
>> The patch below is for trunk.
>> Andrew Pinski says he has a patch to fix it, bit that won't
>> materialize
>> before v16.
>> AVR: PR118012
On Tue, 21 Jan 2025, Iain Buclaw wrote:
> This patch adds a MIPS64 implementation of `fiber_switchContext',
> replacing the generic implementation. The `core.thread.fiber' module
> already defines version=AsmExternal on mips64el-linux-gnuabi64 targets.
Don't you need similar code for n32 MIPS64
Hi!
The following testcase r12-6328, because the elements of the array
are destructed twice, once when the callee encounters delete[] p;
and then second time when the exception is thrown.
The array elts should be only destructed if exception is thrown from
one of the constructors during the build_
> On Jan 22, 2025, at 12:20, Martin Uecker wrote:
>
> Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker:
>> Am Mittwoch, dem 22.01.2025 um 16:37 + schrieb Qing Zhao:
>>>
On Jan 22, 2025, at 11:22, Martin Uecker wrote:
Hello Michael,
Am Mittw
On Thu, 23 Jan 2025, Maciej W. Rozycki wrote:
> > This patch adds a MIPS64 implementation of `fiber_switchContext',
> > replacing the generic implementation. The `core.thread.fiber' module
> > already defines version=AsmExternal on mips64el-linux-gnuabi64 targets.
>
> Don't you need similar cod
On Wed, 2025-01-22 at 08:47 -0500, Antoni Boucher wrote:
> Hi David.
Hi Antoni
I went ahead and pushed this patch since without it even simple unit
tests like test-factorial.c were failing for me on aarch64; in
particular, the build of emacs was failing in Fedora's mass rebuild
with gcc 15, and t
On Tue, Jan 21, 2025 at 05:09:32PM -0500, Jason Merrill wrote:
> On 1/16/25 5:42 PM, Marek Polacek wrote:
> > On Wed, Jan 15, 2025 at 04:18:36PM -0500, Jason Merrill wrote:
> > > On 1/15/25 12:55 PM, Marek Polacek wrote:
> > > > On Wed, Jan 15, 2025 at 09:39:41AM -0500, Jason Merrill wrote:
> > > >
On Thu, Jan 23, 2025 at 2:05 PM Richard Sandiford
wrote:
>
> rtl-ssa uses degenerate phis to maintain an RPO list of
> accesses in which every use is of the RPO-previous definition.
> Thus, if it finds that a phi is always equal to a particular
> value V, it sometimes needs to keep the phi and mak
On Thu, 2025-01-09 at 01:15 +0100, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on x86_64-redhat-linux. Ok for master?
>
>
>
> The FakeStack flag is not zeroed out when can_store_by_pieces()
> returns false. Over time, this causes FakeStack::Allocate() to
> perform
> the maximum number
On Thu, Jan 23, 2025 at 2:23 PM Georg-Johann Lay wrote:
>
> Hi, this is Ping #2 for a patch from 2024.
>
> It adds a new target hook that allows to output
> assembly code for a VAR_DECL in a custom way.
>
> The default action is an obvious no-op,
> i.e. assemble_variable() behaves like before.
I
When we get a zero distance vector we still have to check for the
situation of a common inner loop with zero distance. But we can
still allow a zero distance for the loop we distribute
(gcc.dg/tree-ssa/ldist-33.c is such a case). This is because
zero distances in non-outermost loops are a misrepr
Le 22/01/2025 à 22:55, Harald Anlauf a écrit :
Dear all,
while looking at details of a related but slightly different PR, I found
that we did evaluate the arguments to MINLOC/MAXLOC too often in the
inlined version.
The attached patch creates temporaries for array elements where needed,
and ens
On Thu, Jan 23, 2025 at 4:53 PM Georg-Johann Lay wrote:
>
> Am 23.01.25 um 14:58 schrieb Richard Biener:
> > On Thu, Jan 23, 2025 at 2:23 PM Georg-Johann Lay wrote:
> >>
> >> Hi, this is Ping #2 for a patch from 2024.
> >>
> >> It adds a new target hook that allows to output
> >> assembly code fo
On Fri, Jan 17, 2025 at 8:20 AM Qing Zhao wrote:
>
> Hi, Bill,
>
> Thanks a lot for your testing case.
>
> I studied this testing case and realized that we need to decide
> what’s the expected behavior for the following situation:
>
> struct bar;
>
> struct a {
>int dummy;
>struct bar *arr
On Fri, Jan 24, 2025 at 5:43 AM Alexandre Oliva wrote:
>
> On Jan 23, 2025, Richard Biener wrote:
>
> > That said, it'd be a lot clearer if this simply read
>
> > || !access_in_bounds_of_type_p (TREE_TYPE (inner), bs, bp)
>
> > without all the other weird conditions.
>
> ACK, will do.
>
On Jan 23, 2025, Richard Biener wrote:
> That said, it'd be a lot clearer if this simply read
> || !access_in_bounds_of_type_p (TREE_TYPE (inner), bs, bp)
> without all the other weird conditions.
ACK, will do.
>> + /* Check that the loads that we're trying to combine have the same
On 1/23/25 4:06 PM, Tejas Belagod wrote:
On 1/22/25 4:37 PM, Jakub Jelinek wrote:
On Wed, Jan 22, 2025 at 04:19:37PM +0530, Tejas Belagod wrote:
On 1/21/25 10:16 PM, Jakub Jelinek wrote:
On Fri, Oct 18, 2024 at 11:52:22AM +0530, Tejas Belagod wrote:
Currently poly-int type structures are passe
Lulu Cheng writes:
> 在 2025/1/22 上午8:49, Xi Ruoyao 写道:
>> The second source register of this insn cannot be the same as the
>> destination register.
>>
>> gcc/ChangeLog:
>>
>> * config/loongarch/loongarch.md
>> (_alsl_reversesi_extended): Add '&' to the destination
>> register const
On Thu, Jan 23, 2025 at 04:47:32PM -0500, Jason Merrill wrote:
> On 1/6/25 7:24 AM, Nathaniel Shead wrote:
> > Happy to defer this till GCC16 if preferred.
> >
> > -- >8 --
> >
> > This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
> > detection of TU-local lambdas. Now that L
Am Donnerstag, dem 23.01.2025 um 20:24 + schrieb Qing Zhao:
>
> > On Jan 23, 2025, at 13:27, Martin Uecker wrote:
> >
> > Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao:
> > >
> > > > On Jan 22, 2025, at 12:20, Martin Uecker wrote:
> > > >
> > > > Am Mittwoch, dem 22.01.20
Ping patch to fix PR target/117251, Add PowerPC XXEVAL support for fusion
optimization in power10
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669138.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
> On Jan 23, 2025, at 13:27, Martin Uecker wrote:
>
> Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao:
>>
>>> On Jan 22, 2025, at 12:20, Martin Uecker wrote:
>>>
>>> Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker:
Am Mittwoch, dem 22.01.2025 um 16:37 +00
Ping patches 1-5 to Add more user friendly TARGET_ names for PowerPC:
Message-ID
Information for patch set:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669067.html
Patch #1, Change TARGET_POPCNTB to TARGET_POWER5:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669068.html
Ping patch to fix PR target/99293, Optimize splat of a V2DF/V2DI extract with
constant element:
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669136.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patches for adding intial dense math support to a potential future PowerPC
processor:
Explation of the patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670789.html
Patch 1 of 3, add wD constraint:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670790.html
Patch 2 of
Ping patch to fix PR target/117487, Add power9/power10 float to logical
operations
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669137.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Hello all,
The attached patch is straight forward. I spent more time on getting the
test case ready. Thanks Steve for finding this and narrowing down where
the problem was.
Regression tested on x86_64-linux-gnu.
OK for trunk? What about a backport to 14?
Regards,
Jerry
Author: Jerry DeLis
On 1/23/25 12:06 PM, Simon Martin wrote:
Hi Marek,
On 23 Jan 2025, at 16:45, Marek Polacek wrote:
On Thu, Jan 23, 2025 at 02:40:09PM +, Simon Martin wrote:
Hi Jason,
On 20 Jan 2025, at 22:49, Jason Merrill wrote:
On 1/20/25 2:11 PM, Simon Martin wrote:
Hi Jason,
On 15 Jan 2025, at 22
On 1/6/25 7:24 AM, Nathaniel Shead wrote:
Happy to defer this till GCC16 if preferred.
-- >8 --
This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
detection of TU-local lambdas. Now that LAMBDA_EXPR_EXTRA_SCOPE is
properly set for most lambdas we can use it to detect lambdas
On 1/23/25 5:45 AM, Jakub Jelinek wrote:
Hi!
After committing the append_ctor_to_tree_vector patch, I've realized
that for the larger constructors make_tree_vector_from_ctor unnecessarily
wastes one GC vector; make_tree_vector () / release_tree_vector () only
caches GC vectors from 4 to 16 alloc
Hello,
I agree about most of what you wrote, but I still prefer the version
without __self__. I would be fine with __self__ though, as long
as we can avoid delayed parsing. (For those who care, it I may be
helpful to add a comment to the clang discussion.)
I just add some brief comments.
A
On 1/23/25 11:45 AM, Marek Polacek wrote:
On Tue, Jan 21, 2025 at 05:09:32PM -0500, Jason Merrill wrote:
On 1/16/25 5:42 PM, Marek Polacek wrote:
On Wed, Jan 15, 2025 at 04:18:36PM -0500, Jason Merrill wrote:
On 1/15/25 12:55 PM, Marek Polacek wrote:
On Wed, Jan 15, 2025 at 09:39:41AM -0500,
Matthias Klose 于2025年1月23日周四 22:39写道：
>
LGTM.
81 matches
Mail list logo
