<div dir="ltr"><div><div><div><div><div><div><div><div>Following simple program gives different answers when compiling with GCC (4.8.4) and ToT Clang:<br><br></div>$ cat builtin_fmodf_bugpoint.cpp<br></div>#include <cstdio><br><br></div>int main(int argc, char** argv) {<br></div>  const float a = 1.0f;<br></div>  const float b = 0.1f;<br></div></div>  printf("%f mod %f = %f\n", a, b, __builtin_fmodf(a, b));<br></div>  return 0;<br><div><div><div><div><div>}<br></div><div>$ g++ -o builtin_fmodf_bugpoint_gcc builtin_fmodf_bugpoint.cpp<br>$ ./builtin_fmodf_bugpoint_gcc<br></div><div>1.000000 fmodf 0.100000 = 0.100000<br></div><div>$ clang++ -o builtin_fmodf_bugpoint_clang builtin_fmodf_bugpoint.cpp<br>1.000000 fmodf 0.100000 = 0.000000<br></div><div><br></div><div>Clang will compile __builtin_fmod() into LLVM's "frem" [1]. Since both operands are constant, it is constant folded by IRBuilder at the time when "frem" was built. The exeuction finally goes to llvm::ConstantFoldBinaryInstruction() which uses APFloat::mod() to compute the result. As you can see from above, it gives us 0.000000 (hex: 0x0) which is different than the answer from std::fmodf() (0.100000, hex: 0x3dcccccb).<br><br></div><div>SelectionDAG also uses APFloat::mod() to fold "frem" when operands are constants. (see SelectionDAG::getNode()). However, lli interprets "frem" to a fmod() and therefore generates the same result as GCC's.<br><br></div><div>$ lli -force-interpreter builtin_fmodf_bugpoint.ll<br>1.000000 fmodf 0.100000 = 0.100000<br><br></div><div>(Please refer to attachment for the .ll)<br><br></div><div>Are these expected? Which semantic does LLVM's "frem" stick to? Any idea on how to fix it?<br><br>[1] <a href="http://llvm.org/docs/LangRef.html#i-frem">http://llvm.org/docs/LangRef.html#i-frem</a><br><br></div></div></div></div></div></div>