, I'm replacing 'or more' with 'at least', as, again, recommended in
the audit trail, and consistently with the other similar error message
recently added. Tested x86_64-linux.
Thanks,
Paolo.
///////
/cp
2014-08-14 Paolo Carlini
PR
Hi,
On 08/14/2014 04:18 PM, Jason Merrill wrote:
On 08/14/2014 07:14 AM, Paolo Carlini wrote:
+ nparms -= variadic_p ? variadic_p : default_p;
What if you have both default arguments and parameter packs?
Right. Got distracted by the minor secondary issues...
It seems to me
.
Thanks,
Paolo.
2014-08-14 Paolo Carlini
* typeck.c (composite_pointer_type, cxx_sizeof_or_alignof_type,
cp_build_array_ref, cp_build_function_call_vec): When a
pedwarn is suppressed under SFINAE, return error_mark_node.
*
.. unfortunately something is wrong with this commit, thus c++/62072.
For the time being I'm simply reverting it and adding the new testcase.
By the way, more generally, I don't understand at the moment how we can
safely use complete_type in the middle of tsubst & co: it can emit hard
errors a
Hi,
On 08/15/2014 07:30 PM, Jason Merrill wrote:
On 08/15/2014 12:17 PM, Paolo Carlini wrote:
By the way, more generally, I don't understand at the moment how we can
safely use complete_type in the middle of tsubst & co: it can emit hard
errors about, eg, incompleteness (see
... in practice, something like the below.
Paolo.
///
Index: cp/pt.c
===
--- cp/pt.c (revision 214027)
+++ cp/pt.c (working copy)
@@ -162,7 +162,7 @@ static tree tsubst_friend_class (tree, tree);
static int
Hi,
On 08/15/2014 09:22 PM, Jason Merrill wrote:
On 08/15/2014 03:16 PM, Paolo Carlini wrote:
+ bool in_function = (TREE_TYPE (tparms)
+ && DECL_FUNCTION_TEMPLATE_P (TREE_TYPE (tparms)));
Huh? There's no such thing as a template parameter of function type.
Works
Hi,
On 08/18/2014 09:01 PM, Jason Merrill wrote:
On 08/15/2014 03:37 PM, Paolo Carlini wrote:
On 08/15/2014 09:22 PM, Jason Merrill wrote:
On 08/15/2014 03:16 PM, Paolo Carlini wrote:
+ bool in_function = (TREE_TYPE (tparms)
+ && DECL_FUNCTION_TEMPLATE_P (TREE_TYPE
Hi,
recently, while having a look to c++/58614, I noticed that if we are
going to use default arguments we can clean up quite a few functions and
function calls, for example cp_parser_expression, per the below, which
passes testing. Is this something we want to pursue?
Thanks,
Paolo.
//
Hi,
two more functions. Tested x86_64-linux.
Thanks,
Paolo.
///
2014-08-19 Paolo Carlini
* parser.c (cp_parser_assignment_expression,
cp_parser_constant_expression): Add default arguments.
(cp_parser_primary_expression
Hi,
On 08/20/2014 08:56 PM, Andrew Sutton wrote:
+ return VAR_P (decl)
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_DECLARED_CONCEPT_P (decl);
this is brittle from the formatting point of view. Please double check
in detail what I'm going to say, but I think that in such cases you
Hi Andrew,
On 08/20/2014 11:08 PM, Andrew Sutton wrote:
On 08/20/2014 08:56 PM, Andrew Sutton wrote:
+ return VAR_P (decl)
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_DECLARED_CONCEPT_P (decl);
this is brittle from the formatting point of view. Please double check in
detail what
Hi,
On 08/21/2014 10:34 AM, Tony Wang wrote:
It's a very simple patch. Some target don't support atomic builtins, so all
related test cases should be
disabled. In folder libstdc++-v3/testsuite/18_support/nested_exception, all
other test cases have already been
disabled for target don't have at
Hi,
On 08/22/2014 12:01 AM, Manuel López-Ibáñez wrote:
On 21 August 2014 23:35, Jason Merrill wrote:
On 08/21/2014 04:22 PM, Manuel López-Ibáńez wrote:
+ && TREE_CODE (x) != FUNCTION_DECL
+ && !FUNCTION_POINTER_TYPE_P (TREE_TYPE (x
How about p
HI,
On 08/22/2014 04:48 PM, Marek Polacek wrote:
+ current.lhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT))
+? TRUTH_NOT_EXPR : ERROR_MARK;
IMHO, you want to close the parenthesis later, right before the semicolon.
Paolo.
Hi,
maybe this old issue is already fixed. We used to ICE on:
typedef void (*fptr)() __attribute((noreturn));
template void foo();
template void bar();
fptr f = bar< foo<0> >;
but lately we simply reject it:
34938.C:5:10: error: no matches converting function ‘bar’ to type ‘fptr
{aka void (*
Hi,
On 08/22/2014 08:17 PM, Jason Merrill wrote:
On 08/22/2014 01:53 PM, Paolo Carlini wrote:
maybe this old issue is already fixed. We used to ICE on:
typedef void (*fptr)() __attribute((noreturn));
template void foo();
template void bar();
fptr f = bar< foo<0> >;
but late
Hi,
On 08/22/2014 09:27 PM, Jason Merrill wrote:
On 08/22/2014 03:19 PM, Paolo Carlini wrote:
Ok. Currently in cases like the present one, dump_type_suffix upon a
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the given
FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers
Hi again,
On 08/22/2014 09:33 PM, Paolo Carlini wrote:
Hi,
On 08/22/2014 09:27 PM, Jason Merrill wrote:
On 08/22/2014 03:19 PM, Paolo Carlini wrote:
Ok. Currently in cases like the present one, dump_type_suffix upon a
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the
given
Hi,
On 08/22/2014 10:45 PM, Jason Merrill wrote:
Does your patch handle this correctly?
template struct A { };
A*p = 42;
I would say yes:
34938_2.C:2:20: error: invalid conversion from ‘int’ to ‘Aconst>*’ [-fpermissive]
A*p = 42;
But, interestingly, in this case 4.8.x was incorrect, this
.. on the other hand, the below is a case which my patchlet, which
simply tracks pointers, does *not* handle correctly:
struct B { };
template struct A { };
A*p = 42;
should be fixable by complicating a bit the tracking, telling apart
member pointers.
Paolo.
Hi again,
On 08/23/2014 09:16 AM, Paolo Carlini wrote:
.. on the other hand, the below is a case which my patchlet, which
simply tracks pointers, does *not* handle correctly:
struct B { };
template struct A { };
A*p = 42;
should be fixable by complicating a bit the tracking, telling apart
Hi,
I'm going to commit as obvious the below when testing finishes.
Thanks,
Paolo.
///
2014-08-25 Paolo Carlini
* g++.old-deja/g++.pt/var1.C: Use c++14, not c++1y, in dg-error.
Index: g++.old-deja/g++.pt/v
Hi,
On 08/24/2014 12:37 AM, Ed Smith-Rowland wrote:
With revision 214400 we have the C++14 value of __cplusplus set to the
correct value of 201402L (from 201300L).
It occurs to me: instead of having to remember every time those numbers,
couldn't we predefine, for example:
__cplusplus_98
Hi,
On 08/26/2014 10:42 AM, Rainer Orth wrote:
Paolo Carlini writes:
Hi,
On 08/24/2014 12:37 AM, Ed Smith-Rowland wrote:
With revision 214400 we have the C++14 value of __cplusplus set to the
correct value of 201402L (from 201300L).
It occurs to me: instead of having to remember every
Hi,
On 08/26/2014 10:52 AM, Jonathan Wakely wrote:
That seems like a good idea, but I'm not convinced there's any benefit
in Ed's changes to do:
-#if __cplusplus > 201103L
+#if __cplusplus >= 201402L
It seems like unnecessary churn to me,
about this, I had the same thought ;)
Paolo.
Hi,
On 08/26/2014 10:56 AM, Rainer Orth wrote:
bits/c++config...
Which won't help users seeing them in the headers. Maybe the issue
could be avoided by chosing names that make it clear that they are
g++/libstdc++ specific, not generic?
Sure, whatever works, the names were tentative, for the cp
Hi,
On 08/26/2014 08:58 PM, Jason Merrill wrote:
On 08/26/2014 12:01 PM, Paolo Carlini wrote:
the difference, for the latter and for more complex cases, is that
adjust_temp_type calls cp_fold_convert which ends up returning a
NOP_EXPR (eg, build in fold_convert_loc).
Perhaps we should
Hi again,
On 08/26/2014 08:58 PM, Jason Merrill wrote:
On 08/26/2014 12:01 PM, Paolo Carlini wrote:
the difference, for the latter and for more complex cases, is that
adjust_temp_type calls cp_fold_convert which ends up returning a
NOP_EXPR (eg, build in fold_convert_loc).
Perhaps we should
.. two additional remarks (maybe obvious, I don't know):
- It also appears to work - for sure for all the tests in c++/52892 +
the tests in c++/52282 not involving data members (eg, the original one)
- simply unconditionally calling STRIP_NOPS right after the
cxx_eval_constant_expression at the
Hi,
On 08/27/2014 04:19 PM, Jason Merrill wrote:
On 08/27/2014 04:41 AM, Paolo Carlini wrote:
.. two additional remarks (maybe obvious, I don't know):
- It also appears to work - for sure for all the tests in c++/52892 +
the tests in c++/52282 not involving data members (eg, the origina
Hi,
I think that in order to implement the resolution we simply have to
remove the check. Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2014-09-01 Paolo Carlini
DR 1405
PR c++/58102
* semantics.c (cxx_eval_outermost_constant_expr): Do not check
Hi,
while looking into c++/58102 and DR 1405 I noticed that we don't
implement DR 1453 either, sort of dual issue with volatile instead of
mutable. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2014-09-02 Paolo Carlini
DR 1453
* cl
Hi,
On 09/02/2014 04:11 PM, Jason Merrill wrote:
On 09/01/2014 09:47 AM, Paolo Carlini wrote:
-constexpr A b = a;// { dg-error "mutable" }
+constexpr A b = a;
This is wrong; we still need to get an error here.
Hum, interesting. Neither current EDG nor current clang error
Hi,
On 09/02/2014 04:28 PM, Jason Merrill wrote:
On 09/02/2014 10:17 AM, Paolo Carlini wrote:
Let's see if I can tease the case out...
I think you need to leave that hunk alone, and instead fix the new
testcase by treating = {} more like {}, just as we already don't
requ
Hi again,
On 09/02/2014 04:28 PM, Jason Merrill wrote:
On 09/02/2014 10:17 AM, Paolo Carlini wrote:
Let's see if I can tease the case out...
I think you need to leave that hunk alone, and instead fix the new
testcase by treating = {} more like {}, just as we already don't
requ
Hi,
On 09/02/2014 05:45 PM, Jason Merrill wrote:
On 09/02/2014 11:07 AM, Paolo Carlini wrote:
Anyway, what about the below? Certainly works for the tests which we
have got.
Hmm. This is definitely an improvement, as it allows a subset of
a non-volatile glvalue of literal type that refers
Hi,
On 11/05/2013 04:51 PM, Jonathan Wakely wrote:
On 3 November 2013 11:30, Paolo Carlini wrote:
On 11/03/2013 12:19 PM, Jonathan Wakely wrote:
Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
patch coming. Luc is there any reason not to just replace all those
Hi
On 11/06/2013 12:01 AM, Jonathan Wakely wrote:
I also changed a few tests to use static_assert instead of VERIFY so
they only need to be compiled, not executed, saving a few milliseconds
when running the testsuite ;-)
Good idea, anyway. I may get around to do more of that + those missing
tes
Hi,
in this bug, filed by Zack, we loop forever after error in
constant_value_1. Straightforward thing to do, detect and break out.
Tested x86_64-linux.
Thanks,
Paolo.
/cp
2013-11-06 Paolo Carlini
PR c++/50436
* init.c (constant_value_1): Break out
Hi,
at -O0 we ICE for this valid testcase in output_constant because
NULLPTR_TYPE is not handled. Should I dig further because we never want
nullptr to reach varasm? Because otherwise the patchlet works fine, I
checked that expand_expr can cope perfectly well with NULLPTR_TYPE as
TREE_TYPE of
Hi all, Jason,
in mainline, this commit:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199232
appear to have caused a diagnostic regression for the following (from
c++/43906):
extern void z();
void f() { if ( z ) z(); }
that is, with -Waddress we warn twice, because in cp_conver
... well, something like this seems better to me. Only lightly tested so
far, sorry.
Paolo.
///
Index: cvt.c
===
--- cvt.c (revision 204536)
+++ cvt.c (working copy)
@@ -621,24 +621,25 @@ cp_convert_
.. nope, p2 isn't Ok, because we would return a different tree
depending on complain and . c_inhibit_evaluation_warnings. Thus either
something closer to p or something else.
Paolo.
... I think that a much better fix would be calling the second cp_convert with
tf_none and make sure the information is propagated down to the c-common code
emitting the diagnostic. I'm going to work on it. Note anyway that we still
have the option of not calling cp_convert when it's not neces
On 11/09/2013 08:59 PM, Ed Smith-Rowland wrote:
On 10/27/2013 05:17 AM, Paolo Carlini wrote:
On 10/22/2013 02:28 PM, Ed Smith-Rowland wrote:
I think this is pretty easy - gnu::deprecated has the same semantics.
Since we decided to have this now, we should also update the docs,
thus htdocs
Hi,
this is the issue with -Waddress caused by the fix for c++/56930. I'm
handling it as already described, that is by adding a bool parameter to
c_common_truthvalue_conversion.
Tested x86_64-linux.
Thanks!
Paolo.
//
/c-family
2013-11-11 Paolo Carlini
g the cp_* variant of
build_c_cast, which takes a tsubst_flags_t, in a function taking a
tsubst_flags_t seems the right thing to do.
Tested x86_64-linux.
Thanks!
Paolo.
//
2013-11-11 Paolo Carlini
* cvt.c (cp_convert_to_pointer): Call build_ptrmemfunc b
rlier today ;) Tested x86_64-linux.
Thanks!
Paolo.
//
/cp
2013-11-12 Paolo Carlini
PR c++/57734
* pt.c (lookup_template_class_1): Handle alias template declarations
of enumeration types.
/testsuite
2013-11-12 Paolo Carlini
PR c++/
Hi,
in this very old issue we reject:
void f(int,int);
void f(int,int,int);
void g ()
{
(&f)(1,2,3);
}
with "address of overloaded function with no contextual type information".
It seems to me that handling the ADDR_EXPR close to the beginning of
finish_call_expr goes a long way toward f
Paolo.
//
/cp
2013-11-13 Paolo Carlini
PR c++/59080
* pt.c (unify): Don't call unify_array_domain with a NULL_TREE
third argument.
PR c++/59096
* pt.c (apply_late_template_attributes): Check that TREE_VALUE
isn't N
Hi,
On 11/13/2013 03:40 PM, Marc Glisse wrote:
Bootstrap and testsuite on x86_64-unknown-linux-gnu.
Ok, thanks. If you like I think the patch is safe for 4.8.3 too.
The main other issue in that PR will require a UDL specialist.
Let's ping Ed, then.
Thanks,
Paolo.
Hi,
we are getting bug reports about this issue with NSDMIs in template
classes, like:
struct B
{
template
struct A
{
int X = N;
};
};
57887.C:6:13: error: ‘N’ was not declared in this scope
Looking at cp_parser_class_specifier_1, the comments about the late
parsing of default arguments (wh
hanks, much simpler indeed. I'm finishing testing the below.
Paolo.
/cp
2013-11-14 Paolo Carlini
PR c++/57887
* parser.c (cp_parser_late_parsing_nsdmi): Call
maybe_begin_member_template_processing.
* pt.c (maybe_begin_member_template_
Hi,
On 11/12/2013 04:51 PM, Jason Merrill wrote:
Please add a comment citing 13.3.1.1. OK with that change.
Thanks. The patch is still unapplied, because there are some
interactions with access control (and bugs we have got about access
control) which make me a bit nervous. For example for a
Hi,
fixed by a recent patch of mine, committed to mainline.
Thanks,
Paolo.
/
2013-11-15 Paolo Carlini
PR c++/58599
* g++.dg/cpp0x/nsdmi-template5.C: New.
Index: g++.dg/cpp0x/nsdmi-template5.C
Hi,
committed to mainline.
Thanks,
Paolo.
///
2013-11-15 Paolo Carlini
PR c++/58188
* g++.dg/cpp0x/nsdmi-template8.C: New.
2013-11-15 Paolo Carlini
PR c++/58725
* g++.dg/cpp0x/nsdmi-template7.C: New.
2013-11-15 Paolo Carlini
Hi,
C++11 7.1.5 seems very clear that redeclarations of *variables*
differing in constexpr are fine (clang and icc agree). Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2013-11-17 Paolo Carlini
PR c++/59123
* decl.c (validate_constexpr_redeclaration
Hi,
tested x86_64-linux, committed to mainline.
Paolo.
/
2013-11-18 Paolo Carlini
PR c++/53473
* g++.dg/cpp0x/constexpr-noexcept7.C: New.
Index: g++.dg/cpp0x/constexpr-noexcept7.C
===
--- g
Hi
> On 22/nov/2013, at 21:12, Jakub Jelinek wrote:
>
> Hi!
>
> I've noticed recently that the 28_regex/ tests look very expensive
> testing time wise, while there are only ~ 120 tests, I'm routinely seeing
> 28_regex/* complete last. This patch moves the most expensive 28_regex/
> tests ([ab]
On 11/23/2013 08:12 PM, Jason Merrill wrote:
On 11/10/2013 05:26 AM, Paolo Carlini wrote:
this is the issue with -Waddress caused by the fix for c++/56930. I'm
handling it as already described, that is by adding a bool parameter to
c_common_truthvalue_conversion.
Why not handle this by m
On 11/23/2013 08:36 PM, Jason Merrill wrote:
On 11/06/2013 05:56 AM, Paolo Carlini wrote:
in this bug, filed by Zack, we loop forever after error in
constant_value_1. Straightforward thing to do, detect and break out.
This doesn't handle mutual infinite recursion, such as the mod
On 11/23/2013 10:08 PM, Jason Merrill wrote:
I believe that our current practice is to have one error and then use
inform for follow-on messages. OK with that change.
Thanks. The multiple permerror and error aren't in the new code, my
patch just shuffles those around. I would be glad to work on
... evidently I attached the wrong p ;) This should be right one.
Paolo.
Index: c-common.c
===
--- c-common.c (revision 205343)
+++ c-common.c (working copy)
@@ -4579,10 +4579,11 @@ c_common_truthvalue_conversion (location_t locati
Hi,
On 11/25/2013 10:47 PM, Jason Merrill wrote:
On 11/25/2013 05:02 AM, Paolo Carlini wrote:
because then we don't warn *at all*. The reason being that with the
*first* cp_convert we end up calling c_common_truthvalue_conversion with
c_inhibit_evaluation_warnings bumped. The bumping ha
Hi,
On 11/23/2013 11:35 PM, Jason Merrill wrote:
On 10/20/2013 12:07 PM, Paolo Carlini wrote:
case COMPONENT_REF:
+ if (is_overloaded_fn (TREE_OPERAND (t, 1)))
+return t;
Hmm, I'd be inclined to strip the COMPONENT_REF in this case to
produce something that's actua
Hi,
On 11/26/2013 04:30 PM, Jason Merrill wrote:
A BASELINK isn't useful as a constant, either; I was thinking of the
FUNCTION_DECL itself. Perhaps
gcc_checking_assert (!really_overloaded_fn
return get_first_fn
We have got a bunch of testcases, for example constexpr-ex4.C - attached
for your
Hi,
On 10/05/2014 08:50 PM, François Dumont wrote:
+#include
Seems redundant.
Thanks!
Paolo.
Thanks!
Paolo.
/
/cp
2014-10-06 Paolo Carlini
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 m
-statements; the parser is tweaked to suppress the
"compound-statement in constexpr function" pedwarn in C++14 mode.
Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2014-10-08 Paolo Carlini
* semantics.c (check_constexpr_ctor_bo
Hi,
On 10/09/2014 08:10 AM, Ville Voutilainen wrote:
Ok, another try (I don't have write-after-approval, so please commit
the patch once you think it's ok):
Thanks Ville from me too. I'm taking care of the commit with a few very
minor tweaks:
1- In new library testcases we are consistently usin
Hi,
On 10/09/2014 03:31 PM, Jason Merrill wrote:
On 10/08/2014 03:47 PM, Paolo Carlini wrote:
(check_constexpr_ctor_body): Use it; add bool parameter.
This function seems to only be called in one place; why add the parameter?
Is also called recursively by check_constexpr_ctor_body_1 and
.. a simple example in C++11 would be:
struct S
{
constexpr S() { { struct T { }; } }
};
Paolo.
Hi,
On 10/09/2014 04:18 PM, Jason Merrill wrote:
On 10/09/2014 09:49 AM, Paolo Carlini wrote:
Hi,
On 10/09/2014 03:31 PM, Jason Merrill wrote:
On 10/08/2014 03:47 PM, Paolo Carlini wrote:
(check_constexpr_ctor_body): Use it; add bool parameter.
This function seems to only be called in
Hi,
I'm renaming a few testcases which actually are about alias declarations
not typedefs.
Thanks,
Paolo.
2014-10-14 Paolo Carlini
* testsuite/20_util/add_lvalue_reference/requirements/typedefs.cc:
Rename to alias_decl.cc.
* testsuite/20
below.
Thanks,
Paolo.
//
2014-10-15 Paolo Carlini
* include/std/limits: Remove stray spaces after backslash.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line number.
* testsuite/20_util/make_signed/requirements/typedefs_n
Hi,
I committed the below.
Thanks,
Paolo.
/
2014-10-15 Paolo Carlini
* testsuite/20_util/add_const/requirements/alias_decl.cc: New.
* testsuite/20_util/add_cv/requirements/alias_decl.cc: Likewise.
* testsuite/20_util/add_pointer/requirements
Hi,
On 10/15/2014 11:44 AM, Jonathan Wakely wrote:
Index: testsuite/20_util/add_const/requirements/alias_decl.cc
===
--- testsuite/20_util/add_const/requirements/alias_decl.cc (revision 0)
+++ testsuite/20_util/add_const/requiremen
Hi again,
On 10/15/2014 11:50 AM, Paolo Carlini wrote:
We might also want to consider a global s/gnu++0x/gnu++11/ some day.
And s/gnu++1y/gnu++14 of course ;)
I'm going to commit the below.
Thanks,
Paolo.
/
2014-10-15 Paolo Carlini
* testsuite/20
On 10/15/2014 07:35 PM, Mike Stump wrote:
On Oct 15, 2014, at 8:41 AM, Paolo Carlini wrote:
... the below replaces -std=c++0x and -std=c++11 with -std=gnu++11.
Seems odd to go from c++11 -> gnu++11. Why?
Because all the new testcases we are committing use -std=gnu++11, which
is ri
Hi,
On 10/15/2014 11:44 AM, Jonathan Wakely wrote:
We might also want to consider a global s/gnu++0x/gnu++11/ some day.
The below takes care of 17-19, the rest over the next days...
Paolo.
//
2014-10-15 Paolo Carlini
* testsuite/17_intro/freestanding.cc: Prefer
Hi,
contributed by Daniel. Thanks!
Paolo.
/
2014-10-15 Daniel Krugler
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Enable tests predicated on PR c++/53000.
Index: testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
=
... the below completes the work, no -std=gnu++0x anymore.
Paolo.
/
2014-10-16 Paolo Carlini
* testsuite/lib/libstdc++.exp: Prefer -std=gnu++11.
* testsuite/20_util/add_lvalue_reference/requirements/
explicit_instantiation.cc: Likewise
Hi,
another patchlet along the lines of the other I proposed over the last
weeks: this one should be really uncontroversial, because turns out that
in all but one case we are passing all NULL / false arguments.
Tested x86_64-linux.
Thanks,
Paolo.
/
... the patch.
Paolo.
//
2014-10-21 Paolo Carlini
* parser.c (cp_parser_unary_expression): Add default arguments.
(cp_parser_cast_expression, cp_parser_sizeof_operand,
cp_parser_omp_atomic): Adjust.
Index: parser.c
Hi,
On 10/22/2014 11:05 PM, François Dumont wrote:
+ VERIFY( counter_type::less_compare_count <= 2.0 * std::log2(nb_values) );
Nit: log2 isn't in C89, thus we shouldn't use it unconditionally, ie, if
the test isn't guarded by { dg-require-cmath "" }. Thus, either the
latter, or just express l
Hi,
tested x86_64-linux.
Thanks,
Paolo.
///
2014-10-24 Paolo Carlini
* include/bits/atomic_base.h: Avoid including .
* include/std/atomic: When __cplusplus < 201103L skip the rest of
the header.
* testsuite/29_atomics/headers/atomic/st
Hi,
On 06/02/2014 12:52 AM, Daniel Krügler wrote:
My formulation was intentionally tentative, because I never searched
for that coding rule. Maybe Paolo could help to clarify.
As far as I remember, we never explicitly discussed that coding rule,
it's largely an historical accident. Thus I woul
Hi,
I noticed only today that the code I touched a few days ago can trigger
a spurious -Wuninitialized warning, which I'm going to avoid with the below.
Thanks,
Paolo.
2014-06-02 Paolo Carlini
* pt.c (tsubst_function_type): Initialize arg_types.
Index:
templates too.
Tested x86_64-linux.
Thanks,
Paolo.
//
gcc/cp
2014-06-03 Paolo Carlini
DR 1423
PR c++/52174
* call.c (standard_conversion): Convert nullptr to bool only
in case of direct-initialization.
(add_function_candidate
.. wondering if I should check DECL_CONSTRUCTOR_P (fn) too.
Paolo.
I see, thanks. Thus I'm finishing testing the below.
Thanks,
Paolo.
gcc/cp
2014-06-03 Paolo Carlini
DR 1423
PR c++/52174
* call.c (standard_conversion): Convert nullptr to bool only
in case of direct-initialization.
gcc/testsuite
20
Hi,
On 06/03/2014 05:41 PM, Jason Merrill wrote:
On 06/03/2014 11:24 AM, Paolo Carlini wrote:
+ if (NULLPTR_TYPE_P (from) && (flags & LOOKUP_ONLYCONVERTING))
+conv->bad_p = true;
Thanks. What kind of error message do we get with this change? Would
addi
Hi,
On 05/26/2014 05:41 PM, Paolo Carlini wrote:
... the below should be better, handles correctly cv-qualifiers.
Pinging this...
Thanks!
Paolo.
k also ought to be well-formed.
Right. Thus I reworked a bit the code in cp_complete_array_type to
handle specially a single-element TREE_LIST together a single-element
CONSTRUCTOR. Tested x86_64-linux.
Thanks!
Paolo.
//
/cp
2014-06-04 Paolo Carlini
PR c++/434
Hi,
On 06/04/2014 09:32 PM, Jason Merrill wrote:
On 06/04/2014 02:08 PM, Paolo Carlini wrote:
/* An array of character type can be initialized from a
- brace-enclosed string constant.
-
- FIXME: this code is duplicated from reshape_init. Probably
- we should just call
... sorry attached a wrong diff.
Paolo.
/
Index: cp/decl.c
===
--- cp/decl.c (revision 211242)
+++ cp/decl.c (working copy)
@@ -5758,6 +5758,13 @@ check_initializer (tree decl, tree init, int flags
Hi,
in this minor issue, after a permerror about "passing ‘volatile foo’ as
‘this’ argument discards qualifiers" we crash with an infinite recursion
in the gimplifier. The testcase:
struct foo { };
typedef struct
{
volatile foo fields;
} CSPHandleState;
CSPHandleState a;
void fn1 ()
{
CSPH
Hi,
On 06/05/2014 03:12 PM, Jason Merrill wrote:
On 06/05/2014 09:05 AM, Richard Biener wrote:
+ *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
+ op0, build_fold_addr_expr (op1));
That seems like a fine approach.
Thanks a lot guys. Therefor
Hi,
On 06/05/2014 03:20 PM, Richard Biener wrote:
I think the operands have to be reversed though - the type matches
that of op0. Sorry ;)
Something like this, then?
Thanks,
Paolo.
///
Index: cp-gimplify.c
===
--- cp-
701 - 800 of 3018 matches
Mail list logo
