Am Freitag, dem 15.09.2023 um 11:11 -0400 schrieb Marek Polacek:
> On Wed, Aug 30, 2023 at 10:46:14AM +0200, Martin Uecker wrote:
> > > Improving the security of software has been a major trend in the recent
> > > years. Fortunately, GCC offers a wide variety of flags that enable extra
> > >
Committed, thanks Robin.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Robin Dapp via Gcc-patches
Sent: Friday, September 15, 2023 11:44 PM
To: 钟居哲 ; Jeff Law ; kito.cheng
Cc: rdapp@gmail.com; gcc-patches ; kito.cheng
Subject: Re: [PATCH V4] RISC-V: Expand VLS mode to
On 9/15/23 12:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here convert_to_void always completes the type of an INDIRECT_REF or
VAR_DECL expression, but according to [expr.context] an lvalue-to-rvalue
conversion is applied to
On Sat, 16 Sep 2023, Jason Merrill wrote:
> On 9/15/23 13:55, Patrick Palka wrote:
> > This corrects decltype of a (class) NTTP object as per
> > [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case.
> > In the non-dependent case (nontype-class8.C) we resolve the decltype
> >
So when VN finds a name which has a nop conversion, it says
both names are equivalent to each other and the valuaization
function for one will return the other. This normally does not
cause any issues as there is no recusive matches. But after
r14-4038-gb975c0dc3be285, there was one added. So we
On 9/15/23 12:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
When constraining the visibility of an instantiation, we weren't
properly considering the visibility of PTRMEM_CST and TEMPLATE_DECL
template arguments.
On 9/13/23 13:53, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Since the LHS of a qualified-id is a non-deduced context, it effectively
means we can't deduce from outer template arguments of a class template
On 9/12/23 20:33, Patrick Palka wrote:
Bootstrpaped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
This simple patch extends the r12-3271-gf1e73199569287 optimization
to apply to deduction without explicit template arguments as well.
The motivation for this
On 9/13/23 13:53, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here more_specialized_partial_spec considers the two partial
specializations to be unordered ultimately because unify for identical
parm=arg=A::C returns failure due
On 9/15/23 13:55, Patrick Palka wrote:
This corrects decltype of a (class) NTTP object as per
[dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case.
In the non-dependent case (nontype-class8.C) we resolve the decltype
ahead of time, and finish_decltype_type already made sure to
On Sat, 16 Sep 2023, Jason Merrill wrote:
> On 9/15/23 12:03, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > Here convert_to_void always completes the type of an INDIRECT_REF or
> > VAR_DECL expression, but
This patch supports VLS reduction vectorization.
It can optimize the current reduction vectorization codegen with current COST
model.
#define DEF_REDUC_PLUS(TYPE)\
TYPE __attribute__ ((noinline, noclone))\
reduc_plus_##TYPE (TYPE * __restrict a, int n) \
{
Hi Richard,
> On 14 Sep 2023, at 11:18, Richard Biener wrote:
>
> On Wed, Sep 6, 2023 at 5:44 PM FX Coudert wrote:
>>
>> ping**2 on the revised patch, for Richard or another global reviewer. So far
>> all review feedback is that it’s a step forward, and it’s been widely used
>> for both
On 9/15/23 16:32, Marek Polacek wrote:
On Fri, Sep 15, 2023 at 02:08:46PM -0400, Jason Merrill wrote:
On 9/13/23 20:02, Marek Polacek wrote:
On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote:
On 9/13/23 16:56, Marek Polacek wrote:
On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason
在 2023/9/16 下午10:52, WANG Xuerui 写道:
Hi,
On 9/16/23 17:16, mengqinggang wrote:
The cost of lo_sum rtx for addi.d instruction my be a very big number if
computed by common function. It may cause some symbols saving to
stack and
loading from stack if there no enough registers during loop
`(a == CST) & a` can be either simplified to simplying `a == CST`
or 0 depending on the first bit of the CST.
This is an extension of the already pattern of `X & !X` and allows
us to remove the 2 xfails on gcc.dg/binop-notand1a.c and
gcc.dg/binop-notand4a.c.
OK? Bootstrapped and tested on
The cost of lo_sum rtx for addi.d instruction my be a very big number if
computed by common function. It may cause some symbols saving to stack and
loading from stack if there no enough registers during loop optimization.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
Hi,
On 9/16/23 17:16, mengqinggang wrote:
The cost of lo_sum rtx for addi.d instruction my be a very big number if
computed by common function. It may cause some symbols saving to stack and
loading from stack if there no enough registers during loop optimization.
Thanks for the patch! It
> Date: Tue, 29 Aug 2023 15:42:27 -0400
> From: Marek Polacek via Gcc-patches
> Surely, there must be no ABI impact, the option cannot cause
> severe performance issues,
> Currently, -fhardened enables:
...
> -ftrivial-auto-var-init=zero
> Thoughts?
Regarding -ftrivial-auto-var-init=zero, I
Hans-Peter Nilsson via Gcc-patches writes:
>> Date: Tue, 29 Aug 2023 15:42:27 -0400
>> From: Marek Polacek via Gcc-patches
>
>> Surely, there must be no ABI impact, the option cannot cause
>> severe performance issues,
>
>> Currently, -fhardened enables:
> ...
>>
20 matches
Mail list logo
