[PATCH] c++: Implement C++23 P0849R8 - auto(x) [PR103049]

This patch implements P0849R8 which allows auto in a functional cast, the result of which is a prvalue. [expr.type.conv]/1 says that the type is determined by placeholder type deduction. We only accept 'auto', not 'decltype(auto)' -- that the type shall be auto comes from [dcl.type.auto.deduct].

[pushed] testsuite: Fix g++.dg/opt/pr102970.C

This test uses a generic lambda, only available since C++14, so don't run it in earlier modes. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: * g++.dg/opt/pr102970.C: Only run in C++14 and up. --- gcc/testsuite/g++.dg/opt/pr102970.C | 2 +- 1 file changed, 1

Re: [PATCH] attribs: Allow optional second arg for attr deprecated [PR102049]

On Mon, Nov 01, 2021 at 05:15:03PM -0600, Martin Sebor wrote: > On 10/11/21 9:17 AM, Marek Polacek via Gcc-patches wrote: > > Any thoughts? > > I'm a little unsure. Clang just uses the replacement string > as the text of the fix-it note as is, so it does nothing to > help

Re: [PATCH v2] libcpp: Implement -Wbidirectional for CVE-2021-42574 [PR103026]

On Tue, Nov 02, 2021 at 01:20:03PM -0600, Martin Sebor wrote: > On 11/2/21 11:18 AM, Marek Polacek via Gcc-patches wrote: > > On Mon, Nov 01, 2021 at 10:10:40PM +, Joseph Myers wrote: > > > On Mon, 1 Nov 2021, Marek Polacek via Gcc-patches wrote: > > > > >

Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]

On Tue, Nov 02, 2021 at 12:51:16PM -0600, Martin Sebor via Gcc-patches wrote: > On 10/4/21 4:39 PM, Eric Gallager wrote: > > On Mon, Oct 4, 2021 at 2:43 PM Martin Sebor via Gcc-patches > > wrote: > > > > > > While resolving the recent -Waddress enhancement request (PR > > > PR102103) I came

[PATCH v2] libcpp: Implement -Wbidirectional for CVE-2021-42574 [PR103026]

On Mon, Nov 01, 2021 at 10:10:40PM +, Joseph Myers wrote: > On Mon, 1 Nov 2021, Marek Polacek via Gcc-patches wrote: > > > + /* We've read a bidi char, update the current vector as necessary. */ > > + void on_char (kind k, bool ucn_p) > >

Re: [PATCH v4] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

Ping. On Mon, Oct 11, 2021 at 11:17:11AM -0400, Marek Polacek wrote: > Ping. > > On Tue, Sep 28, 2021 at 04:20:46PM -0400, Marek Polacek wrote: > > On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote: > > > On 9/20/21 18:59, Marek Polacek via Gcc-patc

[PATCH v2] c++: P2360R0: Extend init-stmt to allow alias-decl [PR102617]

On Thu, Oct 21, 2021 at 04:56:57PM -0400, Jason Merrill wrote: > On 10/21/21 16:26, Marek Polacek wrote: > > The following patch implements C++23 P2360R0. This proposal merely > > extends init-statement to contain alias-declaration. init-statement > > is used in if/for/s

[PATCH] c++: P2360R0: Extend init-stmt to allow alias-decl [PR102617]

The following patch implements C++23 P2360R0. This proposal merely extends init-statement to contain alias-declaration. init-statement is used in if/for/switch. The unsightly duplication of the new code seems to be necessary to handle for ( init-statement condition[opt] ; expression[opt] )

Re: (!HELP NEEDED) Where is the doc for the format strings in gcc (for example, %q+D, ...)

On Wed, Oct 20, 2021 at 03:49:09PM +, Qing Zhao via Gcc-patches wrote: > Hi, > > In GCC, there are many utility routines for reporting error, warning, or > information, for example: > > warning (0, "weak declaration of %q+D not supported", decl); > warning_at (stmtloc,

Re: [PATCH] attribs: Allow optional second arg for attr deprecated [PR102049]

Any thoughts? On Thu, Sep 23, 2021 at 12:16:36PM -0400, Marek Polacek via Gcc-patches wrote: > Clang implements something we don't have: > > __attribute__((deprecated("message", "replacement"))); > > which seems pretty neat so I wrote this patch to a

Re: [PATCH v4] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

Ping. On Tue, Sep 28, 2021 at 04:20:46PM -0400, Marek Polacek wrote: > On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote: > > On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote: > > > +void > > > +handle_ignored_attributes_option (vec *v) > &g

[wwwdocs] Update cxx-status with October 2021 WG21 plenary

Pushed. Jakub already added the feature test macros. commit 78f03a4a633950743a416f5b9e7f721db7892090 Author: Marek Polacek Date: Tue Oct 5 12:57:19 2021 -0400 cxx-status: Add papers from the October 2021 WG21 plenary diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx

Re: [PATCH] c++: Implement C++23 P2334R1 - #elifdef/#elifndef

On Tue, Oct 05, 2021 at 10:35:12AM +0200, Jakub Jelinek wrote: > Hi! > > This patch implements C++23 P2334R1, which is easy because Joseph has done > all the hard work for C2X already. > Unlike the C N2645 paper, the C++ P2334R1 contains one important addition > (but not in the normative text): >

[PATCH v2] c-family: Implement -Warray-compare [PR97573]

On Fri, Oct 01, 2021 at 11:15:45PM +0200, Jakub Jelinek wrote: > On Fri, Oct 01, 2021 at 04:11:08PM -0400, Marek Polacek via Gcc-patches wrote: > > + auto_diagnostic_group d; > > + if (warning_at (location, OPT_Warray_compare, > > + "compa

Re: [PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

On Fri, Oct 01, 2021 at 09:30:41AM -0400, Jason Merrill wrote: > On 9/30/21 17:56, Marek Polacek wrote: > > On Thu, Sep 30, 2021 at 03:34:24PM -0400, Jason Merrill wrote: > > > On 9/30/21 10:50, Marek Polacek wrote: > > > > This patch addresses one of my leftovers

[PATCH] c-family: Implement -Warray-compare [PR97573]

This patch addresses one of my leftovers from GCC 11. C++20 introduced [depr.array.comp]: "Equality and relational comparisons between two operands of array type are deprecated." so this patch adds -Warray-compare. Since the code in question is dubious (the comparison doesn't actually compare

Re: [PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

On Fri, Oct 01, 2021 at 09:16:53AM -0600, Martin Sebor wrote: > On 9/30/21 8:50 AM, Marek Polacek via Gcc-patches wrote: > > This patch addresses one of my leftovers from GCC 11. C++20 introduced > > [depr.array.comp]: > > "Equality and relational comparisons between

Re: [PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

On Thu, Sep 30, 2021 at 03:34:24PM -0400, Jason Merrill wrote: > On 9/30/21 10:50, Marek Polacek wrote: > > This patch addresses one of my leftovers from GCC 11. C++20 introduced > > [depr.array.comp]: > > "Equality and relational comparisons between two operands of arr

[PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

This patch addresses one of my leftovers from GCC 11. C++20 introduced [depr.array.comp]: "Equality and relational comparisons between two operands of array type are deprecated." so this patch adds -Wdeprecated-array-compare (enabled by default in C++20). Bootstrapped/regtested on

[PATCH v4] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote: > On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote: > > +void > > +handle_ignored_attributes_option (vec *v) > > +{ > > + if (v == nullptr) > > +return; > > + > > + for (auto o

[PATCH] attribs: Allow optional second arg for attr deprecated [PR102049]

Clang implements something we don't have: __attribute__((deprecated("message", "replacement"))); which seems pretty neat so I wrote this patch to add it to gcc. It doesn't allow the optional second argument in the standard [[]] form so as not to clash with possible future standard additions. I

Re: [PATCH v3] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Mon, Sep 20, 2021 at 09:08:09PM +0200, Jakub Jelinek wrote: > On Mon, Sep 20, 2021 at 02:37:03PM -0400, Marek Polacek wrote: > > > So, wouldn't be this better specified as > > > Wno-attributes= > > > Common Joined RejectNegative > > > (not sure if RejectNe

Re: [PATCH v2] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Mon, Sep 20, 2021 at 02:37:03PM -0400, Marek Polacek wrote: > > > +/* { dg-additional-options "-Wno-attributes=yoyodyne::attr_new" } */ > > > +/* { dg-additional-options "-Wno-attributes=c4::__attr__" } */ > > > > When writing __attr__, doe

Re: [PATCH] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Mon, Sep 20, 2021 at 07:38:59PM +0200, Jakub Jelinek wrote: > On Mon, Sep 20, 2021 at 01:06:58PM -0400, Marek Polacek via Gcc-patches wrote: > > Not a review, just a few nits: > > I think it would be useful to clarify that -Wno-attributes=list doesn't > actually imply -Wno-

[PATCH] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

It is desirable for -Wattributes to warn about e.g. [[deprecate]] void g(); // typo, should warn However, -Wattributes also warns about vendor-specific attributes (that's because lookup_scoped_attribute_spec -> find_attribute_namespace finds nothing), which, with -Werror, causes grief. We don't

Re: [PATCH RFA] tree: Change error_operand_p to an inline function

On Thu, Sep 02, 2021 at 10:41:52AM -0400, Jason Merrill via Gcc-patches wrote: > I've thought for a while that many of the macros in tree.h and such should > become inline functions. This one in particular was confusing Coverity; the > null check in the macro made it think that all code guarded

[PATCH] c++: Fix ICE with nullptr comparison (GCC 11) [PR101592]

On trunk, PR101592 was fixed by r12-2537, but that change shouldn't be backported to GCC 11. In the PR Jakub suggested this fix, so here it is, after the usual testing. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 11? PR c++/101592 gcc/ChangeLog: * fold-const.c

[pushed] c++: Add test for fixed PR [PR101592]

Fixed by my c++/99701 patch. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/101592 gcc/testsuite/ChangeLog: * g++.dg/warn/Wlogical-op-3.C: New test. --- gcc/testsuite/g++.dg/warn/Wlogical-op-3.C | 12 1 file changed, 12 insertions(+) create mode 100644

Re: [pushed] c++: preserve location through constexpr

On Mon, Aug 30, 2021 at 05:25:01PM -0400, Jason Merrill via Gcc-patches wrote: > While working on the patch for PR101460, I noticed that we were losing the > expression location when folding class prvalue expressions. The final patch > doesn't fold class prvalues, but this still seems a

Re: [PATCH] c++: aggregate CTAD and brace elision [PR101344]

On Mon, Aug 16, 2021 at 03:06:08PM -0400, Patrick Palka via Gcc-patches wrote: > During aggregate CTAD, collect_ctor_idx_types always recurses into a > sub-CONSTRUCTOR, regardless of whether the corresponding pair of braces > was elided in the original initializer. This causes us to reject some >

Re: [PATCH v2] c++: Reject ordered comparison of null pointers [PR99701]

Ping for the non-libstdc++ parts. On Mon, Jul 19, 2021 at 02:46:22PM -0400, Marek Polacek wrote: > On Sat, Jul 17, 2021 at 02:50:28PM -0700, Jason Merrill wrote: > > On 7/16/21 6:34 PM, Jakub Jelinek wrote: > > > On Fri, Jul 16, 2021 at 05:36:13PM -0400, Marek Polacek via Gcc-pa

[PATCH] include: Fix -Wundef warnings in ansidecl.h

This quashes -Wundef warnings in ansidecl.h when compiled in C or C++. In C, __cpp_constexpr and __cplusplus aren't defined so we evaluate them to 0; conversely, __STDC_VERSION__ is not defined in C++. This has caused grief when -Wundef is used with -Werror. I've also tested -traditional-cpp.

Re: [PATCH v2] c++: Reject ordered comparison of null pointers [PR99701]

On Sat, Jul 17, 2021 at 02:50:28PM -0700, Jason Merrill wrote: > On 7/16/21 6:34 PM, Jakub Jelinek wrote: > > On Fri, Jul 16, 2021 at 05:36:13PM -0400, Marek Polacek via Gcc-patches > > wrote: > > > When implementing DR 1512 in r11-467 I neglected to reject ordered >

[pushed] c++: Add test for DR 2126

Tested x86_64-pc-linux-gnu, applying to trunk. DR 2126 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-temp2.C: New test. --- gcc/testsuite/g++.dg/cpp0x/constexpr-temp2.C | 6 ++ 1 file changed, 6 insertions(+) create mode 100644

[PATCH] c++: Reject ordered comparison of null pointers [PR99701]

When implementing DR 1512 in r11-467 I neglected to reject ordered comparison of two null pointers, like nullptr < nullptr. This patch fixes that omission. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? DR 1512 PR c++/99701 gcc/cp/ChangeLog: *

Re: [PATCH] c++: Allow constexpr references to non-static vars [PR100976]

On Fri, Jul 16, 2021 at 12:53:05PM -0400, Jason Merrill wrote: > On 7/15/21 5:14 PM, Marek Polacek wrote: > > The combination of DR 2481 and DR 2126 should allow us to do > > > >void f() > >{ > > constexpr const int = 42; > > static_ass

[PATCH] c++: Don't hide narrowing errors in system headers

Jonathan pointed me at this issue where constexpr unsigned f() { constexpr int n = -1; return unsigned{n}; } is accepted in system headers, despite the narrowing conversion from a constant. I suspect that whereas narrowing warnings should be disabled, ill-formed narrowing of constants should

[PATCH] c++: Allow constexpr references to non-static vars [PR100976]

The combination of DR 2481 and DR 2126 should allow us to do void f() { constexpr const int = 42; static_assert(r == 42); } because [expr.const]/4.7 now says that "a temporary object of non-volatile const-qualified literal type whose lifetime is extended to that of a variable that

Re: [PATCH] c++: constexpr array reference and value-initialization [PR101371]

On Wed, Jul 14, 2021 at 12:15:48AM -0400, Jason Merrill wrote: > On 7/13/21 8:15 PM, Marek Polacek wrote: > > This PR gave me a hard time: I saw multiple issues starting with > > different revisions. But ultimately the root cause seems to be > > the following, and the att

[PATCH] c++: constexpr array reference and value-initialization [PR101371]

This PR gave me a hard time: I saw multiple issues starting with different revisions. But ultimately the root cause seems to be the following, and the attached patch fixes all issues I've found here. In cxx_eval_array_reference we create a new constexpr context for the CP_AGGREGATE_TYPE_P case,

Re: [PATCH] c++: permit deduction guides at class scope [PR79501]

On Fri, Jul 09, 2021 at 04:18:34PM -0400, Patrick Palka via Gcc-patches wrote: > > > > --- a/gcc/cp/name-lookup.c > > > > +++ b/gcc/cp/name-lookup.c > > > > @@ -7110,9 +7110,14 @@ lookup_qualified_name (tree scope, tree name, > > > > LOOK_want want, bool complain) > > > > else if (cxx_dialect

Re: [PATCH v2] c++: Fix noexcept with unevaluated operand [PR101087]

On Thu, Jul 08, 2021 at 05:34:24PM -0400, Jason Merrill wrote: > On 7/8/21 4:26 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > OK for trunk and 11, at least. I lean toward putting it on older release > branches as well, but it d

Re: [PATCH v2] c++: Fix noexcept with unevaluated operand [PR101087]

On Thu, Jul 08, 2021 at 09:35:02AM -0400, Marek Polacek wrote: > On Thu, Jul 08, 2021 at 09:30:27AM -0400, Jason Merrill wrote: > > On 7/7/21 9:40 PM, Marek Polacek wrote: > > > It sounds plausible that this assert > > > > > >int f(); >

Re: [PATCH] c++: Fix noexcept with unevaluated operand [PR101087]

On Thu, Jul 08, 2021 at 09:30:27AM -0400, Jason Merrill wrote: > On 7/7/21 9:40 PM, Marek Polacek wrote: > > It sounds plausible that this assert > > > >int f(); > >static_assert(noexcept(sizeof(f(; > > > > should pass: sizeof

Re: PING 2 [PATCH] correct handling of variable offset minus constant in -Warray-bounds (PR 100137)

On Wed, Jul 07, 2021 at 02:38:11PM -0600, Martin Sebor via Gcc-patches wrote: > On 7/7/21 1:38 AM, Richard Biener wrote: > > On Tue, Jul 6, 2021 at 5:47 PM Martin Sebor via Gcc-patches > > wrote: > > > > > > Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573349.html > > > > + if

[PATCH] c++: Fix noexcept with unevaluated operand [PR101087]

It sounds plausible that this assert int f(); static_assert(noexcept(sizeof(f(; should pass: sizeof produces a std::size_t and its operand is not evaluated, so it can't throw. noexcept should only evaluate to false for potentially evaluated operands. Therefore I think that

Re: [PATCH] c++: DR2397 - auto specifier for * and & to arrays [PR100975]

On Tue, Jun 29, 2021 at 03:50:27PM -0400, Jason Merrill wrote: > On 6/29/21 3:25 PM, Marek Polacek wrote: > > --- a/gcc/testsuite/g++.dg/cpp0x/auto3.C > > +++ b/gcc/testsuite/g++.dg/cpp0x/auto3.C > > @@ -10,7 +10,7 @@ auto x; // { dg-error "au

[PATCH] c++: DR2397 - auto specifier for * and & to arrays [PR100975]

This patch implements DR2397, which removes the restriction in [dcl.array]p4 that the array element type may not be a placeholder type. We don't need to worry about decltype(auto) here, so this allows code like int a[3]; auto (*p)[3] = auto ()[3] = a; However, note that auto (&)[2] =

[wwwdocs] Update C++ DR table

used "iconv -f UTF-8 -t ASCII//TRANSLIT" to convert all quotes to ASCII ". Validated, pushed. commit 7220e26862b78df86d77a55f514d110c93d230c6 Author: Marek Polacek Date: Fri Jun 25 20:06:43 2021 -0400 cxx-dr-status.html: Add new DRs, update status of older ones diff --git a/

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

On Thu, Jun 10, 2021 at 10:31:33PM -0400, Jason Merrill wrote: > On 6/10/21 5:19 PM, Marek Polacek wrote: > > 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

Re: [PATCH] c: Fix C cast error-recovery [PR101171]

On Thu, Jun 24, 2021 at 12:11:23PM +0200, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs during error-recovery, as build_c_cast calls > note_integer_operands on error_mark_node and that wraps it into > C_MAYBE_CONST_EXPR which is unexpected and causes ICE later on. > Seems most other

Re: [PATCH] c: Fix up c_parser_has_attribute_expression [PR101176]

On Thu, Jun 24, 2021 at 12:20:56PM +0200, Jakub Jelinek wrote: > Hi! > > This function keeps src_range member of the result uninitialized, which at > least under valgrind can show up later when those uninitialized location_t's > can make it into the IL or location_t hash tables. > > Fixed

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 remova

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

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

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 > > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1938r3.html#compiler-warnings> > > which shows that our existing warning could

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

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

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 p

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

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 i

[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

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

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

[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 > > <https://gcc.gnu.org/pipermail/gcc-patches/2019-August/527699.html>: > > > > This is a crash that points to a GC problem. Consider thi

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

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

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

<    4   5   6   7   8   9   10   11   12   13   >