On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote:
> Here's a great example from uintp.adb (which is the cause of the
> testsuite hang FWIW)
>
> We have a loop with the following termination code in uintp.num_bits
>
> # BLOCK 8
> # PRED: 5 [100.0%] (fallthru,exec) 6 (fallthru,dfs_back,exec)
> # num_2 = PHI <num_49(5), num_10(6)>;
> # bits_1 = PHI <bits_50(5), bits_13(6)>;
> <L7>:;
> num.265_5 = (types__TintB) num_2;
> if (num.265_5 <= 0) goto <L5>; else goto <L4>;
> # SUCC: 7 (true,exec) 6 (false,exec)
...
> Sooooo, why am I bringing this up? Because num can actually have
> the value 0x80000000 at runtime, which is out of its type's
> MIN/MAX range. And what do you think happens? Well, given the
> (valid) simplification of the loop test and the way "num" is
> assigned within the loop (num = num / 2), the loop never terminates.
I've been following this entire thread, and I think there's a serious
disconnect between the parties - it's unfortunate that none of the
tree-ssa folks involved know Ada as I suspect that would straighten
it out in a hurry. This is a perfect example. Now that we have some
concrete code that's causing a problem, let's take a look at it
(bear in mind, I don't know Ada either):
function Num_Bits (Input : Uint) return Nat is
Bits : Nat;
Num : Nat;
begin
if UI_Is_In_Int_Range (Input) then
Num := abs (UI_To_Int (Input));
Bits := 0;
else
Bits := Base_Bits * (Uints.Table (Input).Length - 1);
Num := abs (Udigits.Table (Uints.Table (Input).Loc));
end if;
while Types.">" (Num, 0) loop
Num := Num / 2;
Bits := Bits + 1;
end loop;
return Bits;
end Num_Bits;
I'm going to assume that UI_Is_In_Int_Range isn't true for 0x80000000.
The other case is still assigning 0x80000000 to Nat somehow. I'd be
amazed if that's really valid Ada! Could someone who knows the
language comment, please?
> I wouldn't have a problem with non-canonical bounds if there were
> no way to get a value into an object which is outside the
> bounds. But if we can get values into the object which are outside
> those bounds, then either the bounds are incorrect or the program
> is invalid.
Ignoring 'Valid, which folks agreed to do earlier, I think everyone
agrees with this statement - which is why I suspect that there's
something wrong with Num_Bits.
--
Daniel Jacobowitz
CodeSourcery
