Hi, this is a regression present for 32-bit targets on mainline and 9 branch only, but the underlying issue dates back from the removal of the TYPE_IS_SIZETYPE machinery. Since the removal of this machinery, there is an internal conflict for sizetype: it's an unsigned type so with wrap-around semantics on overflow but overflow nevertheless needs to be tracked for it in order to avoid buffer overflows for large objects. The constant folder contains various tricks to that effect and the Ada front- end even more so, because VLAs are first-class citizens in the language and their lower bound is not necessarily 0. In particular, you need to be able to distinguish large constants in sizetype from small negative constants turned into even larger constants, because the latter appear in the length of e.g.: type Arr is array (2 .. N) of Long_Long_Integer; This works when the expressions haven't been too much mangled by the constant folder and here we have a counter-example for 32-bit targets. Starting with: (N + 4294967295) * 8 which is the sizetype expression of the size of Arr in bytes, extract_muldiv_1 distributes the multiplication: N * 8 + 4294967288 and, immediately after, fold_plusminus_mult_expr factors it back: (N + 536870911) * 8 At this point, there is no way for gigi to tell that it's the expression of a simple array with no overflow in sight because the 536870911 constant is large but not large enough, so gigi flags it as overflowing for small values of N. I don't see any other way out than disabling the back-and-forth mathematical game played by the constant folder in this case, which very likely brings no benefit in practice, hence the proposed fix. Tested on x86_64-suse-linux, OK for the mainline and 9 branch? 2019-05-31 Eric Botcazou * fold-const.c (extract_muldiv_1) : Do not distribute a multiplication by a power-of-two value. 2019-05-31 Eric Botcazou * gnat.dg/specs/discr6.ads: New test. -- Eric Botcazou