On 2/9/23 10:22, Patrick Palka wrote:
On Thu, 9 Feb 2023, Patrick Palka wrote:
When substituting into sizeof(expr), tsubst_copy_and_build elides
substitution into the operand if args is NULL_TREE, and instead
considers the TREE_TYPE of the operand. But here the (templated)
operand is a TEMPLAT
On 2/15/23 05:37, Jonathan Wakely wrote:
OK for trunk?
OK.
-- >8 --
Users are confused about what this warning means, so add a suggested
solution to the documentation.
gcc/ChangeLog:
* doc/invoke.texi (C++ Dialect Options): Suggest adding a
using-declaration to unhide funct
On 9/26/22 15:27, Lewis Hyatt wrote:
On Wed, Jun 15, 2022 at 03:06:16PM -0400, Lewis Hyatt wrote:
On Tue, Jun 14, 2022 at 05:26:49PM -0400, Lewis Hyatt wrote:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
The attached patch resolves PR preprocessor/103902 as described in the patc
On 2/15/23 09:21, Patrick Palka wrote:
On Tue, 14 Feb 2023, Jason Merrill wrote:
On 2/13/23 09:23, Patrick Palka wrote:
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
This patch factors out the TYPENAME_TYPE case of tsubst into a sep
On 2/9/23 09:39, Marek Polacek wrote:
In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide
the Y::Y(const Y&) call used to initialize o.c. So store_init_value
-> cxx_constant_init must constexpr-evaluate the call to Y::Y(const Y&)
in cxx_eval_call_expression. It's a trivial funct
On 2/17/23 23:04, Alexandre Oliva wrote:
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t
And fixing that isn't an option? Do the integ
On 2/17/23 23:02, Alexandre Oliva wrote:
cp_build_binary_op, that issues -Waddress warnings, issues an extra
warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect
when comparing a pointer-to-member-function literal with null.
The reason for the extra warning is that, on arm targ
Tested x86_64-pc-linux-gnu. This isn't really a regression fix, but it's very
safe, and fixes a longstanding annoyance, so I'm leaning toward putting it into
GCC 13. Thoughts?
-- 8< --
For a long time, people have expected to be able to write
static_assert (false) in a template and only have it
The standard was unclear what happens with the transformation of a deduction
guide if the initial template argument deduction fails for a reason other
than not deducing all the arguments; my implementation assumed that the
right thing was to give up on the deduction guide. But in consideration of
Tested x86_64-pc-linux-gnu. Since this is fixing experimental (C++20)
functionality, I think it's reasonable to apply now; I'm interested in other
opinions, and thoughts about the user-facing functionality. I'm thinking to
make it internal-only for GCC 13 at least by adding a space in the name, b
In my initial implementation of alias CTAD, I described a couple of
differences from the specification that I thought would not have a practical
effect; this testcase demonstrates that I was wrong. One difference is
resolved by the CPTK_IS_DEDUCIBLE commit; the other (adding too many of the
alias
On 2/17/23 14:42, Marek Polacek wrote:
On Fri, Feb 17, 2023 at 04:32:50PM -0500, Patrick Palka wrote:
On Fri, 17 Feb 2023, Patrick Palka wrote:
On Fri, 17 Feb 2023, Marek Polacek wrote:
On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
On Fri, 17 Feb 2023, Marek Polacek via Gcc
On 2/15/23 13:37, Marek Polacek wrote:
On Wed, Feb 15, 2023 at 02:39:16PM -0500, Jason Merrill wrote:
On 2/9/23 09:39, Marek Polacek wrote:
In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide
the Y::Y(const Y&) call used to initialize o.c. So store_init_value
-> cxx_constant_in
On 2/15/23 12:11, Patrick Palka wrote:
On Wed, 15 Feb 2023, Jason Merrill wrote:
On 2/15/23 09:21, Patrick Palka wrote:
On Tue, 14 Feb 2023, Jason Merrill wrote:
On 2/13/23 09:23, Patrick Palka wrote:
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-Novemb
On 2/17/23 22:55, Alexandre Oliva wrote:
When a multi-source module is found to be unsupported, we fail
module_cmi_p and subsequent sources. Override proc unsupported to
mark the result in module_do, and test it to skip module_cmp_p and
subsequent related tests.
Hmm, I guess the problem that
On 2/23/23 18:51, Marek Polacek wrote:
Since r11-557, cp_finish_decl can call check_initializer even in
a template for a constexpr initializer. That ultimately leads to
convert_for_assignment and check_address_or_pointer_of_packed_member,
where we crash, because it doesn't expect that the CALL_E
On 2/23/23 16:52, Patrick Palka wrote:
Here we're incorrectly treating the non-dependent variable template-id
tag as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR
an empty type which causes the call to finish_template_variable from
finish_id_expression_1 to be dead code at template
On 2/23/23 10:54, Marek Polacek wrote:
On Thu, Feb 23, 2023 at 10:17:22AM -0500, Patrick Palka wrote:
On Wed, 22 Feb 2023, Marek Polacek wrote:
In this test, we get a bogus error because we failed to deduce the auto in
constexpr auto is_pointer_v = is_pointer::value;
to bool. Then ensure_lite
On 2/23/23 05:26, Jakub Jelinek wrote:
Hi!
This translation PR mentioned the description is a little bit weird.
Ok for trunk?
OK.
2023-02-23 Jakub Jelinek
PR translation/108890
* c.opt (fcontracts): Fix description.
--- gcc/c-family/c.opt.jj 2023-02-01 10:19:42.63
On 2/23/23 05:23, Jakub Jelinek wrote:
Hi!
_Float16 and decltype(0.0bf16) types are on x86 supported only with
-msse2. On x86_64 that is the default, but on ia32 it is not.
We should still emit fundamental type tinfo for those types in
libsupc++.a/libstdc++.*, regardless of whether libsupc++/li
On 2/22/23 14:45, Patrick Palka wrote:
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts. T
On 2/22/23 11:03, Alexandre Oliva wrote:
On Feb 17, 2023, Jason Merrill wrote:
On 2/17/23 23:02, Alexandre Oliva wrote:
cp_build_binary_op, that issues -Waddress warnings, issues an extra
warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect
when comparing a pointer-to-member
On 2/22/23 10:23, Alexandre Oliva wrote:
Hello, Jason,
On Feb 17, 2023, Jason Merrill wrote:
On 2/17/23 23:04, Alexandre Oliva wrote:
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow
On 2/22/23 04:06, Jakub Jelinek wrote:
Hi!
The r13-2965-g73d9b0e5947e16 change changed the line touched in this patch
from
return RECUR (tmp, want_rval);
to
return RECUR (DECL_INITIAL (tmp), want_rval);
This is on DECL_EXPR handling code, where tmp can be lots of different
trees an
On 3/1/23 10:32, Patrick Palka wrote:
On Mon, 27 Feb 2023, Jason Merrill wrote:
On 2/22/23 14:45, Patrick Palka wrote:
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constan
On 3/1/23 12:20, Patrick Palka wrote:
On Wed, 1 Mar 2023, Jason Merrill wrote:
On 3/1/23 10:32, Patrick Palka wrote:
On Mon, 27 Feb 2023, Jason Merrill wrote:
On 2/22/23 14:45, Patrick Palka wrote:
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant a
On 3/1/23 08:09, Jakub Jelinek wrote:
On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics.
On 2/2/23 19:28, Marek Polacek wrote:
Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
been completed yet, but that doesn't work:
/* We can't lower this until the class is complete. */
if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
return cst;
a
On 3/1/23 15:33, Marek Polacek wrote:
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add
On 2/21/23 19:05, Patrick Palka wrote:
On Sun, 19 Feb 2023, Jason Merrill wrote:
On 2/15/23 12:11, Patrick Palka wrote:
On Wed, 15 Feb 2023, Jason Merrill wrote:
On 2/15/23 09:21, Patrick Palka wrote:
On Tue, 14 Feb 2023, Jason Merrill wrote:
On 2/13/23 09:23, Patrick Palka wrote:
[N.B.
On 3/1/23 16:40, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
On 3/1/23 15:33, Marek Polacek wrote:
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the class
On 2/7/23 11:46, Marek Polacek wrote:
On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote:
On 1/24/23 17:49, Marek Polacek wrote:
On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
On 1/19/23 21:03, Marek Polacek wrote:
On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Mer
On 2/27/23 18:51, Jakub Jelinek wrote:
On Mon, Feb 27, 2023 at 06:26:04PM -0500, Jason Merrill wrote:
The following patch instead adds a target hook which allows the backend
to temporarily tweak registered types such that emit_support_tinfos
emits whatever is needed.
Why handle these types dif
On 3/2/23 02:43, Richard Biener wrote:
On Wed, 1 Mar 2023, Jason Merrill wrote:
On 3/1/23 08:09, Jakub Jelinek wrote:
On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_l
On 3/1/23 17:33, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:44:12PM -0500, Jason Merrill wrote:
On 3/1/23 16:40, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
On 3/1/23 15:33, Marek Polacek wrote:
-Wmismatched-tags warns about the (harmless) struct/c
On 3/2/23 06:20, Jakub Jelinek wrote:
Hi!
On Wed, Mar 01, 2023 at 05:50:47PM -0500, Jason Merrill wrote:
And then there is a question whether we want to emit rtti for
_Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless
of whether the target supports them at all or not.
Emi
On 2/21/23 15:18, Patrick Palka wrote:
On Mon, 20 Feb 2023, Patrick Palka wrote:
According to [basic.start.static]/2 and [expr.const]/2, a variable
with static storage duration initialized with a constant initializer
has constant initialization, and such an initializer is manifestly
constant-ev
On 2/21/23 14:10, Patrick Palka wrote:
We should also fold the overall initializer passed to cp_fully_fold_init
with mce_false, which enables folding of the copy-initialization of
'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR).
Unfortunately this doesn't help with direct-
On 2/9/23 11:14, Jakub Jelinek wrote:
Hi!
The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P2647R1
was implemented we agreed to make it valid.
Now, as r
On 2/9/23 03:41, Jakub Jelinek wrote:
Hi!
Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct
DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that
change we haven't emitted it at all for a while and after some time
started emitting incorrect locus,
On 3/3/23 10:18, Jakub Jelinek wrote:
On Thu, Mar 02, 2023 at 11:48:04AM -0500, Jason Merrill wrote:
The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P26
On 3/3/23 09:58, Patrick Palka wrote:
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appear
On 3/2/23 16:24, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:
@@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
const int& y = (f(1), 42); // NULL_TREE
const int& z = f(f(1)); // f(f(1))
- EXPR is the initializer. */
+ EXPR is the i
On 3/3/23 12:50, Marek Polacek wrote:
On Fri, Mar 03, 2023 at 11:25:06AM -0500, Jason Merrill wrote:
On 3/2/23 16:24, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:
@@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
const int& y = (f(1), 42); //
On 3/3/23 12:51, Marek Polacek wrote:
Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.
Here we are rejecting
extern const Q q;
template
constexpr auto p = q(0);
even though q has a
On 3/6/23 16:54, Marek Polacek wrote:
On Fri, Mar 03, 2023 at 09:30:38PM -0500, Jason Merrill wrote:
On 3/3/23 12:50, Marek Polacek wrote:
switch (TREE_CODE (expr))
{
case CALL_EXPR:
@@ -13831,7 +13895,8 @@ do_warn_dangling_reference (tree expr)
std::pair v = std
On 3/6/23 17:01, Marek Polacek wrote:
On Mon, Mar 06, 2023 at 11:12:56AM -0500, Jason Merrill wrote:
On 3/3/23 12:51, Marek Polacek wrote:
Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.
He
On 3/6/23 18:59, Marek Polacek wrote:
When processing a noexcept, constructors aren't elided: build_over_call
has
/* It's unsafe to elide the constructor when handling
a noexcept-expression, it may evaluate to the wrong
value (c++/53025). */
&& (force_el
On 3/7/23 04:07, Jakub Jelinek wrote:
Hi!
In my recent rtti.cc change I assumed when emitting the support tinfos
that the tinfos for the fundamental types haven't been created yet.
Normally (in libsupc++.a (fundamental_type_info.o)) that is the case,
but as can be seen on the testcase, one can v
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A missed piece of the patch for static operator(): in tsubst_function_decl,
we don't want to replace the first parameter with a new closure pointer if
operator() is static.
PR c++/108526
PR c++/106651
gcc/cp/ChangeLog:
Tested x86_64-pc-linux-gnu. Does this look good, or do we want to factor the
flag clearing into a symtab_node counterpart to cgraph_node::reset?
-- 8< --
In 107897, by the time we are looking at the mangling clash, the
alias has already been removed from the symbol table by analyze_functions,
so
On 3/8/23 10:53, Jan Hubicka wrote:
Tested x86_64-pc-linux-gnu. Does this look good, or do we want to factor the
flag clearing into a symtab_node counterpart to cgraph_node::reset?
-- 8< --
In 107897, by the time we are looking at the mangling clash, the
alias has already been removed from the
On 3/8/23 11:15, Jason Merrill wrote:
On 3/8/23 10:53, Jan Hubicka wrote:
Tested x86_64-pc-linux-gnu. Does this look good, or do we want to
factor the
flag clearing into a symtab_node counterpart to cgraph_node::reset?
-- 8< --
In 107897, by the time we are looking at the mangling clash, the
On 2/20/23 11:58, Patrick Palka wrote:
On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote:
Tested x86_64-pc-linux-gnu. Since this is fixing experimental (C++20)
functionality, I think it's reasonable to apply now; I'm interested in other
opinions, and thoughts about the u
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The optimization to reuse the same allocator temporary for all string
constructor calls was breaking on this testcase, because the temps were
already in the argument to build_vec_init, and replacing them with
references to one slot got confu
On 3/9/23 14:32, Patrick Palka wrote:
On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote:
When processing a noexcept, constructors aren't elided: build_over_call
has
/* It's unsafe to elide the constructor when handling
a noexcept-expression, it may evaluate to the wro
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
PR c++/108542
gcc/cp/ChangeLog:
* class.cc (instantiate_type): Strip location wrapper.
gcc/testsuite/ChangeLog:
* g++.dg/contracts/contracts-err1.C: New test.
---
gcc/cp/class.cc |
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The code for handling signed + typedef was breaking on __int128_t, because
it isn't a proper typedef: it doesn't have DECL_ORIGINAL_TYPE.
PR c++/108099
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Handle non-typedef typed
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We were failing to come up with the name for the anonymous union. It seems
like unfortunate redundancy, but the ABI does say that the name of an
anonymous union is its first named member.
PR c++/108566
gcc/cp/ChangeLog:
*
On 3/9/23 14:40, Jakub Jelinek wrote:
Hi!
The following testcase FAILs, because starting with r12-6028
the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit
bitfield and one 8-bit char field.
The reason is that when end_of_class attempts to compute dsize, it simply
adds
On 11/24/22 04:13, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because OpenMP lowering for shared clause
on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE.
The reason is that the automatic variable has non-trivial construction
(reference to a lambda) and -fmerge-
On 3/10/23 10:43, Jakub Jelinek wrote:
Hi!
This is on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html
patches (to be precise, the latter isn't essential for it), I've
realized that for the PR10770
On 3/10/23 11:17, Marek Polacek wrote:
We crash here since r10-3661, the store_init_value hunk in particular.
Before, we called cp_fully_fold_init, so e.g.
{.str=VIEW_CONVERT_EXPR("")}
was folded into
{.str=""}
but now we don't fold and keep the VCE around, and it causes trouble in
cxx_
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Better not to ICE after various valid errors.
PR c++/108972
gcc/cp/ChangeLog:
* lambda.cc (compare_lambda_template_head): Check more
for error_mark_node.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-l
On 3/13/23 02:57, Arsen Arsenović wrote:
In the edge case of a coroutine not containing any locals, the ifcd/switch
temporaries would get added to the coroutine frame, corrupting its
layout. To prevent this, we can make sure there is always a BIND_EXPR at
the top of the function body, and thus, a
On 3/10/23 14:07, Marek Polacek wrote:
std::span is a view and therefore should be treated as a reference
wrapper class for the purposes of -Wdangling-reference. I'm not sure
there's a pattern that we could check for.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
gdbhooks, which expects tree_code_type to always be available. I considered
trying to make gdbhooks more robust, but it seemed simpler to define
tree_code_type as a ref
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
It's been inconvenient to compile testcases preprocessed with GCC 12 or
earlier because they break on
typedef __float128 _Float128;
We already had code for handling this with bool and wchar_t, it just needs
to be extended to _FloatNN as
On 3/13/23 16:15, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
gdbhooks, which expects tree_code_type to always be available. I considered
trying to make gdbhooks more robust, but it seemed
On 3/14/23 03:54, Jakub Jelinek wrote:
Hi!
On Fri, Mar 10, 2023 at 01:49:38PM -0500, Jason Merrill via Gcc-patches wrote:
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-lambda3.C: Run at lower std levels,
but expect errors.
I'm seeing
+UNRESOLVED: g++.dg/cpp2a/con
On 3/14/23 03:58, Jakub Jelinek wrote:
Hi!
As reported in the PR, for __has_unique_object_representations we
were treating unnamed bitfields as named ones, which is wrong, they
are actually padding.
THe following patch fixes that. Ok for trunk (and what about release
branches later?)?
OK.
On 3/8/23 11:54, Jason Merrill wrote:
On 3/8/23 11:15, Jason Merrill wrote:
On 3/8/23 10:53, Jan Hubicka wrote:
Tested x86_64-pc-linux-gnu. Does this look good, or do we want to
factor the
flag clearing into a symtab_node counterpart to cgraph_node::reset?
-- 8< --
In 107897, by the time we
On 3/14/23 11:42, Jakub Jelinek wrote:
Hi!
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
gdbhooks, which expects tree_code_type to always be available. I considered
trying to make gdbhooks more robust
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I removed this folding in GCC 12 because it was interfering with an
experiment of richi's, but that never went in and the change causes
regressions, so let's put it back.
This reverts commit r12-5638-ga3e75c1491cd2d.
PR c++/107310
On 3/14/23 12:41, Patrick Palka wrote:
When redeclaring a member of a constrained class template, we need to
repeat the class's constraints, but it turns out we don't verify
anywhere that the repeated constraints match the class's constraints.
A safe place to do so seems to be in push_template_de
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Generally we expect TPARMS_PRIMARY_TEMPLATE to be set, but sometimes it
isn't for partial instantiations. This ought to be improved, but it's
trivial to work around it in this case.
PR c++/108468
gcc/cp/ChangeLog:
* pt.cc
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This function needs to handle this case like convert_template_argument.
PR c++/58538
gcc/cp/ChangeLog:
* semantics.cc (check_template_template_default_arg): Check
maybe_get_template_decl_from_type_decl.
gcc/testsu
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This should have no semantic effect, but is a prerequisite for the PR108179
fix to follow.
PR c++/108179
gcc/cp/ChangeLog:
* pt.cc (coerce_template_template_parms): Take the arg and parm
templates directly.
I kept trying to improve our choice of how many levels of outer_args to add,
when really the problem was that outer_args are for PARM and for this
reverse deduction we should be adding the outer arguments for ARG.
I spent quite a while trying to get DECL_CONTEXT set consistently on
template templa
On 3/15/23 10:37, Marek Polacek wrote:
On Fri, Mar 10, 2023 at 01:47:46PM -0500, Jason Merrill wrote:
On 3/10/23 11:17, Marek Polacek wrote:
We crash here since r10-3661, the store_init_value hunk in particular.
Before, we called cp_fully_fold_init, so e.g.
{.str=VIEW_CONVERT_EXPR("")}
wa
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When flatten_await_stmt processes the backing array for an initializer_list,
we call cp_build_modify_expr to initialize the promoted variable from the
TARGET_EXPR; that needs to be accepted.
PR c++/103871
PR c++/98056
gcc/c
Tested x86_64-pc-linux-gnu. As with the array issue, I know you have WIP to
deal with larger issues, but this seems like a reasonable local fix. Does it
make sense to you?
-- 8< --
Here we were building a temporary MoveOnlyAwaitable to hold the result of
evaluating 'o', but since 'o' is an lval
On 5/9/23 15:23, Jakub Jelinek wrote:
On Tue, May 09, 2023 at 01:17:09PM -0400, Jason Merrill wrote:
How about changing cp_parser_std_attribute to set TREE_VALUE to
error_mark_node if it skips arguments?
In limited testing that seems to work (tried
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make -j3
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The restriction on the "permitted result of a constant expression" to not
refer to an immediate function applies regardless of context. The previous
code tried to only check in cases where we wouldn't get the check in
cp_fold_r, but with th
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
DR 2543 clarifies that constinit variables should follow the language, and
diagnose non-constant initializers (according to [expr.const]) even if they
can actually initialize the variables statically.
DR 2543
gcc/cp/ChangeLog:
On 5/10/23 11:36, Patrick Palka wrote:
r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17, but we need to also remove the one
in convert_nontype_argument_function for sake of the first and third test
case which we incorrectly reject (in
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
While looking at PR109247 I made this change to improve diagnostics. I
don't think I'm going ahead with that patch, but this still seems like a
worthy cleanup.
gcc/cp/ChangeLog:
* call.cc (convert_like_internal): Share ck_ref_bind
On 5/10/23 14:11, Patrick Palka wrote:
On Wed, 10 May 2023, Jason Merrill wrote:
On 5/10/23 11:36, Patrick Palka wrote:
r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17, but we need to also remove the one
in convert_nontype_argumen
On 5/10/23 17:28, Marek Polacek wrote:
On Wed, May 03, 2023 at 03:37:03PM -0400, Jason Merrill wrote:
On 5/2/23 19:10, Marek Polacek wrote:
This PR points out that std::is_convertible has given the wrong answer
in
static_assert (!std::is_convertible_v , "");
since r13-2822 implemented __i
On 5/11/23 14:30, Patrick Palka wrote:
r13-2701-g7107ea6fb933f1 made us correctly accept 'mutable' member
accesses during constexpr evaluation of objects constructed during that
evaluation, while continuing to reject such accesses for constexpr
objects constructed outside of that evaluation, by c
On 5/9/23 08:07, Alex Coplan wrote:
This patch implements clang's __has_feature and __has_extension in GCC.
Thanks!
Currently the patch aims to implement all documented features (and some
undocumented ones) following the documentation at
https://clang.llvm.org/docs/LanguageExtensions.html wit
On 5/12/23 13:02, Patrick Palka wrote:
Hi Martin,
On Fri, May 12, 2023 at 12:13 PM Martin Jambor wrote:
Hello Patrick,
On Wed, May 03 2023, Patrick Palka via Gcc-patches wrote:
[...]
Subject: [PATCH] c++: potentiality of templated memfn call [PR109480]
Here we're incorrectly deeming th
In the context of the recent discussion, it occurred to me that this semantic
would be useful, but currently there is no easy way to access it. Bikeshedding
welcome; the use of this flag is a bit odd, but it has the advantage of being
accepted without error going back at least to 4.3.
-- 8< --
C
On 5/15/23 03:32, Richard Biener wrote:
On Fri, May 12, 2023 at 10:54 PM Jason Merrill via Gcc-patches
wrote:
In the context of the recent discussion, it occurred to me that this semantic
would be useful, but currently there is no easy way to access it. Bikeshedding
welcome; the use of this
On 5/15/23 11:24, Patrick Palka wrote:
This adds the feature-test macro for PR0849R8, as per
https://github.com/cplusplus/CWG/issues/281.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
OK.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_au
On 5/16/23 11:38, Patrick Palka wrote:
add_list_candidates has logic to reject designated initialization of a
non-aggregate type, but this is inadvertendly being suppressed if the type
has a list constructor due to the order of case analysis, which in the
below testcase leads to us incorrectly tr
On 5/16/23 15:13, Marek Polacek wrote:
In check_return_expr, we suppress the -Wdangling-reference warning when
we're sure it would be a false positive. It wasn't working in a
template, though, because the suppress_warning call was never reached.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok
On 5/16/23 15:34, Jakub Jelinek wrote:
Hi!
My GCC 12 change to avoid removing zero-sized bitfields as they are
important for ABI and are needed for layout compatibility traits
apparently causes zero sized bitfields to be initialized in the IL,
which at least in 13+ results in ICEs in the ranger
On 5/18/23 14:01, Patrick Palka wrote:
Avoid performing two norm_cache lookups during normalization of a
concept-id by allocating inserting a norm_entry* before rather than
after the fact, which is simpler and faster.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk
On 5/18/23 13:59, Patrick Palka wrote:
lookup_and_finish_template_variable calls convert_from_reference, which
means for a variable template-id of reference type the function returns
an INDIRECT_REF instead of the bare VAR_DECL. But the downstream logic
of two callers, tsubst_qualified_id and fi
201 - 300 of 2965 matches
Mail list logo