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

[Jeffrey A Law <law at redhat dot com>]

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