On Wed, 7 Mar 2012, Joseph S. Myers wrote:

> On Wed, 7 Mar 2012, Richard Guenther wrote:
> > Now, convert.c is used from all frontends to implement convert ()
> > (that looks backwards - the language convert should be a langhook,
> > called from convert implemented in convert.c).  But well, I aint
> > not touching this beast ;)
> I don't think convert () should be a langhook; it's all about 
> language-specific semantics (the only non-front-end places calling it, 
> outside of convert.c itself, now appear to be in arm.c).
> I'm not sure of the extent to which the recursive calls to convert inside 
> convert.c need any language-specific semantics.  To the extent that they 
> do, I think front ends should be dealing with the semantics rather than 
> having convert call back into the front end.  (I also think all the errors 
> from convert.c should be given by front ends instead; front ends should 
> only call the convert_to_* helpers for code they have checked is valid.)

I was thinking about having convert () be a middle-end function
(not langhook) working on generic, that does all frontend specific
stuff via a langhook (I didn't try to compare the convert implementations
to see if there is even any language-specifics about them).

I agree that errors should be raised from the frontends (also the
remaining optimizations convert_to_* do should be either moved to
fold or to later gimple optimization passes).

But no, I'm not going to touch this - maybe apart from removing
the obvious wrong users in arm.c.


Reply via email to