On Wed, Jul 09, 2014 at 08:14:12AM -0700, Richard Henderson wrote: > On 07/08/2014 10:47 PM, Al Viro wrote: > > So env->fpcr_flush_to_zero = env->fpcr_dnod & env->fpcr_undz; is another > > bug - needs s/dnod/unfd/ there... > > That's exactly what I was looking at, thanks.
BTW, that (unimplementeds being RAZ) is why AARM insists on having FP_C in software - FPCR isn't guaranteed to have the "trap disable" bits and, in fact, doesn't have anywhere to store IEEE_TRAP_ENABLE_DNO on actual hw. The software completion is where it has to be dealt with; note that both swcr_update_status() and ieee_swcr_to_fpcr() treat ->ieee_state (i.e. our FP_C) as authoritative wrt trap enable bits, 21264 or not. Trap _status_ bits are different - there (on 21264) FPCR is considered authoritative, but that's it. Unimplemented trap bits are treated as "trap enabled", so the completion gets to decide what it wants to do. If you want to keep FPCR authoritative for all those bits in linux-user case, we have to treat FPCR.DNOD as writable bit for that mode, which is why my variant slapped an ifdef CONFIG_USER_ONLY around env->fpcr_dnod = (val & FPCR_DNOD) != 0; instead of ripping it out completely...