similar to: A libc in LLVM

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

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 on that make things very difficult for people to come along later and contribute a Windows implementation. This happened with sanitizers for example (lack of support for weak functions on Windows), LLDB (posix api calls scattered throughout the codebase),

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

Hello again, I would like to announce that we now have dedicated mailing lists for the llvm-libc project: 1. libc-dev - https://lists.llvm.org/cgi-bin/mailman/listinfo/libc-dev 2. libc-commits - https://lists.llvm.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

On Wed, Sep 18, 2019 at 11:49 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > Hi, > > What happened since you committed the doc? Is this now graduated from a "proposal to start a project" to a project? I think it has now. > Is there any update to be made to the doc: http://llvm.org/docs//Proposals/LLVMLibC.html ? Not sure what kind of update you have in mind.

I’m not totally sold on the idea of having it be a layer between system libc and application. I think this is likely to create a split between windows and non windows that will be difficult to overcome. It also seems like it brings with it its own set of difficulties. Where can you make a separation in libc such that you’re guaranteed that the two pieces do not share any state, especially given

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: > > >>>> llvm-libc

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

On Tue, Jun 25, 2019 at 2:53 AM Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 24 Jun 2019 at 23:23, Siva Chandra via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hello LLVM Developers, > > > > > > Within Google, we have a growing range of needs that existing libc implementations don't quite address. This is pushing us to

On Jun 26, 2019, at 9:02 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 6/24/19 6:23 PM, Siva Chandra via llvm-dev wrote: >> Within Google, we have a growing range of needs that existing libc >> implementations don't quite address. >> To be very clear: we don't expect our needs to exactly match everyone >> else's -- part of our

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

Cause llvm-libc are in early stage, and we can easily catch up the support with linux. After we add wasi support in llvm-lic, we can easily get a usable llvm-libc across different platform such as linux/windows/macos/android. don't know if iOS is a target, but these target are very much enough -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An

On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Saleem, Owen, others on the thread who are concerned about this: it seems that some of the concern is that the project goals are too narrow, and thus the eventual result may not serve the full community well over time. May be my email listing our goals is being misinterpreted as being

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;

Hello, I suspect that r260758 by kparzysz at codeaurora.org broke build the windows bots which are using Visual Studio 2013 or lower. This doc here specifies that the minimum version required is VS-2013: http://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library I do see that the bots running VS-2014 or higher are green. Can we either revert the said commit or

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

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 going to be a problem. How do you guarantee that if you implement method A and forward method B, that B will

Somehow I wish not all parts of a libc but parts that can be provided without a JavaScript wrapper for .wasm can be provided from llvm's libc (leaving a stab implementation for the rest like file system). I've put together a minimal libc on [1] so using a 26kb .wasm binary file one can decode both PNG and JPG using this [2] simple to integrate JavaScript code, can be easily ported in other

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