Re: [PATCH] PowerPC -mcpu=future Patch 1 of 7, add target supports for -mpcrel and -mprefixed

On Mon, 2020-04-27 at 15:46 -0400, Michael Meissner via Gcc-patches wrote: > This patch adds supports in target-supports.exp for -mpcrel and > -mprefixed. > > Patch #1 of 7. Hi Subject: Re: [PATCH] PowerPC -mcpu=future Patch 1 of 7, add target supports for -mpcrel and -mprefixed Squish that su

Re: [PATCH] PowerPC -mcpu=future Patch 2 of 7, Add PLI/PADDI tests

On Mon, 2020-04-27 at 15:48 -0400, Michael Meissner via Gcc-patches wrote: > Add tests for generating PLI/PADDI with -mcpu=future. > > This is patch #2 of 7. This patch was run on a little endian power8 > system > running Linux and the patches succeeded. > > 2020-04-27 Michael Meissner > >

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

Am 21.04.20 um 23:55 schrieb Thomas Koenig: Hello world, this one took a bit of detective work. ... and also caused a regression, see PR 94788. Reverted on trunk so far, so the upcoming release is OK. This will still take some more work, I suppose... Regards Thomas

Re: [PATCH] PowerPC -mcpu=future Patch 3 of 7, Add test for generating prefixed load/store

On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches wrote: > This patch adds a test that verifies that the compiler generates a prefixed > load/store instruction where the compiler cannot generate the instruction > directly because the offset is not a valid DS or DQ offset. A DS of

Re: [PATCH] PowerPC -mcpu=future Patch 4 of 7, Make sure an invalid instruction is not generated

On Mon, 2020-04-27 at 15:57 -0400, Michael Meissner via Gcc-patches wrote: > This test validates that the compiler does not generate a prefixed > load/store > instruction with an update form. The prefixed load/store > instructions do not > have an update form. > > This is patch #4 of 7. This pat

Re: [PATCH] PowerPC -mcpu=future Patch 5 of 7, Add prefixed load/store tests with large numeric offsets

On Mon, 2020-04-27 at 16:00 -0400, Michael Meissner via Gcc-patches wrote: > This patch adds tests for -mcpu=future generating prefixed load/store > instructions with large numeric offsets. > > This is patch #5 of 7. This patch was tested on a little endian power8 system > running Linux, and the

Re: [PATCH] PowerPC -mcpu=future Patch 6 of 7, add PC-relative tests

On Mon, 2020-04-27 at 16:01 -0400, Michael Meissner via Gcc-patches wrote: > This patch adds PC-relative tests for -mcpu=future. > > This is patch #6 of 7. I have checked this on a little endian power8 system > running Linux, and all tests passed. Can I check this into the GCC 10 trunk? > > 202

Re: [PATCH] PowerPC -mcpu=future Patch 7 of 7, Add test for stack checking and large stack frames

On Mon, 2020-04-27 at 16:04 -0400, Michael Meissner via Gcc-patches wrote: > This patch adds a test for the case where we have prefixed load/store > instructions, a large stack frame, and stack checking is enabled. > > This is patch #7 of 7. I have checked this patch on a little endian power8 > s

[PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

rtl-optimization: ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1 [PR94740] We ICE on the test case below because decompose_normal_address() doesn't expect to see memory operands with constant addresses like below without a (const:DI ...) wrapped around the PLUS: (mem/c:S

[PATCH] wwwdocs: Add D front-end section for GCC 10 changes

Hi, This patch adds a section on the D front-end about all changes that have gone into the GCC 10 release. W3 validator reports there are no errors or warnings to show. Any comments or clarifications required on what's written up? Or is it OK to commit to the website? Regards Iain. --- htdoc

Re: [rs6000] fix mffsl emulation

On Apr 24, 2020, Segher Boessenkool wrote: >> > since all the top bits are zeros always, it will always be a subnormal >> > number, so all comparisons will work as expected / wanted. >> >> *nod*, as long as there's no trapping on subnormals. > There isn't :-) I did say this isn't clean at all,

[PATCH] contrib/vimrc: Reduce textwidth for commit messages

The bundled vimrc script, when enabled, currently sets the text width to 80 characters for all files within the source directory. Unfortunately this means the setting also applies when editing .git/COMMIT_EDITMSG, overriding the default and standard text width of 72 for Git commit messages. (A te

[PATCH] Add value range info for affine combination to improve store motion (PR83403)

From: Xionghu Luo Get and propagate value range info to convert expressions with convert operation on PLUS_EXPR/MINUS_EXPR/MULT_EXPR when not overflow. i.e.: (long unsigned int)((unsigned int)n * 10 + 1) => (long unsigned int)((unsigned int) n * (long unsigned int)10 + (long unsigned int)1)

Re: [PATCH] vect: Fix COND_EXPRs involving variant booleans [PR94727]

On Mon, Apr 27, 2020 at 6:54 PM Richard Sandiford wrote: > > Christophe Lyon writes: > >> 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_compariso

Re: [PATCH] Check whether -fcf-protection=none -Wl, -z, ibt, -z, shstk work first

On Mon, Apr 27, 2020 at 8:13 PM H.J. Lu via Gcc-patches wrote: > > GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host > has Intel CET enabled by introducing an Intel CET violation on purpose. > To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first. > -fcf-prote

Re: [PATCH] match.pd: Decrease number of nop conversions around bitwise ops [PR94718]

On Mon, 27 Apr 2020, Jakub Jelinek wrote: > Hi! > > On the following testcase, there are in *.optimized dump 14 nop conversions > (from signed to unsigned and back), while this patch decreases that number > to just 4; for bitwise ops it really doesn't matter if they are performed in > signed or u

[PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

Hi, I see one gcc_assert was introduce in: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544271.html This is causing an ICE for certain cases. I have created a PR for this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784 I did some check and it looks like everything works fine

Re: [PATCH] s390: Fix C++14 vs. C++17 ABI incompatibility on s390{,x} [PR94704]

On Mon, Apr 27, 2020 at 08:41:32AM +0200, Andreas Krebbel wrote: > Ok. Thanks for doing this! Thanks, committed. > We probably have to look into providing a -Wpsabi warning as well. So like this? Untested except on a small testcase. 2020-04-27 Jakub Jelinek PR target/94704

Re: [PATCH] s390: Fix C++14 vs. C++17 ABI incompatibility on s390{, x} [PR94704]

On 27.04.20 09:36, Jakub Jelinek wrote: > On Mon, Apr 27, 2020 at 08:41:32AM +0200, Andreas Krebbel wrote: >> Ok. Thanks for doing this! > > Thanks, committed. > >> We probably have to look into providing a -Wpsabi warning as well. > > So like this? Untested except on a small testcase. > > 202

Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

"Yangfei (Felix)" writes: > Hi, > > I see one gcc_assert was introduce in: > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544271.html > This is causing an ICE for certain cases. I have created a PR for this: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784 > I did some check

[patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

Please find attached three slightly different patches based on a patch for PR59107 originally developed by Janus Weil and Dominique d'Humieres for gcc-5. The last comment regarding the patch was on 2015-03-21 consequently the code has moved on somewhat and some additional changes where requir

[PATCH] wwdocs: Update coroutines status.

hi, This makes minor adjustments to the coroutines status reflecting the changes in n4861, the C++20 standard DIS. OK to apply? thanks Iain — htdocs/gcc-10/changes.html | 1 + htdocs/projects/cxx-status.html | 9 + 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/ht

RE: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

> -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Monday, April 27, 2020 3:51 PM > To: Yangfei (Felix) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree- > ssa-forwprop.c:2482 > > "Yangfei (Fel

Re: [patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

Am 27.04.20 um 09:51 schrieb Mark Eggleston: Please find attached three slightly different patches based on a patch for PR59107 originally developed by Janus Weil and Dominique d'Humieres for gcc-5. The last comment regarding the patch was on 2015-03-21 consequently the code has moved on som

Re: Return slot optimization for stack protector strong

On Mon, Jan 27, 2020 at 06:53:51PM +0100, Jakub Jelinek wrote: > On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote: > > some function calls trigger the stack-protector-strong although such > > calls are later on implemented via calls to internal functions. > > Consider the

Re: [patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

On 27/04/2020 09:56, Thomas Koenig wrote: Am 27.04.20 um 09:51 schrieb Mark Eggleston: Please find attached three slightly different patches based on a patch for PR59107 originally developed by Janus Weil and Dominique d'Humieres for gcc-5. The last comment regarding the patch was on 2015-

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

On Thu, 23 Apr 2020 at 16:48, Richard Sandiford wrote: > > 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 compar

Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

"Yangfei (Felix)" writes: >> We don't need to fall back to constant comparisons here. >> We should assert for known_eq between the TYPE_VECTOR_SUBPARTS >> instead. >> >> Same for the other assert. > > Good suggestion. Modified accordingly. > >> LGTM otherwise, and sorry for the breakage. > > Doe

[PATCH v5] aarch64: Add TX3 machine model

Here is the patch introducing thunderx3t110 machine 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. Added the TX3 tuning table and cost model tables. Added the new chip name to the documentation. Fi

RE: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

> -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Monday, April 27, 2020 6:10 PM > To: Yangfei (Felix) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree- > ssa-forwprop.c:2482 > > > Good sugges

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

On Mon, 27 Apr 2020, Jason Merrill wrote: > On 4/26/20 6:48 PM, Patrick Palka wrote: > > In the testcase below, the call to the target constructor foo{} from foo's > > delegating constructor is encoded as the INIT_EXPR > > > >*(struct foo *) this = AGGR_INIT_EXPR <4, __ct_comp, D.2140, ...>;

[PATCH][GCC][Arm]: Fix bootstrap failure with rtl-checking

Hi, The code change that caused this regression was not meant to affect neon code-gen, however I missed the REG fall through.  This patch makes sure we only get the left-hand of the PLUS if it is indeed a PLUS expr. I suggest that in gcc-11 this code is cleaned up, as I do not think we even

RE: [PATCH][GCC][Arm]: Fix bootstrap failure with rtl-checking

> -Original Message- > From: Andre Vieira (lists) > Sent: 27 April 2020 14:22 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH][GCC][Arm]: Fix bootstrap failure with rtl-checking > > Hi, > > The code change that caused this regression was not meant to affect neon >

RE: [GCC][PATCH][ARM]: Change arm constraint name from "e" to "Te".

> -Original Message- > From: Srinath Parvathaneni > Sent: 24 April 2020 15:25 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [GCC][PATCH][ARM]: Change arm constraint name from "e" to "Te". > > Hello, > > This patches changes the constraint "e" to "Te". > > Regression

libgomp: Allow overriding via 'GOMP_OFFLOAD_PLUGINS' the configured set of libgomp plugins

Hi! Is the attached patch for "libgomp: Allow overriding via 'GOMP_OFFLOAD_PLUGINS' the configured set of libgomp plugins" OK for master and release branches? If approving this patch, please respond with "Reviewed-by: NAME " so that your effort will be recorded in the commit log, see

Re: [PATCH] c-family: Fix ICE on __builtin_speculation_safe_value () [PR94755]

On 4/26/20 10:59 AM, Jakub Jelinek wrote: On Sun, Apr 26, 2020 at 09:58:16AM -0400, Nathan Sidwell wrote: first_param = (*params)[0]; - if (fncode == BUILT_IN_NONE - || !speculation_safe_value_resolve_params (loc, function, params)) + if (!speculation_safe_value_r

Re: [PATCH] coroutines: Fix handling of non-class coroutine returns [PR94759]

On 4/25/20 9:49 AM, Iain Sandoe wrote: Hi tested on x86_64-darwin, OK for master if the testing passes regstrap on x86-64-linux? thanks Iain gcc/cp/ChangeLog: 2020-04-23 Iain Sandoe PR c++/94759 * coroutines.cc (coro_promise_type_found_p): Do not exclude non-clas

Re: [PATCH] coroutines: Pass class ref to traits lookup and promise allocator [PR94760]

On 4/25/20 11:08 AM, Iain Sandoe wrote: (WAS [PATCH] coroutines: Handle lambda capture objects in the way as clang.) I am sorry to mess you around on this. It wasn't you who wasn't focussing :) We changed the argument passed to the promise parameter preview to match a reference to *this. H

Re: [PATCH] wwdocs: Update coroutines status.

On 4/27/20 3:56 AM, Iain Sandoe wrote: hi, This makes minor adjustments to the coroutines status reflecting the changes in n4861, the C++20 standard DIS. OK to apply? thanks Iain — htdocs/gcc-10/changes.html | 1 + htdocs/projects/cxx-status.html | 9 + 2 files changed, 6 in

Re: [PATCH] coroutines: Fix for uses of structured binding [PR94701]

On 4/21/20 4:33 PM, Iain Sandoe wrote: Hi, As reported by Michał Dominiak, we are generating incorrect code for structured binding of local vars. Somewhere in the machinations associated with lambda captures, I messed up the code handling DECL_VALUE_EXPRs. tested so far on x86_64-darwin16, OK

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

Hi, David, > On Apr 24, 2020, at 5:36 PM, David Malcolm wrote: > > On Fri, 2020-04-24 at 17:22 -0500, Qing Zhao wrote: >> Hi, Dave, >> >> Thanks a lot for the review and comments. >> I just updated the patch with all your suggestions, bootstrapped it >> and run regression test, no any issue. >>

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

On Mon, 27 Apr 2020, Patrick Palka wrote: > On Mon, 27 Apr 2020, Jason Merrill wrote: > > > On 4/26/20 6:48 PM, Patrick Palka wrote: > > > In the testcase below, the call to the target constructor foo{} from foo's > > > delegating constructor is encoded as the INIT_EXPR > > > > > >*(struct f

[PATCH v2] wwdocs: Update coroutines status.

Nathan Sidwell wrote: > On 4/27/20 3:56 AM, Iain Sandoe wrote: >> hi, >> This makes minor adjustments to the coroutines status reflecting the >> changes in >> n4861, the C++20 standard DIS. >> OK to apply? >> thanks >> Iain >> — >> htdocs/gcc-10/changes.html | 1 + >> htdocs/projects/cxx-

[RFC] Clarify -ffinite-math-only documentation

Hi, This documentation change clarifies the effect of -ffinite-math-only. With the current documentation, it is unclear what the presence of NaN and Inf representations means if (arithmetic) operations on such values are unspecified and even classification functions like isnan are unreliable. I

[PATCH] Let numeric_limits::is_iec559 reflect -ffast-math

From: Matthias Kretz PR libstdc++/84949 * include/std/limits: Let is_iec559 reflect whether __GCC_IEC_559 says float and double support IEEE 754-2008. * testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC559 mandated behavior if is_iec559 is true.

Re: [PATCH v2] wwdocs: Update coroutines status.

On 4/27/20 11:04 AM, Iain Sandoe wrote: Nathan Sidwell wrote: On 4/27/20 3:56 AM, Iain Sandoe wrote: hi, This makes minor adjustments to the coroutines status reflecting the changes in n4861, the C++20 standard DIS. OK to apply? thanks Iain — htdocs/gcc-10/changes.html | 1 + htdocs/

[Arm] Account for C++17 artificial field determining Homogeneous Aggregates

NOTE: There is another patch in the making to handle the APCS abi (selected with `-mabi=apcs-gnu`). That patch has a very different change in behaviour and is in a different part of the code so I'm keeping it in a different patch. In C++14, an empty class deriving from an empty base is not

[committed] wwwdocs: Correct two validation errors.

Hi, This corrects two errors picked up by the validator. (one in the patch I just applied, one pre-existing). thanks iain --- htdocs/projects/cxx-status.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html ind

[PATCH] vect: Fix COND_EXPRs involving variant booleans [PR94727]

Christophe Lyon writes: >> 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

[PATCH] arm: Fix an rtl checking failure in cde-errors.c

cde-errors.c and cde-mve-error-2.c were failing with an rtl checking failure because we applied UINTVAL to a nonconstant argument (specifically a REG). Tested on arm-linux-gnueabihf. OK to install? Richard 2020-04-27 Richard Sandiford gcc/ * config/arm/arm-builtins.c (arm_expand_bu

RE: [PATCH] arm: Fix an rtl checking failure in cde-errors.c

> -Original Message- > From: Richard Sandiford > Sent: 27 April 2020 17:14 > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > Ramana Radhakrishnan ; Kyrylo > Tkachov > Subject: [PATCH] arm: Fix an rtl checking failure in cde-errors.c > > cde-errors.c and cde-mv

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

On 4/22/20 12:39 PM, Giuliano Belinassi via Gcc-patches wrote: This patch refactors tree-ssa-operands.c by wrapping the global variables into a class, and also removes unused code. Just a few comments on this nice cleanup: It looks to me like class build_virtual_operands isn't safe to copy or

Re: [RFC] Clarify -ffinite-math-only documentation

On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz wrote: > > Hi, > > This documentation change clarifies the effect of -ffinite-math-only. With the > current documentation, it is unclear what the presence of NaN and Inf > representations means if (arithmetic) operations on such values are > unspecifi

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

Hi Anton, > -Original Message- > From: Anton Youdkevitch > Sent: 27 April 2020 11:24 > To: gcc-patches@gcc.gnu.org > Cc: Richard Earnshaw ; Kyrylo Tkachov > ; James Greenhalgh > ; Richard Sandiford > ; jjo...@marvell.com > Subject: [PATCH v5] aarch64: Add TX3 machine model > > Here is th

Re: [RFC] Clarify -ffinite-math-only documentation

Richard Biener via Gcc-patches writes: > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz wrote: >> >> Hi, >> >> This documentation change clarifies the effect of -ffinite-math-only. With >> the >> current documentation, it is unclear what the presence of NaN and Inf >> representations means if (a

[PATCH, PR94774] tree-optimization: Fix use of uninitialized variable

Array retval is not necessarily initialized by function is_call_safe and may be used afterwards. Thus, initialize it explicitly. Ok for master? gcc/ChangeLog: 2020-04-27 Stefan Schulze Frielinghaus PR tree-optimization/94774 * gimple-ssa-sprintf.c (try_substitute_return_valu

[PATCH] Check whether -fcf-protection=none -Wl, -z, ibt, -z, shstk work first

GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host has Intel CET enabled by introducing an Intel CET violation on purpose. To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first. -fcf-protection=none is added to avoid false negative when -fcf-protection is enable

Re: [PATCH v2 1/2] RISC-V: Add shorten_memrefs pass

On 08/04/2020 17:04, Jim Wilson wrote: > On Wed, Feb 19, 2020 at 3:40 AM Craig Blackmore > wrote: >> On 10/12/2019 18:28, Craig Blackmore wrote: >> Thank you for your review. I have posted an updated patch below which I think >> addresses your comments. >> >> Ping >> >> https://gcc.gnu.org/ml/gcc

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

On 27.4.2020 19:34 , Kyrylo Tkachov wrote: Hi Anton, -Original Message- From: Anton Youdkevitch Sent: 27 April 2020 11:24 To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw ; Kyrylo Tkachov ; James Greenhalgh ; Richard Sandiford ; jjo...@marvell.com Subject: [PATCH v5] aarch64: Add TX3 m

[committed] aarch64: disable test on ilp32 [PR94697]

branch-protection=pac-ret is not supported on ilp32 now and the test requires it via branch-protection=standard. committed as obvious. gcc/testsuite/ChangeLog: PR target/94697 * gcc.target/aarch64/pr94697.c: Require lp64. --- gcc/testsuite/ChangeLog| 5 +

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

On Mon, Apr 27, 2020 at 04:34:49PM +, Kyrylo Tkachov wrote: > Hi Anton, > > > -Original Message- > > From: Anton Youdkevitch > > Sent: 27 April 2020 11:24 > > To: gcc-patches@gcc.gnu.org > > Cc: Richard Earnshaw ; Kyrylo Tkachov > > ; James Greenhalgh > > ; Richard Sandiford > > ; jjo

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

On 4/27/20 10:45 AM, Patrick Palka wrote: On Mon, 27 Apr 2020, Patrick Palka wrote: On Mon, 27 Apr 2020, Jason Merrill wrote: On 4/26/20 6:48 PM, Patrick Palka wrote: In the testcase below, the call to the target constructor foo{} from foo's delegating constructor is encoded as the INIT_EXPR

Re: [RFC] Clarify -ffinite-math-only documentation

On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote: > Richard Biener via Gcc-patches writes: > > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz wrote: > >> Hi, > >> > >> This documentation change clarifies the effect of -ffinite-math-only. > >> With the current documentation, it is

[PATCH] x86: Fix up ix86_atomic_assign_expand_fenv [PR94780]

Hi! This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification the var gets the right DECL_CONT

[PATCH] demangler: Handle <=> operator in the demangler [PR94797]

Hi! The demangler didn't handle spaceship operator. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2020-04-27 Jakub Jelinek PR demangler/94797 * cp-demangle.c (cplus_demangle_operators): Add ss <=> operator. * testsuite/demangle-exp

[PATCH] match.pd: Decrease number of nop conversions around bitwise ops [PR94718]

Hi! On the following testcase, there are in *.optimized dump 14 nop conversions (from signed to unsigned and back), while this patch decreases that number to just 4; for bitwise ops it really doesn't matter if they are performed in signed or unsigned, so the patch (in GIMPLE only, there are some c

Re: [PATCH] coroutines: Pass class ref to traits lookup and promise allocator [PR94760]

Nathan Sidwell wrote: > On 4/25/20 11:08 AM, Iain Sandoe wrote: >> + tree arg = DECL_ARGUMENTS (fndecl); >> + bool lambda_p = LAMBDA_TYPE_P (DECL_CONTEXT (fndecl)); > > I think LAMBDA_FUNCTION_P (fndecl) expresses intent better. done in both places. >> + >>parm.this_ptr = is_this_par

Re: [PATCH] demangler: Handle <=> operator in the demangler [PR94797]

On 4/27/20 2:28 PM, Jakub Jelinek wrote: Hi! The demangler didn't handle spaceship operator. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. 2020-04-27 Jakub Jelinek PR demangler/94797 * cp-demangle.c (cplus_demangle_operators): Add

[committed] Fix warning URLs for Fortran and analyzer [PR 92830]

PR 92830 reports that we always use "gcc/Warning-Options.html" when we emit escaped documentation URLs when printing "[-Wname-of-option]" for a warning. This page is wrong for most Fortran warnings, and for analyzer warnings. I considered various schemes involving adding extra tags to the .opt f

Re: [PATCH] x86: Fix up ix86_atomic_assign_expand_fenv [PR94780]

On Mon, Apr 27, 2020 at 8:26 PM Jakub Jelinek wrote: > > Hi! > > This function, because it is sometimes called even outside of function > bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order > for that to work, when first referenced, the VAR_DECLs need to appear in a > TARGET_

Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

On 4/25/20 6:03 AM, Jakub Jelinek wrote: As reported by Iain and David, powerpc-darwin and powerpc-aix* have C++14 vs. C++17 ABI incompatibilities which are not fixed by mere adding of cxx17_empty_base_field_p calls. Unlike the issues that were seen on other targets where the artificial empty ba

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

On Mon, 27 Apr 2020, Jason Merrill wrote: > On 4/27/20 10:45 AM, Patrick Palka wrote: > > On Mon, 27 Apr 2020, Patrick Palka wrote: > > > > > On Mon, 27 Apr 2020, Jason Merrill wrote: > > > > > > > On 4/26/20 6:48 PM, Patrick Palka wrote: > > > > > In the testcase below, the call to the target c

Re: [RFC] Clarify -ffinite-math-only documentation

"Dr. Matthias Kretz" writes: > On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote: >> Richard Biener via Gcc-patches writes: >> > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz wrote: >> >> Hi, >> >> >> >> This documentation change clarifies the effect of -ffinite-math-only. >> >>

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

On 4/27/20 3:33 PM, Patrick Palka wrote: On Mon, 27 Apr 2020, Jason Merrill wrote: On 4/27/20 10:45 AM, Patrick Palka wrote: On Mon, 27 Apr 2020, Patrick Palka wrote: On Mon, 27 Apr 2020, Jason Merrill wrote: On 4/26/20 6:48 PM, Patrick Palka wrote: In the testcase below, the call to the

[PATCH] PowerPC -mcpu=future tests, Introduction

This patch will allow me to group the 7 patches I have for GCC 10 to test the various -mcpu=future features. There are 7 patches in this patch set: Patch #1: Add target support for -mpcrel and -mprefixed. Patch #2: Test that PLI/PADDI is generated to load or add large constants. Patch #3: Add a

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

On Thu, 23 Apr 2020 at 15:55, Christophe Lyon wrote: > > 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 s

Re: [PATCH] PowerPC -mcpu=future Patch 1 of 7, add target supports for -mpcrel and -mprefixed

This patch adds supports in target-supports.exp for -mpcrel and -mprefixed. Patch #1 of 7. 2020-04-27 Michael Meissner * lib/target-supports.exp (check_effective_target_powerpc_pcrel): New target for PowerPC -mcpu=future support. (check_effective_target_powerpc_prefixe

Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

On Mon, Apr 27, 2020 at 03:32:29PM -0400, Jason Merrill wrote: > Note that C++20 adds empty non-static data members with the > [[no_unique_address]] attribute. How will that fit into these ABIs and the > others that had issues with parameter passing? Are they also represented in the trees handed

[PATCH] PowerPC -mcpu=future Patch 2 of 7, Add PLI/PADDI tests

Add tests for generating PLI/PADDI with -mcpu=future. This is patch #2 of 7. This patch was run on a little endian power8 system running Linux and the patches succeeded. 2020-04-27 Michael Meissner * gcc.target/powerpc/prefix-add.c: New test for -mcpu=future generating PADDI

[PATCH] PowerPC -mcpu=future Patch 3 of 7, Add test for generating prefixed load/store

This patch adds a test that verifies that the compiler generates a prefixed load/store instruction where the compiler cannot generate the instruction directly because the offset is not a valid DS or DQ offset. A DS offset must have the bottom 2 bits clear. A DQ offset must have the bottom 4 bits

Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

On 27/04/20 21:47 +0200, Jakub Jelinek wrote: On Mon, Apr 27, 2020 at 03:32:29PM -0400, Jason Merrill wrote: Note that C++20 adds empty non-static data members with the [[no_unique_address]] attribute. How will that fit into these ABIs and the others that had issues with parameter passing? Ar

[PATCH] PowerPC -mcpu=future Patch 4 of 7, Make sure an invalid instruction is not generated

This test validates that the compiler does not generate a prefixed load/store instruction with an update form. The prefixed load/store instructions do not have an update form. This is patch #4 of 7. This patch was run on a little endian power8 system running Linux, and the tests passed. Can I c

[PATCH] PowerPC -mcpu=future Patch 5 of 7, Add prefixed load/store tests with large numeric offsets

This patch adds tests for -mcpu=future generating prefixed load/store instructions with large numeric offsets. This is patch #5 of 7. This patch was tested on a little endian power8 system running Linux, and the tests passed. Can I check this into GCC 10? 2020-04-27 Michael Meissner

[PATCH] PowerPC -mcpu=future Patch 6 of 7, add PC-relative tests

This patch adds PC-relative tests for -mcpu=future. This is patch #6 of 7. I have checked this on a little endian power8 system running Linux, and all tests passed. Can I check this into the GCC 10 trunk? 2020-04-27 Michael Meissner * gcc.target/powerpc/prefix-pcrel.h: New set of te

[PATCH] PowerPC -mcpu=future Patch 7 of 7, Add test for stack checking and large stack frames

This patch adds a test for the case where we have prefixed load/store instructions, a large stack frame, and stack checking is enabled. This is patch #7 of 7. I have checked this patch on a little endian power8 system running Linux, and the test passed. Can I check this into the GCC 10 trunk? 2

Re: [PATCH] coroutines: Pass class ref to traits lookup and promise allocator [PR94760]

On 4/27/20 2:41 PM, Iain Sandoe wrote: Nathan Sidwell wrote: On 4/25/20 11:08 AM, Iain Sandoe wrote: + tree arg = DECL_ARGUMENTS (fndecl); + bool lambda_p = LAMBDA_TYPE_P (DECL_CONTEXT (fndecl)); I think LAMBDA_FUNCTION_P (fndecl) expresses intent better. done in both places. +

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

On Apr 27, 2020, at 12:43 PM, Christophe Lyon via Gcc-patches wrote: > It seems it's not possible to write these tests so that they works in > all combinations of toolchain configuration and options used for testing :-( So, generally, you can have each change in configuration reflected in a pre

Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

On 4/27/20 3:53 PM, Jonathan Wakely wrote: On 27/04/20 21:47 +0200, Jakub Jelinek wrote: On Mon, Apr 27, 2020 at 03:32:29PM -0400, Jason Merrill wrote: Note that C++20 adds empty non-static data members with the [[no_unique_address]] attribute.  How will that fit into these ABIs and the other

[pushed] c++: Avoid ICE with dependent attribute on type.

We previously happened to accept this testcase, but never actually did anything useful with the attribute. The patch for PR86379 stopped using TREE_TYPE as USING_DECL_SCOPE, so 'using A::b' no longer had TREE_TYPE set, so the language-independent decl_attributes started crashing on it. GNU attrib

Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

On Mon, Apr 27, 2020 at 05:11:38PM -0400, Jason Merrill wrote: > > struct empty { }; > > struct X { [[no_unique_address]] empty e; }; > > > > and have them be layout compatible, otherwise the attribute is useless > > to the standard library. > > Why are zero-size fields changing layout/parameter

Re: [RFC] Clarify -ffinite-math-only documentation

On Montag, 27. April 2020 21:39:17 CEST Richard Sandiford wrote: > "Dr. Matthias Kretz" writes: > > On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote: > >> Richard Biener via Gcc-patches writes: > >> > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz wrote: > >> >> Hi, > >> >> > >>

[PATCH] libstdc++: Fix subrange::advance and subrange::prev (LWG 3433)

This implements the proposed resolution of LWG 3433, which fixes subrange::advance when called with a negative argument. Tested on x86_64-pc-linux-gnu, does this look OK to commit? libstdc++-v3/ChangeLog: LWG 3433 subrange::advance(n) has UB when n < 0 * include/std/ranges (subra

[committed] libphobos: Backport extern(C) bindings from druntime 2.091

Hi, This patch merges the D runtime library with upstream druntime 47688279. Backports latest extern(C) bindings from druntime, fixing PR90718 and PR90719. Both of which should be cherry-picked into the gcc-9 branch. Bootstrapped and regression tested on x86_64-linux-gnu, and commited to mainlin