Gabriel Dos Reis schrieb:
Georg-Johann Lay wrote:
Gabriel Dos Reis schrieb:
Georg-Johann Lay wrote:
AVR-Libc comes with hand-optimized float support functions written
in assembler. These functions use the same naming conventions like
libgcc. There are situations where this name clashed lead to performance
regression because the functions from libgcc are linked. One example
are the new fixed-point support that convert fixed-point to/from float
and reference float/int conversion functions from within libgcc.
The float implementation in libm.a have been discussed several times
with the only result that it is very unlikely that the code will
ever be integrated into libgcc because the original authors are no
more around. And is is much less work to add a new configure switch
than to port and integrate the code, given there were no license issues.
One point against such an extension was that such change to the compiler
establishes a dependency between the compiler and AVR-Libc, but this
decision has been made long ago by accepting code that actually should
had been added to libgcc -- but was not for whatever reason.
This patch removes that performance regressions by removing the
doubly implemented functions from libgcc by means of a new configure
option --with-avrlibc.
as I stated yesterday, I do not understand why there needs to be yet
another
configure option. The NATURAL libc for ARV targets is ARV-libc. We
should not need a switch for that.
There is also newlib that is used with avr-gcc. I know this because
some bugs are only triggered for newlib. If there are users that
report bugs if avr-gcc is build for newlib, I'd guess these users are
actually interested in using newlib.
I did not say there was no other libc library. I said
that the *natural* libc appears to be AVR-libc.
We don't configure GCC/g++ saying --with-libstdc++.
That's a different story because these libraries support in-tree
build just like newlib does. This is not true for AVR-Libc which
does not support in-tree builds.
I agree that AVR-Libc is the most common libc implementation
used with avr-gcc and is has many advantages over other libc
implementation (except that it does not support in-tree builds).
However, a --with-avrlibc is not needed to *get* the support
from AVR-Libc, it's just used to fix some problems that arise
in certain use cases.
Besides that, the proposed arrangement does not affect the
configuration if the switch is *not* specified, thus the patch
is appropriate to be backported.
My intention is to backport it to 4.7 as indicated by the milestone,
but if the change was unconditionally I don't think the change is
appropriate for a backport.
And after all it's just a *configure* option that some distribution
maintainers can set if they want to. The tool chain user is not
bothered at all by the new option and won't even notice it.
From the user perspective it's just as if some optimizations
had been added to the tool chain.
What do you propose?
Use the setting per default and support a --with-avrlibc=no if
the user want full libgcc support and nothing removed from it?
It's clear that the proposed changes do *not* work with newlib
because newlib does not mimic parts of libgcc.
Johann
