Problem with mathematic functions (pow)

[shagkur]

Izhido: This is not going to work. Because we do lazy FP context switching, which is done thru the FP unavailable bit in the MSR, this would disable this path. Furthermore there won't be a FP context switch anymore then. The solution to your idea would be to do the FP context switch at every thread context switch, which in turn would be a big performance hit. Also, doing it this way would make such a function obsolete because the FP unavailable bit in the MSR would get initialized at thread creation and would never change.

Eke: __lwp_thread_deallocatefp is only called for the thread which gets closed and is also the thread which is set as _thr_allocated_fp. And at init state it should be also okay to not save because it'll be the first thread which is trampling onto a fp register.

[Eke]

Just to let you know, the recent changes made for libogc 1.8.4 did not solve my issue, the pow() function randomly (but still rarely) returns a wrong value. I guess the randomness and the rarity of the bug is tied to the timing and occurrence of an exception during the call of the function (the more you call the function successively , the more the error can occur). I also confirm that disabling interrupt around that call seems to prevent the issue from ever happening (intensive testing has shown it).

I guess this will stay an unsolved mystery for the moment

[WinterMute]

Darn, have you managed to come up with a testcase that always invokes the bug? Even if it's something that needs to be run for a while it would help a lot.

[Eke]

Hum, this is quite embarrassing but I think I figured the problem and it's all my fault, not libogc.

I totally forgot that I had a VI callback programmed. Now, this callback is used to update input peripheral data and is calling WPAD_ScanPads, which, off course, uses floating point calculations, and therefore modify FPU registers during the interruption.

So, to resume, if the interrupt occurs between instructions of the pow() or any other function using FPU (which has very low probability to happen but I was actually multiplying my chances by calling the function multiple times in a loop !), the result becomes corrupted.

I didn't had the time to test this theory but I'm 99% sure it's the issue