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

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

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

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,

============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/ =============================================================

Hi Jeff, _HEAPOK is unknown to mingw 1.0 (which is the official release). Henrik. ============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/

Hi >From: Chris Lattner <sabre at nondot.org> >Date: Thu, 15 Jul 2004 17:43:27 -0500 (CDT) >Ah, suddenly everything makes sense. If you're interested in LLVM on the >windows platform, *please* get CVS. Last night I've got the latest version of LLVM from CVS and now porting LLVM to Interix from this version on. I got this error: --------------------- gmake[1]:

Hi By manipulating a #define for G++ I've managed to compile int64_t type with ostream. Now, I'm stopped by some to me unknown constants: ----------------------------------- Compiling Constants.cpp Constants.cpp: In static member function `static bool llvm::ConstantSInt::isValueValidForType(const llvm::Type*, long long int)': Constants.cpp:368: error: `INT8_MAX' undeclared

Hi again Does cygwin support shared libraries. And if not, how did you port llvm on this issue? /Henrik >From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Date: Tue, 27 Jul 2004 00:41:53 +0200 > >Hi, > >I get this error: >------------------ >ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) >ToolRunner.cpp:396:

Hi Guys I'm trying to port and build LLVM to the Interix environment. I've succeded until the Interix version of gcc program executes: gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support' gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' Compiling CommandLine.cpp CommandLine.cpp: In function

On Sat, 3 Jul 2004, Chris wrote: > >That should work fine. I'm not familiar at all with internix, but it >appears to have a buggy header or something. From what I understand, >internix is a posix layer for windows. Have you tried compiling under >cygwin? No, not yet. >If you grab the latest CVS sources, they should work fine with >cygwin, and will probably work

>From: Misha Brukman <brukman at uiuc.edu> >Date: Sat, 3 Jul 2004 19:33:12 -0500 >Well, the patch adds #include <cstring> to CommandLine.cpp, so you >should try the patch first. If it does not work, then the Interix SDK ><cstring> is not a fully complete substitue for <string.h>, which it >should be, then you may have to manually try changing the

Hi I've found below declaration of strdup in /usr/include/string.h. But, I'm wondering why it doesn't belong to the ordinary function prototypes as extern char * __cdecl strcpy(char *, const char *);. Are you able to explain below meaning to me? #if defined(_ALL_SOURCE) \ || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED==1)) \ || (__STDC__ - 0 == 0

Hi > >Are you able to explain below meaning to me? > >#if defined(_ALL_SOURCE) \ > || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED==1)) \ > || (__STDC__ - 0 == 0 && !defined(_POSIX_C_SOURCE)) >extern char* __cdecl strdup(const char *); >#endif /* defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED == 1) */ > (RTFM) Some of the above

>From: John Criswell <criswell at cs.uiuc.edu> >Date: Wed, 14 Jul 2004 09:11:03 -0500 > > >The DataTypes.h header file is generated by the configure script and placed >into your build tree. My best guess is that your system's header files do >not correctly define these macros, so they are missing. > I did a search on the build and source trees, but neither

>From: "Reid Spencer" <reid at x10sys.com> >Date: Thu, 15 Jul 2004 18:33:30 -0400 > >On Thu, 15 Jul 2004 17:43:27 -0500 (CDT) > Chris Lattner <sabre at nondot.org> wrote: >>Sorry! LLVM 1.3 will probably be out in a few weeks... > >Speaking of which, what are your intentions for 1.3? Are you waiting on >CPR? Anything else? We're starting to

Hi Brian, I've been playing around with your test programs and came to the result: --------------------- #ifdef __INTERIX # define _GLIBCPP_USE_C99 1 //Define this macro before including isnan() function from cmath #endif #include <cmath> using std::isnan; int foo(float f) {return isnan(f);} --------------------- /Henrik >From: "Brian R. Gaeke" <gaeke at

I was only looking in the LLVM source folders. It is located in the build folders... Henrik _________________________________________________________________ F� alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/

>From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 16 Sep 2004 11:18:00 +0200 >If VC6 is not doing something wrong with templates... ;-/ As far as I know is template handling a part of some C++ ISO standard. Then, MS should adhere to this... However, what you objects against is that MS didn't implement STL the way STL should be implemented. And the reason to