(* Hello,

This little program is extracted for convenience from a large numerical application that uses floating point expressions. It generates a 216 runtime error when is compiled
with -Or option, proving that this switch is still buggy in 1.0.5. What should we do in this case?

Stefan
*)

program error;
 procedure Proc_1;
 var a,b: extended;
  procedure Proc_3;
  var x,y,z,t: extended;
  begin
   x:=(1-Sqr(a))/(1+a); y:=0; z:=0; t:=0;
  end;
  procedure Proc_2;
  var c: extended;
  begin
   c:=0;
   Proc_3;
  end;
 begin
  a:=0; b:=0;
  Proc_2;
 end;
begin
 Proc_1;
end.

No, it's runtime error 207 (at least under Linux). It's caused by an fpu stack overflow. Pierre, the problem is that proc_1 gets an fpu-varreg, proc_2 as well, and proc_3 gets 4 (and it uses two fpu registers for expression evaluation), so you get a total usage of 8 instead of 7 registers.

All this information is in the assembler code if you use -al, so the compiler is not miscalculating the number of required number of registers per individual procedure, but it seems to be wrong on the overall picture (it should not use an fpu varreg in proc_1).

with -Or option, proving that this switch is still buggy in 1.0.5. What should we do in this case?

Until it's fixed, you can add

{$maxfpuregisters 3}

before the implementation of proc_3

Jonas

Gheorghe Stefan BERINDE wrote

This little program is extracted for convenience from a large numerical application that uses floating point expressions. It generates a 216 runtime error when is compiled with -Or option, proving that this switch is still buggy in 1.0.5.

It's fixed.

Jonas