, 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 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
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 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
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 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 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 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: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 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 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 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 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 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
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
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)
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
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
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
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
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
"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
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:
[...]
| > | > @@ -379,15 +375,15 @@
| > | > switch (code)
| > | > {
| > | > case INTEGER_TYPE:
| > | > - pp_string (pp, (TYPE_UNSIGNED (t)
| > | > - ? M_(" | > -
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
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 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
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 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
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
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:
|
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
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,
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 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: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: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:
>>
>> 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 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 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 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 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
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 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)
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 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 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 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 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
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
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
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
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
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
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
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 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 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 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: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 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 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 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 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 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
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 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
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: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 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 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: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: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 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 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
at revision 202396. No conflict.
-- Gaby
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
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 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:
| 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
";>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
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
On Fri, Sep 28, 2012 at 8:18 AM, Michael Matz wrote:
>> It is common practice to have
>>
>> struct Q
>> {
>> typedef int E;
>> E getme (int index);
>> };
>
> Easy: I wouldn't make a typedef for Q::E that merely is int. The reason
> is that it makes knowing what getme really returns harder.
On Sun, Sep 30, 2012 at 7:23 PM, Kaz Kojima wrote:
> Oleg Endo wrote:
>> The existing .c files are compiled as C++ already. There was a
>> discussion not long go whether the .c files should be renamed to .cc or
>> not. If I remember correctly, the conclusion was that existing .c files
>> remain
On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
wrote:
> On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
>> Your change on September 30th, breaks the powerpc port because the
>> REPORT_DETAILS value in the enumeration is no longer there, and the
>> rs6000_density_test function w
On Mon, Oct 1, 2012 at 4:37 PM, Michael Meissner
wrote:
> I tracked down some of the other code that previously used REPORT_DETAILS, and
> MSG_NOTE is the new way to do the same thing. This bootstraps and no
> unexpected errors occur during make check. Is it ok to install?
yes -- qualifies as "
On Tue, Oct 2, 2012 at 3:57 AM, Marc Glisse wrote:
> (Forgot libstdc++...)
>
>
> Hello,
>
> here is the patch from PR54686. Several notes:
>
> * I'll have to ask experts if std::abs(unsigned) (yes, a weird thing to do,
> but still) is meant to return a double...
don't we have a core issue about p
On Tue, Oct 2, 2012 at 4:21 AM, Marc Glisse wrote:
> On Tue, 2 Oct 2012, Gabriel Dos Reis wrote:
>
>> On Tue, Oct 2, 2012 at 3:57 AM, Marc Glisse wrote:
>>>
>>> (Forgot libstdc++...)
>>>
>>>
>>> Hello,
>>>
>>> here is t
On Tue, Oct 2, 2012 at 4:31 AM, Richard Guenther
wrote:
> On Mon, Oct 1, 2012 at 8:39 PM, Gabriel Dos Reis
> wrote:
>> On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
>> wrote:
>>> On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
>>>> Yo
On Tue, Oct 2, 2012 at 8:07 AM, Marc Glisse wrote:
>>> The library installed by the system was compiled with g++, and is then
>>> used
>>> with clang++. If we can avoid installing 2 config.h files to make that
>>> work...
>>
>>
>> Two things:
>> 1. that is clearly a clang problem. I don't think
On Tue, Oct 2, 2012 at 9:34 AM, Daniel Krügler
wrote:
> 2012/10/2 Marc Glisse :
>> Here I am talking of a library issue: the wording that says that there are
>> sufficient overloads such that integer types call the double version of math
>> functions. It is fairly obvious that it doesn't apply to
On Tue, Oct 2, 2012 at 8:07 AM, Marc Glisse wrote:
> Or do you mean:
> always call __builtin_llabs (whether we have an llabs or not), and let the
> compiler replace it with either (x<0)?-x:x or a library call (I assume it
> never does that unless it has seen a corresponding declaration)?
See wha
On Tue, Oct 2, 2012 at 12:14 PM, Jakub Jelinek wrote:
> On Tue, Oct 02, 2012 at 10:12:38AM -0700, Ian Lance Taylor wrote:
>> On Tue, Oct 2, 2012 at 8:22 AM, Uros Bizjak wrote:
>> >
>> > On a related issue, it looks to me that the compiler itself should be
>> > compiled with -funwind-tables, other
On Tue, Oct 2, 2012 at 1:53 PM, Marc Glisse wrote:
>> See what we did in c/cmath and c_global/cmath.
>
>
> Note that llabs is quite different from asin.
Is asin the function you took out of c/cmath?
> __builtin_llabs generates an
> ABS_EXPR, which will later be expanded either to a special ins
On Sat, Oct 13, 2012 at 12:44 PM, Lawrence Crowl wrote:
>> Thus, please re-use or follow existing concepts.
>
> Both are existing concepts. What I proposed is a common technique
> for avoiding the cost of dynamic_cast when down casting in a class
> hierarchy. Both concepts will work. I propose
On Wed, Oct 17, 2012 at 6:26 AM, Manuel López-Ibáñez
wrote:
> On 17 October 2012 11:55, Dodji Seketeli wrote:
>> Hello Manuel,
>>
>> Let's CC Gaby on this one as well.
>>
>> Manuel López-Ibáñez writes:
>>
>>> The problem is that the macro unwinder code is changing the original
>>> diagnostic typ
On Sun, Nov 4, 2012 at 2:36 PM, Gerald Pfeifer wrote:
> On Sun, 4 Nov 2012, Jonathan Wakely wrote:
>>> http://gcc.gnu.org/onlinedocs/libstdc++/ext/pb_ds/acks.html
>>> - http://starship.python.net/crew/aaron_watters/kjbuckets/
>>>broken links
>>>
>>> http://gcc.gnu.org/onlinedocs/libstdc++/ext
On Fri, Nov 9, 2012 at 5:08 AM, Florian Weimer wrote:
> On 11/08/2012 08:43 PM, Lubos Lunak wrote:
>
>> The patch implements an attribute for marking types for which gcc cannot
>> on
>> its own issue warnings about unused variables (e.g. because the ctor is
>> external), but for which such a war
On Fri, Nov 16, 2012 at 8:51 AM, Jason Merrill wrote:
> Would it work to just do a cp_parser_commit_to_tentative_parse after we see
> the '='?
I like that solution better.
-- Gaby
Now that we can actually declare a variable as `auto', it becomes
important to be precise in our terminology when diagnosing invalid
uses of variables with automatic storage -- especially if the variable
isn't declared 'auto'.
Applied to trunk.
-- Gaby
2012-11-
1 - 100 of 594 matches
Mail list logo
