similar to: lld on Windows

C:\t>type a.c #include <stdio.h> int main() { puts("hello"); return 0; } C:\t>cl /c a.c Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x64 Copyright (C) Microsoft Corporation. All rights reserved. a.c C:\t>lld Select the appropriate flavor OVERVIEW: LLVM Linker USAGE: lld [options] <inputs> OPTIONS: -core CORE linking -flavor

Ah! I don't know what GUARDSYM does or whether there is any way to turn it off at the compiler end; a Google search doesn't seem to find anything; but it would be great if you could add support for msvc 2015. When I try using clang as the compiler, I get a different error message. In this case it seems to be just not finding the standard libraries? C:\t>clang -c a.c C:\t>lld

I build llvm/clang/lld from source on Windows using mingw-64/gcc-6.3. I use clang++ both to test clang targeting gcc and clang targeting VC++. When using clang targeting VC++ I use the appropriate target triple when compiling and am trying to use lld to link the object file(s) into an exe. To do that I use the clang option "-fuse-ld=lld" when linking. According to the llvm doc on

On 3/29/2017 1:38 PM, Reid Kleckner via llvm-dev wrote: > If clang is targeting VC++, then -fuse-ld=lld should be enough to make > it run lld-link.exe, and you won't need to set the flavor or do anything > special to get PE/COFF files. > > This example worked for me: > > $ cat t.cpp > #include <iostream> > int main() { std::cout << "hello

Hi All, Our team at Hip-Hop Virtual Machine (http://hhvm.com<http://hhvm.com/>) have been experimenting with using LLVM as a code generator for x86-64. We have been successfully running it for quite some time as a secondary back end. We had to modify our version of LLVM and our mods were based on 3.5 release. At this point we feel our requirements have become stable enough to start

Hello Group, I have a requirement to dialout some external number, once the call is answered the same has to be forwarded to an Internal Queue. Please help me. I have tried calling with two SIP end point forwarding , even that is not working, My dial plan line is , Dial(SIP/19201/19202,300) -- *Best regards,* *Ruban.S* -------------- next part -------------- An HTML attachment

Hi, I think lld needs to have an infrastructure as part of the build process to build specific flavors and specific targets. For this I was thinking that the Registry expand to consider flavors and targets that are part of the build process. So each flavor/target would register and the Driver would walk through the list of handlers to check if there is a handler defined for that

On 10/7/2014 4:10 PM, Nick Kledzik wrote: > Shankar, > > Can you give provide a scenario where you want this? I’m not sure what you want here. a) LLVM could be built just for one target(LLVM_TARGETS_TO_BUILD) b) With LTO this case might happen more often, where an user would have compiled LLVM just for one architecture and lld would support other architectures that LLVM would not

Hi all, According to lld/docs/Driver.rst, Flavor command line option determines the style of lld command-line interface when invoked. However, it looks like this option also determines the set of supported targets we are linking for. For example, lld -flavor gnu cannot link mach-o binaries, and could not link PE binaries either (well, not until rL312926). Is this really intended by the design

On Wed, Oct 8, 2014 at 11:45 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > This it totally "armchair quarterbacking," but I am a little frustrated > that we've come to conflate flavors and targets. > > The original intent of flavors was to internally translate each flavor > into a neutral lld-native command line syntax. We now have baked in >

Hello list, on the lld main page at http://lld.llvm.org, it says: "lld is in its early stages of development. It can currently self host on Linux x86-64 with -static." Is this information up-to-date? I'm interested in using lld on Windows (win32 on PC) with object files created by llvm (no clang involved). Is that possible at this time? It would be awesome to be able to create a

On 10/9/2013 11:19 PM, Rui Ueyama wrote: > > Isnt having a YAML file starting with the below better, so that you dont > need to go through file extensions. > > magic : > arch: > > I guess we will use a fixed file extension anyway (we probaly don't want to > use .txt for YAML object file for example), so what do you think is the > benefit of depending on special

On Wed, Oct 9, 2013 at 7:57 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 4:19 PM, Shankar Easwaran wrote: > >> On 10/9/2013 3:09 PM, Nick Kledzik wrote: >> >>> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> >>> wrote: >>> >>>> We have a whole bunch of readers(we would have

2013/10/31 Daniel Albuschat <d.albuschat at gmail.com>: > on the lld main page at http://lld.llvm.org, it says: > > "lld is in its early stages of development. > It can currently self host on Linux x86-64 with -static." > > Is this information up-to-date? I made a quick test on a Windows 8 64bit system: test.c: int main () { return 42; } > clang -c test.c

Martell recently added "ld64.lld" as a name for the Darwin driver. As to why there's no driver that provides a unified command line arguments, I can't speak for other people. But no one seems to have been interested in it enough to actually invent and implement a set of unified command line arguments. On Thu, Oct 26, 2017 at 2:20 PM, N <scandium at me.com> wrote: >

On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 11:19 PM, Rui Ueyama wrote: > >> >> Isnt having a YAML file starting with the below better, so that you dont >> need to go through file extensions. >> >> magic : >> arch: >> >> I guess we will use a fixed file extension anyway (we probaly

I mean, there is such a universal driver -- it's called "clang". On Oct 26, 2017 5:31 PM, "Rui Ueyama via llvm-dev" <llvm-dev at lists.llvm.org> wrote: Martell recently added "ld64.lld" as a name for the Darwin driver. As to why there's no driver that provides a unified command line arguments, I can't speak for other people. But no one seems to

On 10/10/2013 5:00 PM, Rui Ueyama wrote: > On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> On 10/9/2013 11:19 PM, Rui Ueyama wrote: >> >>> Isnt having a YAML file starting with the below better, so that you dont >>> need to go through file extensions. >>> >>> magic : >>> arch:

# is a line comment chracter in YAML so it's valid. That's why I wrote a simple magic "comment". On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/10/2013 5:00 PM, Rui Ueyama wrote: > >> On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran >> <shankare at codeaurora.org>**wrote: >> >> On

Ah Sorry. Totally forgot about that. On 10/10/2013 8:24 PM, Rui Ueyama wrote: > # is a line comment chracter in YAML so it's valid. That's why I wrote a > simple magic "comment". > > > On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> On 10/10/2013 5:00 PM, Rui Ueyama wrote: >> >>> On Thu,