Re: [PATCH v2] c++: Member template function lookup failure [PR94799]

On Wed, Apr 29, 2020 at 05:10:44PM -0400, Jason Merrill via Gcc-patches wrote: > On 4/28/20 11:55 PM, Marek Polacek wrote: > > Whew, this took a while. We fail to parse "p->template A::a()" > > (where p is of type A *) because since r249752 we treat the RHS of the -> > > as dependent and avoid a l

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

On 4/30/20 2:02 PM, Richard Sandiford wrote: > Jeff Law writes: >> On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote: >>> I guess at this point it needs a review from someone else though. >>> Jeff, WDYT? Attached again below, this time without the shonky mime type. >> It looks reasonable

RE: [PATCH][AARCH64] Fix for PR86901

Hey all-apologies for the long delay. Haven't had time until recently to look into this further. >>> The zero extract now matching against other modes would generate a >>> test + branch rather than the combined instruction which led to the >>> code size regression. I've updated the patch so that t

Re: [PATCH] diagnostics: get_option_html_page fixes

On Thu, 2020-04-30 at 23:38 +0200, Jakub Jelinek wrote: > On Thu, Apr 30, 2020 at 05:31:22PM -0400, David Malcolm wrote: > > On Thu, 2020-04-30 at 23:26 +0200, Jakub Jelinek wrote: > > > On Thu, Apr 30, 2020 at 05:18:13PM -0400, David Malcolm wrote: > > > > Thanks for working on this; sorry for get

Re: [PATCH] diagnostics: get_option_html_page fixes

On Thu, Apr 30, 2020 at 05:31:22PM -0400, David Malcolm wrote: > On Thu, 2020-04-30 at 23:26 +0200, Jakub Jelinek wrote: > > On Thu, Apr 30, 2020 at 05:18:13PM -0400, David Malcolm wrote: > > > Thanks for working on this; sorry for getting these wrong. > > > > > > Is is possible to build gfortran

Re: [PATCH] diagnostics: get_option_html_page fixes

On Thu, 2020-04-30 at 23:26 +0200, Jakub Jelinek wrote: > On Thu, Apr 30, 2020 at 05:18:13PM -0400, David Malcolm wrote: > > Thanks for working on this; sorry for getting these wrong. > > > > Is is possible to build gfortran without C and C++? If so, then if > > I'm > > It is possible without C+

Re: [PATCH] diagnostics: get_option_html_page fixes

On Thu, Apr 30, 2020 at 05:18:13PM -0400, David Malcolm wrote: > Thanks for working on this; sorry for getting these wrong. > > Is is possible to build gfortran without C and C++? If so, then if I'm It is possible without C++, but not without C. E.g. --enable-languages=fortran,go will actually

Re: [PATCH] diagnostics: get_option_html_page fixes

On Thu, 2020-04-30 at 15:02 +0200, Jakub Jelinek wrote: > Hi! > > (Sorry to David, apparently I've posted it only privately, not to > gcc-patches, so reposting). > > While testing the --with-documentation-root-url= changes, I run into > [Wreturn-type] URL pointing to gfortran documentation where

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

Hi! As Will says, the subject is much too long. 50 chars max is the ideal. "target supports" isn't clear; maybe rs6000: Add effective targets powerpc_{pcrel,prefixed_addr} or something like it (prefix, colon, capital, no dot). On Mon, Apr 27, 2020 at 03:46:06PM -0400, Michael Meissner

Re: [PATCH] coroutines: Fix handling of artificial vars [PR94886]

Nathan Sidwell wrote: On 4/30/20 9:24 AM, Iain Sandoe wrote: The testcase ICEs because the range-based for generates three artificial variables that need to be allocated to the coroutine frame but, when walking the BIND_EXR that contains these, the DECL_INITIAL for one of them refers to an e

[wwwdocs] Improve ugly formatting for std::atomic

This looks much nicer for me, because the font for the part is much smaller than the other text. Committed to wwwdocs. commit 3f573b5fe7df858a27b0275edc5fd4386804ae83 Author: Jonathan Wakely Date: Thu Apr 30 20:54:09 2020 +0100 Improve ugly formatting for std::atomic diff --git a/htdocs

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

On Thu, 2020-04-30 at 20:02 +0100, Richard Sandiford wrote: > Jeff Law writes: > > On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote: > > > Peter Bergner writes: > > > > On 4/29/20 4:15 PM, Peter Bergner wrote: > > > > > On 4/29/20 3:28 PM, Richard Sandiford wrote: > > > > > > (Sorry for

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

Jeff Law writes: > On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote: >> Peter Bergner writes: >> > On 4/29/20 4:15 PM, Peter Bergner wrote: >> > > On 4/29/20 3:28 PM, Richard Sandiford wrote: >> > > > (Sorry for going ahead and writing an alternative patch, since if we do >> > > > go fo

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

On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote: > Peter Bergner writes: > > On 4/29/20 4:15 PM, Peter Bergner wrote: > > > On 4/29/20 3:28 PM, Richard Sandiford wrote: > > > > (Sorry for going ahead and writing an alternative patch, since if we do > > > > go for this, I guess the earli

Re: [PATCH] c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

On Thu, 30 Apr 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > If there are _Atomic side-effects in the parameter declarations > of non-nested function, when they are parsed, current_function_decl is > NULL, the create_artificial_label created labels during build_atomic* are > then adjusted

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

Richard Sandiford writes: > Peter Bergner writes: >> On 4/29/20 4:15 PM, Peter Bergner wrote: >>> On 4/29/20 3:28 PM, Richard Sandiford wrote: (Sorry for going ahead and writing an alternative patch, since if we do go for this, I guess the earlier misdirections will have wasted two days

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel wrote: > > On 30.04.20 08:25, Richard Biener via Gcc-patches wrote: > > On Wed, Apr 29, 2020 at 5:56 PM Jeff Law wrote: > >> > >> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote: > >>> > >>> Btw, does s390 have different inli

[PATCH] c++: Parenthesized-init of aggregates accepts invalid code [PR94885]

Here we have (conceptually *) something like struct B { }; struct D : B { }; D(0); // invalid and in C++20 the ()-initialization has created a { 0 } constructor that it tries to initialize an object of type D with. We should reject initializing an object of type B from 0, but we wrongly ac

Re: [PR c+ 94827]: template parm with default requires

On 4/30/20 10:35 AM, Nathan Sidwell wrote: On 4/30/20 10:18 AM, Jason Merrill wrote: On 4/29/20 2:50 PM, Nathan Sidwell wrote: Jason, this is the patch you suggested, as I understood it.  I kept finish_nested_require's saving of the (converted) current_template_parms, becase of the comment ab

[committed] libstdc++: Avoid errors in allocator's noexcept-specifier (PR 89510)

This fixes a regression due to the conditional noexcept-specifier on std::allocator::construct and std::allocator::destroy, as well as the corresponding members of new_allocator, malloc_allocator, and allocator_traits. Those noexcept-specifiers were using expressions which might be ill-formed, whic

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

On 30.04.20 08:25, Richard Biener via Gcc-patches wrote: > On Wed, Apr 29, 2020 at 5:56 PM Jeff Law wrote: >> >> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote: >>> >>> Btw, does s390 have different inlining parameters somehow? >> I think so. We saw a ton of backend warni

Re: [PATCH] ipa: Cgraph verification fix (PR 94856)

> Hi, > > PR 94856 is a call graph verifier error. We have a method which (in > the course of IPA-CP) loses its this pointer because it is unused and > the pass then does not clone all the this adjusting thunks and just > makes the calls go straight to the new clone - and then the verifier > comp

RE: [PATCH] aarch64: prefer using csinv, csneg in zero extend contexts

> -Original Message- > From: Richard Sandiford > Sent: 30 April 2020 15:13 > To: Alex Coplan > Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > ; nd > Subject: Re: [PATCH] aarch64: prefer using csinv, csneg in zero extend > contexts > > Yeah, I was

Re: [PR c+ 94827]: template parm with default requires

On 4/30/20 10:18 AM, Jason Merrill wrote: On 4/29/20 2:50 PM, Nathan Sidwell wrote: Jason, this is the patch you suggested, as I understood it.  I kept finish_nested_require's saving of the (converted) current_template_parms, becase of the comment about use in diagnostics. Is this what you m

[PATCH] ipa: Cgraph verification fix (PR 94856)

Hi, PR 94856 is a call graph verifier error. We have a method which (in the course of IPA-CP) loses its this pointer because it is unused and the pass then does not clone all the this adjusting thunks and just makes the calls go straight to the new clone - and then the verifier complains that the

Re: [PR c+ 94827]: template parm with default requires

On 4/29/20 2:50 PM, Nathan Sidwell wrote: Jason, this is the patch you suggested, as I understood it.  I kept finish_nested_require's saving of the (converted) current_template_parms, becase of the comment about use in diagnostics. Is this what you meant? Yes, this looks fine. But I don't

Re: [PATCH] aarch64: prefer using csinv, csneg in zero extend contexts

Alex Coplan writes: >> At the risk of feature creep :-) a useful third pattern could be >> to combine a zero-extended operator result with an existing DImode value. >> In that case, the existing DImode value really can be "rZ" and should >> always be in the "else" arm of the if_then_else. E.g.: >

[committed] diagnostics: Fix spelling in comment

gcc/ChangeLog: * pretty-print.c (pp_take_prefix): Fix spelling in comment. Committed to master as obvious. commit 04e88369a7d95492efccf8f527d27cca74664ea7 Author: Jonathan Wakely Date: Thu Apr 30 14:42:24 2020 +0100 diagnostics: Fix spelling in comment gcc/ChangeLog:

Re: [PR c+ 94827]: template parm with default requires

On 4/29/20 2:50 PM, Nathan Sidwell wrote: Jason, this is the patch you suggested, as I understood it.  I kept finish_nested_require's saving of the (converted) current_template_parms, becase of the comment about use in diagnostics. this extended test that tries to call the function ices wit

Re: [PATCH] coroutines: Fix handling of artificial vars [PR94886]

On 4/30/20 9:24 AM, Iain Sandoe wrote: Hi Another case found when building the folly experimental coros stuff. tested on x86_64-darwin so far, OK for master after testing on x86_64-linux? thanks Iain The testcase ICEs because the range-based for generates three artificial variables that need to

Re: [PATCH] coroutines: Fix handling of target cleanup exprs [PR94883]

On 4/30/20 8:53 AM, Iain Sandoe wrote: The problem here is that target cleanup expressions have been added to the initialisers for the awaitable (and returns of non-trivial values from await_suspend() calls). This is because the expansion of the co_await into its control flow is not apparent to

Re: [PATCH] coroutines: Fix cases where proxy variables are used [PR94879]

On 4/30/20 8:33 AM, Iain Sandoe wrote: There are several places where the handling of a variable declaration depends on whether it corresponds to a compiler temporary, or to some other entity. We were testing that var decls were artificial in determining this. However, proxy vars are also arti

RE: [PATCH] aarch64: prefer using csinv, csneg in zero extend contexts

Hi Richard, Many thanks for the detailed review. I've attached an updated patch based on your comments (bootstrapped and regtested on aarch64-linux). > -Original Message- > From: Richard Sandiford > Sent: 29 April 2020 17:16 > To: Alex Coplan > Cc: gcc-patches@gcc.gnu.org; Richard Earns

[PATCH] coroutines: Fix handling of artificial vars [PR94886]

Hi Another case found when building the folly experimental coros stuff. tested on x86_64-darwin so far, OK for master after testing on x86_64-linux? thanks Iain The testcase ICEs because the range-based for generates three artificial variables that need to be allocated to the coroutine frame but

Re: [PATCH] wwwdocs: Added mentioning of TX3 chip to the list of the processors

On 30.4.2020 13:05 , Kyrylo Tkachov wrote: -Original Message- From: Gerald Pfeifer Sent: 30 April 2020 10:53 To: Kyrylo Tkachov Cc: Anton Youdkevitch ; gcc- patc...@gcc.gnu.org; Joseph S. Myers Subject: RE: [PATCH] wwwdocs: Added mentioning of TX3 chip to the list of the processors

Re: [PATCH] match.pd: Optimize (x < 0) != (y < 0) into (x ^ y) < 0 [PR94718]

On Thu, 30 Apr 2020, Jakub Jelinek wrote: > Hi! > > The following patch (on top of the two other PR94718 patches) performs the > actual optimization requested in the PR. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1? > > 2020-04-30 Jakub Jelinek > > PR tree-

[PATCH] match.pd: Optimize (x < 0) != (y < 0) into (x ^ y) < 0 [PR94718]

Hi! The following patch (on top of the two other PR94718 patches) performs the actual optimization requested in the PR. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1? 2020-04-30 Jakub Jelinek PR tree-optimization/94718 * match.pd ((X < 0) != (Y < 0) int

[PATCH] diagnostics: get_option_html_page fixes

Hi! (Sorry to David, apparently I've posted it only privately, not to gcc-patches, so reposting). While testing the --with-documentation-root-url= changes, I run into [Wreturn-type] URL pointing to gfortran documentation where it obviously isn't documented. The following patch updates the list o

Re: [PATCH] tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]

On Thu, Apr 30, 2020 at 08:36:32AM +0200, Richard Biener via Gcc-patches wrote: > On Wed, Apr 29, 2020 at 11:43 PM Marek Polacek via Gcc-patches > wrote: > > > > Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it > > gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built b

[PATCH] c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

Hi! If there are _Atomic side-effects in the parameter declarations of non-nested function, when they are parsed, current_function_decl is NULL, the create_artificial_label created labels during build_atomic* are then adjusted by store_parm_decls through set_labels_context_r callback. Unfortunatel

[PATCH] coroutines: Fix handling of target cleanup exprs [PR94883]

Hi Another case found building folly’s experimental coros tests. tested on x86_64-darwin, linux, powerpc64-linux OK for master? thanks Iain The problem here is that target cleanup expressions have been added to the initialisers for the awaitable (and returns of non-trivial values from await

[PATCH] coroutines: Fix cases where proxy variables are used [PR94879]

Hi, This was found when attempting to build folly’s experimental coros tests. tested on x86_64-darwin, linux, powerpc64-linux ok for master? thanks Iain There are several places where the handling of a variable declaration depends on whether it corresponds to a compiler temporary, or to so

RE: Should ARMv8-A generic tuning default to -moutline-atomics

> -Original Message- > From: Gcc-patches On Behalf Of Kyrylo > Tkachov > Sent: 30 April 2020 11:57 > To: Andrew Pinski ; Florian Weimer > > Cc: gcc-patches@gcc.gnu.org; nmeye...@amzn.com > Subject: RE: Should ARMv8-A generic tuning default to -moutline-atomics > > [Moving to gcc-patche

Re: Should ARMv8-A generic tuning default to -moutline-atomics

On 30/04/2020 11:56, Kyrylo Tkachov wrote: > [Moving to gcc-patches] > >> -Original Message- >> From: Gcc On Behalf Of Andrew Pinski via Gcc >> Sent: 30 April 2020 07:21 >> To: Florian Weimer >> Cc: GCC Mailing List ; nmeye...@amzn.com >> Subject: Re: Should ARMv8-A generic tuning defaul

RE: Should ARMv8-A generic tuning default to -moutline-atomics

[Moving to gcc-patches] > -Original Message- > From: Gcc On Behalf Of Andrew Pinski via Gcc > Sent: 30 April 2020 07:21 > To: Florian Weimer > Cc: GCC Mailing List ; nmeye...@amzn.com > Subject: Re: Should ARMv8-A generic tuning default to -moutline-atomics > > On Wed, Apr 29, 2020 at 6

[committed] d: Fix documentation of -defaultlib= and -debuglib=

Hi, This patch corrects the documentation of -defaultlib= and -debuglib=. >From the generated manpages, it was not clear that its usage is '-debuglib='. Verified the contents of the generated manpage, committed to mainline. Regards Iain. --- gcc/d/ChangeLog: * gdc.texi (Options for Lin

[committed] d: Merge upstream dmd 934df6f8c, druntime 7bdd83d7 (PR90719, PR94825)

Hi, This patch corrects a previous change made to the SPARC stdc bindings, and backports PPC-related fixes. The library and language testsuite now passes fully on powerpc64le-linux-gnu. Backported from upstream dmd 934df6f8c, and druntime 7bdd83d7. Bootstrapped and regression tested on powerpc6

Re: [OpenMP, gimplifier] 'inform' after 'error' diagnostic

On Thu, Apr 30, 2020 at 12:07:32PM +0200, Thomas Schwinge wrote: > Hi! > > Is the attached OK for master branch, in next stage 1? It may even be > obvious, per our diagnostic conventions? If approving this patch, please > respond with "Reviewed-by: NAME " so that your effort will be > recorded i

[OpenMP, gimplifier] 'inform' after 'error' diagnostic

Hi! Is the attached OK for master branch, in next stage 1? It may even be obvious, per our diagnostic conventions? If approving this patch, please respond with "Reviewed-by: NAME " so that your effort will be recorded in the commit log, see . Grüße Thomas

RE: [PATCH] wwwdocs: Added mentioning of TX3 chip to the list of the processors

> -Original Message- > From: Gerald Pfeifer > Sent: 30 April 2020 10:53 > To: Kyrylo Tkachov > Cc: Anton Youdkevitch ; gcc- > patc...@gcc.gnu.org; Joseph S. Myers > Subject: RE: [PATCH] wwwdocs: Added mentioning of TX3 chip to the list of > the processors > > On Thu, 30 Apr 2020, Kyr

RE: [PATCH] wwwdocs: Added mentioning of TX3 chip to the list of the processors

On Thu, 30 Apr 2020, Kyrylo Tkachov wrote: > Ok. Ah, and you also pushed it in Git. (I was just going to do it since Anton does not appear to have an account, and noticed it was a no-op. ;-) Thanks, Gerald

Re: [PATCH] --with-{documentation,changes}-root-url tweaks

On Thu, Apr 30, 2020 at 10:44 AM Jakub Jelinek wrote: > > Hi! > On Thu, Apr 30, 2020 at 08:42:39AM +0200, Richard Biener wrote: > > , CHANGES_URL ("gcc-10/changes.html#empty_base"); > > > > where the macro would just use preprocessor string concatenation? > > Ok, the following patch implements i

Re: arm: Fix vfp_operand_register for VFP HI regs

On Wed, 29 Apr 2020 at 18:40, Kyrylo Tkachov wrote: > > Hi Christophe, > > > -Original Message- > > From: Gcc-patches On Behalf Of > > Christophe Lyon via Gcc-patches > > Sent: 29 April 2020 16:53 > > To: gcc Patches > > Subject: arm: Fix vfp_operand_register for VFP HI regs > > > > Hi,

[PATCH] --with-{documentation,changes}-root-url tweaks

Hi! On Thu, Apr 30, 2020 at 08:42:39AM +0200, Richard Biener wrote: > , CHANGES_URL ("gcc-10/changes.html#empty_base"); > > where the macro would just use preprocessor string concatenation? Ok, the following patch implements it (doesn't introduce a separate macro and just uses CHANGES_ROOT_URL

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

Peter Bergner writes: > On 4/29/20 4:15 PM, Peter Bergner wrote: >> On 4/29/20 3:28 PM, Richard Sandiford wrote: >>> (Sorry for going ahead and writing an alternative patch, since if we do >>> go for this, I guess the earlier misdirections will have wasted two days >>> of your time. But it seemed

[PATCH v2] Add handling of MULT_EXPR/PLUS_EXPR for wrapping overflow in affine combination(PR83403)

Update the patch with overflow check. Bootstrap and regression tested PASS on Power8-LE. Use determine_value_range to get value range info for fold convert expressions with internal operation PLUS_EXPR/MINUS_EXPR/MULT_EXPR when not overflow on wrapping overflow inner type. i.e.: (long unsigne

Re: [Patch, Fortran] OpenMP/OpenACC – fix more issues with OPTIONAL

On Thu, Apr 30, 2020 at 08:24:02AM +0200, Richard Biener wrote: > On Wed, Apr 29, 2020 at 5:05 PM Tobias Burnus wrote: > > was a bit on the backburner but I now digged again. > > See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848 > > > > The problem is a generated static array variable in the

RE: [PATCH] wwwdocs: Added mentioning of TX3 chip to the list of the processors

> -Original Message- > From: Anton Youdkevitch > Sent: 28 April 2020 19:31 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ; ger...@pfeifer.com; > jos...@codesourcery.com > Subject: [PATCH] wwwdocs: Added mentioning of TX3 chip to the list of the > processors > > This adds mentionin

Re: [PATCH] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Thu, Apr 30, 2020 at 08:42:39AM +0200, Richard Biener wrote: > > --- gcc/config/arm/arm.c.jj 2020-04-29 13:12:46.736007298 +0200 > > +++ gcc/config/arm/arm.c2020-04-29 14:34:04.878864236 +0200 > > @@ -6416,6 +6416,8 @@ aapcs_vfp_is_call_or_return_candidate (e > > && ((a