similar to: [LLVMdev] raw_ostream behavior

Hi Dan, lld takes a -emit-yaml option, which emits the intermediate representation(atoms) in YAML form. By default output goes to stdout, the user can control it by using the -o option too. The way its handled is, similiar to this piece of pseudo-code if (dash_o_option) outputFile = dash_o_option->value() else outputFile = "-" When lld tries to mix things that go to

Hi Dan, The other messages, need to go to stdout as well. Using stderr to output for a switch like --verbose is wrong in my opinion. On 8/14/2013 4:44 PM, Dan Gohman wrote: > Would it be appropriate for lld's other output to go to standard error > instead of standard output, since standard output may be used for YAML > output? > > Dan > > On Wed, Aug 14, 2013 at 12:53

The high-level answer is that library code shouldn't hardcode output paths, including "-" and including using llvm::outs(). Library code should (in general) instead accept an ostream in its API and write to wherever it is being asked to write. If this is followed, the only place in any program using llvm::outs() is code which is not part of a "library" -- i.e. it is the

Would it be appropriate for lld's other output to go to standard error instead of standard output, since standard output may be used for YAML output? Dan On Wed, Aug 14, 2013 at 12:53 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Dan, > > lld takes a -emit-yaml option, which emits the intermediate > representation(atoms) in YAML form. > > By default

Standard error is what many tools, including clang for example, use for their --verbose output. This is appropriate because it leaves standard output available for regular output data, which the user may wish to capture in a file or a pipe. Dan On Wed, Aug 14, 2013 at 2:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Dan, > > The other messages, need to go to

Shankar, What is the other output going to stdout? Seems like it could get mixed into the yaml output, causing problems. If -o is not supplied, the linker normally writes to a file called “a.out”. If this is for the core linker when running test suites, may would should have the core linker create a temp file or string buffer to write to (if -o not supplied) and then at the end read from

On Aug 14, 2013, at 3:00 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Standard error is what many tools, including clang for example, use for their --verbose output. This is appropriate because it leaves standard output available for regular output data, which the user may wish to capture in a file or a pipe. Well, at least with the darwin linker, the linker main output goes to a file

Hello, using the LLVM API, I've build one very simple function that adds two ConstantInts and returns the result. I noticed that, when I emit IR code, it is optimized to a simple "ret i16 42" when I add 40 and 2. I'd like to see the operations that are necessary to compute the result, though. Can I somehow disable this optimization in the pass, leading to more verbose IR code?

Dear all, Consider there is a program that writes to stdout using two different raw_fd_ostream-s: #include "llvm/LLVMContext.h" #include "llvm/Module.h" #include "llvm/Support/raw_ostream.h" using namespace llvm; int main() { raw_fd_ostream S(STDOUT_FILENO, false); outs() << "Hello"; S << ", world!";

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

On Wed, Nov 28, 2012 at 10:54 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Dear all, > > Consider there is a program that writes to stdout using two different > raw_fd_ostream-s: raw_fd_ostream does buffered I/O, so it's not really meant to be used like this. > #include "llvm/LLVMContext.h" > #include "llvm/Module.h" > #include

Hi Rui, Not sure if you have seen this problem, but I have been running into this problem when I run the lld tests and the failure occurence is once in 5 times. lld: ../tools/lld/lib/Core/Resolver.cpp:402: void lld::Resolver::deadStripOptimize(): Assertion `symAtom' failed. #0 0x4b05ae llvm::sys::PrintStackTrace(_IO_FILE*)

Manuel, After the discussion at last night, I have agreed that GetTemporaryDirectory() on Win32 would do bad thing, thank you. dir = GetTemporaryDirectory(); dir.eraseFromDisk(erase_contents = true); dir = GetTemporaryDirectory(); /* It doesn't create anything on Win32 due to caching */ I suppose Manuel wants GetTemporaryDirectory() to keep semantics similar mkdtemp(3). Though it is in

On 4/2/2014 12:23 PM, Nick Kledzik wrote: > On Apr 1, 2014, at 9:19 PM, Shankar Easwaran wrote: > >> Hi Nick, Bigcheese, >> >> When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option. >> >> The Gnu linker has the following options :- >> >> --demangle=[style] >> --no-demangle >>

Hi Nick, Bigcheese, When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option. The Gnu linker has the following options :- --demangle=[style] --no-demangle I found that clang/llvm-symbolizer use __cxx_demangle function. I would think that lld also need to call the same function, and I think the way we want to demangle is to have the

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

IRBuilder is a templated class, and one of the template arguments is the constant folder to use. By default it uses the ConstantFolder class which does target-independant constant folding. If you want to disable constant folding you can specify the NoFolder class instead, i.e. declare the builder as follows: IRBuilder<true, llvm::NoFolder> builder(body) On 26 Nov 2013, at 19:23, Daniel

On 10/7/2014 4:10 PM, Nick Kledzik wrote: > Shankar, > > Can you give provide a scenario where you want this? I’m not sure what you want here. a) LLVM could be built just for one target(LLVM_TARGETS_TO_BUILD) b) With LTO this case might happen more often, where an user would have compiled LLVM just for one architecture and lld would support other architectures that LLVM would not

On 4/4/2014 3:46 AM, David Chisnall wrote: > On 3 Apr 2014, at 20:49, Shankar Easwaran <shankare at codeaurora.org> wrote: > >> b) I am not planning to write a demangler. I was planning on using abi::__cxx_demangle if there was one available and the first character in the symbol was a _. >> If MSVC was defined, we would use the Undecorate API. > The demangler that

On Wed, Dec 7, 2016 at 10:02 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > This code from raw_ostream.h is really racy: > > > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path,