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.

C++ cmath floating point functions fail on Ubuntu 12.04 on OMAP5432 EVM

Hello,

I'm running in to problems with calling floating point functions from cmath.  They return with either zeros or the argument I passed.  Adding optimization seems to fix the problem sometimes.  An example that demonstrates the problem:

#include <stdio.h>
#include <cmath>

int main (int argc, char** argv) 
{
  float test = 1.2;
  printf ("ceil of %.5f is %.5f\n", test, ceil(test) );

  float my_pi = 3.14159, hpi = my_pi /2;
  printf("sin %f = %f\n", hpi, sin(hpi));
  printf("cos %f = %f\n", my_pi, cos(my_pi));

  return 0;
}

compiled using arm-linux-gnueabihf-g++ with

-std=c++0x  -mcpu=cortex-a15 -mfloat-abi=softfp -mfpu=neon-vfpv4

gives:

ceil of 1.20000 is 0.00000
sin 1.570795 = 0.000000
cos 3.141590 = 0.000000

I need neon instructions for part of my actual code, and neon only works with softfp.  I think that the problem has to do with which eabi I'm using, but i don't what to do about it because I'm cornered into the setup I'm using. When i compile it with -O1 or higher it works in this simple case but causes segfaults in the math library in my more complex project.   Does anyone have any ideas?  Am i missing something obvious?

  • Hello Ben,

    Do you use OMAP5 GLSDK?

    I suggest before compiling to export your paths to CROSS COMPILER.

    Apply following steps:

    1. export ARCH=arm

    2. export CROSS_COMPILE=/home/users/........./cross-compile/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/bin/arm-linux-gnueabihf-

    3. export PATH=/home/users/........./cross-compile/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/bin:$PATH

    4. make CROSS_COMPILE=arrm-linux-gnueabihf-

    See the processor features in file:

    ti-glsdk_omap5-uevm_6_03_00_01/board-support/linux/arch/arm/kernel/setup.c

    arch/arm/kernel/entry-armv.S

    Best regards,

    Yanko

  • I have the cross compilier set up, and I am using arm-linux-gnueabihf version 4.6.3.  I think that if this was the problem then I would get an error message during the build.

     I'm not having any trouble building programs for the platform, they all run.  The only problem is with calls to floating point functions from an outside library, which is why i think the issue is with which eabi is being used.  

    I am limited to using softfp because I need NEON instructions, and they won't build without that.  

    Do I need to rebuild the Linux kernel with softfp or something so that the libraries will be in the same format?

  • Hello Ben,

    I have made an investigation about your question:

    Do I need to rebuild the Linux kernel with softfp or something so that the libraries will be in the same format?

    The GNU tools do not assume hardware floating-point support unless it is explicitly specified. You must specify -mfpu=neon on the command line to tell the compiler it can generate NEON instructions. You must also specify the floating-point calling convention to use, with the -mfloat-abi command line parameter. This takes one of the following argument:

    soft - No hardware floating-point support. All floating-point operations are implemented as calls to helper libraries. Soft linkage is used for floating-point function arguments and return values. When this mode is specified, the compiler does not generate NEON or VFP instructions.

    softfp - Soft linkage is used, but the compiler can generate hardware floating-point instructions supported by the specified floating-point unit.
     
    hard - Hard linkage is used and the compiler can generate hardware floating-point instructions supported by the specified floating-point unit.

    For example, to build for NEON technology, using the soft-float calling convention, add -mfpu=neon -mfloat-abi=softfp to the compiler command line.

    To build for VFPv3 only, with no NEON instructions, specify -mfpu=vfpv3.

    Yes, I think that you should try to rebuild Linux kernel softfp

    Best regards,

    Yanko

  • Yanko,

    Thank you for looking into this.  Do you know where in the GLSDK makefile or in the linux makefile I can change the abi option?

     

    Thanks,

    Ben

  • Hello Ben,


    I am not sure if the change of the abi option in GLSDK is a good approach.

    It is possible to destroyed your Cross Compiler.

    I think that you must add support of the math libs in Build the Linux kernel section of makefile.


    Best regards,

    Yanko