Right -- gdb does not know the complete type of std::cout and
std::cerr -- try the following program with -g and invoke print, or <<
in the debugger -- see what you will get:
#include
using namespace std;
class A {
public:
int i;
};
__attribute__((noinline)) void print (ostream& os, const A& a)
On 11/20/12, Xinliang David Li wrote:
> one minus -- less gdb friendly.
Do you mean that gdb does not handle the stream expressions
or something else?
>
> David
>
> On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl wrote:
>> On 11/20/12, Diego Novillo wrote:
>>> On Nov 20, 2012 Basile Starynkevi
one minus -- less gdb friendly.
David
On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl wrote:
> On 11/20/12, Diego Novillo wrote:
>> On Nov 20, 2012 Basile Starynkevitch wrote:
>> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>> > > function (FILE *, item_to_dump, formatting
On 11/20/12, Diego Novillo wrote:
> On Nov 20, 2012 Basile Starynkevitch wrote:
> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
> > > function (FILE *, item_to_dump, formatting)
> > > function (item_to_dump, formatting)
> >
> > Since we have switched to C++, it would be really
On Tue, Nov 20, 2012 at 2:32 PM, Basile Starynkevitch
wrote:
> On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
> []
>> >> All of these functions come in two forms.
>> >>
>> >> function (FILE *, item_to_dump, formatting)
>> >> function (item_to_dump, formatting)
>
> Si
On Tue, Nov 20, 2012 at 2:34 PM, Xinliang David Li wrote:
> class bitmap {
>public:
> void print_me (print_flags flags = print_pretty, FILE *stream = stderr);
> ...
> };
This is fine and all, but most of our objects are pointers and many
times we are dealing with NULL pointers. W
On Tue, Nov 20, 2012 at 12:03 PM, Andrew MacLeod wrote:
> On 11/14/2012 08:12 PM, Lawrence Crowl wrote:
>>
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> We propose to provide several function overload sets, as below.
>>
>>
>> dump_pretty
>>
>> This function ove
In graphds.h, struct graph has a field "htab_t indices".
As near as I can tell, it is completely unused. It builds
and tests fine with the field #if'd out.
Shall I remove the field?
--
Lawrence Crowl
On Tue, Nov 20, 2012 at 11:19:41AM -0800, Lawrence Crowl wrote:
> On 11/19/12, Diego Novillo wrote:
> > On Nov 19, 2012 Michael Matz wrote:
> > > So, yes, the larger layouting should be determined by name of the
> > > dump function. A flag argument might look nice from an interface
> > > design
On 11/20/2012 02:22 AM, Senthil Kumar Selvaraj wrote:
> Hi all,
>
> For the AVR target, the FP register spans two registers, yet the DWARF
> location information (DW_AT_location) for a local variable refers to only
> one
> of them.
>
> Looking at the code, I found that based_loc_descr in dw
This can be simplified further -- there should be one print method for
every class/struct entity as a member method
enum print_flags
{
print_pretty = 0x1,
print_decl_only = 0x2,
print_raw = 0x4,
..
};
class bitmap {
public:
void print_me (print_flags flags = print_pretty, FI
On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
[]
> >> All of these functions come in two forms.
> >>
> >> function (FILE *, item_to_dump, formatting)
> >> function (item_to_dump, formatting)
Since we have switched to C++, it would be really nice to have dump functio
On Tue, Nov 20, 2012 at 7:23 AM, Gerald Pfeifer wrote:
> Hi Sri,
>
> On Tue, 13 Nov 2012, Sriraman Tallam wrote:
>> I have added a release note for Function Multiversioning which is
>> checked into trunk. Please review.
>
> Index: changes.html
>
On 11/20/12, Andrew MacLeod wrote:
> On 11/14/2012 08:12 PM, Lawrence Crowl wrote:
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> We propose to provide several function overload sets, as below.
>>
>>
>> dump_pretty
>>
>> This function overload set provides the b
On 11/19/12, Diego Novillo wrote:
> On Nov 19, 2012 Michael Matz wrote:
> > So, yes, the larger layouting should be determined by name of the
> > dump function. A flag argument might look nice from an interface
> > design perspective, but it's harder to use in the debugger.
>
> As long as all th
On 11/14/2012 08:12 PM, Lawrence Crowl wrote:
Diego and I seek your comments on the following (loose) proposal.
We propose to provide several function overload sets, as below.
dump_pretty
This function overload set provides the bulk of the printing.
They will use the existing prett
On 11/14/2012 08:13 PM, Lawrence Crowl wrote:
Diego and I seek your comments on the following (loose) proposal.
We propose a simplified form using new build helper classes ssa_seq
and ssa_stmt that would allow the above code to be written as
follows.
ssa_seq q;
ssa_stmt t = q.stmt (NE_EXPR, s
Hi,
On Tue, 20 Nov 2012, Steven Bosscher wrote:
> On Mon, 19 Nov 2012 18:31:27 -0800, Lawrence Crowl wrote:
>
> > Richi, ping?
>
> Just guessing... isn't he simply out on Honeymoon?
Yes, he'll be back next week.
Ciao,
Michael.
Hi Sri,
On Tue, 13 Nov 2012, Sriraman Tallam wrote:
> I have added a release note for Function Multiversioning which is
> checked into trunk. Please review.
Index: changes.html
===
+ Function Multiversioning Support with G++:
Is
> If the driver can be sure that an executable is being compiled
> (which is a challenge in general case, but simple cases --
> compilation of GCC testsuites -- can be accommodated)
I totally agree here that it could be a challenge. Also it could be
quite confusing: if the user wants to get assemb
Count another vote for getting rid of GC.
Bernd
Hi all,
For the AVR target, the FP register spans two registers, yet the DWARF
location information (DW_AT_location) for a local variable refers to only one
of them.
Looking at the code, I found that based_loc_descr in dwar2out.c, which handles
base+offset based location descriptions, gets
On Mon, 19 Nov 2012 18:31:27 -0800, Lawrence Crowl wrote:
> Richi, ping?
Just guessing... isn't he simply out on Honeymoon?
Those functions were introduced to handle alias sets for spill slots
better, but IIRC this never worked properly. The whole path through
dse_step2_spill is dead.
The code
(sorry for breaking threads... re.
http://gcc.gnu.org/ml/gcc/2012-11/msg00304.html)
On Tue, 20 Nov 2012 09:57:35 +0100, Eric Botcazou wrote:
> > I wouldn't jump to that conclusion too quickly.I think we should be
> > GC free as well, and I doubt I am the only other one.
>
> Dropping the GC mea
> I wouldn't jump to that conclusion too quickly.I think we should be
> GC free as well, and I doubt I am the only other one.
Dropping the GC means re-introducing a whole class of bugs though. Are we
ready to divert a possibly significant part of our time to fixing memory
management bugs ag
25 matches
Mail list logo
