Skip to content

cmd/compile: inconsistent signaling NaN behavior on mips64le #37455

Closed
@randall77

Description

@randall77

Compile and run the following C program:

#include <stdio.h>
#include <stdint.h>

double add0(double x) {
  return x+0;
}

int main(int argc, char *argv[]) {
  double snan64;
  *(uint64_t*)&snan64 = 0x7ff0000000000001;
  printf("snan64: %llx\n", *(uint64_t*)&snan64);
  double x = add0(snan64);
  printf("  add0: %llx\n", *(uint64_t*)&x);
}

On the linux-mips64le-mengzhuo builders, it prints

snan64: 7ff0000000000001
  add0: 7ff8000000000001

On the linux-mips64le-rtrk builders, it prints

snan64: 7ff0000000000001
  add0: 7ff0000000000001

Note that on the mengzhuo builder, the quiet bit gets set, whereas on the rtrk builder it does not.

This seems like a strange inconsistency. The assembly code for add0 is the same on both platforms.

It seems strange that the rtrk builder doesn't convert the NaN from signaling to quiet. add0 quiets the NaN for all the other Go platforms we support (amd64, powerpc, etc.). There are also strange inconsistencies with how it handles float32 <-> float64 conversions of signaling NaNs, which is how I first noticed this (#36399).

Is this expected behavor? Is this allowed by the spec? Might it be a bug in the rtrk builder? Is there some floating-point-signal-interrupt-control-word thingy we might need to set?

@mengzhuo @milanknezevic

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions