[PATCH] XCore fix for SingleSource/Benchmarks/Misc-C++/Large/sphereflake

[robert lytton]

  Hi Daniel,

  The problem is that two doubles, which only differ in the fist (sign) and last bits, are added and the result compared to zero.
  The indeterminism is being injected by the initialisation using the sin() function, which in this one instance differs by the last bit.

  I have read around and can find no comment on how sin() results are rounded up or down or on their accuracy.
  The comment/implementation of LLVMsin() seems to support this problem:
      // LLVM LOCAL begin
      // Implementations of sin() and cos() may vary slightly in the accuracy of
      // their results, typically only in the least significant bit.  Round to make
      // the results consistent across platforms.

  The library implementation will have to return a result where the last bit has been rounded.
  The last bit is then further rounded by LLVMsin() - is this the same type of rounding as done by the library?
  It seems to me that if LLVMsin() is going to round it should not be rounding the last bit, but the last two bits - otherwise the two mechanism could accumulate error - as it seems to be doing in this situation.

  So:
  1. Is there a standard comment that identifies a non conformity?
  2. Should  LLVMsin() be doing any rounding at all, or should sin() be consistent across all libraries and targets?
  3. If  LLVMsin() is rounding, should it not be rounding the bottom two bits?

  Robert

http://llvm-reviews.chandlerc.com/D3022