On 5/8/24 01:04, Ken Matsui wrote:
Fixed the reference_wrapper case. I used non_ref_datum_type to avoid
potentially multiple build_trait_object calls.
-- >8 --
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
On 5/3/24 12:35, Jakub Jelinek wrote:
Hi!
The following patch imeplements the C++26 P2893R3 - Variadic friends
paper. The paper allows for the friend type declarations to specify
more than one friend type specifier and allows to specify ... at
the end of each. The patch doesn't introduce
On 5/7/24 01:35, Nathaniel Shead wrote:
On Thu, May 02, 2024 at 01:53:44PM -0400, Jason Merrill wrote:
On 5/2/24 10:40, Patrick Palka wrote:
On Thu, 2 May 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14.2?
Another alternative would
On 5/3/24 16:52, Ken Matsui wrote:
Fixed datum reference problem. Ok for trunk?
-- >8 --
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.
On 5/5/24 14:14, Andi Kleen wrote:
This patch implements a clang compatible [[musttail]] attribute for
returns.
Thanks.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with
On 5/6/24 18:53, Patrick Palka wrote:
On Mon, 6 May 2024, Jason Merrill wrote:
On 5/3/24 07:17, Nathaniel Shead wrote:
On Thu, May 02, 2024 at 02:05:38PM -0400, Jason Merrill wrote:
On 5/1/24 21:34, Nathaniel Shead wrote:
On Thu, May 02, 2024 at 12:15:44AM +1000, Nathaniel Shead wrote
On 5/3/24 11:26, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
OK.
-- >8 --
The tf_norm flag controlling whether to build diagnostic information
during constraint normalization doesn't need to be a global tsubst flag,
and is confusingly
On 5/3/24 07:17, Nathaniel Shead wrote:
On Thu, May 02, 2024 at 02:05:38PM -0400, Jason Merrill wrote:
On 5/1/24 21:34, Nathaniel Shead wrote:
On Thu, May 02, 2024 at 12:15:44AM +1000, Nathaniel Shead wrote:
On Wed, May 01, 2024 at 09:57:38AM -0400, Patrick Palka wrote:
On Wed, 1 May 2024
On 5/6/24 02:32, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In some circumstances, unions can also have an __as_base type;
Hmm, even though unions can't be bases I guess that is needed for
something like
union U {
int i;
private:
+ * pt.c (build_deduction_guide): Check for error_mark_node
+ result from tsubst_arg_types.
+
2024-05-03 Jason Merrill
PR c++/114935
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index d68d688016d..da5d9b8a665 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -30018,6 +30018,8
On 5/6/24 09:25, Ken Matsui wrote:
On Thu, Mar 14, 2024 at 12:57 AM Ken Matsui wrote:
On Fri, Mar 8, 2024 at 8:42 AM Patrick Palka wrote:
On Wed, 28 Feb 2024, Ken Matsui wrote:
This patch implements a --num-commits (-n) flag for shorthand for
the range of hash~N..hash commits.
Ping.
Tested x86_64-pc-linux-gnu, applying to trunk and 14.
-- 8< --
When we initialize an array of a type with a non-trivial destructor, such as
the backing array for the initializer_list, we have a cleanup to destroy any
constructed elements if a later constructor throws. When the array being
On 5/2/24 23:25, Ken Matsui wrote:
Addressed Jason's review comments. Ok for trunk?
-- >8 --
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.
On 5/2/24 16:47, Ken Matsui wrote:
On Thu, May 2, 2024 at 1:38 PM Jason Merrill wrote:
On 5/2/24 16:12, Ken Matsui wrote:
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr
On 5/2/24 22:09, Ken Matsui wrote:
This patch implements built-in trait for std::is_invocable.
Looks like this doesn't address my review comments on v18, only Marek's?
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr): Handle
On 5/2/24 16:12, Ken Matsui wrote:
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.
* semantics.cc (trait_expr_value): Likewise.
On 5/2/24 14:42, Ken Matsui wrote:
This patch implements built-in trait for std::is_pointer.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_POINTER.
* semantics.cc (trait_expr_value): Likewise.
On 5/2/24 14:42, Ken Matsui wrote:
This patch implements built-in trait for std::is_const.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_const.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
* semantics.cc (trait_expr_value): Likewise.
On 5/2/24 14:42, Ken Matsui wrote:
This patch implements built-in trait for std::is_volatile.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_volatile.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_VOLATILE.
* semantics.cc (trait_expr_value): Likewise.
On 5/2/24 15:36, Iain Sandoe wrote:
On 2 May 2024, at 20:30, Ken Matsui wrote:
On Thu, May 2, 2024 at 10:54 AM Marek Polacek wrote:
On Thu, May 02, 2024 at 08:37:53PM +0300, Ville Voutilainen wrote:
On Thu, 2 May 2024 at 20:25, Ken Matsui wrote:
There was some discussion of how to
On 5/2/24 13:49, Patrick Palka wrote:
On Wed, 1 May 2024, Jason Merrill wrote:
On 5/1/24 13:40, Patrick Palka wrote:
On Wed, 1 May 2024, Jason Merrill wrote:
On 5/1/24 12:41, Patrick Palka wrote:
On Fri, 2 Feb 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux, does
On 5/1/24 21:34, Nathaniel Shead wrote:
On Thu, May 02, 2024 at 12:15:44AM +1000, Nathaniel Shead wrote:
On Wed, May 01, 2024 at 09:57:38AM -0400, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and
later
On 5/2/24 10:40, Patrick Palka wrote:
On Thu, 2 May 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14.2?
Another alternative would be to stream such !DECL_NAME temporaries with
a merge key of MK_unique rather than attempting to find the matching
On 5/2/24 12:45, Jason Merrill wrote:
On 5/2/24 12:20, Ken Matsui wrote:
On Thu, May 2, 2024 at 8:34 AM Ken Matsui
wrote:
On Thu, May 2, 2024 at 8:16 AM Patrick Palka wrote:
On Tue, 30 Apr 2024, Jason Merrill wrote:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built
On 5/2/24 12:20, Ken Matsui wrote:
On Thu, May 2, 2024 at 8:34 AM Ken Matsui wrote:
On Thu, May 2, 2024 at 8:16 AM Patrick Palka wrote:
On Tue, 30 Apr 2024, Jason Merrill wrote:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::rank.
__rank seems too
Tested x86_64-pc-linux-gnu, OK for trunk? 14.2?
This two-year-old thread seems relevant:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593410.html
-- 8< --
#pragma target and optimize should also apply to implicitly-generated
functions like static initialization functions and
On 5/2/24 01:19, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Currently we incorrectly retain "in_unbraced_linkage_specification_p"
and "in_unbraced_export_declaration_p" when parsing a (braced)
declaration-seq. This patch ensures
On 5/1/24 13:40, Patrick Palka wrote:
On Wed, 1 May 2024, Jason Merrill wrote:
On 5/1/24 12:41, Patrick Palka wrote:
On Fri, 2 Feb 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux, does this look like
an improvement? This is not a bugfix and barely related
On 4/12/24 13:22, Patrick Palka wrote:
On Fri, 12 Apr 2024, Jason Merrill wrote:
On 3/26/24 09:44, Patrick Palka wrote:
On Thu, 7 Mar 2024, Jason Merrill wrote:
On 1/29/24 17:42, Patrick Palka wrote:
On Mon, 29 Jan 2024, Patrick Palka wrote:
On Fri, 26 Jan 2024, Jason Merrill wrote
On 5/1/24 12:11, Patrick Palka wrote:
On Wed, 1 May 2024, Jason Merrill wrote:
On 5/1/24 08:54, Patrick Palka wrote:
On Thu, 2 May 2024, Nathaniel Shead wrote:
On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:
Bootstrapped
On 5/1/24 12:41, Patrick Palka wrote:
On Fri, 2 Feb 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux, does this look like
an improvement? This is not a bugfix and barely related to the previous
patch, but the previous patch's new use of entering_scope=true motivated
me
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Constructors and destructors use the in-charge parameter to decide whether
they're responsible for recursing into virtual bases. Historically all
destructors had this parameter in order to also distinguish the deleting
destructor. But
On 5/1/24 23:33, Jakub Jelinek wrote:
The following patch implements the C++26 P2573R2
= delete("should have a reason"); paper.
I've tried to avoid increasing compile time memory for it when it isn't
used (e.g. by adding a new lang_decl tree member), so the reason is
represented as STRING_CST
On 5/1/24 08:54, Patrick Palka wrote:
On Thu, 2 May 2024, Nathaniel Shead wrote:
On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When calling
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The C++ standard specifies that the functions have const and
non-const overloads, unlike C's single function with const argument and
non-const return. Many systems don't actually implement this, but only add
an overload with non-const
On 5/1/24 08:19, Qing Zhao wrote:
"add_flexible_array_elts_to_size" and "layout_var_decl" to handle
the cases when the DECL is union.
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc
On 5/1/24 03:01, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
Another thought would be to replace xtreme-header.h with so
that we don't need to keep it up-to-date in the future. But this patch just
does the obviously correct thing.
-- >8 --
On 5/1/24 02:59, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
The change in r14-8408 to also emit partial specializations in the
global module fragment caused the regression in the linked PR; this
patch fixes this by restricting
On 5/1/24 07:11, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When calling instantiate_pending_templates at end of parsing, any new
functions that are instantiated from this point have their module
On 5/1/24 04:37, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch implements the changes described in
https://github.com/itanium-cxx-abi/cxx-abi/pull/171.
One restriction that is lifted in the ABI that hasn't been updated here
is that
On 4/30/24 14:49, Qing Zhao wrote:
On Apr 30, 2024, at 15:45, Qing Zhao wrote:
gcc/doc/extend.texi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7b54a241a7bf..cba98c8aadd7 100644
---
On 4/30/24 14:45, Qing Zhao wrote:
On Apr 30, 2024, at 15:27, Jason Merrill wrote:
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago
around 2012
for supporting
On 4/30/24 07:58, Qing Zhao wrote:
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc (add_flexible_array_elts_to_size): Handle the cases
when the DECL is union.
gcc/cp/ChangeLog:
* decl.cc
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_nothrow_invocable.
OK after addressing comments on other traits.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_nothrow_invocable.
* constraint.cc (diagnose_trait_expr): Handle
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::rank.
__rank seems too short, maybe __array_rank?
Actually, it occurs to me that perhaps we should have been adding
__builtin to all of these rather than just __ and the library trait
name. I guess it's too
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::decay.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __decay.
* semantics.cc (finish_trait_type): Handle CPTK_DECAY.
gcc/testsuite/ChangeLog:
* g++.dg/ext/has-builtin-1.C: Test
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_rvalue_reference.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_rvalue_reference.
* semantics.cc (finish_trait_type): Handle
CPTK_ADD_RVALUE_REFERENCE.
gcc/testsuite/ChangeLog:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_lvalue_reference.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_lvalue_reference.
* semantics.cc (finish_trait_type): Handle
CPTK_ADD_LVALUE_REFERENCE.
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::remove_extent.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __remove_extent.
* semantics.cc (finish_trait_type): Handle CPTK_REMOVE_EXTENT.
gcc/testsuite/ChangeLog:
*
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::remove_all_extents.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __remove_all_extents.
* semantics.cc (finish_trait_type): Handle
CPTK_REMOVE_ALL_EXTENTS.
gcc/testsuite/ChangeLog:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_pointer.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_pointer.
* semantics.cc (finish_trait_type): Handle CPTK_ADD_POINTER.
gcc/testsuite/ChangeLog:
*
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_unbounded_array.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_unbounded_array.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_UNBOUNDED_ARRAY.
* semantics.cc
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_pointer.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_POINTER.
* semantics.cc (trait_expr_value): Likewise.
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_volatile.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_volatile.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_VOLATILE.
* semantics.cc (trait_expr_value): Likewise.
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_const.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_const.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
* semantics.cc (trait_expr_value): Likewise.
On 3/15/24 01:15, Ken Matsui wrote:
Added diagnostics for build_invoke.
Ok for 15?
Thanks, just a few tweaks needed. Will you have time to make them? Or
Patrick?
[...]
diff --git a/gcc/cp/method.cc b/gcc/cp/method.cc
index 98c10e6a8b5..2282ce71c06 100644
--- a/gcc/cp/method.cc
+++
On 4/30/24 12:04, Andrew Pinski wrote:
On Tue, Apr 30, 2024 at 11:54 AM Jason Merrill wrote:
On 2/20/24 19:06, Andrew Pinski wrote:
After r7-987-gf17a223de829cb, the access for the elements of a vector type
would lose the qualifiers.
So if we had `constvector[0]`, the type of the element
On 2/20/24 19:06, Andrew Pinski wrote:
After r7-987-gf17a223de829cb, the access for the elements of a vector type
would lose the qualifiers.
So if we had `constvector[0]`, the type of the element of the array would not
have const on it.
This was due to a missing build_qualified_type for the
On 3/4/24 06:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu. This should probably
wait for GCC 15 I suppose, but sending it in now in case there are any
comments.
OK for trunk.
-- >8 --
This clarifies which kinds of declarations may and may not be exported
in
On 4/30/24 00:59, Nathaniel Shead wrote:
On Sun, Apr 14, 2024 at 01:40:18AM +1000, Nathaniel Shead wrote:
On Fri, Apr 12, 2024 at 01:50:47PM -0400, Jason Merrill wrote:
On 4/11/24 20:40, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- &g
On 4/29/24 00:11, Jakub Jelinek wrote:
Hi!
The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.
The paper
On 4/29/24 02:34, Nathaniel Shead wrote:
On Fri, Apr 26, 2024 at 09:16:40PM -0400, Jason Merrill wrote:
On 4/19/24 09:29, Nathaniel Shead wrote:
On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:
On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:
On Mon, 15 Apr 2024
On 4/29/24 06:50, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14 (I guess after 14.1 is released)?
OK for both.
-- >8 --
We need to look through TEMPLATE_DECL like make_friend_class does when
adding to CLASSTYPE_BEFRIENDING_CLASSES.
Otherwise
On 4/29/24 07:52, Marek Polacek wrote:
On Mon, Apr 29, 2024 at 10:28:19AM -0400, Patrick Palka wrote:
Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for
trunk/14.1 after bootstrap+regtest finishes?
LGTM.
Yes, OK.
-- >8 --
We're missing a dependence check for the second
On 4/19/24 09:29, Nathaniel Shead wrote:
On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:
On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:
On Mon, 15 Apr 2024, Nathaniel Shead wrote:
I'm not a huge fan of always streaming 'imported_temploid_friends' for
all
On 4/19/24 09:18, Nathaniel Shead wrote:
On Mon, Apr 15, 2024 at 02:49:35PM +1000, Nathaniel Shead wrote:
I took another look at this patch and have split it into two, one (this
one) to standardise the error messages used and prepare
'module_may_redeclare' for use with temploid friends, and
On 4/23/24 08:52, Jakub Jelinek wrote:
On Mon, Apr 15, 2024 at 02:19:36PM +0200, Jakub Jelinek wrote:
They weren't the same, one was trying to evaluate the convert_from_reference
with vc_glvalue, the other evaluates it without that and with vc_prvalue.
Now, I guess the
+ /* Undo
On 4/25/24 07:22, Jakub Jelinek wrote:
On Thu, Apr 25, 2024 at 02:02:32PM +0200, Jakub Jelinek wrote:
I've tried the following patch, but unfortunately that lead to large
number of regressions:
+FAIL: g++.dg/cpp0x/initlist25.C -std=c++17 (test for excess errors)
So the reduced testcase for
On 4/24/24 15:47, Jakub Jelinek wrote:
On Wed, Apr 24, 2024 at 06:39:33PM -0400, Jason Merrill wrote:
--- gcc/cp/decl2.cc.jj 2024-04-23 14:49:41.933186265 +0200
+++ gcc/cp/decl2.cc 2024-04-24 15:17:09.043625729 +0200
@@ -3314,7 +3314,16 @@ tentative_decl_linkage (tree decl
On 4/24/24 09:16, Jakub Jelinek wrote:
On Wed, Apr 24, 2024 at 10:16:05AM +0100, Jonathan Wakely wrote:
That fixes the testcases too, but seems to regress
+FAIL: libstdc++-abi/abi_check
There are explicit instantiation definitions that should instantiate
those types:
On 4/24/24 13:22, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, full bootstrap+regtest in progress,
does this look OK if successful?
-- >8 --
It seems the diagnostic machinery's source line printing respects
the pretty printer prefix, but this is undesirable for the call to
On 4/24/24 05:49, Patrick Palka wrote:
On Tue, 23 Apr 2024, Jason Merrill wrote:
On 4/23/24 11:28, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Is the test being run for multiple standard levels? I'd rather restrict it to
one and keep fully testing GC
On 4/23/24 11:28, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Is the test being run for multiple standard levels? I'd rather restrict
it to one and keep fully testing GC-safety.
-- >8 --
The below testcase uses --param=ggc-min-expand=0 which forces a
On 4/23/24 09:41, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
When merging an imported function template specialization with an
existing one, if the existing one has an undeduced return type and the
imported one's is already deduced, we need to
On 4/21/24 19:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fixes a null dereference issue when decl_specifiers.type is not yet
provided.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_parameter_declaration): Check if
On 4/21/24 19:59, Patrick Palka wrote:
On Sat, 20 Apr 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
A class allocation member function is implicitly 'static' by
[class.free] p3, so cannot have an explicit object parameter.
PR
On 4/22/24 08:42, Jakub Jelinek wrote:
On Wed, Apr 17, 2024 at 09:42:47AM +0200, Jakub Jelinek wrote:
When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors
On 4/22/24 08:54, Jakub Jelinek wrote:
Hi!
The following testcase is rejected with
error: inlining failed in call to 'always_inline' '...': call is unlikely and
code size would grow
errors. The problem is that starting with the r14-2149 change
we try to copy most of the attributes from the
On 4/22/24 15:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/13/12?
OK with a rationale comment.
-- >8 --
The object/offset canonicalization performed in cxx_fold_indirect_ref
is undesirable for union member accesses because it loses
On 3/14/24 17:26, Marek Polacek wrote:
In the following patch, I'm taking a different tack. I believe
we ought to use TARGET_EXPR_ELIDING_P. The gimplify_arg bit I'm
talking about below is this:
/* Also strip a TARGET_EXPR that would force an extra copy. */
if (TREE_CODE
On 3/26/24 09:24, Nathaniel Shead wrote:
I wonder if more generally we need to be doing more work when importing
definitions from header units especially to handle all the work that
'make_rtl_for_nonlocal_decl' and 'rest_of_decl_compilation' would have
been performing.
Can we just call those
On 3/26/24 09:44, Patrick Palka wrote:
On Thu, 7 Mar 2024, Jason Merrill wrote:
On 1/29/24 17:42, Patrick Palka wrote:
On Mon, 29 Jan 2024, Patrick Palka wrote:
On Fri, 26 Jan 2024, Jason Merrill wrote:
On 1/26/24 17:11, Jason Merrill wrote:
On 1/26/24 16:52, Jason Merrill wrote:
On 1
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The second testcase in 113141 is a separate issue: we first decide that the
conversion is ill-formed, but then when recalculating the special c_cast_p
handling makes us think it's OK. We don't want that, it should continue to
fall back to
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The original testcase in PR113141 is an instance of CWG1996; the standard
fails to consider conversion functions when initializing a reference
directly from an initializer-list of one element, but then does consider
them when initializing a
On 4/12/24 14:39, Patrick Palka wrote:
On Fri, 12 Apr 2024, Jason Merrill wrote:
On 4/12/24 13:48, Patrick Palka wrote:
On Fri, 12 Apr 2024, Jason Merrill wrote:
On 4/12/24 10:35, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 4/10/24 14:48, Patrick Palka wrote
On 3/8/24 03:56, Jakub Jelinek wrote:
Hi!
My r9-6136 changes to make a copy of constexpr function bodies before
genericization modifies it broke the constant evaluation of non-POD
arguments passed by value.
In the callers such arguments are passed as reference to usually a
TARGET_EXPR, but on
On 3/22/24 04:08, Jakub Jelinek wrote:
Hi!
The middle-end warns about the ANNOTATE_EXPR added for while/for loops
if they declare a var inside of the loop condition.
This is because the assumption is that ANNOTATE_EXPR argument is used
immediately in a COND_EXPR (later GIMPLE_COND), but
On 4/12/24 13:48, Patrick Palka wrote:
On Fri, 12 Apr 2024, Jason Merrill wrote:
On 4/12/24 10:35, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 4/10/24 14:48, Patrick Palka wrote:
On Tue, 9 Apr 2024, Jason Merrill wrote:
On 3/5/24 10:31, Patrick Palka wrote:
On Tue
On 4/11/24 20:41, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
While working on some other fixes I noticed that the partition handling
code used the wrong flag to propagate OVL_HIDDEN_P on exported bindings
from partitions. This patch
On 4/11/24 20:40, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The modules code currently neglects to set OVL_USING_P on the dependency
created for a using-decl, which causes it not to remember that the
OVL_EXPORT_P flag had been set on it
On 4/11/24 20:40, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
A typo in r14-6978 made us emit too many things. This ensures that we
don't emit using-declarations from the GMF that we don't need to.
PR c++/114600
On 4/12/24 09:12, Jakub Jelinek wrote:
Hi!
I had another look at this P1 PR today.
You said in the "c++: fix in-charge parm in constexpr" mail back in December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors there isn't actually
a need for an
On 4/12/24 09:47, Patrick Palka wrote:
The original PR114393 testcase is unfortunately still not accepted after
r14-9938-g081c1e93d56d35 due to return type deduction confusion when a
lambda-expr is used as a default template argument.
The below reduced testcase demonstrates the bug. Here,
On 4/12/24 10:35, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 4/10/24 14:48, Patrick Palka wrote:
On Tue, 9 Apr 2024, Jason Merrill wrote:
On 3/5/24 10:31, Patrick Palka wrote:
On Tue, 27 Feb 2024, Patrick Palka wrote:
Subject: [PATCH] c++/modules: local type merging
On 4/10/24 20:00, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 4/10/24 17:39, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 3/12/24 10:51, Patrick Palka wrote:
On Tue, 12 Mar 2024, Patrick Palka wrote:
On Tue, 12 Mar 2024, Jason Merrill wrote
On 4/10/24 14:48, Patrick Palka wrote:
On Tue, 9 Apr 2024, Jason Merrill wrote:
On 3/5/24 10:31, Patrick Palka wrote:
On Tue, 27 Feb 2024, Patrick Palka wrote:
Subject: [PATCH] c++/modules: local type merging [PR99426]
One known missing piece in the modules implementation is merging
On 4/10/24 17:39, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 3/12/24 10:51, Patrick Palka wrote:
On Tue, 12 Mar 2024, Patrick Palka wrote:
On Tue, 12 Mar 2024, Jason Merrill wrote:
On 3/11/24 12:53, Patrick Palka wrote:
r13-6452-g341e6cd8d603a3 made build_extra_args
On 4/10/24 13:10, Richard Biener wrote:
On Wed, 10 Apr 2024, Jakub Jelinek wrote:
On Wed, Apr 10, 2024 at 06:43:02PM +0200, Richard Biener wrote:
The following fixes a mismatch in COMPOUND_EXPR handling in
tsubst_expr vs tsubst_stmt where the latter allows a stmt in
operand zero but the
On 4/10/24 09:06, Jakub Jelinek wrote:
Hi!
The following testcase ICEs starting with the r14-4229 PR111529
change which moved ANNOTATE_EXPR handling from tsubst_expr to
tsubst_copy_and_build.
ANNOTATE_EXPR is only allowed in the IL to wrap a loop condition,
and the loop condition of while/for
101 - 200 of 11256 matches
Mail list logo
