similar to: [LLVMdev] std::cout << *MyModule does not work anymore

On Mon, Aug 24, 2009 at 5:40 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > It seems that support for dumping text representation of LLVM objects to > standard channels and C++ output streams was removed. My guess is that > now we must use errs() instead of std::cerr, llvm::raw_fd_ostream > instead of std::ofstream, etc. Correct. std::ostream has been purged from LLVM; the only

Óscar Fuentes wrote: > The changes are not trivial, as for instance llvm::raw_fd_ostream > without flags fails if the file exists, but std::ofstream does not. The > changes include using new names for flags that already exist on the > standard namespace (F_Force instead of O_TRUNC, etc). Also, each of LLVM <=2.5, 2.6 and 2.7(svn) provide their own, incompatible llvm::raw_fd_ostream

On Aug 25, 2009, at 1:04 AM, Albert Graef wrote: > . For many applications > other than LLVM itself, the basic LLVM <=2.5 interface which just > overwrites existing files is all that's ever needed. On LLVM trunk, raw_fd_ostream is now back to overwriting files by default, as it is the unanimous preference among in-tree users (and out-of-tree users that I'm aware of). Dan

Albert Graef wrote: > I understand that. But in this specific case it would be very easy to > maintain, no? FWIW, suggested patch attached. That makes the LLVM 2.5 style raw_fd_ostream constructor work with the trunk (r80036). Note that this just adds a second constructor, existing code will continue to work as before. I'd be happy to prepare an analogous patch for the 2.6 release

On Aug 25, 2009, at 12:24 PM, Albert Graef wrote: > Trunk (r80020): > raw_fd_ostream(const char *Filename, std::string &ErrorInfo, > unsigned Flags = 0); > > It would be helpful to emulate the LLVM 2.5 variant of the constructor > on both 2.6 and trunk, so that frontend developers don't have to code > against three different versions of the

On Aug 25, 2009, at 3:40 PM, Albert Graef wrote: > Albert Graef wrote: >> I understand that. But in this specific case it would be very easy to >> maintain, no? > > FWIW, suggested patch attached. That makes the LLVM 2.5 style > raw_fd_ostream constructor work with the trunk (r80036). Note that > this > just adds a second constructor, existing code will continue to

Dan Gohman wrote: > > On Aug 25, 2009, at 1:04 AM, Albert Graef wrote: >> . For many applications >> other than LLVM itself, the basic LLVM <=2.5 interface which just >> overwrites existing files is all that's ever needed. > > On LLVM trunk, raw_fd_ostream is now back to overwriting files by > default, as it is the unanimous preference among in-tree users

Chris Lattner wrote: > We do not guarantee API stability at all, so this is just the tip of the > iceberg. I understand that. But in this specific case it would be very easy to maintain, no? > It seems that it would be relatively easy to get autoconf to make a > include/llvm/Config/Version.h file that did this. I already have the necessary autoconf magic to deal with this in my

Daniel Dunbar <daniel at zuster.org> writes: [snip] >> Is all this an unintended change or an intentional one, and if the >> later, could you direct me to something that explains what we gain on >> exchange of this restriction? > > Intentional. std::ostream has long been deprecated in LLVM, each > release has increased the degree of deprecation. The coding

Chris Lattner wrote: > Given that we don't guarantee backwards compatibility and prefer to keep > our APIs clean and tidy, why should we take this? I already said that: To make it easier for out-of-tree frontends to support at least the last few LLVM versions. If that's a low priority then don't. I can live with it. Please understand that I don't complain about API breakage

Dear all, I am currently learning how to create R packages using C++ classes. For this purpose I have written a small package MyClass (which I try to attach since I do not have access to a website). MyClass has methods WriteFileC() and WriteFileCpp() which implement C-style and C++-style writing of a table to a file using FILE or ofstream respectively, and the corresponding R-functions

On Aug 25, 2009, at 11:34 PM, Albert Graef wrote: > Chris Lattner wrote: >> Given that we don't guarantee backwards compatibility and prefer to >> keep >> our APIs clean and tidy, why should we take this? > > I already said that: To make it easier for out-of-tree frontends to > support at least the last few LLVM versions. If that's a low priority > then

Hello, The following describes an API change on trunk. The change is not in the 2.6 branch. The raw_fd_ostream class now defaults to overwriting its output file, and the F_Force flag which was introduced only recently is gone. There's a new F_Excl flag to support users wanting the behavior of returning an error if the file exists, though no one actually appears to want this.

Hi Óscar, > Maybe there was a solution that was okay for those concerned with fast & > lightweight executables and for the others who care most about > consistency and code stability. I would appreciate if this changes are > discussed before applying them on the future (maybe I missed the > thread), flagging the subject with something that indicates that the > outcome of the

On Wed, Aug 26, 2009 at 1:20 PM, Chris Lattner<clattner at apple.com> wrote: > > On Aug 25, 2009, at 11:34 PM, Albert Graef wrote: > >> Chris Lattner wrote: >>> Given that we don't guarantee backwards compatibility and prefer to >>> keep >>> our APIs clean and tidy, why should we take this? >> >> I already said that: To make it easier

Hi All, I am trying to write code for simple instrumentation. What I want to do is to insert a call to an external function for result of each conditional branch instruction. This external function simply print true or false based on the result of condition. The modified code is then written into new file. However when I try to link that file with another bitcode file (containing external

Dan Gohman wrote: > Hello, > > The following describes an API change on trunk. The change is not in > the 2.6 branch. > > The raw_fd_ostream class now defaults to overwriting its output file, > and the > F_Force flag which was introduced only recently is gone. There's a > new F_Excl flag to > support users wanting the behavior of returning an error if the

On Thu, Jun 3, 2010 at 9:43 PM, Nehal Gandhi <nbg2k7 at gmail.com> wrote: > Hi All, > > > > I am trying to write code for simple instrumentation. What I want to do is > to insert a call to an external function for result of each conditional > branch instruction. This external function simply print true or false based > on the result of condition. The modified code is

On Aug 23, 2009, at 4:29 PM, Albert Graef <Dr.Graef at t-online.de> wrote: > > One thing I noticed is that writing LLVM assembler code (print() > methods) seems to be horribly slow now (some 4-5 times slower than in > LLVM 2.5). This is a real bummer for me, since Pure's batch compiler > uses those methods to produce output code which then gets fed into > llvmc. >

Hi folks, just installed the new llvm 1.9 build and noticed that my code no longer worked. It seems something has changed with addPassesToEmitFile(). First, the arguments to that method changed so that it no longer takes a PassManager, but only a FunctionPassManager. Instead there is a addPassesToEmitWholeFile() method, but that is marked as optional, and when I change my code to