> It's an ugly hack in extract_range_from_assert:
>
> /* Special handling for integral types with super-types. Some FEs
> construct integral types derived from other types and restrict
> the range of values these new types may take.
>
> It may happen that LIMIT is actually smaller than TYPE's minimum
> value. For instance, the Ada FE is generating code like this
> during bootstrap:
>
> D.1480_32 = nam_30 - 300000361;
> if (D.1480_32 <= 1) goto <L112>; else goto <L52>;
> <L112>:;
> D.1480_94 = ASSERT_EXPR <D.1480_32, D.1480_32 <= 1>;
>
> All the names are of type types__name_id___XDLU_300000000__399999999
> which has min == 300000000 and max == 399999999. This means that
> the ASSERT_EXPR would try to create the range [3000000, 1] which
> is invalid.
>
> The fact that the type specifies MIN and MAX values does not
> automatically mean that every variable of that type will always
> be within that range, so the predicate may well be true at run
> time. If we had symbolic -INF and +INF values, we could
> represent this range, but we currently represent -INF and +INF
> using the type's min and max values.
>
> So, the only sensible thing we can do for now is set the
> resulting range to VR_VARYING. TODO, would having symbolic -INF
> and +INF values be worth the trouble? */
I think we would need to clarify that, because I'm not sure the Ada front-end
directly generates:
D.1480_32 = nam_30 - 300000361;
if (D.1480_32 <= 1) goto <L112>; else goto <L52>;
<L112>:;
D.1480_94 = ASSERT_EXPR <D.1480_32, D.1480_32 <= 1>;
--
Eric Botcazou