Re: [Qemu-trivial] [PATCH v2] libvixl: a64: Skip "-Wunused-variable" for gcc 5.0.0 or higher

[Chen Gang <gang.chen.5i5j@gmail.com>]

On 10/15/2014 03:58 AM, Michael Tokarev wrote:
> On 11.10.2014 23:25, Peter Maydell wrote:
>> On 11 October 2014 15:13, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
>>
>> MJT: please don't put this in -trivial, it will clash with
>> the update to libvixl 1.6 currently on the list.
> 
> Actually I'd not put that to anywhere anyway.  Because to me,
> *especially* in a case like this when the code is imported from
> some other place and will be updated later (so we should not
> modify it), this issue can be more easily dealt with externally,
> by adding a compiler option in a Makefile.  Provided, ofcourse,
> that it is not fixed upstream properly to start with - and if
> it is (and this is the very sane way to go really, to fix it
> upstream), that fix can be pulled to qemu as well, so no
> clashes with further upstream changes will happen.
> 
> And aso because really, this prob should be fixed properly, not
> worked around like this..
> 

Within qemu, what you said sounds reasonable, but if we consider both
libvixl and qemu together, for me, I'like to fix it in related source
code.

Maybe I need send the related patch to libvixl firstly, then Cc to qemu.
If the patch can not pass libvixl's checking, but qemu still need, we
have to do in the way like what you said above.

By the way, originally, I misunderstood "Makefile.objs" under libvixl:
I thought they belong to libvixl, but in fact, they belong to qemu.

> []
>> Some other approaches to this that would confine the
>> fix to the makefiles rather than requiring us to modify
>> the vixl source itself:
>>   a) add a -Wno- option for the affected .o files
>>   b) use -isystem rather than -I to include the libvixl
>>      directory on the include path
>>
>> (a)'s probably better I guess.
> 
> That's what I'm after too (after trying to fix it properly).
> And no, at this time I dont know how gcc5 handles this.
> 

At present, I have sent the related information to gcc upstream mailing
list for gcc5, we are just discussing about it.

 - Some gcc members stick to what gcc5 has done is correct (need still
   report warning).

 - But for me, I am just trying to get another gcc members' confirmation.
   I am not quite familiar with C++, for me it is a complex language, so
   I need additional confirmation by another gcc members, at least.


Thanks.
-- 
Chen Gang

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