On 9 November 2015 at 13:40, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
> On 09/11/2015 14:30, Peter Maydell wrote:
>> After a bunch of "try building specific object files with optimization
>> off to see where the problem goes away" tests, I've narrowed the
>> problem down further: if you tell clang to disable optimization by
>> adding __attribute__ ((optnone)) to the two functions
>> hpet_time_after() and hpet_time_after64() in hw/timer/hpet.c then
>> the problem goes away.
>>
>> My current theory is that we're doing something here that's not
>> valid C and the compiler ends up optimizing it into something
>> that results in the timer setting the next-timeout to a very
>> short interval and that's what's hogging the main-loop time.
>> I'll look in more detail after lunch.
>
> The obvious way to write those functions would be
>
> static uint32_t hpet_time_after(uint64_t a, uint64_t b)
> {
> return ((int32_t)(b - a)) < 0;
> }
>
> static uint32_t hpet_time_after64(uint64_t a, uint64_t b)
> {
> return ((int64_t)(b - a)) < 0;
> }
Yep. I actually tried that just before lunch and it does indeed
cause the bug to go away.
-- PMM
