[PATCH] c++: wrong error with static constexpr var in tmpl [PR109876]

Since r8-509, we'll no longer create a static temporary var for the initializer '{ 1, 2 }' for num in the attached test because the code in finish_compound_literal is now guarded by '&& fcl_context == fcl_c99' but it's fcl_functional here. This causes us to reject num as non-constant when evaluati

[PATCH] doc: Clarification for -Wmissing-field-initializers

The manual is incorrect in saying that the option does not warn about designated initializers, which it does in C++. Whether the divergence in behavior is desirable is another thing, but let's at least make the manual match the reality. PR c/39589 PR c++/96868 gcc/ChangeLog:

[wwwdocs] cxx-dr-status: Update from C++ Core Language Issue TOC, Revision 111

A biiig update with 100 new DRs. Also updated to reflect that DR 976 has been implemented. W3C validated. Pushed. commit d558d0a4f3407696d3f2ed868926a09a289e032e Author: Marek Polacek Date: Mon Jun 12 20:06:34 2023 -0400 cxx-dr-status: Update from C++ Core Language Issue TOC, Revision 1

Re: [PATCH v3] configure: Implement --enable-host-pie

On Mon, Jun 05, 2023 at 09:06:43PM -0600, Jeff Law wrote: > > > On 6/5/23 10:18, Marek Polacek via Gcc-patches wrote: > > Ping. Anyone have any further comments? > Given this was approved before, but got reverted due to issues (which have > since been addressed) -- I think

Re: [pushed] c++: C++26 constexpr cast from void* [PR110344]

On Tue, Jun 27, 2023 at 11:29:34PM -0400, Jason Merrill via Gcc-patches wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > P2768 allows static_cast from void* to ob* in constant evaluation if the > pointer does in fact point to an object of the appropriate type. > cxx_fold_i

[PATCH v2] c++: wrong error with static constexpr var in tmpl [PR109876]

On Fri, May 26, 2023 at 09:47:10PM -0400, Jason Merrill wrote: > On 5/26/23 19:18, Marek Polacek wrote: > > Since r8-509, we'll no longer create a static temporary var for > > the initializer '{ 1, 2 }' for num in the attached test because > > the code in finish_compound_literal is now guarded by >

[pushed] c++: Add tests for P2621, no UB in lexer [PR110340]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- C++26 P2621 removes UB in the lexer and either makes the construct valid or ill-formed. We're already handling this correctly so this patch only adds tests. PR c++/110340 gcc/testsuite/ChangeLog: * g++.dg/cpp/string-4.C:

[PATCH] c++: fix ICE with is_really_empty_class [PR110106]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk and branches? -- >8 -- is_really_empty_class is liable to crash when it gets an incomplete or dependent type. Since r11-557, we pass the yet-uninstantiated class type S<0> of the PARM_DECL s to is_really_empty_class -- because of the po

[PATCH] c++: fix ICE with designated initializer [PR110114]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- r13-1227 added an assert checking that the index in a CONSTRUCTOR is a FIELD_DECL. That's a reasonable assumption but in this case we never called reshape_init due to the type being incomplete, and so the index remained an ide

Re: [PATCH] c++: fix ICE with designated initializer [PR110114]

On Wed, Jul 19, 2023 at 02:32:15PM -0400, Patrick Palka wrote: > On Wed, 19 Jul 2023, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > LGTM. It might be preferable to check COMPLETE_TYPE_P in the caller > instead, so that we avoid inspecting CLASSTYPE_N

[PATCH] c++: -Wmissing-field-initializers and empty class [PR110064]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Let's suppress -Wmissing-field-initializers for empty classes. Here I don't think I need the usual COMPLETE_TYPE_P/dependent_type_p checks. PR c++/110064 gcc/cp/ChangeLog: * typeck2.cc (process_init_construc

Re: [PATCH] testsuite: fix allocator-opt1.C FAIL with old ABI

Ping. On Mon, Jul 10, 2023 at 04:33:26PM -0400, Marek Polacek via Gcc-patches wrote: > Running > $ make check-g++ > RUNTESTFLAGS='--target_board=unix\{-D_GLIBCXX_USE_CXX11_ABI=0,\} > dg.exp=allocator-opt1.C' > yields: > > FAIL: g++.dg/tree-ssa/allocator-opt1.C -

Re: [PATCH] c++: -Wmissing-field-initializers and empty class [PR110064]

On Wed, Jul 19, 2023 at 03:36:49PM -0400, Jason Merrill wrote: > On 7/19/23 15:20, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > OK. We might also improve the diagnostic for base classes, perhaps by > teaching dump_simple_decl about DECL_FIELD_IS_BASE?

[PATCH] c++: Improve printing of base classes [PR110745]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This patch changes warning: missing initializer for member 'D::' [-Wmissing-field-initializers] to warning: missing initializer for member 'D::B' [-Wmissing-field-initializers] PR c++/110745 gcc/cp/ChangeLog:

[PATCH v2] c++: fix ICE with designated initializer [PR110114]

On Wed, Jul 19, 2023 at 03:24:10PM -0400, Jason Merrill wrote: > On 7/19/23 14:38, Marek Polacek wrote: > > On Wed, Jul 19, 2023 at 02:32:15PM -0400, Patrick Palka wrote: > > > On Wed, 19 Jul 2023, Marek Polacek wrote: > > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > >

Re: [PATCH] testsuite: fix allocator-opt1.C FAIL with old ABI

On Wed, Jul 19, 2023 at 03:22:10PM -0400, Marek Polacek wrote: > Ping. > > On Mon, Jul 10, 2023 at 04:33:26PM -0400, Marek Polacek via Gcc-patches wrote: > > Running > > $ make check-g++ > > RUNTESTFLAGS='--target_board=unix\{-D_GLIBCXX_USE_CXX11_ABI=0,\} > &g

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote: > On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk and branches? > > Looks reasonable to me. Thanks. > Though I wonder if we could

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote: > On 7/20/23 14:13, Marek Polacek wrote: > > On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote: > > > On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote: > > > > > > > Bootst

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Thu, Jul 20, 2023 at 03:51:32PM -0400, Marek Polacek wrote: > On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote: > > On 7/20/23 14:13, Marek Polacek wrote: > > > On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote: > > > > On Tue, 18 Jul 2023,

[PATCH] c++: fix ICE with constexpr ARRAY_REF [PR110382]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- This code in cxx_eval_array_reference has been hard to get right. In r12-2304 I added some code; in r13-5693 I removed some of it. Here the problematic line is "S s = arr[0];" which causes a crash on the assert in verify_ct

[PATCH v2] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: > On 7/21/23 18:38, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > -- >8 -- > > > > This code in cxx_eval_array_reference has been hard to get right. > > In r12-2304 I added some code;

[PATCH v3] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On Tue, Jul 25, 2023 at 11:15:07AM -0400, Jason Merrill wrote: > On 7/24/23 18:37, Marek Polacek wrote: > > On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: > > > On 7/21/23 18:38, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > >

[PATCH] c++: clear tf_partial et al in instantiate_template [PR108960]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In we concluded that we might clear all flags except tf_warning_or_error when performing instantiate_template. PR c++/108960 gcc/cp/ChangeLog:

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

/23 14:13, Marek Polacek wrote: > > > > > On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote: > > > > > > On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote: > > > > > > > > > > > > > Bootstrapped/regtested on x86_64-p

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Tue, Jul 25, 2023 at 04:24:39PM -0400, Jason Merrill wrote: > On 7/25/23 15:59, Marek Polacek wrote: > > Something like this, then? I see that cp_parser_initializer_clause et al > > offer further opportunities (because they sometimes use a dummy too) but > > this should be a good start. > > Lo

[PATCH] c++: parser cleanup, remove dummy arguments

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Now that cp_parser_constant_expression accepts a null non_constant_p, we can transitively remove dummy arguments in the call chain. Running dg.exp and counting the # of is_rvalue_constant_expression calls from cp_parser_consta

Re: [PATCH] c-family: Add names to diagnostics for known headers

On Thu, Jun 30, 2022 at 04:11:42PM +0100, Jonathan Wakely via Gcc-patches wrote: > I recently changed to no longer include an unnecessary header, > which meant it no longer includes , which means it no longer > includes . This resulted in some build failures: > https://issues.apache.org/jira/brows

Re: [PATCH] c-family: Add names to diagnostics for known headers

On Mon, Jul 04, 2022 at 05:25:42PM +0100, Jonathan Wakely wrote: > On Thu, 30 Jun 2022 at 16:15, Marek Polacek wrote: > > > > On Thu, Jun 30, 2022 at 04:11:42PM +0100, Jonathan Wakely via Gcc-patches > > wrote: > > > I recently changed to no longer include an unnecessary header, > > > which meant

[PATCH] c-family: Prevent -Wformat warnings with u8 strings [PR105626]

The thread seems to have concluded that -Wformat shouldn't warn about printf((const char*) u8"test %d\n", 1); saying "format string is not an array of type 'char'". This code is not an aliasing violation, and there are no I/O functions f

Re: [PATCH] c++: Define built-in for std::tuple_element [PR100157]

On Thu, Jul 07, 2022 at 06:14:36PM +0100, Jonathan Wakely wrote: > This adds a new built-in to replace the recursive class template > instantiations done by traits such as std::tuple_element and > std::variant_alternative. The purpose is to select the Nth type from a > list of types, e.g. __builtin

[PATCH] c++: Add __reference_con{struc, ver}ts_from_temporary [PR104477]

This patch implements C++23 P2255R2, which adds two new type traits to detect reference binding to a temporary. They can be used to detect code like std::tuple t("meow"); which is incorrect because it always creates a dangling reference, because the std::string temporary is created inside the

[PATCH v2] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

On Mon, Jul 11, 2022 at 11:19:19AM +0100, Jonathan Wakely wrote: > On Fri, 8 Jul 2022 at 18:41, Marek Polacek wrote: > > The patch also adds the relevant class and variable templates to > > . > > > + template > +struct reference_constructs_from_temp > orary > +: public __bool_constant<_

[pushed] libcpp: Avoid pessimizing std::move [PR106272]

std::move in a return statement can prevent the NRVO: PR106272 reports that we have two such cases in class label_text's member functions. We have -Wpessimizing-move that's supposed to detect problematic std::m

[PATCH v3] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

On Tue, Jul 12, 2022 at 04:10:08PM -0400, Jason Merrill wrote: > On 7/8/22 13:41, Marek Polacek wrote: > > +bool > > +reference_from_temporary (tree to, tree from, bool direct_init_p) > > +{ > > + /* Check is_reference. */ > > + if (!TYPE_REF_P (to)) > > +return false; > > + /* Check is_con

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

On Tue, Jul 12, 2022 at 04:15:00PM -0400, Jason Merrill wrote: > On 7/12/22 16:10, Jason Merrill wrote: > > On 7/8/22 13:41, Marek Polacek wrote: > > > This patch implements C++23 P2255R2, which adds two new type traits to > > > detect reference binding to a temporary.  They can be used to detect c

[PATCH] c++: ICE with erroneous template redeclaration [PR106311]

Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens to be error_mark_node in this ill-formed test. I kept running into this while reducing code, so it'd be good to have it fixed. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/106311 gcc/cp/Change

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

On Thu, Jul 14, 2022 at 11:48:51PM -0400, Jason Merrill wrote: > On 7/14/22 13:43, Marek Polacek wrote: > > On Tue, Jul 12, 2022 at 04:15:00PM -0400, Jason Merrill wrote: > > > On 7/12/22 16:10, Jason Merrill wrote: > > > > On 7/8/22 13:41, Marek Polacek wrote: > > > > > This patch implements C++23

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

On Fri, Jul 15, 2022 at 10:59:41PM +0300, Ville Voutilainen wrote: > Well, is_xible is not is_xible_p because it doesn't need to be both is_* > and *_p. But xes_from_temporary is less obviously a question, so > xes_from_temporary_p would imho be a better name. Yeah, I guess so. But I've already p

Re: [PATCH] c++: Enable __has_builtin for new reference binding built-ins

On Tue, Jul 19, 2022 at 02:11:02PM +0100, Jonathan Wakely wrote: > Tested x86_64-linux, OK for trunk? > > -- >8 -- > > The new built-ins need to be detectable using __has_builtin, and the > library should use that to check for them. > > This fixes an error with Clang when C++23 is enabled. LGTM

Re: [pushed] match.pd: Add new abs pattern [PR94920]

On Thu, Jul 21, 2022 at 05:28:34PM -0400, Sam Feifer via Gcc-patches wrote: > This patch is intended to fix a missed optimization in match.pd. It optimizes > (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) to just abs(x). Additionally, the > pattern (x <= 0 ? -x : 0) now gets optimized to max(-x, 0), which

Re: [PATCH] c++: ICE with erroneous template redeclaration [PR106311]

Ping. On Fri, Jul 15, 2022 at 11:29:20AM -0400, Marek Polacek via Gcc-patches wrote: > Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens > to be error_mark_node in this ill-formed test. I kept running into this > while reducing code, so it'd be good to

[v2 PATCH] c++: ICE with erroneous template redeclaration [PR106311]

On Fri, Jul 22, 2022 at 05:21:58PM -0400, Jason Merrill wrote: > On 7/15/22 11:29, Marek Polacek wrote: > > Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens > > to be error_mark_node in this ill-formed test. I kept running into this > > while reducing code, so it'd be good t

[PATCH] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r conversion by creating a NOP_EXPR. For e.g. const int i = i; that means that the DECL_INITIAL is '(int) i' and not 'i' anymore. Consequently, we don't suppress_warning here: 711 case DECL_EXPR: 715 if (VAR_P (DECL_EXPR

Re: [PATCH] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

On Tue, Jul 26, 2022 at 04:24:18PM -0400, Jason Merrill wrote: > On 7/26/22 15:03, Marek Polacek wrote: > > Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r > > conversion by creating a NOP_EXPR. For e.g. > > > >const int i = i; > > > > that means that the DECL_INITIAL is '(i

Re: [PATCH] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

On Wed, Jul 27, 2022 at 06:41:09AM +, Richard Biener via Gcc-patches wrote: > On Tue, 26 Jul 2022, Marek Polacek wrote: > > > Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r > > conversion by creating a NOP_EXPR. For e.g. > > > > const int i = i; > > > > that means that t

[PATCH] c++: Extend -Wpessimizing-move for class prvalues [PR106276]

We already have a warning that warns about pessimizing std::move in a return statement, when it prevents the NRVO: T fn() { T t; return std::move (t); // warning \o/ } However, the warning doesn't warn when what we are returning is a class prvalue, that is, when std::move prevents t

Re: How to check -std=c89 or -std=gnu89 is set in C FE?

On Tue, Aug 02, 2022 at 04:19:56PM +, Qing Zhao via Gcc-patches wrote: > Hi, Joseph, > > When -std=c89 or -std=gnu89 present in the command line, in C FE, which flags > should be > checked to decide it’s -std=c89 or -std=gnu89? You should be able to check flag_iso and related. Marek

[PATCH] c++: Extend -Wpessimizing-move to other contexts

In my recent patch which enhanced -Wpessimizing-move so that it warns about class prvalues too I said that I'd like to extend it so that it warns in more contexts where a std::move can prevent copy elision, such as: T t = std::move(T()); T t(std::move(T())); T t{std::move(T())}; T t = {std

[PATCH] c++: Tweak for -Wpessimizing-move in templates [PR89780]

In my previous patches I've been extending our std::move warnings, but this tweak actually dials it down a little bit. As reported in bug 89780, it's questionable to warn about expressions in templates that were type-dependent, but aren't anymore because we're instantiating the template. As in,

[PATCH] c++: Extend -Wredundant-move for const-qual objects [PR90428]

In this PR, Jon suggested extending the -Wredundant-move warning to warn when the user is moving a const object as in: struct T { }; T f(const T& t) { return std::move(t); } where the std::move is redundant, because T does not have a T(const T&&) constructor (which is very unlikely).

[PATCH v2] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

On Sat, Aug 06, 2022 at 03:29:05PM -0700, Jason Merrill wrote: > On 7/26/22 14:31, Marek Polacek wrote: > > On Tue, Jul 26, 2022 at 04:24:18PM -0400, Jason Merrill wrote: > > > On 7/26/22 15:03, Marek Polacek wrote: > > > > Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r > > > > co

[PATCH v2] c++: Extend -Wpessimizing-move for class prvalues [PR106276]

On Sat, Aug 06, 2022 at 04:07:54PM -0700, Jason Merrill wrote: > On 8/6/22 15:49, Jason Merrill wrote: > > On 7/27/22 17:14, Marek Polacek wrote: > > > We already have a warning that warns about pessimizing std::move > > > in a return statement, when it prevents the NRVO: > > > > > >    T fn() > >

[PATCH v2] c++: Tweak for -Wpessimizing-move in templates [PR89780]

On Sat, Aug 06, 2022 at 04:02:13PM -0700, Jason Merrill wrote: > On 8/4/22 11:46, Marek Polacek wrote: > > In my previous patches I've been extending our std::move warnings, > > but this tweak actually dials it down a little bit. As reported in > > bug 89780, it's questionable to warn about expres

[PATCH v2] c++: Extend -Wredundant-move for const-qual objects [PR90428]

On Sat, Aug 06, 2022 at 03:58:13PM -0800, Jason Merrill wrote: > On 8/6/22 11:13, Marek Polacek wrote: > > In this PR, Jon suggested extending the -Wredundant-move warning > > to warn when the user is moving a const object as in: > > > >struct T { }; > > > >T f(const T& t) > >{ > >

Re: [PATCH v2] c++: Extend -Wredundant-move for const-qual objects [PR90428]

On Mon, Aug 08, 2022 at 04:27:10PM -0400, Marek Polacek wrote: > + /* Also try to warn about redundant std::move in code such as > + T f (const T& t) > + { > + return std::move(t); > + } > +for which EXPR will be something like > + *std::move ((const struct T &) (const

[PATCH] c++: Implement -Wself-move warning [PR81159]

About 5 years ago we got a request to implement -Wself-move, which warns about useless moves like this: int x; x = std::move (x); This patch implements that warning. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/81159 gcc/c-family/ChangeLog: * c.opt (

Re: [PATCH v2] analyzer: stash values for CPython plugin [PR107646]

On Wed, Aug 02, 2023 at 12:59:28PM -0400, David Malcolm wrote: > On Wed, 2023-08-02 at 12:20 -0400, Eric Feng wrote: > > Hi Eric, thanks for the updated patch. > > Overall, looks good to me, although I'd drop the "Exited." from the > "sorry" message (and thus from the dg-message directive), since

Re: [committed] i386: Fix grammar typo in diagnostic

On Mon, Aug 07, 2023 at 10:12:35PM +0100, Jonathan Wakely via Gcc-patches wrote: > Committed as obvious. > > Less obvious (to me) is whether it's correct to say "GCC V13" here. I > don't think we refer to a version that way anywhere else, do we? > > Would "since GCC 13.1.0" be better? x86_field_

Re: [PATCH v3] configure: Implement --enable-host-pie

On Fri, Jun 16, 2023 at 12:26:23PM +0200, Martin Jambor wrote: > Hello, > > On Thu, Jun 15 2023, Marek Polacek via Gcc-patches wrote: > > On Mon, Jun 05, 2023 at 09:06:43PM -0600, Jeff Law wrote: > >> > >> > >> On 6/5/23 10:18, Marek Polacek via Gcc-pa

[wwwdocs] cxx-status: Add C++26 papers (Spring 2023, Varna)

First C++26 papers started to trickle in. Update our docs accordingly. We don't have -std=c++2c/-std=c++26/-std=gnu++2c/-std=gnu++26 yet, but I should have a patch for it by the end of this week. W3C validated. Pushed. commit 9c66e33761140358d350c5fb2d1638f6afdaead4 Author: Marek Polacek Date

Re: PING: Re: [PATCH] c++: provide #include hint for missing includes [PR110164]

On Wed, Jun 21, 2023 at 04:44:00PM -0400, David Malcolm via Gcc-patches wrote: > I'd like to ping this C++ FE patch for review: > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621779.html Not an approval, but LGTM, though some nits below: > On Wed, 2023-06-14 at 20:28 -0400, David Malc

[PATCH] c++: Add support for -std={c,gnu}++2{c,6}

It seems prudent to add C++26 now that the first C++26 papers have been approved. I followed commit r11-6920 as well as r8-3237. I was puzzled to see that -std=c++23 was marked Undocumented but -std=c++2b wasn't. I think it should be the other way round, like the earlier modes. As for __cpluspl

[PATCH v2] c++: Add support for -std={c,gnu}++2{c,6}

On Fri, Jun 23, 2023 at 10:58:54AM -0400, Jason Merrill wrote: > On 6/22/23 20:25, Marek Polacek wrote: > > It seems prudent to add C++26 now that the first C++26 papers have been > > approved. I followed commit r11-6920 as well as r8-3237. > > > > I was puzzled to see that -std=c++23 was marked

[PATCH] c++: fix error reporting routines re-entered ICE [PR110175]

Here we get the "error reporting routines re-entered" ICE because of an unguarded use of warning_at. While at it, I added a check for a warning_at just above it. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/110175 gcc/cp/ChangeLog: * typeck.cc (cp_build_u

Re: [PATCH] configure: Implement --enable-host-bind-now

On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote: > Hello, > > On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote: > > As promised in the --enable-host-pie patch, this patch adds another > > configure option, --enable-host-bind-now, which adds -z now

Re: [PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/13? > > -- >8 -- > > cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding > a CONSTRUCTOR initializer, which for

Re: [PATCH] configure: Implement --enable-host-bind-now

On Thu, Jun 29, 2023 at 05:58:22PM +0200, Martin Jambor wrote: > Hi, > > On Tue, Jun 27 2023, Marek Polacek wrote: > > On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote: > >> Hello, > >> > >> On Tue, May 16 2023, Marek Polacek via Gcc-patches

[PATCH] testsuite: Use -fno-report-bug in gcc.dg/plugin/

Certain downstream compilers (for example, in Fedora) default to -freport-bug. The extra output breaks the following tests. We can use -fno-report-bug to fix that. Patch verified with: $ make check RUNTESTFLAGS='--target_board=unix\{,-freport-bug\} plugin.exp' Tested x86_64-pc-linux-gnu, ok fo

[PATCH] i386: add -fno-stack-protector to two tests

These tests fail when the testsuite is executed with -fstack-protector-strong. To avoid this, this patch adds -fno-stack-protector to dg-options. Tested on x86_64-pc-linux-gnu, ok for trunk? gcc/testsuite/ChangeLog: * gcc.target/i386/pr104610.c: Use -fno-stack-protector. * gcc.ta

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > prote

[PATCH] testsuite: fix dwarf2/utf-1.C with DWARF4

Running $ make check-c++ RUNTESTFLAGS='--target_board=unix\{-gdwarf-5,-gdwarf-4\} dwarf2.exp=utf-1.C' shows FAIL: g++.dg/debug/dwarf2/utf-1.C -std=gnu++20 scan-assembler-times DW_AT_encoding \\(0x10\\) 3 because with -gdwarf-4 the output is: .byte 0x10# DW_AT_encoding but with -gdwarf

[PATCH] testsuite: fix allocator-opt1.C FAIL with old ABI

Running $ make check-g++ RUNTESTFLAGS='--target_board=unix\{-D_GLIBCXX_USE_CXX11_ABI=0,\} dg.exp=allocator-opt1.C' yields: FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++98 scan-tree-dump-times gimple "struct allocator D" 1 FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++14 scan-tree-dump-ti

[PATCH] c++: fix ICE in joust_maybe_elide_copy [PR106675]

joust_maybe_elide_copy checks that the last conversion in the ICS for the first argument is ck_ref_bind, which is reasonable, because we've checked that we're dealing with a copy/move constructor. But it can also happen that we couldn't figure out which conversion function is better to convert the

[PATCH] warn-access: wrong -Wdangling-pointer with labels [PR106080]

-Wdangling-pointer warns when the address of a label escapes. This causes grief in OCaml () as well as in the kernel: because it uses #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)

[PATCH v2] warn-access: wrong -Wdangling-pointer with labels [PR106080]

On Wed, Feb 15, 2023 at 10:50:08AM +0100, Jakub Jelinek wrote: > On Tue, Feb 14, 2023 at 10:48:15PM -0500, Marek Polacek via Gcc-patches wrote: > > -Wdangling-pointer warns when the address of a label escapes. This > > causes grief in OCaml (<https://github.com/ocaml/ocaml

Re: [PATCH] c++: ICE with -fno-elide-constructors and trivial fn [PR101073]

On Wed, Feb 15, 2023 at 02:39:16PM -0500, Jason Merrill wrote: > On 2/9/23 09:39, Marek Polacek wrote: > > In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide > > the Y::Y(const Y&) call used to initialize o.c. So store_init_value > > -> cxx_constant_init must constexpr-evaluate th

[PATCH] c++: ICE with redundant capture [PR108829]

Here we crash in is_capture_proxy: /* Location wrappers should be stripped or otherwise handled by the caller before using this predicate. */ gcc_checking_assert (!location_wrapper_p (decl)); so fixed as the comment suggests. We only crash with the redundant capture: int abyPage = [

[PATCH v2] c++: ICE with redundant capture [PR108829]

On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote: > On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote: > > > Here we crash in is_capture_proxy: > > > > /* Location wrappers should be stripped or otherwise handled by the > > call

[PATCH v3] c++: ICE with redundant capture [PR108829]

On Fri, Feb 17, 2023 at 04:32:50PM -0500, Patrick Palka wrote: > On Fri, 17 Feb 2023, Patrick Palka wrote: > > > On Fri, 17 Feb 2023, Marek Polacek wrote: > > > > > On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote: > > > > On Fri, 17 Feb 20

Re: [PATCH RFC] c++: static_assert (false) in template [DR2518]

On Fri, Feb 17, 2023 at 03:32:09PM -0500, Jason Merrill via Gcc-patches wrote: > Tested x86_64-pc-linux-gnu. This isn't really a regression fix, but it's very > safe, and fixes a longstanding annoyance, so I'm leaning toward putting it > into > GCC 13. Thoughts? LGTM. > -- 8< -- > > For a lo

[PATCH] c-family: avoid compile-time-hog in c_genericize [PR108880]

This fixes a compile-time hog with UBSan. This only happened in cc1 but not cc1plus. The problem is ultimately that c_genericize_control_stmt/ STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited nodes, so it kept on recursing for a long time. We should be able to use the pse

[PATCH] c++: variable template and targ deduction [PR108550]

In this test, we get a bogus error because we failed to deduce the auto in constexpr auto is_pointer_v = is_pointer::value; to bool. Then ensure_literal_type_for_constexpr_object thinks the object isn't literal and an error is reported. This is another case of the interaction between tf_partial a

Re: [PATCH] c++: Fix up -fcontracts option description [PR108890]

On Thu, Feb 23, 2023 at 11:26:27AM +0100, Jakub Jelinek via Gcc-patches wrote: > Hi! > > This translation PR mentioned the description is a little bit weird. > > Ok for trunk? I think this is OK... > 2023-02-23 Jakub Jelinek > > PR translation/108890 > * c.opt (fcontracts): Fix

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On Thu, Feb 23, 2023 at 10:17:22AM -0500, Patrick Palka wrote: > On Wed, 22 Feb 2023, Marek Polacek wrote: > > > In this test, we get a bogus error because we failed to deduce the auto in > > constexpr auto is_pointer_v = is_pointer::value; > > to bool. Then ensure_literal_type_for_constexpr_obje

[PATCH] c++: ICE with constexpr variable template [PR107938]

Since r11-557, cp_finish_decl can call check_initializer even in a template for a constexpr initializer. That ultimately leads to convert_for_assignment and check_address_or_pointer_of_packed_member, where we crash, because it doesn't expect that the CALL_EXPR is a function object. Q has a conste

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On Mon, Feb 27, 2023 at 06:21:13PM -0500, Jason Merrill wrote: > On 2/23/23 10:54, Marek Polacek wrote: > > On Thu, Feb 23, 2023 at 10:17:22AM -0500, Patrick Palka wrote: > > > On Wed, 22 Feb 2023, Marek Polacek wrote: > > > > > > > In this test, we get a bogus error because we failed to deduce th

[PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

-Wmismatched-tags warns about the (harmless) struct/class mismatch. For, e.g., template struct A { }; class A a; it works by adding A to the class2loc hash table while parsing the class-head and then, while parsing the elaborate type-specifier, we add A. At the end of c_parse_file we go thro

Re: [PATCH v4] c++: -Wdangling-reference with reference wrapper [PR107532]

Ping. On Tue, Feb 07, 2023 at 11:46:10AM -0500, Marek Polacek wrote: > On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote: > > On 1/24/23 17:49, Marek Polacek wrote: > > > On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote: > > > > On 1/19/23 21:03, Marek Polacek wrote: > > >

Re: [PATCH] c++: can't eval PTRMEM_CST in incomplete class [PR107574]

Ping. On Thu, Feb 02, 2023 at 07:28:25PM -0500, Marek Polacek via Gcc-patches wrote: > Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't > been completed yet, but that doesn't work: > > /* We can't lower this until the cla

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote: > On 3/1/23 15:33, Marek Polacek wrote: > > -Wmismatched-tags warns about the (harmless) struct/class mismatch. > > For, e.g., > > > >template struct A { }; > >class A a; > > > > it works by adding A to the class2loc hash tabl

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

On Wed, Mar 01, 2023 at 04:44:12PM -0500, Jason Merrill wrote: > On 3/1/23 16:40, Marek Polacek wrote: > > On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote: > > > On 3/1/23 15:33, Marek Polacek wrote: > > > > -Wmismatched-tags warns about the (harmless) struct/class mismatch. > > > > F

Re: [PATCH] wwwdocs: Document several further C++23 changes

On Thu, Mar 02, 2023 at 12:46:42PM +0100, Jakub Jelinek wrote: > Hi! > > Tobias mentioned on IRC that assume attribute wasn't mentioned in > changes.html. The P1774R8 entry was missing for C++, so I went through > projects/cxx-status.html#cxx23 and filled in all the missing papers > which have be

Re: [PATCH v4] c++: -Wdangling-reference with reference wrapper [PR107532]

On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote: > > @@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t) > >const int& y = (f(1), 42); // NULL_TREE > >const int& z = f(f(1)); // f(f(1)) > > - EXPR is the initializer. */ > > + EXPR is the initializer. If ARG_P i

[PATCH v5] c++: -Wdangling-reference with reference wrapper [PR107532]

On Fri, Mar 03, 2023 at 11:25:06AM -0500, Jason Merrill wrote: > On 3/2/23 16:24, Marek Polacek wrote: > > On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote: > > > > @@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t) > > > > const int& y = (f(1), 42); // NULL_TREE > > > >

[PATCH] c++: error with constexpr operator() [PR107939]

Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl can call check_initializer even in a template for a constexpr initializer. Here we are rejecting extern const Q q; template constexpr auto p = q(0); even though q has a constexpr operator(). It's deemed non-con

[PATCH v6] c++: -Wdangling-reference with reference wrapper [PR107532]

On Fri, Mar 03, 2023 at 09:30:38PM -0500, Jason Merrill wrote: > On 3/3/23 12:50, Marek Polacek wrote: > > switch (TREE_CODE (expr)) > > { > > case CALL_EXPR: > > @@ -13831,7 +13895,8 @@ do_warn_dangling_reference (tree expr) > > std::pair v = std::minmax(1, 2); > >

[PATCH v2] c++: error with constexpr operator() [PR107939]

On Mon, Mar 06, 2023 at 11:12:56AM -0500, Jason Merrill wrote: > On 3/3/23 12:51, Marek Polacek wrote: > > Similarly to PR107938, this also started with r11-557, whereby > > cp_finish_decl > > can call check_initializer even in a template for a constexpr initializer. > > > > Here we are rejecting

[PATCH] c++: noexcept and copy elision [PR109030]

When processing a noexcept, constructors aren't elided: build_over_call has /* It's unsafe to elide the constructor when handling a noexcept-expression, it may evaluate to the wrong value (c++/53025). */ && (force_elide || cp_noexcept_operand == 0)) so the

Re: [PATCH v2] c++: error with constexpr operator() [PR107939]

On Tue, Mar 07, 2023 at 09:53:28AM -0500, Jason Merrill wrote: > On 3/6/23 17:01, Marek Polacek wrote: > > On Mon, Mar 06, 2023 at 11:12:56AM -0500, Jason Merrill wrote: > > > On 3/3/23 12:51, Marek Polacek wrote: > > > > Similarly to PR107938, this also started with r11-557, whereby > > > > cp_fi

Re: [PATCH] [RFC] RAII auto_mpfr and autp_mpz

On Tue, Mar 07, 2023 at 09:54:08PM +, Jonathan Wakely via Gcc-patches wrote: > On Tue, 7 Mar 2023 at 21:52, Alexander Monakov wrote: > > > > > > On Tue, 7 Mar 2023, Jonathan Wakely wrote: > > > > > > Shouldn't this use the idiom suggested in ansidecl.h, i.e. > > > > > > > > private: > > > >

  1   2   3   4   5   6   7   8   9   10   >