.ll output is different on windows

[llvmbot]

Bugzilla Link	6745
Resolution	FIXED
Resolved on	Mar 21, 2011 23:16
Version	trunk
OS	Windows XP
Blocks	llvm/llvm-bugzilla-archive#9099
Reporter	LLVM Bugzilla Contributor
CC	@Bigcheese,@efriedma-quic,@ismail

Extended Description

I don't have a windows machine to test on, but it looks like we print 0.0 as "double 0.000000e+00" on linux and as "double 0.000000e+000" on windows.

Possible testcase:

void foo(double a);
void bar(void) {
foo(0.0);
}

[llvmbot]

That probably comes down to a difference in the standard library behavior. Why would it be a problem?

[efriedma-quic]

Consistency; it seems generally bad if the output of llvm-dis on the same .bc file isn't the same on all platforms. It's not really a huge issue, but it would be nice to fix.

[lattner]

I tried this trivial patch:
+++ lib/VMCore/AsmWriter.cpp (working copy)
...
SmallString<128> StrVal;

•  raw_svector_ostream(StrVal) << Val;
  

•  CFP->getValueAPF().toString(StrVal);
  

But it doesn't work. It looks like APFloat prints 1.0 as 1 and -0.0 as 0.

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#7668 has been marked as a duplicate of this bug. ***

[llvmbot]

Also unittests/Support/raw_ostream_test.cpp fails by similar reason.

[llvmbot]

I think Bug 7668 oughta be the root cause.

[llvmbot]

Fix 0\d\d$ -> \d\d
Kludge for this on raw_ostream.cpp.
Some tests(and unittests/Support/raw_ostream should pass.

I'm not care of INF, QNAN and SNAN.

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#8227 has been marked as a duplicate of this bug. ***

[llvmbot]

Created an attachment (id=5442) [details]
Fix 0\d\d$ -> \d\d

The last patch was useless. Here is a new one.

--- a/lib/Support/raw_ostream.cpp
+++ b/lib/Support/raw_ostream.cpp
@@ -208,6 +208,20 @@ raw_ostream &raw_ostream::operator<<(const void *P) {
}

raw_ostream &raw_ostream::operator<<(double N) {
+#if LLVM_ON_WIN32

• char buf[32];
• int len = snprintf(buf, sizeof(buf), "%e", N);
• if (len >= 4 && buf[len - 3] == '0') {
• int c1 = buf[len - 2];
• int c0 = buf[len - 1];
• if (isdigit(c1) && isdigit(c0)) {

•  buf[len - 3] = c1;
  

•  buf[len - 2] = c0;
  

•  buf[--len] = 0;
  

•  return this->operator<<(buf);
  

• }
• }
  +#endif
  return this->operator<<(format("%e", N));
  }

[llvmbot]

That's fairly ugly, but at least the ugliness is inside WIN32:) OK with me.

[llvmbot]

That's fairly ugly, but at least the ugliness is inside WIN32:) OK with me.

Here is the update version:

http://msdn.microsoft.com/en-us/library/0fatw238%28VS.80%29.aspx

raw_ostream &raw_ostream::operator<<(double N) {
#if LLVM_ON_WIN32
char buf[32];
unsigned int old_exponent_format = _set_output_format(_TWO_DIGIT_EXPONENT);
snprintf(buf, sizeof(buf), "%e", N);
_set_output_format( old_exponent_format );
return this->operator<<(buf);
#else
return this->operator<<(format("%e", N));
#endif
}

[llvmbot]

I have written "our floating point formatter."

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110314/118165.html

Checked only on mingw.

[llvmbot]

I have committed a dirty fix in r127872.

I will not forget the right fix, to implement our formatter.

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#7668

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#8227