On 2/28/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > Eric Botcazou wrote: > > > This problem was already raised when Diego contributed the VRP pass and > > Diego > > ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch. > > > Which doesn't mean that Ada is DTRT. On the contrary, Ada ought to be > fixed. 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.
My understanding of Ada is that the above is not (or should not be) what the frontend generates, but D.1480_32 = nam_30 - 300000361; should be carried out in the base type, as should the comparison be. It would be interesting to have a testcase that exposes the above behavior and hunt for the place where things start to go wrong. So correct should be D.xxxx = (base_type)nam_30; D.1480_32 = D.xxxx - 300000361; and D.1480 of type base_type. Just papering over latent bugs isn't the way to go here - rather break Ada, so it (or whatever gets it wrong) gets fixed. Richard.
