[avr-gcc-list] Trouble with: relocation truncated to fit: R_AVR_13_PCREL

[Georg-Johann Lay]

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