I am trying to enable software floating point under gcc following suggestions in this question but I've hit a snag:
The -msoft-float flag causes:
/usr/include/c++/4.8.2/bits/basic_string.h: In function ‘long double std::stold(const string&, std::size_t*)’:
/usr/include/c++/4.8.2/bits/basic_string.h:2857:47: error: x87 register return with x87 disabled
stold(const string& __str, size_t* __idx = 0)
^
and -mno-sse causes:
/usr/include/c++/4.8.2/bits/basic_string.h: In function ‘float std::stof(const string&, std::size_t*)’:
/usr/include/c++/4.8.2/bits/basic_string.h:2849:46: error: SSE register return with SSE disabled
stof(const string& __str, size_t* __idx = 0)
^
There are a couple of questions which mention this error but in relation to kernel programming which doesn't help.
All that is happening in basic_string is the functions are returning floats or doubles. Why does this cause a compilation failure?
More importantly, what can I do about it?
Background
I have found a difference in behaviour for a C++ application on two different platforms:
- Intel(R) Xeon(R) CPU E5504
- Intel(R) Core(TM) i5-3470 CPU
Code compiled natively on either machine runs on the other but for one test the behaviour depends on which machine the code is run on.
Clarification The executable compiled on machine A behaves like the executable compiled on machine B when copied to run on machnie B and visa versa.
It could an uninitialised variable or many other things but I suspect that the cause could be non-portable use of floating point. Perhaps one machine is interpreting the float point assembly differently from the other? I want to test my hypothesis. I thought if I could force the program to use (ideally strict IEE 754) software floating point it might confirm or rule that out. Its not my code and I have no desire to completely rewrite it to test this. Recompiling is fine though.
Related to this I have asked a separate question how-to-detect-differences-in-floating-point-behaviour-across-platforms tackling the question from the other side.
