On 1/31/24 03:51, Richard Biener wrote:
On Wed, Jan 31, 2024 at 4:38 AM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
It's a quite "late" fixup, I suppose you have tried to avoid marking it
during gimplification? I see we do parts of this during BIND_EXPR
p
On 1/31/24 03:40, Richard Biener wrote:
On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We plan to deprecate -fconcepts-ts in GCC 15 and remove the flag_concepts_ts
code. This note is an admonishing reminder to conve
On 1/31/24 08:55, Richard Biener wrote:
On Wed, Jan 31, 2024 at 2:53 PM Jason Merrill wrote:
On 1/31/24 03:40, Richard Biener wrote:
On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We plan to deprecate -fconce
On 1/31/24 10:55, Marek Polacek wrote:
On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote:
On 1/31/24 03:40, Richard Biener wrote:
On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We plan to deprec
On 1/31/24 12:12, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here during declaration matching we undesirably consider the two TT{42}
CTAD expressions to be non-equivalent ultimately because for CTAD
placeholder equivalence we co
On 1/31/24 14:07, Marek Polacek wrote:
On Wed, Jan 31, 2024 at 02:00:18PM -0500, Jason Merrill wrote:
On 1/31/24 10:55, Marek Polacek wrote:
On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote:
On 1/31/24 03:40, Richard Biener wrote:
On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek
On 12/12/23 21:36, Jason Merrill wrote:
On 12/12/23 17:50, Peter Bergner wrote:
On 12/12/23 1:26 PM, Richard Biener wrote:
Am 12.12.2023 um 19:51 schrieb Peter Bergner :
On 12/12/23 12:45 PM, Peter Bergner wrote:
+/* PR target/112822 */
Oops, this should be:
/* PR tree-optimization
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When building an AGGR_INIT_EXPR from a CALL_EXPR, we shouldn't lose location
information.
gcc/cp/ChangeLog:
* tree.cc (build_aggr_init_expr): Copy EXPR_LOCATION.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-nsdmi7b.C
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I was puzzled by the proposed patch for PR71093 specifically ignoring the
in-charge parameter; the problem turned out to be that when
cxx_eval_call_expression jumps from the clone to the cloned function, it
assumes that the latter has the sa
Tested x86_64-pc-linux-gnu, applying to trunk.
This is modified from Nathaniel's last version by adjusting for my recent
CLOBBER changes and removing the special handling of __in_chrg which is no
longer needed since my previous commit.
-- 8< --
This patch adds checks for using objects after they
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When testing the proposed patch for PR71093 I noticed that it changed the
diagnostic for consteval-prop6.C. I then noticed that the diagnostic wasn't
very helpful either way; it was complaining about modification of the 'x'
variable, but it
On 12/13/23 04:49, Jakub Jelinek wrote:
Hi!
With valgrind checking, there are various errors reported on some C++26
libstdc++ tests, like:
==2009913== Conditional jump or move depends on uninitialised value(s)
==2009913==at 0x914C59: gt_ggc_mx_lang_tree_node(void*) (gt-cp-tree.h:107)
==20099
On 12/13/23 11:26, Jakub Jelinek wrote:
On Wed, Dec 13, 2023 at 11:24:42AM -0500, Jason Merrill wrote:
gcc/testsuite/ChangeLog:
* g++.dg/pr112822.C: Require C++17.
---
gcc/testsuite/g++.dg/pr112822.C | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/g++.dg/pr112822.C
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
My r14-6505-g52b4b7d7f5c7c0 change to copy the location in
build_aggr_init_expr reopened PR96997; let's fix it properly this time, by
clearing the location like we do for other trees.
PR c++/96997
gcc/cp/ChangeLog:
* tree.
On 12/13/23 03:39, Jakub Jelinek wrote:
Hi!
On the c-c++-common/cpp/pr88974.c testcase I'm seeing
==600549== Conditional jump or move depends on uninitialised value(s)
==600549==at 0x1DD3A05: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.cc:3050)
==600549==by 0x1DBFC7F: _cpp_parse_
On 12/12/23 16:21, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
OK.
-- >8 --
When unifying constants we need to generally treat constants of
different types but same value as different, in light of auto template
parameters. This patch
On 12/12/23 17:48, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote:
On 12/8/23 16:15, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote:
On 12/5/23 15:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu
On 12/13/23 19:00, Marek Polacek wrote:
On Wed, Dec 13, 2023 at 11:47:37AM -0500, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When building an AGGR_INIT_EXPR from a CALL_EXPR, we shouldn't lose location
information.
I think the following should be an
On 11/27/23 10:58, Patrick Palka wrote:
gcc/cp/ChangeLog:
* cp-tree.h (type_targs_deducible_from): Adjust return type.
* pt.cc (alias_ctad_tweaks): Handle C++23 inherited CTAD.
(inherited_ctad_tweaks): Define.
(type_targs_deducible_from): Return the deduced argume
On 12/14/23 14:17, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Do we want to condition this on abi_check (19)?
I think we do, sadly.
-- >8 --
As with other declaration attributes, we need to look through
TEMPLATE_DECL when looking up
On 12/14/23 14:17, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
The section attribute currently has no effect on templates because the
call to set_decl_section_name only happens at parse time and not also at
instantiation t
On 12/14/23 16:01, Marek Polacek wrote:
On Wed, Dec 13, 2023 at 03:28:38PM -0500, Jason Merrill wrote:
On 12/12/23 17:48, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote:
On 12/8/23 16:15, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason
On 12/14/23 16:02, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
This is sort of like r14-5514, but at block scope. Consider
struct A { A(int, int); };
void
g (int a)
{
A bar(auto(a), 42); // not a fn decl
}
where we emit
On 12/14/23 16:08, Patrick Palka wrote:
On Thu, 14 Dec 2023, Jason Merrill wrote:
On 12/14/23 14:17, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Do we want to condition this on abi_check (19)?
I think we do, sadly.
Sounds good
On 12/14/23 19:59, Patrick Palka wrote:
On Thu, 14 Dec 2023, Jason Merrill wrote:
On 12/14/23 16:08, Patrick Palka wrote:
On Thu, 14 Dec 2023, Jason Merrill wrote:
On 12/14/23 14:17, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Do we
On 12/15/23 19:20, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu with GLIBCXX_TESTSUITE_STDS=20
and RUNTESTFLAGS="--target_board=unix/-D_GLIBCXX_USE_CXX11_ABI=0".
OK, thanks.
-- >8 --
My previous patch (naively) assumed that a TREE_CODE of RECORD_TYPE or
UNION_TYPE
On 12/17/23 16:51, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
An alternative approach for the lambda issue would be to modify
'maybe_add_lambda_conv_op' to not pass a null pointer, but I wasn't sure
what the best approach for that would be.
I don't
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have another theory
about how to merge these?
-- 8< --
Doing a dynamic_cast in both TUs broke because we were declaring a new
__class_type_info in _b that conflicted with the one imported in the global
module from _a. lookup_elaborated_
On 12/18/23 14:56, Marek Polacek wrote:
On Mon, Dec 18, 2023 at 02:50:04PM -0500, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
LGTM but...
-- >8 --
The deprecated and unavailable attributes weren't working when used on
a template red
On 12/18/23 14:50, Patrick Palka wrote:
Bootstrappde and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
When computing a direct conversion to reference type fails and yields a
bad conversion, reference_binding incorrectly commits to that conversion
rather than at
On 12/18/23 14:50, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Here we first use and therefore synthesize the local class operator<=>
from an unevaluated context, which inadvertently affects synthesization
by causing funct
On 12/15/23 14:06, Patrick Palka wrote:
On Mon, 11 Sep 2023, Patrick Palka wrote:
On Thu, 1 Jun 2023, Patrick Palka wrote:
For a complex alias template-id, dependent_alias_template_spec_p returns
true if any template argument of the template-id is dependent. This
predicate indicates that sub
On 12/15/23 14:07, Patrick Palka wrote:
On Thu, 1 Jun 2023, Patrick Palka wrote:
During partial ordering, we want to look through dependent alias
template specializations within template arguments and otherwise
treat them as opaque in other contexts (see e.g. r7-7116-g0c942f3edab108
and r11-701
On 12/18/23 16:57, Nathan Sidwell wrote:
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have
another theory
about how to merge these?
Why isn't push_abi_namespace doing the right setup here? (and I think
get_global_binding mig
On 12/19/23 03:47, Jakub Jelinek wrote:
On Tue, Dec 19, 2023 at 08:11:11AM +0100, Martin Uecker wrote:
Am Montag, dem 18.12.2023 um 20:14 +0100 schrieb Jakub Jelinek:
Hi!
The following patch changes -Walloc-size warning to no longer warn
about int *p = calloc (1, sizeof (int));, because as dis
On 12/11/23 22:00, Jason Merrill wrote:
OK for trunk?
Ping. CCing Alex because this could plausibly be considered build
machinery, and he's had useful feedback on my sh code before.
-- 8< --
I thought it could be easier to use check_GNU_style.py. With this alias,
'git gc
On 12/19/23 14:08, Patrick Palka wrote:
On Mon, 1 May 2023, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
Patrick, can you verify that this resolves 109506 and add whatever testcase(s)
seem appropriate from that PR?
-- 8< --
Here it turns out I also needed to adj
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
-Werror=foo implying -Wfoo wasn't working for -Wdeprecated-copy-dtor,
because it is specified as the value 2 of warn_deprecated_copy, which shows
up as CLVC_EQUAL, which is not one of the three var_types handled by
control_warning_option. It see
On 12/20/23 12:00, Patrick Palka wrote:
On Fri, 1 Apr 2022, Jason Merrill wrote:
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
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Normally we handle xvalue array subscripting with ARRAY_REF, but in this
case we weren't doing that because the operands were reversed. Handle that
case better.
PR c++/103185
gcc/cp/ChangeLog:
* typeck.cc (cp_build_array_
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
maybe_splice_retval_cleanup assumed that the function body can't be empty if
there's a throwing cleanup, but when I added cleanups to try blocks in
r12-6333-gb10e031458d541 I didn't adjust that assumption.
PR c++/113088
PR c
On 12/20/23 17:07, Patrick Palka wrote:
Bootstrap and regtesting in progress on x86_64-pc-linux-gnu, does this
look OK for trunk if successful?
-- >8 --
Since r14-4977-g0f2e2080685e75 the -Wparentheses warning now undesirably
warns on the idiom
Wparentheses-34.C:9:14: warning: suggest parenthe
On 12/20/23 14:20, Jakub Jelinek wrote:
Hi!
The following patch enables the -Walloc-size and -Wcalloc-transposed-args
warnings for C++ as well.
Ok for trunk if it passes bootstrap/regtest?
2023-12-20 Jakub Jelinek
gcc/c-family/
* c.opt (Walloc-size): Enable also for C++ and ObjC++.
On 12/20/23 02:39, Richard Biener wrote:
On Tue, Dec 19, 2023 at 6:41 PM Jason Merrill wrote:
On 12/11/23 22:00, Jason Merrill wrote:
OK for trunk?
Ping. CCing Alex because this could plausibly be considered build
machinery, and he's had useful feedback on my sh code before.
OK in
On 12/20/23 18:29, Jakub Jelinek wrote:
On Wed, Dec 20, 2023 at 05:45:05PM -0500, Jason Merrill wrote:
On 12/20/23 14:20, Jakub Jelinek wrote:
+ if ((warn_sizeof_pointer_memaccess || alloc_size_attr)
&& (complain & tf_warning)
&& !vec_
On 12/20/23 17:54, Patrick Palka wrote:
On Wed, 20 Dec 2023, Jason Merrill wrote:
On 12/20/23 17:07, Patrick Palka wrote:
Bootstrap and regtesting in progress on x86_64-pc-linux-gnu, does this
look OK for trunk if successful?
-- >8 --
Since r14-4977-g0f2e2080685e75 the -Wparentheses warn
This is one of those patches where I first did the basic thing and then thought
"well, or I could do a bit better..." several times...
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
PR37722 complains that a computed goto doesn't destroy objects that go out
of scope. In the PR we agreed
On 12/20/23 20:01, Patrick Palka wrote:
On Wed, 20 Dec 2023, Jason Merrill wrote:
On 12/20/23 17:54, Patrick Palka wrote:
On Wed, 20 Dec 2023, Jason Merrill wrote:
On 12/20/23 17:07, Patrick Palka wrote:
Bootstrap and regtesting in progress on x86_64-pc-linux-gnu, does this
look OK for
On 12/21/23 10:52, Patrick Palka wrote:
On Thu, Dec 21, 2023 at 8:29 AM Patrick Palka wrote:
On Wed, 20 Dec 2023, Ken Matsui wrote:
This patch removes the testsuite_tr1.h dependency from g++.dg/ext/is_*.C
tests since the header is supposed to be used only by libstdc++, not
front-end. This a
On 12/21/23 14:12, Patrick Palka wrote:
On Sat, 16 Sep 2023, Jason Merrill wrote:
On 9/15/23 12:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
Thanks a lot. Testing on cmcstl2 revealed that we don't maintain
visibility
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Recently a mangling test failed on a target with no mangling alias support
because I hadn't updated the expected mangling, but it was still passing on
x86_64-pc-linux-gnu because of the alias for the old mangling. So let's
avoid these alias
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We were getting sizeof... mangling wrong when the argument after
substitution was a pack expansion that is not a simple T..., such as
list... in variadic-mangle4.C or (A+1)... in variadic-mangle5.C. In the
former case we ICEd; in the latter
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As with 37722, we don't clean up the exception object if a computed goto
leaves a catch block, but we can warn about that.
PR c++/81438
gcc/cp/ChangeLog:
* decl.cc (poplevel_named_label_1): Handle leaving catch.
(c
On 12/22/23 04:01, waffl3x wrote:
int n = 0;
auto f = [](this Self){
static_assert(__is_same (decltype(n), int));
decltype((n)) a; // { dg-error {is not captured} }
};
f();
Could you clarify if this error being removed was intentional. I do
recall that Patrick Palka wanted
On 12/23/23 02:10, waffl3x wrote:
On Friday, December 22nd, 2023 at 10:26 AM, Jason Merrill
wrote:
On 12/22/23 04:01, waffl3x wrote:
int n = 0;
auto f = [](this Self){
static_assert(__is_same (decltype(n), int));
decltype((n)) a; // { dg-error {is not captured} }
};
f();
Could you
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline' should be emitted in TUs where they
are ODR-used. We need to make sure that statics imported from modules
are correctly added to the 'pending_statics' map so that they get
emitted if needed, otherwise the attached testca
On 1/4/24 17:24, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline' should be emitted in TUs where they
are ODR-used. We need to make sure that statics imported from m
On 1/4/24 18:02, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 05:42:34PM -0500, Jason Merrill wrote:
On 1/4/24 17:24, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline'
On 1/8/24 04:21, Iain Sandoe wrote:
On 6 Jan 2024, at 22:30, Nathan Sidwell wrote:
Richard Smith & I discussed whether we should use the module interface's
capability of giving vague linkage entities a strong location. I didn't want to go
messing with that, 'cos it was changing yet more stuff
On 1/5/24 15:01, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
Here during default template argument substitution we wrongly consider
the (substituted) default arguments v and vt as value-dependent[1]
which ultimately leads to dedu
On 1/6/24 19:00, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
I'm considering this finished, I have CWG2586 working but I have not
included it in this version of the patch. I was not happy with the
amount of work I had done on it. I will try to get it finished befo
On 1/9/24 15:58, Jason Merrill wrote:
On 1/6/24 19:00, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
I'm considering this finished, I have CWG2586 working but I have not
included it in this version of the patch. I was not happy with the
amount of work I had
On 1/9/24 17:34, waffl3x wrote:
On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill
wrote:
On 1/9/24 15:58, Jason Merrill wrote:
On 1/6/24 19:00, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
I'm considering this finished, I have CWG2586 working
On 11/30/23 01:36, waffl3x wrote:
On Wednesday, November 29th, 2023 at 10:00 PM, Jason Merrill
wrote:
On 11/27/23 00:35, waffl3x wrote:
+ val = handle_arg(TREE_VALUE (parm),
Missing space.
Is there a script I can use for this so I'm not wasting your time on
little typos like thi
On 11/29/23 17:01, Marek Polacek wrote:
On Wed, Nov 29, 2023 at 03:28:44PM -0500, Jason Merrill wrote:
On 11/29/23 12:43, Marek Polacek wrote:
On Wed, Nov 29, 2023 at 12:23:46PM -0500, Patrick Palka wrote:
On Wed, 29 Nov 2023, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux
On 11/23/23 11:46, Marek Polacek wrote:
v5 greatly simplifies the code.
Indeed, it's much cleaner now.
I still need a new ff_ flag to signal that we can return immediately
after seeing an i-e expr.
That's still not clear to me:
+ /* In turn, maybe promote the function we find ourselv
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
More adjustments to allow for explicit object parameters in lambdas. This
has no practical effect until that patch goes in, but applying this
separately seems reasonable.
gcc/cp/ChangeLog:
* semantics.cc (finish_non_static_data_me
On 12/1/23 01:02, waffl3x wrote:
I ran into another issue while devising tests for redeclarations of
xobj member functions as static member functions and vice versa. I am
pretty sure by the literal wording of the standard, this is well formed.
template
concept Constrain = true;
struct S {
vo
On 12/1/23 12:32, Patrick Palka wrote:
On Tue, 14 Nov 2023, Jason Merrill wrote:
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For decltype((x)) within a lambda where x is not captured, we dubiously
requ
On 12/1/23 15:40, Alexandre Oliva wrote:
On Nov 9, 2023, Jonathan Wakely wrote:
On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva wrote:
g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run u
On 12/1/23 18:37, Marek Polacek wrote:
On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote:
On 11/23/23 11:46, Marek Polacek wrote:
v5 greatly simplifies the code.
Indeed, it's much cleaner now.
I still need a new ff_ flag to signal that we can return immediately
after seei
On 12/1/23 20:31, waffl3x wrote:
On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill
wrote:
On 12/1/23 01:02, waffl3x wrote:
I ran into another issue while devising tests for redeclarations of
xobj member functions as static member functions and vice versa. I am
pretty sure by the
On 12/1/23 17:42, Patrick Palka wrote:
On Fri, 1 Dec 2023, Jason Merrill wrote:
On 12/1/23 12:32, Patrick Palka wrote:
On Tue, 14 Nov 2023, Jason Merrill wrote:
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- &g
On 12/2/23 05:51, Jakub Jelinek wrote:
Hi!
foo in the unroll-5.C testcase ICEs because cp_parser_pragma_unroll
during parsing calls maybe_constant_value unconditionally, which is
fine if !processing_template_decl, but can ICE otherwise.
While just calling fold_non_dependent_expr there instead c
On 12/4/23 15:23, Marek Polacek wrote:
+/* FN is not a consteval function, but may become one. Remember to
+ escalate it after all pending templates have been instantiated. */
+
+void
+maybe_store_immediate_escalating_fn (tree fn)
+{
+ if (unchecked_immediate_escalating_function_p (fn))
+
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Mentioning a noreturn function does not involve an lvalue-rvalue
conversion.
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1): Fix
check for loading volatile lvalue.
gcc/testsuite/ChangeLog:
* g+
On 12/5/23 01:55, Jakub Jelinek wrote:
Hi!
When committing the #pragma GCC unroll patch, I found I forgot one spot
for diagnosting the invalid unrolls - if #pragma GCC unroll argument is
dependent and the pragma is before a range for loop, the unroll tree (now,
before one converted form ushort)
On 12/5/23 02:40, Jakub Jelinek wrote:
Hi!
Seems in 2017 attribute-specifier-seq[opt] was added to asm-declaration
and the change was voted in as a DR.
The following patch implements it by parsing the attributes and warning
about them.
I found one attribute parsing bug I'll send a fix for mome
On 12/5/23 11:03, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:07:19AM -0500, Jason Merrill wrote:
Please. Maybe check_pragma_unroll? check_unroll_factor?
So like this (assuming it passes bootstrap/regtest, so far passed just
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g
Tested x86_64-pc-linux-gnu. Are the library test changes OK? A reduced
example of the issue is at https://godbolt.org/z/cPxrcnKjG
-- 8< --
Looks like we implemented option 1 (skip the object parameter) for CWG532
before the issue was resolved, and never updated to the final resolution of
option
On 12/5/23 23:23, waffl3x wrote:
Does CWG2834 effect this weird edge case?
2834 affects all partial ordering with explicit object member functions;
currently the working draft says that they get an additional fake object
parameter, which is clearly wrong.
I couldn't quite grasp the
standar
On 12/6/23 01:02, waffl3x wrote:
On Tuesday, December 5th, 2023 at 9:36 PM, Jason Merrill
wrote:
On 12/5/23 23:23, waffl3x wrote:
Does CWG2834 effect this weird edge case?
2834 affects all partial ordering with explicit object member functions;
Both in relation to each other, and to
On 12/7/23 04:28, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled because two ubsan instrumentations
run into each other.
The first one is the shift instrumentation. Before the C++ FE calls
it, it wraps the 2 shift arguments with cp_save_expr, so that side-effects
in them aren't
On 12/6/23 09:10, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 11:01:20AM -0500, Jason Merrill wrote:
And there is another thing I wonder about: with -Wno-attributes= we are
supposed to ignore the attributes altogether, but we are actually still
warning about them when we emit these generic
On 12/5/23 15:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This test shows that we cannot clear *walk_subtrees in
cp_fold_immediate_r when we're in_immediate_context, because that,
as the comment says, affects cp_fold_r as well. Here we had an
e
mp;& DECL_IOBJ_MEMBER_FUNCTION_P (expr))
...and so I think this should be _OBJECT_.
https://godbolt.org/z/r6v4e1ePP
Here's a patch to adjust all the remaining
DECL_NONSTATIC_MEMBER_FUNCTION_P. With this patch -diagnostic7.C gets
the old address of non-static diagnostic, I think corr
On 12/8/23 12:35, Jakub Jelinek wrote:
On Fri, Dec 08, 2023 at 11:51:19AM -0500, Jason Merrill wrote:
Do we want to do the same for TARGET_EXPR, since those are handled like
SAVE_EXPR in mostly_copy_tree_r?
In mostly_copy_tree_r yes, but I don't see cp_fold doing anything for
TARGET_
On 12/8/23 12:53, Jakub Jelinek wrote:
On Fri, Dec 08, 2023 at 12:06:01PM -0500, Jason Merrill wrote:
@@ -2,7 +21116,7 @@ cp_parser_elaborated_type_specifier (cp_
}
else if (is_declaration && cp_parser_declares_only_class_p (parser))
cplus_decl_attribute
On 12/5/23 12:17, Marek Polacek wrote:
On Tue, Dec 05, 2023 at 06:00:31PM +0100, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 09:45:32AM -0500, Marek Polacek wrote:
When working on the previous patch I put [[]] [[]] asm (""); into a
testcase, but was surprised it wasn't parsed.
By wasn't pars
On 12/8/23 16:15, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote:
On 12/5/23 15:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This test shows that we cannot clear *walk_subtrees in
cp_fold_immediate_r w
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to have
broken by doing this and I wasn't able to find a
On 11/27/23 06:07, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634626.html.
I've been made aware since constructing this patch of CWG2820, which has
a proposed resolution that would change the result of the testcase
'noexcept(yesthrow_t())' (and similar
On 11/24/23 13:09, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
A rewritten guide for alias CTAD isn't really a specialization of the
original guide, so we shouldn't register it as such. This avoids an ICE
in the below mod
other was a formatting
fix, the lats was using TYPE_PTRDATAMEM_P for CPTK_IS_MEMBER_OBJECT_POINTER.
I'm leaving the library patches for library folks to apply.
Thanks!
Jason
From e410303f768fa7b020e46f3bd7d28381144e5340 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Fri, 8 Dec 202
On 12/10/23 05:22, Richard Biener wrote:
Am 09.12.2023 um 21:13 schrieb Jason Merrill :
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_
On 11/23/23 08:40, Nathaniel Shead wrote:
Sorry, I just noticed I hadn't actually filled in the changelog. It
should say "Clear DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P."
OK with that change.
On Thu, Nov 23, 2023 at 11:54 PM Nathaniel Shead
wrote:
Bootstrapped and regtested on x86_64-pc-linux
On 12/10/23 10:22, waffl3x wrote:
On Friday, December 8th, 2023 at 12:25 PM, Jason Merrill
wrote:
On 12/6/23 02:33, waffl3x wrote:
Here is the next version, it feels very close to finished. As before, I
haven't ran a bootstrap or the full testsuite yet but I did run the
explicit-obj
Adjusted thus:
From fa99f7d12b87f36d3c38349fcdcfca074564858d Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Sun, 10 Dec 2023 14:20:32 -0500
Subject: [PATCH] doc: small tweak
To: gcc-patches@gcc.gnu.org
Mention Objective-C++ here to be consistent with the surrounding C/ObjC
lines.
gcc/Cha
On 11/30/23 10:46, Patrick Palka wrote:
On Fri, 27 Oct 2023, Patrick Palka wrote:
On Fri, 27 Oct 2023, Jason Merrill wrote:
On 10/27/23 15:55, Patrick Palka wrote:
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g
On 12/10/23 21:04, Nathaniel Shead wrote:
On Sat, Dec 09, 2023 at 03:40:44PM -0500, Jason Merrill wrote:
On 11/27/23 06:07, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634626.html.
I've been made aware since constructing this patch of CWG2820,
601 - 700 of 11600 matches
Mail list logo
