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
also
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 exac
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 tr
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
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 reshape_init_class,
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
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 x86_64-pc-linux-g
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 20
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/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
A:
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 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/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 tsubst_copy_and_build/FIX_TRUNC_E
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 chang
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,
code=IMPLICIT_CONV_EXP
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 effe
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 t
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 DMI
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 cons
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 lval
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 ill-
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 Derive
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/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 preevaluat
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 -Wstring
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/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)
r
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: expressio
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 depende
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 through
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 if
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 c++/9
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
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 (make_base_init_ok):
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.
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, ap
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 x86_64-pc-linux-gn
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.
gcc/testsui
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.
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 p
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 tel
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): Re
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/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 ca
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 du
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/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/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 the
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 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/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 does
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 x86_64-pc-lin
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 satisf
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 nu
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 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 `current_functio
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
gcc/cp/Chan
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.
gcc/tes
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 us
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 x86_64-pc-linux-gn
This bug was an object/value confusion; we are interested in the size
of *b.ip, but instead the code was calculating the size of b.ip itself.
This seems to be because compute_objsize will compute the size of whatever
object it can find in the argument: if you pass it a VAR_DECL, it gives you
the s
The patch for PR92024 changed -Wshadow=compatible-local to warn if either
new or old decl was a type, but the rationale only talked about the case
where both are types. If only one is, they aren't compatible.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100608
gcc/cp/ChangeLog:
On 4/6/22 10:41, Jakub Jelinek wrote:
On Fri, Feb 11, 2022 at 07:55:50PM +0100, Jakub Jelinek via Gcc-patches wrote:
Something like the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c16
will still be needed with adjusted testcase from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c15
On 3/25/22 14:08, Jason Merrill wrote:
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
On 4/6/22 11:11, Patrick Palka wrote:
We were attempting to issue a -Wctad-maybe-unsupported warning even when
complain=tf_none, which led to a crash in the first testcase below and a
bogus error during SFINAE in the second testcase.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this l
Here, because of problems with the new warning-control code and expressions
that change location, the suppress_warning on the INDIRECT_REF didn't work.
Those problems still need to be worked out, but it's simple to avoid needing
to use suppress_warning in the first place by using a reference instea
On 4/6/22 11:26, Jakub Jelinek wrote:
On Wed, Apr 06, 2022 at 11:18:32AM -0400, Jason Merrill wrote:
Why not check at the beginning of the function?
You just pinged this patch, but I haven't seen a response to this question.
I thought the
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list. r63030 clarified that "Since non-static C++ methods have
an implicit this argument, the arguments of such
On 4/6/22 15:36, Alexandre Oliva wrote:
Please adjust your patch subject lines for the new guidelines adopted as
part of the git transition:
https://gcc.gnu.org/contribute.html#patches
e.g. [PATCH] c++: tolerate cdtors returning this in constexpr [PRn]
On targets that return this from c
On 4/6/22 15:37, Alexandre Oliva wrote:
Need to adjust this subject line, as well.
This patch fixes a divergence in line numbers in diagnostics and,
presumably, debug information, between targets whose cdtors return
this and those that don't.
The problem was visible in g++.dg/cpp2a/constexpr-d
On 4/6/22 15:45, Marek Polacek via Gcc-patches wrote:
On Wed, Apr 06, 2022 at 04:36:49PM -0300, Alexandre Oliva via Gcc-patches wrote:
On targets that return this from cdtors, cxx_eval_call_expression may
flag flowing off the end of a dtor. That's preempted for ctors, and
avoided entirely when
My cleanup in r12-296 cleared TREE_HAS_CONSTRUCTOR on digested class
initializers, but we leave it set for vectors, since we can't wrap them in
TARGET_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105187
gcc/cp/ChangeLog:
* typeck2.cc (store_init_value): Allow TREE
We were already checking COMPLETE_TYPE_P to recognize instantiation of a
generic lambda, but didn't consider that we might be nested in a non-generic
lambda.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101717
gcc/cp/ChangeLog:
* lambda.cc (lambda_expr_this_capture): Ch
We've had a diagnostic for this, but since r10-6571 added an assert to
splice_late_return_type, we need to diagnose before we call it.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101051
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Reject conversion with trailing retur
This rule that for a friend with a qualified name we try to find a
matching template was already in C++98, but it seems we never implemented
it, and nobody reported it until 2019.
This patch sets DECL_IMPLICIT_INSTANTIATION to signal to
check_explicit_specialization that we want to find a template
My patch for PR92385 made us use VEC_INIT_EXPR for aggregate initialization
of an array where some elements are not explicitly initialized. Constexpr
handling of that was treating initialization from {} as equivalent to
value-initialization, which is problematic for classes with default member
ini
On 4/7/22 18:48, Alexandre Oliva wrote:
On Apr 6, 2022, Jason Merrill wrote:
On 4/6/22 15:37, Alexandre Oliva wrote:
Need to adjust this subject line, as well.
*nod*, thanks
* tree.cc (protected_set_expr_location): Propagate locus to
call wrapped in cast-to-void.
I'm reluctant to put t
On 4/7/22 18:25, Alexandre Oliva wrote:
Hello, Jason,
On Apr 6, 2022, Jason Merrill wrote:
On 4/6/22 15:36, Alexandre Oliva wrote:
Please adjust your patch subject lines for the new guidelines adopted
as part of the git transition:
https://gcc.gnu.org/contribute.html#patches
Oh, wow, I
On 4/8/22 15:21, Marek Polacek wrote:
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote:
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list. r63
The standard says, as we quote in the comment just above, that if we don't
find operator new in the allocated type, it should be looked up in the
global scope. This is specifically ::, not just any namespace, and we
already give an error for an operator new declared in any other namespace.
Tested
In a template class A we normally add an implicit using A::operator= as a
placeholder for the implicitly declared operator whose signature we don't
know yet. In my patch for PR92918 I stopped doing that if the class has an
explicit operator=, but that was wrong; an operator= taking an unrelated
ty
Trivial initialization shouldn't bump a variable out of .rodata; if the
result of build_aggr_init is an empty STATEMENT_LIST, throw it away.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104142
gcc/cp/ChangeLog:
* decl.cc (check_initializer): Check TREE_SIDE_EFFECTS.
gc
On 3/24/22 17:06, Jason Merrill wrote:
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
On 4/12/22 12:17, Patrick Palka wrote:
Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an
ARGUMENT_PACK_SELECT (which just resolves to the parameter pac
On 4/12/22 14:38, Marek Polacek wrote:
On Mon, Apr 11, 2022 at 04:39:22PM -0400, Jason Merrill wrote:
On 4/8/22 15:21, Marek Polacek wrote:
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote:
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype, s
On 4/12/22 14:44, Patrick Palka wrote:
On Tue, Apr 12, 2022 at 12:33 PM Jason Merrill wrote:
On 4/12/22 12:17, Patrick Palka wrote:
Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose RE
On 4/12/22 15:48, Patrick Palka wrote:
On Wed, Feb 16, 2022 at 2:47 PM Patrick Palka wrote:
On Tue, 15 Feb 2022, Jason Merrill wrote:
On 2/15/22 17:00, Patrick Palka wrote:
On Tue, 15 Feb 2022, Jason Merrill wrote:
On 2/15/22 15:13, Patrick Palka wrote:
On Tue, 15 Feb 2022, Patrick Palka
While considering the PR102071 patch for backporting, I noticed that I was
considering the alignment of the array new cookie even when there isn't one
because we aren't allocating an array.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102071
gcc/cp/ChangeLog:
* init.cc
There were two problems with this testcase: we weren't copying the target
attribute from the second declaration to the global alias for the first
one (duplicate_decls hunk), and then we were treating the third one as
matching the earlier one even though both are versioned (decls_match hunk).
The la
On 4/12/22 18:50, Marek Polacek wrote:
DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence). That means that reference-related is
now more broad, which means that we will be b
On 4/13/22 04:11, Jakub Jelinek wrote:
Hi!
The following testcase fails, because we only constant evaluate the
alignas argument as non-manifestly constant-evaluated and as
__builtin_is_constant_evaluated appears, we make it non-constant
(the reason is that we often try to evaluate some expressio
The patch for 100111 extended our handling of empty base elision to the case
where the derived class has no other fields, but we still need to make sure
that there's some initializer for the derived object.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105245
PR c++/100111
This issue goes back to r83221, where the cleanup for extended ref temps
changed from being unconditional to being tied to the declaration they
formed part of the initializer for.
The named return value optimization changes the cleanup for the NRV variable
to only run on the EH path; we don't want
Asking for conversion to a dependent type also makes a BASELINK dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101698
gcc/cp/ChangeLog:
* pt.cc (tsubst_baselink): Also check dependent optype.
gcc/testsuite/ChangeLog:
* g++.dg/template/conv19.C: New te
When instantiating the op() for a generic lambda, we can no longer do name
lookup inside function scopes enclosing the lambda, so we need to remember
the lookup result from processing the definition of the lambda. So the code
in finish_call_expr to throw away the lookup result and instead look it
Because common_handle_aligned_attribute only applies the alignment to the
TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it
explicitly in tsubst.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/65211
gcc/cp/ChangeLog:
* pt.cc (tsubst_decl) [TYPE_DECL]:
When a captured variable is type-dependent, we've expressed the type of the
capture field and proxy with a decltype variant. But if the type is "the
current instantiation", we need to be able to see that so that we can do
lookup inside it just like we could with the captured variable itself.
I al
The constexpr constructor checking code got confused by the expansion of a
trivial copy constructor; we don't need to do that checking for defaulted
ctors, anyway.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104646
gcc/cp/ChangeLog:
* constexpr.cc (maybe_save_constexpr
The expression pretty-printing code crashed on a location wrapper with no
type, and didn't know what to do with a USING_DECL.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102987
gcc/cp/ChangeLog:
* error.cc (dump_expr): Handle USING_DECL.
[VIEW_CONVERT_EXPR]: Ju
There's been an extension for a long time to allow applying 'unsigned' to an
int typedef, but that was confusing the integer promotion code. Fixed by
forgetting about the typedef in that case.
I'm going to make this an unconditional pedwarn in stage 1.
Tested x86_64-pc-linux-gnu, applying to tru
701 - 800 of 2965 matches
Mail list logo
