This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: why Glibc does not build with clang?
- From: Will Newton <will dot newton at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 16 May 2014 13:37:14 +0100
- Subject: Re: why Glibc does not build with clang?
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdw135gBO+cTQx3Ws1GrRgFsi8-j=Y_mZ=ixebpPzB4gXw at mail dot gmail dot com> <53760025 dot 10204 at redhat dot com>
On 16 May 2014 13:10, Florian Weimer <fweimer@redhat.com> wrote:
> On 05/16/2014 01:26 PM, Konstantin Serebryany wrote:
>
>> Would the Glibc team consider patches that remove local functions and
>> VLAIS?
>
>
> We have eliminated specific nested functions in the past, based on the
> argument that doing so would increase readability. Our nested functions do
> not need trampolines, so the required code transformations are not very
> complex. On the other hand, it borders on change for change's sake, with a
> poor trade-off on risks/benefits scale.
>
>
>> Is there any reason (technical/political/social/religious?) to keep
>> non-standard extensions
>> in Glibc, or this is just a lack of hands to do the cleanup?
>
>
> We need some extensions because the features are not available in standard C
> (or we are trying to implement them :-).
>
> Personally, I would really like to get rid of alloca, but this is
> controversial.
I'm curious as to why you want to get rid of alloca?
--
Will Newton
Toolchain Working Group, Linaro