> 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