search for: f_forc

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. Accompanying this is a change to the command-line tools. The tools will now overwrite...

...nstead of std::cerr, llvm::raw_fd_ostream instead of std::ofstream, etc. 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). 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? -- Óscar

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 file > exists, though no one > actually appears to want this. > > Accompanying this is a change to the command-line tools. Th...

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. >

Ó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 constructors. This makes it unneccessarily hard to support different LLVM versions in a frontend. I understand why the llvm::raw_fd_ostream interface was changed, but it w...

...h for clients which want to keep using std::ostream. > 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). I believe that Dan plans to fix the "force by default" issue, at least. > 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? Inten...

Jeffrey Yasskin wrote: > See Owen's email about docs for the 2.6 release, but it's really not > that hard to keep up with trunk. I recently merged trunk LLVM into > Unladen Swallow, and the changes I needed to make are at > http://code.google.com/p/unladen-swallow/source/detail?r=724. Thanks Jeffrey, that was really very helpful! I have Pure working with both the LLVM 2.6