[PATCH] opts: SANITIZE_ADDRESS wrongly cleared [PR108543]

Here we crash on a null fndecl ultimately because we haven't defined the built-ins described in sanitizer.def. So builtin_decl_explicit (BUILT_IN_ASAN_POINTER_SUBTRACT); returns NULL_TREE, causing an ICE later. DEF_SANITIZER_BUILTIN only actually defines the built-ins when flag_sanitize has SANIT

Re: [PATCH v4] c++: Reject UDLs in certain contexts [PR105300]

Ping. On Fri, Jan 13, 2023 at 06:22:38PM -0500, Marek Polacek wrote: > On Sat, Dec 03, 2022 at 02:58:16PM -0500, Jason Merrill wrote: > > On 12/2/22 18:58, Marek Polacek wrote: > > > On Fri, Nov 18, 2022 at 08:39:10PM -0500, Jason Merrill wrote: > > > > On 11/18

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

On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote: > On 1/19/23 21:03, Marek Polacek wrote: > > On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote: > > > On 1/18/23 20:13, Marek Polacek wrote: > > > > On Wed, Jan 18, 2023 at 04:07:5

Re: [PATCH] c++: Quash bogus -Wunused-value with new [PR107797]

On Fri, Jan 20, 2023 at 02:37:19PM -0500, Jason Merrill wrote: > On 1/19/23 21:03, Marek Polacek wrote: > > We shouldn't emit "right operand of comma operator has no effect" > > when that comma operator was created by the compiler for "new int{}". > >

[PATCH] c++: Quash bogus -Wunused-value with new [PR107797]

We shouldn't emit "right operand of comma operator has no effect" when that comma operator was created by the compiler for "new int{}". convert_to_void/COMPOUND_EXPR already checks warning_suppressed_p so we can just suppress -Wunused-value. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for tr

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

On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote: > On 1/18/23 20:13, Marek Polacek wrote: > > On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote: > > > On 1/18/23 12:52, Marek Polacek wrote: > > > > Here, -Wdangling-reference triggers where

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

On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote: > On 1/18/23 12:52, Marek Polacek wrote: > > Here, -Wdangling-reference triggers where it probably shouldn't, causing > > some grief. The code in question uses a reference wrapper with a member > > function

[PATCH] c: ICE with nullptr as case expression [PR108424]

In this ICE-on-invalid, we crash on gcc_assert (INTEGRAL_TYPE_P (type)); in perform_integral_promotions, because a nullptr is an INTEGER_CST, but not INTEGRAL_TYPE_P, and check_case_value is only checking the former. In the test I'm testing other "shall be an integral constant expression" cont

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

Here, -Wdangling-reference triggers where it probably shouldn't, causing some grief. The code in question uses a reference wrapper with a member function returning a reference to a subobject of a non-temporary object: const Plane & meta = fm.planes().inner(); I've tried a few approaches, e.g.,

[PATCH v4] c++: Reject UDLs in certain contexts [PR105300]

On Sat, Dec 03, 2022 at 02:58:16PM -0500, Jason Merrill wrote: > On 12/2/22 18:58, Marek Polacek wrote: > > On Fri, Nov 18, 2022 at 08:39:10PM -0500, Jason Merrill wrote: > > > On 11/18/22 18:52, Marek Polacek wrote: > > > > +/* Parse a string literal

Re: [PATCH] c, c++: Allow ignoring -Winit-self through pragmas [PR105593]

On Thu, Jan 12, 2023 at 09:49:56PM -0500, Jason Merrill wrote: > On 1/12/23 19:32, Jakub Jelinek wrote: > > Hi! > > > > As mentioned in the PR, various x86 intrinsics need to return > > an uninitialized vector. Currently they use self initialization > > to avoid -Wuninitialized warnings, which wo

Re: [PATCH] c: Diagnose compound literals with function type [PR108043]

On Mon, Dec 19, 2022 at 12:05:48PM +0100, Jakub Jelinek wrote: > Hi! > > Both C99 and latest C2X say that compound literal shall have an object type > (complete object type in the latter case) or array of unknown bound, > so complit with function type is invalid. When the initializer had to be >

[PATCH] c-family: Fix ICE with -Wsuggest-attribute [PR98487]

Here we crash because check_function_format was using TREE_PURPOSE directly rather than using get_attribute_name. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c/98487 gcc/c-family/ChangeLog: * c-format.cc (check_function_format): Use get_attribute_name. gcc/t

[PATCH v3] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 04:00:15PM +0100, Jakub Jelinek wrote: > On Thu, Dec 08, 2022 at 09:34:34AM -0500, Marek Polacek wrote: > > I got a complaint that while Clang docs suggest options that improve > > the quality of the backtraces ASAN prints (cf. > > <htt

[PATCH v2] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 03:28:13PM +0100, Jakub Jelinek wrote: > On Thu, Dec 08, 2022 at 09:11:54AM -0500, Marek Polacek via Gcc-patches wrote: > > On Thu, Dec 08, 2022 at 08:25:26AM +0100, Florian Weimer wrote: > > > * Marek Polacek via Gcc-patches: > > > > > >

Re: [PATCH] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 08:25:26AM +0100, Florian Weimer wrote: > * Marek Polacek via Gcc-patches: > > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > > index 726392409b6..2de14466dd3 100644 > > --- a/gcc/doc/invoke.texi > > +++ b/gcc/doc/invoke.texi &g

[PATCH] docs: Suggest options to improve ASAN stack traces

I got a complaint that while Clang docs suggest options that improve the quality of the backtraces ASAN prints (cf. ), our docs don't say anything to that effect. This patch amends that with a new paragraph. (It deliberately doesn't mention

[PATCH v3] c++: Reject UDLs in certain contexts [PR105300]

On Fri, Nov 18, 2022 at 08:39:10PM -0500, Jason Merrill wrote: > On 11/18/22 18:52, Marek Polacek wrote: > > +/* Parse a string literal or user defined string literal. > > + > > + user-defined-string-literal : > > + string-literal ud-suffix >

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

On Fri, Nov 18, 2022 at 09:26:26PM -0500, Jason Merrill wrote: > On 11/16/22 15:27, Jason Merrill wrote: > > On 11/16/22 11:06, Marek Polacek wrote: > > > On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote: > > > > On 11/15/22 19:30, Marek Polacek wrote:

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

On Sun, Nov 20, 2022 at 08:06:55AM -0700, Jeff Law wrote: > > On 11/10/22 19:52, Marek Polacek via Gcc-patches wrote: > > This is a rebased version of the patch I posted in March: > > <https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591239.html> > > wh

[PATCH v2] c++: Reject UDLs in certain contexts [PR105300]

On Thu, Nov 17, 2022 at 07:06:34PM -0500, Jason Merrill wrote: > On 11/16/22 20:12, Marek Polacek wrote: > > On Wed, Nov 16, 2022 at 08:22:39AM -0500, Jason Merrill wrote: > > > On 11/15/22 19:35, Marek Polacek wrote: > > > > On Tue, Nov 15, 2022 at 06:58:3

Re: [PATCH] c++, v4: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions

On Fri, Nov 18, 2022 at 08:48:32AM +0100, Jakub Jelinek wrote: > On Thu, Nov 17, 2022 at 07:15:05PM -0500, Marek Polacek wrote: > > > --- gcc/cp/decl.cc.jj 2022-11-16 14:44:43.692339668 +0100 > > > +++ gcc/cp/decl.cc2022-11-17 20:53:44.102011594 +0100 >

Re: [PATCH] c++, v4: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions

On Thu, Nov 17, 2022 at 09:42:17PM +0100, Jakub Jelinek wrote: > On Thu, Nov 17, 2022 at 07:42:40PM +0100, Jakub Jelinek via Gcc-patches wrote: > > I thought for older C++ this is to catch > > void > > foo () > > { > > constexpr int a = ({ static constexpr int b = 2; b; }); > > } > > and for C++2

[PATCH] c++: constinit on pointer to function [PR104066]

[dcl.constinit]: "The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration." Thus, this ought to be OK: constinit void (*p)() = nullptr; but the error message I introduced when implementing constinit was not looking at funcdecl_p, so t

Re: [PATCH] c: fix ICE with -fanalyzer and -Wunused-macros [PR107711]

On Wed, Nov 16, 2022 at 10:05:30PM -0500, David Malcolm wrote: > PR analyzer/107711 reports an ICE since r13-4073-gd8aba860b34203 with > the combination of -fanalyzer and -Wunused-macros. > > The issue is that in c_translation_unit::consider_macro's call to > cpp_create_reader I was passing "ident

Re: [PATCH] c++: Reject UDLs in certain contexts [PR105300]

On Wed, Nov 16, 2022 at 08:22:39AM -0500, Jason Merrill wrote: > On 11/15/22 19:35, Marek Polacek wrote: > > On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote: > > > On 11/12/22 06:53, Marek Polacek wrote: > > > > In this PR, we are crashing because w

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

On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote: > On 11/15/22 19:30, Marek Polacek wrote: > > @@ -996,19 +1040,26 @@ register_constexpr_fundef (const constexpr_fundef > > &value) > > **slot = value; > > } > > -/* FUN is a non-conste

Re: [PATCH] c++: Reject UDLs in certain contexts [PR105300]

On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote: > On 11/12/22 06:53, Marek Polacek wrote: > > In this PR, we are crashing because we've encountered a UDL where a > > string-literal is expected. This patch makes the parser reject string > > and character UD

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

On Mon, Nov 14, 2022 at 06:00:58PM -0500, Jason Merrill wrote: > 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, in

Re: [PATCH v3] c, analyzer: support named constants in analyzer [PR106302]

On Tue, Nov 15, 2022 at 01:35:05PM -0500, David Malcolm wrote: > On Mon, 2022-11-14 at 15:42 -0500, Marek Polacek wrote: > > On Fri, Nov 11, 2022 at 10:23:10PM -0500, David Malcolm wrote: > > > Changes since v1: ported the doc changes from texinfo to sphinx > > > >

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

On Thu, Nov 03, 2022 at 03:22:12PM -0400, Jason Merrill wrote: > 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 qualifi

Re: [PATCH v2] c, analyzer: support named constants in analyzer [PR106302]

On Fri, Nov 11, 2022 at 10:23:10PM -0500, David Malcolm wrote: > Changes since v1: ported the doc changes from texinfo to sphinx > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > Are the C frontend parts OK for trunk? (I can self-approve the > analyzer parts) Sorry for the

[wwwdocs] cxx-status: Add C++23 papers from the Nov 2022 Kona WG21 plenary

Pushed. commit b97d1aba41d95ae9220fe08a991738a58a716212 Author: Marek Polacek Date: Mon Nov 14 13:49:21 2022 -0500 cxx-status: Add C++23 papers from the Nov 2022 Kona WG21 plenary diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html index 8650f3cd..3454cfc9

[PATCH] c++: Reject UDLs in certain contexts [PR105300]

In this PR, we are crashing because we've encountered a UDL where a string-literal is expected. This patch makes the parser reject string and character UDLs in all places where the grammar requires a string-literal and not a user-defined-string-literal. Bootstrapped/regtested on x86_64-pc-linux-g

gcc-patches@gcc.gnu.org

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 least const int &r = std::any_cast(std::an

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

This is a rebased version of the patch I posted in February: . Fortunately it is much simpler than the patch implementing --enable-host-pie. I've converted the install.texi part into configuration.rst, otherwise there are no chan

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

This is a rebased version of the patch I posted in March: which Alex sort of approved here: but it was too late to commit the patch in GCC 12. There are no changes

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

On Thu, Nov 10, 2022 at 08:07:25AM -1000, Jason Merrill wrote: > 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

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

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. This is a common footgun, also described at

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

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 doesn't have to be a literal type; and you c

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

Ping. On Fri, Oct 28, 2022 at 04:42:33PM -0400, Marek Polacek via Gcc-patches 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 s

Re: [PATCH] libcpp: Update to Unicode 15

On Fri, Nov 04, 2022 at 09:55:55AM +0100, Jakub Jelinek wrote: > Hi! > > The following patch (included in the mail is for uname2c.h part > just a pseudo patch with a lot of changes replaced with ... > because it is too large but the important changes like > -static const char uname2c_dict[59418] =

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

On Thu, Nov 03, 2022 at 02:54:12PM -0400, Jason Merrill wrote: > 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

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

-Wdangling-reference complains here: std::vector v = ...; std::vector::const_iterator it = v.begin(); while (it != v.end()) { const int &r = *it++; // warning } because it sees a call to __gnu_cxx::__normal_iterator >::operator* which returns a reference and its argument is a TARGET_E

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

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 { }; // OK, not a redefinition I'm of the mind

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

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 the std::move may not be correct for a differ

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

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 -Wsystem-headers, because the function comes

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

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 coupl

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

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

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

On Tue, Oct 25, 2022 at 11:39:31AM -0400, Jason Merrill wrote: > 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: > > > > > > > &

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

On Tue, Oct 25, 2022 at 12:50:36PM +0100, Jonathan Wakely wrote: > On Sat, 22 Oct 2022 at 00:28, Marek Polacek wrote: > > I've run the testsuite/bootstrap with the warning enabled by default. > > There were just a few FAILs: > > * g++.dg/warn/Wdangling-pointer-

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

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 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++'

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

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

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

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 || !unparenthesized_id_or_class_member_access_p (init)) 30472 && (r = treat_lva

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

This patch implements a new experimental warning (enabled by -Wextra) to detect references bound to temporaries whose lifetime has ended. The primary motivation is the Note in : Capturing the result of std::max by reference produces a dangling re

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

On Wed, Oct 19, 2022 at 02:37:23PM -0400, Jason Merrill wrote: > 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 par

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

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

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

-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" is an lvalue which cannot bind to S&&. I'd like t

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

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, 2

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, Oct 12, 2022 at 11:38:01PM +0100, Jonathan Wakely wrote: > On Wed, 12 Oct 2022 at 23:24, Marek Polacek wrote: > > > > On Wed, Oct 12, 2022 at 09:50:36PM +0100, Jonathan Wakely wrote: > > > On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > > > >

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, Oct 12, 2022 at 09:50:36PM +0100, Jonathan Wakely wrote: > On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > > > As I promised in > > <https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603189.html>, > > I'd like to update our GCC 13 p

[wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

As I promised in , I'd like to update our GCC 13 porting_to.html with the following note. Does this look OK to commit? Thanks, diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html index 84a00f21..243ed29d 1

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

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

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

On Tue, Oct 11, 2022 at 03:33:23PM +0200, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following patch implements excess precision support for C++. > 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 >

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

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, Marek Polacek wrote: > > > > Since r12-8066, in cxx_eval_vec_init w

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

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 cxx_eval_vec_i

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

On Tue, Oct 11, 2022 at 09:40:45AM +0200, Andreas Schwab via Gcc-patches wrote: > On Okt 10 2022, Marek Polacek via Gcc-patches wrote: > > > diff --git a/gcc/testsuite/c-c++-common/pointer-to-fn1.c > > b/gcc/testsuite/c-c++-common/pointer-to-fn1.c > > new file mode 1006

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

Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr while processing the default argument in this test. At this point start_preparsed_function hasn't yet set current_function_decl. expand_vec_init_expr then leads to maybe_splice_retval_cleanup which checks DECL_CONSTRUCTOR_P (curr

[PATCH] testsuite: Only run -fcf-protection test on i?86/x86_64 [PR107213]

This test fails on non-i?86/x86_64 targets because on those targets we get error: '-fcf-protection=full' is not supported for this target so this patch limits where the test is run. Tested on x86_64-pc-linux-gnu, ok for trunk? gcc/testsuite/ChangeLog: * c-c++-common/pointer-to-fn1.c:

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

Ping. On Wed, Sep 28, 2022 at 05:26:34PM -0400, Marek Polacek via Gcc-patches 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Merrill wrote: > > > On 10/5/22 17:27, Marek Polacek wrote: > > > > This PR reports that &g

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

On Wed, Oct 05, 2022 at 08:25:29PM -0400, Jason Merrill wrote: > On 10/5/22 17:27, Marek Polacek wrote: > > This PR reports that > > > >struct Base {}; > >struct Derived : Base {}; > >static_assert(__reference_constructs_from_temporary(Base const&a

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

This PR reports that struct Base {}; struct Derived : Base {}; static_assert(__reference_constructs_from_temporary(Base const&, Derived)); doesn't pass, which it should: it's just like const Base& b(Derived{}); where we bind 'b' to the Base subobject of a temporary object of type Derive

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

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 to use > > get_attribute_name, which handles both [[ ]] and __attribute__(()) > > forms. Failure to do so may result

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

When getting the name of an attribute, we ought to use get_attribute_name, which handles both [[ ]] and __attribute__(()) forms. Failure to do so may result in an ICE, like here. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/106937 gcc/c-family/ChangeLog:

Re: [PATCH RFC] c++: streamline process for adding new builtin trait

On Thu, Sep 29, 2022 at 11:05:04AM -0400, Patrick Palka via Gcc-patches wrote: > Adding a new builtin trait currently involves some boilerplate (as can > be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and > CPTK_ enumerators and adding them to various switch statements across >

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

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 an lvalue. In the standard this was introd

Re: [PATCH v3] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On Tue, Sep 27, 2022 at 05:44:12PM -0400, Jason Merrill wrote: > On 9/27/22 16:26, Marek Polacek wrote: > > --- a/gcc/cp/typeck.cc > > +++ b/gcc/cp/typeck.cc > > @@ -11042,8 +11042,13 @@ check_return_expr (tree retval, bool *no_warning) > > the conditions

[PATCH v3] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On Mon, Sep 26, 2022 at 01:29:35PM -0400, Jason Merrill wrote: > On 9/20/22 14:19, Marek Polacek wrote: > > > > There's one FIXME in elision1.C:five, which we should compile but reject > > > > with "passing 'Mutt' as 'this' argument disca

Re: [PATCH v2] c++: Don't quote nothrow in diagnostic

On Tue, Sep 27, 2022 at 10:41:29AM +0200, Richard Biener wrote: > On Mon, Sep 26, 2022 at 9:54 PM Marek Polacek wrote: > > > > On Mon, Sep 26, 2022 at 12:34:04PM -0400, Jason Merrill wrote: > > > On 9/26/22 03:50, Richard Biener wrote: > > > > On Fri, Sep 23, 2

Re: [PATCH] c++: Make __is_{,nothrow_}convertible SFINAE on access [PR107049]

On Tue, Sep 27, 2022 at 11:35:10AM +0100, Jonathan Wakely wrote: > Tested powerpc64le-linux. OK for trunk? > > -- >8 -- > > The is_convertible built-ins should return false if the conversion fails > an access check, not report an error. Ah, so we do need that sentinel after all. Patch looks goo

[PATCH v2] c++: Don't quote nothrow in diagnostic

On Mon, Sep 26, 2022 at 12:34:04PM -0400, Jason Merrill wrote: > On 9/26/22 03:50, Richard Biener wrote: > > On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches > > wrote: > > > > > > In <https://gcc.gnu.org/pipermail/gcc-patches/2022-September/6020

Re: [PATCH] c++: Instantiate less when evaluating __is_convertible

On Mon, Sep 26, 2022 at 05:02:36PM +0100, Jonathan Wakely wrote: > On Mon, 26 Sept 2022 at 16:23, Marek Polacek wrote: > > > > Jon reported that evaluating __is_convertible in this test leads to > > instantiating char_traits::eq, which is invalid (because we > >

[PATCH v2] c++: Instantiate less when evaluating __is_convertible

On Mon, Sep 26, 2022 at 11:51:30AM -0400, Patrick Palka wrote: > On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: > > > Jon reported that evaluating __is_convertible in this test leads to > > instantiating char_traits::eq, which is invalid (because we > > are

[PATCH] c++: Instantiate less when evaluating __is_convertible

Jon reported that evaluating __is_convertible in this test leads to instantiating char_traits::eq, which is invalid (because we are trying to call a member function on a char) and so we fail to compile the test. __is_convertible doesn't and shouldn't need to instantiate so much, so let's limit it

[PATCH] c++: P2513R4, char8_t Compatibility and Portability Fix [PR106656]

P0482R6, which added char8_t, didn't allow const char arr[] = u8"howdy"; because it said "Declarations of arrays of char may currently be initialized with UTF-8 string literals. Under this proposal, such initializations would become ill-formed." This caused too many issues, so P2513R4 alleviat

[PATCH] c++: Don't quote nothrow in diagnostic

In Jason noticed that we quote "nothrow" in diagnostics even though it's not a keyword in C++. Just removing the quotes didn't work because then -Wformat-diag complains, so this patch replaces it with "no-throw". Bootstrapped/

Re: [PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

On Fri, Sep 23, 2022 at 05:34:21PM +0100, Jonathan Wakely wrote: > On Fri, 23 Sept 2022 at 15:43, Jonathan Wakely wrote: > > > > On Fri, 23 Sept 2022 at 15:34, Marek Polacek wrote: > > > > > > On Thu, Sep 22, 2022 at 06:14:44PM -0400, Jason Merrill wrote: > &

Re: [PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

On Fri, Sep 23, 2022 at 11:54:53AM -0400, Jason Merrill wrote: > On 9/23/22 10:34, Marek Polacek wrote: > > On Thu, Sep 22, 2022 at 06:14:44PM -0400, Jason Merrill wrote: > > > On 9/22/22 09:39, Marek Polacek wrote: > > > > To improve compile times, the C++ librar

Re: [PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

On Fri, Sep 23, 2022 at 03:40:23PM +0100, Jonathan Wakely wrote: > On Thu, 22 Sept 2022 at 23:14, Jason Merrill wrote: > > On 9/22/22 09:39, Marek Polacek wrote: > > > This patch doesn't make libstdc++ use the new built-ins, but I had to > > > rename a class otherwi

Re: [PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

On Thu, Sep 22, 2022 at 06:14:44PM -0400, Jason Merrill wrote: > On 9/22/22 09:39, Marek Polacek wrote: > > To improve compile times, the C++ library could use compiler built-ins > > rather than implementing std::is_convertible (and _nothrow) as class > > templates. This pat

[PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

To improve compile times, the C++ library could use compiler built-ins rather than implementing std::is_convertible (and _nothrow) as class templates. This patch adds the built-ins. We already have __is_constructible and __is_assignable, and the nothrow forms of those. Microsoft (and clang, for

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