similar to: r260758 broke windows build

It works for me: ------ Build started: Project: LLVMHexagonCodeGen, Configuration: RelWithDebInfo Win32 ------ cl : Command line warning D9002: ignoring unknown option '/Zc:inline' HexagonFrameLowering.cpp ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== Here's the info from the "about" window: Microsoft Visual Studio Professional 2013

On 2/12/2016 9:47 PM, Vince Harron wrote: > Are you building LLDB? Im guessing that is where the failure is I'm building LLVM. The failure in the buildbot happens when compiling HexagonFrameLowering.cpp: ---------- FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /TP /DWIN32 /D_WINDOWS /W4 -wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351 -wd4355 -wd4456

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.

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

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

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 start working on a new libc implementation. Informal conversations with others within the LLVM community has told us that a libc in LLVM is actually a broader need, and we are increasingly consolidating our toolchains around LLVM. Hence, we

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

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

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

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

On Tue, Jun 25, 2019 at 4:05 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Syscalls are operating system specific and architecture dependent so I > think we'll want an abstraction layer around the fundamental operations the > syscalls support anyway. Some things like open aren't even syscalls on all > operating > Right, syscalls are OS _and_ architecture

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

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

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