On 10/12/14 5:25, Peter Maydell wrote: > On 11 October 2014 15:13, Chen Gang <gang.chen.5...@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. >
OK thanks (also remove -trivial from replying mailing list). > >> On 10/11/14 22:07, Chen Gang wrote: >>> 'instructions-a64.h' has unused variables for qemu which can be found by >>> gcc 5.0.0 or higher. and qemu needs "-Werror", and cause building break. >>> But they may be used by another projects (not qemu). >>> >>> So for gcc 5.0.0 or higher, need still keep them, but ignore diagnostic >>> (still print warning, but not break building). The related warnings: >>> >>> CXX disas/arm-a64.o >>> In file included from /upstream/qemu/disas/libvixl/a64/disasm-a64.h:32:0, >>> from disas/arm-a64.cc:20: >>> disas/libvixl/a64/instructions-a64.h:98:13: error: >>> 'vixl::kFP32PositiveInfinity' defined but not used [-Werror=unused-variable] >>> const float kFP32PositiveInfinity = rawbits_to_float(0x7f800000); >>> ^ >>> disas/libvixl/a64/instructions-a64.h:99:13: error: >>> 'vixl::kFP32NegativeInfinity' defined but not used [-Werror=unused-variable] > > So, several questions here: > > (1) Does anybody know how the header in question should be > providing constant floats and doubles to its users in a way > that doesn't cause gcc to complain? If so, I can pass the > answer along so at least the next version of the library > is OK... > Hmm... may try to simplify rawbits_to_float() and rawbits_to_double() to let gcc know about it is only for constant? (it seems original authors intended to do it in function, I shall try to know why) I shall try to get a conclusion within this month. > (2) Bonus question, anybody know why gcc is perfectly happy > with the unused integer constants in the .h file but doesn't > like the float and doubles? > For (2), they use a real function rawbits_to_float(), is it gcc own issue? I shall try to analyze it (at present, I am also upstream gcc members, and make a patch for it per month). I shall try to finish analyzing within this month. > (3) Does gcc 5 emit these warnings for all the .cc files > that pull in this header, or only for the arm-a64.cc one? > For (3), yes, it is, so I have to let it in header again. > 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 It is one way, but may have effect with gcc 4 version, and also it is effect with the whole file which is wider than current way. > b) use -isystem rather than -I to include the libvixl > directory on the include path > It sounds good to me, although for me, it is not related with current issue. Thanks -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
