Re: [Gm2] Follow up for bugs reported June 17

[SiTex Graphics]

Hi Gaius,

On Wed, Oct 14, 2009 at 6:17 AM, Gaius Mulley <address@hidden> wrote:
> I believe I've fixed a bug you highlighted a while ago - in that
> SYSTEM.CARDINAL<n> and friends are now VAR parameter compatible with
> CARDINAL providing their sizes are the same.  This is now true for
> REAL, LONGREAL, SHORTREAL, LONGINT, SHORTINT, INTEGER, COMPLEX...

Great - thank you.

> Also on a different topic - I'm now attempting to automate the
> compiling of various thirds party tests - and I'm seeing
> compilation errors on:
>
> test6/pass/CodeGen.mod:170:2: error:  3rd actual parameter type 'CARDINAL' is
> incompatible with the formal parameter type 'CARD16'
> test6/pass/SBase.def:166:11: error:  3rd parameter in procedure 'Opt' 'ndata'
> has a type of 'CARD16'

The use of aliases for fixed size INTEGER and CARDINAL types seemed to
cause many compile errors, so I basically started over with this port.
 Now I'm running the code through a preprocessor that renames various
types to match GM2 naming conventions.  E.g., INT32 -> INTEGER32, REAL
-> SHORTREAL, etc.  So I'm no longer relying on aliases like CARD16
for the fixed size SYSTEM types.

Along the way I've fixed errors like the one above, but the code no
longer uses CARD16 etc.  If you want a version that will compile for
your test suite, I can fix that particular case - or you can probably
just change the parameter type in the definition module to match.

> test8/pass/APF.mod:38:5:error: type incompatibility found between
> types 'ADDRESS' and 'INTEGER32' during an assignment, hint
> maybe the expression should be converted>

I think this is a bug in the compiler.  The relevant line is

dp[apm.ndata]:=ud^.data;

where dp is a parameter declared with

VAR dp : ARRAY OF realarrayptr;

and the 'data' field is an ADDRESS.

with

TYPE realarrayptr = POINTER TO ARRAY [0..9999999] OF REAL;

so the above line assigns an address to a pointer.  No INTEGER32
involved.  Adding a CAST still generates an error message about type
incompatibility with INTEGER32.

Regards,
Scott