the loop would avoid more
bogus warnings... What do you think, is the change good enough for now?
Thanks,
Paolo.
/c-family
2011-10-21 Paolo Carlini paolo.carl...@oracle.com
PR c++/45385
* c-common.c (conversion_warning): Early return only if the
only
Hi,
committed.
Thanks,
Paolo.
//
2011-10-21 Roland Stigge sti...@antcom.de
PR translation/47064
* params.def: Fix typo compilatoin - compilation.
Index: params.def
===
--- params.def
it to the 4_6-branch too after 4.6.2 is out..
Thanks again,
Paolo.
//
/cp
2011-10-21 Paolo Carlini paolo.carl...@oracle.com
PR c++/45385
* init.c (build_vec_init): Early return error_mark_node if
maxindex is -1.
/c-family
2011-10-21 Paolo Carlini
would ;).
Anyway, seriously, I'll try to come up with an improved proposal over
the next days.
Thus I tested on x86_64-linux the below. Ok for mainline?
Thanks,
Paolo.
/
/cp
2011-10-21 Paolo Carlini paolo.carl...@oracle.com
PR c++/31423
* typeck2.c
Hi,
this is essentially about enabling -Wnarrowing as part of -Wc++0x-compat
(see audit trail for details). Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
/
/c-family
2011-10-23 Paolo Carlini paolo.carl...@oracle.com
PR c++/50810
* c-opts.c
Hi,
On 10/23/2011 07:23 AM, Paolo Carlini wrote:
-@item -Wno-narrowing @r{(C++ and Objective-C++ only)}
+@item -Wnarrowing @r{(C++ and Objective-C++ only)}
@opindex Wnarrowing
@opindex Wno-narrowing
-With -std=c++0x, suppress the diagnostic required by the standard for
-narrowing conversions
On 10/23/2011 10:07 PM, Gerald Pfeifer wrote:
Is it possible that this is responsible for a bootstrap failure introduced
in the last 27 hours or so?
/scratch/tmp/gerald/gcc-HEAD/gcc/tree-object-size.c:44:59: error: narrowing
conversion of '-0x1' from 'int' to 'long unsigned
On 10/23/2011 10:19 PM, Eric Botcazou wrote:
So, to be clear, this is for bootstrapping with a C++ compiler, right?
Honestly, didn't try that... It's definitely possible that there are
glitches in the tree wrt -Wnarrowing in C++.
Bootstrapping with the C++ compiler has been the default for
On 10/23/2011 10:25 PM, Eric Botcazou wrote:
Oh my, I thought I was till using C here... Ok, I'll fix that.
The base compiler is a C compiler, stage 2/3 are built with the C++ compiler.
Yes, yes. Sorry about this.
Anyway, the below appears to work for me. Eric shall I commit it?
Thanks,
On 10/23/2011 10:39 PM, Paolo Carlini wrote:
On 10/23/2011 10:25 PM, Eric Botcazou wrote:
Oh my, I thought I was till using C here... Ok, I'll fix that.
The base compiler is a C compiler, stage 2/3 are built with the C++
compiler.
Yes, yes. Sorry about this.
Anyway, the below appears to work
On 10/23/2011 10:47 PM, Paolo Carlini wrote:
On 10/23/2011 10:39 PM, Paolo Carlini wrote:
On 10/23/2011 10:25 PM, Eric Botcazou wrote:
Oh my, I thought I was till using C here... Ok, I'll fix that.
The base compiler is a C compiler, stage 2/3 are built with the C++
compiler.
Yes, yes. Sorry
On 10/23/2011 11:05 PM, Gabriel Dos Reis wrote:
On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazouebotca...@adacore.com wrote:
Anyway, the below appears to work for me. Eric shall I commit it?
I have other errors for config/i386/i386.c on my x86-64 machine. But are we
sure that we want to warn
Hi,
Personally, I would be in favor of taking -Wc++0x-compat out of -Wall.
Patch pre-approved.
Thanks.
It makes sense though that -Wextra implies -Wc++0x-compat.
Indeed, it would. However, unfortunately, we are using -W to bootstrap
(it just failed on me). Thus I'm bootstrapping and testing
... and the patch ;)
Paolo.
/c-family
2011-10-23 Paolo Carlini paolo.carl...@oracle.com
PR c++/50810
* c-opts.c (c_common_handle_option): Do not enable -Wc++0x-compat
as part of -Wall; handle -Wc++0x-compat.
(c_common_post_options): -std=c++0x
Hi,
On 10/24/2011 03:30 AM, Gabriel Dos Reis wrote:
We do not use -W or -Wno- to suppressed *required* diagnostics. So,
when -std=c++0x, -Wno-narrowing should not have any effect.
Personally, I have no problem with this, but note, I'm not inventing
anything new here, the behavior you are
On 10/24/2011 04:10 AM, Gabriel Dos Reis wrote:
Before the patch, -std=c++0x effectively put off -Wc++0x-compat
because we are compiling c++98/c++03 code, so we can only *warn* about
possible compatibility conflict with C++11. However, the narrowing
diagnostic required by C++11 is NOT a
works). I also added a new testcase for that.
Booted and tested x96_64-linux.
Ok?
Thanks,
Paolo.
PS: alternately, I'm attaching a simpler variant which leaves
-Wno-narrowing active in C++0x mode.
/
/c-family
2011-10-24 Paolo Carlini paolo.carl...@oracle.com
PR c
Hi,
On Mon, Oct 24, 2011 at 6:47 AM, Paolo Carlinipaolo.carl...@oracle.com wrote:
Hi,
the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
added to -Wextra either because bootstrap passes -W) and also, as requested
by Gaby, preventing -Wno-narrowing from suppressing the
On 10/24/2011 02:18 PM, Paolo Carlini wrote:
OK with a minor correction. This bit
+With -std=c++0x, @option{-Wno-c++0x-compat} can be used to suppress
+the diagnostic required by the standard.
should not be there. It is currently an accident of implementation
detail as opposed to a feature
.. just to let you know guys, I'm already unassigned from the PR, but
today I wanted to give it one (actually 3) more try. Given the
controversy, I don't feel like further following the issue, it just
makes me nervous. Eventually, feel free to adjust my patches to your likes.
Paolo.
Hi,
this fixes an ICE on invalid which occurs inside
composite_pointer_type_r, now a bit more stressed post fix for PR38174.
Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
//
/cp
2011-10-25 Paolo Carlini paolo.carl...@oracle.com
PR c++/50858
Hi,
this fixes an ICE on invalid new in mainline. Tested x86_64-linux.
Ok?
Thanks,
Paolo.
/cp
2011-10-25 Paolo Carlini paolo.carl...@oracle.com
PR c++/50861
* pt.c (tsubst_copy_and_build): Check return value of
tsubst_copy_and_build
Hi,
double checked that gcc.pot is now ok and committed as trivial
Thanks,
Paolo.
PS: eh, I patched 'main'! ;)
//
2011-10-25 Paolo Carlini paolo.carl...@oracle.com
PR translation/46617
* gcc.c (main): Fix fatal_error string for translation.
Index: gcc.c
Carlini paolo.carl...@oracle.com
PR c++/50870
* pt.c (tsubst_copy_and_build): When object is an ARROW_EXPR
pass to tsubst_baselink its first operand.
/testsuite
2011-10-26 Paolo Carlini paolo.carl...@oracle.com
PR c++/50870
* g++.dg/cpp0x/decltype34.C
On 10/26/2011 05:27 PM, Jason Merrill wrote:
On 10/26/2011 10:39 AM, Paolo Carlini wrote:
I'm trying to fix this PR, ice on valid, which Daniel kindly filed while
we were triaging PR50864. In short, in tsubst_copy_and_build, for
COMPONENT_REF, we call tsubst_baselink with an object which
Hi,
we have an inconsistent mix: shall we do the below? Test in progress on
x86_64-linux.
Thanks,
Paolo.
//
2011-10-26 Paolo Carlini paolo.carl...@oracle.com
* typeck.c (cp_build_addr_expr_1): Use BASELINK_P.
* class.c (instantiate_type): Likewise
Hi,
one more / RFC, for the ICE on invalid part of these issues with '-'.
The below tries to catch the problem very early, in
cp_parser_postfix_dot_deref_expression and apparently works fine, passes
the testsuite, etc. Is it too early? Is the check tight enough?
Thanks,
Paolo.
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after -.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b-A::B::i;
I was also trying to construct such kind of example myself... but my
patch does not regress on the testcase you wrote down. I
On 10/26/2011 10:30 PM, Paolo Carlini wrote:
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after -.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b-A::B::i;
I was also trying to construct such kind of example myself... but my
patch does
On 10/26/2011 10:35 PM, Paolo Carlini wrote:
On 10/26/2011 10:30 PM, Paolo Carlini wrote:
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after -.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b-A::B::i;
I was also trying to construct
On 10/26/2011 06:27 PM, Jason Merrill wrote:
OK.
I re-opened this one because: 1- We may want to fix it in 4_6-branch
too, it's a regression there too; 2- We are still handling incorrectly
the template impl case. For the latter a variant of my old idea still
works, fwiw.
Thanks,
Paolo.
... forgot the testcase, sorry.
Paolo.
//
// PR c++/50870
// { dg-options -std=gnu++0x }
template class V
struct impl
{
template class T static T create();
};
template class T, class U, class V, class
= decltype(implV::template createT()
-
On 10/27/2011 12:48 AM, Jason Merrill wrote:
On 10/26/2011 06:20 PM, Paolo Carlini wrote:
I re-opened this one because: 1- We may want to fix it in 4_6-branch
too, it's a regression there too; 2- We are still handling incorrectly
the template impl case. For the latter a variant of my old idea
.. maybe my message wasn't clear, sorry, I'm a bit tired (here it's
late): I meant to say that the non_reference tweak fixes the
non-template impl class case, but something more is needed for a
template impl (thus the new testcase). And, additionally, this issue is
a [4.6/4.7 Regression],
Hi,
tested x86_64-linux (with _GLIBCXX_USE_C99_COMPLEX_TR1 manually set to
zero for the affected function), committed to mainline. Will go in 4.6.3
too.
Thanks,
Paolo.
///
2011-10-27 Richard B. Kreckel krec...@ginac.de
Paolo Carlini paolo.carl
Hi,
Let me know if you need additional details, or what else.
How is the template case failing?
Some preliminary notes, maybe you can already make some sense out of
this, more later, if you like:
Thus we have this testcase:
template class V
struct impl
{
template class T static T
Hi,
Looks like
qualified_name_lookup_error (object_type, tmpl, member,
input_location);
is passing the wrong first argument; the scope argument should be the same as
we passed to lookup_qualified_name.
Ok, thanks, I'll work
Hi,
On Thu, Oct 27, 2011 at 6:02 AM, Paolo Carlini paolo.carl...@oracle.com
wrote:
Hi,
tested x86_64-linux (with _GLIBCXX_USE_C99_COMPLEX_TR1 manually set to zero
for the affected function), committed to mainline. Will go in 4.6.3 too.
Hmm, why is the test of the form x 0.0
Hi again,
Hmm, why is the test of the form x 0.0, and not testing the sign of x?
Actually, we can as well use the std::abs, no?
Paolo
Hi
On 10/27/2011 08:57 AM, Paolo Carlini wrote:
Ok, thanks, I'll work more on this later today. Then, if we fix that we
don't error out at all, right? Because this is a reject valid, AFAIK.
In that case, lookup_qualified_name shouldn't be returning error_mark_node.
Yes, I suspected
Hi,
I am surprised by your comment. You do not care and that is why you
are eager to
commit the patch without checking first with fellow area maintainers?
Yes, probably my comment wan't clear enough: my point was that I cannot spend
more time on this issue. I'm convinced, I may be wrong,
Hi again,
On 10/27/2011 08:57 AM, Paolo Carlini wrote:
Ok, thanks, I'll work more on this later today. Then, if we fix that we don't
error out at all, right? Because this is a reject valid, AFAIK.
In that case, lookup_qualified_name shouldn't be returning error_mark_node.
A little more
On 04/01/2012 12:38 PM, Diego Novillo wrote:
I'm not sure it makes sense to propose it for gcc-4_6-branch. Jason/Ben,
any opinions on PR 52796 and what should we do for gcc-4_6-branch?
Fixed. :)
I'm so relieved, seriously.
Thanks,
Paolo
Hi,
The attached patches fix http://gcc.gnu.org/PR52822, and have been
tested with `make check-c++` on linux-x86_64. The trunk patch applies
and tests cleanly on gcc-4_7-branch. The gcc-4_6-branch patch is
significantly simpler, as Paolo suggested on the bug.
A few small issues.
For the 4.6
.. ah: remember to add PR libstdc++/52822 at the beginning of the
ChangeLog entry, otherwise Bugzilla will not pick your commit!
Thanks,
Paolo.
Hi,
tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
/
2012-04-11 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/52931
* include/bits/functional_hash.h (struct hash): Remove definition.
* testsuite/20_util/hash/52931.cc: New.
Index
Hi,
this is what I'm going to commit to mainline and 4_7-branch to fix the
regression.
Tested x86_64-linux, debug-mode too.
Thanks,
Paolo.
2012-04-12 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/52942
* include/bits/stl_function.h
Hi,
prettyprinters.exp is never run except in non-parallel check or when
requested explicitly. Tested on powerpc-linux and checked in as
obvious.
Thanks Andreas.
Since you seem to pay good attention to these testing details, I wonder if you
could also help with the issue I noticed again
On 04/12/2012 11:43 PM, Andreas Schwab wrote:
Paolo Carlinipcarl...@gmail.com writes:
Since you seem to pay good attention to these testing details, I wonder if
you could also help with the issue I noticed again over the last days with
make check-performance not actually doing much if make
optimizations). Many thanks to Marc Glisse for off-line
reviewing and helping over the last day or so!!
Tested x86_64-linux multilib.
Paolo.
2012-04-14 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/52699
* include/bits/random.tcc
Hi,
tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
/
2012-04-15 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/52702
* include/std/type_traits (is_trivially_destructible): Add.
(has_trivial_destructor): Remove.
* testsuite
.. hi all, hi Gaby,
a couple of days ago, Manuel suggested in the audit trail of the main
caret diagnostics PR, that now that we actually have got a form of it,
the kind of change I proposed to resolve PR 49152 may make much more
sense. In any case, my original patch still regtests fine
on function-definition);
the trivial check avoids the Seg fault (and would be safe, for 4.7 too)
but I'm not sure if we want to bail out a bit earlier. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2012-04-16 Paolo Carlini paolo.carl...@oracle.com
PR c++/53003
Carlini paolo.carl...@oracle.com
PR c++/52599
* semantics.c (massage_constexpr_body): Check for function-try-block
as constructor function-body.
/testsuite
2012-04-17 Paolo Carlini paolo.carl...@oracle.com
PR c++/52599
* g++.dg/cpp0x/constexpr-ctor10.C
Hi,
I think build_constexpr_constructor_member_initializers is a better
place for that check, since it's already looking at the tree structure.
Indeed. I'm finishing testing the below. Ok if it passes?
Thanks,
Paolo.
/cp
2012-04-17 Paolo Carlini paolo.carl
On 04/17/2012 03:55 PM, Jason Merrill wrote:
I have various thoughts:
It's odd that we still treat 'return' as starting a function body long
after we removed that extension.
Maybe we shouldn't look for a function body if we already have an
initializer and aren't dealing with a function
On 04/17/2012 05:35 PM, Paolo Carlini wrote:
Hi,
I think build_constexpr_constructor_member_initializers is a better
place for that check, since it's already looking at the tree structure.
Indeed. I'm finishing testing the below. Ok if it passes?
... uhm, actually like this seems more correct
On 04/17/2012 06:52 PM, Benjamin De Kosnik wrote:
Found this bug in 4.4 branches, fixed with the following in later
branches:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01616.html
But the test case is useful anyway.
Definitely, thanks! The name of the new testcase seems a bit weird (for
the
the
functions which now get a tsubst_flags_t argument are checked for
error_mark_node and in case early return back error_mark_node itself, as
you requested last time.
As usual, tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
/
/cp
2012-04-17 Paolo Carlini paolo.carl
with a change to the convert_member_func_to_ptr bits.
Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52422
* cp-tree.h (build_addr_func, decay_conversion,
get_member_function_from_ptrfunc
.
/cp
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52363
* call.c (tourney): Add tsubst_flags_t parameter.
(joust): Likewise, use it to handle SFINAE as if pedantic.
(build_user_type_conversion_1, perform_overload_resolution
Hi
On 04/18/2012 01:44 PM, Paolo Carlini wrote:
+ cand = tourney (candidates, tf_warning_or_error);
This seems unlikely to do the right thing; we can get here in both
SFINAE and non-SFINAE situations. In build_user_type_conversion_1 I
think we can get away with checking LOOKUP_COMPLAIN
and
build_user_type_conversion too (besides perform_overload_resolution,
etc) thus convert_like_real can propagate complain down to the former.
This version too passes testing.
Thanks!
Paolo.
///
/cp
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52363
* call.c (tourney
On 04/18/2012 09:00 PM, Jason Merrill wrote:
On 04/18/2012 01:44 PM, Paolo Carlini wrote:
+ cand = tourney (candidates, tf_warning_or_error);
This seems unlikely to do the right thing; we can get here in both
SFINAE and non-SFINAE situations. In build_user_type_conversion_1 I
think we can
Hi,
On 04/18/2012 08:30 PM, Paolo Carlini wrote:
Thus, it seems to me that with above change it's just that we don't have
any hope of fixing latent SFINAE bugs in turney called by
build_user_type_conversion_1 per the above. And, at this time, we don't
have any evidence of such bugs.
We've
Hi,
All,
The enclosed testcases (very close to
ext/mt_allocator/deallocate_global_thread-1.cc) exposes a pattern
where the following sequence is called (when __gthread_active_p is
enabled) :
__gthread_key_create(key,::_M_destroy_thread_key);
__gthread_setspecific(key,
On 04/19/2012 05:02 PM, Laurent Alfonsi wrote:
Well, I don't know mt_allocator enough to know if this is a fix for
real or a quick fix.
I'm pretty sure we could do better. Whether in practice we are going to
do better, any time soon, it's another matter ;)
Paolo.
Hi,
On 04/19/2012 08:45 AM, Paolo Carlini wrote:
@@ -812,7 +816,7 @@ build_list_conv (tree type, tree ctor, int flags)
{
conversion *sub
= implicit_conversion (elttype, TREE_TYPE (val), val,
- false, flags);
+ false, flags
Hi,
tested x86_64-linux, committed.
Thanks,
Paolo.
//
2012-04-20 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/53052
* include/std/type_traits (is_explicitly_convertible): Remove.
* testsuite/20_util/is_explicitly_convertible: Likewise
Hi,
tested x86_64-linux, committed mainline and branch.
Thanks,
Paolo.
///
2012-04-22 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/53067
* include/bits/hashtable_policy.h: Change inheritances to public.
* testsuite/23_containers
Hi,
tested x86_64-linux, committed.
Paolo.
///
2012-04-23 Chris Jefferson ch...@bubblescope.net
PR testsuite/53046
* testsuite/25_algorithms/stable_partition/mem_check.cc: Fix size
of array A.
*
Hi,
this work from Daniel implements the missing
std::is_nothrow_destructible trait and implements LWG 2049. Tested
x86_64-linux, committed to mainline.
Thanks,
Paolo.
2012-04-23 Daniel Krugler daniel.krueg...@googlemail.com
* include/std/type_traits
On 04/23/2012 11:36 PM, Paolo Carlini wrote:
Hi,
this work from Daniel implements the missing
std::is_nothrow_destructible trait and implements LWG 2049. Tested
x86_64-linux, committed to mainline.
Oops. These improvements leads to tidier diagnostics for noexcept15.C
and I have to adjust
for the error. Is
this the way we can fix this or we can do better?
Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2012-04-24 Paolo Carlini paolo.carl...@oracle.com
PR c++/39970
* parser.h (cp_parser::in_template_default_argument_p): Add
Hi,
We should already reject that because it isn't a constant expression;
I don't think we want to bother checking specifically for this case in
the parser as well.
Sure we reject this kind of code at instantiation time. I suspect
submitter bothered filing a PR because other front-end also
On 04/25/2012 01:41 AM, Jason Merrill wrote:
On 04/24/2012 05:24 PM, Paolo Carlini wrote:
Perhaps we aren't checking default arguments unless they're actually
used; a could change that if they aren't dependent.
Your reply reached the mailing list a bit mangled, could you please
clarify
On 04/25/2012 01:41 AM, Jason Merrill wrote:
On 04/24/2012 05:24 PM, Paolo Carlini wrote:
Perhaps we aren't checking default arguments unless they're actually
used; a could change that if they aren't dependent.
Your reply reached the mailing list a bit mangled, could you please
clarify
defaulting which means
non-trivial)
Thus, the below elementary patch appears to work fine (I also double
checked that in such cases the type remains trivial). It's all there is
to it?
Thanks,
Paolo.
/
/cp
2012-04-25 Paolo Carlini paolo.carl...@oracle.com
PR c++/53096
On 04/26/2012 04:15 PM, Jason Merrill wrote:
On 04/25/2012 10:25 AM, Paolo Carlini wrote:
Thus, the below elementary patch appears to work fine (I also double
checked that in such cases the type remains trivial). It's all there is
to it?
Unfortunately, I don't think so; there's a lot of code
(booted ant tested). Let me know if you want it...
Thanks!
Paolo.
2012-04-27 Paolo Carlini paolo.carl...@oracle.com
* call.c (op_error_string, op_error): Rework to avoid memory leaks
due to missing free calls matching the concat calls.
Index: call.c
Hi,
I'm having a look to this PR filed by Daniel, which is again about
SFINAE for combined delete / new expressions, eg a simple example could
be (Daniel provided tens)
templateclass T, class = decltype(::delete ::new T())
auto g(int) - char;
templateclass
auto g(...) - char()[2];
Hi,
On 04/28/2012 05:24 AM, Jason Merrill wrote:
On 04/27/2012 09:42 PM, Paolo Carlini wrote:
In particular about the exact meaning of the FIXME? More generally, is
the issue here matter of compile-time optimization? Like we want to save
work when we actually *know* the type even in template
Hi,
On 04/29/2012 05:17 AM, Jason Merrill wrote:
On 04/28/2012 07:12 AM, Paolo Carlini wrote:
isn't, but clearly can be instantiation dependent. Then, I guess the way
I'm proposing to handle this is by starting some sort of embryonic
instantiation_dependent_expression_p and using it only here
On 04/29/2012 05:42 PM, Paolo Carlini wrote:
Otherwise, I'm attaching something very close to the letter of the
ABI, which passes as-is the testsuite.
Which in any case should use cp_tree_operand_length.
Paolo.
Hi,
contributed by Marc (thanks Again!) and integrated by me. Tested
x86_64-linux, multilib. Committed to mainline.
Thanks,
Paolo.
///
2012-04-29 Marc Glisse marc.gli...@inria.fr
Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/51795
Hi,
Your patch only looks at immediate subexpressions; I believe what the ABI
means is any subexpression, which is why I think something involving
walk_tree might be the way to go.
Ok, I'm going to open code something using walk_tree and quite similar to
for_each_template_parm but checking
Hi again,
On 04/30/2012 07:04 PM, Jason Merrill wrote:
On 04/29/2012 11:42 AM, Paolo Carlini wrote:
This might just be a matter of calling for_each_template_parm and
returning 1 if we see any template parameter.
Good. Today I quickly tried something along these lines (see 'p'
attachment
Hi again,
On 04/29/2012 11:42 AM, Paolo Carlini wrote:
This might just be a matter of calling for_each_template_parm and
returning 1 if we see any template parameter.
Good. Today I quickly tried something along these lines (see 'p'
attachment) and got some fails:
Ah, well. I guess
On 05/01/2012 06:28 AM, Jason Merrill wrote:
On 04/30/2012 07:37 PM, Paolo Carlini wrote:
Thus, my question would be: is something like the below in the right
direction? The alternate possibility I can see, would be basically
redoing a slightly slimmed version of for_each_template_parm
Hi,
On 05/01/2012 08:02 PM, Jason Merrill wrote:
On 05/01/2012 08:00 AM, Paolo Carlini wrote:
I think either approach would be fine; I lean toward the first, but
changing the name and adding a flag for clarity. Changing the walking
behavior based on fn being null is too subtle.
Agreed
On 05/01/2012 10:23 PM, François Dumont wrote:
unordered_multilmap test added, attached patch applied to 4.7 branch
and trunk.
This bug was not so difficult to fix. It would even have been quite
easy to detect with a good test coverage tool showing that not all
possible path had been tested
On 05/01/2012 10:06 PM, Paolo Carlini wrote:
I'm not 100% sure to understand the last two comments. I'm removing
completely the latter cases and changing the former like the below.
Note that the way I handle fn in walk_template_parms implies that when
check_types is true then pfd-fn is always
On 05/02/2012 12:39 AM, Jason Merrill wrote:
On 05/01/2012 04:06 PM, Paolo Carlini wrote:
Hmm, this preexisting code seems to assume that any type-dependent
expression must include a direct use of a template parameter, but it
might just have a declaration with dependent type. We should also
On 05/02/2012 01:27 AM, Paolo Carlini wrote:
Note, there is the minor subtlety with checking !fn explicitly: in my
current patch it's redundant because I make sure in the caller that
when check_types is true, any fn accidentally passed by upper caller
as non-null is zeroed. This way
On 05/02/2012 01:46 AM, Jason Merrill wrote:
I think we need to handle FIELD_DECL, too.
A data point I can give you, I put a gcc_assert (TREE_CODE (t) !=
FIELD_DECL) in the default case of the walk_template_parms_r switch, and
it never triggers for the whole testsuite.
Paolo.
Hi,
On 05/02/2012 03:47 AM, Jason Merrill wrote:
On 05/01/2012 08:14 PM, Paolo Carlini wrote:
I think we need to handle FIELD_DECL, too.
Are there hopes that handling FIELD_DECL like FUNCTION_DECL and VAR_DECL
(besides the DECL_LANG_SPECIFIC check) would work?
I would think so.
Ok, if we
On 05/02/2012 05:01 AM, Paolo Carlini wrote:
Anyway, the attached appear to also pass the testsuite, I could test
it more completely tomorrow. If the FIELD_DECL bits seem safe to
have... ;)
Now fully booted and tested.
I also booted and tested a variant, attached, which changes
Hi,
On 05/01/2012 11:01 PM, Paolo Carlini wrote:
Well, not really. The first time walk_template_parms_r is called, t is a
SIZEOF_EXPR which remains unhandled, the function returns NULL_TREE. The
second time, t is a COMPONENT_REF, thus !TYPE_P (t) is true, TREE_TYPE
is NULL, the function
Hi,
Vincenzo reported today that the work done by Roberto on devirtualizing
final methods, doesn't cover operators (of all sorts). Thus I prepared
the below, which passes the testsuite on x86_64-linux.
Is it Ok?
Thanks,
Paolo.
/
/cp
2012-05-03 Paolo Carlini
On 05/03/2012 03:27 AM, Paolo Carlini wrote:
Hi,
Vincenzo reported today that the work done by Roberto on
devirtualizing final methods, doesn't cover operators (of all sorts).
Thus I prepared the below, which passes the testsuite on x86_64-linux.
... I have an alternate proposal, which
501 - 600 of 2918 matches
Mail list logo
