#3596 _BitInt rotation issues

[Philipp Klaus Krause]

While working on optimizations for rotations in the next branch, I came up with another regression test (see attachment).
Unfortunately, some of it fails even for trunk. Depending on the port, some tests fail to compile, some fail at runtime.

P.S.: Attaching updated version of test that catches another stm8 issue.

[Philipp Klaus Krause]

After a first investigation, it looks like we have at least three separate bugs here.

The first one is in our optimization that when shifting a type by more than its width, we replace the result by 0. But it looks like two lines of code got swapped, so the 0 is of incorrect type. For all our other regression tests, the 0 ended up somehow okay - it tended to be either of the correct type or of type char, which then got promoted to int, which usually worked somehow. But if the correct type is a _BitInt that no longer works - _BitInt doesn't promote to int, so the char resulted in an assertion in type checks being triggered.

The attached patch fixes this first issue. It makes the new tests compile and pass for mcs51 and ds390. For other ports, there are still remaining failures.

[Philipp Klaus Krause]

A second problem is that code generation for z80 did sometimes omit the bit-masking necessary for _BitInt when left-shifting 1 _BitInt of width wider than 8 but narrower than 16 bits.

The attached patch fixes this issue. It makes the test pass for z80 and related, but there are still remaining issues for other ports.

[Philipp Klaus Krause]

For hc08, there were multiple issues. On was similar to the z80 one above (masking omitted on some shifts of _BitInt). The other was a register caching bug that was triggered when a shift by X was followed by a shift by X+1 or X-1 for wide types.

The attached patch fixes these issues. It makes the test pass for hc08 and related, but there are still remaining issues for other ports.

[Philipp Klaus Krause]

For pdk, it was not the left shift, but the bitwise or that was broken. For bitwise or between a 16-bit register operand and a 16-bit global operand, sometimes invalid asm was generated.

The attached patch fixes this issue, but there are still remaining issues for otehr ports (and for pdk ports when using --stack-auto).

[Philipp Klaus Krause]

For mos6502, the problems were essentially the same as for hc08.

The attached patch fixes them, but there is still a remaining issue for pdk with --stack-auto.

[Philipp Klaus Krause]

For pdk with --stack-auto, there was a bug in code generation for right shifts with the result on the stack, which overwrote register p, even if it was holding other iTemps alive at the same time.

The attached patch fixes this issue.

[Philipp Klaus Krause]

For stm8, there was an issue in code generation for left shifts that messed up the stack.

The attached patch fixes this issue.

[Philipp Klaus Krause]

Here is the full patch (containing the test and all fixes for the individual issues).

It should be reviewed to decide if it can go into trunk during the pre-4.3.0 freeze.

P.S.: Updated patch to fix ChangeLog entry.

[Philipp Klaus Krause]

Fixed in [r14110].