similar to: [LLVMdev] Inline assembler

On Wed, 7 Nov 2007, Aaron Gray wrote: > Does LLVM support inline assembler :- > a) In GCC front end ? yes > b) withing .ll files ? yes. > If so is there any documentation, and could you point me to the code > that implements this ? langref has a short description, but your best bet is to take some example C code that uses inline asm and compile it with "llvm-gcc

Oleg, > - llvm/make tools-only worked ok Good. > - llvm-gcc/make all failed with the following message (2nd try): > make[2]: Leaving directory `/home/oleg.smolsky/llvm-gcc-build/gcc' > make[1]: Leaving directory `/home/oleg.smolsky/llvm-gcc-build/gcc' > Checking multilib configuration... > multilib.out is unchanged > Configuring in i686-pc-cygwin/libstdc++-v3 >

Hello Aaron, Aaron Gray wrote on 14/10/2005 at 10:22 a.m.: > I am not sure but it looks like a problem with your Cygwin > instillation ? Try a 'make configure' or 'make reconfigure'. Hmmm, I was able to build llvm/tools-only.... As for "make configure" - that didn't help. > Here's a link to the instructions I developed for building LLVM on > Cygwin

Also, this error: /usr/src/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86CompilationCallback2' doesn't make sense. X86CompilationCallback2 is not visible outside of X86JITInfo.cpp, and line 73 of X86ISelPattern.cpp is in the middle of a comment block.

Aaron Gray wrote: > Turns out I did not have Perl installed and hence no pod2man command, so > it was not groff after all. > > But 'true', what ever it does, does not seem to be working on Cygwin. > > true pod2man --release=1.5 --center="LLVM Command Guide" > /usr/build/llvm/../../src/llvm-1.5/docs/CommandGuide/analyze.pod >

Turns out I did not have Perl installed and hence no pod2man command, so it was not groff after all. But 'true', what ever it does, does not seem to be working on Cygwin. true pod2man --release=1.5 --center="LLVM Command Guide" /usr/build/llvm/../../src/llvm-1.5/docs/CommandGuide/analyze.pod /usr/build/llvm/docs/CommandGuide/analyze.1 'true' seems to behaving like a

Here's the instructions as I have them so far :- http://angray.members.beeb.net/llvm/MakingLLVM.html I was wondering whether you could look them over to see if I am doing something obviously wrong. Thanks, Aaron

Hi, I installed the cfrontend 1.5 and LLVM 1.5 from source in cygwin successfully using GCC3.4.3 and binutils2.15 (as in makefiles do not complain errors except some warnings). However when I do this, there are some errors like, *************************************************************** u0201201 at 9nnvf2ay /home/cfrontend/install/lib $ llvm-ranlib libiberty.a llvm-ranlib: Error opening

>You're welcome to join me. Say when you're ready to dig... I'll join in at some point, if that is okay. I'd like to get LLVM working on MinGW running as well as Cygwin. Aaron

> This is almost exactly what you want to do. Please make the array be [0 x > int] though, as it is undefined in llvm to access past the end of an array > with non-zero length. I added a note about zero-length arrays here: > > http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr > http://llvm.cs.uiuc.edu/docs/LangRef.html#t_array > > As you mention above, you

Here it is, a missing file "analyze.1" :- /usr/bin/groff -Tps -man /usr/build/llvm/docs/CommandGuide/analyze.1 > /usr/buil d/llvm/docs/CommandGuide/analyze.ps troff: fatal error: can't open `/usr/build/llvm/docs/CommandGuide/analyze.1': No such file or directory make[2]: *** [/usr/build/llvm/docs/CommandGuide/analyze.ps] Error 1 make[2]: Leaving directory

I am wanting to upgrade my Fedora Core 6's GCC as it is version 4.1.1 and that does not build LLVM-GCC4. What version of GCC is recomended ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070303/c5da364e/attachment.html>

> You can get one for free on code.google.com. It comes as part of code > hosting. Authentication/authorization for both wiki and svn is > governed by the same credentials as given by the project owner(s) (the > wiki is driven by the same svn repo as the code). So even hosting svn > there might be a good thing . That would not host the commits mailing list. Aaron

You can get one for free on code.google.com. It comes as part of code hosting. Authentication/authorization for both wiki and svn is governed by the same credentials as given by the project owner(s) (the wiki is driven by the same svn repo as the code). So even hosting svn there might be a good thing . On 4/14/07, Reid Spencer <rspencer at reidspencer.com> wrote: > On Fri, 2007-04-13 at

> I installed the cfrontend 1.5 and LLVM 1.5 from source in cygwin > successfully using GCC3.4.3 and binutils2.15 (as in makefiles do not > complain errors except some warnings). > > However when I do this, there are some errors like, > > *************************************************************** > u0201201 at 9nnvf2ay /home/cfrontend/install/lib > $ llvm-ranlib

> The LLVM IR opcodes Add, Sub, and Mul have been each split into > two. Add, Sub, and Mul now only handle integer types, and three > new opcodes, FAdd, FSub, and FMul now handle floating-point types. Dan, Wondering the reason why there is no FDiv ? Thanks, Aaron

> Also, it would be really nice if an official > cygwin build (the binary) was published too. I spent quite a bit of > time screwing with it a few months ago, and it was quite a bastard to > get going... I had quite a time with it too, could only get the debug version to build as there seemed to be an internal problem with ld. I would very interested in how you got it running and

Hello, The LLVM IR opcodes Add, Sub, and Mul have been each split into two. Add, Sub, and Mul now only handle integer types, and three new opcodes, FAdd, FSub, and FMul now handle floating-point types. The main LLVM APIs are currently preserving backwards compatibility, transparently mapping integer opcodes to corresponding floating-point opcodes when the operands have floating-point types.

>Sorry for the delay. Please be aware, that these instructions has not been >used lately. However, I'll try to follow up on your questions. Thanks for getting back to me. Unfortunately I lost my Cygwin configuration and cannot even seem to get GCC 3.4.3 built on CygWin now, when I had it built before. Been trying all day to get it to work maybe I will crack it tomorrow as I have had

On Fri, 24 Jun 2005, Aaron Gray wrote: >> As you mention above, you should use malloc and cast the return value. If >> you want to get the desired size in a target-independent way (always good), >> you should do something like this: ... > Chris you should maybe add this example to the getelementptr documentation. This isn't really appropriate for the reference