Re: [wwwdocs] New C++23 papers

On Tue, Jun 22, 2021 at 02:38:46PM -0400, Jason Merrill wrote: > On 6/22/21 1:14 PM, Marek Polacek wrote: > > P1847 has always been "implemented" as the paper says. > > P2186 needs a few libstdc++ changes that Jonathan already implemented. > > I figured these removals didn't need to be called out

[wwwdocs] Document new C++ features in C++23

It's time to start adding new C++ features. Pushed. commit e373348138d8d767067c0a79b3ddc6a70cbee3a4 Author: Marek Polacek Date: Tue Jun 22 13:19:37 2021 -0400 gcc-12/changes.html: Add if consteval diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index

[wwwdocs] New C++23 papers

P1847 has always been "implemented" as the paper says. P2186 needs a few libstdc++ changes that Jonathan already implemented. Pushed. commit 7b804041d34c344a190105e78c6058e2645bf7cb Author: Marek Polacek Date: Tue Jun 22 13:10:41 2021 -0400 cxx-status: Add more C++23 proposals diff

Re: [PATCH v2] c++: Extend std::is_constant_evaluated in if warning [PR100995]

On Thu, Jun 10, 2021 at 10:27:44AM -0400, Jason Merrill wrote: > On 6/9/21 9:46 PM, Marek Polacek wrote: > > Jakub pointed me at > > > > which shows that our existing warning could be extended to handle more >

Re: [PATCH] c++: Failure to delay noexcept parsing with ptr-operator [PR100752]

On Thu, Jun 10, 2021 at 03:09:29PM -0400, Jason Merrill wrote: > On 6/8/21 8:25 PM, Marek Polacek wrote: > > We weren't passing 'flags' to the recursive call to cp_parser_declarator > > in the ptr-operator case and as an effect, delayed parsing of noexcept > > didn't work as advertised. The

[PATCH] c++: Extend std::is_constant_evaluated in if warning [PR100995]

Jakub pointed me at which shows that our existing warning could be extended to handle more cases. This patch implements that. A minor annoyance was handling macros, in libstdc++ we have reference

[PATCH] c++: Failure to delay noexcept parsing with ptr-operator [PR100752]

We weren't passing 'flags' to the recursive call to cp_parser_declarator in the ptr-operator case and as an effect, delayed parsing of noexcept didn't work as advertised. The following change passes more than just CP_PARSER_FLAGS_DELAY_NOEXCEPT but that doesn't seem to break anything. I'm not

[PATCH] c++: explicit() ignored on deduction guide [PR100065]

When we have explicit() with a value-dependent argument, we can't evaluate it at parsing time, so cp_parser_function_specifier_opt stashes the argument into the decl-specifiers and grokdeclarator then stores it into explicit_specifier_map, which is then used when substituting the function decl.

Re: [PATCH] teach compute_objsize about placement new (PR 100876)

On Wed, Jun 02, 2021 at 03:40:49PM -0600, Martin Sebor via Gcc-patches wrote: > + if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)) > +{ > + /* See if this is a call to placement new. */ > + if (!fn > + || !DECL_IS_OPERATOR_NEW_P (fn) > + ||

Re: [PATCH] c++: Add new warning options for C++ language mismatches

On Wed, May 19, 2021 at 07:35:20PM +0100, Jonathan Wakely wrote: > On 19/05/21 14:03 -0400, Marek Polacek wrote: > > On Wed, May 19, 2021 at 11:51:54AM -0600, Martin Sebor via Gcc-patches > > wrote: > > > On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote: > > > > Jakub pointed out I'd

Re: [PATCH] c++: Add new warning options for C++ language mismatches

On Wed, May 19, 2021 at 11:51:54AM -0600, Martin Sebor via Gcc-patches wrote: > On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote: > > Jakub pointed out I'd forgotten the spaces before the opening parens > > for function calls. The attached patch should fix all those, with no > > other

Re: [PATCH] c++: Add new warning options for C++ language mismatches

On Wed, May 19, 2021 at 05:59:34PM +0100, Jonathan Wakely wrote: > On 19/05/21 12:53 -0400, Marek Polacek wrote: > > On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches > > wrote: > > > Jakub pointed out I'd forgotten the spaces before the opening parens > > > for function

Re: [PATCH] c++: Add new warning options for C++ language mismatches

On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches wrote: > Jakub pointed out I'd forgotten the spaces before the opening parens > for function calls. The attached patch should fix all those, with no > other changes. > > Tested x86_64-linux. OK for trunk? Nice, this is

Re: [PATCH] libcpp: Fix up -fdirectives-only handling of // comments on last line not terminated with newline [PR100646]

On Wed, May 19, 2021 at 09:54:07AM +0200, Jakub Jelinek wrote: > Hi! > > As can be seen on the testcases, before the -fdirectives-only preprocessing > rewrite the preprocessor would assume // comments are terminated by the > end of file even when newline wasn't there, but now we error out. > The

[PATCH] c++: Relax attribute on friend declaration checking [PR100596]

It turned out that there are codebases that profusely use GNU attributes on friend declarations, so we have to dial back our checking and allow them. And for C++11 attributes let's just warn instead of giving errors. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR

Re: [PATCH v2] c++: Check attributes on friend declarations [PR99032]

On Tue, May 18, 2021 at 07:35:52PM +0200, Franz Sirl wrote: > Am 2021-05-14 um 00:08 schrieb Marek Polacek via Gcc-patches: > > On Wed, May 12, 2021 at 08:27:18PM -0400, Jason Merrill wrote: > > > On 5/12/21 8:03 PM, Marek Polacek wrote: > > > > diff --git a/g

Re: [PATCH] PING implement pre-c++20 contracts

On Fri, May 14, 2021 at 04:54:10PM -0400, Jason Merrill via Gcc-patches wrote: > Please add an overview of the implementation strategy to the top of > cxx-contracts.c. Particularly to discuss the why and how of > pre/post/guarded/unguarded functions. And I think let's please name the file

[PATCH] c++: Prune dead functions.

[ Repost from GCC 11 stage 3. Rebased onto current trunk. ] I was looking at the LCOV coverage report for the C++ FE and found a bunch of unused functions that I think we can remove. Obviously, I left alone various dump_* and debug_* routines. I haven't removed cp_build_function_call although it

Re: [PATCH v2] c++: Check attributes on friend declarations [PR99032]

On Wed, May 12, 2021 at 08:27:18PM -0400, Jason Merrill wrote: > On 5/12/21 8:03 PM, Marek Polacek wrote: > > diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c > > index 89f874a32cc..2bcefb619aa 100644 > > --- a/gcc/cp/decl2.c > > +++ b/gcc/cp/decl2.c > > @@ -1331,6 +1331,20 @@

Re: [PATCH v2] c++: Check attributes on friend declarations [PR99032]

On Wed, May 12, 2021 at 12:21:26PM -0400, Jason Merrill wrote: > On 5/12/21 11:03 AM, Marek Polacek wrote: > > On Wed, May 12, 2021 at 10:37:50AM -0400, Jason Merrill wrote: > > > On 5/11/21 10:45 PM, Marek Polacek wrote: > > > > This patch implements [dcl.attr.grammar]/5: "If an > > > >

[PATCH] c++: Disable -Wint-in-bool-context in instantiations

This warning is of questionable value when it's emitted when instantiating a template, as in the following testcase. It could be silenced by writing hb(i) << 1 instead of 2 * hb(i) but that's unnecessary obfuscation. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog:

Re: [PATCH] c++: Check attributes on friend declarations [PR99032]

On Wed, May 12, 2021 at 10:37:50AM -0400, Jason Merrill wrote: > On 5/11/21 10:45 PM, Marek Polacek wrote: > > This patch implements [dcl.attr.grammar]/5: "If an attribute-specifier-seq > > appertains to a friend declaration ([class.friend]), that declaration shall > > be a definition." > > > >

[PATCH] c++: Check attributes on friend declarations [PR99032]

This patch implements [dcl.attr.grammar]/5: "If an attribute-specifier-seq appertains to a friend declaration ([class.friend]), that declaration shall be a definition." This restriction only applies to C++11-style attributes. There are various forms of friend declarations, we have friend

Re: [PATCH] libcpp: Fix up pragma preprocessing [PR100450]

On Fri, May 07, 2021 at 09:53:29AM +0200, Jakub Jelinek wrote: > Hi! > > Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c > https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html > changes, so that we handle macros inside of pragmas that should expand > macros, during

[pushed] c++: Add testcase for already fixed PR [PR94102]

We correctly accept this testcase since r11-1571. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: PR c++/94102 * g++.dg/cpp1z/class-deduction87.C: New test. --- gcc/testsuite/g++.dg/cpp1z/class-deduction87.C | 15 +++ 1 file changed, 15

[PATCH] c++: Remove GCC12 FIXME for DR1312

This patch removes a FIXME I left for myself for GCC 12, along with adjusting the relevant test. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: DR 1312 * constexpr.c (cxx_eval_constant_expression): Don't check integer_zerop.

[PATCH] c++: Fix ICE with invalid requires-expression [PR100055]

This fixes a crash on invalid requires-expression: in this test, current_template_parms is null so accessing TEMPLATE_PARMS_CONSTRAINTS is going to fail. So don't crash, but make sure we've complained already. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog:

Re: [PATCH v2] c++: Prevent bogus -Wtype-limits warning with NTTP [PR100161]

On Tue, Apr 20, 2021 at 10:40:52PM -0400, Jason Merrill wrote: > On 4/20/21 8:42 PM, Marek Polacek wrote: > > Recently, we made sure that we never call value_dependent_expression_p > > on an expression that isn't potential_constant_expression. That caused > > this bogus warning with a non-type

Re: [PATCH] testsuite: Add -fchecking to dg-ice tests

On Wed, Apr 21, 2021 at 12:52:39PM +0200, Jakub Jelinek wrote: > Hi! > > In --enable-checking=release builds (which is the default on release > branches), I'm getting various extra FAILs that don't appear in > --enable-checking=yes builds. > > XPASS: g++.dg/cpp0x/constexpr-52830.C -std=c++14

[PATCH] c++: Prevent bogus -Wtype-limits warning with NTTP [PR100161]

Recently, we made sure that we never call value_dependent_expression_p on an expression that isn't potential_constant_expression. That caused this bogus warning with a non-type template parameter, something that users don't want to see. The problem is that in tsubst_copy_and_build/LE_EXPR 't' is

[PATCH] c++: Don't allow defining types in enum-base [PR96380]

In r11-2064 I made cp_parser_enum_specifier commit to tentative parse when seeing a '{'. That still looks like the correct thing to do, but it caused an ICE-on-invalid as well as accepts-invalid. When we have something sneaky like this, which is broken in multiple ways: template enum

[PATCH] c++: ICE with concept defined in function [PR97536]

This is an ICE-on-invalid, but I keep seeing it when reducing code so I'd like to fix it. We crash on template void forward() { concept C = true; } which breaks two requirements: [temp.concept]/1: A concept is a template ... [temp.concept]/3: A concept-definition shall inhabit a

Re: [PATCH] c++: ICE with bogus late return type [PR99803]

On Thu, Apr 15, 2021 at 03:31:24PM -0400, Jason Merrill wrote: > On 4/14/21 9:21 PM, Marek Polacek wrote: > > Here we ICE when compiling this code in C++20, because we're trying to > > slam a 'typename' after the ->. The cp_parser_template_id call just > > before the spot I'm changing parsed

[PATCH] c++: ICE with bogus late return type [PR99803]

Here we ICE when compiling this code in C++20, because we're trying to slam a 'typename' after the ->. The cp_parser_template_id call just before the spot I'm changing parsed A::template A as a BASELINK that contains a constructor, but make_typename_type crashes on that. My fix is the same as

Re: [PATCH] c: Avoid clobbering TREE_TYPE (error_mark_node) [PR99990]

On Sat, Apr 10, 2021 at 08:13:08AM +0200, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs during error recovery, because finish_decl > overwrites TREE_TYPE (error_mark_node), which better should stay always > to be error_mark_node. > > Fixed thusly, bootstrapped/regtested on

Re: [PATCH v2] c++: Fix two issues with auto function parameter [PR99806]

On Thu, Apr 08, 2021 at 04:37:00PM -0400, Patrick Palka wrote: > On Thu, 8 Apr 2021, Marek Polacek via Gcc-patches wrote: > > > When we have a member function with auto parameter like this: > > > > struct S { > > void f(auto); > > }; > > >

[PATCH] c++: Fix two issues with auto function parameter [PR99806]

When we have a member function with auto parameter like this: struct S { void f(auto); }; cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL "void S::foo(auto:1)", and then finish_fully_implicit_template turns that FUNCTION_DECL into a TEMPLATE_DECL. The bug here is that

[PATCH] c++: Fix ICE with unexpanded parameter pack [PR99844]

In explicit17.C, we weren't detecting an unexpanded parameter pack in explicit(bool), so we crashed on a TEMPLATE_PARM_INDEX in constexpr. I noticed the same is true for noexcept(), but only since my patch to implement delayed parsing of noexcept. Previously, we would detect the unexpanded pack

[pushed] c++: Add test for Core issue 1376 [PR52202]

As Jens says in the PR, we handle this correctly. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: PR c++/52202 * g++.dg/cpp0x/rv-life.C: New test. --- gcc/testsuite/g++.dg/cpp0x/rv-life.C | 12 1 file changed, 12 insertions(+) create mode

Re: [PATCH v2] c++: GC during late parsing collects live data [PR91416]

On Sat, Apr 03, 2021 at 10:47:13AM -0400, Jason Merrill wrote: > On 4/2/21 9:53 PM, Marek Polacek wrote: > > Coming back to > > : > > > > This is a crash that points to a GC problem. Consider this test: > > > >__attribute__

[PATCH] c++: GC during late parsing collects live data [PR91416]

Coming back to : This is a crash that points to a GC problem. Consider this test: __attribute__ ((unused)) struct S { S() { } } s; We're parsing a simple-declaration. While parsing the decl specs, we parse the

Re: [PATCH v2] c++: GC collects live data when synthesizing operator== [PR99831]

On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote: > On 4/1/21 2:15 PM, Marek Polacek wrote: > > Here we crash in reshape_init because we're accessing ggc_freed > > & poisoned data: since r277865 in defaulted_late_check we call > > synthesize_method here: > > > >if (kind ==

[PATCH] c++: GC collects live data when synthesizing operator== [PR99831]

Here we crash in reshape_init because we're accessing ggc_freed & poisoned data: since r277865 in defaulted_late_check we call synthesize_method here: if (kind == sfk_comparison) { /* If the function was declared constexpr, check that the definition qualifies. Otherwise we

Re: RFC: Sphinx for GCC documentation

On Thu, Apr 01, 2021 at 03:30:10PM +0200, Martin Liška wrote: > Hey. > > I've returned to the David's project and I'm willing to finish his transition > effort. > I believe using Sphinx documentation can rapidly improve readability, both > HTML and PDF version, > of various GCC manuals ([1]).

[PATCH] c++: ICE on invalid with NSDMI in C++98 [PR98352]

NSDMIs are a C++11 thing, and here we ICE with them on the non-C++11 path. Fortunately all we need is a small tweak to my recent r11-7835 patch (and a small tweak to the new test). Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/98352 *

Re: [PATCH v2] c++: -Wconversion vs value-dependent expressions [PR99331]

On Tue, Mar 23, 2021 at 04:59:53PM -0400, Jason Merrill via Gcc-patches wrote: > On 3/8/21 7:34 PM, Marek Polacek wrote: > > On Fri, Mar 05, 2021 at 05:03:45PM -0500, Jason Merrill wrote: > > > On 3/4/21 9:37 PM, Marek Polacek wrote: > > > > This PR complains that we issue a -Wconversion warning

Re: [PATCH] c++: Fix bogus warning in deprecated namespace [PR99318]

On Tue, Mar 23, 2021 at 09:05:42AM -0400, Jason Merrill via Gcc-patches wrote: > On 3/9/21 10:22 PM, Marek Polacek wrote: > > In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can > > handle attribute deprecated on a namespace declaration. This > > function walks the decl's

Re: [r11-7723 Regression] FAIL: g++.dg/torture/pr85013.C -Os (test for excess errors) on Linux/x86_64

Fixed now. On Thu, Mar 18, 2021 at 02:40:19PM -0700, sunil.k.pandey via Gcc-patches wrote: > On Linux/x86_64, > > c5e55673b486533c4d6d19ac903460f70b48f11a is the first bad commit > commit c5e55673b486533c4d6d19ac903460f70b48f11a > Author: Marek Polacek > Date: Wed Mar 17 19:39:10 2021 -0400 >

Re: [pushed] c++: Add assert to tsubst.

On Thu, Mar 18, 2021 at 02:04:59PM -0700, H.J. Lu wrote: > On Thu, Mar 18, 2021 at 11:35 AM Marek Polacek via Gcc-patches > wrote: > > > > As discussed in the r11-7709 patch, we can now make sure that tsubst > > never sees a FLOAT_EXPR, much like its counterpart FIX_TR

[pushed] c++: Add assert to tsubst.

As discussed in the r11-7709 patch, we can now make sure that tsubst never sees a FLOAT_EXPR, much like its counterpart FIX_TRUNC_EXPR. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * pt.c (tsubst_copy_and_build): Add assert. --- gcc/cp/pt.c | 2 ++ 1 file changed, 2

Re: [PATCH v2] c++: ICE with real-to-int conversion in template [PR97973]

On Wed, Mar 17, 2021 at 04:45:00PM -0400, Jason Merrill wrote: > On 3/8/21 7:52 PM, Marek Polacek wrote: > > Yeah; it's worked pretty well for classes after we've dealt with the > > initial fallout. I've factored the check into a new function, and also > > extended it with the case where we'd

Re: [PATCH] c-family: Fix up -Wduplicated-branches for union members [PR99565]

On Wed, Mar 17, 2021 at 08:28:20AM -0600, Martin Sebor wrote: > On 3/17/21 2:36 AM, Jakub Jelinek wrote: > > On Tue, Mar 16, 2021 at 06:28:46PM -0600, Martin Sebor via Gcc-patches > > wrote: > > > It seems sort of "inverted:" I'd expect OEP_LEXICOGRAPHIC on its > > > own to do a lexicographical

Re: [PATCH] c-family: Fix up -Wduplicated-branches for union members [PR99565]

On Tue, Mar 16, 2021 at 06:56:47PM +0100, Jakub Jelinek wrote: > Hi! > > Honza has fairly recently changed operand_equal_p to compare > DECL_FIELD_OFFSET for COMPONENT_REFs when comparing addresses. > As the first testcase in this patch shows, while that is very nice > for optimizations, for the

Re: [PATCH] c++: Prune dead functions.

On Mon, Mar 15, 2021 at 08:31:09AM -0400, Nathan Sidwell wrote: > On 3/11/21 3:58 PM, Marek Polacek via Gcc-patches wrote: > > I was looking at the LCOV coverage report for the C++ FE and > > found a bunch of unused functions that I think we can remove. > > Obviously, I lef

[PATCH] c++: Prune dead functions.

I was looking at the LCOV coverage report for the C++ FE and found a bunch of unused functions that I think we can remove. Obviously, I left alone various dump_* and debug_* routines. I haven't removed cp_build_function_call although it is also currently unused. * lambda_return_type: was used in

[PATCH] c++: Fix error-recovery with requires expression [PR99500]

This fixes an ICE on invalid code where one of the parameters was error_mark_node and thus resetting its DECL_CONTEXT crashed. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/99500 * parser.c (cp_parser_requirement_parameter_list): Handle

[PATCH] c++: Fix bogus warning in deprecated namespace [PR99318]

In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can handle attribute deprecated on a namespace declaration. This function walks the decl's contexts so that we warn for code like namespace [[deprecated]] N { struct S { }; } N::S s; We call cp_warn_deprecated_use_scopes when

Re: [committed] [PR99454] LRA: Process 0..9 constraints in process_address_1

On Tue, Mar 09, 2021 at 03:26:12PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Tue, Mar 09, 2021 at 09:12:36AM -0500, Vladimir Makarov via Gcc-patches > wrote: > > diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c > > index 76e3ff7efe6..feff766c590 100644 > > ---

Re: [PATCH] c++: -Wconversion vs value-dependent expressions [PR99331]

On Mon, Mar 08, 2021 at 06:10:05PM -0700, Martin Sebor wrote: > On 3/5/21 3:03 PM, Jason Merrill via Gcc-patches wrote: > > On 3/4/21 9:37 PM, Marek Polacek wrote: > > > This PR complains that we issue a -Wconversion warning in > > > > > >    template struct X {}; > > >    template X foo(); > >

Re: [PATCH v2] c++: ICE with real-to-int conversion in template [PR97973]

On Fri, Mar 05, 2021 at 05:15:49PM -0500, Jason Merrill via Gcc-patches wrote: > On 3/3/21 7:55 PM, Marek Polacek wrote: > > In this test we are building a call in a template, but since neither > > the function nor any of its arguments are dependent, we go down the > > normal path in

Re: [PATCH v2] c++: -Wconversion vs value-dependent expressions [PR99331]

On Fri, Mar 05, 2021 at 05:03:45PM -0500, Jason Merrill wrote: > On 3/4/21 9:37 PM, Marek Polacek wrote: > > This PR complains that we issue a -Wconversion warning in > > > >template struct X {}; > >template X foo(); > > > > saying "conversion from 'long unsigned int' to 'int' may

[pushed] c++: Add test for PR96268.

This works since the recent r11-7102, but we didn't have a test for a template-argument context. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: PR c++/96268 * g++.dg/cpp2a/nontype-class41.C: New test. --- gcc/testsuite/g++.dg/cpp2a/nontype-class41.C |

[PATCH] c++: ICE on invalid with inheriting constructors [PR94751]

This is an ICE on invalid where we crash because since r269032 we keep error_mark_node around instead of using noexcept_false_spec when things go wrong; see the walk_field_subobs hunk. We crash in deduce_inheriting_ctor which calls synthesized_method_walk to deduce the exception-specification,

Re: [pushed] c++: Fix class NTTP constness handling [PR98810]

On Fri, Mar 05, 2021 at 06:00:04PM +0100, Eric Botcazou wrote: > > Here, when substituting still-dependent args into an alias template, we see > > a non-const type because the default argument is non-const, and is not a > > template parm object because it's still dependent. > > > > Tested

[PATCH] c++: ICE with -Wshadow and enumerator in template [PR99120]

We crash here, because in a template, an enumerator doesn't have a type until we've called finish_enum_value_list. But our -Wshadow implementation, check_local_shadow, is called when we pushdecl in build_enumerator, which takes place before finish_enum_value_list. Bootstrapped/regtested on

[PATCH] c++: -Wconversion vs value-dependent expressions [PR99331]

This PR complains that we issue a -Wconversion warning in template struct X {}; template X foo(); saying "conversion from 'long unsigned int' to 'int' may change value". While it's not technically wrong, I suspect -Wconversion warnings aren't all that useful for value-dependent

[PATCH] c++: Pointer-to-member fn conversion with noexcept [PR99374]

The issue in this PR is that we wrongly reject converting pointers to member function of incomplete types, one of which has noexcept. Recall that pointers (including pointers to member functions) to non-throwing functions can be implicitly converted to potentially-throwing functions (but not vice

[PATCH] c++: ICE with real-to-int conversion in template [PR97973]

In this test we are building a call in a template, but since neither the function nor any of its arguments are dependent, we go down the normal path in finish_call_expr. convert_arguments sees that we're binding a reference to int to double and therein convert_to_integer creates a FIX_TRUNC_EXPR.

[pushed] c++: Add fixed test [PR96474]

Was happy to find out that my recent dguide fix (r11-7483) fixed this test too. In particular, the + /* Wait until the enclosing scope is non-dependent. */ + if (DECL_CLASS_SCOPE_P (tmpl) + && dependent_type_p (DECL_CONTEXT (tmpl))) +return ptype; bit. Tested x86_64-pc-linux-gnu,

Re: [PATCH v2] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

On Mon, Mar 01, 2021 at 09:29:19PM -0500, Jason Merrill via Gcc-patches wrote: > On 3/1/21 7:59 PM, Marek Polacek wrote: > > On Mon, Mar 01, 2021 at 03:08:58PM -0500, Jason Merrill wrote: > > > On 3/1/21 2:54 PM, Marek Polacek wrote: > > > > On Thu, Feb 25, 2021 at 10:45:29PM -0500, Jason Merrill

Re: [PATCH] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

On Mon, Mar 01, 2021 at 03:08:58PM -0500, Jason Merrill wrote: > On 3/1/21 2:54 PM, Marek Polacek wrote: > > On Thu, Feb 25, 2021 at 10:45:29PM -0500, Jason Merrill via Gcc-patches > > wrote: > > > On 2/25/21 5:41 PM, Marek Polacek wrote: > > > > On Thu, Feb 25, 2021 at 10:59:49AM -0500, Jason

Re: [PATCH] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

On Thu, Feb 25, 2021 at 10:45:29PM -0500, Jason Merrill via Gcc-patches wrote: > On 2/25/21 5:41 PM, Marek Polacek wrote: > > On Thu, Feb 25, 2021 at 10:59:49AM -0500, Jason Merrill wrote: > > > On 2/12/21 6:12 PM, Marek Polacek wrote: > > > > We represent deduction guides with FUNCTION_DECLs, but

[pushed] builtins: Fix typos in warn_for_access [PR99278]

Tested x86_64-pc-linux-gnu, applying to trunk. gcc/ChangeLog: * builtins.c (warn_for_access): Fix typos. --- gcc/builtins.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/builtins.c b/gcc/builtins.c index 42150cee0bd..d804b0e6617 100644 ---

Re: [PATCH] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

On Thu, Feb 25, 2021 at 10:59:49AM -0500, Jason Merrill wrote: > On 2/12/21 6:12 PM, Marek Polacek wrote: > > We represent deduction guides with FUNCTION_DECLs, but they are built > > without DECL_CONTEXT > > Hmm, that seems wrong: "A deduction-guide shall be declared in the > same scope as the

Re: [PATCH v2] c++: const_cast of null pointer in constant expr [PR99176]

On Wed, Feb 24, 2021 at 10:32:59PM -0500, Jason Merrill wrote: > On 2/24/21 5:34 PM, Marek Polacek wrote: > > Here we reject > > > >constexpr const int *p = nullptr; > >constexpr int *q = const_cast(p); > > > > with "conversion of 'const int*' null pointer to 'int*' is not a > > constant

Re: [PATCH] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

Ping. On Fri, Feb 12, 2021 at 06:12:12PM -0500, Marek Polacek via Gcc-patches wrote: > We represent deduction guides with FUNCTION_DECLs, but they are built > without DECL_CONTEXT, leading to an ICE in type_dependent_expression_p > on the assert that the type of a function

[PATCH] c++: const_cast of null pointer in constant expr [PR99176]

Here we reject constexpr const int *p = nullptr; constexpr int *q = const_cast(p); with "conversion of 'const int*' null pointer to 'int*' is not a constant expression", which seems bogus. This code has been rejected since r238909 which added the can_convert check when converting a null

[PATCH] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

We represent deduction guides with FUNCTION_DECLs, but they are built without DECL_CONTEXT, leading to an ICE in type_dependent_expression_p on the assert that the type of a function template with no dependent (innermost!) template arguments must be non-dependent. Consider the attached

Re: [PATCH v2] c++: Endless loop with targ deduction in member tmpl [PR95888]

On Thu, Feb 11, 2021 at 02:24:22PM -0500, Marek Polacek via Gcc-patches wrote: > On Thu, Feb 11, 2021 at 11:30:07AM -0500, Jason Merrill via Gcc-patches wrote: > > On 2/9/21 5:41 PM, Marek Polacek wrote: > > > My r10-7007 patch tweaked tsubst not to reduce the template level

Re: [PATCH v2] c++: Endless loop with targ deduction in member tmpl [PR95888]

On Thu, Feb 11, 2021 at 11:30:07AM -0500, Jason Merrill via Gcc-patches wrote: > On 2/9/21 5:41 PM, Marek Polacek wrote: > > My r10-7007 patch tweaked tsubst not to reduce the template level of > > template parameters when tf_partial. That caused infinite looping in > > is_specialization_of: we

Re: [PATCH] c++: Fix endless errors on invalid requirement seq [PR97742]

On Thu, Feb 11, 2021 at 05:30:24PM +0100, Jakub Jelinek via Gcc-patches wrote: > Hi! > > As the testcase shows, if we reach CPP_EOF during parsing of requirement > sequence, we end up with endless loop where we always report invalid > requirement expression, don't consume any token (as we are at

[PATCH] c++: ICE with unexpanded pack in do-while [PR99063]

Here an unexpanded parameter pack snuck into prep_operand which doesn't expect to see an operand without a type, and since r247842 NONTYPE_ARGUMENT_PACK doesn't have a type anymore. This only happens with the do-while loop whose condition may not contain a declaration so we never called

Re: [PATCH v2] c, c++: Plug -Wduplicated-cond memory leaks [PR99057]

On Wed, Feb 10, 2021 at 04:48:56PM -0500, Jason Merrill wrote: > On 2/10/21 12:35 PM, Marek Polacek wrote: > > Freeing the condition chain needs to use vec_free which does ->release, > > or we leak memory. > > OK, but if chain were an auto_vec, delete would work. Yes. > Can we merge auto_vec

Re: [PATCH v2] c-family: ICE with assume_aligned attribute [PR99062]

On Wed, Feb 10, 2021 at 03:54:52PM -0700, Martin Sebor via Gcc-patches wrote: > On 2/10/21 3:33 PM, Marek Polacek wrote: > > We ICE in handle_assume_aligned_attribute since r271338 which added > > > > @@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree > > name, tree args,

[PATCH] c-family: ICE with assume_aligned attribute [PR99062]

We ICE in handle_assume_aligned_attribute since r271338 which added @@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name, tree args, int, /* The misalignment specified by the second argument must be non-negative and less than the alignment. */

[PATCH] c, c++: Plug -Wduplicated-cond memory leaks [PR99057]

Freeing the condition chain needs to use vec_free which does ->release, or we leak memory. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/c/ChangeLog: * c-parser.c (c_parser_if_statement): Use vec_free. gcc/cp/ChangeLog: * parser.c

[PATCH] c++: Endless loop with targ deduction in member tmpl [PR95888]

My r10-7007 patch tweaked tsubst not to reduce the template level of template parameters when tf_partial. That caused infinite looping in is_specialization_of: we ended up with a class template specialization whose TREE_TYPE (CLASSTYPE_TI_TEMPLATE (t)) == t, so the second for loop in

[pushed] c++: Fix typo in CLASSTYPE_TI_TEMPLATE comment.

gcc/cp/ChangeLog: * cp-tree.h (CLASSTYPE_TI_TEMPLATE): Fix typo. --- gcc/cp/cp-tree.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index 970ed5e77bb..41472a895b5 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -3775,8

Re: [PATCH] c++: Private parent access check for using decls [PR19377]

On Fri, Feb 05, 2021 at 05:28:07PM +, Anthony Sharp wrote: > Hi Marek, > > > Pedantically, "Altered function." is not very good, it should say what > > in enforce_access changed. > > I would normally 100% agree, but the changes are a bit too complicated > to be concisely (and helpfully)

Re: [PATCH] c++: Private parent access check for using decls [PR19377]

Hi, a few comments: On Fri, Feb 05, 2021 at 03:39:25PM +, Anthony Sharp via Gcc-patches wrote: > 2021-02-05 Anthony Sharp > > * semantics.c (get_class_access_diagnostic_decl): New function. > (enforce_access): Altered function. Pedantically, "Altered function." is not very

[PATCH] c++: Fix ICE with invalid using enum [PR96462]

Here we ICE in finish_nonmember_using_decl -> lookup_using_decl -> ... -> find_namespace_slot because "name" is not an IDENTIFIER_NODE. It is a BIT_NOT_EXPR because this broken test uses using E::~E; // SCOPE::NAME A using-decl can't refer to a destructor, and lookup_using_decl already checks

Re: [PATCH v2] c++: Fix bogus -Wvolatile warning in C++20 [PR98947]

On Thu, Feb 04, 2021 at 03:47:54PM -0500, Jason Merrill via Gcc-patches wrote: > On 2/4/21 1:11 PM, Marek Polacek wrote: > > On Thu, Feb 04, 2021 at 10:59:21AM -0500, Jason Merrill wrote: > > > On 2/3/21 7:03 PM, Marek Polacek wrote: > > > > Since most of volatile is deprecated in C++20, we are

Re: [pushed] c++: Empty args for variadic concept [PR98717]

On Thu, Feb 04, 2021 at 03:43:33PM -0500, Jason Merrill via Gcc-patches wrote: > Nice when fixing a bug is as easy as removing incorrect checks. > > gcc/cp/ChangeLog: > > PR c++/98717 > * constraint.cc (build_concept_check_arguments): Remove assert. > (build_concept_check):

Re: [PATCH] c++: Fix bogus -Wvolatile warning in C++20 [PR98947]

On Thu, Feb 04, 2021 at 10:59:21AM -0500, Jason Merrill wrote: > On 2/3/21 7:03 PM, Marek Polacek wrote: > > Since most of volatile is deprecated in C++20, we are required to warn > > for compound assignments to volatile variables and so on. But here we > > have > > > >volatile int x, y, z;

[PATCH] c++: Fix bogus -Wvolatile warning in C++20 [PR98947]

Since most of volatile is deprecated in C++20, we are required to warn for compound assignments to volatile variables and so on. But here we have volatile int x, y, z; (b ? x : y) = 1; and we shouldn't warn, because simple assignments like x = 24; should not provoke the warning when they

[PATCH] c++: Mark member functions as const [PR98951]

These member functions look like they could be marked const, since they don't modify any (non-mutable) class members. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/98951 * call.c (struct z_candidate): Mark rewritten and reversed as const. (struct

Re: [PATCH] doc: mention -mprefer-vector-width in target attrs

On Wed, Feb 03, 2021 at 04:15:24PM +0100, Martin Liška wrote: > The patch documents -mprefer-vector-width which is a valid target > attribute/pragma. > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index 8daa1c67974..a14875cec37 100644 > --- a/gcc/doc/extend.texi > +++

[PATCH] c++: ICE with late parsing of noexcept in nested class [PR98899]

Here we crash with a noexcept-specifier in a nested template class, because my handling of such deferred-parse noexcept-specifiers was gronked when we need to instantiate a DEFERRED_PARSE before it was actually parsed at the end of the outermost class. In struct S { template struct B {

Re: [PATCH v2] c++: Improve sorry for __builtin_has_attribute [PR98355]

; > On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches > > > > wrote: > > > > > On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via > > > > > Gcc-patches wrote: > > > > > > __builtin_has_attribute d

Re: [PATCH v2] c++: Improve sorry for __builtin_has_attribute [PR98355]

On Fri, Jan 29, 2021 at 06:18:35PM -0500, Jason Merrill via Gcc-patches wrote: > On 1/29/21 5:52 PM, Marek Polacek wrote: > > On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches > > wrote: > > > On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek

<    2   3   4   5   6   7   8   9   10   11   >