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)? Johann
