similar to: [LLVMdev] A question about 'llc -march=c'

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

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

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

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;

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

hi, i also have problems compiling llvm-gcc (current svn version). llvm is current llvm svn. i tried to use every gcc version from 4.0 to 4.3 to compile llvm-gcc. i configured llvm-gcc like this (and tried every other combination of disable-shared, disable-multilib and bootstrap) : ../llvm-gcc/configure --prefix=/usr --enable-llvm=/usr --enable-languages=c,c++ --disable-shared

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 zhangzw, ... > 59 %3 = invoke > %"struct.std::basic_ostream<char,std::char_traits<char> >"* > @_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc(%"struct.std::basic_ostream<char,std::char_traits<char> > >"* @_ZSt4cout, i8* getelementptr ([10 x i8]* @.str, i32 0, i32 0)) > 60 to label %bb6

Anton Korobeynikov pravi: > Hello, Ziga. > > >> VCPP throws a warning that class is previously declared as struct. >> Either it must be struct everywhere or class everywhere. >> Declaration uses struct, while the definition uses class. >> > Nice! However it will be better to do the opposite: have it struct > everywhere. I'll fix this. >

Thank you all for your reply. if(a>10) b=10; else if (a<10) b = 5; Here is the IR of the if-elseif: 56 %0 = load i32, i32* %a, align 4 57 %cmp = icmp sgt i32 %0, 10 58 br i1 %cmp, label %if.then, label %if.else 60 if.then: ; preds = %entry 61 store i32 10, i32* %b, align 4 62 br label %if.end.4 63 64 if.else:

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: > $

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 Aug 10, 2018, at 1:28 PM, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > * The clock stuff being added in C++20 has already been discussed here. I’ve missed the discussions on file_time_type, however I thought I should throw in my opinion here before it is too late to do anything about it. I believe it is a mistake to model file_time_type with 128 bits. It

Mohd-Hanafiah Abdullah wrote: > 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

Hi All, Recently I am using clang++ (3.8.0) to compile some c++ programs and find that some type names will be changed after linking different modules. Here is a simple example: I have two files: main.cpp and b.cpp main.cpp #include <iostream> using namespace std; class A { public: virtual void f() { cout << "A:\tf\n"; } }; int main () { A *p = new A;

Hi, I'm playing around with llvm and the Kaleidoscope tutorial and first of all I have to say I'm really impressed. LLVM rocks! Unfortunately I've now run into a linker error while trying to optimize the IR or turn it to bitcode and likely due to my very limited experience with c++ I just can't figure out how to resolve it. The linker complains that the llvm::WriteBitcodeToFile

I'll ask again that question. Thank you Adrian, I've looked through IR Verifier and it helps me to understand some parts of retrieving metadata and debug info. But , after that, I've faced with another problem: Original Code: std::wcout << L"WCHAR_HELLOWORLD" << std::endl;b IR Code: @.str.2 = private unnamed_addr constant [17 x i32] [i32 87, i32 67, i32 72,