similar to: [LLVMdev] AsmWriter.cpp:255: error: ambiguous overload for `std::basic_ostream<char,...

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;

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

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,

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

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 +#

> >It appears that your libstdc++ does not support insertion of 64-bit >integers into iostreams. Did I mention that you should try cygwin? ;-) > >-Chris > Hmmmm :-) /Henrik _________________________________________________________________ F� alle de nye og sjove ikoner med MSN Messenger http://www.msn.dk/messenger

Hi Scott, > On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: > > this is indeed a miscompilation by your system compiler. However so many > > compilers miscompiled this that a workaround was committed to svn. So you > > may want to check out llvm and llvm-gcc from svn. Alternatively, maybe > > the patch applies to llvm 2.5 too.

On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: > this is indeed a miscompilation by your system compiler.  However so many > compilers miscompiled this that a workaround was committed to svn.  So you > may want to check out llvm and llvm-gcc from svn.  Alternatively, maybe > the patch applies to llvm 2.5 too.  I've attached it. I will try the

On Tue, May 5, 2009 at 11:33 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Scott, > >> On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: >> > this is indeed a miscompilation by your system compiler.  However so many >> > compilers miscompiled this that a workaround was committed to svn.  So you >> > may want to check

On Fri, Feb 27, 2009 at 4:32 PM, Jay Foad <jay.foad at gmail.com> wrote: > >> Could you please rig Makefile.rules or something to print out the value > >> of $(LLVM_ON_WIN32) ? The only way I can think of this happening is if > >> that's erroneously false. > > This works for me: > > Index: Makefile.rules >

On Fri, Feb 27, 2009 at 4:50 PM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Fri, Feb 27, 2009 at 4:32 PM, Jay Foad <jay.foad at gmail.com> wrote: > >> >> Could you please rig Makefile.rules or something to print out the value >> >> of $(LLVM_ON_WIN32) ? The only way I can think of this happening is if >> >> that's

here are the cpp file: $ cat -n eh1.catch.cpp 1 #include <iostream> 2 3 int main() 4 { 5 try { 6 throw 78; 7 } 8 catch (int){ 9 10 std::cout << "at catch\n"; 11 12 } 13 } LLVM-IR: $ llvm-g++ -S -emit-llvm eh1.catch.cpp -o eh1.catch.ll ... 46 define i32 @main() {

Hi there, I am a student considering a compiler design based dissertation with llvm. I am having problems building llvm on OpenBSD-current. I hope to make a port of llvm for OpenBSD once I have figured out how to build it. Observe: llvm[3]: Compiling Deserialize.cpp for Release build In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead er.h:18, from

Hi! I'm trying to compile llvm 2.2 with gcc 4.3.0 on FC8. My compile is failing with the following error(s): error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' If you've run into this, how did you get around this issue? thx in advance! -Bernardo -------------- next part -------------- An HTML attachment was scrubbed...

hi, I try to build hello.cpp using both llvmg++ and GNU g++, the generate llvm bytecode's size is about 960K, and the size of binary code generated by g++ is only 13K. Could anyone explain the difference between the two result? BWT: I rebuild the cfrontend in RH linux9.0, but when I build the hello.cpp the llvmG++ reports warnings too, it shows: ----------------------------- [yue at RH9

On Fri, 17 Nov 2006, Mohd-Hanafiah Abdullah wrote: > After converting a piece of C++ code to C one of the functions that are > generated is this: > _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc This is defined in the C++ standard library. You can get the demangled name like so: $ c++filt _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc std::basic_ostream<char,

On Thu, 2006-11-16 at 21:08 -0800, Chris Lattner wrote: > On Fri, 17 Nov 2006, Mohd-Hanafiah Abdullah wrote: > > After converting a piece of C++ code to C one of the functions that are > > generated is this: > > _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc > > This is defined in the C++ standard library. You can get the demangled > name like so: > $

On 31.05.2011 19:45, Devang Patel wrote: > > On May 31, 2011, at 10:36 AM, trash-stuff at gmx.de > <mailto:trash-stuff at gmx.de> wrote: > >> On 31.05.2011 19:22, Devang Patel wrote: >>> >>> On May 30, 2011, at 11:11 AM,trash-stuff at gmx.de >>> <mailto:trash-stuff at gmx.de>wrote: >>> >>>> Hi all, >>>>

On Fri, Dec 5, 2008 at 1:57 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >> / * snip */ > > Actually, rebuilding it makes "debug tblgen" fail with the errors at > the end of this email, and as such everything that depends on it, how > odd... > When I get back to that