On 2/10/24 15:27, Marek Polacek wrote:
Probably stage1 material but it should be safe...
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Yeah, OK, this should go in along with the 98388 patch.
-- >8 --
On the heels of r14-8903, this patch adds further complain parameters
so th
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
If register_specialization finds a previous declaration and throws the new
one away, we shouldn't still add the new one to
DECL_TEMPLATE_SPECIALIZATIONS.
PR c++/113612
gcc/cp/ChangeLog:
* pt.cc (process_partial_specializat
On 2/13/24 05:27, Rainer Orth wrote:
Hi Jason,
On 2/2/24 10:23, Rainer Orth wrote:
c-c++-common/pr103798-2.c FAILs on Solaris when compiled as C++:
FAIL: c-c++-common/pr103798-2.c -std=gnu++14 scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c -std=gnu++17 scan-assembler-not memchr
On 2/13/24 14:43, Marek Polacek wrote:
On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote:
On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote:
Sadly, I must admit this is looking like GCC 15 material.
If deferred for GCC 15, can't we at least do some minimal
change and j
On 2/13/24 11:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, are one of
both of these fixes OK for trunk?
-- >8 --
Here during ahead of time checking of the non-dependent new-expr we
synthesize B's copy constructor, which should be defined as deleted
due to A's inac
On 2/13/24 15:52, Marek Polacek wrote:
On Tue, Feb 13, 2024 at 03:41:53PM -0500, Jason Merrill wrote:
On 2/13/24 14:43, Marek Polacek wrote:
On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote:
On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote:
Sadly, I must admit this
On 2/13/24 17:59, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
A minimal fix to quash an extra ; warning. I have a more complete
patch for GCC 15.
DR 1693
PR c++/113760
gcc/cp/ChangeLog:
* parser.cc (cp_parser_membe
On 2/11/24 08:26, Nathaniel Shead wrote:
Currently inline vars imported from modules aren't correctly finalised,
which means that import_export_decl gets called at the end of TU
processing despite not being meant to for these kinds of declarations.
I disagree that it's not meant to; inline var
On 2/11/24 21:26, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This ensures that with modules enabled, redeclaring an enum in the wrong
module or with the wrong underlying type no longer ICEs.
The patch also rearranges the order of the checks
On 2/10/24 17:57, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should I re-introduce the tree checking and just add checks for the
new kinds of declarations that could be have keyed decls?
This way is fine.
-- >8 --
The fix for PR107398 weakened
On 2/10/24 22:54, Nathaniel Shead wrote:
Bootstrapped and regtested (so far just modules.exp and dg.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
(Also I noticed I forgot to add the PR to the changelog in my last
patch, I've fixed that locally.)
-- >8 --
After fixing PR11
On 2/13/24 18:20, Nathaniel Shead wrote:
On Tue, Feb 13, 2024 at 06:12:51PM -0500, Jason Merrill wrote:
On 2/11/24 21:26, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This ensures that with modules enabled, redeclaring an enum in the wr
On 2/13/24 20:34, Nathaniel Shead wrote:
On Tue, Feb 13, 2024 at 06:08:42PM -0500, Jason Merrill wrote:
On 2/11/24 08:26, Nathaniel Shead wrote:
Currently inline vars imported from modules aren't correctly finalised,
which means that import_export_decl gets called at the end of TU
proce
On 2/14/24 06:03, Nathaniel Shead wrote:
On Tue, Feb 13, 2024 at 09:47:27PM -0500, Jason Merrill wrote:
On 2/13/24 20:34, Nathaniel Shead wrote:
On Tue, Feb 13, 2024 at 06:08:42PM -0500, Jason Merrill wrote:
On 2/11/24 08:26, Nathaniel Shead wrote:
Currently inline vars imported from
On 2/14/24 08:46, Patrick Palka wrote:
On Tue, 13 Feb 2024, Jason Merrill wrote:
On 2/13/24 11:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, are one of
both of these fixes OK for trunk?
-- >8 --
Here during ahead of time checking of the non-dependent new-e
On 2/15/24 16:11, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
gcc/cp/ChangeLog:
* module.cc (trees_out::core_bools): Stream TREE_UNAVAILABLE.
(trees_in::core_bools): Likewise.
(trees_out::core_vals
On 2/15/24 16:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Issuing a hard error when the GMF doesn't contain preprocessing
directives is inconvenient for automated testcase reduction via cvise.
This patch relaxes this diagnost
On 2/15/24 10:19, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we have
template
auto is_throwable(T t) -> decltype(throw t, true) { ... }
where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
the wrong overload to have bee
On 2/16/24 04:21, Jakub Jelinek wrote:
Hi!
For template parameters, the optional this specifier is in the grammar
template-parameter-list -> template-parameter -> parameter-declaration,
just [dcl.fct/6] says that it is only valid in parameter-list of certain
functions. So, unlike the case of de
On 2/16/24 04:14, Jakub Jelinek wrote:
Hi!
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it), but also on anonymous unions/structs (and we didn't emit that
attribute there).
The following patch fixes it.
Should this involve cp_decl_dwarf_attribute like the
On 2/16/24 10:58, Marek Polacek wrote:
On Thu, Feb 15, 2024 at 04:36:40PM -0500, Jason Merrill wrote:
On 2/15/24 10:19, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we have
template
auto is_throwable(T t) -> decltype(throw t
On 2/16/24 14:52, Jakub Jelinek wrote:
On Fri, Feb 16, 2024 at 04:52:20PM +0100, Jakub Jelinek wrote:
On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
On 2/16/24 04:14, Jakub Jelinek wrote:
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it
On 2/16/24 04:03, Jakub Jelinek wrote:
Hi!
The simple presence of ellipsis as next token after the parameter
declaration doesn't imply it is a parameter pack, it sometimes is, e.g.
if its type is a pack, but sometimes is not and in that case it acts
the same as if the next tokens were , ... inst
On 2/15/24 17:16, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
IMHO trivial enough to go ahead now seeing as it doesn't introduce
new errors.
OK.
-- >8 --
I noticed we don't implement the "unless the overriding function is
defined as deleted" wording adde
On 2/15/24 17:17, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
By the ??? below I mean that maybe_instantiate_noexcept could return
a tristate, and then maybe_check_overriding_exception_spec could check
if (maybe_instantiate_noexcept ().is_unknown ())
On 2/14/24 18:33, Iain Sandoe wrote:
On 14 Feb 2024, at 22:59, Iain Sandoe wrote:
On 12 Feb 2024, at 19:59, Jason Merrill wrote:
On 2/10/24 07:30, Iain Sandoe wrote:
On 10 Feb 2024, at 12:07, Jason Merrill wrote:
On 2/10/24 05:46, Iain Sandoe wrote:
On 9 Feb 2024, at 23:21, Iain
On 2/16/24 17:06, Marek Polacek wrote:
On Fri, Feb 16, 2024 at 04:39:47PM -0500, Patrick Palka wrote:
On Fri, 16 Feb 2024, Marek Polacek wrote:
+ /* We also have to defer checking when we're in a template and couldn't
+ instantiate & evaluate the noexcept to true/false. */
+ if (processi
On 2/19/24 09:39, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
When partially substituting a requires-expr, we don't want to perform
any additional checks beyond the substitution itself, so as to minimize
checking requireme
On 2/19/24 02:55, Jakub Jelinek wrote:
On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
Ah, although __atomic_compare_exchange only takes pointers, the
compiler replaces that with a call to __atomic_compare_exchange_n
which takes the newval by value, which presumably uses an 80-b
On 2/20/24 00:45, Alexandre Oliva wrote:
On Feb 16, 2024, Jason Merrill wrote:
So, for stage2+, let's add just prev- libgcc.
I'm pretty sure this will break bootstrap-lean where libgcc_s isn't a
system library, and we're building post-bootstrap host tools :-(
We need t
On 2/20/24 19:15, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR asks that our -Wuninitialized for mem-initializers does
not warn when binding a reference to an uninitialized data member.
We already check !INDIRECT_TYPE_P in find_uninit_fields_
On 2/23/24 08:53, Christophe Lyon wrote:
On Fri, 23 Feb 2024 at 10:13, Christophe Lyon
wrote:
On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
Hi!
When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
constructor is supposed to return this pointer, but when we cp_fold
On 2/23/24 06:23, Alexandre Oliva wrote:
I'm not so worried about bootstrap itself as I am about post-bootstrap
host tools. Those are unusual in that, after native bootstraps, they're
built using the just-built (last-stage) compiler and target libraries,
rather than the host compiler and system
On 2/21/24 05:28, Nathaniel Shead wrote:
My earlier patch appears to have caused some regressions. I've taken a
quick look to see if there are obvious workarounds, but given the time
frame and the fact that I still don't really understand all the details
of how and when symbols get emitted, I fel
On 2/27/24 23:12, Nathaniel Shead wrote:
On Tue, Feb 27, 2024 at 11:59:46AM -0500, Patrick Palka wrote:
On Fri, 16 Feb 2024, Nathaniel Shead wrote:
On Tue, Feb 13, 2024 at 07:52:01PM -0500, Jason Merrill wrote:
On 2/10/24 17:57, Nathaniel Shead wrote:
The fix for PR107398 weakened the
On 2/27/24 15:48, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and perhaps 13?
-- >8 --
In r12-6773-g09845ad7569bac we gave CTAD placeholders a level of 0 and
ensured we never replaced them via tsubst. It turns out that autos
representing
On 2/26/24 12:10, Patrick Palka wrote:
On Tue, 20 Feb 2024, Jakub Jelinek wrote:
Hi!
Already previously instantiated const variable templates had
cp_apply_type_quals_to_decl called when they were instantiated,
but if they need runtime initialization, their TREE_READONLY flag
has been subsequen
On 2/21/24 19:35, Marek Polacek wrote:
On Fri, Jan 26, 2024 at 04:04:35PM -0500, Jason Merrill wrote:
On 1/25/24 20:37, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Since -Wdangling-reference has false positives that can't be
prevented, w
/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c
(test for excess errors)
Kind regards,
Torbjörn
On 2023-12-11 08:28, Richard Biener wrote:
On Wed, Nov 22, 2023 at 11:45 PM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
OK
-- 8< --
-Waddress-of-packed-member, in additio
On 2/22/24 14:28, Marek Polacek wrote:
On Thu, Feb 22, 2024 at 08:34:45AM +, Jason Merrill wrote:
On 2/20/24 19:15, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR asks that our -Wuninitialized for mem-initializers does
not warn w
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
These two lines have been getting XPASS since the test was added.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-diagnostics7.C: Remove xfail.
---
gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics7.C | 4 ++--
1 file chang
Now in patch form!
Any further comments?
---
htdocs/codingconventions.html | 60 +++
1 file changed, 60 insertions(+)
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f5a356a8..2bbf6670 100644
--- a/htdocs/codingconventions.html
++
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As discussed, our handling of corresponding object parameters needed to
handle the using-declaration case better. And I took the opportunity to
share code between the add_method and cand_parms_match uses.
This patch specifically doesn't co
On 1/12/24 07:45, Jakub Jelinek wrote:
Hi!
The following patch attempts to implement what apparently clang++
implemented for explicit object member function mangling, but nobody
actually proposed in patch form in
https://github.com/itanium-cxx-abi/cxx-abi/issues/148
Ok for trunk if it passes fu
On 12/23/23 14:46, Nathan Sidwell wrote:
On 12/18/23 17:10, Jason Merrill wrote:
On 12/18/23 16:57, Nathan Sidwell wrote:
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have
another theory
about how to merge these?
Why isn&#
On 1/11/24 17:01, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As discussed, our handling of corresponding object parameters needed to
handle the using-declaration case better. And I took the opportunity to
share code between the add_method and cand_parms_ma
On 1/12/24 09:09, Jason Merrill wrote:
On 12/23/23 14:46, Nathan Sidwell wrote:
On 12/18/23 17:10, Jason Merrill wrote:
On 12/18/23 16:57, Nathan Sidwell wrote:
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have
another theory
about how
On 1/3/24 13:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
OK for both.
-- >8 --
Here we neglect to emit the definitions of A::f2 and A::f4
despite the explicit instantiations ultimately because TREE_PUBLIC isn't
set o
On 1/3/24 15:06, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
Since partial template specializations can't be named directly, access
control (when declared at class scope) doesn't apply to them, so we
shouldn't have to set
On 1/5/24 11:50, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
-- >8 --
invalid_tparm_referent_p was rejecting using the address of a class NTTP
object as a template argument, but this should be fine.
Hmm, I suppose so; htt
On 1/8/24 13:40, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13/12?
OK.
-- >8 --
The get_target_expr call added in r12-7069-g119cea98f66476 causes us
for the below testcase to call build_vec_delete in a template context,
which builds a
On 1/15/24 04:41, Nathaniel Shead wrote:
While working on another bug, I noticed the ENABLE_SCOPE_CHECKING macro
and thought to try it out. It caused selftest to ICE. This patch is a
minimal fix to get it working again.
Probably this should use a test to stop this regressing again in the
future
On 1/15/24 17:14, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK, thanks.
-- >8 --
Here we started crashing with r14-1659 because that removed the
auto checking in cp_parser_template_type_arg which seemed like
dead code. But the attached test shows that
On 1/11/24 01:12, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
Currently, thread_locals in header modules cause ICEs. This patch makes
the required changes for them to work successfully.
Functions exported by a module need DECL_CONTEXT to be
On 1/9/24 03:52, Jakub Jelinek wrote:
Hi!
The copy attributes is allowed on decls as well as types and even has
checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics
unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only works
if it applies to a decl.
In t
On 1/8/24 10:27, Patrick Palka wrote:
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
On Sun, 3 Dec 2023, Nathaniel Shead wrote:
The TYPE_DECL_SUPPRESS_DEBUG and DECL_EXTERNAL flags use the same
underlying bit. This is causing confusio
On 1/16/24 06:59, Nathaniel Shead wrote:
On Mon, Jan 15, 2024 at 04:04:49PM -0500, Jason Merrill wrote:
On 1/15/24 04:41, Nathaniel Shead wrote:
While working on another bug, I noticed the ENABLE_SCOPE_CHECKING macro
and thought to try it out. It caused selftest to ICE. This patch is a
minimal
On 12/15/23 04:53, Thomas Schwinge wrote:
Hi Jason!
I think you usually deal with these kind of GCC Git things? If not,
please let me know.
I just took care of this; I didn't notice it until now because the
subject line didn't seem relevant to me.
On 2023-10-26T10:21:18+0200, I wrote:
Fi
On 1/15/24 06:28, Andrew Carlotti wrote:
There's no functional change here, but it makes it clearer that all
three locations should be doing the same thing (aside from changes to
flag_abi_version).
OK.
gcc/cp/ChangeLog:
* mangle.cc (mangle_decl): Consistently use get_mangled_id.
di
On 1/11/24 15:34, Dmitry Drozodv wrote:
You are absolutely right, we can't throw all side-effects away.
+ /* C++ [conv.lval]p3:
+If T is cv std::nullptr_t, the result is a null pointer constant. */
+ return ((TREE_SIDE_EFFECTS (expr) && !CONVERT_EXPR_P (expr))
+ ?
On 1/12/24 03:48, Jakub Jelinek wrote:
On Fri, Jan 12, 2024 at 07:40:19AM +, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
I'm still getting used to things so let me know if the change log
entries are excessive, thanks.
From 9dc168e7bcbbd7d515fa28cb9cae28ec
On 1/16/24 16:28, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Here we crash in maybe_retrofit_in_chrg on an invalid dtor
with explicit this. Such member functions do not get converted
to METHOD_TYPE. If a dtor gets parameters, we reset arg_
On 1/16/24 16:28, Marek Polacek wrote:
Tested x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Diagnostics should start with a lower-case letter.
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator) : Tweak diagnostic
messages.
---
gcc/cp/decl.cc | 6 +++---
1 file changed, 3 inse
On 1/10/24 04:22, Ken Matsui wrote:
+/* Return true if T is an integral type. With __STRICT_ANSI__, __int128 and
+ unsigned __int128 are not integral types. */
This really needs a rationale, since they are actually integer types. I
know __int128 is considered an extension rather than an e
On 1/10/24 04:22, Ken Matsui wrote:
+/* Return true if T is a floating point type. With __STRICT_ANSI__, __float128
+ is not a floating point type. However, _Float128 is a floating point type.
My comment about __is_integral again, but more so; if we support
_Float128, why not __float128?
On 1/10/24 04:23, Ken Matsui wrote:
This patch implements built-in trait for std::is_unsigned.
+case CPTK_IS_UNSIGNED:
+ return TYPE_UNSIGNED (type1);
This seems to lack the checks for arithmetic type that the __is_signed
patch has.
Jason
On 1/17/24 01:33, Nathaniel Shead wrote:
On Mon, Jan 15, 2024 at 06:10:55PM -0500, Jason Merrill wrote:
Under what circumstances does it make sense for CLASSTYPE_INTERFACE_ONLY to
be set in the context of modules, anyway? We probably want to propagate it
for things in the global module so that
On 1/8/24 12:04, Patrick Palka wrote:
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
On Sat, Jan 06, 2024 at 05:32:37PM -0500, Nathan Sidwell wrote:
I;m not sure about this, there was clearly a reason I did it the way it is,
but perhaps that reasoning became obsolete -- something about an existing
On 1/17/24 10:43, Patrick Palka wrote:
On Mon, 15 Jan 2024, Jason Merrill wrote:
On 1/5/24 11:50, Patrick Palka wrote:
invalid_tparm_referent_p was rejecting using the address of a class NTTP
object as a template argument, but this should be fine.
Hmm, I suppose so; https://eel.is/c++draft
On 1/17/24 20:17, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In grokdeclarator/cdk_function the comment says that the find_xobj_parm
lambda clears TREE_PURPOSE so that we can correctly detect an xobj that
is not the first parameter. That's
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We've had a problem with lost conversions to template parameter types for a
while now; looking at this PR, it occurred to me that the problem is really
with alias (and concept) templates, since we do substitution of dependent
arguments into
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
get_template_info was crashing because it assumed that any decl with
DECL_LANG_SPECIFIC could use DECL_TEMPLATE_INFO. It's more complicated than
that.
PR c++/113498
gcc/cp/ChangeLog:
* pt.cc (decl_template_info): New fn.
On 1/22/24 13:11, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13?
-- >8 --
Here we handle the operator expression u < v inconsistently: in a SFINAE
context (such as a requires-expression) we accept the it, and in a
non-SFINAE context we re
On 1/19/24 21:18, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK. A lambda could return a dangling reference, but it's unlikely.
-- >8 --
-Wdangling-reference checks if a function receives a temporary as its
argument, and only warns if any of the argumen
On 1/19/24 02:41, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu using a cross-compiler to
arm-unknown-linux-gnueabihf with --enable-threads=0 that the link test
is correctly skipped. OK for trunk?
OK.
-- >8 --
This disables the new test added by r14-8168 on machines that don't have
TL
Tested x86_64-pc-linux-gnu, applying to 12/13.
-- 8< --
Here we were assuming that current_retval_sentinel would be set if we have
seen a throwing cleanup, but that's not the case if the cleanup is after all
returns.
This change isn't needed on trunk, where current_retval_sentinel is set for
all
On 1/20/24 18:14, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Currently, importing a namespace declarations marks it as imported, and
so marks it as originating from the module that it was imported from.
This is usually harmless, but c
On 1/20/24 05:45, Nathaniel Shead wrote:
On Fri, Jan 19, 2024 at 01:57:18PM -0500, Patrick Palka wrote:
On Wed, 3 Jan 2024, Nathaniel Shead wrote:
+ if (DECL_CONTEXT (decl)
+ && RECORD_OR_UNION_TYPE_P (DECL_CONTEXT (decl))
+ && !DECL_TEMPLATE_INFO (decl))
+
On 1/19/24 17:36, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Currently, when exporting names from the GMF, or within header modules,
for a set of constrained partial specialisations we only emit the first
one. This is because the 'typ
On 1/24/24 00:57, Jasmine Tang wrote:
Change the style from & to && to reflect boolean result with boolean
operation (instead of bitwise operation)
David Binderman 2017-07-01 13:24:44 UTC
trunk/gcc/cp/lex.c:116]: (style) Boolean result is used in bitwise operation.
Clarify expression with par
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here we end up with an initializer_list of 'aa', a type with a non-trivial
destructor, and need to destroy it. The code called
build_special_member_call for cleanups, but that doesn't work for arrays, so
use cxx_maybe_build_cleanup instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here AGGREGATE_TYPE_P includes pointers to member functions, which is not
what we want. Instead we should use class||array, as elsewhere in the
function.
PR c++/113598
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Don't u
On 1/25/24 14:14, Jakub Jelinek wrote:
Hi!
The following testcase reduced from GDB is miscompiled starting with
r14-5503 PR112427 change.
The problem is in the build_m_component_ref hunk, which changed
- datum = fold_build_pointer_plus (fold_convert (ptype, datum), component);
+ datum
On 1/25/24 20:36, Marek Polacek wrote:
Better version:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Real-world experience shows that -Wdangling-reference triggers for
user-defined std::span-like classes a lot. We can easily avoid that
by considering classes like
On 1/25/24 21:28, Nathaniel Shead wrote:
On Wed, Jan 24, 2024 at 03:24:42PM -0500, Jason Merrill wrote:
On 1/20/24 05:45, Nathaniel Shead wrote:
I also included
your change to only add class variable templates to 'pending_statics'
(and the normal 'static_decl's for non
On 1/26/24 10:49, Patrick Palka wrote:
On Fri, 26 Jan 2024, Nathaniel Shead wrote:
This patch just adds enough of the fields from 'function' to fix the ICE
in the linked PR. I suppose there might be more fields from this type
that should be propagated, but I don't know enough to find out which
On 1/25/24 20:37, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Since -Wdangling-reference has false positives that can't be
prevented, we should offer an easy way to suppress the warning.
Currently, that is only possible by using a #pragma, either ar
On 1/25/24 20:38, Marek Polacek wrote:
Low prio and not a regression. Feel free to ignore till GCC 15.
OK for stage 1.
Bootstrapped/regtested on x86_64-pc-linux-gnu.
-- >8 --
The PR complains that
void do_something(){
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored
On 12/5/23 20:52, Lewis Hyatt wrote:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
There are two related issues here really, a regression since GCC 11 where we
can ICE after restoring a PCH, and a deeper issue with bogus locations
assigned to macros that were defined prior to resto
On 1/25/24 14:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13? This isn't a very satisfactory fix, but at least
it safely fixes these testcases I guess. Note that there's
implementation disagreement about the second testcase, GCC always
On 1/26/24 16:52, Jason Merrill wrote:
On 1/25/24 14:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13? This isn't a very satisfactory fix, but at least
it safely fixes these testcases I guess. Note that there's
impl
On 1/26/24 17:11, Jason Merrill wrote:
On 1/26/24 16:52, Jason Merrill wrote:
On 1/25/24 14:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13? This isn't a very satisfactory fix, but at least
it safely fixes these testcases I
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
My earlier commit r14-278-gd60cbbfaa9a3ad was a start toward better
handling of local classes in generic lambdas, but isn't actually useful by
itself and breaks this testcase, so let's revert it for now.
PR c++/113544
gcc/cp/Change
On 1/29/24 15:53, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
Here when trying to unify P=42 A=T::value we ICE due to the latter's
empty type, which same_type_p dislikes. If the argument has empty type
then it can't be an
On 1/27/24 15:51, Nathaniel Shead wrote:
I don't provide a new test because this error only happens when there
are no include paths at all, and I haven't worked out a way to get this
to happen within DejaGNU (as it adds a number of `-B` and `-I` flags).
Bootstrapped and regtested on x86_64-pc-li
On 1/30/24 10:09, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this
look OK for trunk?
OK.
-- >8 --
We miscompile the below testcase because keep_unused_object_arg
duplicates the side effects of a (by-value) object argument of a
xobj member function.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When I added -fabi-compat-version=8 to avoid mangling aliases it also
suppressed the -Wabi warning.
PR c++/113451
gcc/testsuite/ChangeLog:
* g++.dg/abi/mangle-regparm1a.C: Use -Wabi=0.
---
gcc/testsuite/g++.dg/abi/mangle-
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As with r14-6796-g2fa122cae50cd8, avoid mangling compatibility aliases in
mangling tests, and test the new mangling.
PR c++/112846
gcc/testsuite/ChangeLog:
* g++.dg/abi/anon6.C: Specify ABI v18.
* g++.dg/abi/anon6a
On 1/30/24 12:14, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK.
-- >8 --
The original testcase from this PR (fixed by r14-8291) is rather
different from the others, so let's add it to the testsuite.
PR c++/67898
gcc/testsuite/ChangeLog:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
Since my r14-1500-g4d935f52b0d5c0 we promote an initializer_list backing
array to static storage where appropriate, but this happens after we decided
to add it to asan_poisoned_variables. As a result we add unpoison/poison
for it to the gimple.
501 - 600 of 11600 matches
Mail list logo
