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

[Gabriel Dos Reis]

On Tue, Sep 4, 2012 at 1:55 AM, Georg-Johann Lay <avr@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