> "Mike" == Mike Stump writes:
Mike> Yeah, I kinda think the gdb people are wimping out by not just
Mike> implementing __extension__ and ({}), which, I think get us most of the
Mike> way there. Shh, don't tell them I said that.
We eagerly await your patch.
Tom
> "Lawrence" == Lawrence Crowl writes:
Lawrence> Should I add that to my patch to gdbinit.in?
I think it would be helpful.
Tom
On May 23, 2012, at 3:36 PM, Lawrence Crowl wrote:
> For variables that are not optimized out of memory, I think this
> can work. But if you need to go for registers,
Also trivial... Just one has to generate the context correctly. One has to
save off the registers and then in the context gener
On 5/21/12, Tom Tromey wrote:
>> "Alexander" == Alexander Monakov writes:
>
> Alexander> Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?
> Alexander> It's useful to have that in your .gdbinit anyway, because the
> Alexander> same issue arises when calling debug_* functions in cc1 fr
On 5/21/12, Mike Stump wrote:
> On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
>> On 5/17/12, Mike Stump wrote:
>>> On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
> Reusing the compiler for this seems like the only way to go.
> But, we did look at using g++ to parse C++ expression
> "Alexander" == Alexander Monakov writes:
Alexander> Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?
Alexander> It's useful to have that in your .gdbinit anyway, because the
Alexander> same issue arises when calling debug_* functions in cc1 from
Alexander> the debugger.
Yeah, why
On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
> On 5/17/12, Mike Stump wrote:
>> On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
Reusing the compiler for this seems like the only way to go.
But, we did look at using g++ to parse C++ expressions from gdb,
and it was too slow
On Thu, 17 May 2012, Tom Tromey wrote:
> It would be nice if there were a way to make cc1 not crash due to user
> error in the debugger. I think this kind of crash will be especially
> crazy-making.
Hm, isn't GDB's 'set unwindonsignal on' enough to fix it? It's useful to
have that in your .gd
On Mon, May 21, 2012 at 12:18 PM, Richard Guenther
wrote:
> On Sun, May 20, 2012 at 9:10 PM, Diego Novillo wrote:
>> On 12-05-20 13:59 , Richard Henderson wrote:
>>>
>>> On 05/18/2012 04:48 PM, Diego Novillo wrote:
We can do this in trunk today using a variant of Lawrence's original
>>>
On Sun, May 20, 2012 at 9:10 PM, Diego Novillo wrote:
> On 12-05-20 13:59 , Richard Henderson wrote:
>>
>> On 05/18/2012 04:48 PM, Diego Novillo wrote:
>>>
>>> We can do this in trunk today using a variant of Lawrence's original
>>> patch (http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01649.html).
On 12-05-20 13:59 , Richard Henderson wrote:
On 05/18/2012 04:48 PM, Diego Novillo wrote:
We can do this in trunk today using a variant of Lawrence's original
patch (http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01649.html). This
uses no C++ features, though it weakens type checking by removing a
On 05/18/2012 04:48 PM, Diego Novillo wrote:
We can do this in trunk today using a variant of Lawrence's original patch
(http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01649.html). This uses no C++
features, though it weakens type checking by removing away constness.
In the cxx-conversion branc
On 5/18/12, Diego Novillo wrote:
> So, I would like to figure out what to do with this. We have
> a usability problem wrt deubgging that I would like to fix.
> The only way we have of using all the tree accessor macros from
> GDB is to convert the checks into functions (converting the actual
> ac
On 5/17/12, Mike Stump wrote:
> On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
>>> Reusing the compiler for this seems like the only way to go.
>>> But, we did look at using g++ to parse C++ expressions from gdb,
>>> and it was too slow :-(. We're going to look again, at least to
>>> generate
On 12-05-18 08:23 , Jay Foad wrote:
What's wrong with:
(check_in_cxx(t), t)
?
This evaluates 't' twice.
Diego.
On 12-05-18 18:14 , Richard Henderson wrote:
On 05/18/12 05:06, Richard Guenther wrote:
Can you locate those? I mean, most uses look like
#define DECL_NONSHAREABLE(NODE) \
(TREE_CHECK2 (NODE, VAR_DECL, \
RESULT_DECL)->decl_common.decl_nonshareable_flag)
thus they only dere
On 05/18/12 05:06, Richard Guenther wrote:
> Can you locate those? I mean, most uses look like
>
> #define DECL_NONSHAREABLE(NODE) \
> (TREE_CHECK2 (NODE, VAR_DECL, \
> RESULT_DECL)->decl_common.decl_nonshareable_flag)
>
> thus they only dereference the result, not assign it an
On 18 May 2012 12:46, Diego Novillo wrote:
> On 12-05-18 06:14 , Richard Guenther wrote:
>
>> As you retain the macros anyway you can simply not return anything
>> from the C++ checking functions define to a stmt expression
>> ({ check_in_cxx (t); t; })
>
>
> Sure, but that takes us back to the or
On Fri, May 18, 2012 at 1:46 PM, Diego Novillo wrote:
> On 12-05-18 06:14 , Richard Guenther wrote:
>
>> As you retain the macros anyway you can simply not return anything
>> from the C++ checking functions define to a stmt expression
>> ({ check_in_cxx (t); t; })
>
>
> Sure, but that takes us bac
On 12-05-18 06:14 , Richard Guenther wrote:
As you retain the macros anyway you can simply not return anything
from the C++ checking functions define to a stmt expression
({ check_in_cxx (t); t; })
Sure, but that takes us back to the original gdb issue: it does not
understand statement expres
On Thu, May 17, 2012 at 8:36 PM, Diego Novillo wrote:
> On 12-05-17 10:52 , Michael Matz wrote:
>
>> Cross the bridge when you reach it, not before. Not everybody agrees that
>> the splitting of tree would be a good idea. Right now templates aren't
>> necessary, so you shouldn't use them. (well
On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
>> Reusing the compiler for this seems like the only way to go.
>> But, we did look at using g++ to parse C++ expressions from gdb,
>> and it was too slow :-(. We're going to look again, at least to
>> generate some bug reports if we can.
>
> It'
On 5/17/12, Tom Tromey wrote:
> > "Lawrence" == Lawrence Crowl writes:
>
> Tom> Doesn't this mean that if you have checking enabled, and you use
> Tom> the wrong macro on some tree, cc1 will crash? That seems like
> Tom> a distinct minus to me.
>
> Lawrence> Yes, it does mean that, but it is a n
On Thu, May 17, 2012 at 1:53 PM, Tom Tromey wrote:
>> "Lawrence" == Lawrence Crowl writes:
>
> Tom> Doesn't this mean that if you have checking enabled, and you use the
> Tom> wrong macro on some tree, cc1 will crash? That seems like a distinct
> Tom> minus to me.
>
> Lawrence> Yes, it does
> "Lawrence" == Lawrence Crowl writes:
Tom> Doesn't this mean that if you have checking enabled, and you use the
Tom> wrong macro on some tree, cc1 will crash? That seems like a distinct
Tom> minus to me.
Lawrence> Yes, it does mean that, but it is a net overall improvement.
It is a net de
On 12-05-17 10:52 , Michael Matz wrote:
Cross the bridge when you reach it, not before. Not everybody agrees that
the splitting of tree would be a good idea. Right now templates aren't
necessary, so you shouldn't use them. (well, and an investigation why
they come up with smaller .text would
Hi,
On Wed, 16 May 2012, Lawrence Crowl wrote:
> > Because it accepts any type as tree argument? It's of course not less
> > type safety than using macros, but less type safety compared to not
> > using templates.
>
> The overload works if the only types are tree and const_tree. In the
> fut
On 5/16/12, Tom Tromey wrote:
>> "Lawrence" == Lawrence Crowl writes:
>
> Lawrence> The effect is that it now possible to get useful responses
> Lawrence> to gdb command like
> Lawrence> (gdb) print DECL_FUNCTION_CODE (decl)
>
> Doesn't this mean that if you have checking enabled, and you
On 5/16/12, Richard Guenther wrote:
> On May 16, 2012 Diego Novillo wrote:
> > On 12-05-16 09:00 , Richard Guenther wrote:
> > > On May 16, 2012 Diego Novillo wrote:
> > > > On 12-05-16 05:41 , Richard Guenther wrote:
> > > > > What's the reason for templating these functions?
> > > > > They all
> "Lawrence" == Lawrence Crowl writes:
Lawrence> The effect is that it now possible to get useful responses to gdb
Lawrence> command like
Lawrence> (gdb) print DECL_FUNCTION_CODE (decl)
Doesn't this mean that if you have checking enabled, and you use the
wrong macro on some tree, cc1 wil
Il 16/05/2012 15:27, Richard Guenther ha scritto:
>> >
>> > Two bootstrapped compilers built exactly the same, except one was using the
>> > template version, the other using the straight inline functions with
>> > const_tree parameters and CONST_CAST_TREE in return values.
> That's of course not e
On Wed, May 16, 2012 at 3:40 PM, Diego Novillo wrote:
> On 12-05-16 09:27 , Richard Guenther wrote:
>
>>> There's less typing if you use the template variant. Not sure why
>>> you say there is less type safety with templates.
>>
>>
>> Because it accepts any type as tree argument?
>
>
> Yes and no
On 12-05-16 09:27 , Richard Guenther wrote:
There's less typing if you use the template variant. Not sure why
you say there is less type safety with templates.
Because it accepts any type as tree argument?
Yes and no. It accepts any type that responds to tree
operations and has the same fi
On Wed, May 16, 2012 at 3:16 PM, Diego Novillo wrote:
> On 12-05-16 09:00 , Richard Guenther wrote:
>>
>> On Wed, May 16, 2012 at 2:43 PM, Diego Novillo
>> wrote:
>>>
>>> On 12-05-16 05:41 , Richard Guenther wrote:
>>>
What's the reason for templating these functions? They all take trees
>>
On 12-05-16 09:00 , Richard Guenther wrote:
On Wed, May 16, 2012 at 2:43 PM, Diego Novillo wrote:
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason for templating these functions? They all take trees as
parameter!?
True. I don't recall what Lawrence had in mind, but I remembe
On Wed, May 16, 2012 at 2:43 PM, Diego Novillo wrote:
> On 12-05-16 05:41 , Richard Guenther wrote:
>
>> What's the reason for templating these functions? They all take trees as
>> parameter!?
>
>
> True. I don't recall what Lawrence had in mind, but I remember that by
> using templates here, yo
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason for templating these functions? They all take trees as
parameter!?
True. I don't recall what Lawrence had in mind, but I remember that by
using templates here, you don't need to deal with the mess of
distinguishing tree from con
On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowl wrote:
> The gcc source uses several constructs that GDB does not understand.
> This patch corrects some of them. It affects only compilers built
> with ENABLE_TREE_CHECKING, and hence release compilers are unaffected.
>
> In particular, I change th
On 12-05-15 13:19 , Lawrence Crowl wrote:
The gcc source uses several constructs that GDB does not understand.
This patch corrects some of them. It affects only compilers built
with ENABLE_TREE_CHECKING, and hence release compilers are unaffected.
In particular, I change the implementation of C
On May 15, 2012, at 11:23 AM, Steven Bosscher wrote:
> On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowl wrote:
>> The gcc source uses several constructs that GDB does not understand.
>> This patch corrects some of them. It affects only compilers built
>> with ENABLE_TREE_CHECKING, and hence releas
On 12-05-15 14:23 , Steven Bosscher wrote:
On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowl wrote:
The gcc source uses several constructs that GDB does not understand.
This patch corrects some of them. It affects only compilers built
with ENABLE_TREE_CHECKING, and hence release compilers are un
On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowl wrote:
> The gcc source uses several constructs that GDB does not understand.
> This patch corrects some of them. It affects only compilers built
> with ENABLE_TREE_CHECKING, and hence release compilers are unaffected.
> Index: gcc/ChangeLog.cxx-con
The gcc source uses several constructs that GDB does not understand.
This patch corrects some of them. It affects only compilers built
with ENABLE_TREE_CHECKING, and hence release compilers are unaffected.
In particular, I change the implementation of CHECK macros using
__extension__ into macros
43 matches
Mail list logo
