This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MATHLIB Bug: _atan2dp corrupts *A0 if Y == 0.0 and X != 0.0

Other Parts Discussed in Thread: MATHLIB

Edit: This bug appears in all current releases of MATHLIB (http://www.ti.com/tool/mathlib), not only C67X-MATHLIB.

I would be very surprised if there was another C67X-MATHLIB release (the last was in 2010), but I wanted to report this bug in the hope that it might help someone else down the road. The error is on line 259 of atan2dp.asm.

||[A2]  stw     B6, *A0         ; Y=0, _errno = EDOM if (Y,X) = (0,0)

It might take a little time to work through the assembly, but this store must not be executed unless both the Y and X arguments are 0.0 (this is indicated by the comment at the end of the line). However, this store is incorrectly executed when Y is 0.0 and X is not 0.0. In that case, A0 has not been loaded with the address of _errno (lines 246 and 248). Thus, storing B6 to *A0 corrupts whatever is in the location pointed to by A0.

  • 'Butters',

    Can you supply the following, please?

    - C code example that illustrates a wrong value returned for a certain set of arguments to atan2dp()
    - To make sure we are looking at the same thing, which C67X-MATHLIB release number are you referencing?
    - Also, on which specific DSP device and platform are you executing this?

    If we can duplicate this error with your help, we can at least make sure it does not propagate through our more recent DSP architectures. I cannot comment on any new release for C67X-MATHLIB, but a fix should at least be mentioned, in my opinion but not in my control.

    Thank you for taking the time to report this, and your help so we can get it identified and handled in one way or another.

    Regards,
    RandyP
  • RandyP said:
    'Can you supply the following, please?

    - C code example that illustrates a wrong value returned for a certain set of arguments to atan2dp()

    It the context this is an unreasonable request. Reread last sentence from originating post. "Thus, storing B6 to *A0 corrupts whatever is in the location pointed to by A0." First of all you have no control over how compiler uses A0 [not to mention that it can depend on compiler options and that A0 value is result of call history], and secondly, side effects might not be fatal and even considered benign for an example code. Presumably that's how it went unnoticed for such long time.


    RandyP said:
    '- To make sure we are looking at the same thing, which C67X-MATHLIB release number are you referencing?

    I can confirm the presence of the bug even in C66 version on mathlib 3.0.1.1 (delivered with CCSv5).


    RandyP said:
    '- Also, on which specific DSP device and platform are you executing this?

    Out of curiosity, how does it matter?

  • Hello RandyP,

    • I'm sorry, but I am currently unable to spend time on creating a C code example that demonstrates the problem. Andy is correct that the C example would need to be carefully crafted to show the bug.
    • I am using the latest version of C67X-MATHLIB (c67xmathlib_2_01_00_00_Windows_Setup.exe) from http://www.ti.com/tool/mathlib.
    • We encountered the bug in one of our TMS320C6713-based products.

    Best regards,
    Dave

  • RandyP, I wanted to let you know that I downloaded the latest version of C674X-MATHLIB (mathlib_rts_c674x_3_1_1_0_Win32.exe built June 9, 2015) from www.ti.com/tool/mathlib and the offending assembly code is in that release as well.

  • Replacement atan2dp.asm that can simply be added to project to override buggy mathlib

    atan2dp.asm

    and crash_atan2dp.asm that triggers return to address other than original return address (any kind of crash/corruption can be triggered)

    crash_atan2dp.asm

  • RandyP,

    Hello again. I just wanted to ping this issue and make sure that it isn't forgotten about (at least unintentionally). I expect this is a bug that TI will want to address because it is still present in the currently supported releases of MATHLIB. Would it be possible for me to get an Incident Report number for tracking purposes?
    Best regards,
    Dave
  • Dave,

    Updating MATHLIB and DSPLIB Is currently being looked at by the development team and we assure you that even if we have not had a new release , we have some of the issues reported by you in the bug tracking system. you can use PROC_LIBS-261. This was filed after the last release so it doesn`t show up as known issues./defects.

    you can use the link at the top of the following URL for tracking Software defects:
    software-dl.ti.com/.../index_FDS.html

    Regards,
    Rahul