similar to: [LLVMdev] Bitcode not portable from linux to solaris?

To answer my own question. The problem is that Solaris ships with very old tools, and llvmc was generating assembler that worked with a fresh (gcc-4.5) compile & install. I had them handy, just further down the path. Hopefully anyone with the same problem can find this in the archive. Thanks everyone. On Mon, Jan 31, 2011 at 10:56 AM, Lally Singh <lally.singh at gmail.com> wrote:

On 02/02/2011 19:53, Lally Singh wrote: > To answer my own question. The problem is that Solaris ships with > very old tools, and llvmc was generating assembler that worked with a > fresh (gcc-4.5) compile& install. I had them handy, just further > down the path. Hopefully anyone with the same problem can find this > in the archive. > I think llvm isn't ported to

Well, then I'm royally screwed. What would I have to add to make it work, if only for a very limited subset of cases? On Wed, Feb 2, 2011 at 11:44 PM, Yuri <yuri at rawbw.com> wrote: > On 02/02/2011 19:53, Lally Singh wrote: >> >> To answer my own question.  The problem is that Solaris ships with >> very old tools, and llvmc was generating assembler that worked

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

Is llvmc meant for compilation? $ llvmc -c a.c -o a.o /usr/src/llvm/dist/etc/llvm/c:55: Error: Expecting output type value /usr/src/llvm/dist/etc/llvm/c had 1 errors. Terminating. The offending line contains: optimizer.output = bytecode which doesn't seem to be understood by llvmc. If I uncomment this line, I get another error message: $ llvmc -c a.c -o a.o llvmc: Can't find program

Hi, I've been reading through some of the documentation and I'm a little confused. What I'm wondering is if someone could explain how the different tools in LLVM (llvmc, clang, llvm-gcc, llvm-ar, etc.) work together to go from the C code I create through to a running executable (after linking). Apologies if this isn't the right list. I'm not a compiler developer so I'm

Today was the first day when I heard and read about llvm, and I would say I am pretty excited to learn about it. The design looks simply amazing and the codebase seems to be easy to follow. Way to go guys!!! I immediately downloaded and built the llvm-gcc front-end and the llvm tools and libs. Also, I could successfully use the llvm-gcc, llvm-dis and llc tools to see things in action. The only

I'm building a static analysis tool on top of LLVM. It needs to take in a C++ source file and have LLVM translate it into bitcode. In other words, it basically needs to do this: llvmc hello.cpp -emit-llvm -O0 -S -g Except that instead of writing the bitcode to a file, it needs to load it into memory (presumably as an instance of Module) for further processing and analysis. So my

On Aug 24, 2007, at 1:52 PM, Holger Schurig wrote: > Is llvmc meant for compilation? > I'm not sure what the status of llvmc is (is anyone working on it?), but I don't believe it was ready for real use or was finished. If you would like to work on it, patches are welcomed! Thanks, Tanya > $ llvmc -c a.c -o a.o > /usr/src/llvm/dist/etc/llvm/c:55: Error: Expecting output

On Thu, Oct 28, 2010 at 4:41 PM, Stephen Norman <stenorman2001 at me.com> wrote: > Hi, > > I've been reading through some of the documentation and I'm a little confused. > > What I'm wondering is if someone could explain how the different tools in LLVM (llvmc, clang, llvm-gcc, llvm-ar, etc.) work together to go from the C code I create through to a running

Hi, When I execute the command bellow: $llvm-dis Example.bc -o Example.ll I get the following wrong message: llvm-dis:Bitcode stream should be a multiple of 4 bytes in length Who can help me? 2010-04-07 yiqiuping1986 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100407/2cd7a437/attachment.html>

Hey folks, If I've got some code that I can compile using clang, that depends on a certain endianness, can I generate bitcode that will have the code operate correctly, even if run on machines of the the opposite endianness? If not, what're we talking about in specific work that'd be needed? Thanks, - Lally

On Mon, Nov 20, 2006 at 08:01:23AM -0800, Reid Spencer wrote: > On Mon, 2006-11-20 at 17:49 +1100, Emil Mikulic wrote: > > I've compiled all the object files that make up libstdc++ and libsupc++ > > into LLVM bytecode: > > http://goanna.cs.rmit.edu.au/~emil/libstdcxx.tar.bz2 (438KB) > > > > A simple test program, x.cpp: > > > > #include

I've compiled all the object files that make up libstdc++ and libsupc++ into LLVM bytecode: http://goanna.cs.rmit.edu.au/~emil/libstdcxx.tar.bz2 (438KB) A simple test program, x.cpp: #include <iostream> int main() { std::cout << "hello world\n"; return 0; } $ llvm-g++ -emit-llvm -c x.cpp $ llvmc -o=out x.o std/*.o sup/*.o $ lli out.bc Segmentation fault (core

On Mon, 2006-11-20 at 17:49 +1100, Emil Mikulic wrote: > I've compiled all the object files that make up libstdc++ and libsupc++ > into LLVM bytecode: > http://goanna.cs.rmit.edu.au/~emil/libstdcxx.tar.bz2 (438KB) > > A simple test program, x.cpp: > > #include <iostream> > int main() { std::cout << "hello world\n"; return 0; } > > $

On Nov 8, 2012, at 3:31 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Joe, > >> We have a tool which reads in bitcode, processes it, and re-emits it. We use >> this tool as a flexible way to integrate our tool into the Xcode, Android NDK, >> Chromium, and Linux build process. >> >> The problem we face is that bitcode changes, and when it does…

On 19 September 2014 14:33, Steven Wu <stevenwu at apple.com> wrote: > Well, this essentially means when someone need to change assembly syntax in > llvm-3.9, he has to go back and edit all the compatibility tests for 3.N? > Sounds like a little bit extra work, though I am not totally against it. No, the idea is that in test/Features/compatibility-3.6.ll we will have ; The file

Hello, A strange problem appears when upgrading from release_34 to testing. Some transformations to bitcode files cause registered global_ctors to not be called. Here's an example (I've also attached the complete example and pasted it below): This works: clang -fsanitize=address -flto -c -o sum.o sum.c clang -fsanitize=address -o sum sum.o This doesn't work: clang

This sounds like a good plan. Initially, the tests will be very repetitious, but over time as we make changes they will diverge. For example, before swapping the order of 'alias' and linkage in the IL, we would've had: @a = alias weak i8* @target ; CHECK: @a = alias weak i8* @target This would've been copied to compatibility-3.N.ll for the previous release before the change, and

We've noticed a difference in the embedded bitcode when compiling human readable IR to an object directly vs first compiling IR to BC and then an object through clang -cc1. If the original IR file contained an "llvm.compiler.used" gv, it will be preserved when compiling IR -> BC -> Obj. When compiling IR -> Obj directly, it will be removed. This difference does not exist