Re: Bootstrap failure on trunk: x86_64-linux-gnu

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 2/28/06, Diego Novillo <dnovillo@redhat.com> 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.