On Tue, 18 May 2021, Xionghu Luo wrote:
> Hi,
>
> On 2021/5/17 16:11, Richard Biener wrote:
> > On Fri, 14 May 2021, Xionghu Luo wrote:
> >
> >> Hi Richi,
> >>
> >> On 2021/4/21 19:54, Richard Biener wrote:
> >>> On Tue, 20 Apr 2021, Xionghu Luo wrote:
> >>>
>
>
> On 2021/4/15 19:
On Tue, May 18, 2021 at 1:23 AM Andrew MacLeod via Gcc-patches
wrote:
>
> The code in PR 100512 triggers an interaction between ranger and the
> propagation engine related to undefined values.
>
> I put the detailed analysis in the PR, but it boils down to the early
> VRP pass has concluded that s
On 5/17/21 3:15 PM, H.J. Lu via Gcc-patches wrote:
> Changes in the v3 patches:
>
> 1. Split the TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE changes
> into the generic part and the x86 part.
>
>
> 1. Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
> target instructio
On 5/17/21 7:55 PM, Jonathan Wakely wrote:
On 11/05/21 10:56 +0200, Martin Liška wrote:
Hello.
I'm going to push a commit that removes non-strict mode. It's useless right now.
Martin
contrib/ChangeLog:
* gcc-changelog/git_check_commit.py: Remove --non-strict-mode.
* gcc-changelog/git
On Sun, May 16, 2021 at 11:06 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> Instead of some of the more manual optimizations inside phi-opt,
> it would be good idea to do a lot of the heavy lifting inside match
> and simplify instead. In the process, this moves the three simple
Hi!
As mentioned earlier, spaceship_replacement didn't optimize partial_ordering
>= 0 comparisons, because the possible values are -1, 0, 1, 2 and the
>= comparison is implemented as (res & 1) == res to choose the 0 and 1
cases from that. As we optimize that only with -ffinite-math-only, the
2 ca
Which generates vpblendmb.
Bootstrapped/tested on x86_64-unknown-linux-gnu, pushed.
2021-05-18 Richard Biener
gcc/testsuite/
* gcc.target/i386/pr100582.c: Adjust for AVX512.
---
gcc/testsuite/gcc.target/i386/pr100582.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
This plugs a few easy holes avoiding ICEs down the route.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-05-18 Richard Biener
PR c/100522
gcc/c/
* gimple-parser.c (c_parser_gimple_postfix_expression_after_primary):
Diagnose calls to non-functions.
Hi!
Last year I've added cgraph_node::get_create calls for the dummy
functions used for -fdump-passes, so that it interacts well with pass
disabling/enabling which is cgraph uid based.
Unfortunately, as the following testcase shows, when assembler hash
is present, that wants to compute DECL_ASSEMB
On Tue, 18 May 2021, Jakub Jelinek wrote:
> Hi!
>
> As mentioned earlier, spaceship_replacement didn't optimize partial_ordering
> >= 0 comparisons, because the possible values are -1, 0, 1, 2 and the
> >= comparison is implemented as (res & 1) == res to choose the 0 and 1
> cases from that. As
On Tue, 18 May 2021, Jakub Jelinek wrote:
> Hi!
>
> Last year I've added cgraph_node::get_create calls for the dummy
> functions used for -fdump-passes, so that it interacts well with pass
> disabling/enabling which is cgraph uid based.
> Unfortunately, as the following testcase shows, when assem
Tested that locally with Ada and other languages.
Pushed to master,
Martin
gcc/ChangeLog:
* Makefile.in: genversion.o should depend on DATESTAMP.
---
gcc/Makefile.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 1b5d3f4696c.
gcc/
2021-05-18 Claudiu Zissulescu
* config/arc/simdext.md (negv2si2): Remove round bracket.
Signed-off-by: Claudiu Zissulescu
---
gcc/config/arc/simdext.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/arc/simdext.md b/gcc/config/arc/simdext.md
index
Hi!
The following testcase ICEs, because copyprop_hardreg_forward_1 decides
to DCE asm goto with REG_UNUSED notes (because the output is unused and
asm isn't volatile). But that DCE just removes the asm goto, leaving
a bb with two successors and no insn at the end that would allow that.
The foll
On Tue, 18 May 2021, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because copyprop_hardreg_forward_1 decides
> to DCE asm goto with REG_UNUSED notes (because the output is unused and
> asm isn't volatile). But that DCE just removes the asm goto, leaving
> a bb with two successors
On Thu, May 13, 2021 at 11:00 AM Martin Liška wrote:
>
> May I please ping this?
OK.
Please watch for fallout.
Richard.
> Martin
>
> On 3/19/21 10:21 AM, Martin Liska wrote:
> >
> > gcc/ChangeLog:
> >
> > * common/config/aarch64/aarch64-common.c (aarch64_parse_extension):
> > Use s
On Tue, May 18, 2021 at 3:27 AM sunil.k.pandey via Gcc-regression
wrote:
>
> On Linux/x86_64,
>
> e0a5daf81f2c79a0275eccd7c1a25349990a7a4d is the first bad commit
> commit e0a5daf81f2c79a0275eccd7c1a25349990a7a4d
> Author: Richard Biener
> Date: Mon May 17 13:56:14 2021 +0200
>
> middle-end
I find that when compiling some files, lra goes into an infinite loop
reloading constant
addresses. This patch allows them to just be recognized as matching addresses
immediately, which also saves a bit of space for a few other files.
Bootstrapped and regression tested on x86_64-pc-linux-gnu.
gcc
On Tue, 18 May 2021, Hongtao Liu wrote:
> On Tue, May 18, 2021 at 3:27 AM sunil.k.pandey via Gcc-regression
> wrote:
> >
> > On Linux/x86_64,
> >
> > e0a5daf81f2c79a0275eccd7c1a25349990a7a4d is the first bad commit
> > commit e0a5daf81f2c79a0275eccd7c1a25349990a7a4d
> > Author: Richard Biener
>
Hi,
On 2021/5/18 15:02, Richard Biener wrote:
> Can you, for the new gcc.dg/tree-ssa/ssa-sink-18.c testcase, add
> a comment explaining what operations we expect to sink? The testcase
> is likely somewhat fragile in the exact number of sinkings
> (can you check on some other target and maybe P8BE
On 18/05/21 09:31 +0200, Martin Liška wrote:
On 5/17/21 7:55 PM, Jonathan Wakely wrote:
On 11/05/21 10:56 +0200, Martin Liška wrote:
Hello.
I'm going to push a commit that removes non-strict mode. It's useless right now.
Martin
contrib/ChangeLog:
* gcc-changelog/git_check_commit.py: Rem
Pushed as obvious to master.
Martin
gcc/ChangeLog:
* config/gcn/mkoffload.c (STR): Redefine.
* config/i386/intelmic-mkoffload.c (STR): Likewise.
* config/nvptx/mkoffload.c (STR): Likewise.
---
gcc/config/gcn/mkoffload.c | 4 +++-
gcc/config/i386/intelmic-mkoff
On Tue, May 18, 2021 at 4:56 PM Richard Biener wrote:
>
> On Tue, 18 May 2021, Hongtao Liu wrote:
>
> > On Tue, May 18, 2021 at 3:27 AM sunil.k.pandey via Gcc-regression
> > wrote:
> > >
> > > On Linux/x86_64,
> > >
> > > e0a5daf81f2c79a0275eccd7c1a25349990a7a4d is the first bad commit
> > > comm
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k !=
On Fri, May 14, 2021 at 8:44 PM Tobias Burnus wrote:
>
> Fixes the build fail:
> ../../gcc/genversion.c:37:20: error: ‘BASEVER’ was not declared in this scope
> char basever[] = BASEVER;
> when doing a cross compilation.
>
> Cf. patch for details.
> OK for mainline?
OK.
Richard.
> (The runs
Excerpts from Lewis Hyatt via Gcc-patches's message of January 29, 2021 4:46 pm:
> Q1: What is the input charset?
> A1:
>
> libcpp: Whatever was passed to -finput-charset (note, for Fortran,
> -finput-charset is not supported though.)
>
> go: Assume UTF-8.
>
> D: UTF-8, UTF-16, o
This applies some TLC to mark_address_taken which ends up setting
TREE_ADDRESSABLE on nodes where it doesn't have any semantics.
It also does work (incomplete) that get_base_address already does,
likewise we'll never get WITH_SIZE_EXPR in this context and thus
get_base_address never fails.
Bootstr
This avoids setting TREE_ADDRESSABLE on variables we want to force to
the stack. Instead track those in a temporary bitmap and force
stack expansion that way, leaving TREE_ADDRESSABLE alone, not
pessimizing future alias queries.
Bootstrap and regtest running on x86_64-unknown-linux-gnu, comments
Hi!
On 2015-11-03T12:30:09+0100, I wrote:
> On Mon, 2 Nov 2015 14:40:54 +0100, Jakub Jelinek wrote:
>> On Mon, Nov 02, 2015 at 02:09:38PM +0100, Thomas Schwinge wrote:
>> > The OpenACC atomic directive matches OpenMP's atomic directive (got that
>> > clarified by the OpenACC committee), so they c
Richard Biener writes:
> @@ -6621,9 +6637,31 @@ pass_expand::execute (function *fun)
>(int) param_ssp_buffer_size);
> }
>
> + /* Temporarily mark PARM_DECLs and RESULT_DECLs we need to expand to
> + memory addressable so expand_function_start can emit the required
> +
On 5/18/21 12:30 AM, Joseph Myers wrote:
On Mon, 17 May 2021, Martin Liška wrote:
-@enumerate
-@item
-If you have chosen a configuration for GCC which requires other GNU
-tools (such as GAS or the GNU linker) instead of the standard system
-tools, install the required tools in the build directo
Excerpts from Martin Liska's message of March 17, 2021 4:36 pm:
>
> gcc/d/ChangeLog:
>
> * d-builtins.cc (do_build_builtin_fn): Use startswith
> function instead of strncmp.
> * dmd/dinterpret.c (evaluateIfBuiltin): Likewise.
> * dmd/dmangle.c: Likewise.
> * dmd/hdrg
On Fri, May 07, 2021 at 07:24:02PM -0500, Segher Boessenkool wrote:
> Looks good with those things tweaked.
Except that the patch chose the wrong section to emit the label,
because the decl is wrong. But of course I was using the same decl as
used in existing SHF_LINK_ORDER support, so it was alr
On Mon, May 10, 2021 at 04:39:55PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, May 07, 2021 at 12:19:52PM +0930, Alan Modra wrote:
> > PowerPC64 ELFv2 dual entry point functions have a couple of problems
> > with -fpatchable-function-entry. One is that the nops added after the
> > global e
On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
Normally we expect the gimple optimizers to fold away comparisons that
are always true, but at some lower optimization levels this is not
always the case, so the back-end has to be abl
On 2021-05-18 17:28, guojiufu via Gcc-patches wrote:
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would not happen. For example code:
foo (int
On Tue, 18 May 2021, Xionghu Luo wrote:
> Hi,
>
> On 2021/5/18 15:02, Richard Biener wrote:
> > Can you, for the new gcc.dg/tree-ssa/ssa-sink-18.c testcase, add
> > a comment explaining what operations we expect to sink? The testcase
> > is likely somewhat fragile in the exact number of sinkings
On Tue, 18 May 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > @@ -6621,9 +6637,31 @@ pass_expand::execute (function *fun)
> > (int) param_ssp_buffer_size);
> > }
> >
> > + /* Temporarily mark PARM_DECLs and RESULT_DECLs we need to expand to
> > + memory addre
Hi,
Using aarch64_pred_mov for these was tricky as it did both store and
load. Furthermore there was some concern it might allow for a predicated
mov to end up as a mem -> mem and a predicated load being wrongfully
reloaded to a full-load to register. So instead we decided to let the
extendin
Hi!
On 2020-11-30T12:28:31-0700, Jeff Law via Gcc-patches
wrote:
> On 11/24/20 2:53 AM, Thomas Schwinge wrote:
>> On 2020-11-06T10:26:46+0100, I wrote:
>>> On 2018-09-25T16:00:14-0400, David Malcolm wrote:
As noted at Cauldron, dumpfile.c currently emits "note: " for all kinds
of dump
Hi!
On Tue, May 18, 2021 at 07:43:49PM +0930, Alan Modra wrote:
> On Mon, May 10, 2021 at 04:39:55PM -0500, Segher Boessenkool wrote:
> > Huh, did it not already do that?! Hrm, all the other hooks seem to be
> > called via rs6000.c currently. But you do the same, so why do you need
> > to includ
On Tue, 18 May 2021, Richard Biener wrote:
> On Tue, 18 May 2021, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > @@ -6621,9 +6637,31 @@ pass_expand::execute (function *fun)
> > >(int) param_ssp_buffer_size);
> > > }
> > >
> > > + /* Temporarily mark PARM_DECLs an
On Tue, 18 May 2021, Richard Earnshaw wrote:
> On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> > On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
> > >
> > > Normally we expect the gimple optimizers to fold away comparisons that
> > > are always true, but at some lower optimization lev
On Tue, May 18, 2021 at 08:36:34AM +0200, Bernd Edlinger wrote:
> On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
> > Bootstrap and regtest pass on ppc64le. Is this ok for trunk?
> I've tried this patch and it does not seem to pass its own test:
>
> FAIL: gcc.dg/loop-split1.c scan-tree-dump
Richard Biener writes:
> On Tue, 18 May 2021, Richard Biener wrote:
>
>> On Tue, 18 May 2021, Richard Sandiford wrote:
>>
>> > Richard Biener writes:
>> > > @@ -6621,9 +6637,31 @@ pass_expand::execute (function *fun)
>> > > (int) param_ssp_buffer_size);
>> > > }
>> > >
>
Hi!
On 2021-05-03T19:03:24+0200, Tom de Vries wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c/target-44.c
> @@ -0,0 +1,27 @@
> +/* { dg-additional-options "-foffload=-latomic" { target {
> offload_target_nvptx } } } */
Causes issues if more than nvptx offloading compilation is enable
On 2021-05-18 18:32, guojiufu wrote:
On 2021-05-18 17:28, guojiufu via Gcc-patches wrote:
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would no
"Andre Vieira (lists)" writes:
> Hi,
>
> Using aarch64_pred_mov for these was tricky as it did both store and
> load. Furthermore there was some concern it might allow for a predicated
> mov to end up as a mem -> mem and a predicated load being wrongfully
> reloaded to a full-load to register.
Hi!
On 2021-05-07T12:05:11+0200, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c-c++-common/reduction-5.c
> @@ -0,0 +1,193 @@
> +/* { dg-additional-options "-foffload=-latomic" { target {
> offload_target_nvptx } } } */
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.
On 2021/5/17 10:26 PM, Julian Brown wrote:
OK, understood. But, I'm a bit concerned that we're ignoring some
"hidden rules" with regards to OMP pointer clause ordering/grouping that
certain code (at least the bit that creates GOMP_MAP_STRUCT node
groups, and parts of omp-low.c) relies on. I belie
On Fri, May 07, 2021 at 06:09:35PM +0200, David Lamparter wrote:
> The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> resulting in all information about the typedef's involvement getting
> lost. This drops necessary information for warnings and can make them
> confusing or eve
On 5/18/21 1:00 PM, Segher Boessenkool wrote:> On Tue, May 18, 2021 at
08:36:34AM +0200, Bernd Edlinger wrote:
>> On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
>>> Bootstrap and regtest pass on ppc64le. Is this ok for trunk?
>
>> I've tried this patch and it does not seem to pass its own
Hi!
On 2019-11-27T18:54:45+0100, I wrote:
> On 2019-11-14T18:22:39+0100, Jakub Jelinek wrote:
>> On Thu, Nov 14, 2019 at 05:18:41PM +, Andrew Stubbs wrote:
>>> On 14/11/2019 17:05, Jakub Jelinek wrote:
>>> > On Thu, Nov 14, 2019 at 04:47:49PM +, Andrew Stubbs wrote:
>>> > > This patch [..
On Tue, May 18, 2021 at 1:26 PM Richard Earnshaw via Gcc-patches
wrote:
>
>
>
> On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> > On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
> >>
> >> Normally we expect the gimple optimizers to fold away comparisons that
> >> are always true, but
On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/thread (jthread::_S_create): Fix static assert
> message.
> * testsuite/30_threads/jthread/95989.cc: Re-enable test.
> * testsuite/30_threads/jthread/jthread.cc: Do not re
On 5/18/21 1:55 PM, Bernd Edlinger wrote:
> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
>> libstdc++-v3/ChangeLog:
>>
>> * include/std/thread (jthread::_S_create): Fix static assert
>> message.
>> * testsuite/30_threads/jthread/95989.cc: Re-enable test.
>> * tests
Hello.
This patch add support for sized integer types.
Maybe it should check whether the size of a byte for the current
platform is 8 bits and do other checks so that they're only available
when it makes sense.
What do you think?
Thanks.
From d194a03fe3f2e8164c39413b79da9c43e236cf37 Mon Sep 17 00:0
On 5/18/21 12:07 PM, Iain Buclaw wrote:
Excerpts from Martin Liska's message of March 17, 2021 4:36 pm:
gcc/d/ChangeLog:
* d-builtins.cc (do_build_builtin_fn): Use startswith
function instead of strncmp.
* dmd/dinterpret.c (evaluateIfBuiltin): Likewise.
* dmd/dm
I had forgotten to update the documentation.
This new patch contains it.
Le mardi 18 mai 2021 à 08:23 -0400, Antoni Boucher a écrit :
> Hello.
> This patch add support for sized integer types.
> Maybe it should check whether the size of a byte for the current
> platform is 8 bits and do other chec
On Tue, May 18, 2021 at 08:23:56AM -0400, Antoni Boucher via Gcc-patches wrote:
> Hello.
> This patch add support for sized integer types.
> Maybe it should check whether the size of a byte for the current
> platform is 8 bits and do other checks so that they're only available
> when it makes sense
Hi!
On 2021-04-21T09:10:52-0600, Jeff Law via Gcc-patches
wrote:
> On 4/21/2021 6:56 AM, Richard Biener wrote:
>> libatomic isn't built for amdgcn but reduction-16.c adds it
>> via -foffload=-latomic when offloading for nvptx is enabled.
(ACK for that problem.)
>> The following avoids linker e
On Mon, May 17, 2021 at 5:56 PM Richard Sandiford
wrote:
>
> Hongtao Liu via Gcc-patches writes:
> > On Fri, May 14, 2021 at 10:27 AM Hongtao Liu wrote:
> >>
> >> On Thu, May 13, 2021 at 7:52 PM Richard Sandiford
> >> wrote:
> >> >
> >> > Jakub Jelinek writes:
> >> > > On Thu, May 13, 2021 at
On 2021-05-18 14:58, Richard Biener wrote:
On Mon, 17 May 2021, Ian Lance Taylor wrote:
On Mon, May 17, 2021 at 1:17 AM Richard Biener via Gcc-patches
wrote:
>
> On Fri, May 14, 2021 at 11:19 AM guojiufu via Gcc-patches
> wrote:
> >
> > On 2021-05-14 15:39, guojiufu via Gcc-patches wrote:
> >
split_double_mode calls simplify_gen_subreg, which fails for the
high half of the paradoxical subreg. Return temporary register
instead of NULL RTX in this case.
I was not able to construct a testcase without warnings.
2021-05-18 Uroš Bizjak
gcc/
PR target/100626
* config/i386/i386-e
On Tue, 18 May 2021, Thomas Schwinge wrote:
> Hi!
>
> On 2021-04-21T09:10:52-0600, Jeff Law via Gcc-patches
> wrote:
> > On 4/21/2021 6:56 AM, Richard Biener wrote:
> >> libatomic isn't built for amdgcn but reduction-16.c adds it
> >> via -foffload=-latomic when offloading for nvptx is enabled.
Fix a mode mismatch.
2021-05-18 Uroš Bizjak
gcc/
* config/i386/sse.md (v4qiv4di2):
Fix a mode mismatch with operand 1.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Pushed to master, will be backported to other release branches.
Uros.
diff --git a/gcc/config/i386/s
Hi!
Long ago we were forced to make some small ABI breaks to correct errors
in the implementation, and we added warning messages for the changes
from GCC 4.9 to GCC 5. Enough time has passed that these are now just
irritants, so let's remove them. Also clean up associated macros using
rs6000_spe
On 18.05.21 15:57, Richard Biener wrote:
Doh. So -foffload=default -foffloat=nvptx-none=-latomic maybe?
We really need a good documentation for -foffload= and something like
-foffload=default would be good as well – I think we currently only have
'disabled' and an explicit list. (Documentation
In the earlier commit r12-854 I forgot to also rewrite the other operator-
overload in terms of the split-out member function _M_distance_from.
Tested on x86_64-pc-linux-gnu, committed as obvious.
libstdc++-v3/ChangeLog:
PR libstdc++/100631
* include/std/ranges (elements_view::_S
Committed as r12-881-gcc193ac840d58ee0ffb57b14b542706cde3db0e7
I have done grepping and think that EXEC_OMP_DEPOBJ was the only one
missing.
(All ..._END_... are also missing but I think needed.)
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Regi
On 13 May 2021 09:24, Jeff Law wrote:
> On 5/11/2021 10:28 PM, Mike Frysinger via Gcc-patches wrote:
> > Nothing in gcc or binutils or gdb or anything anywhere uses these.
> >
> > config/
> >
> > * acinclude.m4 (CYG_AC_PATH_SIM, CYG_AC_PATH_DEVO): Delete.
>
> "DEVO", yea, that's old. I had a
Hongtao Liu via Gcc-patches writes:
> On Mon, May 17, 2021 at 5:56 PM Richard Sandiford
> wrote:
>> It looks like the rtx “used” flag is unused for INSNs, so we could
>> use that as a CALL_INSN flag that indicates a fake call. We could just
>> need to make:
>>
>> /* For all other RTXes cle
On 5/18/2021 9:08 AM, Mike Frysinger wrote:
On 13 May 2021 09:24, Jeff Law wrote:
On 5/11/2021 10:28 PM, Mike Frysinger via Gcc-patches wrote:
Nothing in gcc or binutils or gdb or anything anywhere uses these.
config/
* acinclude.m4 (CYG_AC_PATH_SIM, CYG_AC_PATH_DEVO): Delete.
"DEV
Add infrastructure, logic and arithmetic support for 4-byte vectors.
These can be used with SSE2 targets, where movd instructions from/to
XMM registers are available. x86_64 ABI passes 4-byte vectors in
integer registers, so also add logic operations with integer registers.
2021-05-18 Uroš Bizja
Hi,
As subject, this patch implements v[r]addhn2 and v[r]subhn2 Neon intrinsic
RTL patterns using a vec_concat of a register_operand and an ADDSUBHN
unspec - instead of just an ADDSUBHN2 unspec. This more relaxed pattern
allows for more aggressive combinations and ultimately better code
generation
Hi,
As subject, this patch implements saturating right-shift and narrow high
Neon intrinsic RTL patterns using a vec_concat of a register_operand
and a VQSHRN_N unspec - instead of just a VQSHRN_N unspec. This
more relaxed pattern allows for more aggressive combinations and
ultimately better code
On Tue, May 18, 2021 at 12:31 AM Bernd Edlinger
wrote:
>
> On 5/17/21 3:15 PM, H.J. Lu via Gcc-patches wrote:
> > Changes in the v3 patches:
> >
> > 1. Split the TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE changes
> > into the generic part and the x86 part.
> >
> >
> > 1. Add TARGET_READ_
Hi,
As subject, this patch uses UNSPEC_SQXTUN instead of UNSPEC_SQXTUN2
in the aarch64_sqxtun2 patterns. This allows for more more
aggressive combinations and ultimately better code generation - which will
be confirmed by a new set of tests in
gcc.target/aarch64/narrow_high_combine.c (patch 5/5 in
Hi!
Is the attached "Add '__OPTIMIZE__' DejaGnu selector" OK to push after
testing?
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
>From f2228df26acc303635
On 5/17/21 11:49 AM, H.J. Lu via Gcc-patches wrote:
On Thu, May 13, 2021 at 9:15 AM Bernd Edlinger
wrote:
On 5/13/21 3:37 PM, H.J. Lu via Gcc-patches wrote:
Warn for excessive argument alignment in main instead of ICE.
gcc/
PR c/100575
* cfgexpand.c (expand_stack_alignment): A
Hi,
As subject, this patch splits the aarch64_qshrn_n
pattern into separate scalar and vector variants. It further splits the vector
pattern into big/little endian variants that model the zero-high-half
semantics of the underlying instruction - allowing for more combinations
with the write-to-high
Hi,
As subject, this patch adds tests to confirm that a *2 (write to high-half)
Neon instruction is generated from vcombine* of a narrowing intrinsic
sequence.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-05-14 Jonathan Wright
* gcc.target/aarch64/narrow_high_
On Tue, May 18, 2021 at 09:09:07AM -0500, Bill Schmidt wrote:
> Long ago we were forced to make some small ABI breaks to correct errors
> in the implementation, and we added warning messages for the changes
> from GCC 4.9 to GCC 5. Enough time has passed that these are now just
> irritants, so let
On 5/18/21 3:22 AM, Richard Biener wrote:
On Tue, May 18, 2021 at 1:23 AM Andrew MacLeod via Gcc-patches
wrote:
The code in PR 100512 triggers an interaction between ranger and the
propagation engine related to undefined values.
I put the detailed analysis in the PR, but it boils down to the e
PR analyzer/100615 reports a missing leak diagnostic.
The issue is that the code calls strsep which the analyzer doesn't
have special knowledge of, and so conservatively assumes that it
could free the pointer, so drops malloc state for it.
Properly "teaching" the analyzer about strsep would requir
On 5/18/21 11:30 AM, Segher Boessenkool wrote:
On Tue, May 18, 2021 at 09:09:07AM -0500, Bill Schmidt wrote:
Long ago we were forced to make some small ABI breaks to correct errors
in the implementation, and we added warning messages for the changes
from GCC 4.9 to GCC 5. Enough time has passed
Am 2021-05-14 um 00:08 schrieb Marek Polacek via Gcc-patches:
On Wed, May 12, 2021 at 08:27:18PM -0400, Jason Merrill wrote:
On 5/12/21 8:03 PM, Marek Polacek wrote:
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 89f874a32cc..2bcefb619aa 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -
On Tue, May 18, 2021 at 07:35:52PM +0200, Franz Sirl wrote:
> Am 2021-05-14 um 00:08 schrieb Marek Polacek via Gcc-patches:
> > On Wed, May 12, 2021 at 08:27:18PM -0400, Jason Merrill wrote:
> > > On 5/12/21 8:03 PM, Marek Polacek wrote:
> > > > diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
> > > >
On 5/18/21 3:22 AM, Richard Biener wrote:
On Tue, May 18, 2021 at 1:23 AM Andrew MacLeod via Gcc-patches
wrote:
The code in PR 100512 triggers an interaction between ranger and the
propagation engine related to undefined values.
I put the detailed analysis in the PR, but it boils down to the e
On 5/18/2021 2:56 AM, Joern Rennecke wrote:
I find that when compiling some files, lra goes into an infinite loop
reloading constant
addresses. This patch allows them to just be recognized as matching addresses
immediately, which also saves a bit of space for a few other files.
Bootstrapped a
The generation of the new runtime check picked up the wrong attributes
in the case of CLASS array arguments. There is related new code in
gfc_conv_procedure_call which served as reference for the fix.
Regtested on x86_64-pc-linux-gnu.
OK for mainline / 11-branch?
Thanks,
Harald
Fortran: Fix e
On Linux/x86_64,
46ca31d65092e5afcef292f807fcf14c5363280d is the first bad commit
commit 46ca31d65092e5afcef292f807fcf14c5363280d
Author: Uros Bizjak
Date: Tue May 18 17:25:54 2021 +0200
i386: Implement 4-byte vector support [PR100637]
caused
FAIL: gcc.dg/vect/pr71264.c -flto -ffat-lto-o
On 5/13/21 6:08 PM, Marek Polacek wrote:
[ Repost from GCC 11 stage 3. Rebased onto current trunk. ]
I was looking at the LCOV coverage report for the C++ FE and
found a bunch of unused functions that I think we can remove.
Obviously, I left alone various dump_* and debug_* routines.
I haven't
It is only defined for i386 and everyone uses the default:
#define MAX_BITSIZE_MODE_ANY_INT (64*BITS_PER_UNIT)
Whatever problems we had before, they have been fixed now.
* config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): Removed.
---
gcc/config/i386/i386-modes.def | 15 +++---
To avoid stack realignment, use SCRATCH_SSE_REG to copy data from one
memory location to another.
gcc/
* config/i386/i386-expand.c (ix86_expand_vector_move): Use
SCRATCH_SSE_REG to copy data from one memory location to
another.
gcc/testsuite/
* gcc.target/i386/eh
Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target instructions to duplicate QImode value to TImode/OImode/XImode
value for memmset.
PR middle-end/90773
* builtins.c (builtin_memset_read_str): Call
targetm.read_memset_value.
(builtin_memset_g
Changes in the v4 patches:
1. Define x86 MAX_MOVE_MAX to 64, which is the constant maximum number
of bytes that a single instruction can move quickly between memory and
registers or between two memory locations.
2. Define x86 MOVE_MAX to MOVE_MAX_PIECES, which is the maximum number of
bytes we can
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/pr72839.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/pr72839.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr72839.c
b/gcc/
1. Make ix86_expand_vector_init_duplicate global to duplicate QImode
value to TImode/OImode/XImode.
2. Make ix86_minimum_incoming_stack_boundary global and add an argument
to ignore stack_alignment_estimated.
3. Define SCRATCH_SSE_REG as a scratch register for ix86_gen_memset_value.
4. Add TARGET_R
PR middle-end/90773
* gcc.target/i386/pr90773-20.c: New test.
* gcc.target/i386/pr90773-21.c: Likewise.
* gcc.target/i386/pr90773-22.c: Likewise.
* gcc.target/i386/pr90773-23.c: Likewise.
---
gcc/testsuite/gcc.target/i386/pr90773-20.c | 13 +
gcc
1 - 100 of 138 matches
Mail list logo
