David Brown wrote:
Georg-Johann Lay wrote:
for historical reasons, AVR-Libc implements functions that
GCC expects to live in libgcc, namely float functions like
__fixsfsi.
Would it not be a better idea to move the functions from AVR-Libc
into libgcc? Or are there complicating issues, such as copyright
assignments, that make that a harder job?
mvh.,
David
Yes, that's the issue.
The original authors put their code in AVR-Libc, presumably because
it was easier to get the code in there than to get it into GCC.
To get it into GCC, you have to sign a copyright assignment and
provide proper patches that passed tests(uite), comply to coding
rules, come with ChangeLogs, documentations etc. It's then up
to the maintainer to push the code upstream, but he won't fix
bugs or typos or coding rules or whatever.
For AVR-Libc it's enough to outline a change, at least that was
my impression from the improved [u]ltoa functions from SVN 2298.
Besides that, even *if* the original authors released their code
under an additional license *and* filed FSF copyright assignments,
someone would have to actually carry the code migration.
From the number of people that contribute to avr-gcc, this is
simply not realistic. A potential move has been discussed too
often before without any results -- except that it's extremely
unlikely anybody will integrate it into libgcc.
Adding a new configure option to gcc is much less work and
straight forward. All that has to be done is to review the excludes
list and make sure that not too much or to less is removed.
And run regression tests, of course.
The objection against such a change was that it introduces a
dependency between avr-gcc and AVR-Libc, but this dependency
was introduced long ago, namely when it was decided to re-implement
functions that live in libgcc once more in AVR-Libc and use
reserved names like __addsf3 together with an "override" hack and
implications on how GCC orders -lgcc, -lm, -lc, or how LTO works.
In addition to the proposed new t-avrlibc Makefile snippets,
there could be defines for, cf. [1]
* TARGET_C99_FUNCTIONS
* TARGET_HAS_SINCOS
Thoughts?
Johann
[1] http://gcc.gnu.org/onlinedocs/gccint/Library-Calls.html