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

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
> On 06/24/2014 02:24 PM, Al Viro wrote:
> > Al, off to figure out the black magic TCG is using to generate calls...
> 
> If you've a helper
> 
> DEF_HELPER_1(halt, void, i64)
> 
> then
> 
>   gen_helper_halt(...)
> 
> will generate the tcg ops that result in the call.

Another fun issue:

CVTTQ is both underreporting the overflow *AND* reports the wrong kind - FOV
instead of IOV.

	* it misses reporting overflows for case when it *knows* that
	  overflow will happen - the need to shift up by more than 63 bits.
	  Trivially fixed, of course.  There overflow cases leave wrong
	  result as well - should be 0.
	* it also misses reporting overflows for case when value is in
	  ranges 2^63..2^64-1 and -2^64+1..-2^63-1.  And yes, it's
	  asymmetric - 2^63 is an overflow, -2^63 isn't.
	* overflow is reported by float_raise(float_flag_overflow, &FP_STATUS).
	  Wrong flag - it should be IOV, not FOV.  And it should be set
	  in FPCR regardless of the trap modifier (IOV, this VI thing is
	  wrong - we should deal with that only when we generate a trap).
	* All overflow cases should raise INE as well.

Could we steal bit 1 in float_exception_flags for IOV?  It is (currently?)
unused -
enum {
    float_flag_invalid   =  1,
    float_flag_divbyzero =  4,
    float_flag_overflow  =  8,
    float_flag_underflow = 16,
    float_flag_inexact   = 32,
    float_flag_input_denormal = 64,
    float_flag_output_denormal = 128
};

That would allow to deal with that crap nicely - we could have it raise
the new flag, then have helper_fp_exc_raise_... for default trap mode
mask it out (and yes, we need to set FPCR flags in default mode, as well
as /U and /V - confirmed by direct experiment *and* by TFM).

If we can't... well, we could put that flag separately, but it would be
more unpleasant.  Folks?