On Wed, Jun 25, 2014 at 10:27:11AM +0100, Peter Maydell wrote: > I think it's OK to put extra float_flags in, provided you can define > their semantics in terms that make sense for more than one > architecture (even if only one arch actually happens to need them). > The input_denormal/output_denormal flags only get used for ARM, > for instance. However if you wanted to split overflow from integer > overflow you'd need to fix up all the other targets which expect > them to generate just one exception flag...
Hmm... On alpha it's generated only by the following: CVTTQ, CVTGQ, CVTQL. I.e. conversions to integer formats that can be held in FPU registers (double -> s64, VAX double -> s64 and s64 -> s32). Does softfloat even have anything similar? As it is, it's all in alpha-specific code; double -> s64 might have a chance to be generic (semantics: * denorms -> 0, raise "inexact", provided that they survived to that point and hadn't buggered off with "invalid" * exact integers in range -2^63 .. 2^63-1 -> equivalent 64bit integer * values outside of that range (all with zero fractional part, since the weight of LSB of significand will be considerably greater than 1 by that point) -> lower 64 bits of value, raise "integer overflow" and "inexact". * values with non-zero fractional part -> rounded according to rounding mode, raise "inexact". ), but existing float64_to_int64() isn't it - very different behaviour on overflows. Incidentally, VAX double to s64 is buggered in that area - it *does* try to use float64_to_int64() and, on top of getting INV instead of IOV, gets the wrong result in case of overflow (MAX_LONG/MIN_LONG instead of value in -2^63..2^63-1 comparable modulo 2^64 with exact value taken as element of $\Bbb Z$). And s64->s32 is just plain weird - not in the part that has IOV raised on values outside of -2^31..2^31-1, but in the bit shuffling it's doing if the test passes; alpha FPU stores s32 value in bits 63-62/58-29, with the rest filled with zeroes. In any case, it's not splitting float_overflow_flag; similar cases in softfloat.c raise float_invalid_flag. I don't know if it would make sense to try and teach float64_to_int64() about this kind of return value on overflow... > (Note that any patch touching softfloat files needs to come with > a statement that you're happy to license it under either the > softfloat-2a or softfloat-2b licenses, because we're currently > midway through the tedious process of trying to relicense it.) Wouldn't be a problem, but I doubt that it would be particulary useful to touch softfloat.c due to the reasons above, anyway.