Re: [PATCH] libcpp, v2: Add -Winvalid-utf8 warning [PR106655]

On 8/30/22 11:20, Jakub Jelinek wrote: On Mon, Aug 29, 2022 at 11:31:54PM -0400, Jason Merrill wrote: The pedwarn on -std=c++23 -finput-charset=UTF-8 or just documenting that "conforming" UTF-8 is only -finput-charset=UTF-8 -Werror=invalid-utf8 ? The former. Ok. So, here is an updated patch

Re: [PATCH] c/c++: new warning: -Wxor-used-as-pow [PR90885]

On 8/11/22 21:38, David Malcolm via Gcc-patches wrote: PR c/90885 notes various places in real-world code where people have written C/C++ code that uses ^ (exclusive or) where presumbably they meant exponentiation. For example https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=2%5E32&search

Re: [Patch] add more C++ name hints. v2

On 8/22/22 15:09, Ulrich Drepper via Gcc-patches wrote: This is the second version of the proposed patch to add more identifiers to the known list to give hints about #include and version numbers. Marek looked through the first version and found it acceptable but remarked that the list is gettin

Re: C++: add -std={c,gnu}++{current,future}

On 7/13/22 15:29, Nathan Sidwell wrote: Inspired by a user question.  Jason, thoughts? Since C++ is such a moving target, Microsoft have /std:c++latest (AFAICT clang does not), to select the currently implemented version of the working paper.  But the use of 'std:latest' is somewhat ambiguous --

Re: [PATCH] c++: __has_builtin gives the wrong answer [PR106759]

On 8/29/22 17:26, Marek Polacek wrote: We've supported __is_nothrow_constructible since r11-4386, but names_builtin_p didn't know about it, so it gave the wrong answer for #if __has_builtin(__is_nothrow_constructible) ... #endif I've tested all C++-only built-ins and only two were missing.

Re: [PATCH] libcpp: Add -Winvalid-utf8 warning [PR106655]

On 8/29/22 17:35, Jakub Jelinek wrote: On Mon, Aug 29, 2022 at 05:15:26PM -0400, Jason Merrill wrote: On 8/29/22 04:15, Jakub Jelinek wrote: Hi! The following patch introduces a new warning - -Winvalid-utf8 similarly to what clang now has - to diagnose invalid UTF-8 byte sequences in comments.

Re: [PATCH v2] c++: Fix C++11 attribute propagation [PR106712]

On 8/29/22 16:01, Marek Polacek wrote: On Mon, Aug 29, 2022 at 01:32:29PM -0400, Jason Merrill wrote: On 8/26/22 19:01, Marek Polacek wrote: When we have [[noreturn]] int fn1 [[nodiscard]](), fn2(); "noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1: [dcl.pre]/3: "The

Re: [PATCH] libcpp: Add -Winvalid-utf8 warning [PR106655]

On 8/29/22 04:15, Jakub Jelinek wrote: Hi! The following patch introduces a new warning - -Winvalid-utf8 similarly to what clang now has - to diagnose invalid UTF-8 byte sequences in comments. In identifiers and in string literals it should be diagnosed already but comment content hasn't been r

Re: [PATCH] c++: Fix C++11 attribute propagation [PR106712]

On 8/26/22 19:01, Marek Polacek wrote: When we have [[noreturn]] int fn1 [[nodiscard]](), fn2(); "noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1: [dcl.pre]/3: "The attribute-specifier-seq appertains to each of the entities declared by the declarators of the init-decla

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

On 8/26/22 13:04, Marek Polacek wrote: On Thu, Aug 25, 2022 at 08:52:58PM -0400, Jason Merrill wrote: On 8/25/22 17:49, Marek Polacek wrote: On Thu, Aug 25, 2022 at 09:25:43AM -0400, Jason Merrill wrote: On 8/24/22 17:30, Marek Polacek wrote: On Tue, Aug 23, 2022 at 05:27:00PM -0400, Jason Me

Re: [PATCH] libcpp: Implement P2362R3 - Remove non-encodable wide character literals and multicharacter [PR106647]

On 8/26/22 03:35, Jakub Jelinek wrote: Hi! My understanding of the paper is that we just want to promote the CPP_WCHAR "character constant too long for its type" warning to error as it is already error for u8, u and U literals. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk

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

On 8/25/22 17:49, Marek Polacek wrote: On Thu, Aug 25, 2022 at 09:25:43AM -0400, Jason Merrill wrote: On 8/24/22 17:30, Marek Polacek wrote: On Tue, Aug 23, 2022 at 05:27:00PM -0400, Jason Merrill wrote: On 8/23/22 09:39, Marek Polacek wrote: + tree arg = CALL_EXPR_ARG (fn, 0); + extract_op

[pushed] c++: block copy elision in delegating ctor

CWG2403 deals with the issue that copy elision is not possible when the initialized object is a potentially-overlapping subobject and the initializer is a function that returns by value. Jonathan pointed out that this also affects delegating constructors, which might be used to construct a base su

[pushed] dwarf2: use DW_ATE_UTF for C++ char8_t

While looking at the Rust changes to dwarf2out I noticed that this was missing from the char8_t support. gcc/ChangeLog: * dwarf2out.cc (base_type_die): Also use DW_ATE_UTF for char8_t. gcc/testsuite/ChangeLog: * g++.dg/debug/dwarf2/utf-1.C: New test. --- gcc/dwarf2out.cc

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On 8/25/22 04:49, Jakub Jelinek wrote: On Wed, Aug 24, 2022 at 04:22:17PM -0400, Jason Merrill wrote: Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Does the copyright 2005-2022 mean that this code is partly derived from some other? Yes, I was lazy and started by copyin

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

On 8/24/22 17:30, Marek Polacek wrote: On Tue, Aug 23, 2022 at 05:27:00PM -0400, Jason Merrill wrote: On 8/23/22 09:39, Marek Polacek wrote: + tree arg = CALL_EXPR_ARG (fn, 0); + extract_op (arg); + if (TREE_CODE (arg) == ADDR_EXPR) +arg = TREE_OPERAND (arg, 0); + tree type = TREE_TYPE

Re: [PATCH] c++: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On 8/21/22 14:18, Jakub Jelinek wrote: Hi! The following patch implements the C++23 P2071R2 - Named universal character escapes paper to support \N{LATIN SMALL LETTER E} etc. I've used Unicode 14.0, there are 144803 character name properties (including the ones generated by Unicode NR1 and NR2 r

Re: [PATCH Rust front-end v2 01/37] Use DW_ATE_UTF for the Rust 'char' type

On 8/24/22 04:59, herron.phi...@googlemail.com wrote: From: Tom Tromey The Rust 'char' type should use the DWARF DW_ATE_UTF encoding. The DWARF changes are OK. --- gcc/dwarf2out.cc | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/gcc/dwarf2out.c

Re: [PATCH] preprocessor: Implement C++23 P2437R1 - Support for #warning [PR106646]

On 8/22/22 02:53, Jakub Jelinek wrote: Hi! On Thu, Aug 18, 2022 at 11:02:44PM +, Joseph Myers wrote: ISO C2x standardizes the existing #warning extension. Arrange accordingly for it not to be diagnosed with -std=c2x -pedantic, but to be diagnosed with -Wc11-c2x-compat. And here is the co

Re: [PATCH] c++: Quash bogus -Wredundant-move warning

On 8/22/22 17:10, Marek Polacek wrote: This patch fixes a pretty stoopid thinko. When I added code to warn about pessimizing std::move in initializations like T t{std::move(T())}; I also added code to unwrap the expression from { }. But when we have return {std::move(t)}; we cannot wa

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

On 8/23/22 09:39, Marek Polacek wrote: On Sat, Aug 20, 2022 at 05:31:52PM -0400, Jason Merrill wrote: On 8/19/22 15:34, Marek Polacek wrote: On Thu, Aug 18, 2022 at 08:33:47PM -0400, Jason Merrill wrote: On 8/18/22 13:19, Marek Polacek wrote: On Mon, Aug 15, 2022 at 03:54:05PM -0400, Jason Me

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

On 8/19/22 15:34, Marek Polacek wrote: On Thu, Aug 18, 2022 at 08:33:47PM -0400, Jason Merrill wrote: On 8/18/22 13:19, Marek Polacek wrote: On Mon, Aug 15, 2022 at 03:54:05PM -0400, Jason Merrill wrote: On 8/9/22 09:37, Marek Polacek wrote: + /* We're looking for *std::move ((T &) &arg), or

Re: [PING][PATCH] Add instruction level discriminator support.

On 8/3/22 17:25, Eugene Rozenfeld wrote: One more ping for this patch https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596065.html CC Jason since this changes discriminators emitted in dwarf. Thanks, Eugene -Original Message- From: Eugene Rozenfeld Sent: Monday, June 27, 2022 12:4

Re: [PATCH] libcpp, v2: Implement C++23 P2290R3 - Delimited escape sequences [PR106645]

On 8/18/22 01:17, Jakub Jelinek wrote: On Wed, Aug 17, 2022 at 10:22:03PM -0400, Jason Merrill wrote: OK, a comment mentioning this should be sufficient. Here is an updated patch with those changes in. So far successfully tested with GXX_TESTSUITE_STDS=98,11,14,17,20,2b make -j32 -k check-gcc

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

On 8/18/22 13:19, Marek Polacek wrote: On Mon, Aug 15, 2022 at 03:54:05PM -0400, Jason Merrill wrote: On 8/9/22 09:37, Marek Polacek wrote: + /* We're looking for *std::move ((T &) &arg), or + *std::move ((T &) (T *) r) if the argument it a reference. */ + if (!REFERENCE_REF_P (rhs) +

Re: [PATCH] libcpp: Implement C++23 P2290R3 - Delimited escape sequences [PR106645]

On 8/17/22 14:19, Jakub Jelinek wrote: On Wed, Aug 17, 2022 at 04:47:19PM -0400, Jason Merrill via Gcc-patches wrote: + length = 32; /* Magic value to indicate no digits seen. */ Indeed, will add the comment. + delimited = true; + if (loc_reader

Re: [PATCH] libcpp: Implement C++23 P2290R3 - Delimited escape sequences [PR106645]

On 8/17/22 00:17, Jakub Jelinek wrote: Hi! The following patch implements the C++23 P2290R3 paper. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2022-08-17 Jakub Jelinek PR c++/106645 libcpp/ * include/cpplib.h (struct cpp_options): Implement

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

On 8/16/22 14:09, Marek Polacek wrote: On Tue, Aug 16, 2022 at 03:23:18PM -0400, Jason Merrill wrote: On 8/2/22 16:04, Marek Polacek wrote: 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 c

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

On 8/2/22 16:04, Marek Polacek wrote: 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(

Re: [PATCH] c: Implement C23 nullptr (N3042)

On 8/13/22 14:35, Marek Polacek wrote: This patch implements the C23 nullptr literal: , which is intended to replace the problematic definition of NULL which might be either of integer type or void*. Since C++ has had nullptr for over a

Re: [PATCH] c++: Implement P2327R1 - De-deprecating volatile compound operations

On 8/15/22 03:31, Jakub Jelinek wrote: From what I can see, this has been voted in as a DR and as it means we warn less often than before in -std={gnu,c}++2{0,3} modes or with -Wvolatile, I wonder if it shouldn't be backported to affected release branches as well. If people are complaining ab

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

On 8/9/22 09:37, Marek Polacek wrote: 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

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

On 8/8/22 13:27, Marek Polacek wrote: 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&

Re: [PATCH 1/1 v2] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics.

Sorry for the delay, I'm travelling with limited internet. I will commit it early next week if no one beats me to it. On Thu, Aug 11, 2022, 2:45 PM Tom Honermann via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > If there are no further concerns, could a C++ or libcpp maintainer > please commit

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

On 8/8/22 12:06, Marek Polacek wrote: 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

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

On 8/8/22 12:27, Marek Polacek wrote: 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:

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

On 8/8/22 12:51, Marek Polacek wrote: 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 quest

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

On 8/8/22 12:06, Marek Polacek wrote: 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

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

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) { return std::move(t); } where the std::move is redundant, because T does not have a T(con

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

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()    { T t; return std::move (t); // warning \o/    } However, the warning doesn't w

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

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 expressions in templates that were type-dependent, but aren't anymore because we'

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

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() { T t; return std::move (t); // warning \o/ } However, the warning doesn't warn when what we are returning is a cla

Re: [PATCH] c++, v4: Add support for __real__/__imag__ modifications in constant expressions [PR88174]

On 7/27/22 02:09, Jakub Jelinek wrote: On Tue, Jul 05, 2022 at 04:44:41PM -0400, Jason Merrill wrote: But preeval should always be true, so we'd never reach the new handling in the if (!preeval) block. Certainly the new testcase doesn't exercise this code. Ok, changed now. I had to keep the

Re: [PATCH] gimple, internal-fn: Add IFN_TRAP and use it for __builtin_unreachable [PR106099]

On 7/27/22 03:09, Richard Biener wrote: On Wed, 27 Jul 2022, Jakub Jelinek wrote: On Wed, Jul 27, 2022 at 09:33:47AM +, Richard Biener wrote: __builtin_unreachable and __ubsan_handle_builtin_unreachable don't use vops, they are marked const/leaf/noreturn/nothrow/cold. But __builtin_trap us

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

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 conversion by creating a NOP_EXPR. For e.g. const int i = i; that means that the D

[pushed] c++: constexpr, empty base after non-empty [PR106369]

Here the CONSTRUCTOR we were providing for D{} had an entry for the B base subobject at offset 0 following the entry for the C base, causing output_constructor_regular_field to ICE due to going backwards. It might be nice for that function to be more tolerant of empty fields, but it also seems rea

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

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 '(int) i' and not 'i' anymore. Consequently, we don't suppress_warning here: 711 case

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

On 7/25/22 14:43, Marek Polacek wrote: 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 red

[pushed] c++: aggregate prvalue as for range [PR106230]

Since my PR94041 work on temporary lifetime in aggregate initialization, we end up calling build_vec_init to initialize the reference-extended temporary for the artificial __for_range variable. And build_vec_init uses finish_for_stmt to implement its loop. That function assumes that if __for_rang

[pushed] c++: -Woverloaded-virtual false positive [PR87729]

My attempt to shortcut unnecessary checking after finding a match was also wrong for multiple inheritance, so let's give up on it. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/87729 gcc/cp/ChangeLog: * class.cc (warn_hidden): Remove shortcut. gcc/testsuite/ChangeLog:

Re: [PATCH] c++: CTAD from initializer list [PR106366]

On 7/21/22 08:43, Patrick Palka wrote: During CTAD, we currently perform the first phase of overload resolution from [over.match.list] only if the class template has a list constructor. But according to [over.match.class.deduct]/4 it should be enough to just have a guide that looks like a list co

Re: [PATCH] c++: Refer to internal linkage for -Wsubobject-linkage [PR86491]

On 6/30/22 12:53, Jonathan Wakely via Gcc-patches wrote: Tested powerpc64le-linux, OK for trunk? -- >8 -- Since C++11 relaxed the requirement for template arguments to have external linkage, it's possible to get -Wsubobject-linkage warnings without using any anonymous namespaces. This confuses

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

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 to have it fixed. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for tru

[pushed] c++: defaulted friend op== [PR106361]

Now non-member functions can be defaulted, so this assert is wrong. move_signature_fn_p already checks for ctor or op=. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/106361 gcc/cp/ChangeLog: * decl.cc (move_fn_p): Remove assert. gcc/testsuite/ChangeLog: * g++.d

[pushed] c++: defaulted ctor with DMI in union [PR94823]

CWG2084 clarifies that a variant member with a non-trivial constructor does not make the union's defaulted default constructor deleted if another variant member has a default member initializer. Tested x86_64-pc-linux-gnu, applying to trunk. DR 2084 PR c++/94823 gcc/cp/ChangeLog:

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

On 7/19/22 09:11, Jonathan Wakely wrote: Tested x86_64-linux, OK for trunk? OK. -- >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. gcc/cp/ChangeLog: * cp-obj

Re: [PATCH] c++: shortcut bad reference bindings [PR94894]

On 7/18/22 12:59, Patrick Palka wrote: In case of l/rvalue or cv-qual mismatch during reference binding, we try to give more helpful diagnostics by attempting a bad conversion that ignores the mismatch. But in doing so, we may end up instantiating an ill-formed conversion function, something tha

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

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 P2255R2, which adds two new type traits to detect reference binding to a temporary.  Th

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

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 code like    std::tuple t("meow"); which is incorrect because it always creat

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

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 code like std::tuple t("meow"); which is incorrect because it always creates a dangling reference, because the std

Re: [PATCH] c++: dependence of constrained memfn from current inst [PR105842]

On 7/11/22 09:33, Patrick Palka wrote: Here we incorrectly deem the calls to func1, func2 and tmpl2 as ambiguous ahead of time ultimately because we mishandle dependence of a constrained member function from the current instantiation. In type_dependent_expression_p, we consider the dependence of

Re: [PATCH] c++: non-dependent call to consteval operator [PR105912]

On 7/11/22 21:27, Patrick Palka wrote: Here we were crashing when substituting a non-dependent call to a consteval operator, whose CALL_EXPR_OPERATOR_SYNTAX flag we try to propagate to the result, but the result isn't a CALL_EXPR since the called function is consteval. This patch fixes this by c

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

On 7/7/22 13:14, 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_type_pack_element(1, char, int

Re: [PATCH] c++: generic targs and identity substitution [PR105956]

On 7/7/22 11:16, Patrick Palka wrote: On Thu, 7 Jul 2022, Jason Merrill wrote: On 7/6/22 15:26, Patrick Palka wrote: On Tue, 5 Jul 2022, Jason Merrill wrote: On 7/5/22 10:06, Patrick Palka wrote: On Fri, 1 Jul 2022, Jason Merrill wrote: On 6/29/22 13:42, Patrick Palka wrote: In r13-1045-

[pushed] c++: -Woverloaded-virtual and dtors [PR87729]

My earlier patch broke out of the loop over base members when we found a match, but that caused trouble for dtors, which can have multiple for which same_signature_p is true. But as the function comment says, we know this doesn't apply to [cd]tors, so skip them. Tested x86_64-pc-linux-gnu, applyi

Re: [PATCH] c++: generic targs and identity substitution [PR105956]

On 7/6/22 15:26, Patrick Palka wrote: On Tue, 5 Jul 2022, Jason Merrill wrote: On 7/5/22 10:06, Patrick Palka wrote: On Fri, 1 Jul 2022, Jason Merrill wrote: On 6/29/22 13:42, Patrick Palka wrote: In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic DECL_TI_ARGS corresponds

Re: Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

On 7/6/22 10:23, Lewis Hyatt wrote: On Fri, Jul 01, 2022 at 08:23:53PM -0400, Jason Merrill wrote: On 7/1/22 18:05, Lewis Hyatt wrote: On Fri, Jul 1, 2022 at 3:59 PM Jason Merrill wrote: On 6/29/22 12:59, Jason Merrill wrote: On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote: Hello- htt

[pushed] c++: dependent conversion operator lookup [PR106179]

This testcase demonstrates that my assumption that we would only be interested in a class template lookup if the template-id is followed by :: was wrong. PR c++/106179 PR c++/106024 gcc/cp/ChangeLog: * parser.cc (cp_parser_lookup_name): Remove :: requirement for u

Re: [PATCH RFA] ubsan: do return check with -fsanitize=unreachable

On 6/29/22 13:26, Jakub Jelinek wrote: On Wed, Jun 29, 2022 at 12:42:04PM -0400, Jason Merrill wrote: The usual case is that people just use -fsanitize=undefined and get both return and unreachable sanitization, for fall through into end of functions returning non-void done through return saniti

Re: [PATCH] c++, v3: Add support for __real__/__imag__ modifications in constant expressions [PR88174]

On 7/4/22 11:50, Jakub Jelinek wrote: On Mon, Jun 27, 2022 at 06:31:18PM +0200, Jakub Jelinek via Gcc-patches wrote: Hmm, why do we need to handle complex in the !preeval case? I'd think we want to preevaluate all complex values or components thereof. Because the late evaluation of the ini

Re: [PATCH] c++: generic targs and identity substitution [PR105956]

On 7/5/22 10:06, Patrick Palka wrote: On Fri, 1 Jul 2022, Jason Merrill wrote: On 6/29/22 13:42, Patrick Palka wrote: In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic DECL_TI_ARGS corresponds to an identity mapping of the given arguments, and hence its safe to always elide

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

On 7/5/22 15:26, Marek Polacek wrote: 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 vi

Re: Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

On 7/1/22 18:05, Lewis Hyatt wrote: On Fri, Jul 1, 2022 at 3:59 PM Jason Merrill wrote: On 6/29/22 12:59, Jason Merrill wrote: On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote: Hello- https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html https://gcc.gnu.org/bugzilla/show_bug.cgi

Re: [PATCH] c++: generic targs and identity substitution [PR105956]

On 6/29/22 13:42, Patrick Palka wrote: In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic DECL_TI_ARGS corresponds to an identity mapping of the given arguments, and hence its safe to always elide such substitution. But this PR demonstrates that such a substitution isn't always

Re: Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

On 6/29/22 12:59, Jason Merrill wrote: On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote: Hello- https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49 Would a C++ maintainer have some time to take a look at this patch please? I

Re: [PATCH v2] c++: fix broken copy elision with nested TARGET_EXPRs [PR105550]

On 6/24/22 20:30, Marek Polacek wrote: On Thu, Jun 02, 2022 at 05:08:54PM -0400, Jason Merrill wrote: On 5/26/22 11:01, Marek Polacek wrote: In this problem, we are failing to properly perform copy elision with a conditional operator, so this: constexpr A a = true ? A{} : A{}; fails with:

Re: [PATCH] c++: warn about using keywords as identifiers [PR106111]

On 6/29/22 12:11, Marek Polacek wrote: In C++03, -Wc++11-compat should warn about int constexpr; since 'constexpr' is a keyword in C++11. Jonathan reports that we don't emit a similar warning for 'alignas' or 'alignof', and, as I found out, 'thread_local'. Similarly, we don't warn for most

[pushed] c++: tweak resolve_args change

I don't know why I used tf_error instead of complain here. PR c++/105779 gcc/cp/ChangeLog: * call.cc (resolve_args): Use complain. --- gcc/cp/call.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc index f1dd8377628..fc98552fda

[pushed] c++: add fixup to missing .template warning

I experimented with giving this diagnostic in another place, which didn't work out, but we can still benefit from adding the fixup. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * parser.cc (missing_template_diag): Split out... (cp_parser_id_expression): ...fro

[pushed] c++: dependent generic lambda template-id [PR106024]

We were wrongly looking up the generic lambda op() in a dependent scope, and then trying to look up its instantiation at substitution time, but lambdas aren't instantiated, so we crashed. The fix is to not look into dependent class scopes. But this created trouble with wrongly trying to use a tem

Re: Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote: Hello- https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49 Would a C++ maintainer have some time to take a look at this patch please? I feel like the PR is still worth resolvin

Re: [PATCH RFA] ubsan: do return check with -fsanitize=unreachable

On 6/27/22 11:44, Jakub Jelinek wrote: On Wed, Jun 22, 2022 at 12:04:59AM -0400, Jason Merrill wrote: On 6/20/22 16:16, Jason Merrill wrote: On 6/20/22 07:05, Jakub Jelinek wrote: On Fri, Jun 17, 2022 at 05:20:02PM -0400, Jason Merrill wrote: Related to PR104642, the current situation where w

[pushed] c++: Include -Woverloaded-virtual in -Wall [PR87729]

This seems like a good warning to have in -Wall, as requested. But as pointed out in PR20423, some users want a warning only when a derived function doesn't override any base function. So let's put that lesser version in -Wall (and -Woverloaded-virtual=1) while leaving the semantics for the exist

Re: [PATCH RFA] ubsan: do return check with -fsanitize=unreachable

On 6/22/22 00:04, Jason Merrill wrote: On 6/20/22 16:16, Jason Merrill wrote: On 6/20/22 07:05, Jakub Jelinek wrote: On Fri, Jun 17, 2022 at 05:20:02PM -0400, Jason Merrill wrote: Related to PR104642, the current situation where we get less return checking with just -fsanitize=unreachable than

Re: Add fnspec attributes to cxa_* functions

On 6/23/22 09:59, Jan Hubicka via Gcc-patches wrote: Note that your email subject line is missing "[PATCH]" and a component tag like "c++:". this patch adds fnspecs for cxa_* functions in except.cc. Main goal is to make modref to see proper side-effects of functions which may throw. So in ge

[pushed] c++: designated init cleanup [PR105925]

build_aggr_conv expects to run after reshape_init, which will usually have filled out all the CONSTRUCTOR indexes; there's no reason to limit using those to the case where the user gave an explicit designator. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105925 gcc/cp/ChangeLog:

[pushed] c++: anon union designated init [PR105925]

This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't getting set on the introduced CONSTRUCTOR for the anonymous union, and build_aggr_conv uses that flag to decide whether to pay attention to the indexes of the CONSTRUCTOR. So set the flag when we see a designator rather than r

Re: [PATCH] c++: constexpr folding in unevaluated context [PR105931]

On 6/23/22 11:06, Patrick Palka wrote: Changing the type of N from int to unsigned in decltype82.C from r12-8472-g47ea22015c90df reveals another spot where we perform constexpr evaluation in an unevaluated context for sake of diagnostics, this time from the call to shorten_compare in cp_build_bin

Re: [PATCH] c++: context completion in lookup_template_class [PR105982]

On 6/23/22 10:48, Patrick Palka wrote: The below testcase demonstrates that completion of the substituted context during lookup_template_class can end up registering the desired specialization for us in more cases than r13-1045-gcb7fd1ea85feea anticipated. In particular, it can happen for a non-

[pushed] c++: -Waddress and if constexpr [PR94554]

Like we avoid various warnings for seemingly tautological expressions when substituting a template, we should avoid warning for the implicit conversion to bool in an if statement. I considered also doing this for the conditions in loop expressions, but that seems unnecessary, as a loop condition i

[pushed] c++: -Waddress and value-dependent expr [PR105885]

We already suppress various warnings for code that would be tautological if written directly, but not when it's the result of template substitution. It seems we need to do this for -Waddress as well. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105885 gcc/cp/ChangeLog:

[pushed] c++: tweak deduction with auto template parms

While looking at PR105964 I noticed that we were unnecessarily repeating the deduction loop because of seeing a non-type parameter with type 'auto'. It is indeed dependent, but not on any other deductions. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * pt.cc (type_uni

[pushed] c++: dependence of baselink [PR105964]

helper::c isn't dependent just because we haven't deduced its return type yet. type_dependent_expression_p already knows how to deal with that for bare FUNCTION_DECL, but needs to learn to look through a BASELINK. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105964 gcc/cp/Chang

[pushed] c++: class scope function lookup [PR105908]

In r12-1273 for PR91706, I removed the code in get_class_binding that stripped BASELINK. This testcase demonstrates that we still need to strip it in outer_binding before putting the overload set in IDENTIFIER_BINDING, for compatibility with bindings added directly for declarations. Tested x86_64

Re: [PATCH RFA] ubsan: do return check with -fsanitize=unreachable

On 6/20/22 16:16, Jason Merrill wrote: On 6/20/22 07:05, Jakub Jelinek wrote: On Fri, Jun 17, 2022 at 05:20:02PM -0400, Jason Merrill wrote: Related to PR104642, the current situation where we get less return checking with just -fsanitize=unreachable than no sanitize flags seems undesirable; I

Re: [PATCH RFA] ubsan: default to trap on unreachable at -O0 and -Og [PR104642]

On 6/21/22 07:17, Jakub Jelinek wrote: On Mon, Jun 20, 2022 at 04:30:51PM -0400, Jason Merrill wrote: I'd still prefer to see a separate -funreachable-traps. The thing is that -fsanitize{,-recover,-trap}= are global options, not per function (and only tweaked by no_sanitize attribute), while some

Re: [PATCH RFA] ubsan: default to trap on unreachable at -O0 and -Og [PR104642]

On 6/16/22 09:14, Jakub Jelinek wrote: On Wed, Jun 15, 2022 at 04:38:49PM -0400, Jason Merrill wrote: Furthermore, handling it the UBSan way means we slow down the compiler (enable a bunch of extra passes, like sanopt, ubsan), which is undesirable e.g. for -O0 compilation speed. The ubsan pass

Re: [PATCH RFA] ubsan: do return check with -fsanitize=unreachable

On 6/20/22 07:05, Jakub Jelinek wrote: On Fri, Jun 17, 2022 at 05:20:02PM -0400, Jason Merrill wrote: Related to PR104642, the current situation where we get less return checking with just -fsanitize=unreachable than no sanitize flags seems undesirable; I propose that we do return checking when

Re: [PATCH] c++, v2: Add support for __real__/__imag__ modifications in constant expressions [PR88174]

On 6/17/22 13:06, Jakub Jelinek wrote: On Fri, Jun 10, 2022 at 09:57:06PM +0200, Jakub Jelinek via Gcc-patches wrote: On Fri, Jun 10, 2022 at 01:27:28PM -0400, Jason Merrill wrote: Doesn't this assert mean that complex_expr will always be == valp? No, even when handling the pushed *PART_EXPR,

[PATCH RFA] ubsan: do return check with -fsanitize=unreachable

Related to PR104642, the current situation where we get less return checking with just -fsanitize=unreachable than no sanitize flags seems undesirable; I propose that we do return checking when -fsanitize=unreachable. Looks like clang just traps on missing return if not -fsanitize=return, but the

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