to trunk.
commit 00e76793666566b604903930c77d4a644ec74a12
Author: Jason Merrill ja...@redhat.com
Date: Tue Jun 17 16:35:57 2014 +0200
PR c++/61507
* pt.c (resolve_overloaded_unification): Preserve
ARGUMENT_PACK_EXPLICIT_ARGS.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d5cc257
We were treating a const member function like a normal const
reference, and binding an rvalue object argument to it. But it doesn't
work that way.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 20a165532a9b0b0dada391716a1fb781af3ec005
Author: Jason Merrill ja...@redhat.com
Date: Wed
On 06/19/2014 12:12 AM, Jason Merrill wrote:
We were treating a const member function like a normal const
reference, and binding an rvalue object argument to it. But it doesn't
work that way.
In 4.9 we also need to set LOOKUP_NO_TEMP_BIND.
commit 48ca9803695872d984b0f4efa56f7f58987d0928
On 06/19/2014 01:29 PM, Marc Glisse wrote:
That looks weird to me. The const version is a better match than the
const, so we should pick that one in overload resolution, but if we
remove the const version, the other one seems valid to me
Hmm, you're right, I was confused.
Jason
On 06/20/2014 03:11 PM, Jason Merrill wrote:
On 06/19/2014 01:29 PM, Marc Glisse wrote:
That looks weird to me. The const version is a better match than the
const, so we should pick that one in overload resolution, but if we
remove the const version, the other one seems valid to me
Hmm
Now that we're calling build_this in build_over_call, it needs to happen
on the template path as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit daf445b34181c222baa792e7310fc4af2d26ec3c
Author: Jason Merrill ja...@redhat.com
Date: Thu Jun 19 14:29:51 2014 +0200
PR c++/61556
On 06/22/2014 10:42 AM, Paolo Carlini wrote:
I think the below would be most of it. Today, however, I did some
archeology, noticed that we would essentially revert to pre-PR9278
behavior (thus, per its audit trail, make again unhappy some people in
the template metaprogramming world?!? Was that
OK.
Jason
On 06/23/2014 04:25 PM, Jan Hubicka wrote:
* class.c (check_methods, create_vtable_ptr, determine_key_method,
add_vcall_offset_vtbl_entries_1): Guard VINDEX checks by FUNCTION_DECL
check.
These changes are unnecessary: TYPE_METHODS is a list of functions.
The rest of the
OK.
Jason
OK, thanks.
Jason
On 06/26/2014 01:08 AM, Adam Butcher wrote:
Do you want me to apply to 4.9 too?
Please.
Jason
On 06/26/2014 11:15 AM, Ed Smith-Rowland wrote:
I, for one, would like gcc to bootstrap with c++11/c++14. I think we
should be starting to shake down that path. I'm probably not alone in
this.
Agreed.
On the other hand, I don't think c++-concepts branch should be the
leader on this. We
OK.
Jason
Now that we're past C++14, C++17(?) features are starting to be added to
the compiler, so we ought to have a switch for them.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit a4480bed3c7aca47203e910dec52d80d61b96b2e
Author: Jason Merrill ja...@redhat.com
Date: Thu Jun 26 12:57:07 2014
, for consistency with other C++11 features.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 00389876d06b03b2550f018e3f96a7b5525c9f38
Author: Jason Merrill ja...@redhat.com
Date: Tue Jun 24 06:15:02 2014 -0400
N3994 Ranged-based for-loops: The Next Generation
* parser.c
On 06/26/2014 12:23 PM, Jason Merrill wrote:
We could add -std=c++1z and add it to that, though.
Added.
Jason
OK.
Jason
On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:
So is C++14 a done deal with a __cplusplus date and all?
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason to
doubt that it will be done soon. The
OK.
Jason
On 06/27/2014 11:04 AM, Paul Pluzhnikov wrote:
Ok to backport r210653 (fix for PR58930) to gcc-4_9-branch?
OK, yes.
Jason
On 06/27/2014 03:27 AM, Dodji Seketeli wrote:
+ print.prev_was_system_token != !!in_system_header_at(loc))
+ /* The system-ness of this token is different from the one
+ of the previous token. Let's emit a line change to
+ mark the new
On 06/27/2014 09:41 AM, Ed Smith-Rowland wrote:
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
to doubt that it will be done soon. The __cplusplus date is 201402L.
I guess we should set this
, applying to trunk.
commit 2b1389491f53fd7ecc9dfe90b55c1d48c4c4548a
Author: Jason Merrill ja...@redhat.com
Date: Fri Jun 27 16:19:47 2014 -0400
PR c++/61433
* error.c (dump_template_bindings): Don't tsubst in a clone.
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 27a167a..fa3bdc4
Hmm, I wonder why we need BINFOs at all for the ptrmemfunc RECORD_TYPEs,
which are not classes.
Jason
OK.
Jason
: Jason Merrill ja...@redhat.com
Date: Mon Jun 30 10:41:22 2014 -0400
PR c++/61539
* pt.c (unify_one_argument): Type/expression mismatch just causes
deduction failure.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f0a598b..7f33b6d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
OK.
Jason
On 06/28/2014 05:57 PM, Ed Smith-Rowland wrote:
OK?
I would also like to apply this to 4.9.
OK.
Jason
On 06/30/2014 08:42 AM, Jason Merrill wrote:
Hmm, I wonder why we need BINFOs at all for the ptrmemfunc RECORD_TYPEs,
which are not classes.
I'm working on removing both BINFO and TYPE_LANG_SPECIFIC.
Jason
We were missing a way the function being called can be dependent.
Tested x86_64-pc-linux-gnu, applying to 4.8, 4.9, trunk.
commit 687aa57720473c7962c9eb9cf79c67cf068ba005
Author: Jason Merrill ja...@redhat.com
Date: Mon Jun 30 13:50:38 2014 -0400
PR c++/61647
* pt.c
decl_mangling_context was failing to recognize a lambda in template
context as a lambda.
Tested x86_64-pc-linux-gnu, applying to 4.9 and trunk.
commit 1ba7cf95c0b024c7a3372e0734d7bf620f31dd14
Author: Jason Merrill ja...@redhat.com
Date: Mon Jun 30 12:08:09 2014 -0400
PR c++/61566
On 06/30/2014 11:58 AM, Jason Merrill wrote:
On 06/30/2014 08:42 AM, Jason Merrill wrote:
Hmm, I wonder why we need BINFOs at all for the ptrmemfunc RECORD_TYPEs,
which are not classes.
I'm working on removing both BINFO and TYPE_LANG_SPECIFIC.
Like so. Applying to trunk.
commit
to trunk.
commit 3019e719de4a7d5972b0057c7da6bb40b198d3ab
Author: Jason Merrill ja...@redhat.com
Date: Mon Jun 30 14:39:17 2014 -0400
PR c++/61659
PR lto/53808
gcc/cp
* decl2.c (maybe_emit_vtables): Mark all vtable entries if
devirtualizing.
* init.c
On 07/01/2014 02:41 PM, Cary Coutant wrote:
Any objections to backporting these fixes to the 4.9 branch?
Nope.
Jason
OK.
Jason
On 07/01/2014 02:45 AM, Andreas Schwab wrote:
I'm getting this ABI change, is that OK?
-FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj@@CXXABI_1.3
Hmm, probably not, thanks.
Jason
On 06/30/2014 03:27 PM, Jan Hubicka wrote:
This catches two cases in C++ FE and several other cases elsewhere.
Does something like this make sense? I think bulitin_types are
generally public, but I am not quite sure about templates.
Template parms have no linkage, but they certainly don't
I think that makes sense; I'm not aware of anyone working on improving
LTO debugging.
Jason
On 07/02/2014 03:34 PM, Trevor Saunders wrote:
On Wed, Jul 02, 2014 at 09:28:03PM +0200, Jan Hubicka wrote:
it seems to me this doesn't get at the real issue that the type names
are the same but the fields are different. maybe a type of the same
name with different fields defined here?
This
On 07/02/2014 01:18 PM, Jan Hubicka wrote:
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory location,
one can not change its type by placement_new into something else.
Hmm. If the memory location
On 07/02/2014 06:30 PM, Jan Hubicka wrote:
But this is one of things that was not quite clear to me. I know that
polymorphic type A
was created at a give memory location. THis means that accesses to that
location in one
alias class has been made.
Now I destroy A and turn it into B, construct
On 06/26/2014 03:22 PM, Marek Polacek wrote:
The following is a revamped patch for -Wsizeof-array-argument.
Its purpose is to detect suspicious usage of the sizeof operator on an array
function parameter.
Then the name should be -Wsizeof-array-parm, not -argument.
@@ -9550,6 +9551,8 @@
OK.
Jason
On 07/01/2014 07:40 PM, Jan Hubicka wrote:
I want to avoid the overhead of SCC hashing and canonical type computation for
these
and here I want the concept of anonymous namespace types to be closed upwards.
That is if I have type that is not considered anonymous it should not be built
from
On 07/04/2014 05:13 AM, Dodji Seketeli wrote:
// preprocessed output
# 3 test.cpp 3 4
sys_token
# 3 test.cpp
3
# 3 test.cpp 3 4
sys_token
Yeah. For Built-in tokens that are expanded like that we only do track
their the location of their expansion, not their spelling location. So
this
I don't think we want to warn about e.g. 1-1, only about literal 0.
Original Message
From: Jakub Jelinek ja...@redhat.com
Sent: Tue, Jul 8, 2014 05:50 AM
To: Joseph S. Myers jos...@codesourcery.com; Jason Merrill
ja...@redhat.com; Carlos O'Donell car...@redhat.com; Siddhesh
I'd rather handle this in check_cv_quals_for_unify.
Jason
/08/2014 01:31 PM, Jakub Jelinek wrote:
On Tue, Jul 08, 2014 at 03:24:52PM -0400, Jason Merrill wrote:
I don't think we want to warn about e.g. 1-1, only about literal 0.
Well, at least literal 0 and '\0'.
Right, I consider '\0' to be a literal 0.
But in the C++ FE there isn't something like
On 07/07/2014 11:15 AM, Paolo Carlini wrote:
+ error (only declarations can be marked %explicit%);
That's pretty unclear, since a definition is a declaration.
Let's split this into three error messages: If the problem is that we're
outside the class, we should say that. If the problem
On 07/07/2014 07:20 AM, Ed Smith-Rowland wrote:
OK?
And for 4.9?
Yes.
Jason
OK.
Jason
On 07/09/2014 06:07 AM, Paolo Carlini wrote:
The third case, I don't think it can really happen,
because there are earlier checks which simply return error_mark_node if
a declaration is within the wrong class...
Not if it's a friend declaration:
struct A {
explicit A(int);
};
struct B {
OK.
Jason
On 07/09/2014 10:40 AM, Manuel López-Ibáñez wrote:
All of these warnings (-Wsizeof-pointer-memaccess, -Wsizeof-array-argument
and -Wmemset-transposed-args) are implemented in a hackish way, because we
fold everything too early. Perhaps for such analysis we want a FOLDED_EXPR
which would have
OK, thanks.
Jason
it is odr-used, and a virtual function is
odr-used in every translation unit where it is declared.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit eaa08ca87b18a48b1cfc895c6308b79ea1aa04a6
Author: Jason Merrill ja...@redhat.com
Date: Tue Jul 1 15:35:15 2014 -0700
PR libstdc++/61728
OK.
Jason
OK.
Jason
note to help people understand why their code is
breaking and how they can work around it if needed.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 82187fb06863161765a270f8ba00bdbf975b3af2
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 7 03:15:02 2014 -0700
PR c++/61659
On 07/10/2014 08:13 AM, Dodji Seketeli wrote:
Jason Merrill ja...@redhat.com writes:
On 07/04/2014 05:13 AM, Dodji Seketeli wrote:
// preprocessed output
# 3 test.cpp 3 4
sys_token
# 3 test.cpp
3
# 3 test.cpp 3 4
sys_token
Yeah. For Built-in tokens that are expanded like that we only do
Hmm, why aren't we already getting the error from
if (convs-check_narrowing)
check_narrowing (totype, expr);
in convert_like_real? Is it that we need to copy LOOKUP_NO_NARROWING
into convflags in build_user_type_conversion_1?
Jason
If we handle PTRMEM_CST specially, we also need to handle any
CONSTRUCTORs that wrap them.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.9.
commit a2f90f6d52fa4c3d5391b23914c4177c3272817c
Author: Jason Merrill ja...@redhat.com
Date: Thu Jul 10 17:05:28 2014 -0400
PR c++/61661
On 07/10/2014 06:38 PM, Paolo Carlini wrote:
if (SCALAR_TYPE_P (type))
+ if (!CLASS_TYPE_P (TREE_TYPE (init)))
Why this change? check_narrowing only deals with scalar types.
Jason
Oops, this patch didn't thread with the earlier one...
On 07/11/2014 06:15 AM, Paolo Carlini wrote:
if (SCALAR_TYPE_P (type))
Is the condition still necessary?
- check_narrowing (type, init);
+ flags |= LOOKUP_NO_NARROWING;
Jason
On 07/11/2014 02:02 PM, Paolo Carlini wrote:
Is the condition still necessary?
I'm removing it and retesting. In any case (the eventual)
check_narrowing will return immediately if !ARITHMETIC_TYPE_P (type) is
true... Would the amended patch be Ok?
Yes, thanks.
Jason
We shouldn't indirect through conv2/conv3 after the obstack_free.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6e4f0317fabeefaac3107707112f433ddb673062
Author: Jason Merrill ja...@redhat.com
Date: Fri Jul 11 17:20:32 2014 -0400
PR c++/61288
* call.c
OK.
Jason
for a defaulted constexpr function around long enough to
pass it in.
The explain_implicit_non_constexpr change may be unnecessary, but is
correct in any case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 57669c237723c6d109badb660440675fd2aab883
Author: Jason Merrill ja...@redhat.com
Date
Calling finish_compound_literal in this case ends up trying to reshape
an initializer that has already been digested, and removing the call
doesn't seem to break anything.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6f94e657ce04fd32cac5e616e9ca675c40e3fab5
Author: Jason Merrill ja
When we call break_out_target_exprs in the middle of
explain_invalid_constexpr_fn, we don't want to replace 'this' with
whatever current_class_ptr is at that point.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b520b30e2e4bf0174eea966cdccac36eefc5a544
Author: Jason Merrill ja
On 03/25/2014 01:43 PM, Jason Merrill wrote:
We got confused tsubsting the VLA type because tsubst doesn't expect to
see a SAVE_EXPR. Simple to fix by enforcing the rule against auto arrays.
Oops, we already had a diagnostic for this, we just needed to make it an
unconditional error
You can't form an array of references in C++, so we shouldn't consider a
conversion to an initializer_list of references either.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.9.
commit 97303858558a5024b357e8ec6f4ffcf4f1c043fe
Author: Jason Merrill ja...@redhat.com
Date: Sun Jul 13 11:53
On 07/14/2014 04:36 AM, Jan Hubicka wrote:
FAIL: g++.dg/cpp0x/static_assert9.C -std=c++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
error: non-constant condition for static assertion
On 06/25/2014 02:51 AM, Jan Hubicka wrote:
@@ -4388,7 +4388,8 @@ build_clone (tree fn, tree name)
clone = copy_decl (fn);
/* Reset the function name. */
DECL_NAME (clone) = name;
- SET_DECL_ASSEMBLER_NAME (clone, NULL_TREE);
+ if (TREE_CODE (clone) != TEMPLATE_DECL)
+
On 07/14/2014 12:20 PM, Paolo Carlini wrote:
I have been looking a bit into this bug, using a reduced testcase which
simplifies the debugging quite a bit for me (a non-variadic variant is
ok). I cannot say to already understand all the details of the issue,
but something which strikes me as
function, so the assert is wrong; let's just remove it.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3115f729a22d8244965b68807561eef04019757a
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 14 01:39:33 2014 -0400
PR c++/61445
PR c++/56947
* pt.c (instantiate_decl): Don't
to only look at TREE_PUBLIC decls, since
comdat-local symbols can be removed if they aren't needed. I also
adjusted the diagnostic so it would print the two symbols in question
rather than the same one twice. :)
OK for trunk?
commit e29dc7a675fdbc1adce40908fda4d5408f0103a0
Author: Jason
On 07/14/2014 05:12 PM, Paolo Carlini wrote:
Thanks. This helps me a lot. In particular I see now, in tsubst_arg_types:
/* Do array-to-pointer, function-to-pointer conversion, and ignore
top-level qualifiers as required. */
type = cv_unqualified (type_decays_to (type));
On 07/15/2014 10:19 AM, Jan Hubicka wrote:
@@ -1722,7 +1722,7 @@ dump_ada_template (pretty_printer *buffe
/* DECL_VINDEX is DECL_TEMPLATE_INSTANTIATIONS in this context. */
tree inst = DECL_VINDEX (t);
/* DECL_RESULT_FLD is DECL_TEMPLATE_RESULT in this context. */
- tree result =
On 07/15/2014 11:29 AM, Jan Hubicka wrote:
Yep, you are right. I was looking into this, too. I think dump_ada_template
should be moved into C++ FE somehow because it deals with C++ trees.
What would be most appropriate way to do so?
I suppose we could pass a pointer to it into dump_ada_specs
OK, thanks.
Jason
OK.
Jason
deb1a9e023d457c88edf52231d32af5ef03179f4
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 14 16:58:57 2014 -0400
PR c++/61623
* symtab.c (symtab_remove_from_same_comdat_group): Also
set_comdat_group to NULL_TREE.
(verify_symtab): Fix diagnostic.
diff --git a/gcc/symtab.c
853b9ecb5c8025c733c756bd9fb20bb64120c649
Author: Jason Merrill ja...@redhat.com
Date: Tue Jul 15 12:09:08 2014 -0400
PR c++/60848
PR c++/61723
* call.c (is_std_init_list): Don't check CLASSTYPE_TEMPLATE_INFO.
* class.c (finish_struct): Reject invalid definition of
std::initializer_list.
diff --git
You need to call resolve_nondeduced_context at some point. This doesn't
seem to be the right place, since you also want to handle code like if
(foovoid). Maybe in resolve_address_of_overloaded_function just
before the error?
Jason
On 07/16/2014 12:39 AM, Paolo Carlini wrote:
In practice, both for the original testcase and for a conditional (and
in more cases, eg conditional expressions), what happens is that
perform_implicit_conversion_flags is called, which, when
implicit_conversion fails, calls instantiate_type (and
OK.
Jason
OK.
Jason
On 07/08/2014 02:50 PM, Jan Hubicka wrote:
I am looking into tracking dynamic types now. Obviously I need to set very
exact rules about when these may change.
Let me first say that this area is somewhat in flux in the standard; if
we have a model of what we want the rules to be for GCC,
On 07/18/2014 11:03 AM, Jan Hubicka wrote:
I really only care about types containing virtual table pointers to not change,
so non-PODs are out of game. Current propagation is built around assumption
that
once polymorphic type is constructed on a given location it won't change to
completely
On 07/22/2014 01:53 PM, Ed Smith-Rowland wrote:
+ if (cxx_dialect cxx1z)
+ {
+ /* Look for the `class' keyword. */
+ cp_parser_require_keyword (parser, RID_CLASS, RT_CLASS);
+ }
+ else
+ {
+ /* Look for the `class' or 'typename'
On 07/22/2014 02:34 PM, Richard Biener wrote:
As discussed during the Cauldron keeping some builtin doesn't help because
you are not forced to access the newly created object via the pointer returned
by the placement new. That is,
template T
struct Storage {
char x[sizeof(T)];
On 07/23/2014 10:31 PM, Ed Smith-Rowland wrote:
+pedwarn (token-location, OPT_Wpedantic,
+ISO C++ forbids typename key in template template parameter);
This should mention -std=c++1z.
+ if (tag_type == none_type)
+cp_parser_error (parser, expected type-parameter-key);
On 07/23/2014 07:29 AM, Richard Biener wrote:
On Wed, Jul 23, 2014 at 12:44 PM, Jason Merrill ja...@redhat.com wrote:
On 07/22/2014 02:34 PM, Richard Biener wrote:
As discussed during the Cauldron keeping some builtin doesn't help because
you are not forced to access the newly created object
First of all, thanks a lot for taking this on! A few nitpicks:
On 07/21/2014 11:06 PM, Braden Obrzut wrote:
grokvardecl (tree type,
tree name,
+tree orig_declarator,
const cp_decl_specifier_seq *declspecs,
int initialized,
On 07/17/2014 08:23 AM, Jan Hubicka wrote:
Given my experience about numbers of functions that become reachable when you
stream all virtuals into LTO,
I wonder if we don't want to use possible_polymorphic_call_targets within the
front-end to avoid instantiating
those that can't be called?
libfoo.so
/home/jason/gtt/foo/one.C:2: undefined reference to `B::~B()'
To deal with this I guess we can either keep -fuse-all-virtuals or not
devirtualize in LTO to something that is hidden and not defined. Thoughts?
commit ac04d4b08190593299c8c94431d5e43384514096
Author: Jason Merrill ja
OK, thanks!
Jason
On 07/04/2014 04:47 PM, Jakub Jelinek wrote:
(ubsan_expand_null_ifn): ...take type from ckind argument's type rather
than
first argument.
Why? It looks like they have the same type with your patch, and then
you need to convert ckind back to unsigned char.
Jason
1 - 100 of 11077 matches
Mail list logo
