[01:57 PM][zplab@zpl-iscope:~]> python
Python 3.5.1 (default, May 31 2016, 20:46:24)
[GCC Intel(R) C++ gcc 6.1.1 mode] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2**39 * 1.596566081047058
877721485311.:
>>>
So, here we have Python 3.5.1 on Arch, built with the Intel C Compiler, version 16.0.3 20160415. We attempt to multiply two numbers. The result is represented as the string, "877721485311.:".
Two problems:
- 877721485311 is not the correct result.
- "877721485311.:" is not a valid string representation of a floating point number. jsonifying this nonsense therefore fails horrendously.
[01:59 PM][zplab@zpl-iscope:~/code_repositories]> python
Python 3.5.1 (default, Mar 3 2016, 09:29:07)
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2**39 * 1.596566081047058
877721485312.0
>>>
Python built with GCC produces correct results; Python built with a super ultra expensive vendor compiler produces bad results. Man, this really takes me back... The last time I dealt with a GCC vs vendor compiler correctness situation on a UNIX-like system was at least 15 years ago, with MIPS Pro, which I had modified to avoid time consuming license checks at each invocation. After restoring the unmodified version and instead cracking the FlexLM license server (yeah, sorry, as a student, I didn't have $16,995.00 to blow on shit that doesn't even fucking work, and cracking software on IRIX was hilariously easy - the license server was such a piece of junk you could use it from the guest account to overwrite any file on the entire system by manipulating the log path environment variable), the issue remained. So, the problem really was MIPS Pro, probably. This time around, in our modern world of bullshit, who even knows or cares? GCC works. Into the trash the Intel Compiler goes...
Post a Comment