Hi,
On 06/16/2014 10:42 AM, Konstantin Serebryany wrote:
On Wed, Jun 11, 2014 at 2:28 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
In file included from
../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
../../../../trunk
) != METHOD_TYPE)
{
which uses type and is more precise. Tested x86_64-linux.
Thanks!
Paolo.
///
/cp
2014-06-24 Paolo Carlini paolo.carl...@oracle.com
PR c++/33972
* decl.c (grokdeclarator): Do not early check for operator-function-id
as non-function.
/testsuite
Hi,
this remained unresolved for a long time, but, if I understand correctly
Jason' Comment 1, should be rather easy, just do not complain for
uninitialized const members in aggregates, recursively too (per struct B
in the testcases). Does the below makes sense, then?!? It passes
testing,
... in order to handle correctly in C++98 mode (*) the case of
references in a member, I think we have to add an explicit check of
CLASSTYPE_REF_FIELDS_NEED_INIT, per the below.
Thanks,
Paolo.
(*) For C++11 my previous patch is fine, the TREE_CODE (TREE_TYPE
(field)) == REFERENCE_TYPE check
Hi,
On 06/24/2014 01:40 AM, Adam Butcher wrote:
+++ b/gcc/testsuite/g++.dg/cpp1y/pr61537.C
@@ -0,0 +1,24 @@
+// PR c++/61537
+// { dg-do compile { target c++1y } }
I don't think this is a C++1y specific issue...
+// { dg-options }
Also, likely minor detail, could you please explain why you
Hi,
should we do something like this? Tested x86_64-linux.
Thanks,
Paolo.
2014-06-26 Paolo Carlini paolo.carl...@oracle.com
* parser.c (cp_parser_compound_literal_p): New.
(cp_parser_postfix_expression, cp_parser_sizeof_operand): Use it.
Index: parser.c
Hi,
I'm afraid something went badly wrong with this commit, I'm seeing tens
of fails. See eg:
https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg02439.html
Paolo.
Hi,
On 06/27/2014 12:38 AM, Jonathan Wakely wrote:
On 26/06/14 23:21 +0200, Paolo Carlini wrote:
Hi,
I'm afraid something went badly wrong with this commit, I'm seeing
tens of fails. See eg:
https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg02439.html
It seems that uneq_allocator
Hi,
On 06/27/2014 05:56 AM, Tim Shen wrote:
The limit can be customized by defining a macro
_GLIBCXX_REGEX_STATE_LIMIT. The default value is 10.
The testcase can be handled if we optimize consecutive quantifiers
(collapse them to one). But cases like (a{100}b){100} can't be
handled still.
Hi,
On 06/27/2014 09:41 AM, Braden Obrzut wrote:
Are you sure about this? Andrew has been putting everything in
ChangeLog.concepts in the root.
In terms of general GCC rules, Marek is certainly right. Whether Andrew
has (very) special reasons for doing that I don't know, meant to ask for
.
/
/cp
2014-06-27 Paolo Carlini paolo.carl...@oracle.com
PR c++/61614
* semantics.c (finish_compound_literal): Revert r204228.
/testsuite
2014-06-27 Paolo Carlini paolo.carl...@oracle.com
PR c++/61614
* g++.dg/ext/complit14.C: New.
Index: cp/semantics.c
Hi,
On 06/27/2014 06:53 PM, Tim Shen wrote:
PS: sorry for being distracted by other issues: what happened to the other
regex issue? I think we are simply going to apply, when ready, your more
complete fix, right?
The problem given in the other PR (PR 61582) is also solved by this
patch (but I
Hi,
On 06/27/2014 07:33 PM, Jonathan Wakely wrote:
I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.
Ok, thanks. I'm reverting the last two libstdc++-v3 commits.
Hi,
On 06/08/2014 06:02 PM, Paolo Carlini wrote:
Hi,
as discussed, tested x86_64-linux multilib, committed.
for now I reverted this. Things get too complicated when we have to
conditionally export some symbols depending on the target (see
libstdc++/61536).
Thanks,
Paolo.
handle_noreturn_attribute and
handle_const_attribute call build_pointer_type and discard the
TYPE_QUALS on the original POINTER_TYPE. That seems obviously incorrect.
The below fixes the ICE and passes testing.
Thanks!
Paolo.
/
/c-family
2014-06-28 Paolo Carlini paolo.carl...@oracle.com
cp_parser_cast_expression and then fall back to
cp_parser_unary_expression (if cp_parser_parse_definitely returns false
after the former). Tested x86_64-linux.
Thanks,
Paolo.
/cp
2014-06-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/54891
* parser.c
... I'm going to commit as obvious the below, to avoid the spurious fail
that we are all seeing.
Thanks,
Paolo.
2014-07-01 Paolo Carlini paolo.carl...@oracle.com
* g++.dg/cpp1y/pr59867.C: Fix target selector.
Index: g++.dg/cpp1y/pr59867.C
Hi,
noticed these error messages. Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2014-07-01 Paolo Carlini paolo.carl...@oracle.com
* pt.c (convert_template_argument): Use inform instead of error in
three places.
/testsuite
2014-07-01 Paolo Carlini paolo.carl
Hi,
On 07/01/2014 08:49 PM, Paul Pluzhnikov wrote:
Index: gcc/testsuite/g++.dg/cpp0x/nsdmi-template11.C
===
--- gcc/testsuite/g++.dg/cpp0x/nsdmi-template11.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/nsdmi-template11.C
.
Thanks,
Paolo.
/
/cp
2014-07-01 Paolo Carlini paolo.carl...@oracle.com
PR c++/51488
PR c++/53618
PR c++/58059
* pt.c (instantiate_class_template_1): Call push_tinst_level /
pop_tinst_level around most_specialized_class.
/testsuite
2014
.. consider this patch withdrawn. I believe that something is going
wrong indeed as part of most_specialized_instantiation but the details
need to be figured out. I'm now focusing on fn_type_unification via
get_bindings.
Paolo.
Hi again,
On 07/02/2014 05:06 PM, Paolo Carlini wrote:
.. consider this patch withdrawn. I believe that something is going
wrong indeed as part of most_specialized_instantiation but the details
need to be figured out. I'm now focusing on fn_type_unification via
get_bindings.
In fact my typo
the tsubst there, which works fine for the testcases we have in this area.
Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
2014-07-03 Paolo Carlini paolo.carl...@oracle.com
PR c++/51488
PR c++/53618
PR c++/58059
* pt.c (get_class_bindings): Call
Hi,
On 07/06/2014 10:56 AM, Tim Shen wrote:
This bug shouldn't be introduced, if I wrote clearer code last summer.
Sorry :(. The _Executor is a little bit messy. The _M_match_queue is
not cleared because it's treated `globally` between iterations (in
_M_main_dispatch(..., __bfs)).
Add a new
Hi,
On 07/06/2014 08:20 PM, Tim Shen wrote:
I'd like to merge testcases to several huge files (char, wchar_t,
dg-do compile, locales, etc.) to (greatly) reduce duplicated regex
compilation.
We do not really care the fine-grained test report, do we? We hope
them all PASS.
Yes. As long as it's
be parsed as unary
expression.
Today I simplified a bit his patch, moving the CPP_ELLIPSIS handling
inside cp_parser_tokens_start_cast_expression. Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2014-07-07 Andrew Sutton andrew.n.sut...@gmail.com
Paolo Carlini
Hi,
tested x86_64-linux, committed as obvious.
Thanks,
Paolo.
/cp
2014-07-07 Paolo Carlini paolo.carl...@oracle.com
* class.c (check_for_override): Wrap the 'final' and 'override'
keywords in % and %.
/testsuite
2014-07-07 Paolo Carlini paolo.carl
overkill considering that we do
*accept* explicit operators in C++98 mode, we only emit a pedwarn).
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2014-07-07 Jonathan Wakely jwak...@redhat.com
Paolo Carlini paolo.carl...@oracle.com
PR c++/60686
Hi,
the defect
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1584) is
Ready and both clang and SolarisStudio already implement it. The below
very simple tweak seems enough, testing is fine on x86_64-linux.
Thanks!
Paolo.
/
/cp
2014-07-08 Paolo Carlini
Hi,
On 07/09/2014 03:53 AM, Tim Shen wrote:
+// This file is for general testcases in regex.
+// We use a single file for multiple testcases because it takes too long to
+// compile regex for each testcase in a single file.
+// Normal testcases in other files should be moved into this file in
Hi,
On 07/09/2014 10:08 AM, Jonathan Wakely wrote:
All the 28_regex tests run as part of the same target:
normal7) \
dirs=`cd $$srcdir; echo 26_*/* 28_*/[c-z]*`;; \
I've tried moving the 26_numeric tests to a different target but it
doesn't make much difference, the regex
Hi,
On 07/09/2014 12:26 AM, Jason Merrill wrote:
I'd rather handle this in check_cv_quals_for_unify.
Yes, the below passes testing.
Thanks,
Paolo.
/
/cp
2014-07-09 Paolo Carlini paolo.carl...@oracle.com
DR 1584
PR c++/57466
* pt.c
Hi,
On 07/09/2014 12:39 AM, Jason Merrill wrote:
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
Hi,
On 07/09/2014 10:34 PM, Jason Merrill wrote:
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
On 07/10/2014 06:30 AM, Tim Shen wrote:
Here's the sane patch :)
Ok, thanks!
Paolo.
Hi,
On 07/10/2014 10:07 AM, Ed Smith-Rowland wrote:
The title says it all.
I've been bootstrapping and testing with this on x86_64-linux for a
month.
OK?
Look OK to me too, but I would move both operator() out of line, and
definitely operator()(_UniformRandomNumberGenerator, const
.. I have another comment: are we sure the usual strategy:
templatetypename _UniformRandomNumberGenerator
result_type
operator()(_UniformRandomNumberGenerator __urng)
{ return this-operator()(__urng, this-_M_param); }
doesn't make sense here too?
Paolo.
Hi,
after more than 2 years, I'm finally back to this issue:
https://gcc.gnu.org/ml/gcc-patches/2012-05/msg01442.html
https://gcc.gnu.org/ml/gcc-patches/2012-05/msg01502.html
and the below draft, which passes testing, tries to implement as closely
as possible what Jason suggested in
Hi,
On 07/10/2014 10:55 PM, Jason Merrill wrote:
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?
Ah, ah,
... the below is another, very safe, option for setting
LOOKUP_NO_NARROWING in flags.
Paolo.
Index: call.c
===
--- call.c (revision 212431)
+++ call.c (working copy)
@@ -3586,7 +3586,8 @@ build_user_type_conversion_1
... and of course the problem with all such ideas is that we easily end
up warning twice in all the simple cases which check_narrowing can
already handle. Something like the attached has more chances of passing
the testsuite while not regressing in terms of duplicate warnings (which
are hard
Hi,
only today it occurred to me that we can as well delay all the
diagnostic at issue to the check_narrowing at the end of
convert_like_real and avoid at once possible issues with duplicate
warnings. Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2014-07-11 Paolo Carlini
Hi,
On 07/11/2014 05:38 PM, Ed Smith-Rowland wrote:
OK?
Ok, thanks, but please adjust the dates you have on the testcases to the
date of the actual commit (I suppose today or tomorrow)
Thanks again!
Paolo.
, confusing...
On 07/11/2014 06:15 AM, Paolo Carlini wrote:
if (SCALAR_TYPE_P (type))
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
Hi,
On 07/13/2014 04:00 AM, Ulrich Drepper wrote:
+ templatestd::size_t _Dimen, typename _RealType, typename _CharT,
+ typename _Traits
+std::basic_ostream_CharT, _Traits
+operator(std::basic_ostream_CharT, _Traits __os,
+ const
Hi,
On 07/13/2014 12:04 PM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 5:24 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
are these dummy implementations intended?
Yes. There is no state. The only parameter is the dimensionality
which is a template parameter.
Ah, interesting, didn't
Hi,
On 07/13/2014 04:11 PM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland 3dw...@verizon.net wrote:
So I would just serialize _M_n here.
It has fixed parameters. This would mean unnecessary work. When you
try to use the parameter of the sphere distribution the
Hi,
On 07/13/2014 06:03 PM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 11:43 AM, Paolo Carlini
paolo.carl...@oracle.com wrote:
and I think: the normal distributions in x and y do have a non-trivial state
(_M_saved, _M_saved_available) which, at any given moment, is different in x
and y
Hi,
On 07/13/2014 06:18 PM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 12:07 PM, Paolo Carlini
paolo.carl...@oracle.com wrote:
Sorry, I still don't get it. When operator() of x and y, two
uniform_on_sphere_distribution, call _M_n(__urng) and those _M_n have a
different state, the numbers
Hi,
On 07/13/2014 06:44 PM, Ulrich Drepper wrote:
But your 4th and 7th call example by itself is not a reason. Again,
the input exclusively determined by the random numbers. Here, of
course, the 4th and 7th use will produce different results. But this
is not what the state of the distribution
Hi,
On 07/14/2014 09:58 AM, Andreas Schwab wrote:
FAIL: ext/random/arcsine_distribution/cons/default.cc (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1587:22:
error: '_M_n' was not declared in this scope
Hi,
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 interesting, is that the DEDUCE_CALL
Hi,
On 07/14/2014 09:47 PM, Jason Merrill wrote:
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
Hi,
while looking into an old issue I noticed that in one place we don't
check the return value of permerror. I'm going to commit the below as
obvious.
Thanks,
Paolo.
//
2014-07-15 Paolo Carlini paolo.carl...@oracle.com
* call.c (convert_like_real): Call
Hi,
On 07/15/2014 11:46 PM, Jason Merrill wrote:
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?
Thanks, that
Hi,
On 07/16/2014 01:05 PM, Ed Smith-Rowland wrote:
One thing we all forgot: the operator== is also non-trivial because it
needs to compare _M_n.
Right. And reset too. I'm going to test and apply the below.
Thanks,
Paolo.
///
2014-07-16 Paolo Carlini paolo.carl
Hi,
Richard Smith noticed another case, like '[' in C++11, where we want to
keep the parsing uncommitted after the parenthesized type-id. Tested
x86_64-linux.
Thanks,
Paolo.
/
/cp
2014-07-16 Paolo Carlini paolo.carl...@oracle.com
PR c++/61804
Hi,
On 07/17/2014 02:40 AM, Jason Merrill wrote:
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
Hi,
On 07/23/2014 12:45 PM, Jonathan Wakely wrote:
On 15/07/14 13:03 +0100, Jonathan Wakely wrote:
On 14/07/14 20:31 +0100, Jonathan Wakely wrote:
This adds printers for the types in the std::experimental namespace.
This should fix the test failures that Paolo and HJ are seeing, older
, definitely not just a diagnostic one.
Thanks,
Paolo.
///
/cp
2014-07-29 Paolo Carlini paolo.carl...@oracle.com
PR c++/57397
* pt.c (unify_arity): Add boolean parameter.
(unify_too_few_arguments): Likewise.
(type_unification_real): Diagnose
Hi,
On 07/29/2014 06:01 PM, Jason Merrill wrote:
On 07/29/2014 10:28 AM, Paolo Carlini wrote:
+unify_arity (bool explain_p, int have, int wanted, bool lb_p = false)
I don't understand lb_p.
lower_bound ;) The first name which came to my mind...
@@ -16598,6 +16608,8
Hi,
On 07/29/2014 06:56 PM, Jason Merrill wrote:
On 07/29/2014 12:23 PM, Paolo Carlini wrote:
On 07/29/2014 06:01 PM, Jason Merrill wrote:
Why would we get here in the too few args case? Won't we only hit
this code if we had enough args for the non-pack parms?
Yeah, that is exactly
.
Thanks,
Paolo.
//
/cp
2014-11-11 Paolo Carlini paolo.carl...@oracle.com
PR c++/63265
* pt.c (tsubst_copy_and_build, case COND_EXPR): Maybe fold to
const the condition.
/testsuite
2014-11-11 Paolo Carlini paolo.carl...@oracle.com
PR c++/63265
Hi,
On 11/11/2014 02:19 PM, Jason Merrill wrote:
On 11/11/2014 08:04 AM, Paolo Carlini wrote:
-tree cond = RECUR (TREE_OPERAND (t, 0));
+tree cond
+ = maybe_constant_value (fold_non_dependent_expr_sfinae
+ (RECUR (TREE_OPERAND (t, 0)), tf_none));
I like
Hi,
On 11/11/2014 04:03 PM, Jason Merrill wrote:
OK.
Committed. What about 4.9? Technically the issue is a regression, but in
my opinion the fix isn't completely trivial for a release branch..
Paolo.
Hi,
if I understand correctly the existing uses of tf_ignore_bad_quals, in
order to correctly implement the resolution of CWG 1510, thus accept the
testcases, we have to handle decltypes like references and template type
arguments, thus make sure cp_build_qualified_type_real is called with |
Hi,
shall we do something like the below? Safety checked x86_64-linux.
Thanks,
Paolo.
///
2014-11-13 Paolo Carlini paolo.carl...@oracle.com
* constexpr.c (maybe_constant_folded_value): Add.
* cp-tree.h (maybe_constant_folded_value): Declare
Hi,
On 11/13/2014 05:42 PM, Jason Merrill wrote:
On 11/13/2014 11:10 AM, Jason Merrill wrote:
On 11/13/2014 05:47 AM, Paolo Carlini wrote:
shall we do something like the below?
Something similar, yes. Though it would also be nice to avoid the
redundant checking in the two functions: we
Hi,
On 11/13/2014 07:31 PM, Jason Merrill wrote:
On 11/13/2014 12:48 PM, Paolo Carlini wrote:
While we are at it, can you double check that in end_maybe_infinite_loop
we really want the non-sfinae version (which in principle can emit hard
errors): the inconsistency
Hi,
On 11/14/2014 03:35 AM, Jason Merrill wrote:
On 11/13/2014 04:31 PM, Paolo Carlini wrote:
I think this should be replaced with fold_ if
(processing_template_decl) in build_enumerator.
Ok. The value can be NULL_TREE, thus in a straightforward change (per
the below) I have to check
On 11/18/2014 02:35 PM, Jason Merrill wrote:
We need to allow copy-list-initialization of constexpr variables with
mutable members, too. The thing we need to avoid is not so much an
full-expression with mutable-containing type as assuming that a
mutable member of a variable hasn't changed
Hi,
On 11/18/2014 08:12 PM, Tim Shen wrote:
Bootstrapped and tested.
Jonathan lately is following your work much better than me, but naively
seems weird that _M_begin is non-const and _M_end is const, a different
type anyway.
Paolo.
, and
__PRETTY_FUNCTION__ is checking whether DECL_ARTIFICIAL (decl) is true
on the decl. Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2014-11-19 Paolo Carlini paolo.carl...@oracle.com
PR c++/55425
* constexpr.c (constexpr_fn_retval): Accept __func__, __FUNCTION__
Hi Tim,
On 11/19/2014 08:27 AM, Tim Shen wrote:
On Tue, Nov 18, 2014 at 11:19 AM, Paolo Carlini
paolo.carl...@oracle.com wrote:
Jonathan lately is following your work much better than me, but naively
seems weird that _M_begin is non-const and _M_end is const, a different type
anyway.
Hmm
Hi,
On 11/19/2014 07:43 PM, Daniel Krügler wrote:
2014-11-19 19:42 GMT+01:00 Tim Shen tims...@google.com:
On Wed, Nov 19, 2014 at 8:16 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Good. To be clear, not having carefully analyzed whatsoever, my point was
more about changing _M_end too
On 11/22/2014 03:18 AM, Jason Merrill wrote:
The earlier fix for 38958 was too broad; we don't want to suppress the
unused warning for all references to type with non-trivial destructor,
just references bound to a temporary.
Thanks!
Paolo.
Hi,
submitter noticed that when Honza in r201994 changed
DECL_CONSTRUCTOR_P/DECL_DESTRUCTOR_P to use middle-end flags forgot to
remove the unused front-end flags. Tested x86_64-linux.
Thanks!
Paolo.
PS: FWIW, the issue still exists in 4_9-branch too.
///
2014-11-23 Paolo
...@redhat.com
Paolo Carlini paolo.carl...@oracle.com
PR c++/63203
* decl.c (initialize_local_var): Add -Winit-self warning for
references initialized with themselves.
/testsuite
2014-11-24 Jonathan Wakely jwak...@redhat.com
Paolo Carlini paolo.carl
Hi,
On 11/12/2014 03:02 AM, H.J. Lu wrote:
I am checking in this.
Looks like devirt-42.C is failing again and reverting your tweak would
fix it?!?
Thanks,
Paolo.
Hi again,
On 11/24/2014 07:33 PM, Paolo Carlini wrote:
Hi,
On 11/12/2014 03:02 AM, H.J. Lu wrote:
I am checking in this.
Looks like devirt-42.C is failing again and reverting your tweak would
fix it?!?
Sorry, in fact now the line failing is First type is base of second 3,
a different one
Hi,
in this rejects-valid, as part of build_user_type_conversion_1,
standard_conversion is called by implicit_conversion with a *null* expr,
thus the condition in standard_conversion
/* [conv.ptr]
A null pointer constant can be converted to a pointer type; ... A
null pointer
Hi,
we are crashing on this kind of invalid code because we don't early
check the case with check_for_bare_parameter_packs. Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2014-11-25 Paolo Carlini paolo.carl...@oracle.com
PR c++/63786
* parser.c
Hi,
On 11/26/2014 05:24 PM, Jason Merrill wrote:
On 11/24/2014 01:55 PM, Paolo Carlini wrote:
in this rejects-valid, as part of build_user_type_conversion_1,
standard_conversion is called by implicit_conversion with a *null* expr,
thus the condition in standard_conversion
/* [conv.ptr
ones given the patch proper, no surprises). How does
it look?
Thanks!
Paolo.
//
2014-09-30 Paolo Carlini paolo.carl...@oracle.com
* g++.dg/cpp0x/decltype26.C: Adjust.
* g++.dg/cpp0x/decltype28.C: Likewise.
* g++.dg/cpp0x/decltype29.C: Likewise
... forgot to attach the complete patch ;)
Paolo.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 215710)
+++ cp/cp-tree.h(working copy)
@@ -5418,7 +5418,6 @@ extern const char
Hi,
On 09/30/2014 04:51 PM, Manuel López-Ibáñez wrote:
I don't want to cause you more work Paolo, but perhaps this should be
documented in https://gcc.gnu.org/gcc-5/changes.html. ?
Something like:
* Excessive template instantiation depth is now a fatal error. This
prevents excessive
Hi,
On 09/30/2014 07:13 PM, Jason Merrill wrote:
Ville asked for help with the necessary compiler intrinsics for the
is_trivially_* C++11 library traits.
The first patch cleans up a few oddities I noticed with the existing
intrinsics. __is_convertible_to was never implemented and isn't
Hi,
On 10/01/2014 12:48 AM, Ville Voutilainen wrote:
Ville asked for help with the necessary compiler intrinsics for the is_trivially_*
C++11 library traits. The first patch cleans up a few oddities I noticed with
the
Great. I think this can be as well marked as PR c++/26099.
There's also
Hi again,
On 10/01/2014 12:48 AM, Ville Voutilainen wrote:
The intrinsics still fail to support certain variadic cases, such as
template class T, class... Args void bar() {
static_assert(__is_trivially_constructible(T, Args...), ); }
... depending on your arrangements with Jason you may or
Hi,
in this issue Daniel argued that the value of a noexcept expression
should not depend on constructor elision. Then, in the audit trail Marc
tentatively suggested something like the parser.c hunk below, which just
disables our -felide-constructors optimization when parsing the noexcept
Hi,
On 10/02/2014 05:22 AM, Jason Merrill wrote:
On 10/01/2014 12:31 PM, Paolo Carlini wrote:
in this issue Daniel argued that the value of a noexcept expression
should not depend on constructor elision.
I'm open to that, but I don't think it's at all clear in the standard.
Ok. Personally, I
Hi,
On 10/02/2014 04:26 PM, Jason Merrill wrote:
On 10/02/2014 08:11 AM, Paolo Carlini wrote:
+/* Nonzero if we are parsing the operand of a noexcept operator. */
+
+extern int cp_noexcept_operand;
Rather than add a global variable, let's look it up in scope_chain
directly, like
Hi,
On 10/02/2014 07:37 PM, Jason Merrill wrote:
On 10/02/2014 12:44 PM, Paolo Carlini wrote:
+ s-noexcept_operand = scope_chain ? cp_noexcept_operand : 0;
s-x_stmt_tree.stmts_are_full_exprs_p = true;
scope_chain = s;
@@ -6182,6 +6183,7 @@ pop_from_top_level_1 (void
Hi,
On 10/02/2014 08:03 PM, Jason Merrill wrote:
On 08/19/2014 08:18 AM, Paolo Carlini wrote:
- /*non_constant_p=*/dummy);
+ dummy);
Why remove the comment?
Oh well, the rationale was that normally we use that sort of comment
only to explain integer
Hi,
On 10/02/2014 10:08 AM, Ed Smith-Rowland wrote:
On 10/02/2014 02:51 AM, Ed Smith-Rowland wrote:
On 10/01/2014 11:28 AM, Jonathan Wakely wrote:
On 02/09/14 10:24 +0100, Jonathan Wakely wrote:
On 01/09/14 21:46 -0400, Ed Smith-Rowland wrote:
Index: include/bits/stl_function.h
Hi,
On 10/03/2014 04:08 PM, Andi Kleen wrote:
+ if (check_no_cilk (destination,
+Cilk array notation cannot be used as a computed goto expression,
+%_Cilk_spawn% statement cannot be used as a computed goto
expression))
+ destination = error_mark_node;
Are you sure
Hi,
On 10/03/2014 07:13 PM, Andi Kleen wrote:
On Fri, Oct 03, 2014 at 07:10:05PM +0200, Paolo Carlini wrote:
Hi,
On 10/03/2014 04:08 PM, Andi Kleen wrote:
+ if (check_no_cilk (destination,
+Cilk array notation cannot be used as a computed goto expression,
+%_Cilk_spawn
Hi,
On 10/03/2014 07:50 PM, Andi Kleen wrote:
I have no idea, but there are lots of error_at() all over while
don't use _. So I just follow precedence.
The problem is, you are *not* calling error_at directly, you are
According to Joseph it's ok because I named the arguments _msgid.
Ok then,
Hi,
On 10/05/2014 08:50 PM, François Dumont wrote:
+#include testsuite_hooks.h
Seems redundant.
Thanks!
Paolo.
2014-10-06 Paolo Carlini paolo.carl...@oracle.com
PR c++/55250
* semantics.c (check_constexpr_bind_expr_vars): New.
(check_constexpr_ctor_body, massage_constexpr_body): Use it.
(build_constexpr_constructor_member_initializers): Handle
BIND_EXPR in the main
1 - 100 of 2918 matches
Mail list logo
