On 10/4/24 8:22 AM, Jakub Jelinek wrote:
On Fri, Oct 04, 2024 at 12:19:03PM +0200, Jakub Jelinek wrote:
Though, maybe the tests should have both the deprecated syntax and the
non-deprecated one...
Here is a variant of the patch which does that.
Tested on x86_64-linux and i686-linux, ok for tr
On 10/2/24 4:51 AM, Simon Martin wrote:
This is a follow-up to the discussion about testing changes to the C++
front end in
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664258.html
It also clarifies that the make invocation examples should be made from
the *build* tree.
Validated fine
On 10/3/24 8:52 PM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu (so far just dg.exp), OK for trunk if full
bootstrap + regtest passes?
OK.
-- >8 --
Users of pushdecl assume that the returned decl will be a possibly
updated decl matching the one that was passed in. My r15-3910 chang
On 10/3/24 10:41 PM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu, so far just dg.exp with
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26,impcx.
OK for trunk if full bootstrap + regtest passes?
-- >8 --
[temp.arg.nontype] changed in C++11 to allow naming internal-linkage
variables and functio
On 10/3/24 7:09 PM, Eric Gallager wrote:
On Thu, Oct 3, 2024 at 12:41 PM Jason Merrill wrote:
By default -Wdeprecated warns about deprecations in the active standard.
When specified explicitly, let's also warn about deprecations in later
standards.
This strikes me as slightly dangerou
ctual hashtable lookup significant
in the profile?
The hashtable also keeps things GC-live ('args' for example).
Those args should also be referenced by TI_ARGS from the respective
template specialization.
JasonFrom 6b5e211b071273174d700f9dea34ff219eb43023 Mon Sep 17 00:00:00 2001
From
On 10/3/24 12:38 PM, Jason Merrill wrote:
On 10/2/24 7:50 AM, Richard Biener wrote:
This reduces peak memory usage by 20% for a specific testcase.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
It's very ugly so I'd appreciate suggestions on how to handle such
situations bet
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
C++23 CWG issue 2521 (https://wg21.link/cwg2521) deprecates user-defined
literal operators declared with the optional space between "" and the
suffix.
Many testcases used that syntax; I removed the space from most of them, and
added C++23 w
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
By default -Wdeprecated warns about deprecations in the active standard.
When specified explicitly, let's also warn about deprecations in later
standards.
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Explicit -Wdepr
e patch, tested x86_64-pc-linux-gnu.From 5b08ae503dd4aef2789a667daaf1984e7cc94aaa Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Wed, 2 Oct 2024 08:05:28 -0400
Subject: [PATCH] c++: free garbage vec in coerce_template_parms
To: gcc-patches@gcc.gnu.org
coerce_template_parms can create two differe
On 9/28/24 2:39 AM, Jakub Jelinek wrote:
On Fri, Sep 27, 2024 at 04:01:33PM +0200, Jakub Jelinek wrote:
So, I think we should go with (but so far completely untested except
for pr78687.C which is optimized with Marek's patch and the above testcase
which doesn't have the clearing anymore) the fol
On 10/2/24 3:20 PM, Marek Polacek wrote:
On Sat, Sep 28, 2024 at 08:39:12AM +0200, Jakub Jelinek wrote:
On Fri, Sep 27, 2024 at 04:01:33PM +0200, Jakub Jelinek wrote:
So, I think we should go with (but so far completely untested except
for pr78687.C which is optimized with Marek's patch and the
ardless of return_full_args. OK with that change.
Alternatively we could use std::unique_ptr or something like it for
inner_args, as the attached (untested). This isn't very idiomatic use
of unique_ptr, a custom class might be better...
Jasoncommit ff16a607f8ba21bc8591f6b7476d1fc4abff693
On 10/2/24 7:49 AM, Richard Biener wrote:
Using iterative_hash_object is expensive compared to using
iterative_hash_hashval_t which is fit for integer sized values.
The following reduces the number of perf cycles spent in
iterative_hash_template_arg and iterative_hash combined by 20%.
Bootstrapp
On 10/1/24 12:44 PM, Simon Martin wrote:
Hi Jason,
On 30 Sep 2024, at 19:56, Jason Merrill wrote:
On 9/23/24 4:44 AM, Simon Martin wrote:
Hi Jason,
On 20 Sep 2024, at 18:01, Jason Merrill wrote:
On 9/20/24 5:21 PM, Simon Martin wrote:
The following code triggers an ICE
=== cut here
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
There have been various problems with -std=c++14 -fconcepts; let's stop
defining the feature test macro in that case.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Don't define __cpp_concepts
before C++17.
---
Handle the new builtin.
gcc/ChangeLog:
* doc/extend.texi: Document the new
__builtin_is_virtual_base_of builtin; amend the docs for
__is_base_of.
gcc/testsuite/ChangeLog:
* g++.dg/ext/is_virtual_base_of.C: New test.
* g++.dg/ext/is_virtual_base_of_diagnostic.C: New test.
Signed-off-by:
On 9/30/24 1:45 PM, Marek Polacek wrote:
On Mon, Sep 30, 2024 at 10:53:04AM -0400, Jason Merrill wrote:
On 9/27/24 5:30 PM, Marek Polacek wrote:
On Fri, Sep 27, 2024 at 04:57:58PM -0400, Jason Merrill wrote:
On 9/18/24 5:06 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux
On 9/17/24 8:14 AM, Simon Martin wrote:
The invalid test case in this PR highlights a bad interaction between
the tentative_firewall and error recovery in cp_parser_decltype: the
firewall makes cp_parser_skip_to_closing_parenthesis a no-op, and the
parser does not make any progress, running "fore
On 9/23/24 4:44 AM, Simon Martin wrote:
Hi Jason,
On 20 Sep 2024, at 18:01, Jason Merrill wrote:
On 9/20/24 5:21 PM, Simon Martin wrote:
The following code triggers an ICE
=== cut here ===
class base {};
class derived : virtual public base {
public:
template constexpr derived(Arg
On 9/27/24 5:30 PM, Marek Polacek wrote:
On Fri, Sep 27, 2024 at 04:57:58PM -0400, Jason Merrill wrote:
On 9/18/24 5:06 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) We're hitting the assert in cp_parser_placeholder_type_specifier.
On 9/27/24 7:29 PM, Nathaniel Shead wrote:
On Fri, Sep 27, 2024 at 03:55:14PM -0400, Jason Merrill wrote:
On 9/27/24 3:38 PM, Jonathan Wakely wrote:
On Fri, 27 Sept 2024 at 19:46, Jason Merrill wrote:
On 9/26/24 6:34 AM, Nathaniel Shead wrote:
On Thu, Sep 26, 2024 at 01:46:27PM +1000
On 9/18/24 5:06 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) We're hitting the assert in cp_parser_placeholder_type_specifier.
It says that if it turns out to be false, we should do error() instead.
Do so, then.
2) lambda-targ8.C should compi
On 9/5/24 6:32 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
OK.
-- >8 --
We ICE in decay_conversion with this test:
struct S {
S() {}
};
S arr[1][1];
auto [m](arr3);
But not when the last line is:
auto [n] = arr3;
Therefore t
On 9/19/24 7:56 PM, Nathaniel Shead wrote:
Noticed how to fix this while working on the other patch.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This implements part of P1787 to no longer complain about redeclaring an
entity via using-decl other than in a cl
On 9/19/24 7:53 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
Alternatively I could solve this the other way around (have a new
'old_target = strip_using_decl (old)' and replace all usages of 'old'
except the usages in this patch); this is mor
On 9/27/24 3:38 PM, Jonathan Wakely wrote:
On Fri, 27 Sept 2024 at 19:46, Jason Merrill wrote:
On 9/26/24 6:34 AM, Nathaniel Shead wrote:
On Thu, Sep 26, 2024 at 01:46:27PM +1000, Nathaniel Shead wrote:
On Wed, Sep 25, 2024 at 01:30:55PM +0200, Jakub Jelinek wrote:
On Wed, Sep 25, 2024 at
On 9/27/24 1:58 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu,
OK for trunk?
-- >8 --
A header unit may contain anonymous namespaces, and those declarations
are exported (as with any declaration in a header unit). This patch
ensures
On 9/26/24 6:34 AM, Nathaniel Shead wrote:
On Thu, Sep 26, 2024 at 01:46:27PM +1000, Nathaniel Shead wrote:
On Wed, Sep 25, 2024 at 01:30:55PM +0200, Jakub Jelinek wrote:
On Wed, Sep 25, 2024 at 12:18:07PM +0100, Jonathan Wakely wrote:
And whether similarly we couldn't use
__attribute__((__v
On 9/27/24 5:14 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
We need to ensure that for a declaration in the module purview, that the
resulting declaration has PURVIEW_P set and IMPORT_P cleared so that we
understand it might be som
On 9/27/24 2:00 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu,
OK for trunk?
-- >8 --
This adds a new xtreme-header testcase to ensure that we have no
regressions with regards to exposures of TU-local declarations
in the standard libr
On 9/27/24 1:59 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu,
OK for trunk?
-- >8 --
[module.import] p6 says "A header unit shall not contain a definition of
a non-inline function or variable whose name has external linkage."
This p
On 9/27/24 1:59 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu,
OK for trunk?
-- >8 --
By [module.interface] p3, if an exported declaration is not within a
header unit, it shall not declare a name with internal linkage.
Unfortunately
On 9/23/24 7:46 PM, Nathaniel Shead wrote:
Currently I just stream DECL_NAME in TU_LOCAL_ENTITYs for use in diagnostics,
but this feels perhaps insufficient. Are there any better approached here?
Otherwise I don't think it matters too much, as which entity it is will also
be hopefully clear from
On 9/23/24 7:45 PM, Nathaniel Shead wrote:
I feel like there should be a way to make use of LAMBDA_TYPE_EXTRA_SCOPE to
avoid the need for the new TYPE_DEFINED_IN_INITIALIZER_P flag, perhaps once
something like my patch here[1] is accepted (but with further embellishments
for concepts, probably),
I noticed that IRC information was difficult to find on the website. OK?
---
htdocs/style.mhtml | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/style.mhtml b/htdocs/style.mhtml
index d015029a..f1aa8214 100644
--- a/htdocs/style.mhtml
+++ b/htdocs/style.mhtml
@@ -67,6 +67,7 @@
Snaps
IRC discussion noted that the GettingStarted page was hard to find. Committing
as obvious.
---
htdocs/contribute.html | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index caff1f2a..53c27c6e 100644
--- a/htdocs/contribute.html
+++ b/htdocs/c
On 9/24/24 2:53 AM, Nathaniel Shead wrote:
On Tue, Sep 24, 2024 at 09:44:48AM +1000, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fixes some inconsistencies with what kinds of linkage various
entities are assumed to have. This also fixe
On 9/23/24 7:45 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Currently the streaming code uses TREE_CONSTANT to determine whether an
entity will have a definition that is interesting to stream out. This
is not sufficient, however; we also
On 9/26/24 1:29 AM, Nathaniel Shead wrote:
On Tue, Sep 24, 2024 at 09:47:17AM +1000, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
[module.import] p6 says "A header unit shall not contain a definition of
a non-inline function or variable whose
On 9/26/24 4:41 AM, Giuseppe D'Angelo wrote:
Hi,
Thank you for the review.
Il 25/09/24 20:13, Jason Merrill ha scritto:
Supporting the ambiguous case seems pointless to me but, that is what
the accepted proposal specifies, so indeed that's what we should
implement.
It's fu
On 9/25/24 6:24 PM, Arsen Arsenović wrote:
Tested on x86_64-pc-linux-gnu. OK for trunk?
OK.
TIA
-- >8 --
If we reach a CLEANUP_POINT_EXPR while trying to walk statements, we
actually care about the statement or statement list contained within it.
Indeed, such a construction
On 9/18/24 2:35 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
This PR reports that the warning would be better off using a check
for trivially constructible rather than trivially copyable.
LLVM accepted a similar fix:
https://github.com/ll
On 9/25/24 4:21 PM, Marek Polacek wrote:
On Wed, Sep 25, 2024 at 08:54:46AM -0400, Jason Merrill wrote:
On 9/24/24 5:10 PM, Marek Polacek wrote:
On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote:
On 9/20/24 12:18 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux
On 9/25/24 12:44 PM, Patrick Palka wrote:
On Wed, 25 Sep 2024, Jason Merrill wrote:
On 7/30/24 6:49 PM, Giuseppe D'Angelo wrote:
On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
Hi,
The attached patch is a stab at adding the necessary compiler builtin to
support std::is_virtu
On 7/30/24 6:49 PM, Giuseppe D'Angelo wrote:
On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
Hi,
The attached patch is a stab at adding the necessary compiler builtin to
support std::is_virtual_base_of (P2985R0, approved for C++26). The name
of the builtin matches the one just merged into clang:
On 9/25/24 10:01 AM, Jakub Jelinek wrote:
Hi!
Seems we already allow the partial specializations the way the DR clarifies,
so this patch just adds a testcase which verifies that.
Tested on x86_64-linux, ok for trunk?
OK.
2024-09-25 Jakub Jelinek
* g++.dg/DRs/dr2874.C: New test.
On 9/25/24 10:00 AM, Jakub Jelinek wrote:
Hi!
Seems we already handle it the way the DR clarifies, if double/long double
and std::float64_t have the same mode, foo has long double type (while
x + y would be _Float64 in C23), so this patch just adds a testcase which
verifies that.
Tested on x86_
On 9/25/24 9:57 AM, Jakub Jelinek wrote:
Hi!
Seems we already handle delete expressions the way the DR clarifies,
so this patch just adds a testcase which verifies that.
Tested on x86_64-linux, ok for trunk?
OK.
2024-09-25 Jakub Jelinek
* g++.dg/DRs/dr2728.C: New test.
--- gcc/
On 9/25/24 9:31 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK (and obvious, IMO).
-- >8 --
While futzing around with PR116416 I noticed that we can use
the _SLOT and _INITIAL macros to make the code more readable.
gcc/c-family/ChangeLog:
*
On 9/24/24 5:10 PM, Marek Polacek wrote:
On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote:
On 9/20/24 12:18 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR reports a missed optimization. When we have:
Str str{&q
On 9/24/24 7:51 AM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu.
Is this the right fix, or do we want to stop using these deprecated classes,
here and in stl_function.h?
Oops, adding libstdc++ CC.
-- 8< --
The CI saw failures on 17_intro/headers/c++2011/parallel_mode.cc due
On 9/23/24 7:44 PM, Nathaniel Shead wrote:
I don't currently have any testcases where this changes something, but I felt
it to be a valuable cleanup.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This avoids any possible inconsistencies (current or future) ab
On 9/23/24 7:43 PM, Nathaniel Shead wrote:
This patch intends no change in functionality apart from the mangling
difference noted; more tests are in patch 4 of this series, which adds a
way to actually check what the linkage of decl_linkage provides more
directly.
Bootstrapped and regtested on x
On 9/24/24 12:53 PM, Jakub Jelinek wrote:
On Mon, Sep 23, 2024 at 03:46:36PM -0400, Jason Merrill wrote:
-frange-based-for-ext-temps
or do you have better suggestion?
I'd probably drop "based", "range-for" seems enough.
Shall we allow also disabling it in C++23 or
On 8/30/24 8:49 AM, Nina Dinka Ranns wrote:
We currently do not expect comdat group of the guarded function to
be set at the time of generating pre and post check function.
However, in the case of an explicit instantiation, the guarded
function has been added to a comdat group before generating c
Tested x86_64-pc-linux-gnu.
Is this the right fix, or do we want to stop using these deprecated classes,
here and in stl_function.h?
-- 8< --
The CI saw failures on 17_intro/headers/c++2011/parallel_mode.cc due to
-Wdeprecated-declarations warnings in some parallel/ headers.
libstdc++-v3/Change
On 9/21/24 1:54 PM, Arsen Arsenović wrote:
convert_to_void has, so far, when converting a co_await expression to
void altered the await_resume expression of a co_await so that it is
also converted to void. This meant that the type of the await_resume
expression, which is also supposed to be the
On 9/21/24 1:54 PM, Arsen Arsenović wrote:
Okay, these patch should work correctly in all cases, at least all I
could think of. The first patch is unchanged, the second one is simpler
than it was before, I think.
-- >8 --
If such a diagnostic is necessary, it has already been emi
On 9/23/24 9:24 PM, Jakub Jelinek wrote:
On Mon, Sep 23, 2024 at 11:32:59AM -0400, Jason Merrill wrote:
On 8/9/24 9:06 PM, Jakub Jelinek wrote:
Hi!
The following patch implements the C++23 P2718R0 paper
- Wording for P2644R1 Fix for Range-based for Loop.
As all the temporaries from
On 9/23/24 9:08 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We don't detect an explicit object parameter in a requires expression.
We can get there by way of requires-expression -> requirement-parameter-list
-> parameter-declaration-clause -> ..
On 8/9/24 9:06 PM, Jakub Jelinek wrote:
Hi!
The following patch implements the C++23 P2718R0 paper
- Wording for P2644R1 Fix for Range-based for Loop.
As all the temporaries from __for_range initialization should have life
extended until the end of __for_range scope, this patch disables (for C++
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
c++config needs to be compilable as C, in which mode we complain about the
-Wc++ pragmas.
libstdc++-v3/ChangeLog:
* include/bits/c++config: Don't try to disable -Wc++??-extensions
when compiling as C.
---
libstd
On 9/23/24 9:05 AM, Richard Biener wrote:
On Sat, Sep 21, 2024 at 2:49 AM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. OK for trunk?
-- 8< --
We've been using -Wno-narrowing since gcc 4.7, but at this point narrowing
diagnostics seem like a stable part of C++ and we shoul
On 9/23/24 12:58 PM, Simon Martin wrote:
Hi Jason,
On 20 Sep 2024, at 18:06, Jason Merrill wrote:
On 9/16/24 4:07 PM, Simon Martin wrote:
Hi Jason,
On 14 Sep 2024, at 18:44, Simon Martin wrote:
Hi Jason,
On 14 Sep 2024, at 18:11, Jason Merrill wrote:
On 9/13/24 11:06 AM, Simon Martin
On 9/23/24 10:44 AM, Simon Martin wrote:
Hi Jason,
On 20 Sep 2024, at 18:01, Jason Merrill wrote:
On 9/20/24 5:21 PM, Simon Martin wrote:
The following code triggers an ICE
=== cut here ===
class base {};
class derived : virtual public base {
public:
template constexpr derived(Arg
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
With the changes to #pragma system_header, g++.dg/tm/pr46270.C was
failing because didn't implement the N4514 change to [new.delete] that
says "The library versions of the global allocation and deallocation
functions are declared transaction_saf
Tested x86_64-pc-linux-gnu. OK for trunk?
-- 8< --
We've been using -Wno-narrowing since gcc 4.7, but at this point narrowing
diagnostics seem like a stable part of C++ and we should adjust.
This patch changes -Wno-narrowing to -Wno-error=narrowing so that narrowing
issues will still not break
On 9/20/24 12:40 AM, Jakub Jelinek wrote:
On Fri, Sep 20, 2024 at 06:18:15PM -0400, Marek Polacek wrote:
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1473,6 +1473,20 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
that case, strip it in favor of this one. */
On 9/20/24 12:18 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR reports a missed optimization. When we have:
Str str{"Test"};
callback(str);
as in the test, we're able to evaluate the Str::Str() call at compile
time. But when we h
On 9/20/24 7:34 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/20/24 6:51 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk
On 9/20/24 8:48 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
As a follow-up to r15-3741-gee3efe06c9c49c, which was only concerned
with usings, it seems we should also compare contexts of a reversed
vs non-reversed (memb
On 9/20/24 6:51 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since
On 9/16/24 4:07 PM, Simon Martin wrote:
Hi Jason,
On 14 Sep 2024, at 18:44, Simon Martin wrote:
Hi Jason,
On 14 Sep 2024, at 18:11, Jason Merrill wrote:
On 9/13/24 11:06 AM, Simon Martin wrote:
Hi Jason,
On 12 Sep 2024, at 16:48, Jason Merrill wrote:
On 9/12/24 7:23 AM, Simon Martin
On 9/20/24 5:21 PM, Simon Martin wrote:
The following code triggers an ICE
=== cut here ===
class base {};
class derived : virtual public base {
public:
template constexpr derived(Arg) {}
};
int main() {
derived obj(1.);
}
=== cut here ===
The problem is that cxx_bind_parameters_in_call e
On 9/19/24 4:37 PM, Jakub Jelinek wrote:
On Thu, Sep 19, 2024 at 10:21:15AM -0400, Jason Merrill wrote:
On 9/19/24 7:57 AM, Richard Biener wrote:
On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
I'm fine with th
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since it'll mean inconsistent
behavior between implict vs explicit object members in GCC 14: the ca
On 9/20/24 4:02 PM, Patrick Palka wrote:
On Wed, 18 Sep 2024, Patrick Palka wrote:
Our implementation of the CWG 2273 inheritedness tiebreaker seems to be
incorrectly considering all inherited members, not just inherited
constructors. This patch restricts the tiebreaker accordingly.
D
On 9/19/24 5:35 PM, Marek Polacek wrote:
On Tue, Sep 17, 2024 at 12:50:46PM -0400, Jason Merrill wrote:
On 9/16/24 7:14 PM, Marek Polacek wrote:
+/* Mark an explicitly defaulted function FN as =deleted and warn.
+ IMPLICIT_FN is the corresponding special member function that
+ would have
On 9/19/24 7:57 AM, Richard Biener wrote:
On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
I'm fine with this in general - do we have needs of bumping the requirement for
GCC 15 though? IMO we should bump once w
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
GCC compiles with -fno-exceptions, so __throw_exception_again is a no-op,
and compilation gives a -Wempty-body warning here, so let's wrap it as is
already done in a few other files.
libstdc++-v3/ChangeLog:
* include/bit
On 9/18/24 6:36 PM, Iain Sandoe wrote:
On 18 Sep 2024, at 17:18, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
Despite that adequate support is available in GCC-5.5/6, would it be
useful to jump to a version that allows a single toolchain to
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
-- 8< --
This implements my proposal to update our bootstrap requirement to C++14.
The big benefit of the change is the greater constexpr power, but C++14 also
added variable templates, generic lambdas, lambda init-capture, bina
Tested x86_64-pc-linux-gnu. Marek, thoughts?
-- 8< --
The -Wdangling-reference diagnostic talks about the full-expression, but
prints one call, while the full-expression in a declaration is the entire
initialization. It seems more useful to point out the temporary that the
compiler thinks we mi
Tested x86_64-pc-linux-gnu. Marek, any concerns?
-- 8< --
We can't have a dangling reference to an empty class unless it's
specifically to that class or one of its bases. This was giving a
false positive on the _ExtractKey pattern in libstdc++ hashtable.h.
This also adjusts the order of argume
On 9/17/24 3:22 PM, Patrick Palka wrote:
On Mon, 16 Sep 2024, Patrick Palka wrote:
On Mon, 16 Sep 2024, Andrew Pinski wrote:
On Mon, Sep 16, 2024 at 8:12 AM Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look
OK for trunk? Sadly the prerequisity patch r15
On 8/29/24 9:10 PM, Iain Sandoe wrote:
Hi Jason,
- char *buf = xasprintf ("_Coro_unnamed_parm_%d", no_name_parm++);
+ char *buf = xasprintf ("anon%d", parm_num);
Why the reduction in verbosity here?
I was getting ahead of myself; not intended in this patch. Fixed.
+ p =
On 9/17/24 10:30 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
OK.
-- >8 --
The result of build_fold_indirect_ref can be a COMPONENT_REF in
which case using DECL_SOURCE_LOCATION will crash. Look at its op1
instead.
PR c++/116741
gcc/cp/Cha
On 9/17/24 10:32 PM, Marek Polacek wrote:
On Tue, Sep 17, 2024 at 12:53:25PM -0400, Jason Merrill wrote:
On 9/16/24 7:08 PM, Marek Polacek wrote:
On Tue, Sep 10, 2024 at 10:37:31AM -0400, Jason Merrill wrote:
On 8/29/24 12:23 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux
On 9/17/24 9:26 PM, Iain Sandoe wrote:
On 17 Sep 2024, at 20:06, Jason Merrill wrote:
On 9/17/24 8:26 PM, Iain Sandoe wrote:
On 17 Sep 2024, at 18:24, Jason Merrill wrote:
On 8/29/24 5:22 PM, Iain Sandoe wrote:
Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
thanks,
Iain
On 9/17/24 8:26 PM, Iain Sandoe wrote:
On 17 Sep 2024, at 18:24, Jason Merrill wrote:
On 8/29/24 5:22 PM, Iain Sandoe wrote:
Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
thanks,
Iain
--- >8 ---
Awaiters always need to have a coroutine state frame copy since
they pers
On 8/29/24 5:22 PM, Iain Sandoe wrote:
Tested on x86_64-darwin/linux, powerpc64le linux, OK for trunk?
thanks,
Iain
--- >8 ---
Awaiters always need to have a coroutine state frame copy since
they persist across potential supensions. It simplifies the later
analysis considerably to assign these
On 9/16/24 7:08 PM, Marek Polacek wrote:
On Tue, Sep 10, 2024 at 10:37:31AM -0400, Jason Merrill wrote:
On 8/29/24 12:23 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
Pre r14-4793, we'd call warn_tautological_cmp -> operand_e
On 9/16/24 7:14 PM, Marek Polacek wrote:
On Fri, Sep 13, 2024 at 06:43:06PM +0200, Jason Merrill wrote:
On 9/12/24 3:12 PM, Marek Polacek wrote:
On Wed, Sep 11, 2024 at 10:25:34PM -0400, Jason Merrill wrote:
On 9/11/24 4:08 PM, Marek Polacek wrote:
@@ -6503,10 +6504,17
On 9/17/24 10:38 AM, Simon Martin wrote:
Hi Jason,
Apologies for the back and forth and thanks for your patience!
No worries.
On 5 Sep 2024, at 19:00, Jason Merrill wrote:
On 9/5/24 7:02 AM, Simon Martin wrote:
Hi Jason,
On 4 Sep 2024, at 18:09, Jason Merrill wrote:
On 9/1/24 2:51 PM
On 9/17/24 3:26 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
OK.
-- >8 --
r12-3495 added maybe_warn_about_constant_value which will crash if
it gets a nameless VAR_DECL, which is what happens in this PR.
We created this VAR_DECL in cp_parser_dec
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When we're explicitly choosing GCC extensions, we similarly shouldn't
complain about optional features that GCC provides. This particular pattern
of cast between function and object pointer is used by gthr-posix.h on some
targets, including
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
It seems more useful for a conversion to have the location of the source
expression rather than the enclosing expression, such as a call that might
convert multiple arguments in different ways.
As a result, in srcloc17.C the recorded locati
On 9/12/24 1:32 PM, Patrick Palka wrote:
On Mon, 12 Aug 2024, Seyed Sajad Kahani wrote:
When deducing auto for `adc_return_type`, `adc_variable_type`, and
`adc_decomp_type` contexts (at the usage time), we try to resolve the outermost
template arguments to be used for satisfaction. This is done
On 9/13/24 11:06 AM, Simon Martin wrote:
Hi Jason,
On 12 Sep 2024, at 16:48, Jason Merrill wrote:
On 9/12/24 7:23 AM, Simon Martin wrote:
Hi,
While looking at more open PRs, I have discovered that the problem
reported in PR109790 is very similar to that in PR100632, so I’m
combining both in
1 - 100 of 1582 matches
Mail list logo
