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.
Description: Binary data