https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80006
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 13 Mar 2017, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80006 > > Martin Sebor <msebor at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Keywords| |missed-optimization > Status|UNCONFIRMED |NEW > Last reconfirmed| |2017-03-13 > Summary|loss of range information |loss of range information > |after widening conversion |due to spurious widening > | |conversion > Ever confirmed|0 |1 > > --- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> --- > I see. I agree that transforming ~[-3, 7] to [SCHAR_MIN, SCHAR_MAX] when > converting a signed char to a wider type makes sense. I was so focused on > preserving the anti-range that I hadn't thought of that. > > Let me use this bug to track the spurious conversion from signed char to int > (thanks for the pointer, Joseph). I'm not sure what Component to assign it > to: > target? middle-end As for where to do the promotion one needs to look at what this exactly does, what targets do this (and why). Basically you need to see whether for each target disabling this will break the ABI or just have optimization effects. These kind of "promotions" should be defered to RTL expansion (at this stage) or a hypotetical lowering phase where call ABI details are exposed at the GIMPLE level. In the past we had other similar promotions done by frontends and this was (re-)moved.
