[PATCH] c++: Get rid of convert_like* macros.

The convert_like* macros were introduced in 2000-03-05 Nathan Sidwell * call.c (convert_like): Macrofy. (convert_like_with_context): New macro. but now we can use overloading so we can do away with the macros. I've also taken this chance to rename _real to _internal to make it

Re: [PATCH] c++: Get rid of convert_like* macros.

On Thu, Jul 16, 2020 at 09:16:06AM -0400, Nathan Sidwell wrote: > On 7/15/20 6:59 PM, Marek Polacek wrote: > > The convert_like* macros were introduced in > > > > 2000-03-05 Nathan Sidwell > > > > * call.c (convert_like): Macrofy. > > (convert_like_with_context): New macro. >

[PATCH] c++: Variable template and template parameter pack [PR96218]

This is DR 2032 which says that the restrictions regarding template parameter packs and default arguments apply to variable templates as well, but we weren't detecting that. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: DR 2032 PR c++/96218

[committed] c++: Add test for DR 188.

Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: DR 188 * g++.dg/DRs/dr188.C: New test. --- gcc/testsuite/g++.dg/DRs/dr188.C | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 gcc/testsuite/g++.dg/DRs/dr188.C diff --git a/gcc/testsuite/g++.dg

[PATCH] c++: Fixing the wording of () aggregate-init [PR92812]

P1975R0 tweaks the static_cast wording: it says that "An expression e can be explicitly converted to a type T if [...] T is an aggregate type having a first element x and there is an implicit conversion sequence from e to the type of x." This already works for classes, e.g.: struct Aggr { int x

Re: [PATCH] c++: Fixing the wording of () aggregate-init [PR92812]

On Tue, Jul 21, 2020 at 12:53:03PM +0300, Ville Voutilainen wrote: > On Tue, 21 Jul 2020 at 02:28, Marek Polacek wrote: > > > > P1975R0 tweaks the static_cast wording: it says that "An expression e can be > > explicitly converted to a type T if [...] T is an aggregate type having a > > first > >

Re: [PATCH] c++: Fixing the wording of () aggregate-init [PR92812]

On Tue, Jul 21, 2020 at 10:03:37PM +0300, Ville Voutilainen via Gcc-patches wrote: > On Tue, 21 Jul 2020 at 21:56, Marek Polacek wrote: > > > > On Tue, Jul 21, 2020 at 12:53:03PM +0300, Ville Voutilainen wrote: > > > On Tue, 21 Jul 2020 at 02:28, Marek Polacek wrote: > > > > > > > > P1975R0 twea

RFC: Monitoring old PRs, new dg directives

In Bugzilla, for the c++ component, we currently have over 3200 open bugs. In my experience, a good amount of them have already been fixed; my periodical sweeps always turn up a bunch of PRs that had already been fixed previously. Sometimes my sweeps are more or less random, but more often than no

Re: [PATCH] c++: Fixing the wording of () aggregate-init [PR92812]

On Wed, Jul 29, 2020 at 07:21:46PM -0400, Jason Merrill via Gcc-patches wrote: > On 7/20/20 7:28 PM, Marek Polacek wrote: > > P1975R0 tweaks the static_cast wording: it says that "An expression e can be > > explicitly converted to a type T if [...] T is an aggregate type having a > > first > > ele

Re: [PATCH] c++: Variable template and template parameter pack [PR96218]

On Wed, Jul 29, 2020 at 05:56:56PM -0400, Jason Merrill via Gcc-patches wrote: > On 7/16/20 11:06 AM, Marek Polacek wrote: > > This is DR 2032 which says that the restrictions regarding template > > parameter packs and default arguments apply to variable templates as > > well, but we weren't detect

[committed] c++: Remove unused declaration.

gcc/cp/ChangeLog: * cp-tree.h (after_nsdmi_defaulted_late_checks): Remove. --- gcc/cp/cp-tree.h | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index 1e583efd61d..fc54e6bb9bd 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -6809,7 +6809,6 @@

[PATCH] c++: Template keyword following :: [PR96082]

In r9-4235 I tried to make sure that the template keyword follows a nested-name-specifier. :: is a valid nested-name-specifier, so I also have to check 'globalscope' before giving the error. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10/9? gcc/cp/ChangeLog: PR c++/96082

Re: RFC: Monitoring old PRs, new dg directives

dfail? Good point, I missed that I could use xfail and xpass. Fixed. For accepts_invalid I think we *could* use the existing directives, if you know where to expect an error. But for ICEs we currently have nothing that would work well. I'll probably drop dg-accepts-invalid completely.

Re: RFC: Monitoring old PRs, new dg directives

On Tue, Jul 28, 2020 at 09:02:17PM -0600, Jeff Law wrote: > On Tue, 2020-07-28 at 17:44 -0400, Marek Polacek via Gcc-patches wrote: > > In Bugzilla, for the c++ component, we currently have over 3200 open bugs. > > In > > my experience, a good amount of them have a

Re: RFC: Monitoring old PRs, new dg directives

t the fix > is made (rather than some time after the fact). I appreciate the feedback! > Marek Polacek via Gcc-patches writes: > > […] > > My thinking is that for: > > > > * rejects-valid: use the existing dg-xfail-if > > * accepts-valid: use the new dg-accepts

Re: RFC: Monitoring old PRs, new dg directives

On Wed, Jul 29, 2020 at 04:37:03PM -0400, Jason Merrill wrote: > On Tue, Jul 28, 2020 at 5:45 PM Marek Polacek via Gcc-patches < > gcc-patches@gcc.gnu.org> wrote: > > > In Bugzilla, for the c++ component, we currently have over 3200 open > > bugs. In > > my exper

Re: RFC: Monitoring old PRs, new dg directives

arnation of this patch so I've dropped it. Thanks, Marek > On 7/28/20 3:44 PM, Marek Polacek via Gcc-patches wrote: > > In Bugzilla, for the c++ component, we currently have over 3200 open bugs. > > In > > my experience, a good amount of them have already been fixed; my

Re: RFC: Monitoring old PRs, new dg directives

On Thu, Jul 30, 2020 at 11:08:03AM +0200, Martin Liška wrote: > Hello. > > I support the initiative! > What would be nice to add leading 'PR component/12345' > to a git commit so that these test additions are linked to bugzilla issues. Thanks! Yes, it should be clear which test tests a PR that h

Re: RFC: Monitoring old PRs, new dg directives

On Thu, Jul 30, 2020 at 11:54:23AM +0200, Jakub Jelinek via Gcc-patches wrote: > On Tue, Jul 28, 2020 at 05:44:47PM -0400, Marek Polacek via Gcc-patches wrote: > > We will still have a surfeit of bugs that we've given short shrift to, but > > let's at least automate

Re: RFC: Monitoring old PRs, new dg directives

On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump wrote: > I think the read of the room is that people think it would be generally > useful, so let approve the general plan. Cool. > So, now we are down to the fine details. Please do see just how far you can > stretch the existing mechanisms

Re: RFC: Monitoring old PRs, new dg directives

On Tue, Aug 04, 2020 at 03:53:50PM -0700, Mike Stump wrote: > On Aug 4, 2020, at 3:16 PM, Marek Polacek via Gcc-patches > wrote: > > > > The benefit of dg-accepts-invalid was that you would > > get an XPASS even for a test that should not be accepted, but you didn'

Re: RFC: Monitoring old PRs, new dg directives

On Tue, Aug 04, 2020 at 03:45:11PM -0700, Mike Stump wrote: > On Aug 4, 2020, at 3:08 PM, Marek Polacek via Gcc-patches > wrote: > > > > That works well if you know where to expect an error. But if you don't, > > it's > > worse. E.g., > >

Re: RFC: Monitoring old PRs, new dg directives

On Wed, Aug 05, 2020 at 09:04:53AM +0100, Richard Sandiford wrote: > Marek Polacek writes: > > On Wed, Jul 29, 2020 at 09:40:35AM +0100, Richard Sandiford wrote: > >> I guess there's a possibility that some tests happen to pass already > >> on some targets. That's more likely with middle-end and

Re: RFC: Monitoring old PRs, new dg directives

On Wed, Aug 05, 2020 at 08:58:40AM +0100, Richard Sandiford wrote: > Marek Polacek via Gcc-patches writes: > > On Thu, Jul 30, 2020 at 11:54:23AM +0200, Jakub Jelinek via Gcc-patches > > wrote: > >> On Tue, Jul 28, 2020 at 05:44:47PM -0400, Marek Polacek via Gcc-patche

Re: RFC: Monitoring old PRs, new dg directives

On Tue, Aug 04, 2020 at 08:54:32PM -0400, Marek Polacek via Gcc-patches wrote: > On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump wrote: > > A word of caution, if we produce core files, before you add tons of core > > file producing test cases, you'll want to submit a, ul

Re: RFC: Monitoring old PRs, new dg directives

On Wed, Aug 05, 2020 at 11:03:08AM -0400, Nathan Sidwell wrote: > On 8/4/20 8:54 PM, Marek Polacek via Gcc-patches wrote: > > On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump wrote: > > > I think the read of the room is that people think it would be generally > > >

Re: RFC: Monitoring old PRs, new dg directives

On Wed, Aug 05, 2020 at 01:01:32PM -0700, Mike Stump wrote: > On Aug 4, 2020, at 5:54 PM, Marek Polacek wrote: > >> As you find it difficult to express a test using the existing mechanisms, > >> let's talk about those and see if anyone has a good idea on how to express > >> it. I think ICEs are

Re: RFC: Monitoring old PRs, new dg directives

On Thu, Aug 06, 2020 at 02:30:11PM +0200, Jakub Jelinek wrote: > On Thu, Aug 06, 2020 at 08:27:05AM -0400, Marek Polacek via Gcc-patches wrote: > > // PR c++/88003 > > // { dg-do compile { target c++14 } } > > // { dg-prune-output ".*internal compiler error

Re: RFC: Monitoring old PRs, new dg directives

On Thu, Aug 06, 2020 at 10:01:37AM -0400, Nathan Sidwell wrote: > On 8/5/20 7:29 PM, Marek Polacek wrote: > > On Wed, Aug 05, 2020 at 11:03:08AM -0400, Nathan Sidwell wrote: > > > On 8/4/20 8:54 PM, Marek Polacek via Gcc-patches wrote: > > > > On Tue, Aug 04, 2020 a

Re: RFC: Monitoring old PRs, new dg directives

AM -0400, Nathan Sidwell wrote: > > > > > On 8/4/20 8:54 PM, Marek Polacek via Gcc-patches wrote: > > > > > > On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump wrote: > > > > > > > I think the read of the room is that peopl

Re: [PATCH v6] c++: DR1710, template keyword in a typename-specifier [PR94057]

On Thu, Mar 26, 2020 at 01:43:28AM -0400, Jason Merrill wrote: > > > I think you want to check all typedefs like in e.g. > > > find_parameter_packs_r; > > > if the name is a typedef, it's only suitable if > > > alias_template_specialization_p. > > > > ..this: Since alias_template_specialization_p

[PATCH] c++: template keyword accepted before destructor names [PR94336]

This came up on the C++ core list recently. We don't diagnose the case when 'template' is followed by a destructor name which is not permitted by [temp.names]/5. PR c++/94336 - template keyword accepted before destructor names. * parser.c (cp_parser_unqualified_id): Give an error

[PATCH] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't expect null indexes for a constructor: /* ??? Here's to hoping the front end fills in all of the indices, so we don't have to figure out what's missing ourselves. */ gcc_assert (purpose); The indexes wer

Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote: > On 3/30/20 4:28 PM, Marek Polacek wrote: > > Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't > > expect null indexes for a constructor: > > > >/* ??? Here's to hoping the front end fill

Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via Gcc-patches wrote: > On 4/3/20 9:08 PM, Marek Polacek wrote: > > On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 3/30/20 4:28 PM, Marek Polacek wrote: > > > > Here we crash in the gimplifier bec

[PATCH] c++: C++20 DR 2237, disallow simple-template-id in cdtor.

This patch implements DR 2237 which says that a simple-template-id is no longer valid as the declarator-id of a constructor or destructor; see . It is not explicitly stated but out-of-line destructors with a simple-template-id are also meant to be ill-fo

Re: [PATCH v3] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On Mon, Apr 06, 2020 at 10:47:49AM -0400, Jason Merrill via Gcc-patches wrote: > On 4/4/20 1:56 PM, Marek Polacek wrote: > > On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 4/3/20 9:08 PM, Marek Polacek wrote: > > > > On Fri, Apr 03, 2020 at 03:01:37PM -

[PATCH] c++: Fix ICE-on-invalid with lambda template [PR94507]

While reducing something else I noticed that we ICE on the following invalid code. In tsubst_lambda_expr, tsubst_template_decl has already reported an error and returned the error_mark_node, so make sure we don't ICE on that. I'm using a goto here because we still have to do finish_struct because

[PATCH] c++: ICE with defaulted comparison operator [PR94478]

Here we ICE because early_check_defaulted_comparison passed a null ctx to same_type_p. The attached test is ill-formed according to [class.compare.default]/1, so fixed by detecting this case early. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/94478 - ICE with defau

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote: > Among the numerous regressions introduced by the change committed > to GCC 9 to allow string literals as template arguments is a failure > to recognize the C++ nullptr and GCC's __null constants as pointers. > For one,

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote: > On 4/7/20 1:50 PM, Marek Polacek wrote: > > On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches > > wrote: > > > Among the numerous regressions introduced by the change committed > > > to GCC 9 to allow string liter

Re: [PATCH v2] c++: Fix ICE-on-invalid with lambda template [PR94507]

On Wed, Apr 08, 2020 at 08:55:08AM -0400, Jason Merrill via Gcc-patches wrote: > On 4/6/20 9:05 PM, Marek Polacek wrote: > > While reducing something else I noticed that we ICE on the following > > invalid code. In tsubst_lambda_expr, tsubst_template_decl has already > > reported an error and retu

[PATCH] c++: Fix wrong paren-init of aggregates interference [PR93790]

This PR points out that we are rejecting valid code in C++20. The problem is that we were surreptitiously transforming T& t(e) into T& t{e} which is wrong, because the type of e had a conversion function to T, while aggregate initialization of t from e doesn't work. Therefore, I was viola

[PATCH] c++: make __is_constructible work with paren-init of aggrs [PR94149]

In C++20 this is well-formed: using T = int[2]; T t(1, 2); which means that std::is_constructible_v should be true. But constructible_expr immediately returned the error_mark_node when it saw a list with more than one element. To give accurate results in C++20, we have to try initializing th

[committed] c++: Add test for PR 86327.

Fixed by r264171. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/86327 * g++.dg/cpp1y/constexpr-return5.C: New test. --- gcc/testsuite/g++.dg/cpp1y/constexpr-return5.C | 12 1 file changed, 12 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp1y/conste

[PATCH] c++: Improve redeclared parameter name diagnostic [PR94588]

While reviewing [basic.scope.param] I noticed we don't show the location of the previous declaration when giving an error about "A parameter name shall not be redeclared in the outermost block of the function definition". Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++

[PATCH] c++: Fix ICE with { } as template argument [PR94592]

As an extension (there should be a CWG about this though), we support braced-init-list as a template argument, but convert_nontype_argument had trouble digesting them. We ICEd because of the double coercion we perform for template arguments: convert_nontype_argument called from finish_template_typ

[PATCH] c++: Fix crash with template spec in different namespace [PR94255]

This is an ICE on invalid, because we're specializing S::foo in the wrong namespace. cp_parser_class_specifier_1 parses S::foo in M and then it tries to push the nested-name-specifier of foo, which is S. By that, we're breaking the assumption of push_inner_scope that the pushed scope must be a sc

[PATCH] c++: Fix bogus -Wparentheses warning with fold-expression [PR94505]

We issue bogus -Wparentheses warnings (3 of them!) for this fold expression: ((B && true) || ...) Firstly, issuing a warning for a compiler-generated expression is wrong and secondly, B && true must be wrapped in ( ) otherwise you'll get error: binary expression in operand of fold-expression.

[PATCH] c++: Detect long double -> double narrowing [PR94590]

This PR points out that we don't detect long double -> double narrowing when long double happens to have the same precision as double; on x86_64 this can be achieved by -mlong-double-64. [dcl.init.list]#7.2 specifically says "from long double to double or float, or from double to float", but check

[PATCH] coroutines: Fix STRIP_NOPS usage.

parm = STRIP_NOPS (parm); is unnecessary and generates warning: operation on 'parm' may be undefined [-Wsequence-point] when cp/coroutines.cc is compiled with -std=c++11. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? * coroutines.cc (captures_temporary): Don't assign the re

Re: [PATCH v2] c++: Fix ICE with { } as template argument [PR94592]

On Mon, Apr 20, 2020 at 11:51:59AM -0400, Jason Merrill wrote: > On 4/17/20 4:28 PM, Marek Polacek wrote: > > As an extension (there should be a CWG about this though), we support > > braced-init-list as a template argument, but convert_nontype_argument > > had trouble digesting them. We ICEd beca

Re: [PATCH v2] c++: Fix ICE with { } as template argument [PR94592]

On Mon, Apr 20, 2020 at 06:37:08PM -0400, Jason Merrill wrote: > On 4/20/20 4:44 PM, Marek Polacek wrote: > > On Mon, Apr 20, 2020 at 11:51:59AM -0400, Jason Merrill wrote: > > > On 4/17/20 4:28 PM, Marek Polacek wrote: > > > > As an extension (there should be a CWG about this though), we support >

[PATCH] c++: Add test for c++/93807

This PR was initially accepts-invalid, but I think it's actually valid C++20 code. My reasoning is that in C++20 we no longer require the declaration of operator== (#if-defed in the test), because C++20's [temp.names]/2 says "A name is also considered to refer to a template if it is an unqualified

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

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 something like T t = x where T is a class ty

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

Re: [pushed] c++: implicit operator== with previous decl [PR94583]

On Sat, Apr 25, 2020 at 12:17:18AM -0400, Jason Merrill via Gcc-patches wrote: > P2085 clarified that a defaulted comparison operator must be the first > declaration of the function. Rejecting that avoids the ICE trying to > compare the noexcept-specifications. > > Tested x86_64-pc-linux-gnu, app

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

On Fri, Apr 24, 2020 at 04:07:03PM -0400, Jason Merrill via Gcc-patches wrote: > On 4/23/20 7:08 PM, Marek Polacek wrote: > > > > @@ -1252,6 +1252,8 @@ standard_conversion (tree to, tree from, tree > > > > expr, bool c_cast_p, > > > > if (flags & LOOKUP_PREFER_RVALUE) > > > > /* T

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

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 lookup in the enclosing context: since that rev cp_parser_template_name checks parser->context->object_type too, which here is unknown_t

Re: [wwwdocs] Correct status and macro for P1907R1

On Wed, Apr 29, 2020 at 10:51:21AM +0100, Jonathan Wakely wrote: > As noted in PR c++/94765 floating point types are not supported as > non-type template args. > > Marek added the P1907R1 paper in commit d59a823fb but didn't give it a > distinct entries for the "Supported in GCC?" and "SD-6 Featur

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

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 by build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1. When we strip_typedefs the element of the array "const d", we see it's a typedef_variant_p, so we

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

[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: [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: Ping: [PATCH] wwwdocs: Document support for extended identifiers added to GCC 10

On Wed, Mar 11, 2020 at 09:12:20AM -0400, Lewis Hyatt via Gcc-patches wrote: > Great, thank you very much for taking a look at it. Sorry if this > email is unnecessary noise, but it wasn't quite clear to me whether > this should also still be approved from a content perspective? I > didn't want to

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

On Fri, May 01, 2020 at 04:12:35PM -0400, Jason Merrill wrote: > > @@ -7754,9 +7755,22 @@ cp_parser_postfix_dot_deref_expression (cp_parser > > *parser, > > } > > if (dependent_p) > > -/* Tell cp_parser_lookup_name that there was an object, even though > > it's > > - type-depe

[PATCH] c++: ICE in value_dependent_expression_p in C++98 mode [PR94938]

Here we ICE with -std=c++98 since the newly added call to uses_template_parms (r10-6357): we hit 26530 gcc_assert (cxx_dialect >= cxx11 26531 || INTEGRAL_OR_ENUMERATION_TYPE_P (type)); and TYPE is a record type. The problem is that the argument to value_dependen

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

On Mon, May 04, 2020 at 05:41:37PM -0400, Jason Merrill via Gcc-patches wrote: > On 5/4/20 4:37 PM, Marek Polacek wrote: > > On Fri, May 01, 2020 at 04:12:35PM -0400, Jason Merrill wrote: > > > > @@ -7754,9 +7755,22 @@ cp_parser_postfix_dot_deref_expression > > > > (cp_parser *parser, > > > >

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

On Tue, May 05, 2020 at 01:01:00AM -0400, Jason Merrill wrote: > On 5/4/20 9:51 PM, Marek Polacek wrote: > > On Mon, May 04, 2020 at 05:41:37PM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 5/4/20 4:37 PM, Marek Polacek wrote: > > > > On Fri, May 01, 2020 at 04:12:35PM -0400, Jason Merr

Re: [PATCH v2] c++: ICE in value_dependent_expression_p in C++98 mode [PR94938]

On Mon, May 04, 2020 at 09:18:57PM -0400, Jason Merrill wrote: > On 5/4/20 7:32 PM, Marek Polacek wrote: > > Here we ICE with -std=c++98 since the newly added call to > > uses_template_parms > > (r10-6357): we hit > > 26530 gcc_assert (cxx_dialect >= cxx11 > > 26531

[PATCH] c++: ICE with -Wall and constexpr if [PR94937]

An ICE arises here because we call cp_get_callee_fndecl_nofold in a template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK. This tickles the INDIRECT_TYPE_P assert in cp_get_fndecl_from_callee. Jakub said in the PR that he'd hit a similar problem too and dealt with it in omp_declare_

Re: [PR C++/94946] ambiguous overload regression

On Wed, May 06, 2020 at 02:14:03PM -0400, Nathan Sidwell wrote: > @@ -0,0 +1,7 @@ > +// { dg-do compile { target { i?86-*-* x86_64-*-* } } } > +// { dg-options -m32 } > +// PR 94946 > +class a { > + template a(b (*)()); > + template a(b(__attribute__((fastcall)) *c)()); > +}; I think instead o

[PATCH] c++: ICE when shortening right shift [PR94955]

Since r10-6527 fold_for_warn calls maybe_constant_value, which means it can fold more than it previously could. In this testcase it means that cp_build_binary_op/RSHIFT_EXPR set short_shift because now we were able to fold op1 to an INTEGER_CST. But then when actually performing the shortening we

Re: [PATCH] c-family: Fix error-recovery ICE on __builtin_speculation_safe_value [PR94968]

On Thu, May 07, 2020 at 09:42:32AM +0200, Jakub Jelinek wrote: > Hi! > > If the second argument of __builtin_speculation_safe_value is > error_mark_node (or has such a type), we ICE during > useless_typ_conversion_p. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for

Re: [PATCH v2] c++: ICE with -Wall and constexpr if [PR94937]

On Wed, May 06, 2020 at 05:26:32PM -0400, Jason Merrill wrote: > On 5/5/20 6:17 PM, Marek Polacek wrote: > > An ICE arises here because we call cp_get_callee_fndecl_nofold in a > > template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK. > > This tickles the INDIRECT_TYPE_P assert in c

Re: [PATCH] c++: Fix spelling of non-static

On Thu, Mar 19, 2020 at 12:51:42PM -0400, Marek Polacek via Gcc-patches wrote: > On Thu, Mar 19, 2020 at 10:45:01AM -0600, Martin Sebor via Gcc-patches wrote: > > On 3/19/20 9:48 AM, Marek Polacek via Gcc-patches wrote: > > > I was looking at DR 296 and noticed that we say &quo

Re: [PATCH] c++: Fix spelling of non-static

On Thu, May 07, 2020 at 12:34:44PM -0600, Martin Sebor wrote: > On 5/7/20 11:24 AM, Marek Polacek wrote: > > On Thu, Mar 19, 2020 at 12:51:42PM -0400, Marek Polacek via Gcc-patches > > wrote: > > > On Thu, Mar 19, 2020 at 10:45:01AM -0600, Martin Sebor via Gcc-patches &

Re: [C++ Patch] PR 90915 [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

On Wed, Jan 29, 2020 at 10:06:51PM +0100, Paolo Carlini wrote: > Hi, > > On 29/01/20 19:00, Jason Merrill wrote: > > On 1/29/20 4:31 AM, Paolo Carlini wrote: > > > Hi, > > > > > > in this regression we issue a diagnostic about an incomplete type > > > (only a warning by default) and then we crash

Re: [C++ Patch] PR 90915 [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

On Thu, May 07, 2020 at 06:09:30PM -0600, Martin Sebor wrote: > On 5/7/20 5:03 PM, Marek Polacek via Gcc-patches wrote: > > On Wed, Jan 29, 2020 at 10:06:51PM +0100, Paolo Carlini wrote: > > > Hi, > > > > > > On 29/01/20 19:00, Jason Merrill wrote: > > &

Re: [PATCH] c++: C++20 DR 2237, disallow simple-template-id in cdtor.

On Sun, Apr 05, 2020 at 09:46:09PM -0400, Jason Merrill wrote: > On 4/4/20 7:30 PM, Marek Polacek wrote: > > This patch implements DR 2237 which says that a simple-template-id is > > no longer valid as the declarator-id of a constructor or destructor; > > see

[PATCH] c++: explicit(bool) malfunction with dependent expression [PR95066]

I forgot to set DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P when merging two function declarations and as a sad consequence, we never tsubsted the dependent explicit-specifier in tsubst_function_decl, leading to disregarding the explicit-specifier altogether, and wrongly accepting this test. Bootstrapped/r

[PATCH] c++: Function found via ADL when it should not [PR95074]

I noticed that we don't implement [basic.lookup.argdep]/3: quite correctly; it says "If X (the lookup set produced by unqualified lookup) contains -- a block-scope function declaration that is not a using-declaration [...] then Y (the lookup set produced by ADL) is empty." but we were still perform

[committed] c++: Fix g++.dg/parse/attr4.C test.

I noticed this test failing in C++11 mode. Tested x86_64-pc-linux-gnu, applying to trunk. * g++.dg/parse/attr4.C: Use c++11 in a target selector. --- gcc/testsuite/g++.dg/parse/attr4.C | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/g++.dg/parse/attr4.C

[PATCH] c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

DR 2289 clarified that since structured bindings have no C compatibility implications, they should be unique in their declarative region, see [basic.scope.declarative]/4.2. The duplicate_decls hunk is the gist of the patch, but that alone would not be enough to detect the 'A' case: cp_parser_decom

Re: New mklog script

On Fri, May 15, 2020 at 10:59:56AM +0200, Martin Liška wrote: > Hi. > > Since we moved to git world and we're in the preparation for ChangeLog > messages > being in git commit messages, I think it's the right time to also simplify > mklog > script. > > I'm sending a new version (which should ev

Re: New mklog script

On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote: > On 5/15/20 2:42 PM, Marek Polacek wrote: > > I actually use mklog -i all the time. But I can work around it if it > > disappears. > > Ah, I can see a consumer. > There's an updated version that supports that. > > For the future, wil

[PATCH] c++: Implement DR 1512, Pointer comparison vs qual convs [PR87699]

This patch resolves DR 1512 (and, by turn, DR 583). This entails: 1) Relational pointer comparisons against null pointer constants have been made ill-formed: void f(char *p) { if (p > 0) // ... } was always invalid in C but was -- accidentally -- allowed in C++. 2) Th

[PATCH] c++: Don't add built-in operator for ++ on bool.

This feels extremely obscure but at least it's an opportunity to fix the comments. P0002R1 removed deprecated operator++(bool) in C++17 so let's avoid adding a builtin overload candidate for ++ when the type is bool. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? * call.c (

[PATCH] c++: Regenerate cp/cfns.h.

Current cfns.h includes register-qualified variables and that wouldn't play well when bootstrapping with GCC that uses the C++17 dialect, because 'register' was removed in C++17. Regenerating it using the command specified in cfns.h luckily cleaned this up. Bootstrapped/regtested on x86_64-pc-lin

[PATCH] c++: Change the default dialect to C++17.

Since GCC 9, C++17 support is no longer experimental. It was too late to change the default C++ dialect to C++17 in GCC 10, but I think now it's time to pull the trigger (C++14 was made the default in GCC 6.1). We're still missing two C++17 library features, but that shouldn't stop us. See

[committed] c++: Add test for c++/95143

Already fixed by r10-8124-gceae6a13366d9646e172fc943fe8e221b70f0920. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/95143 * g++.dg/cpp0x/sfinae66.C: New test. --- gcc/testsuite/g++.dg/cpp0x/sfinae66.C | 32 +++ 1 file changed, 32 insertions(+) crea

Re: [PATCH] c++: Change the default dialect to C++17.

On Mon, May 18, 2020 at 10:04:07PM +0200, Jakub Jelinek wrote: > On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote: > > > --- a/libgomp/testsuite/libgomp.c++/for-27.C > > > +++ b/libgomp/testsuite/libgomp.c++/for-27.C > > > @@ -151,6 +151,12 @@ f4 (const I &x, const I &y) > > > el

Re: [PATCH] c++: Implement DR 1512, Pointer comparison vs qual convs [PR87699]

On Mon, May 18, 2020 at 03:50:55PM -0400, Jason Merrill via Gcc-patches wrote: > On 5/16/20 6:32 PM, Marek Polacek wrote: > > + const int q1 = cp_type_quals (pointee1); > > + const int q2 = cp_type_quals (pointee2); > > + const int quals = q1 | q2; > > result_type = cp_build_qualified_type (

Re: [PATCH] c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

On Mon, May 18, 2020 at 04:50:44PM -0400, Jason Merrill via Gcc-patches wrote: > On 5/13/20 12:22 PM, Marek Polacek wrote: > > DR 2289 clarified that since structured bindings have no C compatibility > > implications, they should be unique in their declarative region, see > > [basic.scope.declarati

Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.

On Tue, May 19, 2020 at 01:19:13AM +0200, Mark Wielaard wrote: > On Mon, May 18, 2020 at 05:24:58PM +0200, Mark Wielaard wrote: > > On Mon, May 18, 2020 at 11:09:18AM -0400, David Malcolm wrote: > > > Overall, I like it, but it looks like there's a problem with the > > > location of the fix-it hint

Re: [PATCH v2] c++: Change the default dialect to C++17.

On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote: > On 5/16/20 6:34 PM, Marek Polacek wrote: > > Since GCC 9, C++17 support is no longer experimental. It was too late > > to change the default C++ dialect to C++17 in GCC 10, but I think now > > it's time to pull the trigger (C++14 was

Re: [PATCH v2] c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

On Tue, May 19, 2020 at 10:39:59AM -0400, Jason Merrill wrote: > On 5/18/20 5:07 PM, Marek Polacek wrote: > > On Mon, May 18, 2020 at 04:50:44PM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 5/13/20 12:22 PM, Marek Polacek wrote: > > > > DR 2289 clarified that since structured bindings

Re: [PATCH] c++: C++20 DR 2237, disallow simple-template-id in cdtor.

Ping. On Mon, May 11, 2020 at 04:23:17PM -0400, Marek Polacek via Gcc-patches wrote: > On Sun, Apr 05, 2020 at 09:46:09PM -0400, Jason Merrill wrote: > > On 4/4/20 7:30 PM, Marek Polacek wrote: > > > This patch implements DR 2237 which says that a simple-template-id is > &

[PATCH] c++: Fix bogus -Wparentheses warning [PR95344]

Since r267272, which added location wrappers, cp_fold loses TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and that results in a bogus -Wparentheses warning. I.e., previously we had "b = 1" but now we have "VIEW_CONVERT_EXPR(b) = 1" and cp_fold_maybe_rvalue folds away the loc

<    3   4   5   6   7   8   9   10   11   >