On 8/21/24 3:10 PM, Iain Sandoe wrote:
This splits out the building of the allocation and deallocation expressions
and runs them early in the ramp build, so that we can exit if they are not
usable, before we start building the ramp body.
Likewise move checks for other required resources to the b
On 8/22/24 7:29 AM, Iain Sandoe wrote:
+ tree fn_return_type = TREE_TYPE (TREE_TYPE (orig));
/* Ramp: */
+ tree stmt = begin_function_body ();
The name "stmt" doesn't suggest to me that it's holding the result of begin_function_body. Maybe
"ramp_fnbody"? Of course, then there's some
On 8/22/24 9:30 AM, Iain Sandoe wrote:
Hi Jason,
+ tree stmt = begin_function_body ();
As in the last patch, "stmt" seems an obscure name for the result of
begin_function_body.
done.
+ /* Avoid the code here attaching a location that makes the debugger jump. */
+ location_t save_inpu
On 8/21/24 3:10 PM, Iain Sandoe wrote:
The responsibility for destroying part of the frame content (promise,
arg copies and the frame itself) transitions from the ramp to the
body of the coroutine once we reach the await_resume () for the
initial suspend.
We added the variable that flags the tra
On 8/21/24 3:10 PM, Iain Sandoe wrote:
Require that the value returned by get_return_object is convertible to
the ramp return. This means that the only time we allow a void
get_return_object, is when the ramp is also a void function.
We diagnose this early to allow us to exit the ramp build if
On 8/21/24 3:10 PM, Iain Sandoe wrote:
We have been requiring the get_return_on_allocation_fail() call to have the
same type as the ramp. This is not intended by the standard, so relax that
to allow anything convertible to the ramp return.
OK.
PR c++/109682
gcc/cp/ChangeLog:
On 8/22/24 11:42 AM, Jason Merrill wrote:
On 8/21/24 3:10 PM, Iain Sandoe wrote:
Require that the value returned by get_return_object is convertible to
the ramp return. This means that the only time we allow a void
get_return_object, is when the ramp is also a void function.
We diagnose this
On 8/21/24 3:10 PM, Iain Sandoe wrote:
[dcl.fct.def.coroutine]/7 says:
The expression promise.get_return_object() is used to initialize the returned
reference or prvalue result object of a call to a coroutine. The call to
get_return_object is sequenced before the call to initial_suspend and is
in
On 8/21/24 3:10 PM, Iain Sandoe wrote:
In the fix for PR95822 (r11-7402) we set throwing_cleanup false in the top
level of the coroutine transform code. However, as the current PR shows,
that is not sufficient.
Any use of cxx_maybe_build_cleanup() can reset the flag, which causes the
check_retu
On 8/21/24 3:10 PM, Iain Sandoe wrote:
In the case that the initial awaiter returns an object, the initial await
can be a target expression and we need to look at its initializer to cast
the await_resume() to void and to wrap in a compoun expression that sets
the initial_await_resume_called flag.
On 8/22/24 4:38 AM, Iain Sandoe wrote:
Hi Jason,
+ if (!glvalue_p (o) && !xvalue_p (o))
+o = build_target_expr_with_type (o, TREE_TYPE (o), tf_warning_or_error);
Maybe get_target_expr instead?
done.
+ o = cp_build_init_expr (loc, e_proxy, convert_from_reference (o));
Why con
On 8/22/24 12:19 PM, Iain Sandoe wrote:
Maybe use iloc_sentinel? It's a bit awkward because it won't set
UNKNOWN_LOCATION, but avoids needing to restore it at the end of the function.
I've used this - with the function start location - but I don't think that
really solves the problem; it needs
On 8/22/24 12:35 PM, Iain Sandoe wrote:
Hi Jason,
Firstly, Arsen has WIP to revise the allocation / deallocation to deal with
coroutine frames that are more aligned than 2 * sizeof (pointer). We will also
be considering Lewis' P2014 (use of the aligned allocator). So this patch is
very much a
On 8/22/24 12:51 PM, Simon Martin wrote:
We currently ICE upon the following invalid code, because we don't check the
number of template parameters in member class template specializations. This
patch fixes the PR by adding such a check.
=== cut here ===
template struct x {
template struct
On 8/22/24 3:43 PM, Iain Sandoe wrote:
On 22 Aug 2024, at 17:47, Jason Merrill wrote:
On 8/22/24 12:35 PM, Iain Sandoe wrote:
+build_coroutine_frame_delete_expr (tree coro_fp, tree orig, tree frame_size,
+ tree promise_type, location_t loc)
+{
Here it
On 8/23/24 9:41 AM, Iain Sandoe wrote:
http://eel.is/c++draft/dcl.fct.def.coroutine#12 (sentence 2) says " If both a
usual deallocation function with only a pointer parameter and a usual deallocation
function with both a pointer parameter and a size parameter are found, then the
selected deall
On 8/23/24 10:36 AM, Iain Sandoe wrote:
Hi Jason,
+ tree iarc_m = lookup_member (frame_type, coro_frame_i_a_r_c_id,
+ 1, 0, tf_warning_or_error);
+ tree iarc_x = build_class_member_access_expr (deref_fp, iarc_m,
NULL_TREE,
+
On 8/23/24 2:30 PM, Iain Sandoe wrote:
Hi Jason
+ /* Check for a bad get return object type. */
+ tree gro_return_type = FUNC_OR_METHOD_TYPE_P (TREE_TYPE (get_ro_meth))
+ ? TREE_TYPE (TREE_TYPE (get_ro_meth))
+ : TREE_TYPE (get_ro_meth);
Is this t
On 8/24/24 7:38 AM, Iain Sandoe wrote:
Hi Jason,
+ return build_op_delete_call_1 (code, addr, size, global_p,
+ two_args_priority_p, placement, alloc_fn,
+ complain);
+}
Rather than having a new overload with the same name and a bo
On 8/23/24 12:44 PM, Simon Martin wrote:
We currently emit an incorrect -Woverloaded-virtual warning upon the following
test case
=== cut here ===
struct A {
virtual operator int() { return 42; }
virtual operator char() = 0;
};
struct B : public A {
operator char() { return 'A'; }
};
==
On 8/23/24 8:41 AM, Jonathan Wakely wrote:
Tested x86_64-linux. OK for trunk?
OK.
-- >8 --
This includes uncommenting the atomic_flag non-member functions, which
were added by PR libstdc++/103934.
Also generate a hint for std::ignore, which was recently tweaked to be
more generally useful b
On 8/23/24 5:11 AM, Simon Martin wrote:
The case in PR113746 used to ICE until commit f04dc89a991. This patch
Please use the git gcc-descr output instead of the raw SHA for referring
to previous commits; in this case that would be r15-123-gf04dc89a991ddc
or just r15-123. OK with that tweak.
On 8/23/24 3:49 PM, Arsen Arsenović wrote:
Iain Sandoe writes:
static tree
get_awaitable_var (suspend_point_kind suspend_kind, tree v_type)
{
- static int awn = 0;
+ auto cinfo = get_coroutine_info (current_function_decl);
+ gcc_assert (cinfo);
If the purpose of this is to check for mista
On 8/22/24 7:49 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Currently the handling of include translation is confusing to read,
using a tri-state integer without much clarity on what different states
mean. This patch cleans this u
On 8/22/24 7:51 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
After importing a header unit we learn about and setup any header
modules that we transitively depend on. However, this causes
'set_filename' to fail an assertion if we t
On 8/26/24 4:26 AM, Simon Martin wrote:
Hi Jason,
On 22 Aug 2024, at 19:28, Jason Merrill wrote:
On 8/22/24 12:51 PM, Simon Martin wrote:
We currently ICE upon the following invalid code, because we don't
check the
number of template parameters in member class template
specializations.
On 8/25/24 12:37 PM, Simon Martin wrote:
On 24 Aug 2024, at 23:59, Simon Martin wrote:
On 24 Aug 2024, at 15:13, Jason Merrill wrote:
On 8/23/24 12:44 PM, Simon Martin wrote:
We currently emit an incorrect -Woverloaded-virtual warning upon the
following
test case
=== cut here ===
struct
On 8/24/24 9:55 AM, Jonathan Wakely wrote:
On Sat, 24 Aug 2024 at 14:14, Jason Merrill wrote:
On 8/23/24 8:41 AM, Jonathan Wakely wrote:
Tested x86_64-linux. OK for trunk?
OK.
I've just noticed that this changes the copyright dates from 2022-2024
to just 2024 (see the excerpts o
On 8/26/24 12:49 PM, Simon Martin wrote:
We mention 'X::__ct' instead of 'X::X' in the "names the constructor,
not the type" error for this invalid code:
=== cut here ===
struct X {};
void g () {
X::X x;
}
=== cut here ===
The problem is that we use %<%T::%D%> to build the error message, whi
On 8/26/24 10:33 AM, Iain Sandoe wrote:
As the PR notes, we now have two bogus warnings that the single frame
pointer parameter is unused in each of the helper functions.
This started when we began to use start_preparsed_function/finish_function
to wrap the helper function code generation. I am
On 8/26/24 2:34 PM, Iain Sandoe wrote:
Hi Jason,
As the PR notes, we now have two bogus warnings that the single frame
pointer parameter is unused in each of the helper functions.
This started when we began to use start_preparsed_function/finish_function
to wrap the helper function code generat
On 8/20/24 11:52 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk only?
OK.
-- >8 --
Extending the PR113063 testcase to additionally constant evaluate the <=>
expression causes us to trip over the assert in cxx_eval_call_expression
/
On 8/27/24 1:15 PM, Simon Martin wrote:
Hi Jason,
On 26 Aug 2024, at 19:30, Jason Merrill wrote:
On 8/26/24 12:49 PM, Simon Martin wrote:
We mention 'X::__ct' instead of 'X::X' in the "names the constructor,
not the type" error for this invalid code:
=== cu
Tested x86_64-pc-linux-gnu. OK for trunk, or were these supposed to be used?
-- 8< --
The __ok variable and _RefT typedef aren't used in the rest of their blocks.
Should they be?
libstdc++-v3/ChangeLog:
* include/std/format (check_dynamic_spec): Add [[maybe_unused]].
* include/
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
The semicolons after each macro invocation here end up following the closing
brace of a function, leading to -Wextra-semi pedwarns.
libstdc++-v3/ChangeLog:
* include/decimal/decimal.h (_DEFINE_DECIMAL_BINARY_OP_WITH_INT)
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
The return seems to have been lost in the r15-1858 RAII overhaul.
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h (__uninitialized_move_copy): Add
missing return.
---
libstdc++-v3/include/bits/stl_uni
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
The unescaped * broke the match.
libstdc++-v3/ChangeLog:
* testsuite/20_util/default_delete/void_neg.cc: Fix regexp quoting.
---
libstdc++-v3/testsuite/20_util/default_delete/void_neg.cc | 2 +-
1 file changed, 1 insert
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
libstdc++-v3/ChangeLog:
* include/std/coroutine (coroutine_handle): Use nullptr instead of
0 as initializer for _M_fr_ptr.
---
libstdc++-v3/include/std/coroutine | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The pedwarns for each of these features should be silenced by
the appropriate -Wno-c++??-extensions.
The handle_pragma_diagnostic_impl change is necessary so that we handle
-Wc++23-extensions early so it's available to interpret_float while
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
testsuite/lib/dg-options.exp defines __GLIBCXX__ to 999; avoid a macro
redefinition warning in that case.
libstdc++-v3/ChangeLog:
* include/bits/c++config: Avoid redefining __GLIBCXX__.
---
libstdc++-v3/include/bits/c++config | 2 +
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
-Wsign-compare complained about these comparisons between (unsigned) size_t
and (signed) streamsize, or between (unsigned) native_handle_type
and (signed) -1. Fixed by adding casts to unify the types.
libstdc++-v3/ChangeLog:
* include/
On 8/28/24 5:55 AM, Jonathan Wakely wrote:
On Wed, 28 Aug 2024 at 10:54, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
Redefining that macro to invalidate PCH is a bit of a hack, but it's
what we have for now, so OK for trunk, thanks.
If it's just to invalidate
On 8/28/24 6:09 AM, Jonathan Wakely wrote:
On Wed, 28 Aug 2024 at 10:58, Jason Merrill wrote:
On 8/28/24 5:55 AM, Jonathan Wakely wrote:
On Wed, 28 Aug 2024 at 10:54, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
Redefining that macro to invalidate PCH is a bit of a hack
Tested x86_64-pc-linux-gnu. Any objections? Should I change all the other
instances of
if (CPP_PEDANTIC...
cpp_error (...CPP_DL_PEDWARN
the same way?
-- 8< --
Using CPP_W_PEDANTIC lets users suppress these diagnostics with
#pragma GCC diagnostic ignored "-Wpedantic".
libcpp/ChangeLog:
On 8/28/24 11:21 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK for trunk/13/14.
-- >8 --
Here we crash on a cp_gimplify_expr/TARGET_EXPR assert:
gcc_checking_assert (!TARGET_EXPR_ELIDING_P (*expr_p)
|| !TREE_ADDRES
On 8/28/24 4:51 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
OK.
-- >8 --
Here maybe_init_list_as_array gets elttype=field, init={NON_LVALUE_EXPR <2>}
and it tries to convert the init's element type (int) to field
using implicit_conversion, which wo
On 8/28/24 3:18 PM, Arsen Arsenović wrote:
Regtested on x86_64-pc-linux-gnu. OK for trunk?
OK.
-- >8 --
In some scenarios, it is possible for the CFG cleanup to cause one of
the labels mentioned in CO_YIELD, which coro-early-expand-ifns intends
to remove, to become part of so
On 8/28/24 3:59 PM, Arsen Arsenović wrote:
This patch fixes a gcc-15 regression (PR116502) and an inelegance in my
earlier patch related to converting CO_AWAIT_EXPRs to void.
This wasn't noticed anywhere AFAICT, but it was a bit unfortunate.
The other two patches fix an actual regression as wel
On 8/28/24 3:59 PM, Arsen Arsenović wrote:
Hm, maybe-unused-1.C should be moved into the previous patch. Could do
before pushing.
Let's combine these three into a single patch, they're all small and
closely related.
@@ -3147,7 +3147,13 @@ maybe_promote_temps (tree *stmt, void *d)
On 8/29/24 11:21 AM, Iain Sandoe wrote:
In the review of earlier patches it was suggested that we might make
use of finish_class_access_expr instead of doing a lookup for the
member and then a build_class_access_expr call.
finish_class_access_expr does a lot more work than we need and ends
up ca
On 8/29/24 11:21 AM, Iain Sandoe wrote:
This will help with the patches to follow for revising the
frame layout when we have an entry with excess alignment.
Tested on x86_64 darwin/linux powerpc64le linux, OK for trunk?
thanks
Iain
--- 8< ---
Now that we have separated the codegen of the ramp,
On 6/7/24 10:44, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/14?
OK.
-- >8 --
Here find_parameter_packs_r is incorrectly treating the 'auto' return
type of a lambda as a parameter pack due to Concepts-TS specific logic
added in r6-4517,
On 6/5/24 05:20, Simon Martin wrote:
On 5 Jun 2024, at 10:34, Jakub Jelinek wrote:
On Wed, Jun 05, 2024 at 08:13:14AM +, Simon Martin wrote:
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -2792,10 +2792,13 @@ duplicate_decls (tree newdecl, tree olddecl,
bool hiding, bool was_hidden)
On 6/7/24 08:12, Simon Martin wrote:
We ICE upon the following when trying to emit a -Wlogical-not-parentheses
warning:
=== cut here ===
template T foo (T arg, T& ref, T* ptr) {
int a = 1;
return static_cast(a);
}
=== cut here ===
This patch makes *_cast<*> parsing more robust by skippin
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Within a source file, #include is translated to import if a suitable header
unit is available, but this wasn't working with -include. This turned out
to be because we suppressed the translation before the beginning of the
main file. Af
On 6/10/24 11:13, Marek Polacek wrote:
On Mon, Jun 10, 2024 at 10:22:11AM -0400, Patrick Palka wrote:
On Fri, 7 Jun 2024, Marek Polacek wrote:
@@ -3940,9 +3936,6 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees,
void* data)
parameter pack (14.6.3), or the type-specifier-seq of
all depend on 2 different OPT_ entries?
Typically = options will specify RejectNegative so the driver will
reject e.g. -Wno-invalid-noreturn=explicit.
Jason
best regards,
Julian
On Sat, Jun 1, 2024 at 4:57 AM Jason Merrill wrote:
On 5/29/24 09:58, Julian Waters wrote:
Currently, gcc warns
On 6/5/24 00:45, Andi Kleen wrote:
The only semantics changes are slightly more vague error messages
to generalize.
Just a few nits:
+/* Extracting strings from constexpr. */
+
+class cexpr_str
+{
+public:
+ cexpr_str (tree message) : message(message) {}
Space before paren.
...
+/* Get
On 6/5/24 00:45, Andi Kleen wrote:
Some programing styles use a lot of inline assembler, and it is common
to use very complex preprocessor macros to generate the assembler
strings for the asm statements. In C++ there would be a typesafe alternative
using templates and constexpr to generate the as
On 6/11/24 23:53, Andi Kleen wrote:
Sorry I must have misunderstood you. I thought the patch was already
approved earlier and I did commit. I can revert or do additional
changes.
I only meant to approve the refactoring patch, but no worries.
On Tue, Jun 11, 2024 at 04:31:30PM -0400, Jason
On 6/12/24 10:02, Andi Kleen wrote:
No semantics changes.
gcc/cp/ChangeLog:
* cp-tree.h (extract): Add new overload to return tree.
* parser.cc (cp_parser_asm_string_expression): Use tree extract.
* semantics.cc (cexpr_str::extract): Add new overload to return
On 6/12/24 14:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK for trunk and 14, I'd say.
-- >8 --
It seems we don't maintain visibility flags for concepts either, so
min_vis_expr_r should ignore them for now, otherwise after r14-678
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The r15-1180 adjustments to this testcase broke a couple of tests in C++26
mode.
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/static_assert1.C: Fix diagnostic typos.
---
gcc/testsuite/g++.dg/cpp26/static_assert1.C | 4 ++--
1 file chan
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
exception_ptr.h contains
namespace __exception_ptr
{
class exception_ptr;
}
using __exception_ptr::exception_ptr;
so when module std tries to 'export using std::exception_ptr', it names
another using-directive rather than the c
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A sample implementation of module std was breaking because the exports
included 'using std::operator&' twice. Since Nathaniel's r15-964 for
PR114867, the first using added an extra instance of each function that was
revealed/exported by tha
On 6/12/24 14:22, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
OK.
-- >8 --
Since the terms of a requires-clause are grammatically primary-expressions
rather than e.g. postfix-expressions, it seems we need to explicitly
handle and di
On 6/12/24 13:56, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/14?
-- >8 --
Here during overload resolution we have two strictly viable ambiguous
candidates #1 and #2, and two non-strictly viable candidates #3 and #4
which we hold on to eve
On 6/12/24 13:20, Andi Kleen wrote:
asm constexpr now only accepts the same string types as C++26 assert,
e.g. string_view and string. Adjust test suite and documentation.
This patchset is all OK, thanks.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_asm_string_expression): Remove support
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
add_binding_entity creates an OVERLOAD to represent a using-declaration in
module purview of a declaration in the global module, even for
non-functions, and we were failing to merge that with the original
declaration in name lookup.
It's no
On 6/13/24 11:16, Patrick Palka wrote:
On Wed, 12 Jun 2024, Jason Merrill wrote:
exception_ptr.h contains
namespace __exception_ptr
{
class exception_ptr;
}
using __exception_ptr::exception_ptr;
so when module std tries to 'export using std::exception_ptr', it nam
On 6/13/24 11:05, Patrick Palka wrote:
On Thu, 23 May 2024, Jason Merrill wrote:
On 5/23/24 17:42, Patrick Palka wrote:
On Thu, 23 May 2024, Jason Merrill wrote:
On 5/23/24 14:06, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
-- &g
On 6/13/24 10:31, Ken Matsui wrote:
This patch adds a warning switch for "#pragma once in main file". The
warning option name is Wpragma-once-outside-header, which is the same
as Clang.
PR preprocessor/89808
gcc/c-family/ChangeLog:
* c.opt (Wpragma_once_outside_header): Define
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Currently we represent a non-function using-declaration by inserting the
named declaration into the target scope. In general this works fine, but in
the case of an exported using-declaration we have nowhere to mark the
using-declaration as
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk? This fixes PR115358 whose testcase used a constexpr static
array variable, but it seems the general issue is not specific to
constexpr as illustrated by the below testcase. Not
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
The capture proxy handling in finish_decltype_type added in r14-5330
was stripping the reference type of a capture proxy's captured variable,
which is desirable for
On 6/18/24 10:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Since r13-3299, build_dynamic_cast_1 calls pushdecl which calls
duplicate_decls and that in this testcase emits the "conflicting
declaration" error and returns error_mark_node, so
On 6/18/24 10:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
Makes sense to me, though probably the [meta.unary.prop] table should be
adjusted in the same way. Jonathan, what do you think?
-- >8 --
Here we started to ICE with r13-25: in check_tr
On 6/17/24 14:17, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In r13-272 we hardened the *_PACK_EXPANSION and *_ARGUMENT_PACK macros.
That trips up here because make_pack_expansion returns error_mark_node
and we access that with PACK_EXPANSIO
On 6/25/24 07:15, Jonathan Wakely wrote:
On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
On 6/18/24 10:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
Makes sense to me, though probably the [meta.unary.prop] table should be
adjusted in the
On 6/25/24 11:03, Patrick Palka wrote:
On Mon, 24 Jun 2024, Jason Merrill wrote:
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
The capture proxy handling in finish_decltype_type added in r14-5330
On 6/13/24 13:00, Patrick Palka wrote:
On Thu, 13 Jun 2024, Jason Merrill wrote:
On 6/13/24 11:05, Patrick Palka wrote:
On Thu, 23 May 2024, Jason Merrill wrote:
On 5/23/24 17:42, Patrick Palka wrote:
On Thu, 23 May 2024, Jason Merrill wrote:
On 5/23/24 14:06, Patrick Palka wrote
On 6/25/24 04:01, Tamar Christina wrote:
Hi All,
It looks like I forgot to check in the C++ frontend if a condition exist for the
loop being adorned with novector. This causes a segfault because cond isn't
expected to be null.
This fixes it by issuing the same kind of diagnostics we issue for
On 6/25/24 15:07, Marek Polacek wrote:
On Tue, Jun 25, 2024 at 06:22:56PM +0100, Jonathan Wakely wrote:
On Tue, 25 Jun 2024 at 16:17, Jason Merrill wrote:
On 6/25/24 07:15, Jonathan Wakely wrote:
On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
On 6/18/24 10:31, Marek Polacek wrote
On 6/25/24 12:52, Tamar Christina wrote:
The 06/25/2024 17:10, Jason Merrill wrote:
On 6/25/24 04:01, Tamar Christina wrote:
Hi All,
It looks like I forgot to check in the C++ frontend if a condition exist for the
loop being adorned with novector. This causes a segfault because cond isn&#
On 6/25/24 11:45, Patrick Palka wrote:
On Tue, 25 Jun 2024, Jason Merrill wrote:
On 6/25/24 11:03, Patrick Palka wrote:
On Mon, 24 Jun 2024, Jason Merrill wrote:
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- &g
On 7/22/24 11:53 AM, Marek Polacek wrote:
On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote:
On Mon, 22 Jul 2024, Jakub Jelinek wrote:
Hi!
While reading the fold expression and concept tree comments, I found
various spots referring to non-existent macros etc.
The following patch
On 7/22/24 9:43 AM, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk
and perhaps backports?
-- >8 --
When passing *this to the promise type ctor (or operator new) (as
per [dcl.fct.def.coroutine]/4), we add an explicit cast to lvalue
reference, but that's unnecessa
On 7/22/24 4:45 PM, Jakub Jelinek wrote:
Hi!
On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote:
FWIW this tree code seems to be a vestige of the initial Concepts TS
implementation and is effectively unused, we can remove it outright.
Here is a patch which removes that.
Bootstrapp
On 7/19/24 10:30 AM, Patrick Palka wrote:
On Thu, 18 Jul 2024, Jason Merrill wrote:
On 7/18/24 12:45 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look
OK for trunk/14?
-- >8 --
As a followup of r15-2047-g7954bb4fcb6fa8, we also need to consi
On 7/20/24 2:31 PM, Marek Polacek wrote:
[ Entering the contest to fix the oldest PR in this cycle. ]
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This 18-year-old PR reports that we parse certain comma expressions
as a declaration rather than statement when the stateme
On 7/19/24 12:24 PM, Patrick Palka wrote:
On Fri, 19 Jul 2024, Jason Merrill wrote:
On 7/19/24 10:55 AM, Patrick Palka wrote:
On Fri, Jul 5, 2024 at 1:50 PM Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
-- >8 --
During the al
On 7/5/24 12:18 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14 and perhaps 13?
Alternatively we can set current_template_parms from weakly_subsumes
instead, who has only one caller anyway.
Would it also work to pass tmpl instead of NU
On 7/23/24 9:37 AM, Patrick Palka wrote:
On Tue, 23 Jul 2024, Jason Merrill wrote:
On 7/5/24 12:18 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14 and perhaps 13?
Alternatively we can set current_template_parms from weakly_subsumes
On 7/18/24 7:46 PM, Andi Kleen wrote:
Updated patch with the !retval bug fix identified by Marek.
OK.
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter f
On 6/15/24 10:29 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
This probably isn't the most efficient approach, since we need to do
name lookup to find deduction guides for a type which will also
potentially do a bunch of pointless lazy loading from
On 7/7/24 12:39 AM, Nathaniel Shead wrote:
Bootstrapped on x86_64-pc-linux-gnu, successfully regtested modules.exp;
OK for trunk if full regtest passes?
Patrick, I assume this change won't mess with your streaming optimizations?
OK with Patrick's approval or on Friday, whichever comes first.
On 6/17/24 8:14 AM, Iain Sandoe wrote:
This is a minor tidy-up, tested on x86_64-darwin,
OK For trunk?
thanks
Iain
--- 8< ---
At present, for pre-conditions and for post-conditions with a void
return, we are not emitting a return statement. This patch adds the
relevant return statements.
Hmm,
On 7/23/24 4:18 PM, Marek Polacek wrote:
On Tue, Jul 23, 2024 at 12:53:07AM -0400, Jason Merrill wrote:
On 7/20/24 2:31 PM, Marek Polacek wrote:
[ Entering the contest to fix the oldest PR in this cycle. ]
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This 18-year-
On 7/17/24 5:33 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Hmm, I thought I had replied to this already.
-- >8 --
Unfortunately, my r15-1946 fix broke the attached testcase. In it,
we no longer go into the
/* P1009: Array size deduction in new-ex
On 7/17/24 3:47 AM, Jakub Jelinek wrote:
Hi!
This patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655013.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657049.html
patches which just introduce non-o
1001 - 1100 of 11982 matches
Mail list logo
