[fpc-devel] Unexpected behaviour with intermediate results

[Stefan Glienke]

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" <gareth at moreton-family.com> 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 - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel