gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gaius Mulley
Subject: Re: [Gm2] Follow up for bugs reported June 17
Date: Sat, 10 Oct 2009 11:45:16 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

SiTex Graphics <address@hidden> writes:

> Hi Gaius,
>
> First, some good news:  my test application now builds and for the
> first time produces correct output in some but not all tests.  That is
> a big step forward!

Hi,

excellent news!

> Thank you very much for all your help with this project so far.
> In the course of getting the application to work, I coded around what
> seems to be a bug in the conversion of record fields that are small
> cardinals or integers.  The short test module below illustrates the
> bug.  Compiled with
>
> gm2 -I. -fiso -fmakeall -o test test.mod
>
> The result is:
>
> in = 1718
> out = 12977846
>
> I expect the compiler either to issue a type incompatibility error or
> to produce the correct result.  Note that either removing the in2
> field or setting that field to 0 produces a correct result. Maybe that
> will help track this one down.

thanks again for the test code - definitely a bug as VAL should be able
to convert from CARDINAL16 to CARDINAL.  The removal of in2 is
interesting - I will look into this.  I'm assuming you are running
on an LP64 system (64 bit GNU/Linux ?)

> This situation crops up quite a bit in the test application, and I
> think this bug is likely causing at least some of the runtime
> failures.

yes most likely.  The gm2 standard regression suite now stands at 6
failures out of >8000 tests.  This last set of failures occur when
passing an ADR("string") to an ADDRESS formal parameter.  In the
TermOpen module it passes it as 32 bit entity - in other test programs
it is correctly passed as a 64 entity.  Very odd and fun to track down
:-)

regards,
Gaius




reply via email to

[Prev in Thread] Current Thread [Next in Thread]