Am 18.06.2014 00:09, schrieb Peter Maydell:
> On 17 June 2014 22:07, Stefan Weil <s...@weilnetz.de> wrote:
>> This helps detecting wrong format strings.
>>
>> Signed-off-by: Stefan Weil <s...@weilnetz.de>
>> ---
>>
>> 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
>
The platform is Debian wheezy (64 bit) with gcc-4.7.2, but I'm afraid
any of my builds shows these errors.
Stefan
