Re: [PATCH] c++: Fix P0846 (ADL and function templates) in template [PR97010]

Ping. On Fri, Sep 18, 2020 at 04:05:16PM -0400, Marek Polacek via Gcc-patches wrote: > Ping. > > On Thu, Sep 10, 2020 at 06:15:24PM -0400, Marek Polacek via Gcc-patches wrote: > > To quickly recap, P0846 says that a name is also considered to refer to > > a template if it

Re: [PATCH v3] c++: Implement -Wrange-loop-construct [PR94695]

On Mon, Sep 28, 2020 at 03:05:55PM -0400, Jason Merrill via Gcc-patches wrote: > On 9/28/20 12:30 PM, Marek Polacek wrote: > > On Sat, Sep 26, 2020 at 01:22:41AM -0400, Jason Merrill wrote: > > > > +bool > > > > +ref_conv_binds_directly_p (tree type, tree expr) > > > > +{ > > > > + gcc_assert (TYP

[PATCH] c++: Verify 'this' of NS member functions in constexpr [PR97230]

This PR points out that when we're invoking a non-static member function on a null instance during constant evaluation, we should reject. cxx_eval_call_expression calls cxx_bind_parameters_in_call which evaluates function arguments, but it won't detect problems like these. Well, ok, so use integer

[PATCH] c++: Fix printing of C++20 template parameter object [PR97014]

No one is interested in the mangled name of the C++20 template parameter object for a class NTTP. So instead of printing required for the satisfaction of ‘positive’ [with T = X<::_ZTAXtl5ratioLin1ELi2EEE>] let's print required for the satisfaction of ‘positive’ [with T = X<{-1, 2}>] I don

[pushed] c++: Fix typo in NON_UNION_CLASS_TYPE_P.

Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * cp-tree.h (NON_UNION_CLASS_TYPE_P): Fix typo in a comment. --- gcc/cp/cp-tree.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index c9ad75117ad..c7b5e7915ae 100644

[PATCH] c++: typename in out-of-class member function definitions [PR97297]

I was notified that our P0634R3 (Down with typename) implementation has a flaw: when we have an out-of-class member function definition, we still required 'typename' for its parameters. For example here: template struct S { int simple(T::type); }; template int S::simple(/* typename

Re: [PATCH v2] c++: Verify 'this' of NS member functions in constexpr [PR97230]

On Tue, Oct 06, 2020 at 01:06:37AM -0400, Jason Merrill via Gcc-patches wrote: > On 10/1/20 1:08 PM, Marek Polacek wrote: > > @@ -2496,8 +2502,72 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, > > tree t, > > new_obj = NULL_TREE; > > } > > } > > + /* Verify that the obj

Re: [PATCH v3] c, c++: Implement -Wsizeof-array-div [PR91741]

Ping for the C parts. On Mon, Sep 28, 2020 at 02:15:41PM -0400, Marek Polacek via Gcc-patches wrote: > On Tue, Sep 22, 2020 at 04:07:41PM -0400, Jason Merrill wrote: > > On 9/22/20 1:29 PM, Marek Polacek wrote: > > > Ping. > > > > The C++ change is OK. > > P

[PATCH] c: Stray inform note with -Waddress [PR106947]

A trivial fix for maybe_warn_for_null_address where we print an inform note without first checking the return value of a warning call. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12? PR c/106947 gcc/c/ChangeLog: * c-typeck.cc (maybe_warn_for_null_address): Don't

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

On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote: > On 9/3/22 12:42, Marek Polacek wrote: > > This patch implements https://wg21.link/p2266, which, once again, > > changes the implicit move rules. Here's a brief summary of various > > changes in this area: > > > > r125211: Introduced

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

On Mon, Sep 12, 2022 at 04:27:27PM -0400, Jason Merrill wrote: > On 9/8/22 18:54, Marek Polacek wrote: > > On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote: > > > On 9/3/22 12:42, Marek Polacek wrote: > > > > This patch implements https://wg21.link/p2266, which, once again, > > > > cha

[PATCH] c++: ICE-on-invalid with designated initializer [PR106983]

We ICE in the code added in r12-7117: type_build_dtor_call gets the error_mark_node because the type of 'prev' wasn't declared. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/106983 gcc/cp/ChangeLog: * typeck2.cc (split_nonconstant_init_1): Check TYPE_P. gc

[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

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 patch adds the built-ins.

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 otherwise its name would clash with the

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++ library could use compiler built-ins > >

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: > > > > On 9/22/22 09:39, Marek Polacek wro

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

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

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 > > are trying to call a member function

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

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

[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 discards qualifiers". That > > > > looks bogus to me, I think I'l

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 for the named return value optimizatio

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

[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 in an ICE, like here. > >

[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++: 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&, > > Derived)); > > > > doesn't pass

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 > > > > > > > > struct Base {}; > > > > struc

[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:29PM -0400, Jason Merrill wrote: > > > > > On

[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 an attribute, we ought to use > > > > get_attribut

[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:44AM -0400, Jason Merrill wrote: > > > > > On

[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:24AM -0400, Jason Merrill wrote: > > > > > On

[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:40PM -0400, Jason Merrill wrote: > > > > > On

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:41PM -0400, Jason Merrill wrote: > > > > > On

[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:34PM -0400, Jason Merrill wrote: > > > > > On

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

[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

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 v2] c++: ->template and implicit typedef [PR104608]

On Mon, Feb 28, 2022 at 12:31:37PM -0400, Jason Merrill wrote: > On 2/22/22 17:46, Marek Polacek wrote: > > Here we have a forward declaration of Parameter for which we create > > an implicit typedef, which is a TYPE_DECL. Then, when looking it up > > at template definition time, cp_parser_templat

[PATCH] c++: Attribute deprecated/unavailable divergence

Attributes deprecated and unavailable are largely the same, except that the former produces a warning whereas the latter produces an error. So is_late_template_attribute should treat them the same. Confirmed by Iain that this divergence is not intentional:

[PATCH] c++: Don't allow type-constraint auto(x) [PR104752]

104752 points out that template concept C = true; auto y = C auto(1); is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type conversion, T is the specified type, which shall be auto." which doesn't allow type-constraint auto. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok fo

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

On Fri, Feb 25, 2022 at 12:04:32AM +, Joseph Myers wrote: > On Thu, 24 Feb 2022, Marek Polacek via Gcc-patches wrote: > > > gmp/mpfr/mpc/isl are DSOs I believe and therefore always PIC. > > They are *not* DSOs when built in-tree (see the use of --disable-shared in >

[PATCH] rtl: ICE with thread_local and inline asm [PR104777]

In r270550, Jakub fixed classify_insn to handle asm goto: if the asm can jump to a label, the insn should be a JUMP_INSN. However, as the following testcase shows, non-null ASM_OPERANDS_LABEL_VEC doesn't guarantee that the rtx has any actual labels it can branch to. Here, the rtvec has 0 elements

Re: [PATCH] rtl: ICE with thread_local and inline asm [PR104777]

On Mon, Mar 07, 2022 at 07:19:09PM -0600, Segher Boessenkool wrote: > On Mon, Mar 07, 2022 at 07:03:17PM -0500, Marek Polacek via Gcc-patches wrote: > > In r270550, Jakub fixed classify_insn to handle asm goto: if the asm can > > jump to a label, the insn should be a JUMP_INSN. &

Re: [PATCH] rtl: ICE with thread_local and inline asm [PR104777]

On Tue, Mar 08, 2022 at 09:14:56AM -0600, Segher Boessenkool wrote: > Hi! > > On Tue, Mar 08, 2022 at 10:08:25AM -0500, Marek Polacek wrote: > > On Mon, Mar 07, 2022 at 07:19:09PM -0600, Segher Boessenkool wrote: > > > On Mon, Mar 07, 2022 at 07:03:17PM -0500, Marek

Re: [PATCH] rtl: ICE with thread_local and inline asm [PR104777]

On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote: > On Tue, Mar 08, 2022 at 10:25:45AM -0500, Marek Polacek wrote: > > On Tue, Mar 08, 2022 at 09:14:56AM -0600, Segher Boessenkool wrote: > > > On Tue, Mar 08, 2022 at 10:08:25AM -0500, Marek Polacek wrote: > > > > ...I don't see th

Re: [PATCH] rtl: ICE with thread_local and inline asm [PR104777]

On Tue, Mar 08, 2022 at 05:12:43PM +0100, Jakub Jelinek wrote: > On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote: > > > But like I said above, even if we didn't copy these XVECLEN 0 rtvecs, > > > the crash would not go away. > > > > An rtvec should never have length 0. Look at

[PATCH v2] rtl: ICE with thread_local and inline asm [PR104777]

On Tue, Mar 08, 2022 at 10:24:50AM -0600, Segher Boessenkool wrote: > On Tue, Mar 08, 2022 at 05:12:43PM +0100, Jakub Jelinek wrote: > > On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote: > > > > But like I said above, even if we didn't copy these XVECLEN 0 rtvecs, > > > > the cras

[PATCH] c++: Wrong error with alias template in class tmpl [PR104108]

In r10-6329 I tried to optimize the number of calls to v_d_e_p in convert_nontype_argument by remembering whether the expression was value-dependent in a bool flag. I did that wrongly assuming that its value-dependence will not be changed by build_converted_constant_expr. This testcase shows that

[PATCH v2] c++: Don't allow type-constraint auto(x) [PR104752]

On Tue, Mar 08, 2022 at 02:47:42PM -0500, Jason Merrill wrote: > On 3/2/22 14:31, Marek Polacek wrote: > > 104752 points out that > > > >template > >concept C = true; > >auto y = C auto(1); > > > > is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type > > conversion, > >

[PATCH] c++: ICE with operator delete [PR104846]

This is an ICE-on-invalid with "auto operator delete[] (void *)" whose return type must be void. The return type is checked in coerce_delete_type but we never got there in this test, because we took the wrong path in grokdeclarator, set type to error_mark_node, ended up creating a FIELD_DECL with

[PATCH] c++: ICE with template code in constexpr [PR104284]

Since r9-6073 cxx_eval_store_expression preevaluates the value to be stored, and that revealed a crash where a template code (here, code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. It happens because we're performing build_vec_init while processing a template, which calls get_temp_regvar which creat

Re: [PATCH] c++: ICE with template code in constexpr [PR104284]

On Thu, Mar 10, 2022 at 05:04:59PM -0500, Marek Polacek via Gcc-patches wrote: > Since r9-6073 cxx_eval_store_expression preevaluates the value to > be stored, and that revealed a crash where a template code (here, > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. > > It happen

Re: [PATCH] gcc: add --enable-systemtap switch [PR61257]

On Mon, Mar 14, 2022 at 01:48:21PM +0100, David Seifert via Gcc-patches wrote: > Bug: https://bugs.gentoo.org/654748 > > gcc/configure.ac > * Add --enable-systemtap switch to explicitly allow for > disabling systemtap even if the target libc supports it. > --- > gcc/configure.ac |

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

It was high time I updated our C++ DR table. Pushed. --- htdocs/projects/cxx-dr-status.html | 153 +++-- 1 file changed, 122 insertions(+), 31 deletions(-) diff --git a/htdocs/projects/cxx-dr-status.html b/htdocs/projects/cxx-dr-status.html index b49a97f2..63ec6d51 1006

[PATCH] c++: alias template and empty parameter packs [PR104008]

Zero-length pack expansions are treated as if no list were provided at all, that is, with template struct S { }; template void g() { S...>; } g will result in S<>. In the following test we have something similar: template using IsOneOf = disjunction...>; and then we have "IsOn

Re: [PATCH v2] middle-end/104854: Limit strncmp overread warnings

On Wed, Mar 16, 2022 at 06:54:51AM +0530, Siddhesh Poyarekar wrote: > On 16/03/2022 02:06, Martin Sebor wrote: > > The intended use of the strncmp bound is to limit the comparison to > > at most the size of the arrays or (in a subset of cases) the length > > of an initial substring. Providing an ar

[PATCH v2] c++: ICE with template code in constexpr [PR104284]

On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote: > On 3/10/22 18:04, Marek Polacek wrote: > > Since r9-6073 cxx_eval_store_expression preevaluates the value to > > be stored, and that revealed a crash where a template code (here, > > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. > >

[PATCH] c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]

This patch fixes two kinds of wrong -Wmissing-field-initializers warnings. Our docs say that this warning "does not warn about designated initializers", but we give a warning for 1) the array case: struct S { struct N { int a; int b; } c[1]; } d = { .c[0].a = 1, .

Re: [PATCH] c++: Fall through for arrays of T vs T cv [PR104996]

On Tue, Mar 22, 2022 at 08:39:21PM +, Ed Catmur wrote: > If two arrays do not have the exact same element type including > qualification, this could be e.g. f(int (&&)[]) vs. f(int const (&)[]), which > can still be distinguished by the lvalue-rvalue tiebreaker. > > By tightening this branch

[PATCH] c++: FIX_TRUNC_EXPR in tsubst [PR102990]

This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build where it hits gcc_unreachable (). The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it was introduced in r181478, but it did the wrong thing, whereupon it was turned into gcc_unreachable () in r258821 (see this t

Re: [PATCH] c++: FIX_TRUNC_EXPR in tsubst [PR102990]

On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote: > On 3/22/22 19:55, Marek Polacek wrote: > > This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build > > where it hits gcc_unreachable (). > > > > The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it > > w

[PATCH] c, c++: alignas and alignof void [PR104944]

I started looking into this PR because in GCC 4.9 we were able to detect the invalid struct alignas(void) S{}; but I broke it in r210262. It's ill-formed code in C++: [dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has the same effect as alignas(alignof(type-id))", and [exp

[PATCH v2] c++: FIX_TRUNC_EXPR in tsubst [PR102990]

On Thu, Mar 24, 2022 at 09:32:19AM -0400, Jason Merrill wrote: > On 3/23/22 19:26, Marek Polacek wrote: > > On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote: > > > On 3/22/22 19:55, Marek Polacek wrote: > > > > This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build > >

[PATCH v2] c++: alignas and alignof void [PR104944]

On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote: > On 3/24/22 11:49, Marek Polacek wrote: > > I started looking into this PR because in GCC 4.9 we were able to > > detect the invalid > > > >struct alignas(void) S{}; > > > > but I broke it in r210262. > > > > It's ill-formed cod

[PATCH v3] c++: ICE with template code in constexpr [PR104284]

On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote: > On 3/18/22 17:55, Marek Polacek wrote: > > On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote: > > > On 3/10/22 18:04, Marek Polacek wrote: > > > > Since r9-6073 cxx_eval_store_expression preevaluates the value to > > > > b

[PATCH v3] c++: alignas and alignof void [PR104944]

On Thu, Mar 24, 2022 at 05:12:12PM -0400, Jason Merrill wrote: > On 3/24/22 15:56, Marek Polacek wrote: > > On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote: > > > On 3/24/22 11:49, Marek Polacek wrote: > > > > I started looking into this PR because in GCC 4.9 we were able to > > > > d

Re: [PATCH v3] c++: alignas and alignof void [PR104944]

On Fri, Mar 25, 2022 at 09:36:10AM -0400, Jason Merrill wrote: > On 3/24/22 18:43, Marek Polacek wrote: > > On Thu, Mar 24, 2022 at 05:12:12PM -0400, Jason Merrill wrote: > > > On 3/24/22 15:56, Marek Polacek wrote: > > > > On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote: > > > > > On

Re: [PATCH] c++: diagnosing if-stmt with non-constant branches [PR105050]

On Fri, Mar 25, 2022 at 12:07:31PM -0400, Patrick Palka via Gcc-patches wrote: > When an if-stmt is deemed non-constant because both of its branches are > non-constant, we issue a rather generic error which, given that it points > to the 'if' token, misleadingly suggests the condition is at fault:

[PATCH] c++: ICE with aggregate assignment and DMI [PR104583]

The attached 93280 test no longer ICEs but looks like it was never added to the testsuite. The 104583 test, modified so that it closely resembles 93280, still ICEs. The problem is that in 104583 we have a value-init from {} (the line A a{};), so this code in convert_like_internal 7960 /

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

Hi, On Sun, Mar 27, 2022 at 06:25:16PM -0300, Alexandre Oliva via Gcc-patches wrote: > Hello, Marek, > > The patch looks good to me, and I'd have no trouble approving it if we > were in stage1. Since we aren't, I'd prefer if we waited for another > build system maintainer to give it a look, if i

[PATCH] gimple: Wrong -Wimplicit-fallthrough with if(1) [PR103597]

This patch fixes a wrong -Wimplicit-fallthrough warning for case 0: if (1) // wrong may fallthrough return 0; case 1: which in .gimple looks like : // case 0 if (1 != 0) goto ; else goto ; : D.1987 = 0; // predicted unlikely by early return (on trees) p

[PATCH] c-family: ICE with -Wconversion and A ?: B [PR101030]

This patch fixes a crash in conversion_warning on a null expression. It is null because the testcase uses the GNU A ?: B extension. We could also use op0 instead of op1 in this case, but it doesn't seem to be necessary. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/

Re: [PATCH] c-family: ICE with -Wconversion and A ?: B [PR101030]

On Tue, Mar 29, 2022 at 04:53:21PM -0400, Marek Polacek via Gcc-patches wrote: > This patch fixes a crash in conversion_warning on a null expression. > It is null because the testcase uses the GNU A ?: B extension. We > could also use op0 instead of op1 in this case, but it doesn'

Re: [PATCH] c++: ICE with aggregate assignment and DMI [PR104583]

On Tue, Mar 29, 2022 at 10:19:47PM -0400, Jason Merrill wrote: > On 3/25/22 18:16, Marek Polacek wrote: > > The attached 93280 test no longer ICEs but looks like it was never added to > > the > > testsuite. The 104583 test, modified so that it closely resembles 93280, > > still > > ICEs. > > >

Re: [PATCH] c-family: ICE with -Wconversion and A ?: B [PR101030]

On Tue, Mar 29, 2022 at 10:21:47PM -0400, Jason Merrill wrote: > On 3/29/22 16:53, Marek Polacek wrote: > > This patch fixes a crash in conversion_warning on a null expression. > > It is null because the testcase uses the GNU A ?: B extension. We > > could also use op0 instead of op1 in this case,

[PATCH] c-family: Tweak -Woverflow diagnostic

When g++ emits warning: overflow in conversion from 'int' to 'char' changes value from '300' to '','' for code like "char c = 300;" it might raise a few eyebrows. With this warning we're not interested in the ASCII representation of the char, only the numerical value, so convert constants of ty

[PATCH] c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]

Attribute format takes three arguments: archetype, string-index, and first-to-check. The last two specify the position in the function parameter list. r63030 clarified that "Since non-static C++ methods have an implicit this argument, the arguments of such methods should be counted from two, not

Re: -Wformat-overflow handling for %b and %B directives in C2X standard

On Sat, Apr 02, 2022 at 12:19:47AM +0500, Frolov Daniil via Gcc-patches wrote: > Hello, I've noticed that -Wformat-overflow doesn't handle %b and %B > directives in the sprintf function. I've added a relevant issue in bugzilla > (bug #105129). > I attach a patch with a possible solution to the lett

Re: tolerate cdtors returning this in constexpr

On Wed, Apr 06, 2022 at 04:36:49PM -0300, Alexandre Oliva via Gcc-patches wrote: > > On targets that return this from cdtors, cxx_eval_call_expression may > flag flowing off the end of a dtor. That's preempted for ctors, and > avoided entirely when dtors return void, but when they return this, >

Re: [PATCH] c: Error on va_arg with function type [PR105149]

On Thu, Apr 07, 2022 at 05:52:53PM +0200, Jakub Jelinek wrote: > Hi! > > In the PR Joseph said that the C standard for va_arg talks about > pointers to object type and as a function type is not object type, > it is invalid. > > The following patch diagnoses it in the FE, instead of ICEing later o

Re: [PATCH] c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]

On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote: > On 4/1/22 15:14, Marek Polacek wrote: > > Attribute format takes three arguments: archetype, string-index, and > > first-to-check. The last two specify the position in the function > > parameter list. r63030 clarified that "Since no

Re: [PATCH] c-family: Initialize ridpointers for __int128 etc. [PR105186]

On Fri, Apr 08, 2022 at 09:29:52AM +0200, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs with C++ and is incorrectly rejected with C. > The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD > and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP > d

Re: -Wformat-overflow handling for %b and %B directives in C2X standard

On Thu, Apr 07, 2022 at 02:10:48AM +0500, Frolov Daniil wrote: > Hello! Thanks for your feedback. I've tried to take into account your > comments. New patch applied to the letter. Thanks. > The only thing I have not removed is the check_std_c2x () function. From my > point of view -Wformat-overf

Re: [PATCH] c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]

On Mon, Apr 11, 2022 at 04:39:22PM -0400, Jason Merrill wrote: > On 4/8/22 15:21, Marek Polacek wrote: > > On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote: > > > On 4/1/22 15:14, Marek Polacek wrote: > > > > Attribute format takes three arguments: archetype, string-index, and > > > >

[PATCH] c++: ambiguous call not diagnosed after DR2352 [PR97296]

DR 2352 changed the definitions of reference-related (so that it uses "similar type" instead of "same type") and of reference-compatible (use a standard conversion sequence). That means that reference-related is now more broad, which means that we will be binding more things directly. The origina

[PATCH v2] c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]

On Tue, Apr 12, 2022 at 04:01:14PM -0400, Jason Merrill wrote: > On 4/12/22 14:38, Marek Polacek wrote: > > On Mon, Apr 11, 2022 at 04:39:22PM -0400, Jason Merrill wrote: > > > On 4/8/22 15:21, Marek Polacek wrote: > > > > On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote: > > > > > On

[PATCH] c++: wrong error with variadic concept [PR105268]

Here we issue a wrong error for the template>> void g(); line in the testcase. I surmise that's because we mistakenly parse C_many as a placeholder-type-specifier, and things go wrong from there. We are in a default argument so we should reject parsing C_many as a placeholder-type-specifier,

[PATCH] c++: wrong error with constexpr COMPOUND_EXPR [PR105321]

Here we issue a bogus error for the first assert in the test. Therein we have = (void) (VIEW_CONVERT_EXPR(yes) || handle_error ());, VIEW_CONVERT_EXPR(value); which has a COMPOUND_EXPR, so we get to cxx_eval_constant_expression . The problem here is that we call 7044 /* Check tha

[PATCH v2] c++: wrong error with constexpr COMPOUND_EXPR [PR105321]

On Thu, Apr 21, 2022 at 08:56:23AM -0400, Jason Merrill wrote: > On 4/20/22 18:40, Marek Polacek wrote: > > Here we issue a bogus error for the first assert in the test. Therein > > we have > > > > = (void) (VIEW_CONVERT_EXPR(yes) || handle_error ());, > > VIEW_CONVERT_EXPR(value); > > > > whi

Re: [PATCH v2] c++: wrong error with constexpr COMPOUND_EXPR [PR105321]

On Thu, Apr 21, 2022 at 04:22:03PM +0200, Jakub Jelinek wrote: > On Thu, Apr 21, 2022 at 09:20:48AM -0400, Marek Polacek via Gcc-patches wrote: > > --- a/gcc/cp/constexpr.cc > > +++ b/gcc/cp/constexpr.cc > > @@ -4566,19 +4566,18 @@ cxx_eval_bit_cast (const constexpr_ctx *c

[PATCH v3] c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]

On Thu, Apr 14, 2022 at 11:55:10PM -0400, Jason Merrill wrote: > On 4/13/22 19:17, Marek Polacek wrote: > > -static tree > > -get_constant (const_tree fntype, const_tree atname, tree expr, int argno, > > + N.B. This function modifies EXPR. */ > > + > > +static bool > > +get_constant (const_tree

Re: [PATCH] c++: ICE with noexcept and canonical types [PR101715]

On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote: > On 1/14/22 19:22, Marek Polacek wrote: > > This is a "canonical types differ for identical types" ICE, which started > > with r11-4682. It's a bit tricky to explain. Consider: > > > >template struct S { > > S bar() noexce

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