| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This test was failing on 32-bit because it made
the assumption that 'long' is always 64-bit.
Fix this by using 'long long' when 64-bit is needed.
Fixes 36a75754ba161b4ce905390cf5b0ba9b83b34cd2
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The result of a shift-assigns has the same type as the left
operand but the shift itself must be done on the promoted type.
The usual conversions are not done for shifts.
The problem is that this promoted type is not stored explicitly
in the data structure. This is specific to shift-assigns because
for other operations, for example add-assign, the usual conversions
must be done and the resulting type can be found on the RHS.
Since at linearization, the LHS and the RHS must have the same type,
the solution is to cast the RHS to LHS's promoted type during
evaluation.
This solve a bunch of problems with shift-assigns, like doing
logical shift when an arithmetic shift was needed.
Fixes: efdefb100d086aaabf20d475c3d1a65cbceeb534
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
When doing a shift operation, both arguments are subjected to
integer promotion and the type of the result is simply the type
of the promoted left operand. Easy.
But for a shift-assignment, things are slightly more complex:
-) 'a >>= n' should be equivalent to 'a = a >> n'
-) but the type of the result must be the type of the left
operand *before* integer promotion.
Currently, the linearization code use the type of the right
operand to infer of the type of the operation. But simply changing
the code to use the type of the left operand will also be wrong
(for example for signed/unsigned divisions). Nasty.
For example, the following C code:
int s = ...;
s >>= 11U;
is linearized as a logical shift:
lsr.32 %r2 <- %arg1, $11
while, of course it's an arithmetic shift that is expected:
asr.32 %r2 <- %arg1, $11
So, add a testcase for these.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
