Re: expression function bug or think?

[Adam Beneschan <adam@irvine.com>]

On Jun 16, 4:00 am, georg bauhaus <rmhost.bauh...@maps.arcor.de>
wrote:
> When I compile the following program with GNAT GPL 2011 on Mac,
> I get confusingly different behavior depending on whether
> or not I suppress checks. *Suppressing* the checks results in the
> desired
> program behavior. (The effect  reminds me of potential for Ariane 5
> gossip—or simply of me being dense.)  When checks are *disabled*
> (-gnatp), the program runs as expected and prints fib(10) = 55.
> When checks are enabled (no -gnatp) I get a constraint error
> on L.6.  Optimization does not affect the result, only -gnatp.
>
> Is the program correct, at least in theory?
>
> raised CONSTRAINT_ERROR : fib.ada:6 range check failed
>
> package Functions is
> function Fib (N : Natural) return Natural is
>     (case N is
>      when 0 => 0,
>      when 1 => 1,
>      when others => Fib(N-1) + Fib(N-2));  -- L.6
> end Functions;
>
> with Functions;
> with Ada.Text_IO;
>
> procedure Run_Fib is
>     N : Natural;
> begin
>     if Functions.Fib(0) /= 0 then
>          raise Program_Error;
>     end if;
>     N := Functions.Fib(10);
>     Ada.Text_IO.Put_Line ("fib(10) =" & Natural'Image(N));
> end Run_Fib;
>
> The debugger says that N=0 at L.6. Therefore, my guess is that
> translating in normal Ada mode (implying range checks) breaks
> the instruction sequence for case somewhere.  (I haven't understood
> the asm yet, takes time and effort since I don't
> read that every day.)

My guess is that the code is trying to evaluate N-1 and/or N-2 even
when N is 0 or 1, which would cause the Constraint_Error.  The program
should work; according to 4.5.7(21), at most one of the expressions on
the right side of => should be evaluated, so there should not be any
code to evaluate N-1 or N-2 when N is <= 1.  However, this is the kind
of thing that's easy to screw up in a compiler.  You have a tree
representing the conditional expression, and then you try to rearrange
the nodes in the tree in order make the code run faster and avoid
redundant computations, and if you don't do it right then something
that was supposed to be evaluated conditionally gets moved so that
it's evaluated before the condition is checked, and then your code
blows up.  I've had to fix a number of compiler problems of this
nature, related to short-circuit expressions.

                                -- Adam