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.