[fpc-devel] Unexpected behaviour with intermediate results

[J. Gareth Moreton]

 I will add though that Delphi apparently does the same thing, so if any
changes are made so precision is lost as expected (even though loss of
precision is usually not a desired trait), it shouldn't occur under
-mDelphi.

 Personally I'm under the opinion that precision should be lost because
that is the expected behaviour, as well as noting the fact that the
behaviour is different depending on if you're working with 32-bit numbers
compared to 8 or 16-bit values.

 Gareth

 On Tue 12/06/18 01:07 , "J. Gareth Moreton" gareth at moreton-family.com
sent:
  https://bugs.freepascal.org/view.php?id=33851
 Someone pointed out that if you perform "(x shl 8) shr 8", where x is of
type Word, the result is always x, even though logic dictates that the
upper 8 bits should be shifted out and hence the result actually be equal
to "x and $FF".  After analysing the assembly language that's produced, it
turns out that the optimiser works with the full 32-bits of the register. 
For example:

 is_this_a_bug:=((counter shl 8) shr 8);

 ...becomes the following under -O3 (under -O1, %r13w and %si are replaced
with references)...

 movzwl %r13w,%eax
 shl    $0x8,%eax
 shr    $0x8,%eax
 mox    %al,%si

 A similar situation happens if the variables are of type Byte as well -
the intermediate values use the full 32 bits of the register.

 I'm not certain if this is a bug or intended behaviour though.  Can
someone more senior make a decision on this?

 Gareth
  _______________________________________________
 fpc-devel maillist - fpc-devel at lists.freepascal.org [1]
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

 

Links:
------
[1] mailto:fpc-devel at lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180612/bbf09426/attachment.html>