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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Mon, Sep 3, 2012 at 4:23 PM, Georg-Johann Lay <avr@gjlay.de> 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.

>
> 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.

>  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