Coutantccout...@google.com
c++ runtime libs Paolo Carlini paolo.carl...@oracle.com
-c++ runtime libs Gabriel Dos Reisg...@integrable-solutions.net
c++ runtime libs Ulrich Drepper drep...@gmail.com
c++ runtime libs Benjamin De Kosnik
";>Gabriel Dos Reis.
var-template
This branch is for implementation work on
! variable template for C++. It is maintained by
! mailto:g...@gcc.gnu.org";>Gabriel Dos Reis.
cilkplus
This branch is for the development of
--- 542,556
c++-concepts
Andrew Sutton writes:
| I added a new macro to replace the use of TREE_TYPE to get
| constraints. It's called TEMPLATE_PARMS_CONSTRAINTS. Patch attached:
|
| 2013-09-10 Andrew Sutton
| * gcc/cp/cp-tree.h (TEMPLATE_PARMS_CONSTRAINTS): New.
| * gcc/cp/parser.c (cp_parser_template_declar
On Mon, Sep 9, 2013 at 12:54 PM, Mike Stump wrote:
> On Sep 9, 2013, at 10:25 AM, Gabriel Dos Reis
> wrote:
>> On Mon, Sep 9, 2013 at 11:16 AM, Mike Stump wrote:
>>> You've failed to understand g++. Please seek to understand the compiler,
>>> before
Andrew Sutton writes:
| The last merge didn't compile for me. Apparently some pretty printing
| functions have disappeared that were being called in the concept
| stuff. This patch just replaces the broken calls to pp_cxx_type_id
| with pp->type_id.
|
| Ok to commit?
yes, please. Sorry for tha
On Mon, Sep 9, 2013 at 11:16 AM, Mike Stump wrote:
> You've failed to understand g++. Please seek to understand the compiler,
> before you weigh in.
Gee Mike, see a medical assistance for your and our benefits.
-- Gaby
at revision 202396. No conflict.
-- Gaby
On Sun, Sep 8, 2013 at 3:26 PM, Paolo Carlini wrote:
> Hi all, Gaby,
>
> I was having a look to c++/58363 and besides the main issue, that is we
> probably want to help the user and tell him/her something about destructors,
> etc, I noticed that we aren't able to pretty print the pseudo destructor
On Mon, Sep 9, 2013 at 7:49 AM, Paolo Carlini wrote:
> Hi all, hi Gaby,
>
> thus a more sensible try at fixing this issue:
> function.c:do_warn_unused_parameter uses "%q+D" for the error call. That
> means that cp/error.c:cp_printer does:
>
> if (set_locus && t != NULL)
> *text->locus = loca
On Mon, Sep 9, 2013 at 5:41 AM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2013 at 12:38:46PM +0200, Paolo Carlini wrote:
>> On 09/09/2013 11:37 AM, Richard Biener wrote:
>> >That said, grepping for %q+D reveals quite some uses and it looks like
>> >all of them expect the location being used to be tha
On Mon, Sep 9, 2013 at 5:38 AM, Paolo Carlini wrote:
> On 09/09/2013 11:37 AM, Richard Biener wrote:
>>
>> That said, grepping for %q+D reveals quite some uses and it looks like
>> all of them expect the location being used to be that of the decl passed
>> to the diagnostic call, not some random o
On Mon, Sep 9, 2013 at 5:13 AM, Richard Biener wrote:
> On Mon, 9 Sep 2013, Paolo Carlini wrote:
>
>> On 09/09/2013 12:04 PM, Richard Biener wrote:
>> > On Mon, 9 Sep 2013, Jakub Jelinek wrote:
>> >
>> > > On Mon, Sep 09, 2013 at 11:45:08AM +0200, Richard Biener wrote:
>> > > > Well, in this case
On Mon, Sep 9, 2013 at 5:04 AM, Richard Biener wrote:
> On Mon, 9 Sep 2013, Jakub Jelinek wrote:
>
>> On Mon, Sep 09, 2013 at 11:45:08AM +0200, Richard Biener wrote:
>> > Well, in this case the patch should IMHO be a no-op.
>> >
>> > - warning (OPT_Wunused_parameter, "unused parameter %q+D",
On Mon, Sep 9, 2013 at 4:46 AM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2013 at 11:45:08AM +0200, Richard Biener wrote:
>> Well, in this case the patch should IMHO be a no-op.
>>
>> - warning (OPT_Wunused_parameter, "unused parameter %q+D", decl);
>> + warning_at (DECL_SOURCE_LOCATION (de
On Mon, Sep 9, 2013 at 4:19 AM, Marc Glisse wrote:
> On Mon, 9 Sep 2013, Richard Biener wrote:
>
>> On Sat, Sep 7, 2013 at 11:00 PM, Marc Glisse wrote:
>>>
>>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>>
On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
>
>
> Now flag_check_new shou
On Mon, Sep 9, 2013 at 4:06 AM, Richard Biener
wrote:
> On Sat, Sep 7, 2013 at 11:00 PM, Marc Glisse wrote:
>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>
>>> On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
Now flag_check_new should probably disable this optimization…
>>>
>>>
>>> Yes, thi
Andrew Sutton writes:
| Ok to commit? Attached is the doc fix patch. I'll send the TREE_TYPE
| patch shortly.
Yes, please -- that is what Jason earlier. Let me know when youve
committed so that I can synchronize with trunk.
-- Gaby
On Sun, Sep 8, 2013 at 9:58 AM, Jan Hubicka wrote:
>> On Sun, Sep 8, 2013 at 9:23 AM, Jan Hubicka wrote:
>> > Hi,
>> > this patch adds API for varpool node removal/insertion hooks that are
>> > fully symmetric
>> > to cgraph code.
>> >
>> > Bootstrapped/regtested x86_64-linux after working aroun
On Sun, Sep 8, 2013 at 9:23 AM, Jan Hubicka wrote:
> Hi,
> this patch adds API for varpool node removal/insertion hooks that are fully
> symmetric
> to cgraph code.
>
> Bootstrapped/regtested x86_64-linux after working around PR58340, will commit
> it shortly.
Hi Honza,
I can't bootstrap trunk
On Sun, Sep 8, 2013 at 8:59 AM, Paolo Carlini wrote:
> Hi Gaby,
>
>
> On 09/08/2013 03:41 PM, Gabriel Dos Reis wrote:
>>
>> On Sun, Sep 8, 2013 at 8:00 AM, Paolo Carlini
>> wrote:
>>>
>>> Hi all, Gaby,
>>>
>>> in this bug Man
On Sun, Sep 8, 2013 at 8:00 AM, Paolo Carlini wrote:
> Hi all, Gaby,
>
> in this bug Manuel noticed that the zeros in the diagnostic lines of the
> form:
>
> :0:0:
>
> don't provide useful information. Thus the below just avoids printing the
> zeros basing directly on the file name: admittedl
On Sun, Sep 8, 2013 at 4:36 AM, Paolo Carlini wrote:
> .. it's r202296 aka bootstrap/58340, Jeff is already on it.
Thanks for the detective work, Paolo.
-- Gaby
On Sat, Sep 7, 2013 at 2:46 PM, Mike Stump wrote:
>
> On Sep 7, 2013, at 12:37 PM, Gabriel Dos Reis
> wrote:
>
>> On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
>>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>>
>>>> On Sep 7, 2013, at 3:33 AM, Ma
On Sat, Sep 7, 2013 at 3:41 PM, Paolo Carlini wrote:
> -- Caroline,
>
> something seems wrong with the patch, I can't build anymore. Something in
> libvtv/testsuite:
>
> make[4]: Entering directory
> `/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libvtv/testsuite'
> Makefile:369: *
On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
> On Sat, 7 Sep 2013, Mike Stump wrote:
>
>> On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
>>>
>>> this patch teaches the compiler that operator new, when it can throw,
>>> isn't allowed to return a null pointer.
>>
>>
>> You sure:
>>
>> @item -
On Sat, Sep 7, 2013 at 12:59 PM, Marc Glisse wrote:
>> Furthermore, I do think that the compiler should have special nodes
>> for both standard placement new and the global operator new functions,
>
>
> That's one way to do it. Since this is the first time I look at those, I
> don't really see th
On Sat, Sep 7, 2013 at 11:42 AM, Marc Glisse wrote:
> On Sat, 7 Sep 2013, Marc Glisse wrote:
>
>> this patch teaches the compiler that operator new, when it can throw,
>> isn't allowed to return a null pointer. Note that it doesn't work for
>> placement new (that one may have to be handled in the
On Sat, Sep 7, 2013 at 6:44 AM, Basile Starynkevitch
wrote:
> On Sat, 2013-09-07 at 12:33 +0200, Marc Glisse wrote:
>> Hello,
>>
>> this patch teaches the compiler that operator new, when it can throw,
>> isn't allowed to return a null pointer. Note that it doesn't work for
>> placement new (that
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-09-04 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::simple_type_specifier): Now
a virtual member function.
(pp_simple_type_specifier): Remove.
(pp_c_type_specifier): Likewise
Same topic as 19/n.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-09-03 Gabriel Dos Reis
c/
* c-objc-common.c (c_tree_printer): Tidy.
c-family/
* c-pretty-print.h (c_pretty_printer::type_id): Now a virtual
member function.
(c_pretty_printer
Eric Botcazou writes:
| > It seems the patch needs a couple of minor amendments to work with Darwin -
| > and I've added an updated version to the PR which passes bootstrap and make
| > check-ada on x86_64-darwin12. Iain
|
| Thanks, here is the final patch I just installed.
Thanks!
-- Gaby
Eric Botcazou writes:
| > This patch fixes that by introducing GXX_LINK which is GCC_LINK except
| > that CXX (e.g. xg++) instead of CC (e.g. xgcc) is invoked.
| >
| > Eric, are there other executables that need to be linked with GXX_LINK
| > too but aren't triggered yet?
|
| Yes, all not cover
Most of declaration pretty printing functions.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-08-30 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::declaration): Now a virtual
member function.
(c_pretty_printer::declaration_specifiers
On Fri, Aug 30, 2013 at 10:37 AM, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
>> > Well, it was a wrong decision then. For some smaller types writing manual
>> > marker might be a sensible thing, or for some extra complicated
>> > constructs. But here we
On Fri, Aug 30, 2013 at 10:21 AM, Michael Matz wrote:
> Hi,
>
> On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
>
>> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
>>
>> >> I thought the principle that was acquired was that gengtype shouldn't
>&
On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 08:58:43AM -0500, Gabriel Dos Reis wrote:
>> On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
>>
>> > And the manual GTY markers are so not maintainable in the long run,
>> >
On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
> And the manual GTY markers are so not maintainable in the long run,
> gengtype or something else really needs to be taught to create them
> automatically.
I thought the principle that was acquired was that gengtype shouldn't
be improved to s
On Thu, Aug 29, 2013 at 4:06 PM, Adam Butcher wrote:
> On 29.08.2013 21:59, Gabriel Dos Reis wrote:
>>
>> On Thu, Aug 29, 2013 at 3:57 PM, Adam Butcher
>> wrote:
>>>
>>> From: abutcher
>>>
>>> * e
On Thu, Aug 29, 2013 at 3:57 PM, Adam Butcher wrote:
> From: abutcher
>
> * error.c (dump_lambda_function): New function, dependent on ...
> (dump_substitution): ... this new function, factored out of ...
> (subst_to_string): ... here and ...
> (dump_function_decl)
l): ... here. Updated to early-out with call to
> dump_lambda_function after determining template bindings.
> ---
> Hi Gaby,
>
> On 29.08.2013 18:04, Adam Butcher wrote:
>> On 29.08.2013 16:25, Gabriel Dos Reis wrote:
>> >
>> > Document the new functions
On Thu, Aug 29, 2013 at 9:20 AM, Adam Butcher wrote:
> * error.c (dump_lambda_function): New function, dependent on ...
> (maybe_dump_template_bindings): ... this new function, factored out of
> ...
> (dump_function_decl): ... here. Updated to early-out with call t
On Tue, Aug 27, 2013 at 7:54 PM, Adam Butcher wrote:
> * error.c (dump_function_decl): Use standard diagnostic flow to dump a
> lambda diagnostic, albeit without stating the function name or
> duplicating the parameter spec (which is dumped as part of the type).
> R
On Mon, Aug 26, 2013 at 8:17 PM, Jason Merrill wrote:
> On 08/26/2013 10:45 AM, Gabriel Dos Reis wrote:
>>
>> Hmm, let's not make it a default. Replacing global operator new (e.g. for
>> tracing purposes) is a valid C++ programming idiom.
>
>
> Absolute
On Mon, Aug 26, 2013 at 7:58 PM, Jason Merrill wrote:
> On 08/26/2013 11:21 AM, Jan Hubicka wrote:
>>
>> Our default behaviour special case inline functions that are always
>> AVAIL_AVAILABLE and, via decl_replaceable_p, also any COMDAT (that may be
>> for
>> functions since all COMDATs are also i
On Mon, Aug 26, 2013 at 9:32 AM, Jan Hubicka wrote:
>>
>> modify ALL_LINKERFLAGS or BUILD_LINKERFLAGS?
>
> configure --with-build-config=bootstrap-lto . You need plugin enabled
> buinutils for that.
> I think there however should be a lot easier way to reproduce it by just
> dropping some reall
On Mon, Aug 26, 2013 at 9:07 AM, Jason Merrill wrote:
> On 08/22/2013 12:45 PM, Gabriel Dos Reis wrote:
>>
>> If the user-supplied operator new returns &a, then it must
>> also ensure that 'a' is not used anywhere else -- e.g. I you can't
>> do lv
On Mon, Aug 26, 2013 at 9:32 AM, Jan Hubicka wrote:
>> On Mon, Aug 26, 2013 at 9:00 AM, Jan Hubicka wrote:
>> >> On Mon, Aug 26, 2013 at 7:24 AM, Jan Hubicka wrote:
>> >> > Hi,
>> >> > it seems to be couple weeks I am not able to compile big ltrans unit
>> >> > with -fdump-tree-all
>> >> > beca
On Mon, Aug 26, 2013 at 9:38 AM, Jan Hubicka wrote:
>> On 08/22/2013 12:45 PM, Gabriel Dos Reis wrote:
>> >If the user-supplied operator new returns &a, then it must
>> >also ensure that 'a' is not used anywhere else -- e.g. I you can't
>> >
On Mon, Aug 26, 2013 at 9:00 AM, Jan Hubicka wrote:
>> On Mon, Aug 26, 2013 at 7:24 AM, Jan Hubicka wrote:
>> > Hi,
>> > it seems to be couple weeks I am not able to compile big ltrans unit with
>> > -fdump-tree-all
>> > because the compiler eventually runs out of memory. I think it is one of
On Mon, Aug 26, 2013 at 7:24 AM, Jan Hubicka wrote:
> Hi,
> it seems to be couple weeks I am not able to compile big ltrans unit with
> -fdump-tree-all
> because the compiler eventually runs out of memory. I think it is one of
> your patches
> introducing serious memory leak. Can you, please,
at revision 201992.
There were conflicts with the recent pretty printing patches.
Fixed. (Mostly due to the new concept-specific nodes printing.)
Modulo the asan stuff.
-- Gaby
Paolo Carlini writes:
| Hi Gaby,
|
| bootstrap is currently broken:
|
| /scratch/Gcc/svn-dirs/trunk/gcc/c/c-objc-common.c: In function ‘bool
| c_tree_printer(pretty_printer*, text_info*, const char*, int, bool,
| bool, bool)’:
| /scratch/Gcc/svn-dirs/trunk/gcc/c/c-objc-common.c:123:31: error:
|
Paolo Carlini writes:
| Hi Gaby.
|
| On 08/26/2013 10:42 AM, Gabriel Dos Reis wrote:
| > Same topic as patch 17/n. For more expressing printers.
| > Tested on an x86_64-suse-linux. Applied to mainline.
| Just got this:
|
| /scratch/Gcc/svn-dirs/trunk/gcc/c/c-objc-common.c: In function
Same topic as patch 17/n. For more expressing printers.
Tested on an x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-26 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::unary_expression): Now a
virtual member function.
(c_pretty_printer
On Mon, Aug 26, 2013 at 2:44 AM, Mike Stump wrote:
> but I fear you won't understand this and how it applies.
You must be right. I cannot match the entertaining value of your
message, so you win.
-- Gaby
Same topic as patch 15/n, but postfix_expression.
Tested on an x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-25 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::postfix_expression): Now a
virtual member function.
(pp_postfix_expression
GCC_LINK except
that CXX (e.g. xg++) instead of CC (e.g. xgcc) is invoked.
Eric, are there other executables that need to be linked with GXX_LINK
too but aren't triggered yet?
Thanks,
-- Gaby
ada/
2013-08-25 Gabriel Dos Reis
* gcc-interface/Makefile.in (GXX_LINK): New. Sa
Same topic as patch 14/n. This time for primary_expression.
-- Gaby
2013-08-25 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::primary_expression): Now a
virtua member function.
(pp_primary_expression): Adjust.
(pp_c_primary_expression
"Joseph S. Myers" writes:
[...]
| > | > @@ -379,15 +375,15 @@
| > | > switch (code)
| > | > {
| > | > case INTEGER_TYPE:
| > | > - pp_string (pp, (TYPE_UNSIGNED (t)
| > | > - ? M_(" | > -
On Sun, Aug 25, 2013 at 10:38 AM, Jan Hubicka wrote:
>> On 08/24/2013 05:18 AM, Jan Hubicka wrote:
>> >In the next step I would like to introduce the
>> >DECL_CPP_CONSTRUCTOR/DESTRUCTOR macro.
>> >The catch I run into is that these flags are tested on TEMPLATE_DECL so the
>> >middle-end
>> >macr
"Joseph S. Myers" writes:
| On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
|
| > Instead of defining the same macro several times in different
| > translation units, we can just make it a function and use it where
| > needed.
|
| Have you made sure that po/exgettext still ex
Instead of defining the same macro several times in different
translation units, we can just make it a function and use it where
needed.
Tested on an x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-25 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer
Same as previous topic; for id_expression.
-- Gaby
2013-08-24 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::id_expression): Now a
virtual function.
(pp_c_id_expression): Remove.
(pp_id_expression): Adjust.
* c-pretty-print.c
Most of the specialized pretty printing functions from the C-family
languages are really virtual functions. This patchlet makes the first
explicitly so.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
c-family/
2013-08-24 Gabriel Dos Reis
* c-pretty-print.h
On Fri, Aug 23, 2013 at 10:34 PM, Mike Stump wrote:
> On Aug 23, 2013, at 5:53 PM, Gabriel Dos Reis
> wrote:
>> If you quoted the standard to back up your assertions, I would have been
>> able to "feel free to point this out" :-)
>>
>> The thing is I am
On Fri, Aug 23, 2013 at 7:32 PM, Mike Stump wrote:
> On Aug 22, 2013, at 7:16 PM, Gabriel Dos Reis
> wrote:
>> But even so, in light of this, I don't think you original assertion is
>> definitive.
>
> Nothing is ever definitive. Now, if you want to say I quoted
ng it easier to search for a pretty printer's output
buffer access.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-08-23 Gabriel Dos Reis
* diagnostic.c (diagnostic_set_caret_max_width): Use pp_buffer.
* gimple-pretty-print.c (gimple_dump_bb_buff)
This patchlet is an easy low hanging fruit in the pile of local patches
I have. It turns old style emulation of inline functions into real inline
functions.
Tested on x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-23 Gabriel Dos Reis
* pretty-print.h
On Thu, Aug 22, 2013 at 8:51 PM, Mike Stump wrote:
> On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis
> wrote:
>> I think we must distinguish what is "wrong" according to the standards
>> we are implementing from what is "wrong" from a QoI point of view
On Thu, Aug 22, 2013 at 6:16 PM, Mike Stump wrote:
> On Aug 22, 2013, at 2:28 PM, Gabriel Dos Reis
> wrote:
>> On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote:
>>> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
>>> wrote:
>>>>> I.e. can I have
On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote:
> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
> wrote:
>>> I.e. can I have something like
>>>
>>> int a;
>>> test()
>>> {
>>> int *b=new (int);
>>> }
>>>
>
On Thu, Aug 22, 2013 at 11:08 AM, Jan Hubicka wrote:
>>
>> This should be a C++ front-end bug. The specific operator new
>> from used in this placement-new should be folded,
>> even if -fno-inline. Jason, is this something easily fixable?
>>
>> After overload resolution, we know exactly which o
On Thu, Aug 22, 2013 at 11:16 AM, Jan Hubicka wrote:
>> On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka wrote:
>> >> >
>> >> > So the existing program needs to overwrite libsup++ symbol like we do
>> >> > with malloc?
>> >> > Of course with user defineed malloc function we should not propagate
>>
On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka wrote:
>> >
>> > So the existing program needs to overwrite libsup++ symbol like we do with
>> > malloc?
>> > Of course with user defineed malloc function we should not propagate the
>> > attribute,
>> > but I think we could have it when we end up ca
On Thu, Aug 22, 2013 at 10:38 AM, Alexander Monakov wrote:
> On Thu, 22 Aug 2013, Jan Hubicka wrote:
>
>> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > > > - I would like to recall issue if we can make NEW_EXPR annotated with
>> > > >M
On Thu, Aug 22, 2013 at 10:21 AM, Jan Hubicka wrote:
>> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > > - I would like to recall issue if we can make NEW_EXPR annotated with
>> > >MALLOC attribute. Without it, it is basically impossible to track
>&
On Thu, Aug 22, 2013 at 9:56 AM, Jakub Jelinek wrote:
> On Thu, Aug 22, 2013 at 09:53:35AM -0500, Gabriel Dos Reis wrote:
>> On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov
>> wrote:
>> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> >> > - I wo
On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov wrote:
> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > - I would like to recall issue if we can make NEW_EXPR annotated with
>> >MALLOC attribute. Without it, it is basically impossible to track
>> >any
On Thu, Aug 22, 2013 at 8:19 AM, Jan Hubicka wrote:
>
> Hi,
> this patch started as a work to make cxa_pure_virtual as noreturn. This
> is good for middle-end to figure out that it should not care about
> devirtualizing to it and it should devirtualize speculative where there
> is only one varian
left in tree-pretty-printer.c , and one in cp/error.c.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-08-22 Gabriel Dos Reis
* pretty-print.h (output_buffer::output_buffer): Declare.
(pretty_printer::pretty_printer): Likewise.
(pp_construct): Remo
On Tue, Aug 20, 2013 at 8:59 AM, Tom Tromey wrote:
> This converts the C++ front end.
>
> This renames g++spec.o to cp/g++spec.o for uniformity.
> This lets us remove an explicit rule.
>
> This patch does not remove various *_H macros from cp/Make-lang.in.
> These are still needed by ObjC++. They
, it becomes a problem.
Tested on an x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-20 Gabriel Dos Reis
* error.c (pp_ggc_formatted_text): New.
(type_as_string): Use it in lieu of pp_formatted_text.
(type_as_string_translate): Likewise.
(expr_as_string
On Mon, Aug 19, 2013 at 6:04 AM, Paolo Carlini wrote:
> Hi,
>
> was having a look to c++/58187 (looks like we are missing a lookup) and
> noticed this. It seems obvious to me, I'll commit it later today barring
> objections.
OK.
>
> Tested x86_64-linux.
>
> Thanks,
> Paolo.
>
> /
The c++-concepts branch was synchronized with trunk at revision 201834.
-- Gaby
On Sat, Aug 17, 2013 at 7:56 PM, Jason Merrill wrote:
>> I do not know if one can do
>> something like having automatic variable of class A and use placement new
>> to change it to class B.
>
>
> This is something of a grey area in the standard, with a few defect reports
> yet to be resolved. I
Same topic as previous patch in this series.
-- Gaby
2013-08-16 Gabriel Dos Reis
* sched-vis.c (rtl_slim_pp_initialized): Remove.
(rtl_slim_pp): Likewise.
(init_rtl_slim_pretty_print): Likewise.
(dump_value_slim): Don't call it. Use local pretty pr
On Wed, Aug 14, 2013 at 9:49 AM, Uros Bizjak wrote:
> On Wed, Aug 14, 2013 at 4:36 PM, Uros Bizjak wrote:
>> On Wed, Aug 14, 2013 at 4:34 PM, Gabriel Dos Reis
>> wrote:
>>> On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote:
>>>>
>>>> O
On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote:
>
> On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
> wrote:
> > I agree 'const void*' is preferable, and all the places you mention should
> > be covered too.
>
> I already installed my original
On Wed, Aug 14, 2013 at 9:07 AM, Jason Merrill wrote:
> On 08/12/2013 08:34 PM, Adam Butcher wrote:
>>
>> Currently it is the implicit function template code in pt.c that updates
>> this; specifically add_implicit_template_parms and
>> finish_fully_implicit_template.
>>
>> It is queried by the par
On Fri, Aug 9, 2013 at 4:28 AM, Paolo Carlini wrote:
> Hi,
>
>
> On 08/09/2013 10:46 AM, Gabriel Dos Reis wrote:
>>
>> I think we should find ways to have the pretty printer in the diagnostic
>> framework stop trying to redo most of the work done by the type checker
On Fri, Aug 9, 2013 at 2:13 AM, Paolo Carlini wrote:
> .. another thought I had, less esoteric ;) is the following: we use tf_none
> for two rather different reasons: for SFINAE and to avoid recursive Error
> routines calls, when we call tsubst (... tf_none, ...) from
> dump_template_bindings.
>
>
On Fri, Aug 9, 2013 at 2:33 AM, Florian Weimer wrote:
> On 08/09/2013 09:28 AM, Paolo Carlini wrote:
>
>> I see. You know, I was trying to figure out the logic other compilers -
>> two of them, actually - are following, because the really appear to sfinae
>> away infinite recursions. Was trying to
On Fri, Aug 9, 2013 at 2:13 AM, Florian Weimer wrote:
> On 08/09/2013 08:43 AM, Paolo Carlini wrote:
>
>>> Yes, that is intended. Changing that could mean that the meaning of
>>> code depends on what max depth the user selected.
>>
>>
>> Indeed. Yesterday I wondered what would happen if the front
On Thu, Aug 8, 2013 at 6:40 PM, Jason Merrill wrote:
> On 08/08/2013 03:54 PM, Paolo Carlini wrote:
>>
>> the really interesting one is decltype28.C, which we don't reject
>> anymore, we simply accept it. What is happening is that the overload
>> which leads to excessive template instantiation dep
trunk was merged into c++-concepts branch at revision 201560.
I resolved some conflicts in cp caused by recent merges and ongoing work
on trunk.
-- Gaby
On Mon, Aug 5, 2013 at 6:24 AM, Martin Jambor wrote:
[…]
>> > Note that as per
>> > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01365.html
>> > we'll use "pass_manager" rather than "pipeline", so this would look
>> > like:
>> > pass_manager &get_passes () { gcc_assert (passes_); return *passe
Same topics as from previous patch; this time for the graphiz outputter.
-- Gaby
2013-08-05 Gabriel Dos Reis
* graph.c (init_graph_slim_pretty_print): Remove.
(print_graph_cfg): Do not call it. Use local pretty printer.
(start_graph_dump): Likewise.
Index: gcc
This patch stops the gimple printer from using global pretty printers.
Applied to trunk.
-- Gaby
2013-08-05 Gabriel Dos Reis
* gimple-pretty-print.c (buffer): Remove.
(initialized): Likewise.
(maybe_init_pretty_print): Likewise.
(print_gimple_stmt): Do
This patchlet has print_c_tree use non-static local variable for its
pretty-printer object. The code is much simpler that way.
(A follow up will add destructor so we stop leaking storage.)
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-08-05 Gabriel Dos Reis
* c
This patchlet makes the asan module stop using a global pretty printer.
As a result, the code is cleaner that way -- and this is in preparation
of having pretty printers initialize themselves through constructors.
-- Gaby
2013-08-05 Gabriel Dos Reis
* asan.c (asan_pp): Remove
1 - 100 of 594 matches
Mail list logo
