Tested x86_64-pc-linux-gnu. Does this make sense? Did you have another theory
about how to merge these?
-- 8< --
Doing a dynamic_cast in both TUs broke because we were declaring a new
__class_type_info in _b that conflicted with the one imported in the global
module from _a.
On 12/17/23 16:51, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
An alternative approach for the lambda issue would be to modify
'maybe_add_lambda_conv_op' to not pass a null pointer, but I wasn't sure
what the best approach for that would be.
I don't
On 12/15/23 19:20, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu with GLIBCXX_TESTSUITE_STDS=20
and RUNTESTFLAGS="--target_board=unix/-D_GLIBCXX_USE_CXX11_ABI=0".
OK, thanks.
-- >8 --
My previous patch (naively) assumed that a TREE_CODE of RECORD_TYPE or
On 12/14/23 19:59, Patrick Palka wrote:
On Thu, 14 Dec 2023, Jason Merrill wrote:
On 12/14/23 16:08, Patrick Palka wrote:
On Thu, 14 Dec 2023, Jason Merrill wrote:
On 12/14/23 14:17, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Do we
On 12/14/23 16:08, Patrick Palka wrote:
On Thu, 14 Dec 2023, Jason Merrill wrote:
On 12/14/23 14:17, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Do we want to condition this on abi_check (19)?
I think we do, sadly.
Sounds good
On 12/14/23 16:02, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
This is sort of like r14-5514, but at block scope. Consider
struct A { A(int, int); };
void
g (int a)
{
A bar(auto(a), 42); // not a fn decl
}
where we
On 12/14/23 16:01, Marek Polacek wrote:
On Wed, Dec 13, 2023 at 03:28:38PM -0500, Jason Merrill wrote:
On 12/12/23 17:48, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote:
On 12/8/23 16:15, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason
On 12/14/23 14:17, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
The section attribute currently has no effect on templates because the
call to set_decl_section_name only happens at parse time and not also at
instantiation
On 12/14/23 14:17, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Do we want to condition this on abi_check (19)?
I think we do, sadly.
-- >8 --
As with other declaration attributes, we need to look through
TEMPLATE_DECL when looking up
On 11/27/23 10:58, Patrick Palka wrote:
gcc/cp/ChangeLog:
* cp-tree.h (type_targs_deducible_from): Adjust return type.
* pt.cc (alias_ctad_tweaks): Handle C++23 inherited CTAD.
(inherited_ctad_tweaks): Define.
(type_targs_deducible_from): Return the deduced
On 12/13/23 19:00, Marek Polacek wrote:
On Wed, Dec 13, 2023 at 11:47:37AM -0500, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When building an AGGR_INIT_EXPR from a CALL_EXPR, we shouldn't lose location
information.
I think the following should be an obvi
On 12/12/23 17:48, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote:
On 12/8/23 16:15, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote:
On 12/5/23 15:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu
On 12/12/23 16:21, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
OK.
-- >8 --
When unifying constants we need to generally treat constants of
different types but same value as different, in light of auto template
parameters. This patch
On 12/13/23 03:39, Jakub Jelinek wrote:
Hi!
On the c-c++-common/cpp/pr88974.c testcase I'm seeing
==600549== Conditional jump or move depends on uninitialised value(s)
==600549==at 0x1DD3A05: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.cc:3050)
==600549==by 0x1DBFC7F:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
My r14-6505-g52b4b7d7f5c7c0 change to copy the location in
build_aggr_init_expr reopened PR96997; let's fix it properly this time, by
clearing the location like we do for other trees.
PR c++/96997
gcc/cp/ChangeLog:
*
On 12/13/23 11:26, Jakub Jelinek wrote:
On Wed, Dec 13, 2023 at 11:24:42AM -0500, Jason Merrill wrote:
gcc/testsuite/ChangeLog:
* g++.dg/pr112822.C: Require C++17.
---
gcc/testsuite/g++.dg/pr112822.C | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/g++.dg/pr112822.C
On 12/13/23 04:49, Jakub Jelinek wrote:
Hi!
With valgrind checking, there are various errors reported on some C++26
libstdc++ tests, like:
==2009913== Conditional jump or move depends on uninitialised value(s)
==2009913==at 0x914C59: gt_ggc_mx_lang_tree_node(void*) (gt-cp-tree.h:107)
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When testing the proposed patch for PR71093 I noticed that it changed the
diagnostic for consteval-prop6.C. I then noticed that the diagnostic wasn't
very helpful either way; it was complaining about modification of the 'x'
variable, but
Tested x86_64-pc-linux-gnu, applying to trunk.
This is modified from Nathaniel's last version by adjusting for my recent
CLOBBER changes and removing the special handling of __in_chrg which is no
longer needed since my previous commit.
-- 8< --
This patch adds checks for using objects after
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I was puzzled by the proposed patch for PR71093 specifically ignoring the
in-charge parameter; the problem turned out to be that when
cxx_eval_call_expression jumps from the clone to the cloned function, it
assumes that the latter has the
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When building an AGGR_INIT_EXPR from a CALL_EXPR, we shouldn't lose location
information.
gcc/cp/ChangeLog:
* tree.cc (build_aggr_init_expr): Copy EXPR_LOCATION.
gcc/testsuite/ChangeLog:
*
On 12/12/23 21:36, Jason Merrill wrote:
On 12/12/23 17:50, Peter Bergner wrote:
On 12/12/23 1:26 PM, Richard Biener wrote:
Am 12.12.2023 um 19:51 schrieb Peter Bergner :
On 12/12/23 12:45 PM, Peter Bergner wrote:
+/* PR target/112822 */
Oops, this should be:
/* PR tree-optimization
On 12/12/23 12:50, Jason Merrill wrote:
On 12/12/23 10:24, Jason Merrill wrote:
On 12/12/23 06:15, Jakub Jelinek wrote:
On Tue, Dec 12, 2023 at 02:13:43PM +0300, Alexander Monakov wrote:
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill
On 12/12/23 17:50, Peter Bergner wrote:
On 12/12/23 1:26 PM, Richard Biener wrote:
Am 12.12.2023 um 19:51 schrieb Peter Bergner :
On 12/12/23 12:45 PM, Peter Bergner wrote:
+/* PR target/112822 */
Oops, this should be:
/* PR tree-optimization/112822 */
It's fixed on my end.
Ok
Pushed
c762599f112aa3b3c35c6aaac5856560d9282eb0 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Tue, 12 Dec 2023 14:41:39 -0500
Subject: [PATCH] c++: class hotness attribute and member template
To: gcc-patches@gcc.gnu.org
The FUNCTION_DECL check ignored member function templates.
gcc/cp/ChangeLog:
* class.cc
On 12/12/23 13:40, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
I considered removing the is_overloaded_fn test now as
well, but it could in theory be hit (and not subsumed by the
type_unknown_p test) for e.g. OVERLOAD of a single
On 12/12/23 10:24, Jason Merrill wrote:
On 12/12/23 06:15, Jakub Jelinek wrote:
On Tue, Dec 12, 2023 at 02:13:43PM +0300, Alexander Monakov wrote:
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
In discussion of PR71093 it came up
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This testcase uses variable templates, a C++14 feature.
gcc/testsuite/ChangeLog:
* g++.dg/ext/is_nothrow_constructible8.C: Require C++14.
---
gcc/testsuite/g++.dg/ext/is_nothrow_constructible8.C | 2 +-
1 file changed, 1
On 12/12/23 06:15, Jakub Jelinek wrote:
On Tue, Dec 12, 2023 at 02:13:43PM +0300, Alexander Monakov wrote:
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
In discussion of PR71093 it came up that more clobber_kind options would
OK for trunk?
-- 8< --
I thought it could be easier to use check_GNU_style.py. With this alias,
'git gcc-style' will take a git revision as argument instead of a file, or
check HEAD if no argument is given.
contrib/ChangeLog:
* gcc-git-customization.sh: Add git gcc-style alias.
---
On 12/11/23 14:21, Marek Polacek wrote:
On Mon, Dec 11, 2023 at 08:17:22PM +0100, Richard Biener wrote:
Am 11.12.2023 um 20:12 schrieb Jason Merrill :
Maybe something like this? Or shall we write out the names like
CLOBBER_OBJECT_START, CLOBBER_STORAGE_END, etc?
Yeah, the abbreviations
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Since r14-6064-gc3f281a0c1ca50 this test was checking for the wrong
mangling, but it still passed on targets that support ABI compatibility
aliases. Let's avoid generating those aliases when checking mangling.
gcc/ChangeLog:
*
On 12/11/23 03:02, Richard Biener wrote:
On Sun, 10 Dec 2023, Jason Merrill wrote:
On 12/10/23 05:22, Richard Biener wrote:
Am 09.12.2023 um 21:13 schrieb Jason Merrill :
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure
On 12/11/23 03:49, FX Coudert wrote:
Hi Marek,
The patch is causing three failures on x86_64-apple-darwin21:
FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler
_Z1gI1XEvT_
FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler
_Z1gI1YEvT_
I think these
On 12/10/23 21:04, Nathaniel Shead wrote:
On Sat, Dec 09, 2023 at 03:40:44PM -0500, Jason Merrill wrote:
On 11/27/23 06:07, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634626.html.
I've been made aware since constructing this patch of CWG2820, which
On 11/30/23 10:46, Patrick Palka wrote:
On Fri, 27 Oct 2023, Patrick Palka wrote:
On Fri, 27 Oct 2023, Jason Merrill wrote:
On 10/27/23 15:55, Patrick Palka wrote:
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g
:
From fa99f7d12b87f36d3c38349fcdcfca074564858d Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Sun, 10 Dec 2023 14:20:32 -0500
Subject: [PATCH] doc: small tweak
To: gcc-patches@gcc.gnu.org
Mention Objective-C++ here to be consistent with the surrounding C/ObjC
lines.
gcc/ChangeLog:
* doc
On 12/10/23 10:22, waffl3x wrote:
On Friday, December 8th, 2023 at 12:25 PM, Jason Merrill
wrote:
On 12/6/23 02:33, waffl3x wrote:
Here is the next version, it feels very close to finished. As before, I
haven't ran a bootstrap or the full testsuite yet but I did run the
explicit-obj tests
On 11/23/23 08:40, Nathaniel Shead wrote:
Sorry, I just noticed I hadn't actually filled in the changelog. It
should say "Clear DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P."
OK with that change.
On Thu, Nov 23, 2023 at 11:54 PM Nathaniel Shead
wrote:
Bootstrapped and regtested on
On 12/10/23 05:22, Richard Biener wrote:
Am 09.12.2023 um 21:13 schrieb Jason Merrill :
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF
was a formatting
fix, the lats was using TYPE_PTRDATAMEM_P for CPTK_IS_MEMBER_OBJECT_POINTER.
I'm leaving the library patches for library folks to apply.
Thanks!
Jason
From e410303f768fa7b020e46f3bd7d28381144e5340 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Fri, 8 Dec 2023 15:55:49
On 11/24/23 13:09, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
A rewritten guide for alias CTAD isn't really a specialization of the
original guide, so we shouldn't register it as such. This avoids an ICE
in the below
On 11/27/23 06:07, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634626.html.
I've been made aware since constructing this patch of CWG2820, which has
a proposed resolution that would change the result of the testcase
'noexcept(yesthrow_t())' (and
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to have
broken by doing this and I wasn't able to find
On 12/8/23 16:15, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote:
On 12/5/23 15:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This test shows that we cannot clear *walk_subtrees in
cp_fold_immediate_r w
On 12/5/23 12:17, Marek Polacek wrote:
On Tue, Dec 05, 2023 at 06:00:31PM +0100, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 09:45:32AM -0500, Marek Polacek wrote:
When working on the previous patch I put [[]] [[]] asm (""); into a
testcase, but was surprised it wasn't parsed.
By wasn't
On 12/8/23 12:53, Jakub Jelinek wrote:
On Fri, Dec 08, 2023 at 12:06:01PM -0500, Jason Merrill wrote:
@@ -2,7 +21116,7 @@ cp_parser_elaborated_type_specifier (cp_
}
else if (is_declaration && cp_parser_declares_only_class_p (parser))
cplus_decl_at
On 12/8/23 12:35, Jakub Jelinek wrote:
On Fri, Dec 08, 2023 at 11:51:19AM -0500, Jason Merrill wrote:
Do we want to do the same for TARGET_EXPR, since those are handled like
SAVE_EXPR in mostly_copy_tree_r?
In mostly_copy_tree_r yes, but I don't see cp_fold doing anything for
TARGET_EXPRs
https://godbolt.org/z/r6v4e1ePP
Here's a patch to adjust all the remaining
DECL_NONSTATIC_MEMBER_FUNCTION_P. With this patch -diagnostic7.C gets
the old address of non-static diagnostic, I think correctly, so I'm not
sure we still need the BASELINK change in cp_build_addr_expr_1?
JasonFrom
On 12/5/23 15:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This test shows that we cannot clear *walk_subtrees in
cp_fold_immediate_r when we're in_immediate_context, because that,
as the comment says, affects cp_fold_r as well. Here we had an
On 12/6/23 09:10, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 11:01:20AM -0500, Jason Merrill wrote:
And there is another thing I wonder about: with -Wno-attributes= we are
supposed to ignore the attributes altogether, but we are actually still
warning about them when we emit these generic
On 12/7/23 04:28, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled because two ubsan instrumentations
run into each other.
The first one is the shift instrumentation. Before the C++ FE calls
it, it wraps the 2 shift arguments with cp_save_expr, so that side-effects
in them aren't
On 12/6/23 01:02, waffl3x wrote:
On Tuesday, December 5th, 2023 at 9:36 PM, Jason Merrill
wrote:
On 12/5/23 23:23, waffl3x wrote:
Does CWG2834 effect this weird edge case?
2834 affects all partial ordering with explicit object member functions;
Both in relation to each other
On 12/5/23 23:23, waffl3x wrote:
Does CWG2834 effect this weird edge case?
2834 affects all partial ordering with explicit object member functions;
currently the working draft says that they get an additional fake object
parameter, which is clearly wrong.
I couldn't quite grasp the
Tested x86_64-pc-linux-gnu. Are the library test changes OK? A reduced
example of the issue is at https://godbolt.org/z/cPxrcnKjG
-- 8< --
Looks like we implemented option 1 (skip the object parameter) for CWG532
before the issue was resolved, and never updated to the final resolution of
On 12/5/23 11:03, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:07:19AM -0500, Jason Merrill wrote:
Please. Maybe check_pragma_unroll? check_unroll_factor?
So like this (assuming it passes bootstrap/regtest, so far passed just
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g
On 12/5/23 02:40, Jakub Jelinek wrote:
Hi!
Seems in 2017 attribute-specifier-seq[opt] was added to asm-declaration
and the change was voted in as a DR.
The following patch implements it by parsing the attributes and warning
about them.
I found one attribute parsing bug I'll send a fix for
On 12/5/23 01:55, Jakub Jelinek wrote:
Hi!
When committing the #pragma GCC unroll patch, I found I forgot one spot
for diagnosting the invalid unrolls - if #pragma GCC unroll argument is
dependent and the pragma is before a range for loop, the unroll tree (now,
before one converted form ushort)
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Mentioning a noreturn function does not involve an lvalue-rvalue
conversion.
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1): Fix
check for loading volatile lvalue.
gcc/testsuite/ChangeLog:
*
On 12/4/23 15:23, Marek Polacek wrote:
+/* FN is not a consteval function, but may become one. Remember to
+ escalate it after all pending templates have been instantiated. */
+
+void
+maybe_store_immediate_escalating_fn (tree fn)
+{
+ if (unchecked_immediate_escalating_function_p (fn))
+
On 12/2/23 05:51, Jakub Jelinek wrote:
Hi!
foo in the unroll-5.C testcase ICEs because cp_parser_pragma_unroll
during parsing calls maybe_constant_value unconditionally, which is
fine if !processing_template_decl, but can ICE otherwise.
While just calling fold_non_dependent_expr there instead
On 12/1/23 17:42, Patrick Palka wrote:
On Fri, 1 Dec 2023, Jason Merrill wrote:
On 12/1/23 12:32, Patrick Palka wrote:
On Tue, 14 Nov 2023, Jason Merrill wrote:
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- &g
On 12/1/23 20:31, waffl3x wrote:
On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill
wrote:
On 12/1/23 01:02, waffl3x wrote:
I ran into another issue while devising tests for redeclarations of
xobj member functions as static member functions and vice versa. I am
pretty sure
On 12/1/23 18:37, Marek Polacek wrote:
On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote:
On 11/23/23 11:46, Marek Polacek wrote:
v5 greatly simplifies the code.
Indeed, it's much cleaner now.
I still need a new ff_ flag to signal that we can return immediately
after seeing
On 12/1/23 15:40, Alexandre Oliva wrote:
On Nov 9, 2023, Jonathan Wakely wrote:
On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva wrote:
g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run
On 12/1/23 12:32, Patrick Palka wrote:
On Tue, 14 Nov 2023, Jason Merrill wrote:
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For decltype((x)) within a lambda where x is not captured, we dubiously
requ
On 12/1/23 01:02, waffl3x wrote:
I ran into another issue while devising tests for redeclarations of
xobj member functions as static member functions and vice versa. I am
pretty sure by the literal wording of the standard, this is well formed.
template
concept Constrain = true;
struct S {
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
More adjustments to allow for explicit object parameters in lambdas. This
has no practical effect until that patch goes in, but applying this
separately seems reasonable.
gcc/cp/ChangeLog:
* semantics.cc
On 11/23/23 11:46, Marek Polacek wrote:
v5 greatly simplifies the code.
Indeed, it's much cleaner now.
I still need a new ff_ flag to signal that we can return immediately
after seeing an i-e expr.
That's still not clear to me:
+ /* In turn, maybe promote the function we find
On 11/29/23 17:01, Marek Polacek wrote:
On Wed, Nov 29, 2023 at 03:28:44PM -0500, Jason Merrill wrote:
On 11/29/23 12:43, Marek Polacek wrote:
On Wed, Nov 29, 2023 at 12:23:46PM -0500, Patrick Palka wrote:
On Wed, 29 Nov 2023, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux
On 11/30/23 01:36, waffl3x wrote:
On Wednesday, November 29th, 2023 at 10:00 PM, Jason Merrill
wrote:
On 11/27/23 00:35, waffl3x wrote:
+ val = handle_arg(TREE_VALUE (parm),
Missing space.
Is there a script I can use for this so I'm not wasting your time on
little typos like this one
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In review of the deducing 'this' patch it came up that LAMBDA_EXPR_MUTABLE_P
doesn't make sense for a lambda with an explicit object parameter. And it
was never necessary, so let's remove it.
gcc/cp/ChangeLog:
* cp-tree.h
returns
the TREE_TYPE of the COMPONENT_REF. But the underlying problem is that
finish_non_static_data_member assumes that 'object' is '*this', for
which you can trust the cv-quals; for auto&&, you can't.
capture_decltype has the same problem. I'm attaching a patch to address
this in both places.
On 11/29/23 14:42, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for
trunk?
OK.
-- >8 --
We need to consistently look through implicit INDIRECT_REF when
setting/checking for -Wparentheses warning suppression. In passing
use STRIP_REFERENCE_REF
On 11/29/23 13:56, Marek Polacek wrote:
On Mon, Nov 20, 2023 at 04:29:33PM -0500, Jason Merrill wrote:
On 11/17/23 16:46, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch is an attempt to implement (part of?) P2280, Using unknown
point
On 11/29/23 12:43, Marek Polacek wrote:
On Wed, Nov 29, 2023 at 12:23:46PM -0500, Patrick Palka wrote:
On Wed, 29 Nov 2023, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Now that I'm posting this patch, I think you'll probably want me to use
ba_any
On 11/29/23 04:39, Alexandre Oliva wrote:
Hello, Jason,
On Nov 22, 2023, Jason Merrill wrote:
On 11/22/23 13:12, Jason Merrill wrote:
I'm coming to the conclusion that your C++ patch is fine but we
should remove the TYPE_PACKED warning from
check_address_or_pointer_of_packed_member
On 11/29/23 10:45, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Now that I'm posting this patch, I think you'll probably want me to use
ba_any unconditionally. That works too; g++.dg/tc1/dr52.C just needs
a trivial testsuite tweak:
'C' is not an
On 11/29/23 13:01, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 11:27:55AM -0500, Jason Merrill wrote:
On 11/24/23 03:34, Jakub Jelinek wrote:
On Mon, Sep 18, 2023 at 07:12:40PM +0200, Jakub Jelinek via Gcc-patches wrote:
On Tue, Aug 22, 2023 at 09:39:11AM +0200, Jakub Jelinek via Gcc-patches
On 11/28/23 12:52, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 11:31:48AM -0500, Jason Merrill wrote:
+ if (len)
+ {
+ if (data)
+ msg = c_getstr (data);
+ if (msg == NULL)
+ buf = XNEWVEC (char, len
On 11/28/23 11:51, Patrick Palka wrote:
This adds a sanity check to cp_parser_expression_statement similar to
the one in finish_expr_stmt added by r6-6795-g0fd9d4921f7ba2, which
effectively downgrades accepts-invalid/wrong-code bugs like this one
into ice-on-invalid/ice-on-valid ones.
OK.
On 11/28/23 11:51, Patrick Palka wrote:
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we deem the array-to-pointer conversions in both calls as invalid,
but we fail to issue a diagnostic for the second call, ultimately because
cp_build_c_cast
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
My change for PR53220 made array to pointer decay for prvalue arrays
ill-formed to catch well-defined C code that produces a dangling pointer in
C++ due to the shorter lifetime of compound literals. This wasn't really
correct, but wasn't a
On 11/28/23 12:12, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 04:45:41PM +, Alex Coplan wrote:
--- gcc/cp/cp-objcp-common.cc.jj2023-11-27 17:34:25.0 +0100
+++ gcc/cp/cp-objcp-common.cc 2023-11-28 08:55:18.868419864 +0100
@@ -145,7 +145,7 @@ static constexpr
On 11/28/23 12:08, Thomas Schwinge wrote:
Hi!
On 2023-11-23T09:32:24+0100, Jakub Jelinek wrote:
Here is what I've committed
--- gcc/testsuite/g++.dg/cpp26/static_assert1.C.jj2023-11-22
10:17:41.340064988 +0100
+++ gcc/testsuite/g++.dg/cpp26/static_assert1.C 2023-11-22
On 11/28/23 11:03, Thomas Schwinge wrote:
Hi!
On 2023-11-17T14:50:45+, Alex Coplan wrote:
--- a/gcc/cp/cp-objcp-common.cc
+++ b/gcc/cp/cp-objcp-common.cc
+/* Table of features for __has_{feature,extension}. */
+
+static constexpr cp_feature_info cp_feature_table[] =
+{
+ {
On 11/28/23 03:22, Jakub Jelinek wrote:
On Mon, Nov 27, 2023 at 10:58:04AM +, Alex Coplan wrote:
Many thanks both for the reviews, this is now pushed (with Jason's
above changes implemented) as g:06280a906cb3dc80cf5e07cf3335b758848d488d.
The new test FAILs everywhere with
On 11/23/23 03:32, Jakub Jelinek wrote:
On Wed, Nov 22, 2023 at 04:53:48PM -0500, Jason Merrill wrote:
I agree it's weird to get two of the same error, but maybe instead of
duplicating the error, we could look up data only if size succeeded, and
then error once if either failed?
Here is what
On 11/24/23 03:34, Jakub Jelinek wrote:
On Mon, Sep 18, 2023 at 07:12:40PM +0200, Jakub Jelinek via Gcc-patches wrote:
On Tue, Aug 22, 2023 at 09:39:11AM +0200, Jakub Jelinek via Gcc-patches wrote:
The following patch implements the C++26 P2169R4 paper.
As written in the PR, the patch expects
On 11/26/23 20:44, waffl3x wrote:
The other problem I'm having is
auto f0 = [n = 5, ](this auto const&){ n = 10; };
This errors just fine, the lambda is unconditionally const so
LAMBDA_EXPR_MUTABLE_P flag is set for the closure.
This on the other hand does not. The constness of the captures
On 11/26/23 18:10, waffl3x wrote:
On Sunday, November 26th, 2023 at 2:30 PM, Jason Merrill
wrote:
On 11/24/23 20:14, waffl3x wrote:
OKAY, I figured out SOMETHING, I think this should be fine. As noted in
the comments, this might be a better way of handling the static lambda
case too
On 11/24/23 20:14, waffl3x wrote:
OKAY, I figured out SOMETHING, I think this should be fine. As noted in
the comments, this might be a better way of handling the static lambda
case too. This is still a nasty hack so it should probably be done
differently, but I question if making a whole new
been working on this about 8 hours today and I'm a
little defeated after discovering this.
commit 39ade88fa1632c659c5c4ed065fa2b62d16a8670
Author: Jason Merrill
Date: Tue Jan 24 15:29:35 2023 -0500
c++: static lambda in template [PR108526]
tsubst_lambda_expr uses build_memfn_type
On 11/22/23 05:00, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 10:51:36PM -0500, Jason Merrill wrote:
Actually, let's go back to the previous message, but change the tf_nones
above to 'complain' so that we see those errors and then this explanation.
Likewise with the conversion checks later
On 11/22/23 13:12, Jason Merrill wrote:
On 11/22/23 03:17, Alexandre Oliva wrote:
On Nov 20, 2023, Jason Merrill wrote:
I think the warning is wrong here.
Interesting... Yeah, your analysis makes perfect sense.
Still, we're left with a divergence WRT the TYPE_PACKED status of enum
types
On 11/22/23 15:46, waffl3x wrote:
On Tuesday, November 21st, 2023 at 8:22 PM, Jason Merrill
wrote:
On 11/21/23 08:04, waffl3x wrote:
/* Nonzero for FUNCTION_DECL means that this decl is a non-static
- member function. */
+ member function, use DECL_IOBJ_MEMBER_FUNC_P instead. */
#define
On 11/22/23 12:26, Patrick Palka wrote:
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk/13?
OK.
-- >8 --
The entering_scope adjustment in tsubst_aggr_type assumes if an alias is
dependent, then so is the aliased type (and therefore it has template info)
but
On 11/22/23 03:17, Alexandre Oliva wrote:
On Nov 20, 2023, Jason Merrill wrote:
I think the warning is wrong here.
Interesting... Yeah, your analysis makes perfect sense.
Still, we're left with a divergence WRT the TYPE_PACKED status of enum
types between C and C++.
It sort of kind
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
-Waddress-of-packed-member, in addition to the documented warning about
taking the address of a packed member, also warns about casting from
a pointer to a TYPE_PACKED type to a pointer to a type with greater
alignment.
This wrongly warns if
Following the last patch, let's rename the functions to reflect the change
in behavior.
gcc/c-family/ChangeLog:
* c-warn.cc (check_address_or_pointer_of_packed_member):
Rename to check_address_of_packed_member.
(check_and_warn_address_or_pointer_of_packed_member):
601 - 700 of 11376 matches
Mail list logo
