On 18 June 2014 18:27, Stefan Weil wrote:
> Am 18.06.2014 17:19, schrieb Richard Henderson:
>>
>> On 06/17/2014 09:45 PM, Stefan Weil wrote:
>>>
>>> Variable arguments usually are not converted to 64 bit values: if
>>> they are smaller than int, they are expanded to int, and larger
>>> values are
On 18 June 2014 18:27, Stefan Weil wrote:
> So each of those functions really returns an int64_t which of course
> should not use a "%d" format string.
Forgot to mention, I'm happy to take a patch which fixes these
locally pending our next libvixl update.
thanks
-- PMM
Am 18.06.2014 17:19, schrieb Richard Henderson:
>
> On 06/17/2014 09:45 PM, Stefan Weil wrote:
>>
>> Variable arguments usually are not converted to 64 bit values: if
>> they are smaller than int, they are expanded to int, and larger
>> values are passed as they are. But here obviously the compiler
On 06/17/2014 09:45 PM, Stefan Weil wrote:
> Variable arguments usually are not converted to 64 bit values: if they
> are smaller than int, they are expanded to int, and larger values are
> passed as they are. But here obviously the compiler expands uint32_t to
> int64_t. Why?
They really really s
Il 18/06/2014 06:45, Stefan Weil ha scritto:
A 32 bit build on Ubuntu gcc-4.6.3-1ubuntu5 just finished and shows the
same error messages, so really all of my builds show them (32 and 64
bit, Linux native and cross for Windows).
Peter, I know that libvixl is external code, but posted this patch
b
On 18 June 2014 05:45, Stefan Weil wrote:
> A 32 bit build on Ubuntu gcc-4.6.3-1ubuntu5 just finished and shows the
> same error messages, so really all of my builds show them (32 and 64
> bit, Linux native and cross for Windows).
>
> Peter, I know that libvixl is external code, but posted this pa
Am 18.06.2014 06:31, schrieb Stefan Weil:
> Am 18.06.2014 06:28, schrieb Richard Henderson:
>>> 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.
>> ...
>>> + void GCC_FMT_AT
Am 18.06.2014 06:28, schrieb Richard Henderson:
>> 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.
> ...
>> + void GCC_FMT_ATTR(2, 3) AppendToOutput(const char* string, ...);
> 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.
...
> + void GCC_FMT_ATTR(2, 3) AppendToOutput(const char* string, ...);
It "helps" because 2,3 is wrong. Correct would be 1
Am 18.06.2014 00:09, schrieb Peter Maydell:
> On 17 June 2014 22:07, Stefan Weil wrote:
>> This helps detecting wrong format strings.
>>
>> Signed-off-by: Stefan Weil
>> ---
>>
>> This patch is not intended to be applied before fixing some potential errors.
>>
>> Addings the GNU gcc format attrib
On 17 June 2014 22:07, Stefan Weil wrote:
> This helps detecting wrong format strings.
>
> Signed-off-by: Stefan Weil
> ---
>
> 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 o
This helps detecting wrong format strings.
Signed-off-by: Stefan Weil
---
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
12 matches
Mail list logo
