This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 00/89] Compile-time gimple-checking

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 keep the typedefs; giving something like the
>>>>   static void
>>>>   dump_gimple_switch (pretty_printer *buffer, gimple_switch gs, int
>>>>                       int flags)
>>>>   [...snip...]
>>>>   [...later, within pp_gimple_stmt_1:]
>>>>      case GIMPLE_SWITCH:
>>>>        dump_gimple_switch (buffer, as_a <gimple_switch> (gs), spc,
>>>>        break;
>>>> which is concise, readable, and avoid the change in pointerness
>>>> to the "gimple" typedef; the local decls above would look like this:
>>>>   gimple some_stmt;  /* note how this doesn't have a star... */
>>>>   gimple_assign assign_stmt; /* ...and neither do these */
>>>>   gimple_cond assign_stmt;
>>>>   gimple_phi phi;
>>>> I think this last proposal is my preferred API, but it requires the
>>>> change to is-a.h
>>>> Attached is a proposed change to the is-a.h API that elimintates the
>>>> discrepancy, allowing the use of typedefs with is-a.h (doesn't yet
>>>> compile, but hopefully illustrates the idea).  Note how it changes
>>>> API to match C++'s  dynamic_cast<> operator i.e. you do
>>>>   Q* q = dyn_cast<Q*> (p);
>>>> not:
>>>>   Q* q = dyn_cast<Q> (p);
>>>Thanks for being flexible. :-)  I like this version too FWIW, for the
>>>reason you said: it really does look like a proper C++ cast.
>> Indeed. I even wasn't aware it is different Than a c++ cast...
> It would be nice if you can change that with a separate patch posted
> in a separate thread to be more visible.
> 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?  ISTR that
> it was "oh, if we were only using C++ we wouldn't need to jump through
> that hoop".

To followup myself here, it's because 'tree' is a typedef to a pointer
and thus 'const tree' is different from 'const tree_node *'.

Not sure why we re-introduced the 'mistake' of making 'tree' a pointer
when we introduced 'gimple'.  If we were to make 'gimple' the class
type itself we can use gimple *, const gimple * and also const gimple &
(when a NULL pointer is not expected).

Anyway, gazillion new typedefs are ugly :/  (typedefs are ugly)


> Thanks,
> Richard.
>> Richard.
>>>If we ever decide to get rid of the typedefs (maybe at the same time as
>>>using "auto") then the choice might be different, but that would be a
>>>more systematic and easily-automated change than this one.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]