Re: [Qemu-devel] [PATCH] libvixl: Add gcc format attribute

[Peter Maydell]

On 17 June 2014 22:07, Stefan Weil <address@hidden> wrote:
> This helps detecting wrong format strings.
>
> Signed-off-by: Stefan Weil <address@hidden>
> ---
>
> This patch is not intended to be applied before fixing some potential errors.
>
> Addings the GNU gcc format attribute results in lots of compiler errors like 
> these ones:
>
>   CXX   disas/libvixl/a64/disasm-a64.o
> disas/libvixl/a64/disasm-a64.cc: In member function ‘int 
> vixl::Disassembler::SubstituteImmediateField(vixl::Instruction*, const 
> char*)’:
> disas/libvixl/a64/disasm-a64.cc:1372:66: error: format ‘%d’ expects argument 
> of type ‘int’, but argument 3 has type ‘int64_t {aka long int}’ 
> [-Werror=format]
> disas/libvixl/a64/disasm-a64.cc:1421:52: error: format ‘%d’ expects argument 
> of type ‘int’, but argument 3 has type ‘int64_t {aka long int}’ 
> [-Werror=format]
> disas/libvixl/a64/disasm-a64.cc:1442:48: error: format ‘%d’ expects argument 
> of type ‘int’, but argument 3 has type ‘int64_t {aka long int}’ 
> [-Werror=format]
> disas/libvixl/a64/disasm-a64.cc:1449:42: error: format ‘%d’ expects argument 
> of type ‘int’, but argument 3 has type ‘int64_t {aka long int}’ 
> [-Werror=format]
>
> I don't know the reason, because all locations seem to have arguments
> which are function calls, and the called function returns Instr which
> is uint32_t, not int64_t.

As usual, I'm sceptical about carrying local libvixl patches
unless they're really necessary.

Which platform are you building on, and what does it
define uint32_t and int64_t as? I agree that it looks to me
like the compiler's wrong here, but maybe there's an integer
promotion rule for varargs I'm unaware of that means the
uint32_t gets promoted to int64_t ?

If the format strings really are wrong we can feed that back
to upstream libvixl and get them fixed there.

thanks
-- PMM