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 a
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 su
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:
* com
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
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.
---
co
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 be
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 insertion
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
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 FU
From 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:
* cla
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
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 11/4/23 02:40, waffl3x wrote:
I'm unfortunately going down a rabbit hole again.
--function.h:608
```
/* If pointers to member functions use the least significant bit to
indicate whether a function is virtual, ensure a pointer
to this function will have that bit clear. */
#define MINI
plate
+void do_calls()
You probably want to instantiate the templates in these testcases to
make sure that works.
+// It's very hard to test for incorrect successes without requires, and by
extension a non dependent variable
+// so for the time being, there are no non dependent tes
On 11/5/23 10:06, waffl3x wrote:
I had wanted to write about some of my frustrations with trying to
write a test for virtual specifiers and errors/warnings for
shadowing/overloading virtual functions, but I am a bit too tired at
the moment and I don't want to delay getting this up for another nig
On 11/9/23 14:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we are wrongly parsing
int y(auto(42));
which uses the C++23 cast-to-prvalue feature, and initializes y to 42.
However, we were treating the auto as an implicit template paramet
On 11/8/23 16:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here when building up the non-dependent .* expression, we crash from
fold_convert on 'b.a' due to this (templated) COMPONENT_REF having an
IDENTIFIER_NODE instead of F
On 11/7/23 14:52, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The capture decltype handling in finish_decltype_type wasn't looking
through implicit INDIRECT_REF (added by convert_from_reference), which
caused us to incorrectly re
On 11/7/23 14:52, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
We usually don't see capture proxies in finish_decltype_type because
process_outer_var_ref is a no-op inside an unevaluated context and
so a use of a capture in
On 11/7/23 10:08, Patrick Palka wrote:
bootstrapped and regtested on x86_64-pc-linxu-gnu, does this look OK for trunk?
-- >8 --
In the COMPOUND_EXPR case of tsubst_expr, we were redundantly clearing
the tf_decltype flag when substituting the LHS and also neglecting to
propagate it when substitu
On 11/10/23 12:25, Patrick Palka wrote:
On Thu, 9 Nov 2023, Jason Merrill wrote:
On 11/7/23 10:08, Patrick Palka wrote:
bootstrapped and regtested on x86_64-pc-linxu-gnu, does this look OK for
trunk?
-- >8 --
In the COMPOUND_EXPR case of tsubst_expr, we were redundantly clearing
On 11/10/23 10:28, Patrick Palka wrote:
On Fri, 10 Nov 2023, Patrick Palka wrote:
On Thu, 9 Nov 2023, Jason Merrill wrote:
On 11/8/23 16:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here when building up the
[combined reply to all three threads]
On 11/9/23 23:24, waffl3x wrote:
I'm unfortunately going down a rabbit hole again.
--function.h:608
`/* If pointers to member functions use the least significant bit to indicate
whether a function is virtual, ensure a pointer to this function will have t
On 11/6/23 17:34, Marek Polacek wrote:
On Fri, Nov 03, 2023 at 01:51:07PM -0400, Jason Merrill wrote:
On 11/2/23 11:28, Marek Polacek wrote:
On Sat, Oct 14, 2023 at 12:56:11AM -0400, Jason Merrill wrote:
On 10/10/23 13:20, Marek Polacek wrote:
I suppose some
functions cannot possibly be
On 11/13/23 14:01, Jonathan Wakely wrote:
Tested x86_64-linux. Does this make sense for trunk?
OK, thanks.
These forbidden conversions are defined as narrowing conversions, and we
already use -Wnarrowing to control other "ill-formed, but only warn by
default" diagnostics required by the stand
On 11/10/23 20:13, Marek Polacek wrote:
On Thu, Nov 09, 2023 at 07:07:03PM -0500, Jason Merrill wrote:
On 11/9/23 14:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we are wrongly parsing
int y(auto(42));
which uses the C++23 cast
On 11/11/23 05:43, waffl3x wrote:
[combined reply to all three threads]
On 11/9/23 23:24, waffl3x wrote:
There are a few known issues still present in this patch. Most importantly,
the implicit object argument fails to convert when passed to by-value xobj
parameters. This occurs both for xobj
On 11/13/23 06:50, Jakub Jelinek wrote:
The following patch implements C++26 P2864R2 by emitting pedwarn enabled by
the same options as the C++20 and later warnings (i.e. -Wenum-compare,
-Wdeprecated-enum-enum-conversion and -Wdeprecated-enum-float-conversion
which are all enabled by default). I
On 11/14/23 02:33, Jakub Jelinek wrote:
Hi!
On Tue, Nov 14, 2023 at 08:23:27AM +0100, Jakub Jelinek wrote:
The following patch (in plaintext just a pseudo-patch where I've left out
the too big parts of either wget downloaded or regenerated files out with
..., full patch attached compressed) upd
On 11/3/23 14:58, Jakub Jelinek wrote:
On Thu, Nov 02, 2023 at 10:23:27PM -0400, Jason Merrill wrote:
Under the existing diagnostic I'd like to distinguish the different cases
more, e.g.
"multicharacter literal with %d characters exceeds 'int' size of %d bytes"
"
On 11/13/23 01:02, Iain Sandoe wrote:
The clang compiler supports essentially arbitrary, per-attribute, syntax and
token forms for attribute arguments. This extends to the case where token
forms are required to be accepted that are not part of the valid set for
standard C or C++.
A motivating
On 11/14/23 12:38, Jakub Jelinek wrote:
On Mon, Nov 13, 2023 at 10:59:52PM -0500, Jason Merrill wrote:
On 11/13/23 06:50, Jakub Jelinek wrote:
The following patch implements C++26 P2864R2 by emitting pedwarn enabled by
the same options as the C++20 and later warnings (i.e. -Wenum-compare
On 11/14/23 10:58, Marek Polacek wrote:
On Mon, Nov 13, 2023 at 09:26:41PM -0500, Jason Merrill wrote:
On 11/10/23 20:13, Marek Polacek wrote:
On Thu, Nov 09, 2023 at 07:07:03PM -0500, Jason Merrill wrote:
On 11/9/23 14:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu
On 11/14/23 10:43, Patrick Palka wrote:
On Fri, 10 Nov 2023, Jason Merrill wrote:
On 11/10/23 10:28, Patrick Palka wrote:
On Fri, 10 Nov 2023, Patrick Palka wrote:
On Thu, 9 Nov 2023, Jason Merrill wrote:
On 11/8/23 16:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc
On 11/14/23 16:04, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Here we're ICEing from strip_typedefs for the partially instantiated
requires-expression when walking its REQUIRES_EXPR_EXTRA_ARGS since it's
a TREE_LIST with
On 11/14/23 11:35, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
The NON_DEPENDENT_EXPR removal exposed that is_direct_enum_init may end
up checking convertibility of a type-dependent argument.
PR c++/112515
gcc/cp
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
require that the lambda has a capture default, unlike for decltype(x).
This patch fixes this i
On 11/1/23 11:07, Patrick Palka wrote:
On Tue, 31 Oct 2023, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Does it look OK for release branches as well for sake of PR111703?
-- >8 --
potential_constant_expression was incorrectly treating
On 11/15/23 17:24, Marek Polacek wrote:
On Tue, Nov 14, 2023 at 05:27:03PM -0500, Jason Merrill wrote:
On 11/14/23 10:58, Marek Polacek wrote:
On Mon, Nov 13, 2023 at 09:26:41PM -0500, Jason Merrill wrote:
On 11/10/23 20:13, Marek Polacek wrote:
On Thu, Nov 09, 2023 at 07:07:03PM -0500
On 11/15/23 13:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/13/12 (to match the PR107939 / r13-6525-ge09bc034d1b4d6 backports)?
-- >8 --
potential_constant_expression for a CALL_EXPR to a non-overload tests
FUNCTION_POINTER_TYPE_P on th
On 11/5/23 12:42, Jakub Jelinek wrote:
Hi!
check_field_decls for DECL_C_BIT_FIELD FIELD_DECLs with error_mark_node
TREE_TYPE continues early and doesn't call check_bitfield_decl which would
either set DECL_BIT_FIELD, or clear DECL_C_BIT_FIELD. So, the following
testcase ICEs after emitting tons
On 10/30/23 08:57, Richard Biener wrote:
We have a support case that shows GCC 7 sometimes creates
DW_TAG_label refering to itself via a DW_AT_abstract_origin
when using LTO. This for example triggers the sanity check
added below during LTO bootstrap.
Making this check cover more than just DW_A
On 11/11/23 03:22, Jakub Jelinek wrote:
Hi!
While filing a clang request to return 18 on _BitInts for
__builtin_classify_type instead of -1 they return currently, I've
noticed that we return -1 for vector types. I'm not convinced it is a good
idea to change behavior of __builtin_classify_type (
You recently pinged this patch, but I haven't seen an update since this
review?
On 10/26/23 21:21, Jason Merrill wrote:
On 9/18/23 13:21, Jakub Jelinek wrote:
Here is an updated version of the patch.
Compared to the last version, based on the discussion in the PR, the
patch
1) warns
On Sat, Nov 18, 2023 at 1:43 AM waffl3x wrote:
>
> The patch is coming along, I just have a quick question regarding
> style. I make use of IILE's (immediately invoked lambda expression) a
> whole lot in my own code. I know that their use is controversial in
> general so I would prefer to ask inst
On 11/19/23 08:39, waffl3x wrote:
Funny enough I ended up removing the ones I was thinking about, seems
to always happen when I ask style questions but I'm glad to hear it's
okay going forward.
I'm having trouble fixing this bug, based on what Gasper said in
PR102609 I am pretty sure I know what
On 11/19/23 13:36, waffl3x wrote:
I'm having trouble fixing the error for this case, the control flow
when the functions are overloaded is much more complex.
struct S {
void f(this S&) {}
void f(this S&, int)
void g() {
void (*fp)(S&) = &f;
}
};
This seemed to have fixed the n
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Let's use a more informative name instead of DECL_VIRTUAL_P directly.
gcc/cp/ChangeLog:
* cp-tree.h (DECL_TEMPLATE_PARM_CHECK): New.
(DECL_IMPLICIT_TEMPLATE_PARM_P): New.
(decl_template_parm_check): New.
* m
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
There should never be a reason to compare more than one level of template
parameters; additional levels are for the enclosing context, which is either
irrelevant (for a template template parameter) or already compared (for a
member template)
Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I
push this?
-- 8< --
Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and
https://github.com/itanium-cxx-abi/cxx-abi/pull/166
We need to mangle constraints to be able to distinguish between function
templates tha
On 11/19/23 16:44, waffl3x wrote:
On Sunday, November 19th, 2023 at 1:34 PM, Jason Merrill
wrote:
On 11/19/23 13:36, waffl3x wrote:
I'm having trouble fixing the error for this case, the control flow
when the functions are overloaded is much more complex.
struct S {
void f(t
On 11/19/23 02:38, Alexandre Oliva wrote:
__dt_base doesn't get its body from a maybe_return_this caller, it's
rather cloned with the full body within build_clone, and then it's
left alone, without going through finish_function_body or
build_delete_destructor_body, that call maybe_return_this.
On 11/19/23 02:28, Alexandre Oliva wrote:
When targetm.cxx.cdtor_return_this() holds, cdtors have a
non-VOID_TYPE_P result, but IMHO this ABI implementation detail
shouldn't leak to the abstract language conceptual framework, in which
cdtors don't have return values. For contracts, specifically
On 11/19/23 21:33, Alexandre Oliva wrote:
Unlike C, C++ doesn't mark enums shortened by -fshort-enums as packed.
This makes for undesirable warning differences between C and C++,
e.g. c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early*.c
triggers a warning about a type cast fro
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
pointers and references in constant expressions. (Note that R4 seems to
only allow References to unknown/Accesses v
On 11/17/23 09:50, Alex Coplan wrote:
Hi,
This is a v5 patch to address Marek's feedback here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635157.html
I also implemented Jason's suggestion to use constexpr for the tables
from this review:
https://gcc.gnu.org/pipermail/gcc-patches/20
On 11/15/23 00:13, Sam James wrote:
Florian Weimer writes:
* Sam James:
Florian Weimer writes:
Most -Wimplicit-int warnings were unconditionally disabled for system
headers. Only missing types for parameters in old-style function
definitions resulted in warnings. This is inconsistent with
On 11/21/23 12:17, Jakub Jelinek wrote:
On Thu, Oct 26, 2023 at 09:21:47PM -0400, Jason Merrill wrote:
On 9/18/23 13:21, Jakub Jelinek wrote:
Here is an updated version of the patch.
Compared to the last version, based on the discussion in the PR, the patch
1) warns (but only that) if size
On 11/21/23 08:04, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
Hopefully this patch is legible enough for reviewing purposes, I've not
been feeling the greatest so it was a task to get this finished.
Tomorrow I will look at putting the diagnostics in
start_prepars
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In review of the deducing 'this' patch, it came up that the logic in
start_preparsed_function around the ctype variable was convoluted, being
set for non-static member functions and friends, but not for static member
functions. Let's set it
On 11/21/23 17:51, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:19:56PM +0100, Jakub Jelinek wrote:
+ error_at (location, "% message must be a string "
+ "literal or object with % and "
+ "% members");
Let's print the type of t
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):
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 the
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 ki
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 tha
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 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
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
nces. I've 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 u
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 fnt
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. This
On 11/26/23 20:44, waffl3x wrote:
The other problem I'm having is
auto f0 = [n = 5, &m](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 d
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 t
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
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 GXX_TESTSUITE_STD
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[] =
+{
+ { "cxx_except
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
10:47:45.0
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 cp_feature_inf
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 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 does
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 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/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/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 accessibl
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 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 uncondit
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 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 con
adjustment I was talking about, since that function basically 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.
c
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 (LAMBDA_
On 9/19/23 09:01, Marek Polacek wrote:
On Mon, Sep 18, 2023 at 09:36:31PM -0400, Jason Merrill wrote:
On 9/18/23 17:42, Marek Polacek wrote:
+ /* The purpose of this is not to emit errors for mce_unknown. */
+ const tsubst_flags_t complain = (data->flags == ff_fold_immedi
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In this testcase, it seems clear that B should be trivially
default-constructible, since the inherited default constructor is trivial
and there are no other subobjects to initialize. But we were saying no
because we don't define triviality
On 8/3/23 05:21, Alex Coplan wrote:
Hi,
This patch implements clang's __has_feature and __has_extension in GCC.
This is a v3 which addresses feedback for the v2 patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626058.html
Main changes since v2:
- As per Jason's feedba
On 9/15/23 19:51, Ken Matsui via Gcc-patches wrote:
Now that RID_MAX has reached 255, we need to update the bit sizes of every
use of the enum rid from 8 to 16 to support more keywords.
Sorry to bring this up so late, but this does raise the question of
whether we actually want to use keyword
On 9/19/23 12:40, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
OK for trunk. What's your argument for backporting?
-- >8 --
1. Move class NTTP object pretty printing to a more general spot in
the pretty printer.
2. Print the type of an class NTTP o
On 9/19/23 11:04, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
This patch makes tsubst_template_decl use use_spec_table=false also in
the non-class non-function template case, to avoid computing 'argvec' and
doing a hash table loo
On 9/11/23 09:49, waffl3x via Gcc-patches wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
Hopefully I fixed all the issues. I also took the opportunity to remove the
small mistake present in v1, so that is no longer a concern.
Thanks again for all the patience.
-Alex
Th
On 8/31/23 04:33, Jakub Jelinek wrote:
On Thu, Aug 31, 2023 at 06:02:36AM +, waffl3x via Gcc-patches wrote:
+++ b/gcc/testsuite/g++.dg/cpp23/explicit-object-param-valid2.C
@@ -0,0 +1,24 @@
+// P0847R7
+// { dg-do run { target c++23 } }
This raises an important question whether we as an ex
On 9/6/23 06:20, Javier Martinez wrote:
reminder: ready for commit?
Pushed, thanks!
- Javier
On Wed 23. Aug 2023 at 15:02, Javier Martinez
<mailto:javier.martinez.bugzi...@gmail.com>> wrote:
On Tue, Aug 22, 2023 at 7:50 PM Jason Merrill mailto:ja...@redhat.com>> wr
On 9/1/23 08:22, Nathaniel Shead wrote:
On Wed, Aug 30, 2023 at 04:28:18PM -0400, Jason Merrill wrote:
On 8/29/23 09:35, Nathaniel Shead wrote:
This is an attempt to improve the constexpr machinery's handling of
union lifetime by catching more cases that cause UB. Is this approach
OK?
701 - 800 of 11600 matches
Mail list logo
