RTH has been suggesting to use build_int_cst (etype, 0) instead.
Indeed. I was trying to minimize the change, but such cleanups are always
useful. This was also missing a protection on INTEGER_TYPE_P. I just got
a good bootstrap of Ada on x86_64 with this and a patch from Diego to fix
the o
[EMAIL PROTECTED] (Richard Kenner) writes:
> Sorry it took me so long to get to this.
>
> > You're not showing where this comes from, so it's hard to say. However
> > D.1480 is created by the gimplifier, not the Ada front end. There could
> > easily be a typing problem in the tree
Sorry it took me so long to get to this.
> You're not showing where this comes from, so it's hard to say. However
> D.1480 is created by the gimplifier, not the Ada front end. There could
> easily be a typing problem in the tree there (e.g., that of the
> subtraction) but I can't
On Tue, May 03, 2005 at 06:21:11PM -0400, Richard Kenner wrote:
> As of right now, I don't think this is a VRP problem, but something wrong
> with the tree Ada produces.
>
That'd be good. If that's the case, we can make VRP assert that
the range derived from such types agrees with the type's ran
Yeah, I didn't show all of it, sorry. My patch to address this
problem includes a more detailed description
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html).
As of right now, I don't think this is a VRP problem, but something wrong
with the tree Ada produces.
Configu
On Mon, May 02, 2005 at 09:46:59PM -0400, Richard Kenner wrote:
> You're not showing where this comes from, so it's hard to say. However
> D.1480 is created by the gimplifier, not the Ada front end. There could
> easily be a typing problem in the tree there (e.g., that of the subtraction),
> but
I am tracking an ICE in VRP that triggers only in Ada. Given
this:
1 D.1480_32 = nam_30 - 30361;
2 if (D.1480_32 <= 1) goto ; else goto ;
3 :;
4 D.1480_94 = ASSERT_EXPR ;
5 goto ();
for name D.1480_94. However, the type of D.1480 is:
(gdb) ptu
