On 10/28/23 00:07, waffl3x wrote:
I wanted to change DECL_NONSTATIC_MEMBER_FUNCTION_P to include explicit
object member functions, but it had some problems when I made the
modification. I also noticed that it's used in cp-objcp-common.cc so
would making changes to it be a bad idea?
-- cp-tree.h
On 11/2/23 11:28, Marek Polacek wrote:
On Sat, Oct 14, 2023 at 12:56:11AM -0400, Jason Merrill wrote:
On 10/10/23 13:20, Marek Polacek wrote:
On Tue, Aug 29, 2023 at 03:26:46PM -0400, Jason Merrill wrote:
On 8/23/23 15:49, Marek Polacek wrote:
+struct A {
+ int x;
+ int y = id(x
On 11/3/23 00:44, waffl3x wrote:
That leaves 2, 4, and 5.
2. I am pretty sure xobj functions should have the struct they are a
part of recorded as the method basetype member. I have already checked
that function_type and method_type are the same node type under the
hood and it does appear to be,
LGTM but I'd like Marek to approve it.
On Fri, Nov 3, 2023, 3:12 PM Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because with -Wno-attributes=foo::no_sanitize
> (but generally any other non-gnu namespace and some gnu well known
> attribute
> name within that other namespace) the F
The C++11 requirement that an explicit exception-specification on a
defaulted function match the implicit one was found to be problematic for
std::atomic. This paper, adopted in February, simply removes that
requirement: if an explicitly defaulted function has a different
exception-specification,
OK.
On Mon, Oct 28, 2019 at 7:56 PM Paul Pluzhnikov via gcc-patches
wrote:
>
> Greetings,
>
> This is rather on the trivial side. Google fuzzer found signed integer
> overflow in d_number, given this input: _ZZccDF2147483647
> Google ref: b141647507.
>
> Ok for trunk?
>
> Thanks,
>
> libiberty/Ch
On 10/22/19 11:03 AM, Jakub Jelinek wrote:
Hi!
The following patch is just a partial fix for a regression introduced
in the PR90947 changes, the testcase is fixed for just C++17/20.
type_initializer_zero_p has been added to the generic code, supposedly
because similar initializer_zerop is in gen
On 10/22/19 2:52 PM, Marek Polacek wrote:
On Tue, Oct 22, 2019 at 08:48:30PM +0200, Paolo Carlini wrote:
Hi,
at the moment I'm going through more typeck.c and typeck2.c functions: the
below are some straightforward changes for build_x_unary_op (fwiw, the
resulting locations are also consistent
On 10/23/19 2:10 PM, Marek Polacek wrote:
This fixes a bogus "modifying a const object" error for an array that actually
isn't declared const. The problem was how I handled ARRAY_REFs here; we
shouldn't look at the ARRAY_REF itself, but at the array its accessing.
Bootstrapped/regtested on x86_
On 10/23/19 6:35 PM, Jakub Jelinek wrote:
Hi!
For middle-end pointer conversions are useless, which means the gimplifier
can change the type of the value being gimplified.
gimplify_call_expr is careful about this and remembers the fnptrtype early
before gimplification and
else
/* Remembe
On 10/25/19 2:38 PM, Marek Polacek wrote:
After r269667 which introduced joust_maybe_elide_copy, in C++17 we can elide
a constructor if it uses a conversion function that returns a prvalue, and
use the conversion function in its stead.
This eliding means that if we have a candidate that previous
On 10/24/19 10:07 AM, Paolo Carlini wrote:
Hi,
some additional straightforward bits in typeck.c, which I noticed when I
went through the cp_build_binary_op callers. Tested x86_64-linux.
Thanks, Paolo.
//
OK.
On 10/24/19 3:24 PM, Marek Polacek wrote:
When fixing c++/91889 (r276251) I was assuming that we couldn't have a ck_qual
under a ck_ref_bind, and I was introducing it in the patch and so this
+ if (next_conversion (convs)->kind == ck_qual)
+ {
+ gcc_assert (same_type_p (TREE_TYPE (exp
On 10/24/19 5:50 PM, Marek Polacek wrote:
I noticed that for code like
struct S {
int *foo : 3;
};
we generate nonsensical
r.C:2:8: error: function definition does not declare parameters
2 | int *foo : 3;
It talks about a function because after parsing the declspecs of
On 10/24/19 6:30 PM, Marek Polacek wrote:
I wasn't properly setting LOOKUP_CONSTINIT in grokfield and so we didn't
detect a non-const initializer.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
2019-10-24 Marek Polacek
PR c++/92134 - constinit malfunction in static dat
A cleanup I noticed while working on operator<=>.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/cxx-pretty-print.c | 48 ++-
1 file changed, 2 insertions(+), 46 deletions(-)
diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 2
On 10/30/19 9:30 AM, Marek Polacek wrote:
On Wed, Oct 30, 2019 at 10:58:57AM +0100, Jakub Jelinek wrote:
On Fri, Oct 25, 2019 at 10:44:18AM -0400, Marek Polacek wrote:
That is... sneaky. I guess I/we need to test with
--enable-symvers=gnu-versioned-namespace every now and then.
Indeed.
Pro
On 10/12/19 2:10 PM, Bernd Edlinger wrote:
On 10/11/19 6:31 PM, Jason Merrill wrote:
On 10/10/19 2:06 PM, Bernd Edlinger wrote:
On 10/10/19 7:49 PM, Jason Merrill wrote:
On 10/10/19 10:42 AM, Bernd Edlinger wrote:
Hi,
this fixes a crash when -Wshadow=compatible-local is
enabled in the
On 10/24/19 5:11 AM, Jakub Jelinek wrote:
Hi!
Jonathan has showed me a testcase with std::allocator::{,de}allocate
and std::construct_at which FAILs with the current constexpr new
implementation.
There are two problems that make the testcase rejected, and further issues
(not addressed by this p
On 10/24/19 7:47 AM, Jakub Jelinek wrote:
On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
So, do you prefer to do it the other way during build_cxx_call?
It seems more straightforward.
I've tried this approach, but am running into issues:
1) the normal constructors aren
Previously we would put the template arguments for the concept-check in a
TEMPLATE_ID and then also pass them to constraints_satisfied_p, which meant
that we would try to normalize the concept-check with the fully instantiated
arguments, leading to sadness. Simply not passing the args to
constrain
On 10/30/19 7:20 AM, Jeff Chapman wrote:
Hello,
Attached is a patch that adds parsing of the optional requires-clause in a
lambda-expression and lambda-declarator. Additionally, shorthand constraints
from the template-parameter-list are now actually applied and constrain the
synthesized operator
On 10/30/19 7:29 PM, Jakub Jelinek wrote:
On Tue, Oct 29, 2019 at 04:26:14PM -0400, Jason Merrill wrote:
I think type_initializer_zero_p should return false if
CLASSTYPE_NON_AGGREGATE; we can't expect that value-initialization will have
the intended effect in that case.
That indeed work
On 10/31/19 1:10 PM, Jakub Jelinek wrote:
On Wed, Oct 30, 2019 at 11:05:29PM +0100, Jakub Jelinek wrote:
Looks like there used to be a TREE_CALLS_NEW flag in TREE_LANG_FLAG_1, but
that flag is now free for CALL_EXPR.
I'll try a CALL_EXPR flag first.
TREE_LANG_FLAG_1 is also STMT_IS_FULL_EXPR
On 10/31/19 1:21 PM, Jakub Jelinek wrote:
On Wed, Oct 30, 2019 at 05:06:00PM -0400, Jason Merrill wrote:
build_cplus_new does the magic of replacing a dummy argument, e.g.
if (obj_arg && is_dummy_object (obj_arg))
{
call = build_cplus_new (DECL
On 11/1/19 10:06 AM, Paolo Carlini wrote:
Hi again,
On 31/10/19 16:56, Paolo Carlini wrote:
Hi,
yesterday I noticed that we want to forward the location parameter of
cp_build_binary_op to composite_pointer_type and then
composite_pointer_error. Note, for the time being at least, this is
alw
On Sat, Oct 19, 2019 at 6:35 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Sat, Oct 19, 2019 at 12:46:56AM -0400, Jason Merrill wrote:
> > gcc/testsuite/g++.dg/cpp2a
> > * nodiscard-construct.C: New test.
> > * nodiscard-once.C: New test.
>
On 10/22/19 10:53 AM, Marek Polacek wrote:
This patch implements C++20 P0960R3: Parenthesized initialization of aggregates
(; see R0 for more background info). Essentially, if you have
an aggregate, you can now initialize it by (x, y), similarly to {x, y}. E.g.
struct A {
int x, y;
On 11/1/19 3:57 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2019 at 03:42:58PM -0400, Jason Merrill wrote:
+ for (size_t n = cp_parser_skip_balanced_tokens (parser, 1); ; n++)
+ {
+ size_t after = cp_parser_skip_attributes_opt (parser, n);
+ if (after >
On 11/1/19 4:42 PM, Marek Polacek wrote:
On Fri, Nov 01, 2019 at 04:37:15PM -0400, Jason Merrill wrote:
On 10/22/19 10:53 AM, Marek Polacek wrote:
This patch implements C++20 P0960R3: Parenthesized initialization of aggregates
(; see R0 for more background info). Essentially, if you have
an
On 10/31/19 2:06 PM, kamlesh kumar wrote:
Jason,
Can you please review this,
let me know how can we handle -fabi-version?
We should bump latest_abi_version in c-opts.c and use
abi_version_at_least to control this change.
On Wed, Oct 23, 2019 at 7:55 AM Kamlesh Kumar wrote:
---
gcc/cp/m
On 11/1/19 5:19 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2019 at 09:56:44PM +0100, Jakub Jelinek wrote:
Ah, used 8.x to test it. There have been r265787 and r269775 changes in
between.
Though
auto d = [] () mutable __attribute__((noreturn)) constexpr {};
auto e = [] () mutable [[noreturn]
On 11/1/19 11:47 PM, Kamlesh Kumar wrote:
Changlogs
gcc
--
2019-11-02 Kamlesh Kumar
PR c++/91979 - mangling nullptr expression
* mangle.c (write_template_arg_literal): Handle nullptr
mangling.
* testsuite/g++.dg/cpp0x/nullptr27.C: Modify Test.
I noticed that when returning an ambiguous call in a void function, we then
uselessly gave another error about returning a non-void expression.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/typeck.c | 2 +-
gcc/testsuite/g++.dg/other/return2.C | 7 +++
2 fil
On 11/3/19 6:42 AM, Kamlesh Kumar wrote:
ChangeLog Entries:
gcc/cp
--
2019-11-02 Kamlesh Kumar
PR c++/91979 - mangling nullptr expression
* cp/mangle.c (write_template_arg_literal): Handle nullptr
mangling.
gcc
--
2019-11-02 Kamlesh Kumar
* co
OK. I wonder why we're returning false for EMPTY_CLASS_EXPR?
On Tue, Nov 5, 2019 at 7:35 AM Jakub Jelinek wrote:
>
> Hi!
>
> When Martin Liska added PREDICT_EXPR to potential_constant_expression_1,
> it was with goto in mind and in that case goto isn't a potential
> constant expression, but when
trunk.
commit 88d071f8e0a1637bc95e78c5a52ff44423946bfc
Author: Jason Merrill
Date: Tue Nov 5 10:44:34 2019 +
Catch missed uses of function with unsatisfied constraints.
While looking at CA378 I noticed that we weren't properly diagnosing two of
the three erroneous li
Wrappers for lookup_qualified_name and build_x_binary_op to make calling
them more convenient in places, and a function named contextual_conv_bool
for places that want contextual conversion to bool.
I noticed that we weren't showing the declaration location when we complain
about a call to a non-c
My operator<=> patch wants to split up build_new_op_1, which makes using a
tree array as well as the vec inconvenient. build_new_op_1 already has a
vec, and build_conditional_expr_1 can release its vec right away, so this
doesn't increase garbage at all.
Tested x86_64-pc-linux-gnu, applying to tr
I'm applying this patch again now, this time with a tweak to expmed.c
to prevent the false positive warning from breaking bootstrap. I
don't see any problem in the gimple output, so the bug must be in the
middle-end somewhere.
On Thu, Sep 19, 2019 at 8:43 PM Jason Merrill wrote
There are three major pieces to this support: scalar operator<=>,
synthesis of comparison operators, and rewritten/reversed overload
resolution (e.g. a < b becomes 0 > b <=> a).
Unlike other defaulted functions, where we use synthesized_method_walk to
semi-simulate what the definition of the funct
7;s what I'm applying:
Jason
commit c3e97f573b6e29324ef72ded63e0307cec8d2ce2
Author: Jason Merrill
Date: Tue Nov 5 17:31:44 2019 +
Fix parser to recognize operator?:
This change lets grok_op_properties print its useful "ISO C++ prohibits
overloading operator ?:" message inste
No real use cases have arisen for constraints on non-templated
functions, and handling of them has never been entirely clear, so the
committee agreed to accept this national body comment proposing that we
remove them.
Tested x86_64-pc-linux-gnu, applying to trunk.
* decl.c (grokfndecl): R
re comprehensive diagnostics, but do not enable.
* parser.c (cp_parser_requires_expression): Relax requirement that
requires-expressions can live only inside templates.
* pt.c (any_template_parm_r): Look into type of PARM_DECL.
2019-11-0
ISO C++ paper D1907R1 proposes "structural type" as an alternative to the
current notion of "strong structural equality", which has various problems.
I'm implementing it to give people a chance to try it.
The build_base_field changes are to make it easier for structural_type_p to
see whether a bas
Shortly after I finished implementing the previous <=> semantics, the
committee decided to remove the *_equality comparison categories, because
they were largely obsoleted by the earlier change that separated operator==
from its original dependency on operator<=>.
Tested x86_64-pc-linux-gnu, apply
OK.
On 11/7/19 3:38 PM, Jakub Jelinek wrote:
Hi!
GCC does use UTF-16 and UTF-32 for char16_t and char32_t string literals
already, so P1041R4 is I believe already implemented with no changes needed.
While going through P1139R2, I've realized that we weren't handling
"If the value is not repres
This paper was delayed until the February meeting in Prague so that we could
get a better idea of what the impact on existing code would actually be. To
that end, I'm implementing it now.
Tested x86_64-pc-linux-gnu, applying to trunk.
* typeck2.c (check_narrowing): Treat pointer->bool as
OK, thanks.
On Mon, Nov 11, 2019 at 3:14 PM Jakub Jelinek wrote:
> Hi!
>
> The finish_function change to goto cleanup; on DECL_DELETED_FN added
> in the spaceship commit broke the following testcase.
> The problem is that during start_preparsed_function push_nested_class
> pushes a scope, but as
I'm not sure what semantics we might eventually want for vector <=>, but let's
give a sorry for now.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/typeck.c | 7 +++
gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C | 11 +++
2 files changed, 18 inse
ng to trunk.
commit 0cbd94b2731032f1e0ec0a576f7b59cbcfded735
Author: Jason Merrill
Date: Fri Nov 8 21:57:44 2019 +
Implement P1946R0, Allow defaulting comparisons by value.
* method.c (early_check_defaulted_comparison): Accept by-value,
reject mix
On 10/25/19 2:53 PM, Richard Sandiford wrote:
One of the changes in r277281 was to make the typedef variant
handling in strip_typedefs pass the raw DECL_ORIGINAL_TYPE to the
recursive call, instead of applying TYPE_MAIN_VARIANT first.
This PR shows that that interacts badly with the implementatio
On Wed, Nov 13, 2019 at 6:39 AM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> On Tue, Nov 12, 2019 at 04:17:17PM +0300, Konstantin Kharlamov wrote:
> > On Вт, ноя 12, 2019 at 14:08, Andreas Schwab
> > wrote:
> > >On Nov 12 2019, Konstantin Kharlamov wrote:
> > >> I'm definitely missin
OK.
On Tue, Nov 12, 2019 at 11:45 AM Marek Polacek wrote:
> This is a complaint that we issue a [[nodiscard]] warning even in SFINAE
> contexts. Here 'complain' is tf_decltype, but not tf_warning so I guess
> we can fix it as below.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
>
On 1/9/20 3:59 AM, Jakub Jelinek wrote:
On Thu, Jan 09, 2020 at 02:20:23PM +0800, Bin.Cheng wrote:
On December 20, 2019 2:13:47 AM GMT+01:00, "Bin.Cheng"
wrote:
On Fri, Dec 13, 2019 at 11:26 AM bin.cheng
wrote:
Hi,
As reported in PR92926, constant ctor is shared translation unit wide
bec
On 1/9/20 4:37 PM, Jakub Jelinek wrote:
On Thu, Jan 09, 2020 at 04:27:09PM -0500, Jason Merrill wrote:
Isn't the right spot to fix this somewhere in cp_gimplify_expr?
I mean, the way gimplification works, we unshare_body first and then
gimplify, which is destructive for the GENERIC
afe_conversion_p back into conversion_warning with the others.
rshift.diff restores the short_shift code to the C++ front end so that C
and C++ give the same warnings with -Warith-conversion.
Tested x86_64-pc-linux-gnu. Comments?
commit 77b31408e3de8178f20972744d06501adb6ea961
Author: Jason M
My patch for 93033 wasn't sufficient to handle all the possible sharing
introduced by split_nonconstant_init, and it occurred to me that it would
make sense to use the same unsharing technique as unshare_body, namely
copy_if_shared.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93
We don't unshare CONSTRUCTORs as often during constexpr evaluation, so we
need to unshare them here.
Many thanks to bin cheng for the analysis and initial patch.
Tested x86_64-pc-linux-gnu, applying to trunk.
* constexpr.c (cxx_eval_outermost_constant_expr): Don't assume
CONSTRUC
The library has already worked around this issue, but I was curious about
why it wasn't working. The answer: because we were passing &var to fold,
which doesn't know about the constexpr values hash table. Fixed by passing
&"str" instead.
Tested x86_64-pc-linux-gnu. Does this seem useful even th
This is a pretty rare situation since the C++11 change to make all
destructors default to noexcept, but it is still possible to define throwing
destructors, and if a destructor for a local variable throws during the
return, we've already constructed the return value, so now we need to
destroy it.
On 1/11/20 10:54 AM, Richard Earnshaw (lists) wrote:
On 11/01/2020 15:41, Segher Boessenkool wrote:
Hi Richard,
On Thu, Jan 09, 2020 at 04:50:03PM +, Richard Earnshaw (lists) wrote:
Given the proposed intention to use non-standard refspecs for private
and vendor branches I've written some
On Mon, Jan 13, 2020 at 6:11 AM Jonathan Wakely wrote:
> On 11/01/20 00:03 -0500, Jason Merrill wrote:
> >The library has already worked around this issue, but I was curious about
> >why it wasn't working. The answer: because we were passing &var to fold,
> &g
On 12/12/19 3:44 PM, Jason Merrill wrote:
On Wed, Dec 11, 2019 at 1:37 PM Jeff Law <mailto:l...@redhat.com>> wrote:
On Wed, 2019-12-11 at 00:03 -0700, Sandra Loosemore wrote:
> On 12/6/19 3:41 PM, Jeff Law wrote:
> > On Wed, 2019-11-13 at 09:27 -0700, Sand
Here, we weren't recognizing that the template parameter of A is used by the
reference to d in the requires-clause of f. Fixed by passing down the
active template parameters in the context of normalization, and adding to
the mapping any such parameters shared by a member template used in the
const
Another place that needs to specially handle Concepts TS function-style
concepts.
Tested x86_64-pc-linux-gnu, applying to trunk.
* except.c (check_noexcept_r): Handle concept-check.
---
gcc/cp/except.c | 2 ++
gcc/testsuite/g++.dg/concepts/fn-concept3.C | 6 ++
I wonder why nobody fixed this until now; it's been two years since the
diagnostic context output was changed.
Tested x86_64-pc-linux-gnu, applying to trunk.
* lib/prune.exp (prune_gcc_output): Adjust constexpr pattern.
---
gcc/testsuite/lib/prune.exp | 2 +-
1 file changed, 1 insertion(
There were two issues in this PR:
1) We were crashing in is_really_empty_class because we say that the
internal RTTI types are classes, but never gave them TYPE_BINFO.
2) We were allowing the cast to a different pointer type because STRIP_NOPS
in cxx_fold_indirect_ref ignored REINTERPRET_CAST_P.
Here we were getting confused about whether or not pod_tuple has a trivial
default constructor. bar inherits the trivial e default constructor; the
effect of calling that inherited constructor is equivalent to calling a
defaulted default constructor in bar, so let's treat it as such.
Tested x86_6
On 1/14/20 2:14 PM, Nathan Sidwell wrote:
+ if (tree ti = (TREE_CODE (fn) == TYPE_DECL && !TYPE_DECL_ALIAS_P (fn)
+? TYPE_TEMPLATE_INFO (TREE_TYPE (fn))
+: DECL_TEMPLATE_INFO (fn)))
Is there a reason not to use get_template_info?
Jason
I thought my earlier fix for 91930 was an obvious bug fix, but apparently an
inherited constructor does not count as user-declared. So this patch
reverts that change and the other follow-on patches, and fixes 91930
differently, by not letting the inherited default constructor hide the
implicitly-d
I steered Jakub wrong on the desired behavior for temp-extend1.C in the
context of bug 92831; it doesn't make sense to try to extend the lifetime of
a temporary that we've already materialized to evaluate the test. So this
patch munges the stabilized expression so that it won't be subject to
lifet
A prvalue can have void type, and if it doesn't do anything prohibited in a
constant expression, it's vacuously constant.
Tested x86_64-pc-linux-gnu, applying to trunk.
* constexpr.c (verify_constant): Allow void_node.
---
gcc/cp/constexpr.c | 3 ++-
gcc/testsu
On 1/11/20 12:12 AM, Jason Merrill wrote:
This is a pretty rare situation since the C++11 change to make all
destructors default to noexcept, but it is still possible to define throwing
destructors, and if a destructor for a local variable throws during the
return, we've already constructe
On Wed, Jan 15, 2020 at 5:56 PM Joseph Myers
wrote:
> A reasonable replacement for those push rules might be command aliases
> (e.g. "git upush " to push the user branch ).
>
And/or git mpush for push origin HEAD:master
Jason
I recently added an assert to cp-gimplify to catch any
TARGET_EXPR_DIRECT_INIT_P being expanded without a target object, and this
testcase found one. We started out with a TARGET_EXPR around the
CONSTRUCTOR, which would normally mean that the member initializer would be
used to directly initialize
Here we had been recursing in tsubst_copy_and_build if type2 was a TREE_LIST
because that function knew how to deal with pack expansions, and tsubst
didn't. But tsubst_copy_and_build expects to be dealing with expressions,
so we crash when trying to convert_from_reference a type.
Tested x86_64-pc
On 12/30/19 3:51 PM, Kerem Kat wrote:
+/* { dg-message "expected" "expected" { target *-*-* } .3 } */
Dejagnu doesn't like this:
ERROR: c-c++-common/pr92833-4.c -std=c++98: expected integer but got
".3" for " dg-message 4 "expected" "expected" { target *-*-* } .3 "
Jason
On 1/10/20 3:28 PM, Jakub Jelinek wrote:
Hi!
As the following testcase shows, when deprecated attribute is on a template,
we'd never print the message if any, because the attribute is not
present on the TEMPLATE_DECL with which warn_deprecated_use is called,
but on its DECL_TEMPLATE_RESULT or it
This was failing because uses_template_parms didn't recognize LAMBDA_EXPR as
a kind of expression. Instead of trying to enumerate all the different
varieties of expression and then aborting if what's left isn't
error_mark_node, let's handle error_mark_node and then assume anything else
is an expre
On 1/17/20 9:22 AM, Joseph Myers wrote:
On Fri, 17 Jan 2020, Joel Brobecker wrote:
The main goal of the limit is really to avoid accidents where someone
pushes something he shouldn't or something he didn't realize would
push so many commits. If the GCC repository is such that merges of
100 comm
Since we removed the special parsing for C++11 lambdas, it's just been an
open-coded copy of cp_parser_function_body. So let's call it instead. This
avoids the need to change this code in my revised 33799 patch.
Tested x86_64-pc-linux-gnu, applying to trunk.
* parser.c (cp_parser_lambda
This patch differs from the reverted patch for 33799 in that it adds the
CLEANUP_STMT for the return value at the end of the function, and only if
we've seen a cleanup that might throw, so it should not affect most C++11
code.
Tested x86_64-pc-linux-gnu, applying to trunk.
* cp-tree.h (cu
The problem in the PR was that make_temporary_var_for_ref_to_temp ran before
determine_visibility, so when we copied the linkage of the reference
variable it had not yet been restricted by its anonymous namespace context,
so the temporary wrongly ended up with TREE_PUBLIC set. The natural
solution
On 1/21/20 10:17 AM, Jason Merrill wrote:
The problem in the PR was that make_temporary_var_for_ref_to_temp ran before
determine_visibility, so when we copied the linkage of the reference
variable it had not yet been restricted by its anonymous namespace context,
so the temporary wrongly ended
On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote:
On 21/01/2020 15:39, Jakub Jelinek wrote:
On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote:
Some examples would be useful I'd say, e.g. it is unclear in what
way you
want the PR number to be appended, shall it be
some
We were failing to handle VLA capture in tsubst_lambda_expr; initially
building a DECLTYPE_TYPE for the capture and then tsubsting it doesn't give
the special VLA handling. So with this patch we call add_capture again for
VLAs.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (tsubs
For normal captures we usually look through them within unevaluated context,
but that doesn't work here; trying to take the sizeof of the array in the
enclosing scope tries and fails to evaluate a SAVE_EXPR from the enclosing
scope.
Tested x86_64-pc-linux-gnu, applying to trunk.
* lambda.
On 1/20/20 8:06 PM, Patrick Palka wrote:
The leak in get_mapped_args is due to auto_vec not properly supporting
destructible elements, in that auto_vec's destructor doesn't call the
destructors of its elements.
Hmm, perhaps vec should static_assert __is_trivial(T) when supported.
@@ -15344,6
On 1/19/20 4:18 PM, Marek Polacek wrote:
On Sun, Jan 19, 2020 at 10:00:42PM +0100, Jakub Jelinek wrote:
On Sun, Jan 19, 2020 at 03:34:48PM -0500, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-linux, ok for trunk?
* semantics.c (is_std_constant_evaluated_p): Check fndecl.
On 1/21/20 9:08 PM, Marek Polacek wrote:
Here the problem is that if the noexcept specifier is used in the context
of a const member function, const is not considered for the member variables,
leading to a bogus error. g's const makes its 'this' const, so the first
overload of f should be select
On 1/22/20 10:22 AM, Paolo Carlini wrote:
Hi,
in this simple issue we either wrongly talked about variable template-id
in c++17 mode or ICEd in c++2a. I think we simply want to handle
concept-ids first, both as represented in c++17 mode and as represented
in c++2a mode. Tested x86_64-linux.
On 1/22/20 11:33 AM, Marek Polacek wrote:
Here's what I did. Unfortunately it doesn't fix PR79620.
No, I wouldn't expect it to, that looks like more of an issue with how
is_lambda_ignored_entity skips captures in unevaluated context.
+ cp_cv_quals quals;
+ if (DECL_NONSTATIC_MEMBER_FUNCT
On 1/22/20 11:19 AM, Patrick Palka wrote:
On Tue, 21 Jan 2020, Jason Merrill wrote:
On 1/20/20 8:06 PM, Patrick Palka wrote:
The leak in get_mapped_args is due to auto_vec not properly supporting
destructible elements, in that auto_vec's destructor doesn't call the
destructors of it
On 1/22/20 5:14 AM, Martin Liška wrote:
Hi.
Just for the record, after the change 526.blender_r fails due to:
blender/source/blender/blenlib/intern/math_color.c: In function
'rgb_float_to_uchar':
blender/source/blender/blenlib/BLI_utildefines.h:251:22: error:
conversion from 'float' to 'unsig
On 1/22/20 3:31 PM, Paolo Carlini wrote:
Hi,
On 22/01/20 17:27, Jason Merrill wrote:
On 1/22/20 10:22 AM, Paolo Carlini wrote:
Hi,
in this simple issue we either wrongly talked about variable
template-id in c++17 mode or ICEd in c++2a. I think we simply want to
handle concept-ids first
On 1/22/20 1:20 PM, Jason Merrill wrote:
On 1/22/20 5:14 AM, Martin Liška wrote:
Hi.
Just for the record, after the change 526.blender_r fails due to:
blender/source/blender/blenlib/intern/math_color.c: In function
'rgb_float_to_uchar':
blender/source/blender/blenlib/BLI_utildefine
On 1/22/20 5:58 PM, Jason Merrill wrote:
On 1/22/20 1:20 PM, Jason Merrill wrote:
On 1/22/20 5:14 AM, Martin Liška wrote:
Hi.
Just for the record, after the change 526.blender_r fails due to:
blender/source/blender/blenlib/intern/math_color.c: In function
'rgb_float_to_uchar'
In a template we don't instantiate a deferred noexcept-spec, and we don't
need it because we aren't going to do anything with the value of
throwing_cleanup in a template anyway.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93345 - ICE with defaulted dtor and template.
PR
If we can't change the argument to &"...", use the original arg instead of
the partially munged one.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93331 - ICE with __builtin_strchr.
* constexpr.c (cxx_eval_builtin_function_call): Use the original
argument if we did
101 - 200 of 11472 matches
Mail list logo
