On Thu, 2013-11-14 at 00:34 -0700, Jeff Law wrote:
> On 10/31/13 10:26, David Malcolm wrote:

[...]

> > diff --git a/gcc/gimple.c b/gcc/gimple.c
> > index 9b1337a..e9ef8e0 100644
> > --- a/gcc/gimple.c
> > +++ b/gcc/gimple.c
> > @@ -641,21 +641,22 @@ static inline gimple
> >   gimple_build_asm_1 (const char *string, unsigned ninputs, unsigned 
> > noutputs,
> >                       unsigned nclobbers, unsigned nlabels)
> >   {
> > -  gimple p;
> > +  gimple_statement_asm *p;
> >     int size = strlen (string);
> >
> >     /* ASMs with labels cannot have outputs.  This should have been
> >        enforced by the front end.  */
> >     gcc_assert (nlabels == 0 || noutputs == 0);
> >
> > -  p = gimple_build_with_ops (GIMPLE_ASM, ERROR_MARK,
> > -                        ninputs + noutputs + nclobbers + nlabels);
> > +  p = as_a <gimple_statement_asm> (
> > +        gimple_build_with_ops (GIMPLE_ASM, ERROR_MARK,
> > +                          ninputs + noutputs + nclobbers + nlabels));
> >
> > -  p->gimple_asm.ni = ninputs;
> > -  p->gimple_asm.no = noutputs;
> > -  p->gimple_asm.nc = nclobbers;
> > -  p->gimple_asm.nl = nlabels;
> > -  p->gimple_asm.string = ggc_alloc_string (string, size);
> > +  p->ni = ninputs;
> > +  p->no = noutputs;
> > +  p->nc = nclobbers;
> > +  p->nl = nlabels;
> > +  p->string = ggc_alloc_string (string, size);
> As noted in a prior message, having build methods would eliminate this 
> downcasting.  Not necessary for this patch, just wanted to point it out 
> to anyone reading.  I won't point it out everywhere ;-)

This one (gimple_build_asm_1) is itself a build method.  The checking on
the downcast could be argued to be redundant, since presumably we trust
gimple_build_with_ops to give us a stmt with the code we asked for, but
I don't think it hurts.

> So given the prior disussions around as_a, I'm not going to object to 
> these as_a instances.  I see them as warts/markers that we have further 
> work to do in terms of fleshing out the class and possibly refactoring 
> code.
> 
> Conditionally OK.  Conditional on the other related patches going in and 
> keeping it updated with Andrew's churn.  If/when the set goes in, post 
> the final version you actually checkin -- no re-review is needed for 
> this hunk so long as any changes are the obvious fixing of fallout from 
> Andrew's work.

Thanks.

Reply via email to