qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [PATCH] disas/libvixl/a64/instructions-a64.h: Remove


From: Chen Gang
Subject: Re: [Qemu-trivial] [PATCH] disas/libvixl/a64/instructions-a64.h: Remove useless varialbe to avoid building break with '-Werror'
Date: Fri, 10 Oct 2014 17:03:33 +0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2

On 10/10/14 16:53, Chen Gang wrote:
> On 10/10/14 15:37, Peter Maydell wrote:
>>>> The reason I'm reluctant to make changes to these files is
>>>> that they're pulled in from a different upstream project
>>>> (libvixl) so we should only fix critical problems in them,
>>>> or it makes new versions harder to update to.
>>>>
>>>
>>> Originally, I first try the Xilinx branch (Xilinx-master from Xilinx
>>> github), yesterday, and found this issue, then I try upstream main
>>> branch, found the same issue.
>>>
>>> For me, when add the related patch (which will use these variables in
>>> 'libvixl'), then declare and set them in the related headers, again.
>>> That will let other reviewers and readers easier understanding.
>>>
>>>  - removing them at present, is easy understanding.
>>>
>>>  - add them again when really need them, is also easy understanding.
>>
>> But it's all changes which we would have to carry locally
>> and then re-make every time we updated to a new libvixl.
>> I definitely don't want to do that unless it's absolutely
>> required.
>>
> 
> It is really a little complex, we almost can not touch this header file,
> sorry for my original misunderstanding.
> 
> And I guess, "disas/arm-64.cc" is our own file (only for qemu, not from
> libvixl upstream project). If really it is, we may do something in it to
> avoid this warning, e.g.
> 
>   "#pragma GCC diagnostic ignored -Wunused-variable" (almost like 
> "include/ui/qemu-pixman.h" have done).
> 

Oh, may need "-Wunused-but-set-variable" instead of "-Wunused-variable",
and also need check CONFIG_PRAGMA_DIAGNOSTIC_AVAILABLE (I guess the
latest gcc should be OK).

If what I guess is OK, I shall try to test it under both the latest gcc
for x86_64 and the host gcc under Fedora 20 x86_64. If they are all OK,
I shall send patch v2 for it.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed



reply via email to

[Prev in Thread] Current Thread [Next in Thread]