similar to: [LLVMdev] Understanding tail calls

On Mar 16, 2010, at 6:46 PM, Scott Ricketts wrote: > I have some code generated with llvm-g++ and llvm-link that includes a tail call that is confusing me for two reasons: > > 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position) The "tail" marker has a very specific description in LLVM IR: it says that the caller does not access the

On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > HI > Did you run the static constructor and destructor? How did you make your process symbols visible to ORC jit? Yes. It's the constructor that generates the undefined symbol error. We use DynamicLibrary::LoadLibraryPermanently(nullptr) to add process symbols. > Could you

You can add symbols from Archieve via StaticLibrarySearchGenerator. But it is added recently though On Tue, 27 Aug 2019 at 21:02, Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > I tried it, but I can't able to reproduce it. > > Test Program: > #include <fstream> > int main() > { > std::ifstream stream1, stream2; >

Hello xapian users, The server I'm compiling on is a little odd. SunOS on a sun4 architecture. Fails when linking, gives the following, memcpy 0x10 /usr/local/gcc-3.3.2/lib/./libstdc++.a(ctype.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status *** Error code 1 make: Fatal error:

Greetings, LLVM wizards. We are using Clang and Orc JIT (v1) to compile and execute C++ code on the fly. If a C++ module calls functions from external libraries, we add them via DynamicLibrary::LoadLibraryPermanently(). The problem we have run into recently is when a module calls a function from the STL -- in particular this swap() function for input streams: #include <fstream>

Hi guys Is some one able to explain me, why these errors emerge: gmake[2]: Entering directory `/usr/local/src/llvm/lib/VMCore' Compiling AsmWriter.cpp AsmWriter.cpp: In function `void WriteConstantInt(std::ostream&, const llvm::Constant*, bool, std::map<const llvm::Type*, std::string, std::less<const llvm::Type*>, std::allocator<std::pair<const llvm::Type* const,

No, Chris, I'm not buying that argument, due to I've tweaked /usr/include/types.h a little bit, so the configuration and compilation of the cfrontend would be correct: /* * 64bit type for BSD compatability */ #ifdef __GNUC__ typedef long long int quad_t; typedef unsigned long long int u_quad_t; typedef long long int int64_t; typedef unsigned long long int u_int64_t;

Thanks for the suggestion, Andre. I downloaded GNAT GPL 2007, and followed the directions on your web page. Now I get a lot of C++ errors. In fact, the output I captured to a log file is over six megabytes just from the start of the problem command to the termination of the make. I'm obviously not going to include it all here, but the command and the first few errors are copied below.

On Wed, 7 Jul 2004, Henrik Bach wrote: > This tweak seems to work. > > As far as I can see, correct me if I'm wrong, it is the compiler, that can't > figure out which std::basic_ostream to use. Why? What I'm saying is that it appears that your implementation of operator<< is not functional or is missing. You said that you are using GCC on internix. Is it possible

Yes, Chris you're right. It seems that my << operator for int64_t is missing in my '/opt/gcc.3.3/include/c++/3.3/bits/ostream.tcc' file. Which ordinary version of GCC are you working with and how do your definition of the << operator for int64_t look like? /Henrik > >Here is an excerpt from the config.log for LLVM: > >configure:19451: checking for int64_t

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

I ran the LLVM regression tests today (via make check) and noticed that llvm-ranlib crashes with a Bus Error on my test system (a fairly old RedHat 9 system), using the latest CVS version. I did some digging and I think I know what the problem is, and I have attached a quick and dirty patch that fixes the problem for me, but I need a suggestion about how it should be integrated properly. Here

On Mon, Aug 10, 2015 at 8:08 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Mon, Aug 10, 2015 at 5:53 PM, Brian Cain via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> First off, thanks -- this is a pretty great library and it feels like I'm >> learning a lot. >> > > Thanks! > > >> I'm getting some

The Wine development release 1.5.7 is now available. What's new in this release (see below for details): - New version of the Gecko engine based on Firefox 13. - Dynamic device support with UDisks2. - More stream classes implemented in the C++ runtime. - Support for metadata in TIFF files. - Fleshed out WBEM implementation. - Improved support for printer paper sizes. - Various

Here is an excerpt from the config.log: configure:19451: checking for int64_t configure:19476: gcc -c -g -O2 conftest.c >&5 configure:19479: $? = 0 configure:19482: test -s conftest.o configure:19485: $? = 0 configure:19496: result: yes configure:19511: checking for uint64_t configure:19536: gcc -c -g -O2 conftest.c >&5 configure:19539: $? = 0 configure:19542: test -s conftest.o

Okay, let's try this again. I've taken all the source and header files needed to build libstdc++ and libsupc++, and put together a small and very simple Makefile that automates the process. Anyone interested can grab the whole thing from here: http://goanna.cs.rmit.edu.au/~emil/dietstdcxx.1.tar.bz2 (101KB) Usage instructions: 1) Run GNU make: $ gmake This will produce dietstdcxx.bc

Report by Eric Lindblad 28-08-2015 http://www.ericlindblad.blogspot.com As of Windows 8.1 MS has discontinued enabling for Interix, so perhaps there is little or no interest in this e-mail's subject matter. NB: As far as possible languages for xapian-bindings I only have be able to compile earlier versions of Tcl with a static library on Interix 3.5, Perl versions fail 'make check',

Question by Eric Lindblad 05-09-2015 http://www.ericlindblad.blogspot.com I would enquire if anyone has an opinion on whether it might be a possibility that adding the following #ifdef in certain xapian-core-1.2.21 /common and/or /backends files following the string #include <sys/types.h> might move closer towards resolution the 'ambiguous overload' issue. +#ifdef __INTERIX +#

So I've been looking around for people who have built shared libraries on windows and have run in to a bit of a stumbling block. I'm able to compile without the BUILD_SHARED_LIBS flag but if I put turn the flag on as follows: cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_SHARED_LIBS:BOOL=ON ../llvm-2.7 Then call: mingw32-make I get: ... Linking CXX

I'm attempting to build Firefox on Windows using clang-cl with -fprofile-instr-generate (*), but I'm running into some linker errors that I haven't been able to make sense of. lld-link.exe: error: duplicate symbol: __profc_?width at ios_base@std@@QEBA_JXZ in minidump-analyzer.obj and in ..\google-breakpad\src\processor\basic_code_modules.obj lld-link.exe: error: duplicate symbol: