Closed as suggestion for future release.
When using optimization level -O3 and above, a -NaN value is being returned from the vec_extract vector built-in function. In this scenario, a double complex value is loaded into a vector4double datatype using a vec_ld2 vector built-in function. When the values are extracted from the vector4double, the result is an incorrect -NaN value. ===== CODE EXAMPLE ===== double complex test; test= 1+2*I; vector4double test_ex= vec_ld2(0, (double *)&test); double result = vec_extract(test_ex,0);
- Use a lower optimization level
The problem is due to an ansi aliasing violation in the usage of the 'vec_ld2' built-in function: vector4double test_ex= vec_ld2(0, (double *)&test); When optimization is disabled, the trivial case works because no assumptions are made about the data types being used. Casting the second parameter to (double *) is a violation of ansi aliasing rules, and will affect how the code gets optimized at higher opt levels, such as -O3. When this happens, bad code can be generated. The vec_ld2 built-in was not designed for use with complex data types. For complex datatypes, the vec_ld built-in should be used instead. The issue may also be worked around by compiling with the -qalias=noansi option, which tells the compiler that aliasing rules may be violated. Usage of this option limits the optimization potential of the program, so it should be used carefully. A related APAR, LI76958, may also affect aliasing cases using the vec_ld2 and vec_ld built-in functions.
Reported component name
XL C/C++ FOR BG
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following: