On Mon, Apr 15, 2013 at 12:04 PM, Eric Botcazou <ebotca...@adacore.com> wrote: >> I think I already rejected this and asked you to fix the users (like >> layout_type is a user). > > Yes, but that would be a pain, there are too many users in the Ada front-end.
Users that care about the special casing of 0 - 1 and overflow detection? For the C family I found exactly one - the layout_type case, and fixed it in the FEs by making empty arrays use [1, 0] domains or signed domains (I don't remember exactly). I believe the layout_type change was to make Ada happy. >> Clearly 0 - 1 in unsigned arithmetic overflows. Not indicating this may >> cause bugs elsewhere as easily as it fixes code not dealing with this fact. > > !?? There is no overflow in unsigned arithmetics. Instead size_binop forces > overflows artificially and I don't see the problem in deciding that 0 - 1 is a > special case, like [0, -1] is a special case for layout_type. And note that > this was the historical behavior, before the latest sizetype changes. Historically sizetype didn't overflow because it was supposed to never overflow. Well, unless we check for overflow. It may be that enabling overflow detection for even unsigned sizetype was because of Ada as well. After all only Ada changed its sizetype sign recently. I don't like special casing 0 - 1 in a general compute function. Maybe you want to use size_diffop for the computation? That would result in a signed result and thus no overflow for 0 - 1. The other option is to for example disable overflow handling for _all_ constants and MINUS_EXPR (and then please PLUS_EXPR as well) in size_binop. Maybe it's only the MULT_EXPR overflow we want to know (byte-to-bit conversion / element size scaling IIRC). Richard. > -- > Eric Botcazou
