On Tue, 2006-02-28 at 18:50 +0100, Eric Botcazou wrote: > > 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>; This one is probably worth tracking down -- if the Ada front-end actually created this kind of code, then it would be a bug. Similarly if we originally had the proper typecasts and they were later eliminated, then that would be a bug in the optimizers.
Diego -- do you recall what code actually triggered this problem? jeff
