On Mon, Apr 04, 2016 at 08:46:17PM +0100, Peter Maydell wrote: > On 4 April 2016 at 20:42, Eduardo Habkost <ehabk...@redhat.com> wrote: > > On Mon, Apr 04, 2016 at 08:38:54PM +0100, Peter Maydell wrote: > >> On 4 April 2016 at 20:37, Eduardo Habkost <ehabk...@redhat.com> wrote: > >> > On Mon, Apr 04, 2016 at 02:31:47PM +0100, Peter Maydell wrote: > >> >> On 4 April 2016 at 14:21, Aleksandar Markovic > >> >> <aleksandar.marko...@imgtec.com> wrote: > >> >> > B. arm - explicitely sets other fields of float_status, > >> >> > explicit invocation of set_snan_bit_is_one(0) added > >> >> > >> >> We zero the float_status structs on reset, because they are earlier > >> >> in the CPUARMState structure than the 'features' field (and so the > >> >> memset() in arm_cpu_reset() will clear them). So you don't > >> >> need to explicitly zero a field like this. I expect the other > >> >> architectures are the same. > >> > > >> > Even if it is not zeroed on reset, it is zeroed on object_new(). > >> > Isn't that enough? > >> > >> It must be zeroed on reset, otherwise we won't get the right > >> behaviour if you reset the CPU after running it for a bit. > >> object_new() zeroing is not sufficient. > > > > The only calls to set_snan_bit_is_one() with non-zero arguments I > > see on this patch are during CPU init or reset. How exactly would > > the snan_bit_is_one field change to non-zero during runtime, to > > require zeroing it again on reset? > > I meant in general for these float_status flags, not anything > specific to this particular flag.
Sorry, I misunderstood you. I was talking about snan_bit_is_one, specifically. My point is that all the set_snan_bit_is_one(0, ...) calls on this patch are not necessary because object_new() already zeroed the field. -- Eduardo
