On Sat, Apr 14, 2018 at 1:56 PM, Michalis Kamburelis
<michalis.ka...@gmail.com> wrote:
> 2018-04-14 12:42 GMT+02:00 Punit Agrawal <punitagra...@gmail.com>:
>> At this point, I suspect it's a compiler issue. I've created a
>> reproducer (attached) that highlights the problem and behaves
>> differently on arm64 and x86.
>>
>> Note: I am not at all familiar with Pascal. Input from somebody more
>> familiar with the language ecosystem will be greatly appreciated.
>>
>
> Great job!
>
> Note that in your testcase, the minimized "TRectangle.ScaleAround0"
> does not set Result.Width, Result.Left in some cases. And, since this
> is a record, the uninitialized fields are undefined (may contain
> memory garbage).
>
> It should not matter for the result (from what I see, the
> TRectangle.Width is always guaranteed to be 0 when calling this). But
> maybe writing something like
>
> """
> if Width <= 0 then
> begin
> Result.Width := Width;
> Result.Left := Left;
> end else
> Writeln('This should never happen');
> """
>
> would make this clearer?
I updated the reproducer as you suggested. The behaviour is unchanged as below.
>
> The testcase definitely makes sense to me, and if you get different
> results on different CPUs -- then indeed we have nicely reproducible
> FPC bug.
The output on arm64
arm64:~/src/fpc-test$ ./test
S.Width=0 R.ScaleAround0(2).Width=214748364800
and on x86-64
x86-64$ ./test
S.Width=0 R.ScaleAround0(2).Width=0
I'll file a bug against the debian fpc package. What would be the best
way to bring this to upstream's attention?
>
> (P.S. I'm the castle-game-engine upstream author.)
Cool! Thanks a lot for looking over the findings. Very much appreciated.
test.pas
Description: Binary data
