Re: [avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit: R_AVR_13_PCREL"

[Joerg Wunsch]

[Cc to avr-gcc-list as this is IMHO important for our userbase.]

As Dmitry K. wrote:

(About two different implementations for __addsf33x et al.)

> Now the opportunity of choose works.

>       text    data     bss     dec     hex filename
>       2012       8       4    2024     7e8 foo-gcc.elf
>        562       0       4     566     236 foo-m.elf

> First program (foo-gcc.elf) is linked with libgcc's
> modules. It produces 0, as NaN is not equal to NaN.

> Second program (foo-m.elf) is linked with libm's modules.
> It produces 1:  NaN/Inf/Subnormals are not fully released
> in Avr-libc/libm.  But compare size!

Yet, the libm version is inherently broken.  GCC claims
support for IEEE features, so we cannot ignore them.

I a user wants to choose an inferior implementation for floating-point
routines that are supposed to be in libgcc.a, we should offer them a
separate library that can be explicitly given on the command-line (as
libsimplefp.a, not via -l) so it will take precedence over libgcc.a.
It should not be bundled with libm.a though.

> > So I think that bug should be resolved by using XJMP instead of
> > RJMP.

> No!
> The error is to mix the libraries.

The error is to replace library functions that are in the domain of
libgcc.a in a different library.  If a full replacements exist, they
need to be supplied to the GCC team for inclusion into libgcc.a.

> Is inadmissible to replace a part of library another if the author
> did not project such replacement initially. 'libm' uses some
> assumptions of use of registers to which does not follow 'libgcc'.

Sigh.  This is another bug then.  If the functions have identical
names, they should have identical calling conventions.

We seriously need a maintainer for libm.a.  As the state is now, I
tend to drop support for fplib completely, and release it on a `use at
your own risk' base.  I'm unable to maintain it myself, and nobody
else appears to be willing or able to maintain it.  We've got half a
dozen of bug reports open for it (some of them for more than 3 years),
and nobody in sight to really fix anything there.

It would be better to supply a large but accurate libm.a that is based
on C code and can be maintained easily by any team member, rather than
the cruel hack we're suffering from right now.  Even though it's
pretty small in code size, it's got so many problems that turn out to
be inherent due to the way it has been written, I feel it's no longer
justifiable to `sell' it to our users that way.  It could perhaps be
built as a standalone hack that can be used by those who could live
with the bugs given the code size saving, but I'd rather like to see a
default libm.a that follows the same quality of implementation
standards as both, GCC as well as the remainder of avr-libc.

I might sound a bit pissed off here, and yes, I actually am.  I've
been trying to fix bugs in that library off and on myself, and I'm now
simply sick of that.  With all its internal cruft, it turned out to be
unmaintainable.

I'm not going to drop the current fplib for 1.4.0 (as it would defer
1.4.0 even more than it already is behind schedule), but unless
someone really steps forward and wants to fix all those bugs, and
continue maintaining fplib (that is, actively maintaining it,
including the require CVS skills, and taking over responsibility for
handling all future bug reports as well), I'll see to rewrite all the
math functions in C after 1.4.0 has been shipped, and eventually
replace the existing library.  In that case, 1.6.0 would then ship
with a new libm.a (probably joined into libc.a), and ship fplib as a
separate add-on item only for those who really want to use it,
explicitly marking it as being unmaintained.  I'll close all open bug
reports for that library than as "won't fix", and not accept new bug
reports.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)