On Tue, Sep 4, 2012 at 1: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.
obviously that situation isn't ideal, and we shouldn't build patches that are as if it it should be perpetuated. [...] >> yes, but it is still one more configure option. > > > hmm. The configure machinery was not changed, It is one more configure option for user to specify, no matter how the internal configury is implemented. -- Gaby
