search for: subtools

...be versioned and would be allowed to change once the tool moves out of the experimental stage. * The format of the human readable Sanitizer reports is allowed to change but the parser should be correspondingly changed when this happens. This will be enforced with tests. The parsing tools would be subtools of the asan, tsan, ubsan subtools. This would require the user to explicitly communicate the report type ahead of time. Command line invocation would look something like: ``` llvm-xsan asan parse < asan_report.txt > asan_report.json llvm-xsan tsan parse < tsan_report.txt > tsan_report....

...once the tool moves out of the experimental stage. >> * The format of the human readable Sanitizer reports is allowed to >> change but the parser should be correspondingly changed when this >> happens. This will be enforced with tests. >> >> The parsing tools would be subtools of the asan, tsan, ubsan subtools. >> This would require the user to explicitly communicate the report type >> ahead of time. Command line invocation would look something like: >> >> ``` >> llvm-xsan asan parse < asan_report.txt > asan_report.json >> llvm-x...

...for converting between ir formats. Extending this to object code assembly feels wrong. I think the solution to this is to move the llvm developer only tools (llc, lli, opt, as, dis, bugpoint, bcanalyzer, diff, extract, link) to the llvm tool. This would have a git like interface for accessing the subtools. The other tools remain as user tools and still support bitcode. - Michael Spencer

Tanya Lattner wrote: > You can set the program-prefix to be "llvm-". We actually recommend > this and its in the README.llvm. We do not require it though. > > -Tanya > Hello Tanya. Yes, I'm aware of this, but one of the programs that got installed for me, like i686-apple-darwin8.10.1-gcc-4.0.1, was not getting the program prefix, and was getting used by gcc.

...ch should not be added to your $PATH. Since they aren't in your path, the system GCC doesn't pick them up. To get llvm-gcc into my path, I then add symlinks from /usr/local/bin/ llvm-gcc to /usr/local/llvm-gcc/bin/llvm-gcc (likewise g++). This adds the driver to the path but not the subtools. This works like a charm for me (though it is gross and hackish). If your patch eliminates the need for this and doesn't break anything else, I'd love to see it in llvm 2.2. One of our plans for 2.1 that I hope will work out is to provide a "universal" binary for the ma...

Binutils and LLVM As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems. As a start, I'd like to summarize the current status, and ask people for help updating the list. List taken from <http://www.gnu.org/software/binutils/>

On Sep 18, 2007, at 9:28 PM, Erick Tryzelaar wrote: > Tanya Lattner wrote: >> LLVMers, >> >> The 2.1 pre-release (version 1) is available for testing: >> http://llvm.org/prereleases/2.1/version1/ > > A couple months ago, I had a problem packaging llvm-gcc for macports > because one of the binaries from llvm-gcc was somehow getting used by > Apple's gcc

On Fri, 2005-04-22 at 11:39 -0500, Misha Brukman wrote: > On Fri, Apr 22, 2005 at 08:54:07AM -0700, Reid Spencer wrote: > > There has been some debate about the default value. I tend to agree > > with Chris on this. The default should be "all" so that everything > > gets tested by default. More sophisticated users can limit the targets > > that are built by

Not sure I follow how this would work. "llvm" is an executable, and "opt" is a symlink to "llvm"? How does llvm then detect that it needs to use the opt set of commands? That said, in principle sure you could have "llvm opt <opt-specific command syntax>" or "llvm llc <llc options>". At some point you'd probably need to extend

Hi all, please, is there some utility/command/... to list all installed kernel modules ? Peter Rosa