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" [email protected] 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 - [email protected] [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:[email protected] [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
