On Jan 13, 2021, Alexandre Oliva wrote:
> On Jan 5, 2021, Alexandre Oliva wrote:
>> So this patch adds -mfpu=auto to the test, overriding any implicit
>> flags with the fpu implied by the arch.
>> * gcc.target/arm/simd/vmmla_1.c: Pass -mfpu=auto.
> Ping?
> https://gcc.gnu.org/pipermail/gcc-pa
Binary constants aren't mentioned individually in this list because
they are covered by the general wording about features previously
supported as extensions. Allowing duplicate standard attributes isn't
mentioned as it's considered a minor change of details of a feature
supported in GCC 10, rathe
Hi,
This patch is a small tidy-up of the intrinsics.def file to make it
clear that the parameters refer to INTRINSIC and BUILT_IN codes.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* d-tree.h (DEF_D_INTRINSIC):
On Fri, Feb 05, 2021 at 04:11:30PM +0100, Florian Weimer wrote:
> * Peter Bergner:
> > On 2/5/21 4:28 AM, Florian Weimer wrote:
> >> Maybe add a check that the compatibility builtins are flagged as
> >> availble using __has_builtin?
> >
> > Do you mean add a test in the testsuite for this? I can c
On Thu, Feb 04, 2021 at 10:05:19PM -0600, Peter Bergner wrote:
> On 2/4/21 3:16 PM, Segher Boessenkool wrote:
> > On Thu, Feb 04, 2021 at 02:40:20PM -0600, Peter Bergner wrote:
> >> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
> >> __builtin_mma_disassemble_pair built
On Fri, Feb 05, 2021 at 05:28:07PM +, Anthony Sharp wrote:
> Hi Marek,
>
> > Pedantically, "Altered function." is not very good, it should say what
> > in enforce_access changed.
>
> I would normally 100% agree, but the changes are a bit too complicated
> to be concisely (and helpfully) descr
On 05/02/2021 12:47, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi,
As mentioned in the PR, this patch fixes up the nvectors parameter passed to
vect_get_loop_mask in vectorizable_condition.
Before the STMT_VINFO_VEC_STMTS rework we used to handle each ncopy separately,
now we
Hi Marek,
> Pedantically, "Altered function." is not very good, it should say what
> in enforce_access changed.
I would normally 100% agree, but the changes are a bit too complicated
to be concisely (and helpfully) described there. I think the patch
description covers it well enough; not sure wha
(CC fortran@)
Hi Julian,
not doing an extensive review yet, but the following gives an ICE
with this patch applied. (I believe the others are already in, aren't they?)
type t
integer :: i, j
end type t
type t2
type(t) :: b(4)
end type
type(t2) :: var(10)
!$acc update host(var(3)%b(:)%j)
!$acc
Hi Tom!
Ping.
Grüße
Thomas
On 2021-01-22T16:23:57+0100, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2021-01-13T12:59:14+0100, I wrote:
>> Hi Tom!
>>
>> On 2020-10-09T13:56:09+0200, Tom de Vries wrote:
>>> The nvptx-as assembler verifies the ptx code using ptxas, if there's an
Hi,
a few comments:
On Fri, Feb 05, 2021 at 03:39:25PM +, Anthony Sharp via Gcc-patches wrote:
> 2021-02-05 Anthony Sharp
>
> * semantics.c (get_class_access_diagnostic_decl): New function.
> (enforce_access): Altered function.
Pedantically, "Altered function." is not very go
Sorry - last one had a formatting error. This one might be better.
Linux text editor doesn't consistently show whitespace for me!
On Fri, 5 Feb 2021 at 15:39, Anthony Sharp wrote:
>
> > I'm imagining member functions, i.e. A::f() and A2::f(int).
>
> You're right - good spot.
>
> > == is enough, i
> I'm imagining member functions, i.e. A::f() and A2::f(int).
You're right - good spot.
> == is enough, identifiers are unique.
Done.
> Agreed, but the using-declaration might not be introducing DECL. This
> would be another way to skip irrelevant usings.
Okie dokie.
New patch attached (tha
* Peter Bergner:
> On 2/5/21 4:28 AM, Florian Weimer wrote:
>> * Peter Bergner via Gcc-patches:
>>
>>> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
>>> __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
>>> __builtin_vsx_disassemble_pair res
On 2/5/21 4:28 AM, Florian Weimer wrote:
> * Peter Bergner via Gcc-patches:
>
>> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
>> __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
>> __builtin_vsx_disassemble_pair respectively. It's too late
On 2/4/21 6:10 PM, Marek Polacek wrote:
Here we ICE in finish_nonmember_using_decl -> lookup_using_decl ->
... -> find_namespace_slot because "name" is not an IDENTIFIER_NODE.
It is a BIT_NOT_EXPR because this broken test uses
using E::~E; // SCOPE::NAME
A using-decl can't refer to a destruc
On 2/4/21 6:09 PM, Marek Polacek wrote:
On Thu, Feb 04, 2021 at 03:47:54PM -0500, Jason Merrill via Gcc-patches wrote:
On 2/4/21 1:11 PM, Marek Polacek wrote:
On Thu, Feb 04, 2021 at 10:59:21AM -0500, Jason Merrill wrote:
On 2/3/21 7:03 PM, Marek Polacek wrote:
Since most of volatile is depre
> > We'd rather not have PR references in the source files, so please remove it
> > (it will be there as part of the commit log and git annotate).
> >
> > OK with the comment updated.
>
> Thanks, here's the revised patch.
OK, thanks.
> gcc/ada/
>
> 2021-02-05 Mikael Pettersson
>
> P
On Fri, 5 Feb 2021, Kyrylo Tkachov wrote:
> Hi Richard,
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Richard Biener
> > Sent: 01 October 2020 14:15
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] tree-optimization/97236 - fix bad use of
> > VMAT_CONTIGUOUS
> >
>
Hi Richard,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Richard Biener
> Sent: 01 October 2020 14:15
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] tree-optimization/97236 - fix bad use of
> VMAT_CONTIGUOUS
>
> This avoids using VMAT_CONTIGUOUS with single-element interleav
On Fri, Feb 5, 2021 at 9:35 AM Arnaud Charlet wrote:
>
> > This fixes the bootstrap failure with Ada on Cygwin since the switch
> > to C++11. The configure checks detect that fileno_unlocked () is
> > present, but when Ada's cstreams.c is compiled in C++11 mode,
> > does not declare it, causing a
On Fri, 5 Feb 2021, Richard Biener wrote:
> On Fri, 5 Feb 2021, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > On Fri, 5 Feb 2021, Richard Sandiford wrote:
> > >> Richard Biener writes:
> > >> > + /* First produce cost vectors sorted by loop index. */
> > >> > + auto_vec >
> > >
On Fri, 5 Feb 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > On Fri, 5 Feb 2021, Richard Sandiford wrote:
> >> Richard Biener writes:
> >> > + /* First produce cost vectors sorted by loop index. */
> >> > + auto_vec >
> >> > +li_scalar_costs (scalar_costs.length ());
> >> > +
On Thu, 4 Feb 2021 20:35:32 -0800
sunil.k.pandey wrote:
> On Linux/x86_64,
>
> 9a4d32f85ccebc0ee4b24e6d9d7a4f11c04d7146 is the first bad commit
> commit 9a4d32f85ccebc0ee4b24e6d9d7a4f11c04d7146
> Author: Julian Brown
> Date: Tue Feb 2 03:44:34 2021 -0800
>
> openacc: Allow strided arrays
Richard Biener writes:
> On Fri, 5 Feb 2021, Richard Sandiford wrote:
>> Richard Biener writes:
>> > + /* First produce cost vectors sorted by loop index. */
>> > + auto_vec >
>> > +li_scalar_costs (scalar_costs.length ());
>> > + auto_vec >
>> > +li_vector_costs (vector_costs.length
On Fri, 5 Feb 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > The following attempts to account for the fact that BB vectorization
> > regions now can span multiple loop levels and that an unprofitable
> > inner loop vectorization shouldn't be offsetted by a profitable
> > outer loop
On Thu, 4 Feb 2021 20:35:32 -0800
sunil.k.pandey wrote:
> On Linux/x86_64,
>
> b2d84e9f9cccbe4ee662f7002b83105629d09939 is the first bad commit
> commit b2d84e9f9cccbe4ee662f7002b83105629d09939
> Author: Julian Brown
> Date: Thu Feb 4 10:13:22 2021 -0800
>
> openacc: Tests for character
Hello.
As seen the flag -fpatchable-function-entry is properly marked as Optimization.
However, it's the argument is parsed early and stored into the following tuple:
; How many NOP insns to place at each function entry by default
Variable
HOST_WIDE_INT function_entry_patch_area_size
; And how
"Andre Vieira (lists)" writes:
> Hi,
>
> As mentioned in the PR, this patch fixes up the nvectors parameter passed to
> vect_get_loop_mask in vectorizable_condition.
> Before the STMT_VINFO_VEC_STMTS rework we used to handle each ncopy
> separately, now we gather them all at the same time and do
Richard Biener writes:
> The following attempts to account for the fact that BB vectorization
> regions now can span multiple loop levels and that an unprofitable
> inner loop vectorization shouldn't be offsetted by a profitable
> outer loop vectorization to make it overall profitable.
>
> For now
I'm sending Tom's patch that was approved by Jakub in the PR.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install it.
Thanks,
Martin
gcc/ChangeLog:
PR debug/98656
* tree-switch-conversion.c (jump_table_cluster::emit): Add loc
argu
Hi,
As mentioned in the PR, this patch fixes up the nvectors parameter passed to
vect_get_loop_mask in vectorizable_condition.
Before the STMT_VINFO_VEC_STMTS rework we used to handle each ncopy separately,
now we gather them all at the same time and don't need to multiply vec_num with
ncopies
The following attempts to account for the fact that BB vectorization
regions now can span multiple loop levels and that an unprofitable
inner loop vectorization shouldn't be offsetted by a profitable
outer loop vectorization to make it overall profitable.
For now I've implemented a heuristic based
* Peter Bergner via Gcc-patches:
> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
> __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
> __builtin_vsx_disassemble_pair respectively. It's too late to remove the
> old names, so this patch adds s
Hi Prathamesh,
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 05 February 2021 09:53
> To: gcc Patches ; Kyrylo Tkachov
>
> Subject: [PR97903][ARM] Missed optimization in lowering to vtst
>
> Hi,
> For the following test-case:
>
> #include
>
> uint8x8_t f1(int8x8_t a, int8x
GCC may be configured to use PIC by default, then the test with
-mno-abicall may fail. Just add -fno-PIC option for it.
---
gcc/testsuite/gcc.target/mips/compact-branches-5.c | 2 +-
gcc/testsuite/gcc.target/mips/compact-branches-6.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -
For R6+, it allows to configure gcc to use compact branches only.
---
gcc/config.gcc | 18 +-
gcc/doc/install.texi | 23 +++
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 17fea83b2e4..7d50e7995d2 10064
For MIPSr6, we may wish to use compact-branches only.
Currently, we have to use `always' option, while it is mark as conflict
with pre-R6.
cc1: error: unsupported combination: ‘mips32r2’ -mcompact-branches=always
It make some trouble for distributions to make -mcompact-branches=always
default fo
Hi,
For the following test-case:
#include
uint8x8_t f1(int8x8_t a, int8x8_t b) {
return (uint8x8_t) ((a & b) != 0);
}
gcc fails to lower test operation to vtst, and instead emits:
f1:
vandd0, d0, d1
vceq.i8 d0, d0, #0
vmvnd0, d0
bx lr
The attached
Hi Richard,
> -Original Message-
> From: Richard Biener
> Sent: 05 February 2021 09:25
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: Reimplement vget_low* intrinsics
>
> On Fri, Feb 5, 2021 at 9:59 AM Kyrylo Tkachov via Gcc-patches
> wrote:
> >
> >
On Fri, Feb 05, 2021 at 10:38:44AM +0100, Uros Bizjak wrote:
> > > --- gcc/config/i386/i386-options.c.jj 2021-01-14 19:34:06.041425286
> > > +0100
> > > +++ gcc/config/i386/i386-options.c 2021-02-04 16:30:18.424999701
> > > +0100
> > > @@ -98,6 +98,8 @@ along with GCC; see the file COPYING
On Fri, Feb 5, 2021 at 10:31 AM Uros Bizjak wrote:
>
> On Fri, Feb 5, 2021 at 10:29 AM Jakub Jelinek wrote:
> >
> > Hi!
> >
> > As written in the PR, TARGET_QIMODE_MATH was meant to be set for all
> > tunings and it was the case for GCC <= 7, but as the number of
> > PROCESSOR_* enumerators grew,
Hello.
Based on discussion with Richi, I'm re-sending the patch. Note that the patch
has been waiting for a review for almost one year and I would like to see
it in GCC 11.1.
Thank you,
Martin
>From 4cb8475a40464d5b7805ececb280bb2463d3caa4 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri,
On Fri, Feb 5, 2021 at 10:29 AM Jakub Jelinek wrote:
>
> Hi!
>
> As written in the PR, TARGET_QIMODE_MATH was meant to be set for all
> tunings and it was the case for GCC <= 7, but as the number of
> PROCESSOR_* enumerators grew, some AMD tunings (which are at the end
> of the list) over time got
Hi!
As written in the PR, TARGET_QIMODE_MATH was meant to be set for all
tunings and it was the case for GCC <= 7, but as the number of
PROCESSOR_* enumerators grew, some AMD tunings (which are at the end
of the list) over time got enumerators with values >= 32 and
TARGET_QIMODE_MATH became disabl
On Fri, Feb 5, 2021 at 9:59 AM Kyrylo Tkachov via Gcc-patches
wrote:
>
> Hi all,
>
> We can do better on the vget_low* intrinsics.
> Currently they reinterpret their argument into a V2DI vector and extract the
> low "lane",
> reinterpreting that back into the shorter vector.
> This is functionall
Hi all,
Similar to the vget_low* intrinsics we should just use a proper vec_select
rather than
going through V2DI subregs.
Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf.
Pushing to trunk.
Thanks,
Kyrill
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.
> This fixes the bootstrap failure with Ada on Cygwin since the switch
> to C++11. The configure checks detect that fileno_unlocked () is
> present, but when Ada's cstreams.c is compiled in C++11 mode,
> does not declare it, causing a hard error.
>
> Fixed by defining _GNU_SOURCE before including
Hi all,
We can do better on the vget_low* intrinsics.
Currently they reinterpret their argument into a V2DI vector and extract the
low "lane",
reinterpreting that back into the shorter vector.
This is functionally correct and generates a sequence of subregs and a
vec_select that, by itself,
gets
On Thu, Feb 4, 2021 at 11:18 PM Alexandre Oliva wrote:
>
> On Feb 4, 2021, Richard Biener wrote:
>
> >> > b) if expansion would use BY_PIECES then expand to an unrolled loop
> >>
> >> Why would that be better than keeping the constant-length memset call,
> >> that would be turned into an unroll
50 matches
Mail list logo
