similar to: [LLVMdev] : trouble with compiling

Vadim Khoptynets <vadya.poiuj at gmail.com> writes: > Hello, Óscar! > > I had some problems with my machine, so I've reistalled system and LLVM > repository. And now, I have another trouble during compilation: > make[1]: Entering directory `/media/data/dev/llvm/bin/tools/llvm-config' > llvm[1]: Constructing LLVMBuild project information. > /usr/bin/env: python:

Hello everyone! Could somebody advice me, how can I run llvm-tblgen to get MyTargetGenRegisterInfo.inc file to include in MyTargerRegisterInfo.h ? Unfortunately, I haven't found this information in "Writing an LLVM Compiler Backend" and "TableGen Fundamentals". -- Regards, Vadim. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello everyone! There is segmentation fault during translating a simple function with my backend. Investigation with gdb has shown that address of InstrNameData array in generated file MyTargetGenInstrInfo.inc is out of bounds. Also, if I run llc without -view-dag options, NumOpcodes equals 0 inside llvm::MCInstrInfo::get function, although there are some instructions (they are appeared in

Hello everyone! Is there any documentation about LLVM backend implementation, except "Writing an LLVM backend"? I'm trying to write InstrFormats.td and InstrInfo.td for my backend now. After reading "Writing an LLVM backend" and "Creating an LLVM Backend for the Cpu0 Architecture", many black holes have remained. These tutorials describe it on concrete examples,

Hi Vadim, I am the book author of "Creating an LLVM Backend for the Cpu0 Architecture". Your question is right. More documents is good for programmer just like plentiful book in Linux Programming, even though the GCC backend compiler book is seldom. As you can see, I have let readers know how to write a RISC backend in my book but lack of the CISC backend features, like the complex

Hello everyone! I've started to implement a ColdFire backend, but there are some troubles during configuring: $ ../llvm/configure --enable-targets=x86,x86_64,coldfire ... ... ... checking whether byte ordering is bigendian... no configure: error: Unrecognized target coldfire configure: error: ../../../llvm/projects/sample/configure failed for projects/sample I've added ColdFire to : 1)

Hello developers! Could you, please, inform me about actual open projects? Where can I find this information? Does this list contains up to date information http://llvm.org/OpenProjects.html#new ? -- Regards, Vadim. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120922/3db4debe/attachment.html>

On 9/22/12 9:01 AM, Vadim Khoptynets wrote: > Hello developers! > > Could you, please, inform me about actual open projects? Where can I > find this information? Does this list contains up to date information > http://llvm.org/OpenProjects.html#new ? I'm not sure if all of the information is up to date, but I suspect some of the items are still unimplemented. The best thing

On Fri, Feb 01, 2013 at 04:43:59PM +0200, Vadim Khoptynets wrote: > Hello everyone! > > I've started to implement a ColdFire backend, but there are some troubles > during configuring: > > $ ../llvm/configure --enable-targets=x86,x86_64,coldfire > ... > ... > ... > checking whether byte ordering is bigendian... no > configure: error: Unrecognized target

Hello, I am a new member of this forum. One of the reasons I registered was that I could not clarify following question: I cannot print to PDF using MS Office 2003. I am running it on Wine, I have Ubuntu Intrepid. Of course I can open the same xls or doc file in Open Office, but these files are very precise and sensitive, and OO distorts their fine architecture. I did not try frank print

On Fri, Feb 1, 2013 at 4:01 PM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Feb 01, 2013 at 04:43:59PM +0200, Vadim Khoptynets wrote: >> Hello everyone! >> >> I've started to implement a ColdFire backend, but there are some troubles >> during configuring: >> >> $ ../llvm/configure --enable-targets=x86,x86_64,coldfire >> ... >>

Hello everyone! After I've checked out Clang and Compiler-RT repositories, I receive this error during compilation: llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp: In member function 'bool {anonymous}::CompareDiagnostics::operator()(const clang::ento::PathDiagnostic*, const

Hi Vadim, which compiler are you using to to the build, what platform are you on, how did you configure LLVM, clang etc ? Ciao, duncan. On 09/09/12 03:36, Vadim Khoptynets wrote: > Hello everyone! > > After I've checked out Clang and Compiler-RT repositories, I receive this error > during compilation: > > llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build >

Hi! just a minor thing: FormattedStream.h is in llvm/Support/FormattedStream.h and not in llvm/CodeGen/FormattedStream.h, therefore the comment at the beginning of the file has to be changed. -Jochen

Building on OS X 10.7.1 with the standard toolchain, I have seen the following linker warnings going back a number of versions in trunk whenever I build an executable linked with LLVM: ld: warning: direct access in llvm::fouts() to global weak symbol llvm::formatted_raw_ostream::~formatted_raw_ostream() means the weak symbol cannot be overridden at runtime. This was likely caused by

On 28.12.2011, at 19:02, Jonathan Ragan-Kelley wrote: > Building on OS X 10.7.1 with the standard toolchain, I have seen the > following linker warnings going back a number of versions in trunk > whenever I build an executable linked with LLVM: > > ld: warning: direct access in llvm::fouts() to global weak > symbol llvm::formatted_raw_ostream::~formatted_raw_ostream()

We've had this argument before. IMO LLVM should not be in the business of closing stdout, and no code in lib/ should print to stdout because users may expect output there (-o -). On Fri, Jan 23, 2015 at 10:20 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-Jan-23, at 09:52, mats petersson <mats at planetcatfish.com> wrote: > > > >

I was just fixing a bug that was caused by `stdout` being closed before the runtime has done `fflush(stdout)` [or however this is implemented in the runtime]. The cause of this seems to be that `outs()` returns a static object created from `raw_fd_stream(STDOUT_FILENO, true)` - the `true` being the `shouldClose` parameter. Surely LLVM is not supposed to close `stdout` as part of its operations?

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

Hi there, I'm having some trouble compiling llvm from trunk in the svn. I configured it with: CC=gcc CXX=g++ ./configure --enable-optimisation=yes --enable-assertions=no But I have this error: llvm[1]: Building llvm-config BuildVariables.inc file. llvm[1]: Compiling llvm-config.cpp for Release build 3.1_svn/llvm/tools/llvm-config/llvm-config.cpp:45:35: fatal error: LibraryDependencies.inc: