I had been thinking about DR1286 "equivalence" as meaning generally
interchangeable, but looking back at the proposed resolution in the context
of this PR, I see that it's just about use as a template argument. So let's
give a pedwarn if we look through a renaming alias.
Tested
We were failing to declare class S in the global namespace because we were
treating the requires-expression parameter scope as a normal block scope, so
the implicit declaration went there.
It seems to me that the requires parameter scope is more like a function
parameter scope (not least in the
Since olddecl isn't a definition, it doesn't get DECL_FRIEND_CONTEXT, so we
need to copy it from newdecl when we merge the declarations.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101894
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Copy DECL_FRIEND_CONTEXT.
The suggested resolution for CWG1286, which we implemented, ignores default
template arguments, but this PR is an example of why that doesn't make
sense: the templates aren't functionally equivalent.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/103852
DR 1286
On 3/30/22 09:06, Benno Evers via Gcc-patches wrote:
From: Benno Evers
When finishing a function that is a coroutine, the function is
transformed into a "ramp" function, and the original user-provided
function body gets moved into a newly created "actor" function.
In this case
On 3/30/22 17:51, Patrick Palka wrote:
Here deduction for the P/A pair V/a spuriously fails with
types ‘A’ and ‘const A’ have incompatible cv-qualifiers
because the argument type is const, whereas the parameter type is
non-const.
Since the type of an NTTP is always cv-unqualified, it seems
On 3/30/22 18:28, Marek Polacek wrote:
When g++ emits
warning: overflow in conversion from 'int' to 'char' changes value from '300'
to '',''
for code like "char c = 300;" it might raise a few eyebrows. With this
warning we're not interested in the ASCII representation of the char, only
the
On 4/1/22 11:17, Patrick Palka wrote:
An implicit guide already inherits the (rewritten) constraints of the
constructor. Thus it seems natural that the guide must also inherit
the constraints of the class template, since a constructor's constraints
might assume the class's constraints are
The recent change to reject __is_constructible for nested classes with DMI
is breaking some code loudly that was previously only silently broken.
Let's allow simple cases by immediately parsing DMI that do no name lookup;
then being in complete class scope makes no difference.
Tested
On 3/30/22 08:56, Patrick Palka wrote:
On Tue, 29 Mar 2022, Jason Merrill wrote:
On 3/29/22 15:22, Patrick Palka wrote:
Here we're crashing when diagnosing a failed __is_constructible constraint
because diagnose_atomic_constraint don't know how to diagnose a trait
that diagnose_trait_expr
On 3/29/22 02:02, Pokechu22 wrote:
On Thu, Mar 24, 2022 at 1:53 PM Jason Merrill wrote:
Thanks! For future reference, the patch doesn't apply easily because
gmail wrapped lines; for sending patches via gmail you'll need to use
attachments. Or you can use another MUA, or git send-email. This
On 3/29/22 16:59, Marek Polacek wrote:
On Tue, Mar 29, 2022 at 04:53:21PM -0400, Marek Polacek via Gcc-patches wrote:
This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension. We
could also use op0 instead of op1 in this
On 3/29/22 16:53, Marek Polacek wrote:
This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension. We
could also use op0 instead of op1 in this case, but it doesn't seem
to be necessary.
I wonder why we don't represent
On 3/25/22 18:16, Marek Polacek wrote:
The attached 93280 test no longer ICEs but looks like it was never added to the
testsuite. The 104583 test, modified so that it closely resembles 93280, still
ICEs.
The problem is that in 104583 we have a value-init from {} (the line A a{};),
so this code
On 3/27/22 08:37, Zhao Wei Liew wrote:
On Fri, 25 Mar 2022 at 05:58, Jason Merrill wrote:
+ if (current_function_decl
+ && (DECL_CONSTRUCTOR_P (current_function_decl)
+ || DECL_DESTRUCTOR_P (current_function_decl))
+ && TREE_CODE (expr) == NOP_EXPR
+
On 3/29/22 04:05, Jakub Jelinek wrote:
Hi!
The concepts support (in particular template introductions from concepts TS)
broke the following testcase, valid unnamed bitfields with dependent
types (or even just typedefs) were diagnosed as typos (: instead of correct
::) in template introduction
On 3/29/22 15:22, Patrick Palka wrote:
Here we're crashing when diagnosing a failed __is_constructible constraint
because diagnose_atomic_constraint don't know how to diagnose a trait
that diagnose_trait_expr doesn't specifically handle. This patch fixes
this by falling through to the default
On 3/29/22 08:43, Jonathan Wakely wrote:
Tested powerpc64le-linux, OK for trunk?
OK.
-- >8 --
This allows the gpp_std_list variable to be set in ~/.dejagnurc instead
of using the GXX_TESTSUITE_STDS environment variable. This is
consistent with how other defaults such as tool_timeout can be
On 3/28/22 09:28, Patrick Palka wrote:
We weren't rejecting a concept declared with multiple template
parameter lists.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
PR c++/105067
gcc/cp/ChangeLog:
* pt.cc (finish_concept_definition):
On 3/28/22 09:29, Patrick Palka wrote:
Here during declaration matching for the two constrained template
friends, we crash from maybe_substitute_reqs_for because the second
friend doesn't yet have DECL_TEMPLATE_INFO set (we're being called
indirectly from push_template_decl).
As far as I can
For PR104008 we thought it might be enough to keep strip_typedefs from
removing this alias template specialization, but this PR demonstrates that
other parts of the compiler also need to know to consider it dependent.
So, this patch changes complex_alias_template_p to no longer consider
template
This test ICEd after the constexpr new patch (r10-3661) because alloc_call
had a NOP_EXPR around it; fixed by moving the NOP_EXPR to alloc_expr. And
the PR pointed out that the size_t cookie might need more alignment, so I
fix that as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
When setting up the hidden namespace-scope decl for a local extern, we also
need to set its visibility.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/103291
gcc/cp/ChangeLog:
* name-lookup.cc (push_local_extern_decl_alias): Call
determine_visibility.
When building a deduction guide from the Test constructor, we need to
rewrite the use of _dummy into a dependent reference, i.e. Test::template
_dummy. We were using SCOPE_REF for both type and non-type templates; we
need to use UNBOUND_CLASS_TEMPLATE for type templates.
Tested
Here, we were wrongly thinking that (const Options&)Widget::c_options is
not value-dependent because neither the type nor the (value of) c_options
are dependent, but since we're binding it to a reference we also need to
consider that it has a value-dependent address.
Tested x86_64-pc-linux-gnu,
More quirks of rewriting member references to dependent references for
CTAD. A reference to a member of dependent scope is definitely dependent.
And since r11-7044, tsubst_baselink builds a SCOPE_REF, so
tsubst_qualified_id should just use it.
Tested x86_64-pc-linux-gnu, applying to trunk.
When make_base_init_ok changes a call to a complete constructor into a call
to a base constructor, we were never marking the base ctor as used, so it
didn't get emitted.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102045
gcc/cp/ChangeLog:
* call.cc
My implementation of union non-type template arguments in r11-2016 broke
braced casts of union type, because they are still in syntactic (undigested)
form.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104847
gcc/cp/ChangeLog:
* mangle.cc (write_expression): Don't write
This was breaking because when we stripped the 't' typedef in s...>
to be s, the TYPE_MAIN_VARIANT of "Args..." was still
"t...", because type pack expansions are treated as types. Fixed by
using the right function to copy a "type".
Tested x86_64-pc-linux-gnu, applying to trunk.
PR
On 3/17/22 07:37, Benno Evers via Gcc-patches wrote:
The coroutine transformation moves the original function body into a
newly created actor function, but the block of the
`current_binding_level` still points into the original function,
causing the block to be shared between the two functions
On 3/25/22 11:58, Jakub Jelinek wrote:
Hi!
Jonathan reported on IRC that we don't parse
__builtin_bit_cast (type, val).field
etc.
The problem is that for these 2 builtins we return from
cp_parser_postfix_expression instead of setting postfix_expression
to the cp_build_* value and falling
On 3/25/22 14:09, Patrick Palka wrote:
When constructing the builtin operator->* candidate set according to
the available conversion functions for each operand type, we end up
considering a candidate with C1=T (a TEMPLATE_TYPE_PARM) and C2=F,
during which we crash from lookup_base because
On 3/25/22 12:07, Patrick Palka wrote:
When an if-stmt is deemed non-constant because both of its branches are
non-constant, we issue a rather generic error which, given that it points
to the 'if' token, misleadingly suggests the condition is at fault:
constexpr-105050.C:8:3: error:
On 3/25/22 12:34, Jakub Jelinek wrote:
Hi!
cplus_decl_attributes can be called with attributes equal to
error_mark_node, there are some spots in the function that test
it or decl_attributes it calls starts with:
if (TREE_TYPE (*node) == error_mark_node || attributes == error_mark_node)
On 3/24/22 18:43, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 05:12:12PM -0400, Jason Merrill wrote:
On 3/24/22 15:56, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
On 3/24/22 11:49, Marek Polacek wrote:
I started looking into this PR because in GCC 4.9
On 3/17/22 06:35, Jonathan Wakely via Gcc-patches wrote:
On 15/03/22 14:36 -0600, Martin Sebor wrote:
On 3/15/22 10:40, Siddhesh Poyarekar wrote:
On 15/03/2022 21:09, Martin Sebor wrote:
The strncmp function takes arrays as arguments (not necessarily
strings).? The main purpose of the
On 3/24/22 17:53, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote:
On 3/18/22 17:55, Marek Polacek wrote:
On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
On 3/10/22 18:04, Marek Polacek wrote:
Since r9-6073 cxx_eval_store_expression
On 3/13/22 19:43, Zhao Wei Liew wrote:
On Sat, 12 Mar 2022 at 06:15, Jason Merrill wrote:
It looks good, but unfortunately regresses some other warning tests,
such as Wnonnull5.C. Please remember to run the regression tests before
sending a patch (https://gcc.gnu.org/contribute.html#testing).
On 3/17/22 01:51, Zhao Wei Liew wrote:
Thanks for the review. I've tested and uploaded a new patch v2 with
the requested changes.
On Thu, 17 Mar 2022 at 09:20, Jason Merrill wrote:
On 3/14/22 02:36, Zhao Wei Liew via Gcc-patches wrote:
This patch adds a warning when casting "this" to
On 3/24/22 15:56, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
On 3/24/22 11:49, Marek Polacek wrote:
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's
On 3/22/22 16:59, Marek Polacek via Gcc-patches wrote:
On Tue, Mar 22, 2022 at 08:39:21PM +, Ed Catmur wrote:
If two arrays do not have the exact same element type including qualification, this could
be e.g. f(int (&&)[]) vs. f(int const (&)[]), which can still be distinguished
by the
On 3/23/22 21:01, Pokechu22 via Gcc-patches wrote:
When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or
constexpr auto variable, the type might not be complete the first time
(this happened when auto deduces to an initializer_list).
cp_apply_type_quals_to_decl removes the
With the changes for PR81359 and PR88368 to make get_nsdmi errors be treated
as substitution failure, we have the problem that if we check
std::is_default_constructible for a complete class that still has unparsed
default member initializers, we get an answer (false) that will be wrong
once the
On 3/24/22 13:03, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 09:32:19AM -0400, Jason Merrill wrote:
On 3/23/22 19:26, Marek Polacek wrote:
On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
On 3/22/22 19:55, Marek Polacek wrote:
This is a crash where a FIX_TRUNC_EXPR gets into
On 3/24/22 11:49, Marek Polacek wrote:
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's ill-formed code in C++:
[dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has
the same
On 3/18/22 17:55, Marek Polacek wrote:
On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
On 3/10/22 18:04, Marek Polacek wrote:
Since r9-6073 cxx_eval_store_expression preevaluates the value to
be stored, and that revealed a crash where a template code (here,
On 3/24/22 10:32, Patrick Palka wrote:
Here we weren't respecting SFINAE when evaluating a substituted call to
a consteval function, which caused us to reject the new testcase below.
This patch fixes this by making build_over_call use the SFINAE-friendly
version of cxx_constant_value.
This
On 3/23/22 19:26, Marek Polacek wrote:
On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
On 3/22/22 19:55, Marek Polacek wrote:
This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().
The history of
On 3/22/22 03:35, Jakub Jelinek wrote:
Hi!
C++14 to C++20 apparently should allow extern thread_local declarations in
constexpr functions, however useless they are there (because accessing
such vars is not valid in a constant expression, perhaps sizeof/decltype).
P2242 changed that for C++23 to
On 3/22/22 19:55, Marek Polacek wrote:
This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().
The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it
was introduced in r181478, but it did the wrong thing, whereupon it
was turned into
On 3/22/22 14:31, Patrick Palka wrote:
On Tue, 22 Mar 2022, Patrick Palka wrote:
Here we're neglecting to clear cp_unevaluated_operand when substituting
into the arguments of the alias template-id skip<(T(), 0), T> with T=A,
which means cp_unevaluated_operand remains set during mark_used for
On 3/22/22 10:19, Patrick Palka wrote:
On Mon, 21 Mar 2022, Jason Merrill via Gcc-patches wrote:
Our C++20 designated initializer handling was broken with members of class
type; we would find the relevant member and then try to find a member of
the member with the same name. Or we would
On 3/23/22 10:29, Patrick Palka wrote:
I wonder if it'd be worthwhile to also test dependent_type_p (scope) here
here to avoid iterating over the lookup set when it can't possibly contain
a dependent using-decl.
Good thought:
From b1005f60c17d693e9fbc38a9481b3cd896d26785 Mon Sep 17 00:00:00
Here, DECL_DEPENDENT_P was false for the second using because Row is
"the current instantiation", so lookup succeeds. But since Row itself has a
dependent using-decl for operator(), the set of functions imported by the
second using is dependent, so we should set the flag.
Tested
We went into build_vec_init because we're dealing with a VLA, but then
build_vec_init thought it was safe to just build an INIT_EXPR because the
outer dimension is constant. Nope.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Check for vla
Our C++20 designated initializer handling was broken with members of class
type; we would find the relevant member and then try to find a member of
the member with the same name. Or we would sometimes ignore the designator
entirely. The former problem is fixed by the change to
We found .x in the anonymous struct, but then didn't find .y there; we
should decide that means we're done with the struct rather than that the
code is wrong.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101767
gcc/cp/ChangeLog:
* decl.cc (reshape_init_class): Back out
On 3/18/22 14:47, Jakub Jelinek wrote:
On Fri, Mar 18, 2022 at 02:27:30PM -0400, Jason Merrill wrote:
That is also correct C++ expression, but user probably has no idea what is
present at offset 32 into the variable.
Of course if there is a type match and not any kind of type punning,
it will
On 3/18/22 14:20, Jakub Jelinek wrote:
On Fri, Mar 18, 2022 at 01:35:53PM -0400, Jason Merrill wrote:
On 3/15/22 12:06, Jakub Jelinek wrote:
On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
The intent of r11-6729 is that it prints something that helps user to figure
out what
The problem in both PR92918 and PR104476 is overloading of base member
functions brought in by 'using' with direct member functions during parsing
of the class body. To this point they've had a troublesome coexistence
which was resolved by set_class_bindings when the class is complete, but we
On 3/15/22 12:06, Jakub Jelinek wrote:
On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
The intent of r11-6729 is that it prints something that helps user to figure
out what exactly is being accessed.
When we find a unique non-static data member that is being accessed, even
when
On 3/16/22 12:55, Jakub Jelinek wrote:
On Tue, Mar 15, 2022 at 04:19:05PM -0400, Jason Merrill wrote:
But if you strongly prefer it that way, I can do that.
Note, probably not 3 new args but 4, depends on whether we could turn
all those cases where the tree arg0 = CALL_EXPR_ARG (oldop, 0);
is
On 3/16/22 17:18, Marek Polacek wrote:
Zero-length pack expansions are treated as if no list were provided
at all, that is, with
template struct S { };
template
void g() {
S...>;
}
g will result in S<>. In the following test we have something
similar:
template
using
On 3/14/22 02:36, Zhao Wei Liew via Gcc-patches wrote:
This patch adds a warning when casting "this" to Derived* in the Base
class constructor and destructor. I've added the warning under the
-Wextra flag as I can't find a more appropriate flag for it.
It's generally best to add a new warning
On 3/15/22 13:18, Patrick Palka wrote:
As a followup to r12-7656-gffe9c0a0d3564a, this minor patch condenses
the handling of ambiguity and access w.r.t. the value of 'protect' so
that it more clearly matches the function comment.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
On 3/15/22 13:09, Patrick Palka wrote:
On Tue, 15 Mar 2022, Jason Merrill wrote:
On 3/15/22 10:03, Patrick Palka wrote:
On Mon, 14 Mar 2022, Jason Merrill wrote:
On 3/14/22 13:13, Patrick Palka wrote:
On Fri, 11 Mar 2022, Jason Merrill wrote:
On 3/10/22 11:27, Patrick Palka wrote:
On
On 3/15/22 07:44, Jakub Jelinek wrote:
On Fri, Mar 11, 2022 at 11:28:09PM -0500, Jason Merrill wrote:
@@ -7264,9 +7265,66 @@ cxx_eval_constant_expression (const cons
DECL_NAME (var)
= (DECL_NAME (var) == heap_uninit_identifier
? heap_identifier :
On 3/15/22 08:32, Jakub Jelinek wrote:
On Fri, Feb 11, 2022 at 12:27:49PM -0500, Jason Merrill wrote:
Yes, that's what the above code would correctly do if TYPE were the
pointer-to-method type. It's wrong for this case because TYPE is unrelated
to TREE_TYPE (field).
I think the problem is
On 3/15/22 10:03, Patrick Palka wrote:
On Mon, 14 Mar 2022, Jason Merrill wrote:
On 3/14/22 13:13, Patrick Palka wrote:
On Fri, 11 Mar 2022, Jason Merrill wrote:
On 3/10/22 11:27, Patrick Palka wrote:
On Wed, 9 Mar 2022, Jason Merrill wrote:
On 3/1/22 18:08, Patrick Palka wrote:
A
On 3/12/22 14:22, Jakub Jelinek wrote:
Hi!
We ICE on the following testcase, because we tentatively parse it multiple
times and the erroneous attribute syntax results in
cp_parser_skip_to_end_of_statement, which when seeing CPP_PRAGMA (can be
any deferred one, OpenMP/OpenACC/ivdep etc.) it
On 3/14/22 13:13, Patrick Palka wrote:
On Fri, 11 Mar 2022, Jason Merrill wrote:
On 3/10/22 11:27, Patrick Palka wrote:
On Wed, 9 Mar 2022, Jason Merrill wrote:
On 3/1/22 18:08, Patrick Palka wrote:
A well-formed call to std::move/forward is equivalent to a cast, but the
former being a
On 3/14/22 13:24, Patrick Palka wrote:
When a lookup is ambiguous, lookup_member still attempts to check
access of the first member found before diagnosing the ambiguity and
erroring out, which may cause us to issue an extraneous access error
in case of ambiguous lookup as in the testcase below
On 2/11/22 14:55, Jakub Jelinek wrote:
Hi!
As mentioned by Jason in the PR, non-trivially-copyable types (or non-POD
for purposes of layout?) types can be base classes of derived classes in
which the padding in those non-trivially-copyable types can be redused for
some real data members or even
On 2/21/22 04:25, Jakub Jelinek wrote:
Hi!
The new expression constant expression evaluation right now tries to
deduce how many elts the array it uses for the heap or heap [] vars
should have (or how many elts should its trailing array have if it has
cookie at the start). As new is lowered at
On 3/10/22 11:27, Patrick Palka wrote:
On Wed, 9 Mar 2022, Jason Merrill wrote:
On 3/1/22 18:08, Patrick Palka wrote:
A well-formed call to std::move/forward is equivalent to a cast, but the
former being a function call means it comes with bloated debug info, which
persists even after the
On 3/10/22 12:41, Patrick Palka wrote:
On Wed, 9 Mar 2022, Jason Merrill wrote:
On 3/9/22 10:39, Patrick Palka wrote:
On Tue, 8 Mar 2022, Jason Merrill wrote:
On 3/2/22 14:32, Patrick Palka wrote:
In order to be able to perform CTAD for a dependently-scoped template
such as A::B in the
On 3/10/22 18:04, Marek Polacek wrote:
Since r9-6073 cxx_eval_store_expression preevaluates the value to
be stored, and that revealed a crash where a template code (here,
code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*.
It happens because we're performing build_vec_init while processing
a
On 3/10/22 15:30, Patrick Palka wrote:
When shortcutting bad conversions during overload resolution, we assume
argument conversions get computed in sequential order and that therefore
we just need to inspect the last conversion in order to determine if _any_
conversion is missing. But this
On 3/10/22 16:57, Patrick Palka wrote:
On Thu, 10 Mar 2022, Jason Merrill wrote:
On 2/16/22 15:56, Patrick Palka wrote:
On Tue, 15 Feb 2022, Jason Merrill wrote:
On 2/14/22 11:32, Patrick Palka wrote:
Here the template context for the atomic constraint has two levels of
template
On 3/11/22 11:46, Patrick Palka wrote:
On Thu, 10 Mar 2022, Jason Merrill wrote:
On 3/1/22 00:10, Patrick Palka wrote:
On Tue, 19 Jan 2021, Jason Merrill wrote:
On 1/13/21 12:05 PM, Patrick Palka wrote:
In the below testcase, the expression of the atomic constraint after
substitution is
On 2/17/22 23:30, Zhao Wei Liew wrote:
On Fri, 18 Feb 2022 at 08:32, Zhao Wei Liew wrote:
+/* Test non-empty class */
+void f2(B b1, B b2)
+{
+ if (b1 = 0); /* { dg-warning "suggest parentheses" } */
+ if (b1 = 0.); /* { dg-warning "suggest parentheses" } */
+ if (b1 = b2); /* { dg-warning
On 3/1/22 00:10, Patrick Palka wrote:
On Tue, 19 Jan 2021, Jason Merrill wrote:
On 1/13/21 12:05 PM, Patrick Palka wrote:
In the below testcase, the expression of the atomic constraint after
substitution is (int *) NON_LVALUE_EXPR <1> != 0B which is not a C++
constant expression, but its
On 3/1/22 00:14, Patrick Palka wrote:
This improves diagnostic quality for unsatisfied atomic constraints
that consist of a fold expression, e.g. in concepts/diagnostics3.C:
.../diagnostic3.C:10:22: note: the expression ‘(foo && ...) [with Ts =
{int, char}]’ evaluated to ‘false’
10 |
On 2/16/22 15:56, Patrick Palka wrote:
On Tue, 15 Feb 2022, Jason Merrill wrote:
On 2/14/22 11:32, Patrick Palka wrote:
Here the template context for the atomic constraint has two levels of
template arguments, but since it depends only on the innermost argument
T we use a single-level
On 3/2/22 19:15, Martin Sebor wrote:
The -Wdangling-pointer code tests the EDGE_DFS_BACK but the pass never
calls the mark_dfs_back_edges() function that initializes the bit (I
didn't know about it). As a result the bit is not set when expected,
which can cause false positives under the right
On 3/10/22 04:34, Jakub Jelinek wrote:
Hi!
wg21.link/p2128 removed "with exactly one parameter" from over.sub
section. grok_op_properties has for that the last 2 lines in:
case OVL_OP_FLAG_BINARY:
if (arity != 2)
{
if (operator_code == ARRAY_REF && cxx_dialect
On 2/28/22 03:52, Roger Sayle wrote:
This patch resolves PR c++/84964 which is an ICE in the middle-end after
emitting a "sorry, unimplemented" message, and is a regression from
earlier releases of GCC. This issue is that after encountering a
function call requiring an unreasonable amount of
On 2/21/22 08:17, Roger Sayle wrote:
This patch resolves PR c++/95999 which is an ICE-after-error regression
in the g++ front-end. When parsing an enumerator list, the C++ parser
assumes that cp_parser_constant_expression always returns either an
INTEGER_CST or error_mark_node, but in testcase
On 2/22/22 08:02, Roger Sayle wrote:
This patch resolves PR c++/96442, another ICE-after-error regression.
In this case, invalid code attempts to use a non-integral type as the
underlying type for an enumeration (a record_type in the example given
in the bugzilla PR), for which the parser emits
On 2/26/22 19:55, Roger Sayle wrote:
This is a fix for PR c++/39751 which is an ICE-on-invalid regression in
the C++ parser after encountering the end of file. The one line change
is to check that the tokens cached in DECL_PENDING_INLINE_INFO haven't
been purged before processing them in
On 3/9/22 10:39, Patrick Palka wrote:
On Tue, 8 Mar 2022, Jason Merrill wrote:
On 3/2/22 14:32, Patrick Palka wrote:
In order to be able to perform CTAD for a dependently-scoped template
such as A::B in the testcase below, we need to permit a
typename-specifier to resolve to a template as per
On 3/9/22 11:22, Marek Polacek wrote:
On Tue, Mar 08, 2022 at 02:47:42PM -0500, Jason Merrill wrote:
On 3/2/22 14:31, Marek Polacek wrote:
104752 points out that
template
concept C = true;
auto y = C auto(1);
is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type
On 3/9/22 14:09, Marek Polacek wrote:
This is an ICE-on-invalid with "auto operator delete[] (void *)" whose
return type must be void. The return type is checked in coerce_delete_type
but we never got there in this test, because we took the wrong path in
grokdeclarator, set type to
On 3/9/22 14:35, Roger Sayle wrote:
Hi Jason,
Very many thanks for your reviews/approvals of these ICE-on-invalid-code fixes.
+ if (TREE_VALUE (new_parm) != error_mark_node)
+DECL_VIRTUAL_P (TREE_VALUE (new_parm)) = true;
Hmm, I wonder about returning early if there was an error, but
On 3/1/22 17:12, Marek Polacek wrote:
On Mon, Feb 28, 2022 at 12:31:37PM -0400, Jason Merrill wrote:
On 2/22/22 17:46, Marek Polacek wrote:
Here we have a forward declaration of Parameter for which we create
an implicit typedef, which is a TYPE_DECL. Then, when looking it up
at template
On 3/1/22 18:08, Patrick Palka wrote:
A well-formed call to std::move/forward is equivalent to a cast, but the
former being a function call means it comes with bloated debug info, which
persists even after the call has been inlined away, for an operation that
is never interesting to debug.
This
On 3/2/22 05:22, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, different standards have different definition
on what is an UB left shift. They all agree on out of bounds (including
negative) shift count.
The rules used by ubsan are:
C99-C2x ((unsigned) x >> (uprecm1 - y)) != 0 then UB
On 3/2/22 14:32, Patrick Palka wrote:
In order to be able to perform CTAD for a dependently-scoped template
such as A::B in the testcase below, we need to permit a
typename-specifier to resolve to a template as per [dcl.type.simple]/2,
at least when it appears in a CTAD-enabled context.
This
On 3/8/22 17:17, Patrick Palka wrote:
On Tue, 8 Mar 2022, Jason Merrill wrote:
On 3/8/22 14:38, Patrick Palka wrote:
On Tue, 8 Mar 2022, Jason Merrill wrote:
On 3/8/22 11:36, Patrick Palka wrote:
On Mon, 7 Mar 2022, Jason Merrill wrote:
On 3/7/22 10:47, Patrick Palka wrote:
On Fri, 4
On 3/8/22 17:14, Marek Polacek wrote:
In r10-6329 I tried to optimize the number of calls to v_d_e_p in
convert_nontype_argument by remembering whether the expression was
value-dependent in a bool flag. I did that wrongly assuming that its
value-dependence will not be changed by
1101 - 1200 of 2962 matches
Mail list logo
