Re: [Gm2] LONGREAL

[Gaius Mulley]

Jan Carpay <address@hidden> writes:

> Hello,
>
> I am trying to compile the libraries we used years ago with a Metrowerks 
> compiler on the mac with GM2 (in the mean time, we used Oberon, but I like M2 
> more).
> Some of these are numerical and I wanted to compile them using LONGREALs by 
> putting REAL= LONGREAL in the def module, as I do not know of a compiler 
> switch that does that.
> (A welcome side effect of this type redefinition was that a so-called spill 
> error, which has to do with the code generated by a .c file, disappeared, 
> which I could not manage in another way. It seems a bug in the toolchain.
> )
>
> Unfortunately this type change may generate a lot of work, as some 
> expressions involving real constants are not accepted.
> E.g. in this routine (which compiles without errors in this version):
>
> PROCEDURE RROUND(arg: REAL; places: INTEGER): REAL;
>  VAR Eplaces: REAL;
>  BEGIN 
>   Eplaces:=PWI(1.0E1,places);
>   IF arg<0.0 THEN RETURN -LFLOAT(LTRUNC(LFLOAT(-arg*Eplaces+5.0E-1)))/Eplaces
>   ELSE RETURN LFLOAT(LTRUNC(LFLOAT(arg*Eplaces+5.0E-1)))/Eplaces
>   END;
> END RROUND;
>
> the inner LFLOAT in the RETURNs is required and cannot be placed around the 
> 5E-1 alone. Similar strange requirements arise in other statements and they 
> may disappear when one of them is met (by adding some LONG conversion). All 
> REAL variables and parameters are seen as LONGREAL without problem.
> Other procedures are not so short, so I forsee a lot of L-work.
>
> I hope someone can shed a light on why/when real constants / expressions may 
> (not) be accepted, or even on the spill error (I use the version 1.0.1. of 
> april with gcc 4.1.2).
>
> Thanks,
>
> Jan Carpay

Hi Jan,

many thanks for the bug report and example code - I'll reproduce this
and fix the bug,

regards,
Gaius