In another thread I found an issue using gcc (any version) in 32-bit mode with the X87. The issue seemed to be the accumulation of truncation error. How it managed to do that with an 80-bit X87 truncating to 64-bit I don't know. The problem was solved by using SSE. How that managed to solve the problem is something I don't know either.
I am still looking into this but decided not to use the X87 in 32-bit mode. It is worth noting that PowerBASIC uses the X87 and gives us no choice. Having said that, PowerBASIC cannot have a choice because it has Extended Precision available and that is 80-bit arithmetic. Of course SSE could be used for the 'lesser' data types but Bob Zale probably decided to keep life simple and use only the X87 for everything. For all I know PowerBASIC may have a problem but I cannot test it against 64-bit, there isn't one, or another 32-bit compiler, there isn't one.
Now SetCompilerSwitchesII does not know if we are going to compile source code in 32-bit mode or 64-bit mode, so I decided to use SSE across the board. Both myself and srvaldez found that 64-bit mode didn't seem concerned whether we used the X87 or SSE. It may well be that 64-bit mode does not use the X87 so requesting it by default may get ignored. Requesting SSE when it isn't required won't do any harm as it will simply be surplus to requirements so using SSE across the board should be OK. What we will get is 32-bit mode using SSE and that is what we want.
Enter SetCompilerSwitchesII (V1.04) which inserts '-fpu sse' for us.
So if we choose 32-bit, an indeterminate -arch and '-gen gcc -Wc -O2' this is what we get
Code: Select all
-fpu sse -arch 686 -gen gcc -Wc -O2
I need to edit the Help file but I have run out of my writing Help file medication and need a new prescription. I wouldn't dare attempt an edit without my pills.
