> I don't like littering the patterns with this and it's likely far from the > only cases we have?
Maybe, but that's the only problematic case we have in Ada. It occurs only on mainline because we have streamlined address calculations there, from out-of- line to inline expansion, i.e. from run time to compile time. > Since we did move some of the patterns from fold-const.cc to match.pd and > the frontends might be interested in TREE_OVERFLOW (otherwise we'd just > scrap that!) I'm not sure removing the flag is good (and I never was really > convinced the setting for the implementation defined behavior on conversion > to unsigned is good). Yes, the Ada front-end relies on the TREE_OVERFLOW flag to detect overflows at compile time, so it cannot be removed, but it must be set correctly, which is not the case here: (T)p - (T) (p + 4) where T is signed should just yield -4. > Am I correct that the user writing such a conversion in Ada _should_ > get a constraint violation? So it's just the middle-end introducing it > to avoid undefined signed overflow that's on error? Yes, it's a Constraint_Error in Ada to convert a value of an unsigned type to a signed type if it does not fit in the signed type. > I'll also note that fold_convert_const_int_from_int shouldn't set > TREE_OVERFLOW on unsigned destination types? So it's the > outer conversion back to signed that generates the TREE_OVERFLOW? Yes, 4 is converted to unsigned, then negated, yielding a huge number, and the final conversion back to signed yields -4 with TREE_OVERFLOW set. > Would it help to use a (view_convert ...) here? For non-constants that > should be folded back to a sign changing (convert ...) but the constant > folding should hopefully happen earlier? But it's again implementation > defined behavior we have here, so not sure we need TREE_OVERFLOW at all. I'm not sure we need to jump through too many hoops here: the intermediate conversion trick is a kludge because we lack a proper method to selectively disable undefined overflow at run time, but that's not the case at compile time where we have a finer-grained control (and even different rules) so I don't really see a problem with handling the two cases differently. -- Eric Botcazou
