Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 12:31 AM Jeff Law wrote: > > On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote: > > > > > > In some ways it feels like it would be easier to resurrect RTL SSA :-) > > > > Why was RTL SSA abandoned? > > > > It might well work to keep everything in SSA form all the

RE: [GCC][PATCH][ARM]: Modify the MVE polymorphic variant arguments to match the MVE intrinsic definition.

> -Original Message- > From: Srinath Parvathaneni > Sent: 22 April 2020 14:00 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [GCC][PATCH][ARM]: Modify the MVE polymorphic variant > arguments to match the MVE intrinsic definition. > > Hello, > > When MVE intrinsic's are

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

On Wed, Apr 22, 2020 at 05:10:56PM -0500, Segher Boessenkool wrote: > > PR target/94707 > > * config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Add > > CXX17_EMPTY_BASE_SEEN argument. Pass it to recursive calls. > > Ignore cxx17_empty_base_field_p fields after setting > >

[rs6000] fix mffsl emulation

The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going through the motions, but not storing the result in the given operands[0]; it rather modifies operands[0] without effect. It also creates a DImode pseudo that it doesn't use, a DFmode pseudo that's unnecessary AFAICT, and it's

[PATCH][wwwdocs][AArch64] Fix typo in sve2-aes

Hi all, Pushing this obvious typo fix to the AArch64 changes.html for GCC 10. Thanks, Kyrill wwwdocs-typo.patch Description: wwwdocs-typo.patch

Re: [PATCH] amdgcn: Add stub personality function

On 22/04/2020 22:10, Kwok Cheung Yeung wrote: Hello This patch adds a stub implementation of __gxx_personality_v0, which is used in C++ exception handling. AMD GCN currently does not actually support exception handling (the unwind functions are all stubs too), so adding an extra stub function

Re: introduce target tmpnam and require it in tests relying on it

On Apr 21, 2020, Bernhard Reutner-Fischer wrote: > On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches > wrote: >> On 4/17/20 11:48 AM, Alexandre Oliva wrote: >>> On Apr 9, 2020, Alexandre Oliva wrote: >>> Some target C libraries that aren't recognized as freestanding don't

Re: [PATCH] libstdc++: don't use #include_next in c_global headers

On 23/04/20 06:32 +0200, Helmut Grohne wrote: Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: > Now you are probably going to say that "-isystem /usr/include" is a bad > idea and that you shouldn't do that. Right. > I'm inclined to agree. This isn't a > problem just yet.

RE: [PATCH v2] aarch64: Add TX3 machine model

Hi Anton, Thanks to you and Joel for clarifying the copyright assignment... > -Original Message- > From: Gcc-patches On Behalf Of Anton > Youdkevitch > Sent: 20 April 2020 19:29 > To: gcc-patches@gcc.gnu.org > Cc: jo...@marvell.com > Subject: [PATCH v2] aarch64: Add TX3 machine model >

Re: [patch, fortran] Fix PR 93956, wrong pointer when returned via function

Hi Thomas, You didn't attach the testcase but never mind, I am sure that it is OK :-) OK for trunk and, if you feel like it, for 9-branch. Thanks Paul On Tue, 21 Apr 2020 at 22:56, Thomas Koenig via Fortran wrote: > Hello world, > > this one took a bit of detective work. When array pointer

[PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

Hi This is a simple fix for pr94708. It's unsafe for rtl combine to generate fp min/max under -funsafe-math-optimizations, considering NaNs. We can only do this kind of transformation under -funsafe-math-optimizations and -ffinite-math-only. Bootstrap and tested on aarch64 Linux platform. No new

Re: [PATCH] coroutines: Handle lambda capture objects in the way as clang.

Nathan Sidwell wrote: On 4/22/20 8:48 AM, Iain Sandoe wrote: Hi, There is no PR for this, at present, but the implementation of clang and GCC's handling of lambda capture object implicit parms is currently different. There is still some discussion about 'correct' interpretation of the standar

Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

On Thu, Apr 23, 2020 at 10:42 AM Zhanghaijian (A) wrote: > > Hi > > This is a simple fix for pr94708. > It's unsafe for rtl combine to generate fp min/max under > -funsafe-math-optimizations, considering NaNs. > We can only do this kind of transformation under -funsafe-math-optimizations > and -

Re: [PATCH] [Stage1] Refactor tree-ssa-operands.c

On Wed, Apr 22, 2020 at 8:40 PM Giuliano Belinassi wrote: > > This patch refactors tree-ssa-operands.c by wrapping the global > variables into a class, and also removes unused code. > > Just sending this for when Stage1 is back again. > > I ran the testsuite and bootstraped in a x86_64 linux machi

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 09:32:37AM +0200, Richard Biener wrote: > On Thu, Apr 23, 2020 at 12:31 AM Jeff Law wrote: > > On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote: > > > > > In some ways it feels like it would be easier to resurrect RTL SSA :-) > > > > > > Why was RTL SSA abandoned

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

Hi! On Thu, Apr 23, 2020 at 10:06:16AM +0200, Jakub Jelinek wrote: > > Is there no way to describe this without referring to "c++17" (or even > > "base field")? It's a pretty gross abstraction violation. > > I'm afraid it is desirable to talk about c++17 and base field, otherwise > it won't be c

RE: [PATCH] aarch64: eliminate redundant zero extend after bitwise negation

Hi Alex, > -Original Message- > From: Alex Coplan > Sent: 22 April 2020 21:41 > To: gcc-patches@gcc.gnu.org > Cc: Richard Earnshaw ; Richard Sandiford > ; Marcus Shawcroft > ; Kyrylo Tkachov ; > nd > Subject: [PATCH] aarch64: eliminate redundant zero extend after bitwise > negation > >

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 12:17 PM Segher Boessenkool wrote: > > On Thu, Apr 23, 2020 at 09:32:37AM +0200, Richard Biener wrote: > > On Thu, Apr 23, 2020 at 12:31 AM Jeff Law wrote: > > > On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote: > > > > > > In some ways it feels like it would be

[PATCH] Enable simple invocation of runtest in testsuite

I noticed this inconvenience while learning dejagnu. From: Matthias Kretz * testsuite/Makefile.am: Remove dup target_triplet and set tool, allowing runtest to work without arguments. --- libstdc++-v3/testsuite/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) di

Re: [PATCH] amdgcn: Add stub personality function

Hi! On 2020-04-23T09:15:29+0100, Andrew Stubbs wrote: > On 22/04/2020 22:10, Kwok Cheung Yeung wrote: >> This patch adds a stub implementation of __gxx_personality_v0, which is >> used in C++ exception handling. AMD GCN currently does not actually >> support exception handling So we should simpl

Re: [PATCH] amdgcn: Add stub personality function

On 23/04/2020 12:05 pm, Thomas Schwinge wrote: So we should simply disable it properly (see below)... ... instead of adding such stub functions. I suggest we instead apply what I'd proposed a month ago in "[amdgcn] ld: error: undefined symbol: __gxx_personality_v0

Re: [rs6000] fix mffsl emulation

Hi! On Thu, Apr 23, 2020 at 05:08:55AM -0300, Alexandre Oliva wrote: > The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going > through the motions, but not storing the result in the given > operands[0]; it rather modifies operands[0] without effect. Heh, oops. > It also > creates

[AArch64] (PR94383) Avoid C++17 empty base field checking for HVA/HFA

In C++17, an empty class deriving from an empty base is not an aggregate, while in C++14 it is. In order to implement this, GCC adds an artificial field to such classes. This artificial field has no mapping to Fundamental Data Types in the AArch64 PCS ABI and hence should not count towards determ

Re: [AArch64] (PR94383) Avoid C++17 empty base field checking for HVA/HFA

Matthew Malcomson writes: > In C++17, an empty class deriving from an empty base is not an > aggregate, while in C++14 it is. In order to implement this, GCC adds > an artificial field to such classes. > > This artificial field has no mapping to Fundamental Data Types in the > AArch64 PCS ABI and

Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

Hi! On Thu, Apr 23, 2020 at 11:05:22AM +0200, Richard Biener wrote: > On Thu, Apr 23, 2020 at 10:42 AM Zhanghaijian (A) > wrote: > > This is a simple fix for pr94708. > > It's unsafe for rtl combine to generate fp min/max under > > -funsafe-math-optimizations, considering NaNs. > > We can only d

[PATCH] rs6000: Small improvement to the C++17 ABI fix [PR94707]

On Thu, Apr 23, 2020 at 05:24:19AM -0500, Segher Boessenkool wrote: > > + inform (input_location, > > + "parameter passing for argument of type %qT " > > + "when C++17 is enabled changed to match C++14 " > > + "

Re: [PATCH, libgfortran] Protect the trigd functions in libgfortran from unavailable math functions [PR94586, PR94694]

On Wed, Apr 22, 2020 at 01:13:47PM -0400, Fritz Reese via Gcc-patches wrote: > Jakub has OK'd the patch and I recently authored the original trigd My patch is already in. > code being modified here. After his patch is committed I will commit > this one unless others have comments or concerns. >

Re: [PATCH][RFC] extend DECL_GIMPLE_REG_P to all types

On Wed, 22 Apr 2020, Richard Sandiford wrote: > Richard Biener writes: > > On Wed, 22 Apr 2020, Richard Biener wrote: > > > >> > >> This extends DECL_GIMPLE_REG_P to all types so we can clear > >> TREE_ADDRESSABLE even for integers with partial defs, not just > >> complex and vector variables.

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 12:52:30PM +0200, Richard Biener wrote: > On Thu, Apr 23, 2020 at 12:17 PM Segher Boessenkool > wrote: > > > > On Thu, Apr 23, 2020 at 09:32:37AM +0200, Richard Biener wrote: > > > On Thu, Apr 23, 2020 at 12:31 AM Jeff Law wrote: > > > > On Wed, 2020-04-22 at 15:50 -0500,

Re: [PATCH] amdgcn: Add stub personality function

On 23/04/2020 12:21, Kwok Cheung Yeung wrote: I agree that not generating the problematic code in the first place is the better approach. Does that mean we can now remove libgcc/config/gcn/unwind-gcn.c completely? That was added for the benefit of libgfortran, not C++. It's used by the backtr

Re: [PATCH] Do not remove ifunc_resolver in LTO.

> On 4/22/20 8:11 PM, Jan Hubicka wrote: > > > On Mon, 2020-04-20 at 11:34 +0200, Martin Liška wrote: > > > > Hi. > > > > > > > > The patch prevents a ifunc alias from removal in remove unreachable > > > > nodes. > > > > Note that ifunc alias lives in a COMDAT section and so that > > > > cgraph_n

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 2:07 PM Segher Boessenkool wrote: > > On Thu, Apr 23, 2020 at 12:52:30PM +0200, Richard Biener wrote: > > On Thu, Apr 23, 2020 at 12:17 PM Segher Boessenkool > > wrote: > > > > > > On Thu, Apr 23, 2020 at 09:32:37AM +0200, Richard Biener wrote: > > > > On Thu, Apr 23, 2020

Re: [PATCH] rs6000: Small improvement to the C++17 ABI fix [PR94707]

On Thu, Apr 23, 2020 at 01:48:00PM +0200, Jakub Jelinek wrote: > On Thu, Apr 23, 2020 at 05:24:19AM -0500, Segher Boessenkool wrote: > > > + inform (input_location, > > > + "parameter passing for argument of type %qT " > > > + "when C++17 is

[PATCH] aarch64: add tests for CPP predefines under -mgeneral-regs-only

Hi, I noticed that gcc.target/aarch64/pragma_cpp_predefs_1.c performs testing for -mgeneral-regs-only. This adds similar testing in the following two tests to make sure CPP predefines redefinitions on #pragma works as expected when -mgeneral-regs-only option is specified (See PR9467

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote: > > > But being stuck with something means no progress... I know > > > very well it's 100 times harder to get rid of something than to > > > add something new ontop. > > > > Well, what progress do you expect to make? After expand tha

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool wrote: > > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote: > > > > But being stuck with something means no progress... I know > > > > very well it's 100 times harder to get rid of something than to > > > > add something new ontop.

Re: [PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

The 04/22/2020 15:22, Christophe Lyon wrote: > The new test fails with ilp32, not sure if that's supposed to work? > > FAIL: gcc.target/aarch64/pr94514.c (test for excess errors) > Excess errors: > /gcc/testsuite/gcc.target/aarch64/pr94514.c:27:4: warning: cast to > pointer from integer of differe

Re: [PATCH] coroutines: Handle lambda capture objects in the way as clang.

Iain Sandoe wrote: > Nathan Sidwell wrote: > >> On 4/22/20 8:48 AM, Iain Sandoe wrote: >>> Hi, >>> There is no PR for this, at present, but the implementation of >>> clang and GCC's handling of lambda capture object implicit parms >>> is currently different. There is still some discussion abou

Re: [PING] [PATCH] [ARM] Adjust test expectations of unaligned-memcpy-2/3.c (PR 91614)

On 4/22/20 8:20 PM, Jeff Law wrote: > On Thu, 2020-03-26 at 04:23 +0100, Bernd Edlinger wrote: >> Hi, >> >> I am pinging this because PR 91614 has been raised to P2 now: >> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html > It's been nearly a month since the ping and many since th

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 03:07:23PM +0200, Richard Biener wrote: > On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool > wrote: > > > > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote: > > > > > But being stuck with something means no progress... I know > > > > > very well it's 100 t

Follow-up Patch – Re: [Patch][OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

On 4/20/20 11:33 PM, Thomas Schwinge wrote: Really 'GOMP_MAP_DELETE', or should that rather be 'GOMP_MAP_RELEASE'? Depends on the previous item, i.e. 'delete:' vs. 'release:/from:/…' Rather obvious – OK? Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 Mün

[PATCH] aarch64: ensure bti c is emitted at function start [PR94697]

The bti pass currently first emits bti c at function start if there is no paciasp (which also acts as indirect call landing pad), then bti j is emitted at jump labels, however if there is a label right before paciasp then the function start can end up like foo: label: bti j paciasp

[PATCH 2/8] testsuite: Add arm_v8_2a_fp16_neon and arm_v8_2a_bf16_neon options

A few tests lack the dg-add-options directives associated with the dg-require-effective-target they are using. Adding them enables to pass the right float-abi option. 2020-04-21 Christophe Lyon gcc/tesuite/ * gcc.target/arm/bfloat16_scalar_typecheck.c: Add arm_v8_2a_fp1

[PATCH 6/8] testsuite: Add arm_dsp_ok effective target and use it in arm/dsp_arith.c

gcc.target/arm/acle/dsp_arith.c uses DSP intrinsics, which arm_acle.h defines only with __ARM_FEATURE_DSP, so make the test check for that property rather than arm_qbit_ok. However, the existing arm_dsp effective target only checks if DSP features are supported with the current multilib rather tha

[PATCH 4/8] testsuite: Add arm_softfp_ok or arm_hard_ok as needed.

Several tests want to override the -mfloat-abi option detected by the other effective targets. Make sure it is supported, so that these tests are unsupported rather than failed. 2020-04-21 Christophe Lyon gcc/testsuite/ * gcc.target/arm/bf16_dup.c: Add arm_softfp_ok. *

[PATCH 7/8] testsuite: [arm] Remove useless -mfloat-abi option

These tests pass with their current dg-add-options, no need to force -mfloat=abi. 2020-04-21 Christophe Lyon gcc/testsuite/ * gcc.target/arm/armv8_1m-shift-imm-1.c: Remove -mfloat=abi option. * gcc.target/arm/armv8_1m-shift-reg-1.c: Likewise. * gcc.target/arm/pr

[PATCH 1/8] testsuite: Fix -mfloat-abi order in arm_v8_2a_bf16_neon_ok and arm_v8_2a_i8mm_ok_nocache

Make the order in which we try -mfloat-abi options consistent with the other similar effective targets: try softfp first, then hard. We have new failures on arm-eabi: FAIL: gcc.target/arm/bfloat16_scalar_1_1.c check-function-bodies stacktest1 FAIL: gcc.target/arm/bfloat16_simd_1_1.c check-function

[PATCH 5/8] testsuite: Add arm_softfp_ok in gcc.target/arm/pr51968.c

This test forces -mfloat-abi=softfp, so we add the related effective target to make it unsupported on arm-linux-gnueabihf. 2020-04-21 Christophe Lyon gcc/testsuite/ * gcc.target/arm/pr51968.c: Add arm_softfp_ok effective target. --- gcc/testsuite/gcc.target/arm/pr51968.c | 3 +

[PATCH 3/8] testsuite: Add arm_v8_2a_i8mm options in gcc.target/arm/simd/vmmla_1.c

We need to add the options corresponding to the arm_v8_2a_i8mm_ok effective target in order to use the right float-abi option. 2020-04-21 Christophe Lyon gcc/testsuite/ * gcc.target/arm/simd/vmmla_1.c: Add arm_v8_2a_i8mm options. --- gcc/testsuite/gcc.target/arm/simd/vmmla_1.c

RE: [PATCH] aarch64: ensure bti c is emitted at function start [PR94697]

> -Original Message- > From: Szabolcs Nagy > Sent: 23 April 2020 14:51 > To: gcc-patches@gcc.gnu.org > Cc: Richard Earnshaw ; Kyrylo Tkachov > ; Sudakshina Das > Subject: [PATCH] aarch64: ensure bti c is emitted at function start [PR94697] > > The bti pass currently first emits bti c a

[PATCH 8/8] testsuite: Fix -mfloat-abi order in arm_v8_1m_mve_ok and arm_v8_1m_mve_fp_ok

Make the order in which we try -mfloat-abi options consistent with the other similar effective targets: try softfp first, then hard. We have new failures on arm-eabi: FAIL: gcc.target/arm/mve/intrinsics/mve_vector_int.c scan-assembler vmov\\tq[0-7], q[0-7] FAIL: gcc.target/arm/mve/intrinsics/mve

Re: [PATCH] coroutines: Fix handling of conditional statements [PR94288]

On 4/20/20 12:48 PM, Iain Sandoe wrote: Hi, Normally, when we find a statement containing an await expression this will be expanded to a statement list implementing the control flow implied. The expansion process successively replaces each await expression in a statement with the result of its

[committed] amdgcn: Check HSA return codes [PR94629]

This patch adds some additional checking to ensure that the HSA runtime call do not return errors. Previously the return codes were ignored, but failure still detected by the output data still having its initial value. This was probably safe, but a static analyzer correctly noticed that the st

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, 2020-04-23 at 07:07 -0500, Segher Boessenkool wrote: > > > I think at least one step would be uncontroversical(?), namely moving > > the RTL expansion "magic" > > up to a GIMPLE pass. Where the "magic" would be to turn > > GIMPLE stmts not directly expandable via an existing optab into >

RE: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

Thanks for your suggestions. I have modified accordingly. Attached please find the adapted patch. Bootstrap and tested on aarch64 Linux platform. Does the v2 patch look batter? diff --git a/gcc/combine.c b/gcc/combine.c index cff76cd3303..ad8a385fc48 100644 --- a/gcc/combine.c +++ b/gcc/combine.c

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote: > On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool > wrote: > > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote: > > > > > But being stuck with something means no progress... I know > > > > > very well it's 100 times harder

[Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, This is the second version of the patch based on the previous discussion. In this new version, the major changes are: 1. The name of the option is changed to -flarge-source-files; 2. Add a hint to use this new option “-flarge-source-files” in the routine “get_visual_column”; 3. Documentation

[committed] vect: Fix comparisons between invariant booleans [PR94727]

This PR was caused by mismatched expectations between vectorizable_comparison and SLP. We had a "<" comparison between two booleans that were leaves of the SLP tree, so vectorizable_comparison fell back on: /* Invariant comparison. */ if (!vectype) { vectype = get_vectype_for_scala

Re: [RFC] split pseudos during loop unrolling in RTL unroller

> > > What is wrong with DF? > > > > It's slow and memory hungry? > > Very true, of course. But can this be significantly better? That's a good question worth investigating in my opinion, because DF didn't quite achieve its initial goal of replacing all the custom liveness analysis passes onl

Re: [PR93488] [OpenACC] ICE in type-cast 'async', 'wait' clauses

On 21/04/2020 10:54, Thomas Schwinge wrote: Normalize GOACC_parallel_keyed async and wait parameters Oh, not only 'GOACC_parallel_keyed', but also other OpenACC directives. Maybe simply "[OpenACC] Avoid ICE in type-cast 'async', 'wait' clauses"? ;-P To record the review effort, please include

Re: [PATCH] aarch64: add tests for CPP predefines under -mgeneral-regs-only

"Yangfei (Felix)" writes: > Hi, > > I noticed that gcc.target/aarch64/pragma_cpp_predefs_1.c performs testing > for -mgeneral-regs-only. > This adds similar testing in the following two tests to make sure CPP > predefines redefinitions on #pragma > works as expected when -mgeneral-re

Re: [RFC] split pseudos during loop unrolling in RTL unroller

Jeff Law via Gcc-patches writes: > On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote: >> On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool >> wrote: >> > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote: >> > > > > But being stuck with something means no progress... I know >

Re: [PATCH] rs6000, Fix header comment for intrinsic function

On Wed, 2020-04-22 at 11:20 -0700, Carl Love wrote: > GCC maintainers: > Hi, > The following is a trivial patch to fix a comment describing the > intrinsic function _mm_movemask_epi8. The comment was expanded to > clarify the layout of the returned result. Something seems wrong there, see be

Re: [PATCH] handle initialized flexible array members in __builtin_object_size [PR92815]

On Wed, 2020-04-22 at 15:36 -0600, Martin Sebor via Gcc-patches wrote: > When computing the size of an object with a flexible array member > the object size pass doesn't consider that the initializer of such > an object can result in its size being in excess of the size of > the enclosing type. As

[PATCH] tsan: Add optional support for distinguishing volatiles

Add support to optionally emit different instrumentation for accesses to volatile variables. While the default TSAN runtime likely will never require this feature, other runtimes for different environments that have subtly different memory models or assumptions may require distinguishing volatiles.

Re: [RFC][PR target PR90000] (rs6000) Compile time hog w/impossible asm constraint lra loop

On Wed, 2020-04-22 at 12:26 -0600, Jeff Law wrote: > On Fri, 2020-04-10 at 16:40 -0500, will schmidt via Gcc-patches > wrote: > > [RFC][PR target/9] Compile time hog w/impossible asm constraint > > lra loop > > > > Hi, > > RFC for a bandaid/patch to partially address target PR/9. > >

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, 2020-04-23 at 16:32 +0100, Richard Sandiford wrote: > Jeff Law via Gcc-patches writes: > > On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote: > > > On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool > > > wrote: > > > > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote:

[PATCH] rs6000: Replace outdated link to ELFv2 ABI

A user reported that we are still referring to a public review draft of the ELFv2 ABI specification. Replace that by a permalink. Tested with "make pdf" and verified the link is hot. Is this okay for master? Thanks, Bill 2020-04-24 Bill Schmidt * gcc/doc/extend.texi (PowerPC AltiVe

Re: [AMD GCN] Use 'radeon' for the environment variable 'ACC_DEVICE_TYPE'

On 21/04/2020 13:24, Thomas Schwinge wrote: I wondered whether for symmetry, the GCC-internal 'GOMP_DEVICE_GCN', 'OFFLOAD_TARGET_TYPE_GCN' should also be renamed to '*_RADEON'? Or, going by example of '*_NVIDIA_PTX', name them '*_AMD_GCN'. Or, in fact then leave them as '*_GCN', given Julian's

Re: [PATCH v2] aarch64: Add TX3 machine model

Hi Kyrylo, On 23.4.2020 11:29 , Kyrylo Tkachov wrote: Hi Anton, Thanks to you and Joel for clarifying the copyright assignment... -Original Message- From: Gcc-patches On Behalf Of Anton Youdkevitch Sent: 20 April 2020 19:29 To: gcc-patches@gcc.gnu.org Cc: jo...@marvell.com Subject: [

Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

Hi! On Thu, Apr 23, 2020 at 02:34:03PM +, Zhanghaijian (A) wrote: > Thanks for your suggestions. I have modified accordingly. > Attached please find the adapted patch. Bootstrap and tested on aarch64 Linux > platform. > Does the v2 patch look batter? > > diff --git a/gcc/combine.c b/gcc/comb

Re: introduce target tmpnam and require it in tests relying on it

On 4/23/20 2:21 AM, Alexandre Oliva wrote: On Apr 21, 2020, Bernhard Reutner-Fischer wrote: On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches wrote: On 4/17/20 11:48 AM, Alexandre Oliva wrote: On Apr 9, 2020, Alexandre Oliva wrote: Some target C libraries that aren't recogniz

Re: [RFC] split pseudos during loop unrolling in RTL unroller

Hi! On Thu, Apr 23, 2020 at 08:29:34AM -0600, Jeff Law wrote: > On Thu, 2020-04-23 at 07:07 -0500, Segher Boessenkool wrote: > > Most of expand is *other stuff*. Expand does a *lot* of things that are > > actually changing the code. And much of that is not done anywhere else > > either yet, so t

[wwwdocs] Remove form for (un)subscribing from old mailing lists

This no longer works, so direct people to the mailman listinfo pages instead. OK to commit to wwwdocs? commit 2ae426c876e6ddc026bc2a30e82cb56946c9031f Author: Jonathan Wakely Date: Thu Apr 23 18:38:00 2020 +0100 Remove form for (un)subscribing from old mailing lists This no long

[PATCH] tree: Fix up get_narrower [PR94724]

Hi! In the recent get_narrower change, I wanted it to be efficient and avoid recursion if there are many nested COMPOUND_EXPRs. That builds the COMPOUND_EXPR nest with the right arguments, but as build2_loc computes some flags like TREE_SIDE_EFFECTS, TREE_CONSTANT and TREE_READONLY, when it is ca

Re: [Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Qing Zhao writes: > --- > gcc/c-family/c-indentation.c | 3 +++ > gcc/common.opt | 5 + > gcc/doc/invoke.texi| 15 ++- > gcc/testsuite/gcc.dg/plugin/location-overflow-test-1.c |

Re: [patch, fortran] Fix PR 93956, wrong pointer when returned via function

Hi Paul, You didn't attach the testcase but never mind, I am sure that it is OK :-) You're right. I thought I had it in the git diff, but then again, I am still learning the niceties (and not-so-niceties) of git. Test case is attached, for completeness. OK for trunk and, if you feel like it

Re: [PATCH] c++: Explicit constructor called in copy-initialization [PR90320]

On 4/22/20 11:27 PM, Marek Polacek wrote: This test is rejected with a bogus "use of deleted function" error starting with r225705 whereby convert_like_real/ck_base no longer sets LOOKUP_ONLYCONVERTING for user_conv_p conversions. This does not seem to be always correct. To recap, when we have

Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle.

Ping 4: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html Thanks, - Eddy B. On Mon, Apr 13, 2020, at 05:52, Eduard-Mihai Burtescu wrote: > Ping 3: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html > > Thanks, > - Eddy B. > > On Tue, Apr 7, 2020, at 00:52, Eduard-Mi

Re: [PATCH] tree: Fix up get_narrower [PR94724]

On April 23, 2020 8:19:55 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >In the recent get_narrower change, I wanted it to be efficient and >avoid >recursion if there are many nested COMPOUND_EXPRs. That builds the >COMPOUND_EXPR nest with the right arguments, but as build2_loc computes >some >flags

[PATCH] Shortcut identity VEC_PERM expansion [PR94710]

Hi! This PR is about the rs6000 backend emitting wrong assembly for whole vector shift by 0, and while I think it is desirable to fix the backend, I don't see a point why the expander should try to emit that, whole vector shift by 0 is identity, we can just return the operand. Bootstrapped/regtes

[PATCH v3] aarch64: Add TX3 machine model

Here is the patch introducing thunderxt311 maching model for the scheduler. A name for the new chip was added to the list of the names to be recognized as a valid parameter for mcpu and mtune flags. The TX2 cost model was reused for TX3. The previously used "cryptic" name for the command line para

[PATCH] testsuite: C++14 vs. C++17 struct-layout-1.exp testing with ALT_CXX_UNDER_TEST [PR94383]

Hi! On Tue, Apr 21, 2020 at 11:57:02AM +0200, Jakub Jelinek wrote: > I haven't added (yet) checks if the alternate compiler does support these > options (I think that can be done incrementally), so for now this testing is > done only if the alternate compiler is not used. This patch does that, so

Re: [PATCH] rs6000: Replace outdated link to ELFv2 ABI

On Thu, 2020-04-23 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote: > A user reported that we are still referring to a public review > draft of the ELFv2 ABI specification. Replace that by a permalink. > > Tested with "make pdf" and verified the link is hot. Is this okay > for master? > Hi,

[committed] c-family: Fix ICE on attribute with -fgnu-tm [PR94733]

find_tm_attribute was using TREE_PURPOSE to get the attribute name, which is breaking now that we preserve the C++11-style attribute format past decl_attributes. So use get_attribute_name which can handle both formats of attributes. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/9

Re: [PATCH] rs6000: Replace outdated link to ELFv2 ABI

On Thu, Apr 23, 2020 at 12:13 PM Bill Schmidt wrote: > > A user reported that we are still referring to a public review > draft of the ELFv2 ABI specification. Replace that by a permalink. > > Tested with "make pdf" and verified the link is hot. Is this okay > for master? > > Thanks, > Bill > >

Re: [PATCH][v3], rs6000: Use plq/pstq for atomic_{load, store} (PR94622)

On Wed, 2020-04-22 at 07:59 -0500, Segher Boessenkool wrote: > Hi! > > On Tue, Apr 21, 2020 at 04:53:53PM -0500, Aaron Sawdey via Gcc- > patches wrote: > > For future architecture with prefix instructions, always use > > plq/pstq > > rather than lq/stq for atomic load of quadword. Then we never ha

Re: [PATCH] Shortcut identity VEC_PERM expansion [PR94710]

On April 23, 2020 9:04:40 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >This PR is about the rs6000 backend emitting wrong assembly >for whole vector shift by 0, and while I think it is desirable >to fix the backend, I don't see a point why the expander should >try to emit that, whole vector shift by

Re: [Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard, > On Apr 23, 2020, at 1:27 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >> --- >> gcc/c-family/c-indentation.c | 3 +++ >> gcc/common.opt | 5 + >> gcc/doc/invoke.texi

[PATCH] c++: zero_init_expr_p of dependent expression

This fixes a ICE coming from mangle.c:write_expression when compiling the ranges-v3 testsuite; the added testcase is a reduced reproducer of the ICE. Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on the cmcstl2, fmt and range-v3 libraries. Does this look OK to commit? gcc/cp

[PATCH] Mark experimental::net::system_context ctor deleted

* include/experimental/net/executor: Mark system_context::system_context() = default. * testsuite/experimental/net/executor/1.cc: Add new test for deleted system_context ::system_context(). --- libstdc++-v3/include/experimental/executor| 2 +- libstdc++-v3/tes

[PATCH] c++: Lambda in friend of constrained class [PR94645]

In the testcase below, when grokfndecl processes the operator() decl for the lambda inside the friend function foo, processing_template_decl is rightly 1, but template_class_depth on the lambda's closure type incorrectly returns 0 instead of 1. Since processing_template_decl > template_class_depth

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 08:40:50AM -0600, Jeff Law wrote: > On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote: > > On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool > > wrote: > > > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote: > > > > > > But being stuck with something me

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 04:32:51PM +0100, Richard Sandiford wrote: > I also wonder how difficult it would be to get recog to recognise > gimple :-) Since recog recognises single (rtl) insns: hard to impossible? Segher

Re: [PATCH] Mark experimental::net::system_context ctor deleted

On 23/04/20 13:09 -0700, Thomas Rodgers via Libstdc++ wrote: * include/experimental/net/executor: Mark system_context::system_context() = default. s/default/delete/ :-) But the affected function/type/thingie should be named in parens, not in the comment i.e. * include/exper

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, 23 Apr 2020, Richard Biener via Gcc-patches wrote: > I think at least one step would be uncontroversical(?), namely moving > the RTL expansion "magic" > up to a GIMPLE pass. Where the "magic" would be to turn > GIMPLE stmts not directly expandable via an existing optab into > GIMPLE that

Fix PR tree-optimization/94717

This is a regression present on the mainline in the form of a segfault on the attached C testcase with -O2 -fnon-call-exceptions -ftracer. The GIMPLE SSA store merging pass blows up when it is rewriting the stores because it didn't realize that they don't belong to the same EH region. Fixed by

[committed 9/8] libstdc++: Define __cpp_lib_three_way_comparison for freestanding

The header is always supported, not only for hosted configs. * include/std/version (__cpp_lib_three_way_comparison): Define for freestanding builds. Tested powerpc64le-linux, committed to master. commit a2dcb56c9443d1211e14889bd0c2c21360d54cdb Author: Jonathan Wakely Date:

Re: [committed 7/8] libstdc++: Update (and revert) value of __cpp_lib_array_constexpr

On 22/04/20 22:59 +0100, Jonathan Wakely wrote: This macro should have been updated to 201811 when the last C++20 changes were implemented. However those changes are not enabled for C++17 mode, so the macro should only have the new value in C++20 mode. This change ensures that the macro is defin

Re: [committed 0/8] libstdc++: Add/update/fix feature test macros

On 22/04/20 22:57 +0100, Jonathan Wakely wrote: This series of patches fixes a number of omissions and errors in the feature test macros we define. Tested powerpc64le-linux, committed to master. Jonathan Wakely (8): libstdc++: Update value of __cpp_lib_jthread macro libstdc++: Remove non-stan

  1   2   >