I have some strange behaviors when I try to use floating point
arithmetic with Yagarto (gcc 4.2.2). I am using a STR912E olimex dev.
board, everything compile and link well with no error reported. The
download in flash with OpenOCD is OK and the debug through
gdb/OpenOCD/JtagKey is OK, but the variable double or float have strange
behavior and populated with strange results after and instruction like
2.0987E+238 instead of 25.0 for instance.
I have tried Anglia Idealist 1.62 and it works fine, the arithmetic is
OK with the exactly same project.
I have increased the stack up to 4kB following the forum survey, but
nothing better happen.
Is there any Library I should use or declare, or linker option in order
to get floating point working with Yagarto?
Thank you in advance for your help.

Joel Jomed wrote:
> I have some strange behaviors when I try to use floating point
> arithmetic with Yagarto (gcc 4.2.2). I am using a STR912E olimex dev.
> board, everything compile and link well with no error reported. The
> download in flash with OpenOCD is OK and the debug through
> gdb/OpenOCD/JtagKey is OK, but the variable double or float have strange
> behavior and populated with strange results after and instruction like
> 2.0987E+238 instead of 25.0 for instance.
> I have tried Anglia Idealist 1.62 and it works fine, the arithmetic is
> OK with the exactly same project.
> I have increased the stack up to 4kB following the forum survey, but
> nothing better happen.
> Is there any Library I should use or declare, or linker option in order
> to get floating point working with Yagarto?
> Thank you in advance for your help.

What do you mean with "exactly same project" are all options passed to 
the compiler/linker/assembler identical or just the source-codes and the 
linker-script? Did you link with the libm (option -lm)? If not: try to 
add this option to the command used for linking. If this does not work: 
try to find out which options Idialist uses when calling the GNU tools. 
Maybe there is a "verbose" output-mode or a log-file is generated (I 
have not used Idealist so far). When you have these options use the same 
ones for the build-process you use with the Yagarto tools (makefile?). 
If this still does not help paste the complete output of the Yagarto 
build here so all options can be seen.

Martin Thomas wrote:
> Joel Jomed wrote:
>> I have some strange behaviors when I try to use floating point
>> arithmetic with Yagarto (gcc 4.2.2). I am using a STR912E olimex dev.
>> board, everything compile and link well with no error reported. The
>> download in flash with OpenOCD is OK and the debug through
>> gdb/OpenOCD/JtagKey is OK, but the variable double or float have strange
>> behavior and populated with strange results after and instruction like
>> 2.0987E+238 instead of 25.0 for instance.
>> I have tried Anglia Idealist 1.62 and it works fine, the arithmetic is
>> OK with the exactly same project.
>> I have increased the stack up to 4kB following the forum survey, but
>> nothing better happen.
>> Is there any Library I should use or declare, or linker option in order
>> to get floating point working with Yagarto?
>> Thank you in advance for your help.
> 
> What do you mean with "exactly same project" are all options passed to 
> the compiler/linker/assembler identical or just the source-codes and the 
> linker-script? Did you link with the libm (option -lm)? If not: try to 
> add this option to the command used for linking. If this does not work: 
> try to find out which options Idialist uses when calling the GNU tools. 
> Maybe there is a "verbose" output-mode or a log-file is generated (I 
> have not used Idealist so far). When you have these options use the same 
> ones for the build-process you use with the Yagarto tools (makefile?). 
> If this still does not help paste the complete output of the Yagarto 
> build here so all options can be seen.

All the source code and linker script were identical, the compiler 
version is different between Yagarto (arm-elf-gcc 4.2.2) and Anglia 
Idealist 1.62 (arm-eabi-gcc 4.2.3). Even if the Anglia tool does not 
output the exact compiler/linker invocation, I tried to put the same 
compile/link option in Eclipse but without success. Yes, I did add the 
libm.a (I imported the libc.a, libm.a and libgcc.a in my project 
directory as adviced by James P. Lynch in his great tutorial for dummies 
like me).
Here are my built report from yagarto:

**** Build of configuration Default for project Moniteur ****

make all
.compiling Gest_Capteurs.c
gcc -c -march=armv5te -g -Wall -O0 -I./include/ -I./str91x_lib/include/ 
-o ./src/Gest_Capteurs.o ./src/Gest_Capteurs.c
.compiling Gest_RTC.c
gcc -c -march=armv5te -g -Wall -O0 -I./include/ -I./str91x_lib/include/ 
-o ./src/Gest_RTC.o ./src/Gest_RTC.c
.compiling Gest_UART.c
gcc -c -march=armv5te -g -Wall -O0 -I./include/ -I./str91x_lib/include/ 
-o ./src/Gest_UART.o ./src/Gest_UART.c
.compiling Tempo_WDG.c
gcc -c -march=armv5te -g -Wall -O0 -I./include/ -I./str91x_lib/include/ 
-o ./src/Tempo_WDG.o ./src/Tempo_WDG.c
.compiling vectors.c
gcc -c -march=armv5te -g -Wall -O0 -I./include/ -I./str91x_lib/include/ 
-o ./src/vectors.o ./src/vectors.c
.compiling main.c
gcc -c -march=armv5te -g -Wall -O0 -I./include/ -I./str91x_lib/include/ 
-o ./src/main.o ./src/main.c
.assembling startup.s
as -march=armv5te -ahls -mapcs-32 -o ./src/startup.o ./src/startup.s > 
./src/startup.lst
.assembling vector.s
as -march=armv5te -ahls -mapcs-32 -o ./src/vector.o ./src/vector.s > 
./src/vector.lst
gcc (GCC) 4.2.3
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

..linking
gcc -march=armv5te -gdwarf-2 -O0 -Wall -ffunction-sections 
-fdata-sections -I./include/ -I./str91x_lib/include/ 
./src/Gest_Capteurs.o ./src/Gest_RTC.o ./src/Gest_UART.o 
./src/Tempo_WDG.o ./src/vectors.o ./src/main.o ./src/startup.o 
./src/vector.o ./Libraries/libstr91d.a --output main.elf -nostartfiles 
-Wl,-Map=main.map,-cref -Wl,--gc-sections -Trom91x.ld
...copying
objcopy -O ihex main.elf main.hex
objcopy -O binary main.elf main.bin
objdump -h -S -C main.elf > main.dmp
nm -n main.elf > main.sym

size -A main.elf
main.elf  :
section             size       addr
.text              53440          0
.rodata             1736      53440
.ARM.exidx            16      55176
.data               1324   67108864
.bss                 604   67110192
.heap               1024   67110796
.stack              1024   67111820
.stack_irq           256   67112844
.stack_fiq           256   67113100
.comment             936          0
.debug_aranges      2768          0
.debug_pubnames     7273          0
.debug_info       106565          0
.debug_abbrev      18088          0
.debug_line        21345          0
.debug_frame        7932          0
.debug_str          7214          0
.debug_loc         31999          0
.ARM.attributes       41          0
.debug_ranges       1232          0
Total             265073

I have recently switch to arm in order to redesign an equipment based on 
8051 and my  concern is to make a choice between a proprietary tool and 
the open source world for development. I am then a full newbie about 
arm/gcc and I have some difficulties to deeply understand all 
compile/link options meaning.
Thank you again for your help.

Hi,

It's just a general hint: check if, during the link process, the correct 
libraries are used. For example: I use the STM32 which got a cortex-m3 
core and accedentially linked the libs for a other arm core. resulting 
in perfekt working code, up to the point on which I tried to use 
floatingpoint. that is, because the STM32 got no fpu and than the wrong 
lib was linked and used unsupported commands to emulate the fpu. You 
should check the main.map file, it includes the linked libs. then check 
if they are supported/compiled for your core.

regards,
Lain