Hi, running avr-gcc-4.7.0 testsuite I observe mentioned problem with the following command line:
avr-gcc ./gcc/testsuite/gcc.c-torture/execute/980709-1.c -include stdlib.h -O2 -flto -flto-partition=none -mmcu=atmega128 -Wl,-u,vfprintf -lprintf_flt -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80ffff -lm For the source see http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.c-torture/execute/980709-1.c?content-type=text%2Fplain&view=co #include <math.h> main() { volatile double a; double c; a = 32.0; c = pow(a, 1.0/3.0); if (c + 0.1 > 3.174802 && c - 0.1 < 3.174802) exit (0); else abort (); } Error message: /local/gnu/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/lib/avr51/libc.a(log.o):../../../../../source/avr-libc-1.7.1/libm/fplib/log.S:96: relocation truncated to fit: R_AVR_13_PCREL against symbol `__addsf3' defined in .text section in /local/gnu/install/gcc-4.7/lib/gcc/avr/4.7.0/avr51/libgcc.a(_addsub_sf.o) /local/gnu/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/lib/avr51/libc.a(log.o):../../../../../source/avr-libc-1.7.1/libm/fplib/log.S:100: relocation truncated to fit: R_AVR_13_PCREL against symbol `__addsf3' defined in .text section in /local/gnu/install/gcc-4.7/lib/gcc/avr/4.7.0/avr51/libgcc.a(_addsub_sf.o) /local/gnu/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/lib/avr51/libc.a(modf.o):../../../../../source/avr-libc-1.7.1/libm/fplib/modf.S:90: relocation truncated to fit: R_AVR_13_PCREL against symbol `__subsf3' defined in .text section in /local/gnu/install/gcc-4.7/lib/gcc/avr/4.7.0/avr51/libgcc.a(_addsub_sf.o) The command line is a typical commandline used in testsuite regression test runs for avr-gcc. $avr-libc/libm/fplib/log.S shows explicit use of RCALL/RJMP to external symbols which should definitely not be there. Is this worth a bug report or is someone already working on this? I've seen similar topics in avr forums then and when... Then, I wonder why _addsub_sf.o is dragged in (by __addsf3 or __subsf3) even though avr-libc implements that. I've already consulted Jörg about that, and that the hackish "overwrite" of stuff from libgcc by avr-libc does not always work as intended. It's obvious that the desired solution was to have that code integrated into libgcc instead of in avr-libc (which is not the case for reasons we all know). So I proposed a fix that involves less administrative and implementational overhead and resource: * Add a new option to avr-gcc: -mavr-libc (on by default) * If -mavr-libc is on, use gcc optabs to emit other function names for distinct function in libgcc, e.g. __avrlibc___addsf3 instead of __addsf3. * Sprinkle some new __avrlibc_* labels over avr-libc like, e.g: .global __avrlibc___addsf3 .global __addsf3 __avrlibc___addsf3: __addsf3: instead of .global __addsf3 __addsf3: That way the bulky libgcc implementations could be bypassed. It would be a minimal change in avr backend and it is the preferred way to interface with a 3rd party library (like gofast). Johann _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
