Compiler/TMS320C6678: nan is output by log calculation.

user1432743 said:

(If math.h is not included, I think compilation will not pass.)

Well, that's not the case for most C programs.  If math.h isn't included, the compiler will guess prototypes for functions based on the types of the arguments and the "default argument promotions."  You don't want to have to figure this out; just please always double-check that you've math.h included when you use math functions.  You can be extra-safe by adding the compiler option --diag_error=225 so that the compiler emits an error when one forgets to include math.h.

Now as for the bug at hand, there is only one copy of log in the program.  If it operates correctly on Core 1, it will work correctly on every core.  Similarly, if it operates correctly the first time it is called, it should work correctly the second time it is called.  I strongly suspect that the bug is not in log itself, but in the code that calls log.

Please note that you are calling two distinct functions, log and logf.  Even though they perform the same operation, they do it with different precision, so they are two different functions.  Also note that in your example, logf consistently returns the correct answer.

Now we need to discuss the type conversions.  The function log takes a double operand and returns a double result.  The function logf takes a float operand and returns a float result.  The compiler will insert type conversions as necessary to force the arguments to the correct type.

When you call log((double)2.0f), you get what you expect... the compiler converts the float constant 2.0f to a double value (2.0) and passes that to log.

When you call log(2.0f), on the other hand, the compiler again converts the float constant to a double value (2.0) and passes that.

When you call log(2.0), the compiler does no conversion and passes the double value (2.0) to log.

The compiler will also insert type conversions as necessary to convert the return values of these functions before they are assigned to the variables "tempN".

When you write "temp1 = log((double)2.0f)", the compiler converts the double result of log (0.69 roughly) to a float value (0.69f roughly) and assigns that to temp1.

When you write "temp2 = (float)log(2.0f)", you have already converted the double result of log to a float value with an explicit cast."

When you write "temp4 = log(2.0)", the compiler again inserts an implicit conversion of the double return value (0.69) to a float value (0.69f)

Thus, in the lines of your test involving temp1, temp2, and temp4, you should expect that they will always get exactly the same answer, because you are calling the same function (log) with the same value (2.0 is exactly representable as 2.0f, with no roundoff error), and getting the same result after conversion to float (0.69f).

Now it gets a little weird.

When you pass a floating point type to a variadic function (has an ... argument) such as printf or platform_write, the compiler does "default argument promotion."  In particular, any value of type "float" will be converted to "double" before being passed to platform_write.  Your implementation of platform_write must use va_arg(ap, double) to fetch a double value; it won't be a float value.  Please double-check this.  Also, you are required to have a valid prototype in scope before you call such a function.  For printf, you must include stdio.h.  For your function, it must be prototyped like so: int platform_write(const char *, ...).  If this prototype is not visible when you call platform_write, all sorts of weird things can happen.

Okay, now that the easy things that you should check first are out of the way, let's consider the symptoms.

You show that the function returned the correct value at least once before starting to produce an incorerct value - this is just not how the math functions operate.  Given the same input, they should return the same output every time.  I suspect that the inputs have changed.  Knowing how the compiler works, I know that the compiler will have converted all of the constant arguments to log to double constants, and stored them in a constant table.  Despite the fact that the arguments to log are of different types in the source code, they can all be represented by a single double constant, as noted above.  The argument to logf will be a separate constant, because it will be kept as a float constant.  Now, suppose that some write through some stray pointer happens to write into the constant table and just so happens to stomp on the constant 2.0.  Now, the compiler will dutifully load from the constant table to pass the value to log, not knowing the value had been corrupted elsewhere.  This would explain your symptoms of getting the correct answer for a while, and then suddenly getting bogus answers forevermore.  The problem here is that the stray pointer could have come from anywhere; perhaps a bug in the compiler, perhaps a bug in your application.  It's just not possible to rule out such a possibility without looking at the entire program.

You should at least set a breakpoint in Func and observe the value being passed to log; you should see a double value being loaded from a constant table and written to A4 [edited --Archaeologist].  Knowing whether that double value is correct or not will be a huge help in determining where to look for the bug.

In summary:

• I doubt that there is a compiler bug here because the symptoms do not match what I would expect a compiler bug to look like.
• More analysis is required before the compiler team could even begin to look at this.
• My bet is on a memory clobbering problem.