diff mbox

pseries: Fix compiler warning (conversion of pointer to integral value)

Message ID 1371676109-16313-1-git-send-email-sw@weilnetz.de
State Accepted
Headers show

Commit Message

Stefan Weil June 19, 2013, 9:08 p.m. UTC 
This kind of type cast must use uintptr_t or target_ulong to be portable
for hosts with sizeof(void *) != sizeof(long).

Here the value is assigned to a variable of type target_ulong.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
 hw/ppc/spapr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Alexander Graf June 19, 2013, 9:40 p.m. UTC | #1 
On 19.06.2013, at 23:08, Stefan Weil wrote:

> This kind of type cast must use uintptr_t or target_ulong to be portable
> for hosts with sizeof(void *) != sizeof(long).
> 
> Here the value is assigned to a variable of type target_ulong.
> 
> Signed-off-by: Stefan Weil <sw@weilnetz.de>

Acked-by: Alexander Graf <agraf@suse.de>

I suppose this one goes through the trivial tree?


Alex

> ---
> hw/ppc/spapr.c |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 218ea23..6e6f6a5 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -670,7 +670,7 @@ static void spapr_cpu_reset(void *opaque)
>     env->external_htab = spapr->htab;
>     env->htab_base = -1;
>     env->htab_mask = HTAB_SIZE(spapr) - 1;
> -    env->spr[SPR_SDR1] = (unsigned long)spapr->htab |
> +    env->spr[SPR_SDR1] = (target_ulong)spapr->htab |
>         (spapr->htab_shift - 18);
> }
> 
> -- 
> 1.7.10.4
>
Stefan Weil June 20, 2013, 4:40 a.m. UTC | #2 
Am 19.06.2013 23:40, schrieb Alexander Graf:
> On 19.06.2013, at 23:08, Stefan Weil wrote:
>
>> This kind of type cast must use uintptr_t or target_ulong to be portable
>> for hosts with sizeof(void *) != sizeof(long).
>>
>> Here the value is assigned to a variable of type target_ulong.
>>
>> Signed-off-by: Stefan Weil <sw@weilnetz.de>
> Acked-by: Alexander Graf <agraf@suse.de>
>
> I suppose this one goes through the trivial tree?
>
>
> Alex

If Michael pulls it to qemu-trivial, that's fine for me
(that's why I addressed my mail To: qemu-devel).

Of course I would not mind if someone with commit
rights commits it directly without waiting for a pull
request :-) Any patch with "Fix" in the subject is a
candidate for a direct commit.

Stefan
Michael Tokarev June 20, 2013, 5:10 a.m. UTC | #3 
20.06.2013 01:40, Alexander Graf wrote:
> 
> On 19.06.2013, at 23:08, Stefan Weil wrote:
> 
>> This kind of type cast must use uintptr_t or target_ulong to be portable
>> for hosts with sizeof(void *) != sizeof(long).
>>
>> Here the value is assigned to a variable of type target_ulong.
>>
>> Signed-off-by: Stefan Weil <sw@weilnetz.de>
> 
> Acked-by: Alexander Graf <agraf@suse.de>
> 
> I suppose this one goes through the trivial tree?

Anything which goes to -trivial can be applied directly or
into some other subsystem tree first.  When I send a pull
request I rebase trivial tree ontop of current master and
filter out anything which has been already applied, so that's
not an issue.  The only possible issue is when you applied
it to some other tree, and -trivial pull request were handled
before that other tree - how that will be handled by git?

Will it complain (so that the situation should be resolved
manually), will it apply nothing or will it appy an empty
patch?  (the patch signature will be different, with
different S-o-b.)  I think I've seen empty commits before
in qemu tree, with the same subject/author as some previous
commit.

Thanks,

/mjt
Mirza, Taimoor June 20, 2013, 5:33 a.m. UTC | #4 
Hi Guys, 
I am trying to run graphics demo application on QEMU system emulator using SDL on Windows XP. On running QEMU, its Window appears and then gets stuck. It seems some kind of deadlock to me. Same application runs fine on Windows 7 or if I use QEMU 0.15 on Windows XP. I found similar problem mentioned in http://permalink.gmane.org/gmane.comp.emulators.qemu/148857 but this patch is outdated now and function does not exist anymore.

Has anyone experienced something similar to it? As far as I can see, it looks to me that one thread acquires a lock during SDL_SetVideoMode and another thread keeps on waiting for it. Below are backtraces of one of the thread:

0  0x7c90e514 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll
#1  0x7e42c24e in USER32!DefWindowProcA () from C:\WINDOWS\system32\user32.dll
#2  0x7e42c291 in USER32!DefWindowProcA () from C:\WINDOWS\system32\user32.dll
#3  0x008a1322 in ioport_read_table ()
#4  0xfffffff0 in ?? ()
#5  0x14cf0000 in ?? ()
#6  0x7e42c2b2 in USER32!SetWindowLongA () from C:\WINDOWS\system32\user32.dll
#7  0x68135c4b in SDL_RegisterApp () from D:\temp\Sourcery_CodeBench_for_IA32_Windows\bin\SDL.dll
#8  0x6812bbb5 in SDL_SetVideoMode () from D:\temp\Sourcery_CodeBench_for_IA32_Windows\bin\SDL.dll
#9  0x00521645 in _fu10354____stack_chk_guard () at ui/sdl.c:109
#10 0x00521721 in _fu10357____stack_chk_guard () at ui/sdl.c:120
#11 0x0051ed0c in dpy_gfx_resize (s=0x20d2298) at d:/temp/qemu/qemu-1.4.2/qemu-1.4.2/include/ui/console.h:254
#12 _fu10213____stack_chk_guard () at ui/console.c:1596
#13 0x005cd580 in _fu15705____stack_chk_guard () at d:/temp/qemu/qemu-1.4.2/qemu-1.4.2/memory.c:364
#14 0x005d4404 in memory_region_dispatch_write (size=4, data=67881, addr=24, mr=0x20db6a8) at d:/temp/qemu/qemu-1.4.2/qemu-1.4.2/memory.c:916
#15 _fu15859____stack_chk_guard () at d:/temp/qemu/qemu-1.4.2/qemu-1.4.2/memory.c:1597
#16 0x005f95dc in io_writel (physaddr=<optimized out>, retaddr=41276164, addr=268566552, val=67881, env=0x2029148) at d:/temp/qemu/qemu-1.4.2/qemu-1.4.2/include/exec/softmmu_template.h:231
#17 slow_stl_mmu (retaddr=<optimized out>, mmu_idx=<optimized out>, val=<optimized out>, addr=<optimized out>, env=<optimized out>) at d:/temp/qemu/qemu-1.4.2/qemu-1.4.2/include/exec/softmmu_template.h:316
#18 _fu17435____stack_chk_guard () at d:/temp/qemu/qemu-1.4.2/qemu-1.4.2/include/exec/softmmu_template.h:269
#19 0x0275d453 in ?? ()

-Taimoor
Alexander Graf June 20, 2013, 8:48 a.m. UTC | #5 
Am 20.06.2013 um 07:10 schrieb Michael Tokarev <mjt@tls.msk.ru>:

> 20.06.2013 01:40, Alexander Graf wrote:
>> 
>> On 19.06.2013, at 23:08, Stefan Weil wrote:
>> 
>>> This kind of type cast must use uintptr_t or target_ulong to be portable
>>> for hosts with sizeof(void *) != sizeof(long).
>>> 
>>> Here the value is assigned to a variable of type target_ulong.
>>> 
>>> Signed-off-by: Stefan Weil <sw@weilnetz.de>
>> 
>> Acked-by: Alexander Graf <agraf@suse.de>
>> 
>> I suppose this one goes through the trivial tree?
> 
> Anything which goes to -trivial can be applied directly or
> into some other subsystem tree first.  When I send a pull
> request I rebase trivial tree ontop of current master and
> filter out anything which has been already applied, so that's
> not an issue.  The only possible issue is when you applied
> it to some other tree, and -trivial pull request were handled
> before that other tree - how that will be handled by git?
> 
> Will it complain (so that the situation should be resolved
> manually), will it apply nothing or will it appy an empty
> patch?  (the patch signature will be different, with
> different S-o-b.)  I think I've seen empty commits before
> in qemu tree, with the same subject/author as some previous
> commit.

It depends on how you handle the tree. I rebase ppc-next too, so the commit would simply vanish.

I'll apply it to ppc-next as well then.


Alex
diff mbox

Patch

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 218ea23..6e6f6a5 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -670,7 +670,7 @@  static void spapr_cpu_reset(void *opaque)
     env->external_htab = spapr->htab;
     env->htab_base = -1;
     env->htab_mask = HTAB_SIZE(spapr) - 1;
-    env->spr[SPR_SDR1] = (unsigned long)spapr->htab |
+    env->spr[SPR_SDR1] = (target_ulong)spapr->htab |
         (spapr->htab_shift - 18);
 }