> As far as I can see this happens when we fold > > (bitsizetype) (#1 + 7) * 8 + 7 PLUS_EXPR 1 > > which we fold to > > ((bitsizetype) (#1 + 7) + 1) * 8 > > The #1 + 7 expression is computed in sizetype (which is now unsigned > and thus has defined overflow - thus we cannot optimize the widening > to bitsizetype).
I see, thanks for the investigation. > As I previously suggested we can put in special knowledge into > size_binop, or maybe better, provide abstraction for conversion > of sizetype to bitsizetype that would associate the type > conversions. The original plan was of course to at some point > have PLUSNV_EXPR so we can explicitely mark #1 + 7 as not > overflowing. It might be that introducing those just for > size expressions right now (and then dropping them down > to regular PLUS_EXPRs during gimplification) might be > something to explore for 4.8. OK, I'll think about it. No objections by me to going ahead with the patches. -- Eric Botcazou
