On Fri, Oct 02, 2015 at 02:07:32PM +0200, Paolo Bonzini wrote:
> On 02/10/2015 13:14, Laszlo Ersek wrote:
> > On 10/02/15 10:34, Paolo Bonzini wrote:
> >> On 01/10/2015 21:17, Laszlo Ersek wrote:
> >>> - In the firmware, allocate an array of bytes, dynamically. This array
> >>> will have no decla
On 02/10/2015 13:14, Laszlo Ersek wrote:
> On 10/02/15 10:34, Paolo Bonzini wrote:
>> On 01/10/2015 21:17, Laszlo Ersek wrote:
>>> - In the firmware, allocate an array of bytes, dynamically. This array
>>> will have no declared type.
>>>
>>> - Populate the array byte-wise, from fw_cfg. Because
On 10/02/15 10:34, Paolo Bonzini wrote:
>
>
> On 01/10/2015 21:17, Laszlo Ersek wrote:
>> - In the firmware, allocate an array of bytes, dynamically. This array
>> will have no declared type.
>>
>> - Populate the array byte-wise, from fw_cfg. Because the stores happen
>> through character-typ
On 01/10/2015 20:40, Laszlo Ersek wrote:
> > Also strict aliasing improves performance noticeably at least on some
> > kind of code. The relaxation of strict aliasing that GCC does with
> > unions would be a useful addition to the C standard, though.
>
> What do you mean under "relaxation of str
On 01/10/2015 21:17, Laszlo Ersek wrote:
> - In the firmware, allocate an array of bytes, dynamically. This array
> will have no declared type.
>
> - Populate the array byte-wise, from fw_cfg. Because the stores happen
> through character-typed lvalues, they do not "imbue" the target
> obj
Peter Maydell writes:
> On 1 October 2015 at 18:30, Paolo Bonzini wrote:
>>
>>
>> On 01/10/2015 19:07, Laszlo Ersek wrote:
>>> > In addition, C89 didn't say at all what the result was for signed data
>>> > types, so technically we could compile QEMU with -std=gnu89 (the default
>>> > until GCC5)
On 10/01/15 19:38, Peter Maydell wrote:
> On 1 October 2015 at 18:30, Paolo Bonzini wrote:
>>
>>
>> On 01/10/2015 19:07, Laszlo Ersek wrote:
In addition, C89 didn't say at all what the result was for signed data
types, so technically we could compile QEMU with -std=gnu89 (the default
>>>
On 10/01/15 19:30, Paolo Bonzini wrote:
>
>
> On 01/10/2015 19:07, Laszlo Ersek wrote:
>>> In addition, C89 didn't say at all what the result was for signed data
>>> types, so technically we could compile QEMU with -std=gnu89 (the default
>>> until GCC5) and call it a day.
>>>
>>> Really the C st
On 1 October 2015 at 18:30, Paolo Bonzini wrote:
>
>
> On 01/10/2015 19:07, Laszlo Ersek wrote:
>> > In addition, C89 didn't say at all what the result was for signed data
>> > types, so technically we could compile QEMU with -std=gnu89 (the default
>> > until GCC5) and call it a day.
>> >
>> > Re
On 01/10/2015 19:07, Laszlo Ersek wrote:
> > In addition, C89 didn't say at all what the result was for signed data
> > types, so technically we could compile QEMU with -std=gnu89 (the default
> > until GCC5) and call it a day.
> >
> > Really the C standard should make this implementation-define
On 10/01/15 15:52, Paolo Bonzini wrote:
>
>
> On 01/10/2015 11:24, Peter Maydell wrote:
>> On 30 September 2015 at 21:24, Richard Henderson wrote:
>>> On 09/30/2015 11:27 PM, Paolo Bonzini wrote:
ps: Ego ceterum censeo that these warnings are useless and uglify the
code unnecessarily.
On 01/10/2015 11:24, Peter Maydell wrote:
> On 30 September 2015 at 21:24, Richard Henderson wrote:
>> On 09/30/2015 11:27 PM, Paolo Bonzini wrote:
>>> ps: Ego ceterum censeo that these warnings are useless and uglify the
>>> code unnecessarily. But it looks like I'm in a minority so the patch
On 30 September 2015 at 21:24, Richard Henderson wrote:
> On 09/30/2015 11:27 PM, Paolo Bonzini wrote:
>> ps: Ego ceterum censeo that these warnings are useless and uglify the
>> code unnecessarily. But it looks like I'm in a minority so the patch is
>> okay.
> I totally agree. There are no one
On 30/09/2015 22:24, Richard Henderson wrote:
> On 09/30/2015 11:27 PM, Paolo Bonzini wrote:
>>
>>
>> On 29/09/2015 22:34, Eduardo Habkost wrote:
>>> Fix undefined behavior detected by clang runtime check:
>>>
>>>qemu/target-i386/cpu.c:1494:15: runtime error:
>>> left shift of 1 by 31 pl
On 09/30/2015 11:27 PM, Paolo Bonzini wrote:
On 29/09/2015 22:34, Eduardo Habkost wrote:
Fix undefined behavior detected by clang runtime check:
qemu/target-i386/cpu.c:1494:15: runtime error:
left shift of 1 by 31 places cannot be represented in type 'int'
While doing that, add extra
On 29/09/2015 22:34, Eduardo Habkost wrote:
> Fix undefined behavior detected by clang runtime check:
>
> qemu/target-i386/cpu.c:1494:15: runtime error:
> left shift of 1 by 31 places cannot be represented in type 'int'
>
> While doing that, add extra parenthesis for clarity.
>
> Reporte
Fix undefined behavior detected by clang runtime check:
qemu/target-i386/cpu.c:1494:15: runtime error:
left shift of 1 by 31 places cannot be represented in type 'int'
While doing that, add extra parenthesis for clarity.
Reported-by: Peter Maydell
Signed-off-by: Eduardo Habkost
---
targ
17 matches
Mail list logo
