On Fri, 2014-05-02 at 10:02 -0600, Jeff Law wrote:
> On 05/02/14 03:09, Richard Biener wrote:
> >
> > Well, I'd like to see both and one affects the other. Doing the const
> > correctness thing first seems more natural to me.
> > Of course both need to wait for 4.9.1.
> Well, it looks like David i
On 05/02/14 03:09, Richard Biener wrote:
Well, I'd like to see both and one affects the other. Doing the const
correctness thing first seems more natural to me.
Of course both need to wait for 4.9.1.
Well, it looks like David is already on that path to some extent with
the proposed gengtype ch
On April 30, 2014 11:26:35 PM CEST, Jeff Law wrote:
>On 04/23/14 08:32, Richard Biener wrote:
>
>>> Also I see you introduce a const_FOO class with every FOO one.
>>> I wonder whether, now that we have C++, can address
>const-correctness
>>> in a less awkward way than with a typedef. Can you try
On 04/23/14 08:32, Richard Biener wrote:
Also I see you introduce a const_FOO class with every FOO one.
I wonder whether, now that we have C++, can address const-correctness
in a less awkward way than with a typedef. Can you try to go back
in time and see why we did with that in the first place
Hi,
On Fri, 25 Apr 2014, Richard Biener wrote:
> Btw, I agree we should stick to one style throughout the code-base.
> The advantage of the cast variant is that it can be made work with
> NULL pointers (in the dyn_cast <> case).
NULL pointers shouldn't even be casted at all, there should be sens
On Thu, Apr 24, 2014 at 4:49 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 24 Apr 2014, Andrew MacLeod wrote:
>
>> Well, we ought to settle on one... either use the is_a, as_a, and
>> dyn_cast paradigm as they exist today, or we use the cast_as_method
>> approach everywhere. I'm not fond of each pote
Hi,
On Thu, 24 Apr 2014, Andrew MacLeod wrote:
> Well, we ought to settle on one... either use the is_a, as_a, and
> dyn_cast paradigm as they exist today, or we use the cast_as_method
> approach everywhere. I'm not fond of each potential project having a
> different approach... I'd like to
On 04/23/2014 10:42 AM, Michael Matz wrote:
Hi,
On Mon, 21 Apr 2014, David Malcolm wrote:
case GIMPLE_SWITCH:
dump_gimple_switch (buffer, gs->as_a_gimple_switch (), spc, flags);
break;
where the ->as_a_gimple_switch is a no-op cast from "gimple" to the more
concrete "gimpl
Jeff Law writes:
> On 04/22/14 02:03, Richard Sandiford wrote:
>> First of all, thanks a lot for doing this. Maybe one day we'll have
>> the same in rtl :-)
> Funny you should mention that. I blocked off a hunk of time for David
> to investigate doing some work on that this year.
That'd be gre
On 04/22/14 02:03, Richard Sandiford wrote:
First of all, thanks a lot for doing this. Maybe one day we'll have
the same in rtl :-)
Funny you should mention that. I blocked off a hunk of time for David
to investigate doing some work on that this year.
Jeff
On 04/22/14 02:36, Richard Biener wrote:
On Mon, Apr 21, 2014 at 6:56 PM, David Malcolm wrote:
This is a greatly-expanded version of:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01262.html
As of r205034 (de6bd75e3c9bc1efe8a6387d48eedaa4dafe622d) and
r205428 (a90353203da18288cdac1b0b78fe7b2
On 04/23/2014 10:19 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 9:42 PM, Richard Biener
wrote:
On April 22, 2014 8:56:56 PM CEST, Richard Sandiford
wrote:
David Malcolm writes:
Alternatively we could change the is-a.h API to eliminate this
discrepancy, and keep the typedefs; giving s
On Wed, 2014-04-23 at 16:19 +0200, Richard Biener wrote:
> On Tue, Apr 22, 2014 at 9:42 PM, Richard Biener
> wrote:
> > On April 22, 2014 8:56:56 PM CEST, Richard Sandiford
> > wrote:
> >>David Malcolm writes:
> >>> Alternatively we could change the is-a.h API to eliminate this
> >>> discrepanc
Hi,
On Mon, 21 Apr 2014, David Malcolm wrote:
> This is a greatly-expanded version of:
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01262.html
>
> As of r205034 (de6bd75e3c9bc1efe8a6387d48eedaa4dafe622d) and
> r205428 (a90353203da18288cdac1b0b78fe7b22c69fe63f) the various gimple
> statements
On Wed, Apr 23, 2014 at 4:19 PM, Richard Biener
wrote:
> On Tue, Apr 22, 2014 at 9:42 PM, Richard Biener
> wrote:
>> On April 22, 2014 8:56:56 PM CEST, Richard Sandiford
>> wrote:
>>>David Malcolm writes:
Alternatively we could change the is-a.h API to eliminate this
discrepancy, and
On Tue, Apr 22, 2014 at 9:42 PM, Richard Biener
wrote:
> On April 22, 2014 8:56:56 PM CEST, Richard Sandiford
> wrote:
>>David Malcolm writes:
>>> Alternatively we could change the is-a.h API to eliminate this
>>> discrepancy, and keep the typedefs; giving something like the
>>following:
>>>
>>
On April 22, 2014 8:56:56 PM CEST, Richard Sandiford
wrote:
>David Malcolm writes:
>> Alternatively we could change the is-a.h API to eliminate this
>> discrepancy, and keep the typedefs; giving something like the
>following:
>>
>> static void
>> dump_gimple_switch (pretty_printer *buffer, g
On 04/22/2014 02:56 PM, Richard Sandiford wrote:
David Malcolm writes:
Alternatively we could change the is-a.h API to eliminate this
discrepancy, and keep the typedefs; giving something like the following:
static void
dump_gimple_switch (pretty_printer *buffer, gimple_switch gs, int spc
On 04/22/2014 01:50 PM, David Malcolm wrote:
On Tue, 2014-04-22 at 09:05 -0400, Andrew MacLeod wrote:
Of course, it would be ideal if we could use 'gimple' as the namespace,
but that is currently taken by the gimple statement type... I'd even go
so far as to propose that 'gimple' should be ren
David Malcolm writes:
> Alternatively we could change the is-a.h API to eliminate this
> discrepancy, and keep the typedefs; giving something like the following:
>
> static void
> dump_gimple_switch (pretty_printer *buffer, gimple_switch gs, int spc,
> int flags)
> [...
On Tue, 2014-04-22 at 09:05 -0400, Andrew MacLeod wrote:
> On 04/22/2014 04:03 AM, Richard Sandiford wrote:
> > First of all, thanks a lot for doing this. Maybe one day we'll have
> > the same in rtl :-)
> >
> > But...
> >
> > David Malcolm writes:
> >> In doing the checked downcasts I ran into t
On Tue, 2014-04-22 at 09:03 +0100, Richard Sandiford wrote:
> First of all, thanks a lot for doing this. Maybe one day we'll have
> the same in rtl :-)
>
> But...
>
> David Malcolm writes:
> > In doing the checked downcasts I ran into the verbosity of the as_a <>
> > API (in our "is-a.h"). I f
On Tue, Apr 22, 2014 at 09:05:43AM -0400, Andrew MacLeod wrote:
> On 04/22/2014 04:03 AM, Richard Sandiford wrote:
> >First of all, thanks a lot for doing this. Maybe one day we'll have
> >the same in rtl :-)
> >
> >But...
> >
> >David Malcolm writes:
> >>In doing the checked downcasts I ran into
On 04/22/2014 04:03 AM, Richard Sandiford wrote:
First of all, thanks a lot for doing this. Maybe one day we'll have
the same in rtl :-)
But...
David Malcolm writes:
In doing the checked downcasts I ran into the verbosity of the as_a <>
API (in our "is-a.h"). I first tried simplifying them
On Mon, Apr 21, 2014 at 6:56 PM, David Malcolm wrote:
> This is a greatly-expanded version of:
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01262.html
>
> As of r205034 (de6bd75e3c9bc1efe8a6387d48eedaa4dafe622d) and
> r205428 (a90353203da18288cdac1b0b78fe7b22c69fe63f) the various gimple
> stat
First of all, thanks a lot for doing this. Maybe one day we'll have
the same in rtl :-)
But...
David Malcolm writes:
> In doing the checked downcasts I ran into the verbosity of the as_a <>
> API (in our "is-a.h"). I first tried simplifying them with custom
> functions e.g.:
>
>static inli
This is a greatly-expanded version of:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01262.html
As of r205034 (de6bd75e3c9bc1efe8a6387d48eedaa4dafe622d) and
r205428 (a90353203da18288cdac1b0b78fe7b22c69fe63f) the various gimple
statements form a C++ inheritance hierarchy, but we're not yet making
27 matches
Mail list logo
