On Mon, Sep 3, 2012 at 4:23 PM, Georg-Johann Lay <a...@gjlay.de> 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. > > 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. > 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
