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

[Georg-Johann Lay]

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.

>> However, a --with-avrlibc is not needed to *get* the support from
>> AVR-Libc, it's just used to fix some problems that arise in certain
>> use cases.
> 
> so, let's make it the default -- see below.
> 
>> Besides that, the proposed arrangement does not affect the 
>> configuration if the switch is *not* specified, thus the patch is
>> appropriate to be backported.
>> 
>> My intention is to backport it to 4.7 as indicated by the
>> milestone, but if the change was unconditionally I don't think the
>> change is appropriate for a backport.
> 
> It is perfectly reasonable and OK to to make the backport more 
> guarded (e.g. by the configure option) than on mainline.
> 
>> And after all it's just a *configure* option that some distribution
>>  maintainers can set if they want to.
> 
> yes, but it is still one more configure option.

hmm.  The configure machinery was not changed, it automatically sets
with_foo if --with-foo is specified.  It's just about who is to
be blamed if he does not read the release notes ;-)

Whatever, I think we two are stuck now and enough arguments passed
back and forth.  Let the port maintainers decide.

And Jörg, would you check the excludes list in t-avrlibc?

Johann

>> The tool chain user is not bothered at all by the new option and
>> won't even notice it. From the user perspective it's just as if
>> some optimizations had been added to the tool chain.
>> 
>> What do you propose?
>> 
>> Use the setting per default and support a --with-avrlibc=no if the
>> user want full libgcc support and nothing removed from it?
> 
> Yes. Let's make the "sane" behaviour the default.
> 
> -- Gaby