On 5/29/25 2:57 PM, David Malcolm wrote:
On Thu, 2025-05-29 at 09:11 -0400, Jason Merrill wrote:
On 5/27/25 5:12 PM, Jason Merrill wrote:
On 5/27/25 4:47 PM, Jason Merrill wrote:
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Nathaniel shared a more extensive test, which revealed more needed fixes.
PR c++/113563
gcc/cp/ChangeLog:
* lambda.cc (lambda_capture_field_type): Handle 'this' normally.
(build_capture_proxy): Special-case 'this'
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Various places were still making assumptions that we could get to the 'this'
capture through current_class_ref in a lambda op(), which is incorrect for
an explicit object op().
PR c++/113563
gcc/cp/ChangeLog:
* lambda.cc (
On 5/29/25 11:34 AM, Iain Sandoe wrote:
Tested on x86_64-darwin, powerpc64le-linux; I'd like to minimize
effort on this code, since I expect that we will need some changes
to deal with open BZs. This fixes an ICE tho,
OK for trunk?
OK.
thanks
Iain
--- 8< ---
The check was intended to asser
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We only want the error for these cases for functions explicitly declared
constexpr, but we still want to set invalid_constexpr on C++17 lambdas so
maybe_save_constexpr_fundef doesn't make them implicitly constexpr.
The potential_constant_ex
On 5/29/25 6:56 AM, Iain Sandoe wrote:
Tested on x86_64-darwin, confirming that the original reported code
fails without the change here. Unfortunately, if we add a move
constructor to the reduced case, it no longer fails on unpatched
trunk - so not proposing to add that as a testcase (since it
On 5/27/25 5:12 PM, Jason Merrill wrote:
On 5/27/25 4:47 PM, Jason Merrill wrote:
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Typically "does this class have a trivial destructor" is the wrong question
to ask, we rather want "can I destroy this class trivially", thus the
std::is_trivially_destructible standard trait. Let's provide a builtin for
it, and complain ab
On 11/27/24 11:17 AM, Jason Merrill wrote:
On 11/27/24 1:43 AM, Nathaniel Shead wrote:
On Wed, Nov 27, 2024 at 12:03:23AM -0500, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu.
Does this approach make sense to you? Any other ideas?
-- 8< --
We weren't representing 'using name
On 5/27/25 4:47 PM, Jason Merrill wrote:
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
trunk
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
trunk?
Ping?
Ping.
Sorry for the delay in
Tested x86_64-pc-linux-gnu, OK for trunk?
Iain, will you verify that one of your coroutine testcases breaks without this
fix? I don't think lambda or anonymous union uses of DECL_VALUE_EXPR can break
in the same way, though this change is also correct for them.
-- 8< --
This PR noted that fold_
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A class to simplify implementation of -fdump-lang-foo with support for
pp_printf using %D and such.
gcc/cp/ChangeLog:
* cxx-pretty-print.h (class cxx_dump_pretty_printer): New.
* error.cc (cxx_dump_pretty_printer): Ctor/dto
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This patch adds a dump with a trace of template instantiations, indented
based on the depth of recursive instantiation. -lineno adds the location
that triggered the instantiation, -details adds non-instantiation
sbustitutions.
The instantia
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
in r12-1100 we stopped printing template bindings like T = T. The check for
this relied on TREE_CHAIN of a TEMPLATE_TYPE_PARM holding the declaration of
that type-parameter. This should be written as TYPE_STUB_DECL. In
addition, TYPE_STUB
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for trunk?
Ping?
Ping.
-- 8< --
To respect the #pragma diagnostic lines in libstdc++ headers when
compiling
with module std, we need to repres
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I wondered why we needed to push/pop_tinst_level in mangle_decl_string. And
apparently we don't need to anymore.
gcc/cp/ChangeLog:
* mangle.cc (mangle_decl_string): Don't push_tinst_level.
---
gcc/cp/mangle.cc | 22 +++---
On 5/23/25 10:35 AM, Nathaniel Shead wrote:
On Fri, May 23, 2025 at 10:23:51AM -0400, Jason Merrill wrote:
On 5/22/25 8:22 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
(Also is renaming the old test OK/appropriate? Or should I keep it
before
On 5/23/25 10:59 AM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if
full bootstrap+regtest succeeds?
OK.
-- >8 --
When streaming in a reference to a data member, we have an oversight
where we did not consider USING_DECLs, despite otherwise han
On 5/21/25 10:15 PM, Nathaniel Shead wrote:
Another approach would be to fix 'write_class_def' to handle these
declarations better, but that ended up being more work and felt fragile.
It also meant streaming a lot more information that we don't need.
Long term I had been playing around with rewo
On 5/22/25 8:22 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
(Also is renaming the old test OK/appropriate? Or should I keep it
before and just name the new tests as tls1/2, with a comment referring
to pr113292?)
-- >8 --
The PR notes that we m
On 5/9/25 11:37 AM, Simon Martin wrote:
Several gcc_assert through the C++ front-end involve seen_error (), that
does not take into account errors that were turned into warnings due to
-fpermissive or -Wtemplate-body.
Running the full C++ testsuite when forcing the use of -fpermissive
leads to I
Tested x86_64-pc-linux-gnu, any objection?
-- 8< --
r10-1211 added various -Wformat-diag warnings about quoting in GCC
diagnostic strings, but didn't change these two quoting warnings to use that
flag as well.
gcc/c-family/ChangeLog:
* c-format.cc (flag_chars_t::validate): Control quoti
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In cp_fold we do speculative constant evaluation of constexpr calls when
inlining is enabled. Let's also do it for always_inline functions.
PR c++/120935
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_fold): Check always_inline.
On 5/20/25 11:28 AM, Patrick Palka wrote:
On Mon, 19 May 2025, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/15/14?
Whoops, CI reports I missed a testsuite adjustment expecting an
additional error in other/default13.C, which seems reasonab
On 5/20/25 9:51 AM, Iain Sandoe wrote:
Hi Jason,
Moving this initialization doesn't seem connected to the type of gro, or
mentioned above?
A fly-by tidy up.. removed.
I still see it in the new patch?
Apologies, I obviously fat-fingered something - done now.
...return object from an objec
On 5/20/25 9:42 AM, Iain Sandoe wrote:
Hi Jason
So I moved this to the position before the g_r_o is initialized
(since we only manage cleanups of the entities that come before that, although
that's a bit hard to see from the patch).
This will probably need reevaluation if you take my suggest
On 5/19/25 11:11 PM, Nathaniel Shead wrote:
On Mon, May 19, 2025 at 04:56:38PM -0400, Jason Merrill wrote:
On 5/19/25 8:27 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively could go back to always marking vtables as DECL_EXTERNAL
as well
On 4/15/25 6:31 AM, Alfie Richards wrote:
This change refactors FMV handling in the frontend to allows greater
reasoning about versions in shared code.
Looking at the cp/ changes:
diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index c28d9e5b3ab..4f195ae06cd 100644
--- a/gcc/cp/class.cc
+++ b/
On 5/17/25 10:38 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
OK.
-- >8 --
When we import a pending instantiation that matches an existing partial
specialisation, we don't find the slot in the entity map because for
partial specialisations we
On 5/19/25 8:27 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively could go back to always marking vtables as DECL_EXTERNAL
as well but that doesn't seem to be necessary that I can tell.
DECL_NOT_REALLY_EXTERN doesn't make sense without DE
On 5/19/25 11:54 AM, Jason Merrill wrote:
On 5/16/25 10:11 AM, Iain Sandoe wrote:
Hi Jason,
+ returned reference or prvalue result object ...
+ When we use a local to hold this, it is decltype(auto). */
+ tree gro_type
+ = finish_decltype_type (get_ro
On 5/19/25 9:37 AM, Nathaniel Shead wrote:
Regtested on x86_64-pc-linux-gnu (so far just modules.exp), OK for
trunk if full bootstrap+regtest succeeds? And maybe 15?
OK for both.
-- >8 --
We need to mark type info decls as addressable if we take them by
reference; this is done by walking th
On 5/16/25 10:04 AM, Iain Sandoe wrote:
+ /* We must manage the cleanups ourselves, because the responsibility for
+ them changes after the initial suspend. However, any use of
+ cxx_maybe_build_cleanup () can set the throwing_cleanup flag. */
+ cp_function_chain->throwing_cleanup = f
On 5/16/25 10:11 AM, Iain Sandoe wrote:
Hi Jason,
+ returned reference or prvalue result object ...
+ When we use a local to hold this, it is decltype(auto). */
+ tree gro_type
+= finish_decltype_type (get_ro, /*id_expression_or_member_access_p*/true,
This should be false, not
On 5/16/25 10:15 AM, Iain Sandoe wrote:
Hi Jason,
+ = build1_loc (loc, TRUTH_NOT_EXPR, boolean_type_node, iarc_x);
+ do_fr_cleanup = build2_loc (loc, TRUTH_AND_EXPR, boolean_type_node,
+ do_fr_cleanup, coro_before_return);
This also needs reversing
On 5/10/25 11:41 AM, Simon Martin wrote:
The following test case highlights two issues - see
https://godbolt.org/z/7E1KGYreh:
1. We error out at both L4 and L5, while (at least) clang, EDG and MSVC
only reject L5
2. Our error message for L5 incorrectly mentions using a null pointer
===
On 5/16/25 9:14 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This patch removes some no longer needed special casing in linkage
determination, and makes the distinction between "always_emit" and
"internal" for better future-proofing
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
After my r16-670, running the testsuite with explicit --stds didn't run this
one in C++17 mode, but the default did. Let's remove the { target c++17 }
so it doesn't by default, either.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/
On 5/15/25 4:58 PM, Ville Voutilainen wrote:
On Thu, 15 May 2025 at 18:32, Ville Voutilainen
wrote:
On Thu, 15 May 2025 at 18:19, Jason Merrill wrote:
@@ -3347,8 +3347,6 @@ cp_fold (tree x, fold_flags_t flags)
|| id_equal (DECL_NAME (callee), "as_
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
coroutines.exp was basically only there to add -std=c++20 to all the tests;
removing it lets us use the general support for running tests under multiple
standards. Doing this revealed that some tests that specifically run in
C++17 mode were
On 5/14/25 6:26 AM, Nathaniel Shead wrote:
On Tue, May 13, 2025 at 12:40:30PM -0400, Jason Merrill wrote:
On 5/9/25 11:48 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
One slight concern I have is why we end up in 'maybe_thunk_body'
On 5/15/25 10:36 AM, Ville Voutilainen wrote:
This is a follow-up to the earlier patch that adds std::to_underlying to the
set of stdlib functions that are folded. We don't seem to need to handle
the same-type case specially, the folding will just do the right thing.
Also fix up the mistake of n
On 5/14/25 4:48 PM, Patrick Palka wrote:
On Wed, 14 May 2025, Patrick Palka wrote:
On Wed, 14 May 2025, Jason Merrill wrote:
On 5/14/25 2:44 PM, Patrick Palka wrote:
On Wed, 14 May 2025, Patrick Palka wrote:
On Wed, 14 May 2025, Jason Merrill wrote:
On 5/12/25 7:53 PM, Patrick Palka
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Import didn't like differences in DECL_DECLARED_CONSTEXPR_P due to implicit
constexpr, breaking several g++.dg/modules tests; we should handle that
along with DECL_MAYBE_DELETED. For which we need to stream the bit.
gcc/cp/ChangeLog:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Patrick pointed out that if the parm/arg types aren't complete yet at this
point, it would affect the type_has_converting_constructor and
TYPE_HAS_CONVERSION tests. I don't have a testcase, but it makes sense for
safety.
PR c++/995
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The modules tests have used their own version of the code to run tests under
multiple standard versions; they should use the same one as other tests.
I'm not sure about continuing to run modules tests in C++17 mode, but I
guess we might as
On 5/13/25 10:30 AM, Iain Sandoe wrote:
This replaces the cleanup try-catch block in the ramp with a series of
eh-only cleanup statements.
gcc/cp/ChangeLog:
* coroutines.cc
(cp_coroutine_transform::build_ramp_function): Replace ramp
cleanup try-catch block with eh-only c
On 5/13/25 10:30 AM, Iain Sandoe wrote:
The revised wording for coroutines, uses decltype(auto) for the
type of the get return object, which preserves references. The
test is expected to fail, since it attempts to initialize the
return object from an object that has already been destroyed.
gcc/c
On 5/13/25 10:30 AM, Iain Sandoe wrote:
This addresses the clarification that, when the get_return_object is of a
different type from the ramp return, any necessary conversions should be
performed on the return expression (so that they typically occur after the
function body has started execution
On 5/14/25 2:44 PM, Patrick Palka wrote:
On Wed, 14 May 2025, Patrick Palka wrote:
On Wed, 14 May 2025, Jason Merrill wrote:
On 5/12/25 7:53 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK
for trunk/15/14?
-- >8 --
Here unification of P=W
On 5/14/25 2:10 PM, Iain Sandoe wrote:
that indicates we have not yet reached the ramp return.
This flag was not part of the fix on trunk, and could use more rationale.
The original fix was OK on trunk because exceptions thrown from the
return expression would happen before the initi
On 5/12/25 7:53 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK
for trunk/15/14?
-- >8 --
Here unification of P=Wrap::type, A=Wrap::type wrongly
succeeds ever since r14-4112 which made the RECORD_TYPE case of unify
no longer recurse into template ar
On 5/13/25 11:06 AM, Iain Sandoe wrote:
This could not be done as a cherry-pick from the trunk resolution.
Tested on x86_64-darwin, powerpc64le linux sparc9 solaris,
OK for 14.3 ?
thanks
Iain
--- 8< ---
This is a GCC-14 version of the same strategy as used on trunk, but
with the more wide-rangi
On 5/14/25 3:43 AM, Simon Martin wrote:
Patrick noticed that this PR's testcase has been fixed by the patch for
PR c++/114292 (r15-7238-gceabea405ffdc8), more specifically the part
that walks the type of DECL_EXPR DECLs.
This simply adds the case to the testsuite.
OK.
Successfully tested on
On 5/14/25 9:32 AM, Ville Voutilainen wrote:
On Wed, 14 May 2025 at 16:30, Ville Voutilainen
wrote:
On Wed, 14 May 2025 at 16:26, Patrick Palka wrote:
r = CALL_EXPR_ARG (x, 0);
/* Check that the return and argument types are sane before
folding. */
This
On 5/14/25 6:54 AM, Nathaniel Shead wrote:
Bootstrapped and regtested (just modules.exp and dg.exp=lambda*) on
x86_64-pc-linux-gnu, OK for 14 if full regtest succeeds?
OK.
-- >8 --
r14-9232-g3685fae23bb008 broke the ABI for lambdas in base classes,
causing ICEs when different lambdas got giv
): Check whether
-Wvirtual-move-assign is enabled at the location of a base
class's move assignment operator.
gcc/testsuite/ChangeLog:
* g++.dg/warn/ignore-virtual-move-assign.C: New test.
Co-authored-by: Jason Merrill
Signed-off-by: Owen Avery
---
gcc/cp/meth
On 5/13/25 7:15 PM, Ville Voutilainen wrote:
On Tue, 13 May 2025 at 23:42, Ville Voutilainen
wrote:
It seems to me that this
sanity check is checking that it's a cast between
references for the other ones, and that's just unsuitable for
to_underlying. I would suggest just removing that sanity
same line as the source file.
is enabled at the location of a base class's move assignment
operator.
gcc/testsuite/ChangeLog:
* g++.dg/warn/ignore-virtual-move-assign.C: New test.
Co-authored-by: Jason Merrill
Signed-off-by: Owen Avery
---
gcc/cp/meth
On 5/13/25 4:29 PM, Ville Voutilainen wrote:
On Tue, 13 May 2025 at 23:23, Jason Merrill wrote:
/* Check that the return and argument types are sane before
folding. */
- if (INDIRECT_TYPE_P (TREE_TYPE (x))
- && INDIRECT_TYPE_P (TREE
On 5/12/25 4:32 PM, Ville Voutilainen wrote:
This function is yet another stdlib function that is just a simple cast, so
having
it appear while debugging is arguably not useful. So add it to the existing
handling
that always-folds some stdlib functions.
Add std::to_underlying to the set of std
On 5/13/25 10:56 AM, Alejandro Colomar wrote:
Hi Jason,
On Tue, May 13, 2025 at 10:35:00AM -0400, Jason Merrill wrote:
It seems to be one of the more common trailers used in the linux
kernel [1],
Hmm, I don't see it in that list. But it is described in
https://docs.kernel.org/pr
On 5/9/25 11:48 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
One slight concern I have is why we end up in 'maybe_thunk_body' to
start with: the imported constructor isn't DECL_ONE_ONLY (as its
external) and so 'can_alias_cdtor' returns false.
On 5/13/25 10:30 AM, Iain Sandoe wrote:
The constraints of the c++ coroutines specification require the ramp
to construct a return object early in the function. This will be returned
at some later time. To meet the requirements of copy-elision, we need
to ensure NVRO for these objects, even whe
On 5/13/25 10:30 AM, Iain Sandoe wrote:
In some cases, a function might be declared as FUNCTION_NEEDS_BODY_BLOCK
but all the content is contained within that block. However, poplevel
is currently assuming that such cases would always contain subblocks.
In the case that we do have a body block,
On 5/12/25 6:03 PM, Alejandro Colomar wrote:
On Mon, May 12, 2025 at 05:42:55PM +0100, Jonathan Wakely wrote:
On Mon, 12 May 2025 at 17:34, Jonathan Wakely wrote:
On Mon, 12 May 2025 at 16:46, Alejandro Colomar wrote:
contrib/ChangeLog:
* gcc-changelog/git_commit.py (GitCommit):
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The warning compares the position of a field depending on whether or not the
previous base/field is considered a POD for layout, but failed to consider
whether the previous base/field is empty; layout of an empty base doesn't
consider PODnes
On 5/9/25 11:33 AM, Nathaniel Shead wrote:
On Fri, May 09, 2025 at 08:18:58AM -0400, Jason Merrill wrote:
On 4/21/25 6:22 AM, Nathaniel Shead wrote:
This call is not necessary, as we don't access the bodies of any classes
that we instantiate here.
This turns out to break
20
On 5/9/25 1:31 PM, Jonathan Wakely wrote:
On Fri, 9 May 2025 at 18:13, Jonathan Wakely wrote:
On Fri, 9 May 2025 at 11:19, Jonathan Wakely wrote:
On Thu, 8 May 2025 at 20:56, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense for trunk?
Yes, it looks useful. I&#
On 5/11/25 7:11 PM, Owen Avery wrote:
Yeah, that looks way simpler. Should I add you as co-author on the
patch?
Sounds good, thanks.
On 4/28/25 22:13, Jason Merrill wrote:
On 4/28/25 5:07 PM, Owen Avery wrote:
As far as I can tell, that would need to be applied to every class
which
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here tsubst_baselink was returning error_mark_node silently despite
tf_error; we need to actually give an error.
PR c++/120204
gcc/cp/ChangeLog:
* pt.cc (tsubst_baselink): Always error if lookup fails.
gcc/testsuite/Chang
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
My r16-479 adjustment to the PR99599 workaround broke on a class with a
varargs constructor.
It also occurred to me that we don't need to do non-dep conversion checking
in two phases when concepts aren't supported.
PR c++/99599
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In 20_util/variant/visit_member.cc, instantiation of the variant friend
declaration of __get for variant was being marked as internal
because that variant specialization is itself internal. And therefore
check_module_override didn't try to
On 4/21/25 6:22 AM, Nathaniel Shead wrote:
This call is not necessary, as we don't access the bodies of any classes
that we instantiate here.
This turns out to break
20_util/function_objects/mem_fn/constexpr.cc
std/ranges/view.cc
when modified to use import std (as attached). For the former,
Tested x86_64-pc-linux-gnu. Does this make sense for trunk?
-- 8< --
I added this locally to check whether the PR120012 fix affects libstdc++ (it
doesn't) but it seems generally useful to catch whether compiler ABI
changes have library impact.
libstdc++-v3/ChangeLog:
* testsuite/lib/li
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This tweak to CWG2369 has gotten more discussion lately in CWG, including in
P3606. In those discussions, it occurred to me that having the check depend
on whether a class has been instantiated yet is unstable, that it should
only check for
On 5/7/25 1:50 AM, Jakub Jelinek wrote:
On Tue, May 06, 2025 at 05:11:51PM -0400, Jason Merrill wrote:
Well, that's all very complicated but seems to make sense. Can you also add
short rationale comments to the changes in linemap_add and plugin_init?
So like this?
That's gre
On 5/6/25 6:49 AM, Jakub Jelinek wrote:
Hi!
The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switche
On 5/6/25 3:05 PM, Simon Martin wrote:
The following test case highlights two issues - see
https://godbolt.org/z/7E1KGYreh:
1. We error out at both L4 and L5, while (at least) clang, EDG and MSVC
only reject L5
2. Our error message for L5 incorrectly mentions using a null pointer
=== cu
On 5/6/25 7:18 AM, Jakub Jelinek wrote:
Hi!
While the r15-521 commit was meant for trunk only:
On Thu, Apr 25, 2024 at 11:30:48AM -0400, Jason Merrill wrote:
Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, but
rather set it to some stub like void_node?
Though wit
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
c_common_post_options limits flag_abi_version and flag_abi_compat_version to
actual ABI version numbers, but let's not do that for warn_abi_version; we
might want to add a warning relative to a future ABI version that isn't
available in the
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This testcase was incidentally fixed by r16-325 for PR119162.
PR c++/85944
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-temp3.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/constexpr-temp3.C | 8
1 file changed
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here we failed to constant-evaluate the A constructor because DECL_SIZE
wasn't set on 'a' yet, so compare_address thinks we can't be sure it isn't
at the same address as 'i'.
Normally DECL_SIZE is set by build_decl calling layout_decl, but
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
After r16-332 these tests started failing. constexpr-89285.C should have
always given this error, and the new nonlit19.C needs to remove the
destructor body to prevent -fimplicit-constexpr from making the testcase
well-formed.
gcc/testsuit
On 5/1/25 9:33 AM, Patrick Palka wrote:
On Mon, 21 Apr 2025, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
While working on PR119162 it occurred to me that it would be simpler to
detect the problem of a value referring to a heap allocation if we stopped
sett
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
C++20 made a class with only explicitly defaulted constructors no longer
aggregate, and this wrongly affected whether the class is considered "POD
for layout purposes" under the ABI.
Conveniently, we already have check_non_pod_aggregate to
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
This warning relies on the TRANSLATION_UNIT_WARN_EMPTY_P flag (set in
cxx_init_decl_processing) to decide whether we want to warn about the GCC 8
empty class parameter passing fix, but in a call through a function pointer
we don't have a translat
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Looks like I've forgotten to update the docs for -fabi-version for a couple
of my changes.
gcc/ChangeLog:
* doc/invoke.texi: Add -fabi-version detail.
* common.opt: Likewise.
---
gcc/doc/invoke.texi | 9 +++--
gcc/comm
On 5/1/25 3:00 AM, Jakub Jelinek wrote:
Hi!
As discussed in the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674492.html
thread, the following patch attempts to improve build_vec_init generated
code. E.g. on g++.dg/eh/aggregate1.C test the patch has differences like:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
etags was getting confused by the #line pathnames in std-name-hint.h that
don't match my directory layout; let's avoid encoding information about
a particular developer's $(srcdir) in the generated file.
gcc/cp/ChangeLog:
* Make-la
On 4/21/25 4:39 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
Ping.
-- 8< --
While working on PR119162 it occurred to me that it would be simpler to
detect the problem of a value referring to a heap allocation if we stopped
setting TREE_STATIC on them so they natura
On 4/30/25 9:40 AM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk
and maybe 15 if full regtest+bootstrap succeeds?
OK.
-- >8 --
In the linked PR, because the deduction guides depend on an imported
type, we never walk the type and so never call a
On 4/25/25 8:56 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
OK.
-- >8 --
When importing a CNTTP object, since r15-3031-g0b7904e274fbd6 we
shortcut the processing of the generated NTTP so that we don't attempt
to recursively load pendings. H
On 4/28/25 7:06 AM, Nathaniel Shead wrote:
On Thu, Apr 24, 2025 at 12:06:52PM -0400, Jason Merrill wrote:
On 4/22/25 4:48 PM, Jason Merrill wrote:
On 4/22/25 1:21 PM, Tobias Burnus wrote:
Jason Merrill wrote:
On 4/22/25 11:04 AM, Tobias Burnus wrote:
The question is why does this code
On 4/29/25 3:59 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu (so far just
modules.exp), OK for trunk and 15 if full regtest succeeds?
OK.
-- >8 --
In r15-9136-g0210bedf481a9f we started erroring for inline variables
that exposed TU-local entities in their defi
On 4/29/25 8:50 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/15/14?
OK.
-- >8 --
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle
ed_at (DECL_SOURCE_LOCATION (fn), OPT_Wvirtual_move_assign)
then disabling the warning around the base op= would be enough.
Jason
On 4/28/25 08:16, Jason Merrill wrote:
On 4/27/25 5:57 PM, Owen Avery wrote:
This patch should make it easier to selectively disable
-Wvirtual-move-assign errors by a
On 4/27/25 5:57 PM, Owen Avery wrote:
This patch should make it easier to selectively disable
-Wvirtual-move-assign errors by adding an attribute
for move assignment operators which marks them as handling
duplicate calls.
Thanks, but this sort of situation seems like a good fit for
#pragma GCC
On 4/25/25 10:30 AM, Nathaniel Shead wrote:
Tested so far on x86_64-pc-linux-gnu (just modules.exp), OK for trunk/15
if full bootstrap+regtest succeeds?
OK.
A potentially safer approach that would slightly bloat out the size of
the built modules would be to always stream this variable rather
1 - 100 of 2105 matches
Mail list logo
