On 8/29/22 17:26, Marek Polacek wrote:
We've supported __is_nothrow_constructible since r11-4386, but
names_builtin_p didn't know about it, so it gave the wrong answer for
#if __has_builtin(__is_nothrow_constructible)
...
#endif
I've tested all C++-only built-ins and only two were
On 8/29/22 17:35, Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 05:15:26PM -0400, Jason Merrill wrote:
On 8/29/22 04:15, Jakub Jelinek wrote:
Hi!
The following patch introduces a new warning - -Winvalid-utf8 similarly
to what clang now has - to diagnose invalid UTF-8 byte sequences in
From: zhongjuzhe
gcc/ChangeLog:
* config/riscv/riscv.h (enum reg_class): Change vype to vtype.
---
gcc/config/riscv/riscv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 29582f7c545..3ee5a93ce6a 100644
---
On 8/27/22 7:47 PM, Peter Bergner via Gcc-patches wrote:
> On 8/27/22 4:37 PM, Segher Boessenkool wrote:
>>> The fix is to just remove the MMA pointer conversion
>>> handling code altogether.
>>
>> Okay for trunk and all backports. Thanks!
>
> Ok, pushed to trunk. I'll backport after some
From: zhongjuzhe
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_convert_vector_bits): Change
configuration according to TARGET_MIN_VLEN.
* config/riscv/riscv.h (UNITS_PER_FP_REG): Fix annotation.
---
gcc/config/riscv/riscv.cc | 11 ++-
gcc/config/riscv/riscv.h | 2 +-
On Mon, 29 Aug 2022 17:38:08 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Ping; any comments on this?
It looks fine to me, having an extra reuse pattern is pretty much free.
rv32iafc-ilp32 is compatible with rv32iac-ilp32 for library
implementation, so add a reuse rule allowing the default
Ping; any comments on this?
> rv32iafc-ilp32 is compatible with rv32iac-ilp32 for library
> implementation, so add a reuse rule allowing the default configuration
> to support rv32iafc.
On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
wrote:
>
>
> LLVM defines both __bpf__ and __BPF_ as target macros.
> GCC was defining only __BPF__.
>
> This patch defines __bpf__ as a target macro for BPF.
> Tested in bpf-unknown-none.
>
> gcc/ChangeLog:
>
> *
On Mon, Aug 29, 2022 at 11:35:44PM +0200, Jakub Jelinek wrote:
> I guess I should try what happens with 0x11 and 0x7fff in
> identifiers and string literals.
It is rejected in identifiers, but happily accepted in string literals:
const char32_t *a = U"";
const char32_t *b = U"��";
On Mon, Aug 29, 2022 at 05:15:26PM -0400, Jason Merrill wrote:
> On 8/29/22 04:15, Jakub Jelinek wrote:
> > Hi!
> >
> > The following patch introduces a new warning - -Winvalid-utf8 similarly
> > to what clang now has - to diagnose invalid UTF-8 byte sequences in
> > comments. In identifiers and
We've supported __is_nothrow_constructible since r11-4386, but
names_builtin_p didn't know about it, so it gave the wrong answer for
#if __has_builtin(__is_nothrow_constructible)
...
#endif
I've tested all C++-only built-ins and only two were missing.
Bootstrapped/regtested on
On 8/29/22 16:01, Marek Polacek wrote:
On Mon, Aug 29, 2022 at 01:32:29PM -0400, Jason Merrill wrote:
On 8/26/22 19:01, Marek Polacek wrote:
When we have
[[noreturn]] int fn1 [[nodiscard]](), fn2();
"noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1:
[dcl.pre]/3:
On 8/29/22 04:15, Jakub Jelinek wrote:
Hi!
The following patch introduces a new warning - -Winvalid-utf8 similarly
to what clang now has - to diagnose invalid UTF-8 byte sequences in
comments. In identifiers and in string literals it should be diagnosed
already but comment content hasn't been
Hello GCC team,
The following patch update BTF/CTF backend to support
BTF_KIND_ENUM64 type.
Comments will be welcomed and appreciated!,
Kind regards,
guillermo
--
BTF supports 64-bits enumerators with following encoding:
struct btf_type:
name_off: 0 or offset to a valid C identifier
Hi Tobias,
this is not really a review, but:
Am 26.08.22 um 20:21 schrieb Tobias Burnus:
I did run into some issues related to this; those turned out to be
unrelated, but I end ended up implementing this feature.
Side remark: 'omp parallel workshare' seems to actually permit 'nowait'
now, but
The upcoming work for frange triggers a regression in
gcc.dg/tree-ssa/phi-opt-24.c.
For -O2 -fno-signed-zeros, we fail to transform the following into -A:
float f0(float A)
{
// A == 0? A : -Asame as -A
if (A == 0) return A;
return -A;
}
This is because the abs/negative match.pd
> [changes from v1: simplify the new conditional logic as suggested.]
>
> The old method for computing a member index for a CO-RE relocation
> relied on a name comparison, which could SEGV if the member in question
> is itself part of an anonymous inner struct or union.
>
> This patch changes
[changes from v1: simplify the new conditional logic as suggested.]
The old method for computing a member index for a CO-RE relocation
relied on a name comparison, which could SEGV if the member in question
is itself part of an anonymous inner struct or union.
This patch changes the index
LLVM defines both __bpf__ and __BPF_ as target macros.
GCC was defining only __BPF__.
This patch defines __bpf__ as a target macro for BPF.
Tested in bpf-unknown-none.
gcc/ChangeLog:
* config/bpf/bpf.cc (bpf_target_macros): Define __bpf__ as a
target macro.
---
On 8/29/22 12:57, Jose E. Marchesi wrote:
>
> Hi David.
>
>> The old method for computing a member index for a CO-RE relocation
>> relied on a name comparison, which could SEGV if the member in question
>> is itself part of an anonymous inner struct or union.
>>
>> This patch changes the
Hi Jeff!
On Sun, 2022-08-28 15:32:53 -0600, Jeff Law via Gcc-patches
wrote:
> On 8/28/2022 1:50 AM, Jan-Benedict Glaw wrote:
> > On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches
> > wrote:
> > > This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> > > is
On Mon, Aug 29, 2022 at 01:32:29PM -0400, Jason Merrill wrote:
> On 8/26/22 19:01, Marek Polacek wrote:
> > When we have
> >
> >[[noreturn]] int fn1 [[nodiscard]](), fn2();
> >
> > "noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1:
> > [dcl.pre]/3: "The
Hi David.
> The old method for computing a member index for a CO-RE relocation
> relied on a name comparison, which could SEGV if the member in question
> is itself part of an anonymous inner struct or union.
>
> This patch changes the index computation to not rely on a name, while
>
On 8/29/22 19:07, Jeff Law via Gcc-patches wrote:
One of the more interesting ones is to try to limit the range of the
input to the trigonometric functions - that way you could use ones
without any argument reduction phase ...
The difficult part is that most of the trig stuff is in
The old method for computing a member index for a CO-RE relocation
relied on a name comparison, which could SEGV if the member in question
is itself part of an anonymous inner struct or union.
This patch changes the index computation to not rely on a name, while
maintaining the ability to account
Slightly revised version, fixing some issues in mkoffload.cc. Otherwise, the
same applies:
On 25.08.22 19:30, Tobias Burnus wrote:
On 25.08.22 16:54, Tobias Burnus wrote:
The attached patch prepare for reverse-offload device->host
function-address lookup by requesting (if needed) the on-device
> On Aug 29, 2022, at 1:07 PM, Jeff Law via Gcc-patches
> wrote:
>
> ...
> I guess we could do specialization based on the input range. So rather than
> calling "sin" we could call a special one that didn't have the reduction step
> when we know the input value is in a sensible range.
On 8/26/22 19:01, Marek Polacek wrote:
When we have
[[noreturn]] int fn1 [[nodiscard]](), fn2();
"noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1:
[dcl.pre]/3: "The attribute-specifier-seq appertains to each of
the entities declared by the declarators of the
On 8/29/2022 9:13 AM, Toon Moene wrote:
On 8/29/22 17:08, Jeff Law via Gcc-patches wrote:
However, I'm hoping to forget as many floating point details, as fast
as possible, as soon as I can ;-).
Actually FP isn't that bad -- I'd largely avoided it for decades, but
didn't have a choice
Hello,
On Sat, Aug 27 2022, Richard Biener wrote:
>> Am 26.08.2022 um 23:45 schrieb Martin Jambor :
>>
>> Hi,
>>
>>> On Fri, Aug 26 2022, Richard Sandiford wrote:
>>> Richard Biener writes:
> Am 26.08.2022 um 18:40 schrieb Martin Jambor :
>
> Hi,
>
> This adds a method to
On Mon, Aug 29, 2022 at 5:08 PM Jeff Law wrote:
>
>
>
> On 8/29/2022 8:26 AM, Aldy Hernandez wrote:
> > On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >> On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
> >>> On Mon, Aug 29, 2022 at 3:22 PM Jakub
On 8/29/22 17:08, Jeff Law via Gcc-patches wrote:
However, I'm hoping to forget as many floating point details, as fast
as possible, as soon as I can ;-).
Actually FP isn't that bad -- I'd largely avoided it for decades, but
didn't have a choice earlier this year. And there's a lot more
On 8/29/2022 8:26 AM, Aldy Hernandez wrote:
On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
wrote:
On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
On 8/29/22 16:36, Aldy Hernandez wrote:
On Mon, Aug 29, 2022 at 4:30 PM Toon Moene wrote:
On 8/29/22 16:15, Aldy Hernandez wrote:
But even with -ffinite-math-only, is there any benefit to propagating
a known NAN? For example:
The original intent (in 2002) for the option
The following sorts the immediate uses of a possibly uninitialized
SSA variable after their RPO order so we prefer warning for an
earlier occuring use rather than issueing the diagnostic for the
first uninitialized immediate use.
The sorting will inevitably be imperfect but it also allows us to
On Mon, Aug 29, 2022 at 4:30 PM Toon Moene wrote:
>
> On 8/29/22 16:15, Aldy Hernandez wrote:
>
> > But even with -ffinite-math-only, is there any benefit to propagating
> > a known NAN? For example:
>
> The original intent (in 2002) for the option -ffinite-math-only was for
> the optimizers to
On Mon, Aug 29, 2022 at 4:27 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 04:20:16PM +0200, Aldy Hernandez wrote:
> > Sure, I can add the HONOR_NANS, but can we even "see" a NAN in the IL
> > for -ffinite-math-only?
>
> Sure, you can, e.g. __builtin_nan{,s}{,f,l} etc. would do it.
> It
On 8/29/22 16:15, Aldy Hernandez wrote:
But even with -ffinite-math-only, is there any benefit to propagating
a known NAN? For example:
The original intent (in 2002) for the option -ffinite-math-only was for
the optimizers to ignore all the various exceptions to common
optimizations
On Mon, Aug 29, 2022 at 04:20:16PM +0200, Aldy Hernandez wrote:
> Sure, I can add the HONOR_NANS, but can we even "see" a NAN in the IL
> for -ffinite-math-only?
Sure, you can, e.g. __builtin_nan{,s}{,f,l} etc. would do it.
It would be UB to use it at runtime in -ffinite-math-only code though.
On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
> > On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
> >> On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
> >>> It seems to me we can do this
On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
It seems to me we can do this optimization regardless, but then treat
positive and negative zero the same
On Mon, Aug 29, 2022 at 4:17 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 04:08:58PM +0200, Aldy Hernandez wrote:
> > On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > > > For convenience, singleton_p()
On Mon, Aug 29, 2022 at 04:08:58PM +0200, Aldy Hernandez wrote:
> On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek wrote:
> >
> > On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > > For convenience, singleton_p() returns false for a NAN. IMO, it makes
> > > the implementation
Ping!
On 2022-08-15 15:23, Siddhesh Poyarekar wrote:
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since there's a
chance that the input may be too large, resulting in an unnecessary
overhead or worse, the input may
On Mon, Aug 29, 2022 at 4:08 PM Toon Moene wrote:
>
> On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote:
>
> > On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
>
> >> For convenience, singleton_p() returns false for a NAN. IMO, it makes
> >> the implementation cleaner, but I'm
On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > For convenience, singleton_p() returns false for a NAN. IMO, it makes
> > the implementation cleaner, but I'm not wed to the idea if someone
> > objects.
>
> If
On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
For convenience, singleton_p() returns false for a NAN. IMO, it makes
the implementation cleaner, but I'm not wed to the idea if someone
objects.
If singleton_p() is used
On 8/28/22 18:34, John David Anglin wrote:
> On 2022-08-26 3:15 a.m., Martin Liška wrote:
>> Removes the deprecated ports. If I'm correct all hpux9,hpux10 should be
>> removed
>> as they only provide 32-bit targets. On the contrary, hpux11 supports hppa64
>> that
>> we still do support.
> It is
On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> For convenience, singleton_p() returns false for a NAN. IMO, it makes
> the implementation cleaner, but I'm not wed to the idea if someone
> objects.
If singleton_p() is used to decide whether one can just replace a variable
with
Jakub, et al... here is the latest version of the frange endpoints
patch addressing the signed zero problem (well treating +-0.0
ambiguously), as well as implementing all the relational operators.
[Andrew M: I mostly copied our relop code from irange, while keeping
track NANs, etc. It should be
On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
> > It seems to me we can do this optimization regardless, but then treat
> > positive and negative zero the same throughout the frange class.
> > Particularly, in
On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
> It seems to me we can do this optimization regardless, but then treat
> positive and negative zero the same throughout the frange class.
> Particularly, in frange::singleton_p(). We should never return TRUE
> for any version of
On Fri, Aug 26, 2022 at 6:40 PM Jakub Jelinek wrote:
>
> On Fri, Aug 26, 2022 at 05:46:06PM +0200, Aldy Hernandez wrote:
> > On the true side of x == -0.0, we can't just blindly value propagate
> > the -0.0 into every use of x because x could be +0.0 (or vice versa).
> >
> > With this change, we
On Mon, 29 Aug 2022, Martin Jambor wrote:
> Hi,
>
> On Mon, Aug 29 2022, Richard Biener wrote:
> > On Mon, 29 Aug 2022, Martin Jambor wrote:
> >
> >> Hi again,
> >>
> >> On Mon, Aug 29 2022, Richard Biener wrote:
> >> > On Fri, 26 Aug 2022, Martin Jambor wrote:
> >> >
> >> >> Hi,
> >> >>
> >>
On Mon, 29 Aug 2022, Richard Biener wrote:
[...]
> The patch correctly diagnoses an uninitalized use of 'regnum'
> in store_bit_field_1 but also diagnoses an uninitialized use of
> best_match::m_best_candidate_len which I've chosen to silence
> without analyzing it in detail (I'm doing that
Currently the main working of the maybe-uninit pass is to scan over
all PHIs with possibly undefined arguments, diagnosing whether there's
a direct not guarded use. For not guarded uses in PHIs those are queued for
later processing and to make the uninit analysis PHI def handling work,
mark the
Hi,
On Mon, Aug 29 2022, Richard Biener wrote:
> On Mon, 29 Aug 2022, Martin Jambor wrote:
>
>> Hi again,
>>
>> On Mon, Aug 29 2022, Richard Biener wrote:
>> > On Fri, 26 Aug 2022, Martin Jambor wrote:
>> >
>> >> Hi,
>> >>
>> >> On Fri, Aug 26 2022, Richard Biener wrote:
>> >> >> Am 26.08.2022
On Mon, 29 Aug 2022, Martin Jambor wrote:
> Hi again,
>
> On Mon, Aug 29 2022, Richard Biener wrote:
> > On Fri, 26 Aug 2022, Martin Jambor wrote:
> >
> >> Hi,
> >>
> >> On Fri, Aug 26 2022, Richard Biener wrote:
> >> >> Am 26.08.2022 um 18:39 schrieb Martin Jambor :
> >> >>
> >> >> Hi,
> >>
I had this patch lying around since about half a year. I did tweak and
agumented it
a bit today, but finally want to get rid of it (locally - by getting it
committed) ...
This patch changes -misa to -march for nvptx (the latter is now an alias
for the former), it adds a new section about
On Tue, 5 Jul 2022, Richard Sandiford wrote:
> Tamar Christina writes:
> >> > so that the multiple_p test is skipped if the structure is undefined.
> >>
> >> Actually, we should probably skip the constant_multiple_p test as well.
> >> Keeping it would only be meaningful for little-endian.
> >>
Hi again,
On Mon, Aug 29 2022, Richard Biener wrote:
> On Fri, 26 Aug 2022, Martin Jambor wrote:
>
>> Hi,
>>
>> On Fri, Aug 26 2022, Richard Biener wrote:
>> >> Am 26.08.2022 um 18:39 schrieb Martin Jambor :
>> >>
>> >> Hi,
>> >>
>> >> This patch adds constructors of array_slice that are
-ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
and -fdebug-prefix-map. However, when building .S or .s files, gas is
not called with the appropriate --debug-prefix-map option when
-ffile-prefix-map is used.
While the user can specify -fdebug-prefix-map when building assembly
(Patch + RFC.)
OpenMP 5.2 has 'ompx' and (for fixed source form Fortran) 'omx'
as sentinel to provide a defined namespace for vendor extensions.
The behavior when encountering an unknown directive with ompx/omp sentinel
(or an unknown clause with ompx_ prefix) is implementation defined. For
Hi,
On Mon, Aug 29 2022, Richard Biener wrote:
> On Fri, 26 Aug 2022, Martin Jambor wrote:
>
>> Hi,
>>
>> On Fri, Aug 26 2022, Richard Biener wrote:
>> >> Am 26.08.2022 um 18:39 schrieb Martin Jambor :
>> >>
>> >> Hi,
>> >>
>> >> This patch adds constructors of array_slice that are required to
Hi!
The following patch introduces a new warning - -Winvalid-utf8 similarly
to what clang now has - to diagnose invalid UTF-8 byte sequences in
comments. In identifiers and in string literals it should be diagnosed
already but comment content hasn't been really verified.
I'm not sure if this is
On Fri, 26 Aug 2022, Martin Jambor wrote:
> Hi,
>
> On Fri, Aug 26 2022, Richard Biener wrote:
> >> Am 26.08.2022 um 18:39 schrieb Martin Jambor :
> >>
> >> Hi,
> >>
> >> This patch adds constructors of array_slice that are required to
> >> create them from non-const (heap or auto) vectors or
On Fri, 26 Aug 2022, Qing Zhao wrote:
>
>
> > On Aug 26, 2022, at 4:48 AM, Richard Biener wrote:
> >
> > On Wed, 17 Aug 2022, Qing Zhao wrote:
> >
> >> Add the following new option -fstrict-flex-array[=n] and a corresponding
> >> attribute strict_flex_array to GCC:
> >>
> >>
on 2022/8/15 16:33, Kewen.Lin via Gcc-patches wrote:
> on 2022/7/11 11:42, Kewen.Lin wrote:
>> on 2022/6/15 14:20, Kewen.Lin wrote:
>>> Hi Honza,
>>>
>>> Thanks for the comments! Some replies are inlined below.
>>>
>>> on 2022/6/14 19:37, Jan Hubicka wrote:
> Hi,
>
> Function
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html
I think this is a reasonable fix, the behavior is consistent with what we have
in
the previous built-in framework, I'm going to push this a week later if no
objections. :)
BR,
Kewen
> Hi,
>
> As
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html
I think this is a reasonable fix, the behavior is consistent with what we have
in
the previous built-in framework, I'm going to push this a week later if no
objections. :)
BR,
Kewen
>>>
on 2022/5/13 13:29,
On Thu, 18 Aug 2022 at 18:20, Prathamesh Kulkarni
wrote:
>
> On Thu, 18 Aug 2022 at 18:14, Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 17 Aug 2022 at 17:01, Richard Biener
> > wrote:
> > >
> > > On Tue, Aug 16, 2022 at 6:30 PM Richard Sandiford
> > > wrote:
> > > >
> > > > Prathamesh
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598601.html
BR,
Kewen
>
> on 2022/7/20 17:30, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one
>> unroll factor to be applied to vectorization factor when
>> vectorizing
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598748.html
BR,
Kewen
> on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
>> PR106345 shows, some test sources for some powerpc effective
>>
Hi Haochen,
on 2022/8/26 15:29, HAO CHEN GUI wrote:
> Hi,
> This patch changes the sequence of test directives for 3 cases. Originally,
> these 3 cases got failed or unsupported on some platforms, as their target
> selector checks depend on compiling options.
Maybe it's good to say more in the
On Wed, 17 Aug 2022 at 18:09, Prathamesh Kulkarni
wrote:
>
> Hi,
> The attached prototype patch extends fold_vec_perm to fold VEC_PERM_EXPR
> in VLA manner, and currently handles the following cases:
> (a) fixed len arg0, arg1 and fixed len sel.
> (b) fixed len arg0, arg1 and vla sel
> (c) vla
75 matches
Mail list logo
