[Patch,avr] PR54461: Better AVR-Libc integration

[Georg-Johann Lay]

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