search for: sivachandra

On Mon, Jul 15, 2019 at 2:43 PM Siva Chandra <sivachandra at google.com> wrote: > > > On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > > > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: > > >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote...

On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: >>>> llvm-libc is an implementation of the C standard library targeting C11 >>>> and above. >>> Any particular reason for C11 as opposed to C17?...

...txt and LICENSE.txt have been added: https://github.com/llvm/llvm-project/tree/master/libc >> >> I will soon share or put out design docs and code for review, as suitable. >> >> Thanks, >> Siva Chandra >> >> On Thu, Aug 15, 2019 at 11:23 AM Siva Chandra <sivachandra at google.com> wrote: >>> >>> Hello again, >>> >>> I have now committed a proposal for this new libc: >>> https://reviews.llvm.org/D64939. This proposal is based on the charter >>> I shared previously (see below). >>> >>> Th...

...m.org/cgi-bin/mailman/listinfo/libc-commits A brief README.txt and LICENSE.txt have been added: https://github.com/llvm/llvm-project/tree/master/libc I will soon share or put out design docs and code for review, as suitable. Thanks, Siva Chandra On Thu, Aug 15, 2019 at 11:23 AM Siva Chandra <sivachandra at google.com> wrote: > Hello again, > > I have now committed a proposal for this new libc: > https://reviews.llvm.org/D64939. This proposal is based on the charter > I shared previously (see below). > > Though it is now committed, if there are any concerns still, I am open...

On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > llvm-libc is an implementation of the C standard library targeting C11 > > and above. > > Any particular reason for C11 as opposed to C17? Two reasons: 1. The C++17 standard refers to the C11 standard. 2. C11 is sufficiently modern while not closing doors for users requiring compliance

...l, but my point is that there are going to be a ton of subtle issues that arise from this approach that are hard to foresee, precisely because the implementation details of a libc implementation are supposed to be just that - implementation details. On Tue, Jun 25, 2019 at 5:01 PM Siva Chandra <sivachandra at google.com> wrote: > > On Tue, Jun 25, 2019 at 4:32 PM Zachary Turner <zturner at roblox.com> wrote: >> >> The main concern I have is that Windows is so different from >> everything else that there is a high likelihood of decisions being >> baked in early o...

On Thu, Jun 27, 2019 at 5:19 PM JF Bastien <jfbastien at apple.com> wrote: > On Jun 27, 2019, at 5:05 PM, Siva Chandra <sivachandra at google.com> wrote: > On Wed, Jun 26, 2019 at 10:27 AM JF Bastien <jfbastien at apple.com> wrote: > > 3. If there is a specification, we should follow it. The scope that we need includes most of the C Standard Library; POSIX additions; and some necessary, system-specific extensi...

...plication. Given that Windows' libc and other versions of libc are so different, I expect this to lead to some interesting problems. Can you elaborate more on how you envision this working with llvm libc in between application and system libc? On Tue, Jun 25, 2019 at 4:20 PM Siva Chandra <sivachandra at google.com> wrote: > > On Mon, Jun 24, 2019 at 3:43 PM Zachary Turner <zturner at roblox.com> wrote: >> >> What do you expect the support for Windows to be? Certainly, I don't >> expect you to provide Windows support personally if you don't need it, >...

On Wed, Jun 26, 2019 at 10:27 AM JF Bastien <jfbastien at apple.com> wrote: >> 3. If there is a specification, we should follow it. The scope that we need includes most of the C Standard Library; POSIX additions; and some necessary, system-specific extensions. This does not mean we should (or can) follow the entire specification -- there will be some parts which simply aren't worth

On Thu, Jun 27, 2019 at 9:06 AM Zachary Turner <zturner at roblox.com> wrote: > I guess let me make this concrete: can you propose a specific separation that you have in mind? > > Keep in mind that even if A doesn’t depend on B, that doesn’t mean that A and B can be separated. You mentioned that open() and close() would obviously have to be done at the same time, but it’s much

On Thu, Jun 27, 2019 at 3:56 PM Zachary Turner <zturner at roblox.com> wrote: > No, I do not think we want to mix up CRTs on any platform. At the >> least, it will be disruptive to the compiler drivers. Our goal is to >> build a CRT with supports statically linked executables on Linux. We >> do not intend to mix this new CRT with the CRT from the system libc. >>

What do you expect the support for Windows to be? Certainly, I don't expect you to provide Windows support personally if you don't need it, but given that LLVM supports Windows, it should at least be done in such a way that the design lends itself to interested parties contributing Windows support. Currently clang-cl has several dependencies on having a Visual Studio installation present

> On 6/25/19 7:22 PM, Zachary Turner via llvm-dev wrote: > > I foresee problems with this on both Windows and non-Windows. A > > typical libc implementation has a lot of internal state that is shared > > across API boundaries in a way that is considered an implementation > > detail. So making assumptions about which state is shared and which > > isn't is

On Mon, Jun 24, 2019 at 3:37 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > disclaimer: I work at Google so don't take my +1 as an independent vote > forward. > > We would like to use this on Fuchsia and I am particularly interested in > creating a dynamic linking library for ELF with Roland McGrath's guidance. > We spoke about creating a library for writing

On Fri, Jun 28, 2019 at 9:29 AM JF Bastien <jfbastien at apple.com> wrote: > > I think I now understand some of the disconnect you and I are having, and I think some of the pushback you’re getting from the community is the same. You’re talking about where you want to start with an LLVM libc. Many in the community (myself included) want to understand where we’ll get with this libc. At

Hi folks, Building any LLVM project currently requires invoking CMake inside <monorepo-root>/llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn't really need or want it. It's also not great from a build hygiene perspective, as LLVM globally sets some flags