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. Richard.
