Oracle Developer Studio compilers generate code that usually performs similarly on SPARC and x86. However, be aware of the following important differences on x86-based systems:
The x87 floating-point registers are 80 bits wide. Because intermediate results of arithmetic computations can be in double extended (80-bit) precision when the x87 floating-point register stack is in use, computation results can differ. The –fstore flag minimizes these discrepancies. However, using the –fstore flag introduces a penalty in performance. While Oracle Developer Studio 12.5 does not use x87 registers by default for single and double precision expression evaluation, they are used if –xarch=386 is specified, or if the x87 hardware transcendental instructions are used, or if double-extended variables are used.
Each time a single or double precision floating-point number is loaded onto the x87 floating-point register stack or stored into memory, a conversion to or from double extended (80-bit) precision occurs. Thus loads and stores of floating-point numbers can cause exceptions. With –m32, floating-point subroutine operands and results are passed in x87 registers.
When the x87 floating-point register stack is in use, gradual underflow is implemented in hardware with microcode assist; there is no nonstandard mode.
There is no fpversion utility.
The double extended (80-bit) format admits certain bit patterns that do not represent any floating-point values (see Table 8). The hardware generally treats these "unsupported formats" as signaling NaNs, but the math libraries are not consistent in their handling of such representations. Since these bit patterns are never generated by the hardware, they can only be created by invalid memory references. such as reading beyond the end of an array, or from explicit coercions of data in memory from one type to another, via C's union construct, for example. Therefore, in most numerical programs, these bit patterns do not arise.