On Tue, Sep 4, 2012 at 1:01 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > Richard Guenther wrote: >> Georg-Johann Lay 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. > > Can you explain this? A typical build of avr tools goes like > > 1) configure, build and install binutils > 2) configure, build and install the compiler > 3) configure, build and install AVR-Libc > > so that in step 2 no checking is possible because there is no -lc yet. > Or do you mean a check at run time (of the compiler)?
4) build and install the real compiler at which time you have AVR-libc available. AT least that's how you "bootstrap" a glibc cross. Richard. > > Johann > >
