ARM compilation error registered by VFP used by the executable, not the object file

Question

I have had this problem in the last few days, and I can’t understand what is really happening here, or what the problem is.

I have a make file with these flags:

CC = arm-linux-gnueabihf-gcc-4.6 FLAGS = -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -std=gnu99 

I have a library in a .a file that has some object files, all I have to do is link them to my executable. I know the prototypes and all that, the only thing complaining is the following:

 /usr/bin/ld: error: *EXECUTABLE* uses VFP register arguments, *OBJECTFILE* does not /usr/bin/ld: failed to merge target specific data of file *OBJECTFILE* 

When I do not use -mfloat-abi = softfp, I get one more error regarding the floating point case.

Does anyone know what causes this, and what can I do to fix it, for example, to make sure that my executable does not use virtual floating point register arguments?

 x@x:~/Desktop/perf_test$ make arm-linux-gnueabihf-gcc-4.6 -c -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -std=gnu99 -mfloat-abi=softfp perf_test.c ../baseline/util.c arm-linux-gnueabihf-gcc-4.6 -o perf_test perf_test.o util.o ../baseline/lib.a /usr/bin/ld: error: perf_test uses VFP register arguments, perf_test.o does not /usr/bin/ld: failed to merge target specific data of file perf_test.o /usr/bin/ld: error: perf_test uses VFP register arguments, util.o does not /usr/bin/ld: failed to merge target specific data of file util.o /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(ao) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(ao) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(bo) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(bo) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(co) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(co) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(do) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(do) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(eo) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(eo) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(fo) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(fo) collect2: ld returned 1 exit status make: *** [perf_test] Error 1 

Answer 1

Your triplet indicates that your compiler is configured for ABI with a solid float. This means that the libgcc library will also be hardfp. The error message indicates that at least part of your system uses floating point ABI.

If the compiler is enabled with multilib support (you can tell with -print-multi-lib ), you can use -mfloat-abi=softfp , but if not, this option will not help you: gcc will happily generate softfp code, ll not compatible with libgcc for reference.

In principle, hardfp and softfp are simply incompatible. You need to configure your entire system anyway.

EDIT: Some distributions are or will be "multi-archived". If you have one of them, then you can install both ABIs at once, but this is done by doubling everything - compatibility issues still exist.

Answer 2

I found that on the hardfloat hand system, where glibc binutils and gcc were combined, using gcc gives the same error.

It is solved by exporting -mfloat-abi=hard to flags, then gcc compiles without errors.

Answer 3

Also, the error can be resolved by adding several flags, such as -marm -mthumb-interwork . It was useful to me to avoid the same error.

Answer 4

This is a hunch, but you may need to provide some or all of the floating-point switches for the link stage.

Answer 5

In my case, CFLAGS = -O0 -g -Wall -I. -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=soft CFLAGS = -O0 -g -Wall -I. -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=soft helped. As you can see, I used it for my stm32f407.

Answer 6

Use the same compiler options for reference.

Example:

 gcc -mfloat-abi=hard fpu=neon -c -o test.cpp test.o gcc -mfloat-abi=hard fpu=neon -c test1.cpp test1.o gcc test.o test1.o mfloat-abi=hard fpu=neon HardTest 

Answer 7

I ran into a problem using Atollic for ARM on STM32F4 (I think this applies to all STM32 with FPUs).

Using SW floating point did not work for me (thus compiling correctly).

When STM32cubeMX generates code for TrueStudio (Atollic), it does not install the FPU in the C / C ++ build settings (it is not sure of the generated code for other IDEs).

Set the FPU to "Target" for (in the project build settings):

• Assembler
• C compiler
• C linker

Then you have a choice: Mix HW / SW fp or use HW.

The generated command lines are added for this purpose for the target:

 -mfloat-abi=hard -mfpu=fpv4-sp-d16 

arm atollic

Answer 8

In my particular case, -g -march=armv7-a -mfloat-abi=hard -mfpu=neon -marm -mthumb-interwork worked.

Answer 9

This answer may appear on the surface to be unrelated, but there is an indirect reason for this error message.

Firstly, the error message “Uses VFP register ...” was called directly from mixing mfloat-abi = soft and mfloat-abi = hard options inside your assembly. This parameter must be consistent for all objects that must be connected. This fact is well covered in other answers to this question.

The direct cause of this error can be caused by the fact that the Eclipse editor is confused with the error caused by itself in the project file .cproject. The Eclipse editor often rewrites file links, and sometimes it breaks when you make changes to directory structures or file locations. It can also affect the path settings for your gcc compiler - and only for a subset of your project files. Although I'm still not sure what exactly leads to this error, replacing the .cproject file with a backup has fixed this problem for me. In my case, I noticed .java.null.pointer errors after adding the path to the include directory and started receiving VFP register error messages. In the build log, I noticed that for some of my sources that were local to the workspace, a different path to the gcc compiler was used, but not all of them !? The two gcc compilers used different float settings for unknown reasons - hence a VFP register error.

I compared the .cproject options with the old copy and observed differences in the recording for the sources causing the problems, even though overriding the project settings was disabled. Replacing the .cproject file with the old version, the problem disappeared, and I leave this answer as a reminder of what happened.