Re: [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638]

On 11/11/22 08:47, Patrick Palka wrote: The commit r13-3706-gd0a492faa6478c for correcting the result of __has_attribute(init_priority) causes a bootstrap failure on hppa64-hpux because it assumes SUPPORTS_INIT_PRIORITY expands to a simple constant, but on this target SUPPORTS_INIT_PRIORITY is

Re: [PATCH] c++: Disable -Wdangling-reference when initing T

On 11/11/22 10:22, Marek Polacek wrote: Non-const lvalue references can't bind to a temporary, so the warning should not be emitted if we're initializing something of that type. I'm not disabling the warning when the function itself returns a non-const lvalue reference, that would regress at

Re: [PATCH] c++: Add testcase for DR 2604

On 11/14/22 01:43, Jakub Jelinek wrote: Hi! Working virtually out of Baker Island. As the following testcase shows, I think we don't inherit template's attributes into specializations. Tested on x86_64-linux, ok for trunk? OK. 2022-11-13 Jakub Jelinek * g++.dg/DRs/dr2604.C:

Re: [PATCH] c++: P2448 - Relaxing some constexpr restrictions [PR106649]

On 11/9/22 10:53, Marek Polacek wrote: This patch implements C++23 P2448, which lifts more restrictions on the constexpr keyword. It's effectively going the way of being just a hint (hello, inline!). This gist is relatively simple: in C++23, a constexpr function's return type/parameter type

[pushed] c++: only declare satisfied friends

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- A friend declaration can only have constraints if it is defined. If multiple instantiations of a class template define the same friend function signature, it's an error, but that shouldn't happen if it's constrained to only be declared in

Re: [PATCH v3] c++: parser - Support for target address spaces in C++

On 11/10/22 06:40, Georg-Johann Lay wrote: Am 10.11.22 um 15:08 schrieb Paul Iannetta: On Thu, Nov 03, 2022 at 02:38:39PM +0100, Georg-Johann Lay wrote: [PATCH v3] c++: parser - Support for target address spaces in C++ 2. Will it work with compound literals?

Re: [PATCH] c++: Extend -Wdangling-reference for std::minmax

On 11/9/22 15:56, Marek Polacek wrote: This patch extends -Wdangling-reference to also warn for auto v = std::minmax(1, 2); which dangles because this overload of std::minmax returns a std::pair where the two references are bound to the temporaries created for the arguments of std::minmax.

Re: [RFC PATCH] c++: Minimal handling of carries_dependency attribute

On 11/9/22 02:18, Jakub Jelinek wrote: On Tue, Nov 08, 2022 at 01:40:03PM -1000, Jason Merrill wrote: A comment in D2552R1: "The only questionable (but still conforming) case we found was [[carries_dependency(some_argument)]] on GCC, where the emitted diagnostic said that the

Re: [RFC PATCH] c++: Minimal handling of carries_dependency attribute

On 11/8/22 04:42, Jakub Jelinek wrote: Hi! A comment in D2552R1: "The only questionable (but still conforming) case we found was [[carries_dependency(some_argument)]] on GCC, where the emitted diagnostic said that the carries_dependency attribute is not supported, but did not specifically call

Re: [PATCH v2 2/3] libcpp: add a function to determine UTF-8 validity of a C string

On 10/27/22 13:16, Ben Boeckel wrote: This simplifies the interface for other UTF-8 validity detections when a simple "yes" or "no" answer is sufficient. Signed-off-by: Ben Boeckel --- libcpp/ChangeLog | 6 ++ libcpp/charset.cc | 18 ++ libcpp/internal.h | 2 ++ 3

Re: [PATCH v2 1/3] libcpp: reject codepoints above 0x10FFFF

On 10/27/22 13:16, Ben Boeckel wrote: Unicode does not support such values because they are unrepresentable in UTF-16. Signed-off-by: Ben Boeckel --- libcpp/ChangeLog | 6 ++ libcpp/charset.cc | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/libcpp/ChangeLog

Re: [PATCH] c++: Tweaks for -Wredundant-move [PR107363]

On 10/28/22 10:42, Marek Polacek wrote: Two things here: 1) when we're pointing out that std::move on a constant object is redundant, don't say "in return statement" when we aren't in a return statement; 2) suppress the warning when the std::move call was dependent, because removing

Re: [PATCH RFC(libstdc++)] c++: implement P2468R2, the equality operator you are looking for

On 11/7/22 12:04, Jonathan Wakely wrote: On Mon, 7 Nov 2022 at 21:56, Jonathan Wakely wrote: On Mon, 7 Nov 2022 at 20:58, Jason Merrill wrote: Tested x86_64-pc-linux-gnu. Jonathan, what do you want to do about the library test failure? -- >8 -- This paper is resolving the problem of

[PATCH RFC(libstdc++)] c++: implement P2468R2, the equality operator you are looking for

Tested x86_64-pc-linux-gnu. Jonathan, what do you want to do about the library test failure? -- >8 -- This paper is resolving the problem of well-formed C++17 code becoming ambiguous in C++20 due to asymmetrical operator== being compared with itself in reverse. I had previously implemented a

Re: [PATCH] c++: libcpp: Support raw strings with newlines in directives [PR55971]

On 10/27/22 13:30, Lewis Hyatt wrote: Hello- May I please ask for a review of this patch from June? I realize it's a 10-year-old PR that doesn't seem to be bothering people much, but I still feel like it's an unfortunate gap in C++11 support that is not hard to fix. Original submission is

Re: [PATCH] testsuite: Add testcase from C++23 P2314R4 - Character sets and encodings

On 11/4/22 05:14, Jakub Jelinek wrote: Hi! I've read the paper and I believe we just implement it with no changes needed (at least since PR67224 and similar libcpp changes in GCC 10), but I could be wrong. The following patch at least adds a testcase from the start of the paper.

Re: [PATCH RFA] input: add get_source_text_between

On 11/4/22 11:16, David Malcolm wrote: On Fri, 2022-11-04 at 10:27 -0400, Jason Merrill wrote: On 11/3/22 19:06, David Malcolm wrote: On Thu, 2022-11-03 at 15:59 -0400, Jason Merrill via Gcc-patches wrote: [...snip...] Do you have test coverage for this from the DejaGnu side

Re: [PATCH 1/2] c++: correct __has_attribute(init_priority)

On 11/4/22 11:05, Patrick Palka wrote: Currently __has_attribute(init_priority) always returns true, even on targets that don't actually support init priorities, and when using the attribute on such targets, we issue a hard error that init priorities are unsupported. This makes it impossible to

Re: [PATCH RFA] input: add get_source_text_between

On 11/3/22 19:06, David Malcolm wrote: On Thu, 2022-11-03 at 15:59 -0400, Jason Merrill via Gcc-patches wrote: Tested x86_64-pc-linux-gnu, OK for trunk? -- >8 -- The c++-contracts branch uses this to retrieve the source form of the contract predicate, to be returned by contract_violat

[PATCH RFA] input: add get_source_text_between

Tested x86_64-pc-linux-gnu, OK for trunk? -- >8 -- The c++-contracts branch uses this to retrieve the source form of the contract predicate, to be returned by contract_violation::comment(). gcc/ChangeLog: * input.cc (get_source_text_between): New fn. * input.h

[PATCH RFA] libstdc++: add experimental Contracts support

Tested x86_64-pc-linux-gnu. OK for trunk? -- >8 -- This patch adds the library support for the experimental C++ Contracts implementation. This now consists only of a default definition of the violation handler, which users can override through defining their own version. To avoid ABI

[pushed] c++: change -fconcepts to mean C++20 concepts

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- It was always weird that -fconcepts in C++17 mode meant the same thing as -fconcepts-ts in C++20 mode; this patch harmonizes the flags so that for TS concepts you always need to write -fconcepts-ts. In the unlikely event anyone is still

Re: [PATCH] c++: Disable -Wignored-qualifiers for template args [PR107492]

On 11/1/22 13:01, Marek Polacek wrote: It seems wrong to issue a -Wignored-qualifiers warning for code like: static_assert(!is_same_v); because there the qualifier matters. Likewise in template specialization: template struct S { }; template<> struct S { }; template<> struct S {

Re: [PATCH] c++: requires-expr substitution and access checking [PR107179]

On 11/3/22 11:45, Patrick Palka wrote: Like during satisfaction, we need to check access immediately during substitution of a requires-expr since the outcome of an access check can determine the value of the requires-expr. And otherwise, in contexts where access checking is deferred (such as

Re: [PATCH] c++: Quash -Wdangling-reference for member operator* [PR107488]

On 11/1/22 18:06, Marek Polacek wrote: -Wdangling-reference complains here: std::vector v = ...; std::vector::const_iterator it = v.begin(); while (it != v.end()) { const int = *it++; // warning } because it sees a call to __gnu_cxx::__normal_iterator >::operator* which

[pushed] c++: change -fconcepts to mean C++20 concepts

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- It was always weird that -fconcepts in C++17 mode meant the same thing as -fconcepts-ts in C++20 mode; this patch harmonizes the flags so that for TS concepts you always need to write -fconcepts-ts. In the unlikely event anyone is still

Re: [PATCH] c++: constexpr error with defaulted virtual dtor [PR93413]

On 11/3/22 08:33, Patrick Palka wrote: We're rejecting the below testcase with error: 'virtual constexpr Base::~Base()' used before its definition error: 'virtual constexpr Derived::~Derived()' used before its definition due to an early exit added to mark_used by r181272 to defer

Re: [PATCH v3] Add gcc/make-unique.h

On 10/26/22 16:40, David Malcolm via Gcc-patches wrote: Changed in v3: added include of v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604137.html v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598189.html On Tue, 2022-07-12 at 07:48 +0100, Jonathan Wakely wrote: On Tue,

[pushed] c++: set TREE_NOTHROW after genericize

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- genericize might introduce function calls (and does on the contracts branch), so it's safer to set this flag later. gcc/cp/ChangeLog: * decl.cc (finish_function): Set TREE_NOTHROW later in the function. --- gcc/cp/decl.cc | 16

Re: [PATCH] c++: -Wdangling-reference and system headers

On 10/27/22 11:39, Marek Polacek wrote: I got this testcase: auto f() -> std::optional; for (char c : f().value()) { } which has a dangling reference: std::optional::value returns a reference to the contained value, but here it's the f() temporary. We warn, which is great, but only with

[pushed] c++: apply friend attributes sooner

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- Comparing attributes between declarations of a friend function has been complicated by pushdecl happening before decl_attributes. I assumed there was some complicated reason we weren't calling decl_attributes here, but it doesn't break

Re: [PATCH v4] c++: Implement -Wdangling-reference [PR106393]

On 10/26/22 14:26, Marek Polacek wrote: On Wed, Oct 26, 2022 at 12:42:27PM -0400, Jason Merrill wrote: On 10/26/22 12:10, Marek Polacek wrote: As before, I've tested this patch twice, once with -Wdangling-reference enabled by default, once with -Wdangling-reference enabled by -Wextra. The

Re: [PATCH] c++: Fix excess precision related ICE on invalid binop [PR107382, PR107383]

On 10/26/22 04:23, Jakub Jelinek wrote: Hi! The following tests ICE in the gcc_assert (common); in cp_build_binary_op. I've missed that while for * common is set always, while for +, - and / it is in some cases not. If it is not, then if (!result_type && arithmetic_types_p &&

Re: [PATCH v3] c++: Implement -Wdangling-reference [PR106393]

On 10/26/22 12:10, Marek Polacek wrote: On Tue, Oct 25, 2022 at 11:53:51AM -0400, Jason Merrill via Gcc-patches wrote: On 10/25/22 11:21, Marek Polacek wrote: On Mon, Oct 24, 2022 at 01:30:42PM -0400, Jason Merrill wrote: On 10/21/22 19:28, Marek Polacek wrote: It doesn't warn when

Re: [PATCH v3] c++: parser - Support for target address spaces in C++

On 10/26/22 03:18, Paul Iannetta wrote: On Wed, Oct 19, 2022 at 02:55:21PM -0400, Jason Merrill wrote: On 10/18/22 13:01, Paul Iannetta wrote: Thank you very much for the detailed review. On Tue, Oct 18, 2022 at 10:24:23AM -0400, Jason Merrill wrote: On 10/18/22 03:37, Paul Iannetta wrote:

[pushed] c++: correct fold_operand change

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- Still want the conversion to bool. gcc/cp/ChangeLog: * constexpr.cc (find_failing_clause_r): Re-add the call to contextual_conv_bool. --- gcc/cp/constexpr.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[pushed] c++: constexpr-evaluate more assumes

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- The initial [[assume]] support avoided evaluating assumes with TREE_SIDE_EFFECTS set, such as calls, because we don't want any side-effects that change the constexpr state. This patch allows us to evaluate expressions with that flag set by

[pushed] c++: improve failed constexpr assume diagnostic

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- I noticed that we were printing "the comparison reduces to (x == 42)" when we should be able to give the value of x. Fixed by doing the same evaluation in diagnose_failing_condition that we already do in find_failing_clause.

Re: [PATCH v2] c++: Implement -Wdangling-reference [PR106393]

On 10/25/22 11:21, Marek Polacek wrote: On Mon, Oct 24, 2022 at 01:30:42PM -0400, Jason Merrill wrote: On 10/21/22 19:28, Marek Polacek wrote: This patch implements a new experimental warning (enabled by -Wextra) to detect references bound to temporaries whose lifetime has ended. The Great!

Re: [PATCH] c++: Implement -Wdangling-reference [PR106393]

On 10/25/22 09:14, Marek Polacek wrote: On Tue, Oct 25, 2022 at 12:34:50PM +0100, Jonathan Wakely wrote: On Mon, 24 Oct 2022 at 18:30, Jason Merrill wrote: On 10/21/22 19:28, Marek Polacek wrote: When testing a previous version of the patch, there were many FAILs in libstdc++'s 22_locale/;

Re: [PATCH] c, c++: Fix up excess precision handling of scalar_to_vector conversion [PR107358]

On 10/24/22 03:19, Jakub Jelinek wrote: Hi! As mentioned earlier in the C++ excess precision support mail, the following testcase is broken with excess precision both in C and C++ (though just in C++ it was triggered in real-world code). scalar_to_vector is called in both FEs after the excess

Re: [PATCH] c++: remove use_default_args parm of coerce_template_parms

On 10/24/22 12:27, Patrick Palka wrote: It looks like the parameter use_default_args introduced in r110693 is effectively unused ever since r7-5536-g3c75aaa3d884ef removed the last (and probably only) 'coerce_template_parms (..., true, false)' call, so this patch gets rid of it. In passing, I

Re: [PATCH v2] c++: ICE with invalid structured bindings [PR107276]

On 10/24/22 13:13, Marek Polacek wrote: On Mon, Oct 24, 2022 at 10:31:50AM -0400, Jason Merrill wrote: On 10/21/22 19:29, Marek Polacek wrote: This test ICEs in C++23 because we reach the new code in do_auto_deduction: 30468 if (cxx_dialect >= cxx23 30469 && context == adc_return_type

Re: [PATCH] c++: Implement -Wdangling-reference [PR106393]

On 10/21/22 19:28, Marek Polacek wrote: This patch implements a new experimental warning (enabled by -Wextra) to detect references bound to temporaries whose lifetime has ended. The Great! primary motivation is the Note in : Capturing the

Re: [PATCH] c++: ICE with invalid structured bindings [PR107276]

On 10/21/22 19:29, Marek Polacek wrote: This test ICEs in C++23 because we reach the new code in do_auto_deduction: 30468 if (cxx_dialect >= cxx23 30469 && context == adc_return_type 30470 && (!AUTO_IS_DECLTYPE (auto_node) 30471 ||

Re: [PATCH] c++: Fix up constexpr handling of char/signed char/short pre/post inc/decrement [PR105774]

On 10/24/22 03:27, Jakub Jelinek wrote: Hi! signed char, char or short int pre/post inc/decrement are represented by normal {PRE,POST}_{INC,DEC}REMENT_EXPRs in the FE and only gimplification ensures that the {PLUS,MINUS}_EXPR is done in unsigned version of those types: case

Re: Ping (c,c++): Handling of main() function for freestanding

On 10/23/22 07:54, Arsen Arsenović via Gcc-patches wrote: On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote: I have no objections to the C changes. Great! Thanks for the review. I don't have push rights currently, so I must ask that someone else pushes this patch for me. Have a

Re: [PATCH] c++, v2: Don't shortcut TREE_CONSTANT vector type CONSTRUCTORs in cxx_eval_constant_expression [PR107295]

On 10/21/22 03:30, Jakub Jelinek wrote: On Thu, Oct 20, 2022 at 10:51:14AM -0400, Jason Merrill wrote: That seems like a bug; for VECTOR_TYPE we should fold even if !changed. Also, the reason for the short-cutting is I think trying to avoid allocating a new CONSTRUCTOR when nothing changes

[PATCH RFA] tree: add build_string_literal overloads

Tested x86_64-pc-linux-gnu, OK for trunk? -- >8 -- Simplify several calls to build_string_literal by not requiring redundant strlen or IDENTIFIER_* in the caller. I also corrected a wrong comment on IDENTIFIER_LENGTH. gcc/ChangeLog: * tree.h (build_string_literal): New one-argument

Re: [PATCH RESEND 1/1] p1689r5: initial support

On 10/20/22 13:31, Ben Boeckel wrote: On Thu, Oct 20, 2022 at 11:39:25 -0400, Jason Merrill wrote: Oops, I was thinking this was in gcc as well. In libcpp there's _cpp_valid_utf8 (which calls one_utf8_to_cppchar). This routine has a lot more logic (including UCN decoding) and the

Re: [PATCH] c++: constraint matching, TEMPLATE_ID_EXPR, current inst

On 9/17/22 10:31, Patrick Palka wrote: On Sat, 17 Sep 2022, Jason Merrill wrote: On 9/16/22 10:59, Patrick Palka wrote: On Fri, 16 Sep 2022, Jason Merrill wrote: On 9/15/22 11:58, Patrick Palka wrote: Here we're crashing during constraint matching for the instantiated hidden friends due to

Re: [PATCH RESEND 1/1] p1689r5: initial support

On 10/18/22 08:18, Ben Boeckel wrote: On Tue, Oct 11, 2022 at 07:42:43 -0400, Ben Boeckel wrote: On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote: Can we share utf8 parsing code with decode_utf8_char in pretty-print.cc? I can look at factoring that out. I'll have to decode its

Re: [PATCH] c++: Don't shortcut TREE_CONSTANT vector type CONSTRUCTORs in cxx_eval_constant_expression [PR107295]

On 10/19/22 03:48, Jakub Jelinek wrote: Hi! The excess precision support broke building skia (dependency of firefox) on ia32 (it has something like the a constexpr variable), but as the other cases show, it is actually a preexisting problem if one uses casts from constants with wider floating

Re: [PATCH] c++, v2: Fix up mangling ICE with void{} [PR106863]

On 10/20/22 10:38, Jakub Jelinek wrote: On Thu, Oct 20, 2022 at 10:19:59AM -0400, Jason Merrill wrote: I think in a template we want the same early-return behavior as in the processing_template_decl block farther down in the function: specifically, we want to return a CONSTRUCTOR (for which

Re: [PATCH] c++: Fix up mangling ICE with void{} [PR106863]

On 10/19/22 04:00, Jakub Jelinek wrote: Hi! We ICE on the following testcase during mangling, finish_compound_literal returns for void{} void_node and the mangler doesn't handle it. Handling void_node in the mangler seems problematic to me, because we don't know for which case it has been

Re: [PATCH] introduce C++ API data base and generator for C++ hints

On 10/18/22 11:06, Ulrich Drepper wrote: I updated the patch based on the feedback from Jason and Martin.  It keeps the CSV file and the python script in the cp/ directory.  There also is still only one Python script. If there is agreement that either of those should change despite the

Re: [PATCH v3] c++: parser - Support for target address spaces in C++

On 10/18/22 13:01, Paul Iannetta wrote: Thank you very much for the detailed review. On Tue, Oct 18, 2022 at 10:24:23AM -0400, Jason Merrill wrote: On 10/18/22 03:37, Paul Iannetta wrote: On Fri, Oct 14, 2022 at 11:19:50AM -0400, Jason Merrill wrote: On 10/13/22 17:57, Paul Iannetta wrote:

Re: [PATCH v2] c++: Mitigate -Wuseless-cast with classes [PR85043]

On 10/19/22 12:38, Marek Polacek wrote: On Wed, Oct 19, 2022 at 09:27:27AM -0400, Jason Merrill wrote: On 10/18/22 13:38, Marek Polacek wrote: -Wuseless-cast (not part of -Wall/-Wextra) warns here: struct S { }; void g (S&&); void f (S&& arg) { g (S(arg)); // warning:

Re: [PATCH] testsuite: Default make check-g++ vs. tests for newest C++ standard

On 10/19/22 11:27, Jakub Jelinek wrote: Hi! On Wed, Oct 19, 2022 at 09:10:48AM -0400, Jason Merrill wrote: The screw-up on my side with libstdc++ testing (tested normally rather than in C++23 mode) makes me wonder if we couldn't tweak the default testing. Dunno what libstdc++ testing normally

Re: [PATCH] c++: Mitigate -Wuseless-cast with classes [PR85043]

On 10/18/22 13:38, Marek Polacek wrote: -Wuseless-cast (not part of -Wall/-Wextra) warns here: struct S { }; void g (S&&); void f (S&& arg) { g (S(arg)); // warning: useless cast to type 'struct S' } which is wrong: the code will not compile without the cast because "arg"

Re: [PATCH v3] c++: parser - Support for target address spaces in C++

On 10/18/22 03:37, Paul Iannetta wrote: On Fri, Oct 14, 2022 at 11:19:50AM -0400, Jason Merrill wrote: On 10/13/22 17:57, Paul Iannetta wrote: On Thu, Oct 13, 2022 at 03:41:16PM -0400, Jason Merrill wrote: On 10/13/22 12:02, Paul Iannetta wrote: On Thu, Oct 13, 2022 at 11:47:42AM -0400,

Re: [PATCH] C++ API database

On 9/28/22 12:59, Ulrich Drepper via Gcc-patches wrote: Ping. Anyone having problems with this? And the governance of the file? Hmm, for some reason this didn't show up on my C++ patches filter. Please do CC me when pinging C++ patches. On Mon, Sep 12, 2022 at 1:51 PM Ulrich Drepper

Re: [PATCH v2] c++: parser - Support for target address spaces in C++

On 10/13/22 17:57, Paul Iannetta wrote: On Thu, Oct 13, 2022 at 03:41:16PM -0400, Jason Merrill wrote: On 10/13/22 12:02, Paul Iannetta wrote: On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason Merrill wrote: On 10/13/22 11:23, Paul Iannetta wrote: On Thu, Oct 13, 2022 at 11:02:24AM -0400,

Re: Handling of main() function for freestanding

On 10/14/22 06:04, Arsen Arsenović wrote: On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote: I liked in the previous version that you checked the return type of main when !flag_hosted, here and in c_missing_noreturn_ok_p. Let's bring that back. Ah, right; I forgot about that.

Re: Handling of main() function for freestanding

On 10/13/22 16:14, Arsen Arsenović wrote: On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote: I was arguing that we don't need the new flag; there shouldn't be any need to turn it off. At the time, I opted to go with a more conservative route; I haven't been around enough to have

Re: [PATCH v2] c++: parser - Support for target address spaces in C++

On 10/13/22 12:02, Paul Iannetta wrote: On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason Merrill wrote: On 10/13/22 11:23, Paul Iannetta wrote: On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason Merrill wrote: On 10/12/22 20:52, Paul Iannetta wrote: On Tue, Oct 11, 2022 at 09:49:43PM -0400,

Re: [PATCH] middle-end, c++, i386, libgcc, v2: std::bfloat16_t and __bf16 arithmetic support

On 10/13/22 12:50, Jakub Jelinek wrote: Hi! On Wed, Oct 05, 2022 at 04:02:25PM -0400, Jason Merrill wrote: As I wrote earlier, I think we need at least one, __builtin_nans variant which would be used in libstdc++ std::numeric_limits::signaling_NaN() implementation. I think

Re: [PATCH] c++, v2: Implement excess precision support for C++ [PR107097, PR323]

On 10/13/22 12:40, Jakub Jelinek wrote: On Wed, Oct 12, 2022 at 02:08:20PM -0400, Jason Merrill wrote: In general I've tried to follow the C99 handling, C11+ relies on the C standard saying that in case of integral conversions excess precision can be used (see PR87390 for more details), but I

Re: Handling of main() function for freestanding

On 10/13/22 13:02, Arsen Arsenović wrote: Hi, On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote: * gcc.dg/noreturn-4.c: Likewise. I'd be inclined to drop this test. That seems like an odd choice, why do that over using another function for the test case? (there's nothing

Re: [PATCH v2] c++: parser - Support for target address spaces in C++

On 10/13/22 11:23, Paul Iannetta wrote: On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason Merrill wrote: On 10/12/22 20:52, Paul Iannetta wrote: On Tue, Oct 11, 2022 at 09:49:43PM -0400, Jason Merrill wrote: It surprises that this is the only place we complain about an object with an

Re: [PATCH] c++ modules: ICE with templated friend and std namespace [PR100134]

On 10/11/22 13:40, Nathan Sidwell wrote: On 10/11/22 11:35, Patrick Palka wrote: IIUC the function depset::hash::add_binding_entity has an assert verifying that if a namespace contains an exported entity, then the namespace must have been opened in the module purview:    if

Re: [PATCH v2] c++: parser - Support for target address spaces in C++

On 10/12/22 20:52, Paul Iannetta wrote: On Tue, Oct 11, 2022 at 09:49:43PM -0400, Jason Merrill wrote: It surprises that this is the only place we complain about an object with an address-space qualifier. Shouldn't we also complain about e.g. automatic variables/parameters or non-static data

Re: [PATCH] use proper DECL_INITIAL for VTV

On 10/13/22 10:25, Martin Liška wrote: Hi. I am working on the early debug info emission that would benefit from a late use of asm_put_file. This is last blocker where C++ emits early a section directive in assemble_vtv_preinit_initializer. We can use a proper DECL_INITIAL for that. Patch can

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On 10/13/22 09:58, Marek Polacek wrote: On Wed, Oct 12, 2022 at 02:23:40PM -0400, Marek Polacek wrote: On Wed, Oct 12, 2022 at 01:12:57PM -0400, Marek Polacek wrote: On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote: On 10/12/22 12:27, Marek Polacek wrote: On Tue, Oct 11, 2022 at

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On 10/12/22 14:23, Marek Polacek wrote: On Wed, Oct 12, 2022 at 01:12:57PM -0400, Marek Polacek wrote: On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote: On 10/12/22 12:27, Marek Polacek wrote: On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: On 10/11/22 16:00,

Re: [PATCH] c++: Implement excess precision support for C++ [PR107097, PR323]

On 10/11/22 09:33, Jakub Jelinek wrote: Hi! The following patch implements excess precision support for C++. Great! Like for C, it uses EXCESS_PRECISION_EXPR tree to say that its operand is evaluated in excess precision and what the semantic type of the expression is. In most places I've

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On 10/12/22 12:27, Marek Polacek wrote: On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: On 10/11/22 16:00, Marek Polacek wrote: Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr while processing the default argument in this test. Hmm, why are we calling

Re: [PATCH] middle-end, v2: IFN_ASSUME support [PR106654]

On 10/11/22 09:36, Jakub Jelinek wrote: On Mon, Oct 10, 2022 at 11:19:24PM +0200, Jakub Jelinek via Gcc-patches wrote: On Mon, Oct 10, 2022 at 05:09:29PM -0400, Jason Merrill wrote: On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote: My earlier patches gimplify the simplest

[pushed] c++: defer all consteval in default args [DR2631]

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- The proposed resolution of CWG2631 extends our current handling of source_location::current to all consteval functions: default arguments are not evaluated until they're used in a call, the same should apply to evaluation of immediate

Re: [PATCH v2] c++: parser - Support for target address spaces in C++

On 10/11/22 18:03, Paul Iannetta wrote: Thank you very much for the comments. On Mon, Oct 10, 2022 at 03:20:13PM -0400, Jason Merrill wrote: On 10/9/22 12:12, Paul Iannetta wrote: That's a nice feature! LLVM is using AS to mangle the address-name qualified types but that would have required

Re: [PATCH] coroutines: Use cp_build_init_expr consistently.

On 10/11/22 18:17, Iain Sandoe wrote: Hi Jason On 11 Oct 2022, at 23:06, Jason Merrill wrote: On 10/11/22 17:58, Iain Sandoe wrote: Tested on x86_64-darwin19, OK for master? thanks Iain -- >8 -- Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it is set properly on

Re: [PATCH] coroutines: Use cp_build_init_expr consistently.

On 10/11/22 17:58, Iain Sandoe wrote: Tested on x86_64-darwin19, OK for master? thanks Iain -- >8 -- Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it is set properly on target exprs. The code here has a mixture of APIs used to build inits. This patch changes that to

Re: [PATCH] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On 10/11/22 16:00, Marek Polacek wrote: Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr while processing the default argument in this test. Hmm, why are we calling cxx_eval_vec_init during parsing of the default argument? In particular, any expansion that depends on the

Re: [PATCH][ICE] Fix for PR107193.

On 10/10/22 20:36, Eugene Rozenfeld wrote: The bug was introduced in f30e9fd33e56a5a721346ea6140722e1b193db42. A variable (cur_locus_e) was incorrectly declared inside a loop. I also moved two other declarations (last and locus) down to make the code more clear. Tested on x86_64-pc-linux-gnu.

Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote: Hi! My earlier patches gimplify the simplest non-side-effects assumptions into if (cond) ; else __builtin_unreachable (); and throw the rest on the floor. The following patch attempts to do something with the rest too. For -O0, it actually

Re: [PATCH RESEND 1/1] p1689r5: initial support

On 10/4/22 11:12, Ben Boeckel wrote: This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Thanks! Support is communicated through the following three new flags:

Re: [PATCH RESEND 0/1] RFC: P1689R5 support

On 10/4/22 11:11, Ben Boeckel wrote: This patch adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be ordered to

Re: [PATCH] c++: Remove maybe-rvalue OR in implicit move

On 9/28/22 17:26, Marek Polacek wrote: This patch removes the two-stage overload resolution when performing implicit move, whereby the compiler does two separate overload resolutions: one treating the operand as an rvalue, and then (if that resolution fails) another one treating the operand as

Re: [PATCH v5] c-family: ICE with [[gnu::nocf_check]] [PR106937]

On 10/10/22 15:18, Marek Polacek wrote: On Mon, Oct 10, 2022 at 10:49:34AM -0400, Jason Merrill wrote: On 10/7/22 18:16, Marek Polacek wrote: On Fri, Oct 07, 2022 at 05:56:18PM -0400, Jason Merrill wrote: On 10/7/22 17:08, Marek Polacek wrote: On Fri, Oct 07, 2022 at 12:17:34PM -0400, Jason

Re: [PATCH] c++: parser - Support for target address spaces in C++

On 10/9/22 12:12, Paul Iannetta wrote: Hi, On Thu, Oct 06, 2022 at 01:34:40PM -0400, Jason Merrill wrote: [snip] Hmm? We mangle __restrict: void f(int *__restrict *p) { } // _Z1fPrPi Indeed, I have overlooked that point. Thank you for pointing it out. but cv-qualifiers (including

Re: [PATCH v4] c-family: ICE with [[gnu::nocf_check]] [PR106937]

On 10/7/22 18:16, Marek Polacek wrote: On Fri, Oct 07, 2022 at 05:56:18PM -0400, Jason Merrill wrote: On 10/7/22 17:08, Marek Polacek wrote: On Fri, Oct 07, 2022 at 12:17:34PM -0400, Jason Merrill wrote: On 10/6/22 22:12, Marek Polacek wrote: On Thu, Oct 06, 2022 at 05:42:41PM -0400, Jason

[pushed] c++: track whether we expect a TARGET_EXPR to be elided

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- A discussion at Cauldron made me think that with the formalization of copy elision in C++17, we should be able to determine before optimization which TARGET_EXPRs will become temporaries and which are initializers. This patch implements

Re: [PATCH v4] c-family: ICE with [[gnu::nocf_check]] [PR106937]

On 10/7/22 17:08, Marek Polacek wrote: On Fri, Oct 07, 2022 at 12:17:34PM -0400, Jason Merrill wrote: On 10/6/22 22:12, Marek Polacek wrote: On Thu, Oct 06, 2022 at 05:42:41PM -0400, Jason Merrill wrote: On 10/4/22 19:06, Marek Polacek wrote: On Fri, Sep 30, 2022 at 09:12:24AM -0400, Jason

Re: [PATCH v5] c++: fixes for derived-to-base reference binding [PR107085]

On 10/7/22 17:26, Marek Polacek wrote: On Fri, Oct 07, 2022 at 01:01:35PM -0400, Jason Merrill wrote: On 10/7/22 12:10, Marek Polacek wrote: On Thu, Oct 06, 2022 at 06:03:57PM -0400, Jason Merrill wrote: On 10/6/22 17:43, Marek Polacek wrote: On Thu, Oct 06, 2022 at 02:00:40PM -0400, Jason

Re: [PATCH v4] c++: fixes for derived-to-base reference binding [PR107085]

On 10/7/22 12:10, Marek Polacek wrote: On Thu, Oct 06, 2022 at 06:03:57PM -0400, Jason Merrill wrote: On 10/6/22 17:43, Marek Polacek wrote: On Thu, Oct 06, 2022 at 02:00:40PM -0400, Jason Merrill wrote: On 10/6/22 13:51, Marek Polacek wrote: On Thu, Oct 06, 2022 at 10:58:44AM -0400, Jason

Re: [PATCH v3] c-family: ICE with [[gnu::nocf_check]] [PR106937]

On 10/6/22 22:12, Marek Polacek wrote: On Thu, Oct 06, 2022 at 05:42:41PM -0400, Jason Merrill wrote: On 10/4/22 19:06, Marek Polacek wrote: On Fri, Sep 30, 2022 at 09:12:24AM -0400, Jason Merrill wrote: On 9/29/22 18:49, Marek Polacek wrote: When getting the name of an attribute, we ought

Re: c++: Lambda context mangling

On 10/7/22 08:27, Nathan Sidwell wrote: VAR and FIELD decls can become part of a lambda context, when the lambda is 'attached' to that entity (It's a C++20 ODR thing that was discovered with modules, but is actually separate.)  We were not marking those decls as substitution candidates, leading

Re: [PATCH] Set discriminators for call stmts on the same line within the same basic block

On 10/6/22 23:50, Eugene Rozenfeld wrote: Thank you for the review Jason. I fixed formatting and updated the commit description: OK. Call statements are possible split points of a basic block so they may end up in different basic blocks by the time

Re: [PATCH v3] c++: fixes for derived-to-base reference binding [PR107085]

On 10/6/22 17:43, Marek Polacek wrote: On Thu, Oct 06, 2022 at 02:00:40PM -0400, Jason Merrill wrote: On 10/6/22 13:51, Marek Polacek wrote: On Thu, Oct 06, 2022 at 10:58:44AM -0400, Jason Merrill wrote: On 10/6/22 10:49, Marek Polacek wrote: On Wed, Oct 05, 2022 at 08:25:29PM -0400, Jason

Re: [PATCH RFC] c++: fix broken conversion in coroutines

On 10/3/22 23:53, Jason Merrill wrote: On 9/30/22 18:50, Iain Sandoe wrote: Hi Jason, On 30 Sep 2022, at 23:06, Jason Merrill wrote: You can't use CONVERT_EXPR to convert between two class types, and it was breaking copy elision. Unfortunately, this patch breaks

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