The real bug imo is that is that it even generates shl and shr instructions.
b := (a shl x) shr x should be just compile to b := a for x in 0..24 and a being 8bit (which is what several C++ compilers do afaik) > On 12 June 2018 at 02:07 "J. Gareth Moreton" <[email protected]> > wrote: > > > 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] > 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
