Gabriel Dos Reis schrieb:
Georg-Johann Lay wrote:
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).
I think the "in-tree builds" thing is a red herring.
I don't think so. If there was an in-tree build gcc could detect
itself whether or not AVR-Libc is present or not. With the
current setup the user has to specify that -- in whatever
direction: that libc is there or that libc is not there depending
on whatever is default.
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.
so, let's make it the default -- see below.
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.
It is perfectly reasonable and OK to to make the backport more
guarded (e.g. by the configure option) than on mainline.
And after all it's just a *configure* option that some distribution
maintainers can set if they want to.
yes, but it is still one more configure option.
hmm. The configure machinery was not changed, it automatically sets
with_foo if --with-foo is specified. It's just about who is to
be blamed if he does not read the release notes ;-)
Whatever, I think we two are stuck now and enough arguments passed
back and forth. Let the port maintainers decide.
And Jörg, would you check the excludes list in t-avrlibc?
Johann
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?
Yes. Let's make the "sane" behaviour the default.
-- Gaby
