On Tue, Sep 4, 2012 at 8:55 AM, Georg-Johann Lay <a...@gjlay.de> wrote: > 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.
You can do a link check on whether -lc provides those functions and skip those that overlap with libgcc. Richard. > >>> 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 > >
