[fpc-devel] Unexpected behaviour with intermediate results

J. Gareth Moreton gareth at moreton-family.com
Tue Jun 12 11:21:37 CEST 2018

 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

 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.


 On Tue 12/06/18 01:07 , "J. Gareth Moreton" gareth at moreton-family.com
 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?

 fpc-devel maillist - fpc-devel at lists.freepascal.org [1]


[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>

More information about the fpc-devel mailing list