similar to: [LLVMdev] (possible) bytecode format change

On Fri, 8 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am not sure if it is the correct solution, but the attached patch > fixes the problem. Your solution is correct, in that it will work and follows with the current ifdef approach. I applied this patch though, which doesn't use the ifdefs, hopefully it is more robust:

> Please lemme know if it works. It does. Thanks. > I don't know what that is :( I believe that code compiled without -fpic is going into a DSO. This creates text relocations that are not supported on linux/amd64 (http://people.redhat.com/drepper/dsohowto.pdf). > -Chris Rafael

R-devel now makes use of gcc4's visibility features: for an in-depth account see http://people.redhat.com/drepper/dsohowto.pdf (and note there are older versions of that document around). Consider for example stats.so. On a gcc4 Linux system this has just three entry points gannet% nm -g stats.so | grep " T " 00002720 T R_init_stats 0004a544 T _fini 00001f28 T _init since the

I'm the guy who is working on the LLVM bytecode documentation. The document I have at present just supports the bytecodes my code generator processes, though, which is far from all of them. As I get farther along with my code generator I expect I'll get to the point where everything kind of fits together for me and I can finish it up. In the meantime, people are welcome to what I have

On Wed, Jan 21, 2004 at 08:25:23AM -0800, Robert Mykland wrote: > I'm the guy who is working on the LLVM bytecode documentation. The > document I have at present just supports the bytecodes my code > generator processes, though, which is far from all of them. As I get > farther along with my code generator I expect I'll get to the point > where everything kind of fits

Hello Everyone. I'm going to break bytecode format a little bit. This is need to support function aliases. The corresponding patch was sent to llvm-commits for review (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070416/047998.html). However, I tried to make things as much backward-compatible, as I can. Your bytecodes will be broken only if you're using module-wide

Chandler/Domagoj, On Sun, 2006-12-10 at 10:53 -0500, Chandler Carruth wrote: > Unless I'm missing something, the problem lies directly with the fact > that you are trying to do a link-stage operation with the GCC > frontend. GCC, by default, probably runs "ld" or another system > linker, which grabs the executable from binutils. This linker hasn't > been modified

Unless I'm missing something, the problem lies directly with the fact that you are trying to do a link-stage operation with the GCC frontend. GCC, by default, probably runs "ld" or another system linker, which grabs the executable from binutils. This linker hasn't been modified (yet) to include support for .bc files, but you're compiler is emitting byte code to the *.o files.

Reid Spencer wrote: > Chandler/Domagoj, > > On Sun, 2006-12-10 at 10:53 -0500, Chandler Carruth wrote: > >>Unless I'm missing something, the problem lies directly with the fact >>that you are trying to do a link-stage operation with the GCC >>frontend. GCC, by default, probably runs "ld" or another system >>linker, which grabs the executable from

John, This was my attempt to add symbol versioning to the library, letting us break ABI without breaking any existing callers. Unfortunately it doesn't work: - the new versioned symbols are marked local in libguestfs.so - the existing symbols should now have @GUESTFS_0.0 versions, but don't The documentation for this stuff is extremely thin, and I've got a bad case of

All, Post 1.9 we will start using bytecode version 7. Version 6 corresponds to release 1.9. There is some work that needs to be done to make this happen but I'm too tired to think through it right now. I will address this first thing in the morning. In the meantime, the CVS head version of LLVM just changed what version 6 bytecodes means. That means your old version 6 bytecode (before the

Distinguished LLVM Creators, I've been looking through the bytecode representation of the type definition table and had a few questions about it. There's an enum in Types.h that defines all bytecodes that represent the primitive types and a few other necessary things: 0 = 0x00 = Void 1 = 0x01 = Bool 2 = 0x02 = UByte 3 = 0x03 = SByte 4 = 0x04 = UShort (16 bits) 5 = 0x05 =

Dear All, Would somebody be able to update the Bytecode Format Manual with the 28 bit bytecode version numbers for LLVM 1.4, 1.5, and 1.6 (or point me to the file which defines it so I can look it up)? Thanks. -- John T. -- John T. Criswell Research Programmer University of Illinois at Urbana-Champaign "It's today!" said Piglet. "My favorite day," said Pooh.

Folks, I have completed a final draft of the bytecode documentation. You can find it in llvm/docs/BytecodeFormat.html in CVS. Or, if you'd prefer to view online, you can find it here: http://llvm.x10sys.com/llvm/docs/BytecodeFormat.html I'm soliciting your feedback on this document. Please let me know if anything is awkward or just plain wrong. Thanks, Reid. -------------- next part

All, Just a heads up that the bytecode format changed again last night. If you have bc files, they need to be refreshed. If you're running a nightly tester, please refresh your llvm-gcc (mirror should be updated now, or soon). The change resulted from PR1146 which redesigns the parameter attribute feature. With the redesign it became possible to reduce the size of a function type definition

On 8/29/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > Seung, > > On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > > Ok. Note that LLVM can represent irreducible loops. You can handle > > this through code duplication. > > -Chris > > > If you are willing to invest more effort into a more complicated analysis, > in many cases you

Daniel, On 8/30/07, Daniel Berlin <dberlin at dberlin.org> wrote: > On 8/29/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > > Seung, > > > > On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > > > Ok. Note that LLVM can represent irreducible loops. You can handle > > > this through code duplication. > > > -Chris >

Hi Roman, On Tue, 2006-12-19 at 17:32 -0800, Roman Levenstein wrote: > Hi, > > I just updated my LLVM sources from CVS/HEAD and rebuilt them. And I > downloaded the GCC4 frontend from the 1.9 release. > > Now I cannot compile anything, since GCC frontend seems to produce BC > files that cannot be read by llvm-dis, llc and other utils. > > llvm-dis shows a following

Hi Reid, --- Reid Spencer <rspencer at reidspencer.com> wrote: > On Tue, 2006-12-19 at 17:32 -0800, Roman Levenstein wrote: > > But since the new llvm-dis cannot disassemble, I cannot use > > llvm-upgrade, since I need a way to produce an *.ll file. > > If you can't do as Bill suggested (get the latest llvm-gcc and > compile > it), you can use this approach:

Hi, I just updated my LLVM sources from CVS/HEAD and rebuilt them. And I downloaded the GCC4 frontend from the 1.9 release. Now I cannot compile anything, since GCC frontend seems to produce BC files that cannot be read by llvm-dis, llc and other utils. llvm-dis shows a following message: Bytecode formats < 7 are not longer supported. Use llvm-upgrade. (Vers=6, Pos=9) But since the new