libgo patch committed: increase test timeout

This libgo patch by Eric Fang increases the test timeout to 10 minutes, so that tests can pass on some slow machines. This matches the timeout for the gc tests. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian 483096e3130c468a0e1bd224504b394b42662748 diff

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

Thanks for your suggestions. For safety, I put back flag_unsafe_math_optimizations. Attached please find the v3 patch which is suitable for git am. Bootstrap and tested on aarch64 Linux platform. Is the v3 patch ok? >From aafcad7ed5d3d156eee1cabbb4958e2cce7899c6 Mon Sep 17 00:00:00 2001 From:

Re: [PATCH][libstd++][PR92156]

On 24/04/20 00:20 +0100, Jonathan Wakely wrote: On 21/04/20 20:58 +0530, kamlesh kumar via Libstdc++ wrote: added VERIFY in test and changed the template parameter naming. diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any index 6b7e68f0e63..d350d0b2575 100644 ---

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

Hi, Thank you for your quick review :) This patch refactors tree-ssa-operands.c by wrapping the global variables into a class, and also removes unused code. In this version, we now move struct function and gimple stmt arguments previously in the methods to the object constructor, so that we

Re: [PATCH][libstd++][PR92156]

On 21/04/20 20:58 +0530, kamlesh kumar via Libstdc++ wrote: added VERIFY in test and changed the template parameter naming. diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any index 6b7e68f0e63..d350d0b2575 100644 --- a/libstdc++-v3/include/std/any +++

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

On Thu, Apr 23, 2020 at 02:48:38PM -0400, Jason Merrill wrote: > 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

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

On Thu, 2020-04-23 at 16:05 -0500, Qing Zhao wrote: > Hi, Richard, > > This is the 3rd version of the patch, updated based on your previous > comments. > > Please take a look at it and let me know whether it’s okay to commit? > > Thanks a lot for all your help. > > Qing. > > gcc/ChangeLog: >

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

On 4/23/20 9:42 AM, Jeff Law wrote: 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

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

On 4/23/20 4:09 PM, Patrick Palka wrote: 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

Re: [PATCH] c++: zero_init_expr_p of dependent expression

On 4/23/20 4:09 PM, Patrick Palka wrote: 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

[committed] amdgcn: Swap mov_exec operands

I've just committed this patch. It doesn't change anything externally visible; it's just a code clean up that prepares the way for another patch I have in development. There's no rule how these non-standard "*_exec" patterns should look, but every one but this has the exec-mask operand last

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

Hi, Richard, This is the 3rd version of the patch, updated based on your previous comments. Please take a look at it and let me know whether it’s okay to commit? Thanks a lot for all your help. Qing. gcc/ChangeLog: 2020-04-22 qing zhao PR c/94230 * common.opt: Add

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

Tested x86_64_linux. Commited to master, backported to releases/gcc-9. Jonathan Wakely writes: > 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

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

On Thu, 2020-04-23 at 15:16 -0500, Segher Boessenkool wrote: > 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

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

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

[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:

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

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

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. *

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: [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

[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 >

[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 +-

[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?

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

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

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

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 > >

[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

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,

[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,

[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

[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.

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

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,

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, 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

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

[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

[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

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

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

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

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: [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

[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

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

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. >

[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

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.

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

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] 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

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: [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

[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 =

[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.

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

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 +++

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 >

[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

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

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

[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:

[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 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

[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. ---

[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. *

[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

[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

[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

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

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

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

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

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

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

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

[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

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

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,

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 > > > >

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

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][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: [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. >

[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 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

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

[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

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 >

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:

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

[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(-)

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

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: [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

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

  1   2   >