On Wed, Feb 3, 2021 at 4:11 PM Alexandre Oliva wrote:
>
> On Feb 3, 2021, Richard Biener wrote:
>
> > So I think we should try to match what __builtin_memcpy/memset
> > expansion would do here, taking advantage of extra alignment
> > and size knowledge. In particular,
>
> > a) if __builtin_mem
Hi!
We ICE on the following testcase, for incomplete array a on auto [b] { a };
without
giving any kind of diagnostics, with auto [c] = a; during error-recovery.
The problem is that we get too far through check_initializer and e.g.
store_init_value -> constexpr stuff can't deal with incomplete ar
On Wed, Feb 3, 2021 at 6:12 PM Martin Sebor wrote:
>
> On 2/3/21 5:01 AM, Richard Biener wrote:
> > On Mon, Feb 1, 2021 at 5:20 PM Martin Sebor wrote:
> >>
> >> I have pushed the tree.h comments in g:6a2053773b8. I will wait
> >> for an approval of the changes to the manual.
> >
> > Sorry for no
On Thu, Feb 4, 2021 at 7:45 AM Uros Bizjak wrote:
>
> On Thu, Feb 4, 2021 at 5:28 AM Hongtao Liu wrote:
>
> > > > >GCC11 will be the system GCC 2 years from now, and for the
> > > > > processors then, they shouldn't even need to split a 256-bit vector
> > > > > into 2 128-bits vectors.
> > >
Hi!
The following patch uses make_signed_t instead of
make_signed::type in the diagnostics, because the former is shorter.
It is true that one can't use make_signed::type in C++11 code (which
is why I haven't changed it in the testcase which is c++11 effective
target), but the message talks about
On 2/3/21 4:34 PM, Marek Polacek wrote:
On Wed, Feb 03, 2021 at 04:15:24PM +0100, Martin Liška wrote:
The patch documents -mprefer-vector-width which is a valid target
attribute/pragma.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 8daa1c67974..a14875cec37 100644
--- a/gcc/doc
- Multi-lib only check the default argument is appeared in the multilib
flag list, but we didn't check the case that the flag is required but
default argument didn't provide.
- For example riscv*-rtems has a multilib set:
rv32imafd/ilp32d;@march=rv32imafd@mabi=ilp32d
And when we
Hi,
On Thu, Jan 28 2021, Richard Biener wrote:
> On Thu, Jan 28, 2021 at 7:32 AM Hongtao Liu via Gcc-patches
> wrote:
>>
>> Hi:
>>GCC11 will be the system GCC 2 years from now, and for the
>> processors then, they shouldn't even need to split a 256-bit vector
>> into 2 128-bits vectors.
>>
This issue came up when looking at Julian's OpenACC patches
and by coincidence it was also discussed for OpenMP
yesterday (lang-spec F2F meeting; Issue #2607).
OpenACC rather explicitly lists what counts as 'var' and
substrings do not appear there. While OpenMP is rather
silent on this issue; I t
On Thu, Feb 04, 2021 at 12:24:10PM +0100, Tobias Burnus wrote:
> This issue came up when looking at Julian's OpenACC patches
> and by coincidence it was also discussed for OpenMP
> yesterday (lang-spec F2F meeting; Issue #2607).
>
> OpenACC rather explicitly lists what counts as 'var' and
> substr
`__cpp_size_t_suffix` is defined as 202006L, but the draft standard says
202011L: http://eel.is/c++draft/cpp.predefined#tab:cpp.predefined.ft-row-48
From: Gcc-patches on behalf of Ed
Smith-Rowland via Gcc-patches
Sent: Tuesday, February 2, 2021 6:19
To:
On Thu, Feb 04, 2021 at 01:31:52PM +0800, Hongtao Liu via Gcc-patches wrote:
* gcc.target/i386/avx512vl-pr92686-vpcmp-1.c: This test is
used to guard code generation of integer mask comparison, but
for vector comparison to vector dest, integer mask comparison
is disl
This fixes us not costing vectorized bswap for SLP as well as
avoiding biasing to the vectorized side when costing single-argument
PHIs. Instead we assume coalescing here and cost them with zero cost
for both the scalar and vectorized code.
This doesn't fix the PR on its own.
Bootstrapped and te
Hi,
As subject, this patch rewrites [su]mull_high_n Neon intrinsics to use RTL
builtins rather than inline assembly code, allowing for better scheduling and
optimization.
Regression tested and bootstrapped on aarch64-none-linux-gnu and
aarch64_be-none-elf - no issues.
Ok for master?
Thanks,
Jon
Hi,
As subject this patch rewrites [su]mull_high_lane[q] Neon intrinsics to use RTL
builtins rather than inline assembly code, allowing for better scheduling and
optimization.
Regression tested and bootstrapped on aarch64-none-linux-gnu and
aarch64_be-none-elf - no issues.
Ok for master?
Thanks
> -Original Message-
> From: Jonathan Wright
> Sent: 04 February 2021 13:26
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH] aarch64: Use RTL builtins for [su]mull_high_n intrinsics
>
> Hi,
>
> As subject, this patch rewrites [su]mull_high_n Neon intrinsics to us
> -Original Message-
> From: Jonathan Wright
> Sent: 04 February 2021 13:30
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH] aarch64: Use RTL builtins for [su]mull_high_lane[q]
> intrinsics
>
> Hi,
>
> As subject this patch rewrites [su]mull_high_lane[q] Neon int
Hi Tobias,
Thanks for review! Comments below.
On Tue, 2 Feb 2021 17:32:03 +0100
Tobias Burnus wrote:
> > diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> > index 00358ca4d39..8d8da4593c3 100644
> > --- a/gcc/fortran/trans-openmp.c
> > +++ b/gcc/fortran/trans-openmp.c
> > @
Hi Julian,
LGTM. Thanks!
* * *
Can you as follow-up also add a testcase which uses – instead of integer –
'character' (with len > 1, both kind=1 and kind=4) and check that it is
handled correctly? In particular, that the right size is passed on.
(Should be size-in-bytes = kind*len.) It probabl
LGTM.
However, I'd feel better if there were a testcase, which actually
checks that it works correctly. (I think that means a
libgomp/testsuite/ run test.)
Tobias
On 02.02.21 14:28, Julian Brown wrote:
OpenACC 3.0 ("2.14.4. Update Directive") states:
Noncontiguous subarrays may appear. It
Hello,
New bugfix for PR19377
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377). This is
basically an extension of what I did before for PR17314 except it also
fixes this other bug.
I hope I didn't over-comment in the code ... better to say too much
than too little! It's a niche bug so I thoug
LGTM.
However, I'd feel better if there were a testcase, which actually
checks that it works correctly. (I think that means a
libgomp/testsuite/ run test.)
Tobias
On 02.02.21 14:28, Julian Brown wrote:
OpenACC 3.0 ("2.14.4. Update Directive") states:
Noncontiguous subarrays may appear. It
On 2/3/21 6:31 AM, Tom Greenslade (thomgree) via Gcc-patches wrote:
Update of https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562259.html
build_aggr_conv did not correctly handle string literal member initializers.
Extended can_convert_array to handle this case. For the additional check
Ping.
On 22/01/2021 11:42, Andrew Stubbs wrote:
Hi all, Jakub,
I need to implement DWARF for local variables that exist in an
alternative address space. This happens for OpenACC gang-private
variables (or will when the patches are committed) on AMD GCN, at least.
This is distinct from point
On 2/3/21 7:03 PM, Marek Polacek wrote:
Since most of volatile is deprecated in C++20, we are required to warn
for compound assignments to volatile variables and so on. But here we
have
volatile int x, y, z;
(b ? x : y) = 1;
and we shouldn't warn, because simple assignments like x = 24;
On 2/4/21 3:48 AM, Jakub Jelinek wrote:
Hi!
We ICE on the following testcase, for incomplete array a on auto [b] { a };
without
giving any kind of diagnostics, with auto [c] = a; during error-recovery.
The problem is that we get too far through check_initializer and e.g.
store_init_value -> con
On 2/4/21 3:53 AM, Jakub Jelinek wrote:
Hi!
The following patch uses make_signed_t instead of
make_signed::type in the diagnostics, because the former is shorter.
It is true that one can't use make_signed::type in C++11 code (which
is why I haven't changed it in the testcase which is c++11 effec
We used to check all unknown input files, even when passing them to a
compiler. But that caused problems. However, not erroring out on
non-existent would-be-linker inputs confuses configure machinery that
probes the compiler to see if it accepts various inputs. This
restores the access check fo
On 2/4/21 10:02 AM, Anthony Sharp via Gcc-patches wrote:
Hello,
New bugfix for PR19377
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377). This is
basically an extension of what I did before for PR17314 except it also
fixes this other bug.
I hope I didn't over-comment in the code ... better t
On 2/4/21 6:31 AM, Tam S. B. wrote:
`__cpp_size_t_suffix` is defined as 202006L, but the draft standard says
202011L: http://eel.is/c++draft/cpp.predefined#tab:cpp.predefined.ft-row-48
I looks like you're right. Both the latest draft and
https://isocpp.org/std/standing-documents/sd-6-sg10-fea
On 2/4/21 11:24 AM, Jason Merrill wrote:
On 2/4/21 10:02 AM, Anthony Sharp via Gcc-patches wrote:
Hello,
New bugfix for PR19377
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377). This is
basically an extension of what I did before for PR17314 except it also
fixes this other bug.
I hope I di
On 2/4/21 11:27 AM, Ed Smith-Rowland wrote:
On 2/4/21 6:31 AM, Tam S. B. wrote:
`__cpp_size_t_suffix` is defined as 202006L, but the draft standard
says 202011L:
http://eel.is/c++draft/cpp.predefined#tab:cpp.predefined.ft-row-48
I looks like you're right. Both the latest draft and
https://is
On 2/3/21 5:15 PM, Joseph Myers wrote:
On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote:
+/* Return true of T1 and T2 are matching types for the purposes of
+ redeclaring a variable or a function without a prototype (i.e.,
+ considering just its return type). */
I think this commen
> Yes, thanks; it would take a lot to make me request less comments.
Awesome.
> The second lines of arguments are indented one space too far in both these
> calls.
Oops! I will fix that.
> Well, I guess it could be using a declaration of the same name from another
> base.
Yes I had been wor
On Thu, Feb 04, 2021 at 11:03:10AM -0500, Jason Merrill wrote:
> > --- gcc/cp/decl.c.jj2021-01-28 16:13:04.0 +0100
> > +++ gcc/cp/decl.c 2021-02-03 15:57:16.980557836 +0100
> > @@ -6837,7 +6837,8 @@ check_initializer (tree decl, tree init,
> > /* We will have already complai
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 deprecated in C++20, we are required to warn
> > for compound assignments to volatile variables and so on. But here we
> > have
> >
> >volatile int x, y, z;
>
On 04/02/2021 11:01, Kito Cheng wrote:
gcc/ChangeLog:
* gcc.c (print_multilib_info): Check all required argument is provided
by default arg.
Thanks, with this patch the riscv-rtems* target works again.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
On 2/4/21 9:48 AM, Martin Sebor wrote:
On 2/3/21 5:15 PM, Joseph Myers wrote:
On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote:
+/* Return true of T1 and T2 are matching types for the purposes of
+ redeclaring a variable or a function without a prototype (i.e.,
+ considering just its
Adding Richard since he's reviewed the generic opaque mode code in
the past and this patch contains some more eneric support.
GCC handles pseudos that are used uninitialized, by emitting a
(set (reg: ) CONST0_RTX(regmode)) before their uninitialized
pseudo usage. Currently, CONST0_RTX(mode) is NU
Considering that most of the code is already new code it doesn't
look like a major tradeoff duplicate some more code.
So here is a new proposal with only new code. However I left the
new few XXX_tr methods accessible even in C++11 because I'll use them to
propose a fix for PR 98066 whe
PR c/97932 describes a bug in which diagnostic_show_locus prints most
of a source file.
The issue is that it prints a range in which the start and end locations
are part of the same macro map, but the start location is for a token in
the definition of the macro, whereas the end location is for a t
Hi!
On Mon, Nov 16, 2020 at 06:14:52PM -0500, David Edelsohn via Gcc-patches wrote:
> Jenkins does function on AIX. I will take an action item to create
> another LPAR on the AIX systems at OSUOSL for Jenkins and coordinate
> with you to connect it to the terrific Jenkins infrastructure for GCC
>
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 support for creating compatibility built-in
Nice when fixing a bug is as easy as removing incorrect checks.
gcc/cp/ChangeLog:
PR c++/98717
* constraint.cc (build_concept_check_arguments): Remove assert.
(build_concept_check): Allow empty args.
gcc/testsuite/ChangeLog:
PR c++/98717
* g++.dg/cpp2a/co
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 deprecated in C++20, we are required to warn
for compound assignments to volatile variables and so on. But here we
have
On 2/4/21 12:47 PM, Jakub Jelinek wrote:
On Thu, Feb 04, 2021 at 11:03:10AM -0500, Jason Merrill wrote:
--- gcc/cp/decl.c.jj2021-01-28 16:13:04.0 +0100
+++ gcc/cp/decl.c 2021-02-03 15:57:16.980557836 +0100
@@ -6837,7 +6837,8 @@ check_initializer (tree decl, tree init,
/*
On Thu, Feb 04, 2021 at 03:43:33PM -0500, Jason Merrill via Gcc-patches wrote:
> Nice when fixing a bug is as easy as removing incorrect checks.
>
> gcc/cp/ChangeLog:
>
> PR c++/98717
> * constraint.cc (build_concept_check_arguments): Remove assert.
> (build_concept_check): Allo
On 2/4/21 12:46 PM, Anthony Sharp wrote:
Yes, thanks; it would take a lot to make me request less comments.
Awesome.
The second lines of arguments are indented one space too far in both these
calls.
Oops! I will fix that.
Well, I guess it could be using a declaration of the same name fro
On Thu, 4 Feb 2021, Nathan Sidwell wrote:
> We used to check all unknown input files, even when passing them to a
> compiler. But that caused problems. However, not erroring out on
> non-existent would-be-linker inputs confuses configure machinery that
> probes the compiler to see if it ac
It seem that my recent patch for PR97701 for the trunk did not create
new problems. Therefore I am committing the following patch into
gcc-10-branch.
commit 4918937f4c76b05eaa331f8d6f2571e2fddcc22b (HEAD -> releases/gcc-10)
Author: Vladimir N. Makarov
Date: Thu Feb 4 15:57:55 2021 -0500
On Thu, 4 Feb 2021, Martin Sebor via Gcc-patches wrote:
> Okay, that's much simpler. Thanks for nudging me in the right
> direction! How's the attached patch? Retested on x86_64-linux.
OK, minus the addition of gcc/testsuite/c-c++-common/array-lit.s which
looks like a mistake.
--
Joseph S. M
Hi!
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-ins to __builtin_vsx_assemble_pair and
> __builtin_vsx_disassemble_pair respectively. It's too late to remove the
Hi!
On Thu, Feb 04, 2021 at 09:26:47PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 16, 2020 at 06:14:52PM -0500, David Edelsohn via Gcc-patches
> wrote:
> > Jenkins does function on AIX. I will take an action item to create
> > another LPAR on the AIX systems at OSUOSL for Jenkins and coordinate
>
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
The patch is for a new GCC extension -- asm goto with output reloads.
GCC splits inout operands (with constraint "+") into output and new
matched input operands during gimplfication. Addressing input or output
o
On Thu, Feb 4, 2021 at 4:26 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Thu, Feb 04, 2021 at 09:26:47PM +0100, Jakub Jelinek wrote:
> > On Mon, Nov 16, 2020 at 06:14:52PM -0500, David Edelsohn via Gcc-patches
> > wrote:
> > > Jenkins does function on AIX. I will take an action item to create
> >
Hi,
This patch merges the D front-end implementation with upstream dmd
46133f761, and the D runtime library with upstream druntime 0fd4364c.
Backports built-in function handling from upstream, adding a new
intrinsic `byteswap(ushort)`.
Intrinsic modules have been updated accordingly in the runti
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 unrolled loop during expand?
> Well, because of the possibly lost ctz and
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 deprecated in C++20, we are req
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 destructor, and lookup_using_decl already
checks t
On Thu, 4 Feb 2021 16:03:44 +0100
Tobias Burnus wrote:
> LGTM.
>
> However, I'd feel better if there were a testcase, which actually
> checks that it works correctly. (I think that means a
> libgomp/testsuite/ run test.)
Thanks! FYI, I've committed this version with an additional runtime
test.
On Thu, 4 Feb 2021 15:55:20 +0100
Tobias Burnus wrote:
> Hi Julian,
>
> LGTM. Thanks!
>
> * * *
>
> Can you as follow-up also add a testcase which uses – instead of
> integer – 'character' (with len > 1, both kind=1 and kind=4) and
> check that it is handled correctly? In particular, that th
On Thu, Jan 21, 2021 at 10:49 PM Kito Cheng wrote:
> I think this patch is small enough to accept without FSF copyright
> assignment, and he is also on the way of the process, what do you
> think?
>
I see the copyright assignments on file at the FSF when I checked today.
Jim
On Wed, Jan 27, 2021 at 4:40 AM Alexandre Oliva wrote:
> This patch attempts to fix a libgcc codegen regression introduced in
> gcc-10, as -ftree-loop-distribute-patterns was enabled at -O2.
>
> RISC-V doesn't have any setmemM pattern, so the loops above end up
> "optimized" into memset calls, in
On Thu, Feb 4, 2021 at 4:52 PM Richard Biener
wrote:
>
> On Thu, Feb 4, 2021 at 7:45 AM Uros Bizjak wrote:
> >
> > On Thu, Feb 4, 2021 at 5:28 AM Hongtao Liu wrote:
> >
> > > > > >GCC11 will be the system GCC 2 years from now, and for the
> > > > > > processors then, they shouldn't even need
On Thu, Feb 4, 2021 at 8:00 PM Jakub Jelinek wrote:
>
> On Thu, Feb 04, 2021 at 01:31:52PM +0800, Hongtao Liu via Gcc-patches wrote:
> * gcc.target/i386/avx512vl-pr92686-vpcmp-1.c: This test is
> used to guard code generation of integer mask comparison, but
> for vector com
On Thu, Feb 4, 2021 at 2:02 AM Kito Cheng wrote:
> * gcc.c (print_multilib_info): Check all required argument is
> provided
> by default arg.
>
This looks OK to me, but...
>
> - /* If this directory requires any default arguments, we can skip
> + /* If this directory r
On 2/4/21 3:16 PM, Segher Boessenkool wrote:
> Hi!
>
> 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-ins to __builtin_vsx_assemble_pair and
>> __builtin_vsx_disas
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 in update directives
caused
FAIL: gfortran.dg/goacc/array-with-dt-2.f90
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 types in derived-type mappings
caused
FAIL: gfortran.dg/goacc/derived-ch
Thanks Jim, committed with your revision of comment :)
On Fri, Feb 5, 2021 at 11:28 AM Jim Wilson wrote:
>
> On Thu, Feb 4, 2021 at 2:02 AM Kito Cheng wrote:
>>
>> * gcc.c (print_multilib_info): Check all required argument is
>> provided
>> by default arg.
>
>
> This looks OK to
70 matches
Mail list logo
