On Mon, 11 Mar 2019 at 14:35, Aleksandar Markovic <amarko...@wavecomp.com> wrote: > I'll doublecheck, but I think "infzero" here is a misnomer. > > The variable/argument "infzero" actually denotes the cases: > > - "Inf * Zero +/- NaN" > - "Inf * Zero +/- NaN" > - "Zero * Inf +/- NaN" > - "Zero * Inf +/- NaN" > > "Inf * Zero +/- !NaN (let's say, normal fp)" is handled > somewhere else. > > Therefore, "infzero" should be rather called "infzeronan". > This is from what I remember, but I will reanalyse the > relevant softfloat code one more time.
Yes; we don't ask the target-dependent code to pick a NaN in the case of 0 * inf + not-a-NaN because the IEEE spec entirely defines the behaviour there (you get the default NaN and Invalid is set), so that case is handled in the generic softfloat code. (The flag is called 'infzero' probably because in the calling code it indicates all the inf * zero cases, not just the info * zero + nan ones). It's specifically the (0,inf,qnan) and (inf,0,qnan) cases where the spec allows the implementation to decide whether they raise Invalid or not (and what qnan to return if they do), so this is why we pass that flag through to the pick-a-NaN routine. It looks like this part of the MIPS-specific code was incorrectly copied from the Arm implementation (which does return the default NaN here). As well as what the right NaN value should be, the other question for this function for the (0, inf, qnan) case is "should we raise Invalid?" -- what does the MIPS spec require here? thanks -- PMM
