Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions

[Al Viro]

On Tue, Jun 24, 2014 at 05:34:23AM +0100, Al Viro wrote:
>       First of all, kudos - with current qemu tree qemu-alpha-system is
> working pretty well - debian install and a *lot* of builds work just fine.
> As in, getting from lenny to pretty complete squeeze toolchain, including gcj,
> openjdk6 and a lot of crap needed to satisfy build-deps of those, plus all
> priority:required and most of priority:important ones.  It's a _lot_ of
> beating and the damn thing survives - the problems had been with debian
> packages themselves (fstatat() bug in lenny libc, epically buggered build-deps
> in gcc-defaults, etc.).  As it is, one core of 6-way 3.3GHz phenom II is quite
> capable of running a home-grown autobuilder.  Feels like ~250-300MHz alpha
> with a very fast disk...
> 
>       Remaining problems, AFAICS, are around floating point traps.
> I've found one in glibc testsuite (math/tests-misc.c; overflow in
> ADDS/SU ends up with wrong results from fetestexcept() - only FE_OVERFLOW is
> set, while the sucker expects FE_INEXACT as well and actual hardware sets 
> both)
> and another in gcc one (with -funsafe-math-optimizations CVTST/S on denorms
> triggers SIGFPE/FPE_FLTINV).
> 
>       The libc one is a bug in gen_fp_exc_raise_ignore() - the difference
> between ADDS/SU and ADDS/SUI is only in trapping, not storing results in
> FPCR.INE and friends.  Both will have the same effect on those and
>     if (ignore) {
>         tcg_gen_andi_i32(exc, exc, ~ignore);
>     }
> in gen_fp_exc_raise_ignore() leads to exc & ignore not reaching the
> update of env->fpcr_exc_status in helper_fp_exc_raise_s().  See 4.7.8:
> [quote]
>       In addition, the FPCR gives a summary of each exception type for the 
>       exception conditions detected by all IEEE floating-point operates thus
>       far, as well as an overall summary bit that indicates whether any of
>       these exception conditions has been detected. The indiividual exception
>       bits match exactly in purpose and order the exception bits found in the
>       exception summary quadword that is pushed for arithmetic traps. However,
>       for each instruction, these exception bits arse set independent of the
>       trapping mode specified for the instruction. Therefore, even though
>       trapping may be disabled for a certain exceptional condition, the fact
>       that the exceptional condition was encountered by an instruction is
>       still recorded in the FPCR.
> [end quote]
> And yes, on actual hardware both ADDS/SU and ADDS/SUI set FPCR.INE the same
> way - verified by direct experiment.

BTW, here's another testcase:
nclude <stdio.h>

unsigned long __attribute__((noinline)) f(double x)
{
        return (unsigned long)x;        // SVCTQ/SVC
}

main()
{
        unsigned long x;
        extern unsigned long __ieee_get_fp_control(void);
        printf("before:%lx\n", __ieee_get_fp_control());
        x = f(1ULL<<63);
        printf("after:%lx\n", __ieee_get_fp_control());
        printf("result:%lx\n", x);
}

On actual hardware:
before:0
after:20000
result:8000000000000000

On qemu:
before:0
after:0
result:8000000000000000


IOW, gen_fcvttq() is also affected, not only gen_fp_exc_raise().

Can't we simply have separate helpers for various trap suffices, with
all this work on getting exc, etc. taken inside them?  It's not as if
we distinguished many variants, after all...  Right now we have:
        plain, /U, /V
        /S, /SU
        /SUI
        /SV
        /SVI
and /SU should probably be separated from /S - we do want to suppress underflow
traps on those (again, FPCR.UND should be set regardless).  That's what, 5 or 6
helpers?  Might want to separate /V and /U from plain - AFAICS, we get it
wrong with things like ADDS/U vs. ADDS (it's just that normally underflow
traps are disabled by FPCR.DUND).  I hadn't experimented with those yet, but
even if it turns out that they *are* different - 8 helpers instead of the 2 we
currently have, sharing most of the actual source...

Another thing: shouldn't arithmetics on denorms without /S raise EXC_M_INV,
rather than EXC_M_UNF?