similar to: [LLVMdev] Native Static Compilers Compatible with LLVM

If you're generating a .s file for X86, you can specify the flavor of assembly language on the command line like this: llvm-gcc ... -mllvm -x86-asm-syntax=[att|intel] Here's the relevant lines in the llc -help: ... -x86-asm-syntax - Choose style of code to emit from X86 backend: =att - Emit AT&T-style assembly =intel

Is there anything else besides GNU or any other targets in the future? My goal is to be able to not have all the binaries coming out to be GPL.. If not, I will have to go back to using C as an intermediate language. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090408/5216ab28/attachment.html>

On Wed, Apr 8, 2009 at 5:50 PM, Bot Tiger <bottiger1 at gmail.com> wrote: > Is there anything else besides GNU or any other targets in the future? > > My goal is to be able to not have all the binaries coming out to be GPL.. You do know that the GNU tools don't cause their output to be GPL'ed, right? http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF and

> o.O How is that going to help your problem? (Note: LLVM can generate C code.) > -bw It will help because I can generate C code that isn't tied to GCC (which LLVM does not do from my tests so far).

We know. Someone offered to do the Intel version, but did little more than a huge cut and paste of the AT&T version and then lost interest. No one else has had the time or inclination to finish the (barely begun) job. Patches accepted :) Ralph Corderoy wrote: > Hi, > > >> It's a long way towards it: >> >> # AT&T. # Intel.

On Sat, 29 Apr 2006, Jeff Cohen wrote: > We know. Someone offered to do the Intel version, but did little more than a > huge cut and paste of the AT&T version and then lost interest. No one else > has had the time or inclination to finish the (barely begun) job. Patches > accepted :) Actually, that's not true. The LLVM X86 backend started out emitting intel mode for

Hi Eli, Thanks for the response I have one question inline. Regards, Ben [...] > The main problem that I have hit is regarding the use of CL register in the > shift instructions. The problem is that ATT syntax states that it should be > referenced as "%cl" while Intel says just "cl" but these references occur in > X86InstInfo.td and this means that it is shared

Hello Jeffery, Thank you for the information, but I was already aware of this. I still have many concerns about GCC from the links you sent yourself: >"A file is an "Independent Module" if it either requires the Runtime Library for execution after a Compilation >Process, or makes use of an interface provided by the Runtime Library, but is not otherwise based on the >

I've tried compiling with tinycc, and assembling with yasm, and fasm even with intel syntax. I'm just wondering what available compilers and assemblers there are without trying every one of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090408/b779a781/attachment.html>

Hey, I've been trying this for a couple days now, finding different assemblers and trying different options but I can't figure it out.. I must be missing something very obvious. I got a simple "hello world" app in llvm, making the .bc file using 'llvm-as test.llvm -o=test.bc' works fine. then I can use llvm-ld to make an executable which then runs fine (although not

> Nope, llvm's .s output is only compatible with GAS and other at&t syntax > assemblers.  It turns out that MASM syntax is highly ambiguous and MASM is > not production quality for use by a compiler.  This is why visual studio > doesn't go through it.  Long term, we'd like LLVM to be able to write out .o > files directly, if you're interested in adding PECOFF

Aaron Gray wrote: >> GCC is smart enough to realize it doesn't return. That's because the >> declaration of abort() is decorated with __attribute__((__noreturn__)). >> >> So is GCC smarter than VC++? As it turns out, in VC++ the >> declaration of abort() is decorated with __declspec(noreturn). >> >> Whidbey is not stricter than 2003, it is

Van Dijck, Tom wrote: > Hey, > > I've been trying this for a couple days now, finding different assemblers and trying different options but I can't figure it out.. > I must be missing something very obvious. > > I got a simple "hello world" app in llvm, making the .bc file using 'llvm-as test.llvm -o=test.bc' works fine. > then I can use llvm-ld to

I would like to use the LLVM x86 code generator to emit Intel syntax that is compatible with Microsoft's MASM 9.x. Taking the TOT LLVM, from last week, I have found a number of changes that are required to make this work, most of which are straight forward but a couple I wanted to check with the group to see what people thought was the best thing to do. In particular, I have made all necessary

Hi Chris, > The LLVM X86 backend started out emitting intel mode for use with GAS > and it's "intel syntax mode" (which does use registers with %'s). > Unfortunately GAS has (or commonly available versions have) a number > of bugs in intel syntax mode (e.g. you can't define a function named > 'dword'), so we switched to using AT&T syntax. Ah, OK.

> By default, the cmake build generates Visual Studio project files for > the X86 target only. Take a look at > > http://www.llvm.org/docs/CMake.html#llvmvars > > for learning how to build other targets. OK thanks, I'll look at that. In the meantime, is it possible to get the assembly generated by llc to work wiht ML? That would probably be the ideal solution. Cheers Jim

On Mon, Jun 15, 2009 at 11:21 PM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote: > I can get this two work with additional changes to X86InstrInfocpp but > the problem I have with this approach is that it introduces a lot of > duplication, when all I really want to do is parameterize the final > field in the string "shl{b}\t{%cl, $dst|$dst, %CL}". I was wondering

Hi, I am using TargetMachine::addPassesToEmitFile to write out x86-64 assembly. However, the generated assembly uses the AT&T syntax. Is there a way to switch to the Intel syntax? Thanks, Frank

On Jan 21, 2010, at 2:01 PM, Jim Crafton wrote: >> Nope, llvm's .s output is only compatible with GAS and other at&t >> syntax >> assemblers. It turns out that MASM syntax is highly ambiguous and >> MASM is >> not production quality for use by a compiler. This is why visual >> studio >> doesn't go through it. Long term, we'd like

Hi all, I'm getting rather odd behavior from a call asm inteldialect(). TL;DR is "mov reg, $0" with a "i" constraint on $0 is behaving identical to "mov reg, dword ptr [$0]" and differently from "movl $0, reg" in AT&T syntax. I'm not sure how to get clang to emit an inteldialect, so for this example, I'm emitting llvm and then modifying