Il 18/03/2014 16:01, Peter Maydell ha scritto:
By whether the backend or the frontend has trivial
access to the value to be able to avoid doing bad
things if it's out of range. If either do, they can
do a translate-time check to avoid issues. If neither
does then we need the host CPU architecture
On 03/18/2014 08:01 AM, Peter Maydell wrote:
> Unless all our host architectures have undefined-result
> behaviour for variable shifts by out of range values
> then we can't make the TCG op semantics do that.
> (They probably can; the only counterexample I know
> of is the 8086, where the variable-
On 18 March 2014 14:56, Richard Henderson wrote:
> On 03/18/2014 07:47 AM, Peter Maydell wrote:
>> The interesting question is not immediate shifts
>> but variable ones. It's trivially easy for the frontend
>> to avoid passing out of range immediate values
>> and for the backend to screen them out
On 18 March 2014 14:47, Peter Maydell wrote:
> On 18 March 2014 14:39, Richard Henderson wrote:
>> On 03/18/2014 07:25 AM, Peter Maydell wrote:
>>> Why do you think this? tcg/README says out of
>>> range shifts are undefined behaviour. That means we
>>> mustn't execute them, and this code doesn't
On 03/18/2014 07:47 AM, Peter Maydell wrote:
> The interesting question is not immediate shifts
> but variable ones. It's trivially easy for the frontend
> to avoid passing out of range immediate values
> and for the backend to screen them out. This
> case is a variable shift TCG op.
Exactly how a
On 18 March 2014 14:39, Richard Henderson wrote:
> On 03/18/2014 07:25 AM, Peter Maydell wrote:
>> Why do you think this? tcg/README says out of
>> range shifts are undefined behaviour. That means we
>> mustn't execute them, and this code doesn't attempt
>> to branch around or otherwise avoid the
On 03/18/2014 07:25 AM, Peter Maydell wrote:
> Why do you think this? tcg/README says out of
> range shifts are undefined behaviour. That means we
> mustn't execute them, and this code doesn't attempt
> to branch around or otherwise avoid the shift by -1.
Bah. Stuff and nonsense. None of our bac
On 18 March 2014 14:20, Richard Henderson wrote:
> On 03/18/2014 05:33 AM, Peter Maydell wrote:
>> In this case the constant propagation code is smart
>> enough to figure out that tmp1 is always zero at op 85,
>> and therefore tmp3 is -1 at op 87. It then tries to use
>> the shift constant of -1 i
On 03/18/2014 05:33 AM, Peter Maydell wrote:
> 0x7fe9a5f
> 82 mov_i64 tmp1,rcx
> 83 mov_i64 tmp0,rax
> 84 movi_i64 tmp13,$0x1f
> 85 and_i64 tmp1,tmp1,tmp13
> 86 movi_i64 tmp13,$0x1
> 87 sub_i64 tmp3,tmp1,tmp13
> 88 shl_i64 tmp3,tmp0,tmp3
> 89 shl_i64 tmp0,tmp0,tmp1
> 90 ext3
If you run 'make check' under clang's -fsanitize=undefined, then
(among other things) the acpi test provokes these warnings:
/home/petmay01/linaro/qemu-from-laptop/qemu/tcg/optimize.c:833:44:
runtime error: shift exponent 18446744073709551615 is too large for
64-bit type 'tcg_target_ulong' (aka 'u
10 matches
Mail list logo
