GSoC Report- I

Hello World!

Here is my report on GSoC Project- Openlibm.

The project’s primary purpose is to provide a consistent libm to Octave. I tested some of the Bugs listed on the wiki page and below is my observation and report.

This is a companion discussion topic for the original entry at

MY TAKE: The proposed solution to use Openlibm as a replacement of libm to deal with the inconsistancy in maths library caused when Octave is compiled with libc++ (default on macOS) and sometimes with libstdc++ has failed and the bug issues and can not be solved with openlibm. Hence, there is need to find an alternate solution to address this issue.

What do you propose as alternate solution for the remaining time of your project?

Also, does Octave have tests that will catch these? So at least those using the problematic libm are aware of it.

I searched to find if there is an alternative solution for default libm. It seems everyone has a problem with libc++ or with default libm but I couldn’t find the best solution. Here are my findings. I don’t know if it will help.

  1. Some 3rd party math libraries
  1. libstdc++ seems more understanding than libc++. But libc++ is default in macOS. right now I want to know will there be any limitations if we direct macOS systems to not use their default libm and use libstdc++?
  2. Need more suggestions for 3rd party math lib.
  3. we can write our own implementation of maths function causing trouble.

Reference: c - Inconsistent float operation results between clang and gcc - Stack Overflow

here they have discussed the precision inconsistency of sin func

Maximum StackOverflow discussions on inconsistent behavior between clang and GCC are on floating precision problems.
ex- c++ - Inconsistent results between GCC and Clang for simple floating point calculation - Stack Overflow

Maybe I missed that: Did you test with small examples written in C whether openlibm returns more accurate results on the affected platforms?
Compiling the entirety of Octave and linking to openlibm as an initial test (and discarding the entire approach at that point) doesn’t look like the best idea to me.
Octave goes through a lot of indirections in its code to finally call lower-level math functions. Maybe it is not calling those C functions at all (after all it is written in C++).
Maybe it would work if Octave made sure to call these C functions. But checking what might need changes and which changes that would require should come a lot later on your timeline.

sorry I didn’t get what you want to say. I have not tested the openlibm with octave.
If you go through the post, I tested some c++ code snippets relevant to the respective bugs with and without openlibm on diff platforms. Since it’s failing in the initial stage that’s why openlibm doesn’t look a good choice.

Ok. So e.g. in BugTesting/ at main · shreyaswikriti/BugTesting (, how did you determine that std::pow did call a function from openlibm?
Is the result the same if you use the C function ::pow instead?