[RFC] split pseudos during loop unrolling in RTL unroller

Hi, As you may know, we have loop unroll pass in RTL which was introduced a few years ago, and works for a long time. Currently, this unroller is using the pseudos in the original body, and then the pseudos are written multiple times. It would be a good idea to create new pseudos for those

Re: [PATCH] xtensa: fix PR target/94584

On Tue, Apr 14, 2020 at 4:40 PM augustine.sterl...@gmail.com wrote: > > On Mon, Apr 13, 2020 at 4:39 PM Max Filippov wrote: > > 2020-04-13 Max Filippov > > gcc/ > > * config/xtensa/xtensa.md (zero_extendhisi2, zero_extendqisi2) > > (extendhisi2_internal): Add %v1 before the

Re: [PATCH] gcc/gcc.c: add outfiles spec

On Tue, 14 Apr 2020, Rasmus Villemoes wrote: > On 06/04/2020 23.18, Joseph Myers wrote: > > On Sat, 4 Apr 2020, Rasmus Villemoes wrote: > > > >> +#ifndef OUTFILES_SPEC > >> +#define OUTFILES_SPEC "%o" > >> +#endif > > > > A new target macro needs to be documented in tm.texi.in, > > Will do. >

Re: [PATCH] xtensa: fix PR target/94584

On Mon, Apr 13, 2020 at 4:39 PM Max Filippov wrote: > 2020-04-13 Max Filippov > gcc/ > * config/xtensa/xtensa.md (zero_extendhisi2, zero_extendqisi2) > (extendhisi2_internal): Add %v1 before the load instructions. > > gcc/testsuite/ > * gcc.target/xtensa/pr94584.c: New

[committed] libstdc++: Fix constraints on std::compare_three_way

My "simplification" of std::compare_three_way's constraints in commit f214ffb336d582a66149068a2a96b7fcf395b5de was incorrect, because std::three_way_comparable_with imposes additional restrictions beyond the <=> expression being valid. * libsupc++/compare (compare_three_way): Fix

Re: [PATCH], Fix target/94557 PowerPC regression on GCC 9 (variable vec_extract)

On Tue, Apr 14, 2020 at 07:39:44AM -0500, Segher Boessenkool wrote: > Hi, > > On Mon, Apr 13, 2020 at 10:24:39PM -0400, Michael Meissner wrote: > > This patch fixes PR target/94557, on PowerPC. It was a regression on the > > GCC 9 > > branch caused by my recent patch for PR target/93932. > > >

[committed] libstdc++: Add comparison operators to std::shared_ptr (PR 94562)

This also implements the proposed resolution to LWG issue 3247, so that the ill-formed <=> expression with nullptr is not used. PR libstdc++/94562 * include/bits/shared_ptr.h (operator<=>): Define for C++20. * include/bits/shared_ptr_base.h (operator<=>): Likewise.

Re: [PATCH v2] Fix use of singleton in optinfo framework

I have already bisected GCC 10 issue here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 The problem is commit 634afa05a8cbff010480088811fe1f39eca70c1d. On 20-04-14 21:11:01, Iain Sandoe wrote: Gerald Pfeifer wrote: On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote:

Re: [PATCH v2] Fix use of singleton in optinfo framework

Gerald Pfeifer wrote: On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote: gcc/Changelog: 2020-04-06 Gustavo Romero * dumpfile.c: (selftest::temp_dump_context::temp_dump_context): Fix ctor. If you approve (David, Jakub, or someone else) I can take care of committing

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

Rainer Orth wrote: >> Rainer Orth wrote: On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote: > Unfortunately, several targets have ABI constraints that prevent > an indirect tail-call, which results in the PRs compile error. >> >> So .. after scanning the current

[committed] c++: Add testcase for PR c++/93207

gcc/testsuite/ChangeLog: PR c++/93207 * g++.dg/concepts/variadic5.C: New test. --- gcc/testsuite/g++.dg/concepts/variadic5.C | 26 +++ 1 file changed, 26 insertions(+) create mode 100644 gcc/testsuite/g++.dg/concepts/variadic5.C diff --git

Re: [PATCH] c++: "'decltype_type' not supported" in diagnostic [PR85278]

On 4/14/20 11:46 AM, Patrick Palka wrote: This fixes a garbled concepts diagnostic by moving the handling of DECLTYPE_TYPE from pp_cxx_type_specifier_seq to cxx_pretty_printer::simple_type_specifier, a move which also seems to be more consistent with the language grammar. This patch also fixes

Re: [PATCH]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

Kyrylo Tkachov writes: > - if (!REG_P (addr.base)) > + if (addr.type == ADDRESS_SYMBOLIC || !REG_P (addr.base)) > return false; > > Hmm, given that the code below only handles the ADDRESS_REG_* forms, how > about we get defensive here and check that addr.type is not one of >

RE: [PATCH]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

Hi Andrea, > -Original Message- > From: Andrea Corallo > Sent: 14 April 2020 11:01 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ; nd ; > Christophe Lyon > Subject: [PATCH]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for > use of uninitialized value > > Hi all, > >

[PATCH] testsuite: Add check_effective_target_d_runtime_has_std_library procedure

Hi, This patch adds an effect target d_runtime_has_std_library to target-supports.exp, and some preliminary uses of it. The current check_effective_target_d_runtime procedure returns false if the target is without any core runtime library for D. This additional procedure is for targets where

[PATCH] c++: "'decltype_type' not supported" in diagnostic [PR85278]

This fixes a garbled concepts diagnostic by moving the handling of DECLTYPE_TYPE from pp_cxx_type_specifier_seq to cxx_pretty_printer::simple_type_specifier, a move which also seems to be more consistent with the language grammar. This patch also fixes pretty printing of rvalue reference types

Re: [PR C++ 94426] Lambda linkage

Hi Nathan, Nathan Sidwell wrote: > My fix for 94147 was confusing no-linkage with internal linkage, at the > language level. That's wrong. (the std is confusing here, because it > describes linkage of names (which is wrong), and lambdas have no names) > > Lambdas with extra-scope, have

Re: [PATCH] RTEMS: Improve GCC specification

Hello Jeff, On 08/04/2020 22:24, Jeff Law wrote: On Wed, 2020-04-08 at 19:47 +0200, Sebastian Huber wrote: Add a start/end file specification if the -qrtems option is present. Allow targets to customize it. Support the standard -nodefaultlibs option. gcc/ * config/rtems.h

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

> > But we're using it in indirect_ref_may_alias_decl_p as > > /* If second reference is view-converted, give up now. */ > if (same_type_for_tbaa (TREE_TYPE (dbase2), TREE_TYPE (ptrtype2)) != > 1) > return true; > > and clearly if TREE_TYPE (ptrtype2) is void * while

Re: [PATCH] wwwdocs: Slightly improve IPA-SRA description in gcc-10/changes.html

On Tue, 14 Apr 2020, Martin Jambor wrote: > I think that the fact that IPA-SRA can now remove unused return > values deserves a special mention - and I also fixed the proposition > in the name of the pass. > > OK for wwwdocs? Yes, thank you. A small recommendation: > + The

Re: [PATCH] wwwdocs: Deprecate offloading to HSAIL

On Tue, 14 Apr 2020, Martin Jambor wrote: > for reasons described in my earlier email, I'd like to commit the > following to gcc-10/changes.html to mark offloading to HSAIL as > deprecated. > > OK? Yes, thank you. Though given what I saw/understand, you could write "...will likely be removed in

Re: [PATCH] wwwdocs: Slightly improve IPA-SRA description in gcc-10/changes.html

On Tue, Apr 14, 2020 at 4:19 PM Martin Jambor wrote: > > Hi, > > I think that the fact that IPA-SRA can now remove unused return > values deserves a special mention - and I also fixed the proposition > in the name of the pass. > > OK for wwwdocs? > > Thanks, > > Martin > > > --- >

Re: [PATCH] wwwdocs: Deprecate offloading to HSAIL

On Tue, Apr 14, 2020 at 4:17 PM Martin Jambor wrote: > > Hi, > > for reasons described in my earlier email, I'd like to commit the > following to gcc-10/changes.html to mark offloading to HSAIL as > deprecated. > > OK? OK. Richard. > Thanks, > > Martin > > > --- > htdocs/gcc-10/changes.html |

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

On Tue, 14 Apr 2020, Jan Hubicka wrote: > > > > Note that now, looking again, the TYPE_STRUCTURAL_EQUALITY_P in my patch > > doesn't match that of get_alias_set. Since we're looking at the alias > > sets of type1 and type2 anyway we could resort to alias_sets_conflict_p > > for the two

[PATCH] wwwdocs: Deprecate offloading to HSAIL

Hi, for reasons described in my earlier email, I'd like to commit the following to gcc-10/changes.html to mark offloading to HSAIL as deprecated. OK? Thanks, Martin --- htdocs/gcc-10/changes.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/gcc-10/changes.html

[PATCH] wwwdocs: Slightly improve IPA-SRA description in gcc-10/changes.html

Hi, I think that the fact that IPA-SRA can now remove unused return values deserves a special mention - and I also fixed the proposition in the name of the pass. OK for wwwdocs? Thanks, Martin --- htdocs/gcc-10/changes.html | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff

[committed] testsuite: Add testcase for already fixed PR [PR94573]

Hi! The following testcase is optimized since Eric's r10-3575 change. Tested on x86_64-linux -m32/-m64 (and in 9 where it FAILs), committed to trunk as obvious. 2020-04-14 Jakub Jelinek PR tree-optimization/94573 * gcc.dg/store_merging_30.c: New test. ---

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

Hi Iain, > Rainer Orth wrote: >>> >>> On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote: Unfortunately, several targets have ABI constraints that prevent an indirect tail-call, which results in the PRs compile error. > > So .. after scanning the current published testsuite

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

> > Note that now, looking again, the TYPE_STRUCTURAL_EQUALITY_P in my patch > doesn't match that of get_alias_set. Since we're looking at the alias > sets of type1 and type2 anyway we could resort to alias_sets_conflict_p > for the two POINTER_TYPE_P case and return -1 then. Not sure about >

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

Hi Rainer, Rainer Orth wrote: On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote: Unfortunately, several targets have ABI constraints that prevent an indirect tail-call, which results in the PRs compile error. So .. after scanning the current published testsuite results I have:

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On Tue, 14 Apr 2020, Jason Merrill wrote: > On 4/14/20 9:01 AM, Patrick Palka wrote: > > On Tue, 14 Apr 2020, Patrick Palka wrote: > > > > > On Mon, 13 Apr 2020, Jason Merrill wrote: > > > > > > > On 4/13/20 2:49 PM, Patrick Palka wrote: > > > > > On Mon, 13 Apr 2020, Jason Merrill wrote: > > >

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/14/20 9:01 AM, Patrick Palka wrote: On Tue, 14 Apr 2020, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/13/20 2:49 PM, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/12/20 9:43 AM, Patrick Palka wrote: On Sat, 11 Apr 2020, Jason Merrill

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

On Tue, 14 Apr 2020, Jan Hubicka wrote: > > On Tue, 14 Apr 2020, Richard Sandiford wrote: > > > > > Richard Biener writes: > > > > This makes same_type_for_tbaa_p conservative in the same way > > > > get_alias_set is about void * which we allow to alias all other > > > > pointers. > > > > > > >

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/14/20 12:29 AM, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/13/20 2:49 PM, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/12/20 9:43 AM, Patrick Palka wrote: On Sat, 11 Apr 2020, Jason Merrill wrote: On 4/10/20 5:47 PM, Patrick Palka

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

> On Tue, 14 Apr 2020, Richard Sandiford wrote: > > > Richard Biener writes: > > > This makes same_type_for_tbaa_p conservative in the same way > > > get_alias_set is about void * which we allow to alias all other > > > pointers. > > > > > > Bootstrap & regtest running on

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On Tue, 14 Apr 2020, Patrick Palka wrote: > On Mon, 13 Apr 2020, Jason Merrill wrote: > > > On 4/13/20 2:49 PM, Patrick Palka wrote: > > > On Mon, 13 Apr 2020, Jason Merrill wrote: > > > > > > > On 4/12/20 9:43 AM, Patrick Palka wrote: > > > > > On Sat, 11 Apr 2020, Jason Merrill wrote: > > > >

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

On Tue, 14 Apr 2020, Richard Sandiford wrote: > Richard Biener writes: > > This makes same_type_for_tbaa_p conservative in the same way > > get_alias_set is about void * which we allow to alias all other > > pointers. > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu. > > > >

Re: [PATCH] i386: Remove mode size check in ix86_get_ssemov

On Sat, Apr 11, 2020 at 02:48:22PM -0700, H.J. Lu via Gcc-patches wrote: > Even though ix86_hard_regno_mode_ok doesn't allow xmm16-xmm31 nor > ymm16-ymm31 in 128/256 bit modes when AVX512VL is disabled, reload > can still generate reg to reg moves with xmm16-xmm31 and ymm16-ymm31 > in 128/256 bit

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

Richard Biener writes: > This makes same_type_for_tbaa_p conservative in the same way > get_alias_set is about void * which we allow to alias all other > pointers. > > Bootstrap & regtest running on x86_64-unknown-linux-gnu. > > Honza, is this what you had in mind? > > Thanks, > Richard. > >

Re: [PATCH 2/5] testsuite: [arm/mve] Use arm_softfp and arm_hard as needed in MVE tests

On Tue, 14 Apr 2020 at 10:21, Andre Vieira (lists) < andre.simoesdiasvie...@arm.com> wrote: > On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote: > > Some MVE tests explicitly test a -mfloat-abi=hard option, but we need > > to check that the toolchain actually supports it (which may not

Re: [PATCH], Fix target/94557 PowerPC regression on GCC 9 (variable vec_extract)

Hi, On Mon, Apr 13, 2020 at 10:24:39PM -0400, Michael Meissner wrote: > This patch fixes PR target/94557, on PowerPC. It was a regression on the GCC > 9 > branch caused by my recent patch for PR target/93932. > > The patch for 93932 was a back port from the master branch of a fix for the >

Re: [PATCH] gcc/gcc.c: add outfiles spec

On 06/04/2020 23.18, Joseph Myers wrote: > On Sat, 4 Apr 2020, Rasmus Villemoes wrote: > >> +#ifndef OUTFILES_SPEC >> +#define OUTFILES_SPEC "%o" >> +#endif > > A new target macro needs to be documented in tm.texi.in, Will do. > with tm.texi then being regenerated. Please include information

Re: [PATCH PR94574] ICE during GIMPLE pass: ccp

On Tue, Apr 14, 2020 at 1:57 PM yangyang (ET) wrote: > > Hi, > > > -Original Message- > > From: Richard Biener [mailto:richard.guent...@gmail.com] > > Sent: Tuesday, April 14, 2020 4:44 PM > > To: yangyang (ET) > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [PATCH PR94574] ICE during

[PATCH] Add myself as callgraph (IPA) reviewer

Hi, On Mon, Apr 13 2020, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Martin Jambor as GCC IPA Reviewer. > > Please join me in congratulating Martin on his new role. > Martin, please update your listing in the MAINTAINERS file. >

RE: [PATCH PR94574] ICE during GIMPLE pass: ccp

Hi, > -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: Tuesday, April 14, 2020 4:44 PM > To: yangyang (ET) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94574] ICE during GIMPLE pass: ccp > > On Mon, Apr 13, 2020 at 11:38 AM yangyang (ET) >

[patch, fortran, committed] Fix PR 94270

Hi, I just committed the attached patch as obvious and simple. Since this is a regression, I will backport to gcc 9 and gcc 8 shortly. (I'm attaching the patch as txt file in the hope it will not be munged in the web archive). Regards Thomas Fix PR 94270 by not warning about

Re: *ping* Re: [Patch][Fortran] Fix name conflict check for use-assoc (PR 92736)

Hi Tobias, *ping* OK. Thanks for the patch! Regards Thomas

ICE on wrong code [PR94192] commit

Hi all, the PR has just recently been committed. Paul gave his offline approval. I only realized recently, that the NULL pointer check can actually be ommitted if the check is moved in the code. In the commit however, it is still right below the declaration. I believe both ways work fine. It

Re: Merge dg-options and dg-additional-options (with a target directive)?

On Tue, Apr 14, 2020 at 01:39:43PM +0200, Martin Liška wrote: > On 4/14/20 1:26 PM, Jakub Jelinek wrote: > > On Tue, Apr 14, 2020 at 01:11:36PM +0200, Martin Liška wrote: > > > Hi. > > > > > > I've noticed that various files compile both these directives. > > > Do we want to merge them into

Re: Merge dg-options and dg-additional-options (with a target directive)?

On 4/14/20 1:26 PM, Jakub Jelinek wrote: On Tue, Apr 14, 2020 at 01:11:36PM +0200, Martin Liška wrote: Hi. I've noticed that various files compile both these directives. Do we want to merge them into dg-options? I'd defer for GCC11 I'm fine with that. , and only do it if the line doesn't

Re: Merge dg-options and dg-additional-options (with a target directive)?

On Tue, Apr 14, 2020 at 01:11:36PM +0200, Martin Liška wrote: > Hi. > > I've noticed that various files compile both these directives. > Do we want to merge them into dg-options? I'd defer for GCC11, and only do it if the line doesn't get way too long. Jakub

Re: [wwwdocs] Fix inverted option for disabling new feature (PR 94581)

Am 14.04.20 um 12:11 schrieb Jonathan Wakely: Committed as obvious. Thomas, please fix it if this isn't what you meant to say. Yep, that's what I meant to say. Thanks a lot! Regards Thomas

[PATCH] middle-end/94539 - void * aliases every other pointer

This makes same_type_for_tbaa_p conservative in the same way get_alias_set is about void * which we allow to alias all other pointers. Bootstrap & regtest running on x86_64-unknown-linux-gnu. Honza, is this what you had in mind? Thanks, Richard. 2020-04-14 Richard Biener PR

Merge dg-options and dg-additional-options (with a target directive)?

Hi. I've noticed that various files compile both these directives. Do we want to merge them into dg-options? Thanks, Martin gcc/gcc/testsuite/g++.old-deja/g++.robertl/eb27.C: // { dg-options "-Wno-deprecated" } // { dg-additional-options "-Wno-return-type" }

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On 4/14/20 10:37 AM, Jakub Jelinek wrote: On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote: +/* PR c++/94314. */ +/* { dg-do run } */ +/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */ +/* { dg-additional-options "-fdelete-null-pointer-checks" } */ Any reason why

[committed] libstdc++: Make comparison category comparisons noexcept (PR 94565)

PR libstdc++/94565 * libsupc++/compare (__unspec): Add noexcept-specifier to constructor. * testsuite/18_support/comparisons/categories/94565.cc: New test. Tested powerp64le-linux, committed to master. commit 597601aa7a0f822816041d521fae7da6e883fa7d Author: Jonathan

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

Rainer Orth wrote: Hi Segher, On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote: Unfortunately, several targets have ABI constraints that prevent an indirect tail-call, which results in the PRs compile error. diff --git

[wwwdocs] Fix inverted option for disabling new feature (PR 94581)

Committed as obvious. Thomas, please fix it if this isn't what you meant to say. commit 5264b357a424a38ccdcd3af01d67902109218aa8 Author: Jonathan Wakely Date: Tue Apr 14 11:09:43 2020 +0100 Fix inverted option for disabling new feature (PR 94581) diff --git a/htdocs/gcc-10/changes.html

Re: [PATCH][PR target/94542]Don't allow PC-relative addressing for TLS data

Hi! On Fri, Apr 10, 2020 at 06:00:45PM -0500, acsawdey wrote: > One of the things that address_to_insn_form() is used for is determining > whether a PC-relative addressing instruction could be used. In > particular predicate pcrel_external_address and function > prefixed_paddi_p() both use it

[PATCH]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

Hi all, Testing the backport of pr94530 fix (af19e4d0e23e) to GCC 9 I realized this is not entirely correct. aarch64_classify_address sets the base field of struct aarch64_address_info for all aarch64_address_type with the exception of ADDRESS_SYMBOLIC. In this case we would access an

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

Hi Segher, > On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote: >> Unfortunately, several targets have ABI constraints that prevent >> an indirect tail-call, which results in the PRs compile error. > >> diff --git >>

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

Hi! On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote: > Unfortunately, several targets have ABI constraints that prevent > an indirect tail-call, which results in the PRs compile error. > diff --git > a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C >

Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

On Tue, Apr 14, 2020 at 11:05 AM xiezhiheng wrote: > > > -Original Message- > > From: Richard Biener [mailto:richard.guent...@gmail.com] > > Sent: Tuesday, April 14, 2020 4:39 PM > > To: xiezhiheng > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [PING] [PATCH PR94442] [AArch64]

*ping* Re: [Patch][Fortran] Fix name conflict check for use-assoc (PR 92736)

*ping* On 4/8/20 12:44 PM, Tobias Burnus wrote: Hi all, this issue only occurs when use associating a symbol in a module and then again use-associating the same symbol in its submodule. If one simply uses use m, only: i use m, only: i the issue does not occur as all symbols are only

RE: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: Tuesday, April 14, 2020 4:39 PM > To: xiezhiheng > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp > instructions emitted at -O3 > > On Mon, Apr 13, 2020

Re: [PATCH PR94574] ICE during GIMPLE pass: ccp

On Mon, Apr 13, 2020 at 11:38 AM yangyang (ET) wrote: > > Hi, > > This is a simple fix for pr94574. > > testcase testsuite/gcc.target/aarch64/sve/acle/general/deref_1.c ICEs when > testing GCC trunk with -O2 -msve-vector-bits=256 -march=armv8.2-a+sve. > > There is a gimple statement before

Re: [PATCH 3/5] testsuite: [arm/mve] Fix mve_move_gpr_to_gpr.c

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote: This test can pass with a hard-float toolchain, provided we don't force -mfloat-abi=softfp. This patch removes this useless option, as well as -save-temps which is implied by arm_v8_1m_mve_fp. Hi Christophe, LGTM, but you need to

Re: [PATCH 5/5] testsuite: [arm/mve] Include arm_mve.h in arm_v8_1m_mve_ok

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote: Since arm_mve.h includes stdint.h, its use requires the presence of the right gnu/stub-*.h, so make sure to include it when checking the arm_v8_1m_mve_ok_nocache effective target, otherwise we can decide MVE is supported while it's

Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

On Mon, Apr 13, 2020 at 8:48 AM xiezhiheng wrote: > > Ping for: > This is definitely stage1 material. Richard. > Xie Zhiheng > > > > -Original Message- > > From: xiezhiheng > > Sent: Thursday, April 2, 2020 2:35 PM > >

Re: [PATCH 4/5] testsuite: [arm/mve] Use dg-add-options arm_v8_1m_mve in MVE tests

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote: Several ARM/MVE tests can be compiled even if the toolchain does not support -mfloat-abi=hard (softfp is OK). Use dg-add-options arm_v8_1m_mve or arm_v8_1m_mve_fp instead of using dg-additional-options. Hi Christophe, I think a bunch

Re: [PATCH 1/5] testsuite: [arm] Add arm_softfp_ok and arm_hard_ok effective targets.

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote: For arm-linux-gnueabi* targets, a toolchain cannot support the float-abi opposite to the one it has been configured for: since glibc does not support such multilibs, we end up lacking gnu/stubs-*.h when including stdint.h for instance.

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote: > +/* PR c++/94314. */ > +/* { dg-do run } */ > +/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */ > +/* { dg-additional-options "-fdelete-null-pointer-checks" } */ Any reason why you want to do it for -std=c++14 only?

Re: [PATCH] ipa-sra: Fix treatment of internal functions (PR 94434)

On Thu, Apr 9, 2020 at 7:57 PM Martin Jambor wrote: > > Hi, > > On Tue, Apr 07 2020, bule wrote: > > Hi, > > > > The patch is tested and works fine. It is more appropriate to handle > > the context by considering it as a section of assemble code. > > > > A minor question is that I think svst

Re: [PATCH 2/5] testsuite: [arm/mve] Use arm_softfp and arm_hard as needed in MVE tests

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote: Some MVE tests explicitly test a -mfloat-abi=hard option, but we need to check that the toolchain actually supports it (which may not be the case for arm-linux-gnueabi* targets). We also make use of dg-add-options arm_v8_1m_mve_fp and

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On 4/14/20 9:09 AM, Martin Liška wrote: I've updated a bit the Jakub's patch. I forgot to remove valid_pairs data structure, fixed here. Martin >From fb093e29d013ce0ce8e9181bd10635d14a48bcd2 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Thu, 9 Apr 2020 15:50:58 +0200 Subject: [PATCH]

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On 4/10/20 11:17 AM, Jakub Jelinek wrote: On Fri, Apr 10, 2020 at 10:29:29AM +0200, Martin Liška wrote: +/* Valid pairs of new and delete operators for DCE. */ +static hash_set *valid_pairs = NULL; + +/* Return that NEW_CALL and DELETE_CALL are a valid pair of new + and delete operators.

Re: [PATCH] correct format of flexible array members in diagnostics (PR c/92326)

On 4/13/20 9:41 PM, Martin Sebor wrote: On 4/13/20 1:25 PM, Jeff Law wrote: On Mon, 2020-04-13 at 12:39 -0600, Martin Sebor via Gcc-patches wrote: GCC 10 has changed the formatting of zero-length arrays in diagnostics to include their bound, but it also inadvertently added the zero bound to

[PATCH v4] Fix alignment for local variable [PR90811]

- The alignment for local variable was adjust during estimate_stack_frame_size, however it seems wrong spot to adjust that, expand phase will adjust that but it little too late to some gimple optimization, which rely on certain target hooks need to check alignment, forwprop is an example