similar to: [LLVMdev] Binary output to cout on Windows

I'm trying to resolve an issue that occurs in the native Windows implementation of LLVM (it probably doesn't occur in Cygwin, but I haven't checked). Namely, when calling llvm-as < input.ll > output.bc OR llvm-as < input.ll | opt outputting to cout is adding \r (the CR character) to newlines. This specifically causes problems in WriterContext::write(...)

The solution (provided in Microsoft's documentation) is to add: #include <cstdio> #include <io.h> #include <fcntl.h> and run: int result = _setmode( _fileno(stdin), _O_BINARY ); if( result == -1 ) { std::cerr<<"Cannot set input mode to binary."<<std::endl; return 1; } result = _setmode( _fileno(stdout), _O_BINARY ); if( result == -1 ) {

On Tue, 23 May 2006, Michael Smith wrote: > The solution (provided in Microsoft's documentation) is to add: > #include <cstdio> > #include <io.h> > #include <fcntl.h> > and run: > int result = _setmode( _fileno(stdin), _O_BINARY ); > if( result == -1 ) > { std::cerr<<"Cannot set input mode to binary."<<std::endl; return 1; >

Nothing really needs to be done on Unix, because to my knowledge Unix doesn't differentiate between text and binary on stdin/stdout. ~Michael -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Reid Spencer Sent: Tuesday, May 23, 2006 11:25 AM To: LLVM Developers Mailing List Subject: RE: [LLVMdev] Binary output to cout on

Hi, I think I have discovered a bug in FreeBSD 4.8-STABLE's system C++ compiler: % gcc -v % Using builtin specs. % gcc version 2.95.4 20020320 [FreeBSD] Here is a stripped down example that can be used to reproduce the bug: // ----------- begin bug.cpp ----------- #include <iostream> class Class { public: void M1 (void) { cout << "M1" << endl; }; void M2

Hi, Sorry, I just tried posting this but I had it in the wrong format of text, so this is a cleared format repost: I?m trying to call some of my c++ code from R and seem to be having an issue with streams, although that?s just one obvious sign of something different in performance between calling the same function from main in c++ vs. calling the same function from R. I?m not getting any signs

To get Tutorial 1 to compile, I had to cast cout as a raw_osstream, as in: PM.add(createPrintModulePass(&llvm::cout)); ----> PM.add(createPrintModulePass((raw_ostream*)&llvm::cout)); I was getting the following error: $ c++ -g tut1.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut1 tut1.cpp: In function ‘int main(int, char**)’: tut1.cpp:19: error: cannot convert

Hello all, I recently foudn myself wanting to view the basic blocks in the selection DAG as pure DAGs - so just as a list of edges, with no other information. I added the below code to the start of the " void SelectionDAGISel::CodeGenAndEmitDAG()" function. It creates a separate txt file for each basic block and gives a list of edges between nodes. The segment of code is below -

Hi all, after seeing a near inifinite stream of "Checking instruction ''" from bugpoint, I thought to improve that a bit. Turns out that bugpoint outputs the name, which is often empty (especially for the big bitcodes you want to pull through bugpoint :-). Below patch changes the behaviour to output the assembly version of the instruction instead of the name, which makes things

Hello, On windows, the standard output is not set to binary mode by default so all '\n' characters are replaced with '\r\n'. This is a pain for any command using stdout, like "llvm-as < input.ll > out.bc", because out.bc is then most likely corrupted. This is an old story, fixed a while ago: http://llvm.org/bugs/show_bug.cgi?id=787 And here is the thread on

Folks, I'm fairly sure that I'm doing something stupid, but I'm getting a few really strange results from *some* of the distributions, but by no means all, when I link directly to the R shared library. I've tried this on both Windows with the precompiled Mingw binary of R-2.5.0 (compiling my code with MinGW-3.4.2), and by building R-2.5.0 on Mandriva Linux with gcc-3.4.4 and

Hi folks, My system is Windows98 + R1.9.0. The path for my system is c:\perl\bin; c:\mingw\bin; c:\rtools; c:\windows; c:\windows\command; c:\rw1090\bin. I created three files followed the examples in “Writing R extensions” in the directory c:\temp: // X.hh class X { public: X (); ~X (); }; class Y { public: Y (); ~Y (); }; // X.cc #include <iostream> #include "X.hh" static

Hello, I am a newbie to LLVM and right now I am on the hook to parse some IR code and do some instrumentations. However, my problem is that no matter how I tweak my parsing code, it simply cannot print out anything. So here is my C code: int your_fun(int arg2) { int x = arg2; return x+2; } And here is my parsing code: #include <llvm/IR/Module.h> #include

On Jul 25, 2008, at 7:33 AM, Matthijs Kooijman wrote: > Hi all, > > after seeing a near inifinite stream of "Checking instruction ''" from > bugpoint, I thought to improve that a bit. Turns out that bugpoint > outputs the > name, which is often empty (especially for the big bitcodes you want > to pull > through bugpoint :-). > > Below patch

hey guys, I just compiled an application similar to sampledec.c (for speex 1.1.10) and it was fine but when I executed it, the app exited without doing anything. I'm using MS VC 6.0 and this was all I got - First-chance exception in sampledec.exe : 0xC0000005: Access Violation. Has anyone encountered this / does anyone know how to deal with it? by the way, sampleenc executed perfectly... When

I get a crash when I try to link multiple modules registered in their individual contexts. Documentation for Linker::LinkModules doesn't mention anything about contexts, and the first link succeeds. But the second link crashes. Is this not the right way to merge such modules? If not, then what is the right way? In any case, documentation for Linker::LinkModules should say if contexts are

+llvmdev, -llvm-dev On Tue, Jun 26, 2012 at 2:28 PM, Kostya Serebryany <kcc at google.com> wrote: > Hi Reid, > > On Tue, Jun 26, 2012 at 4:30 AM, Reid Watson <reidw at google.com> wrote: > >> Hello, >> >> I'm starting work on a project to detect initialization order problems >> in C++ files using AddressSanitizer. >> The extension in

As of LLVM 3.2, is it possible to use iostream with the MCJIT or interpreter execution engines? I'm getting some errors... Each of these commands correctly prints "hello": echo -e '#include <stdio.h>\nint main(){ printf("hello"); }' | clang -cc1 -emit-llvm-bc -x c++ | lli -use-mcjit echo -e '#include <iostream>\nint main(){ std::cout <<

Hi, when building the second release candidate of llvm 2.2 I noticed that exception handling seems to be broken on Linux x86-64. The exception is thrown but never caught. This can be seen by this trivial example: #include <iostream> using namespace std; class A { }; int main() { cout << "A" << endl; try { cout << "B" << endl;

Hi Steve, thanks for the advice. I placed the appropriate functions outside the while statement but I still get this error at the while loop: First-chance exception at 0x004010fa in SPXDEC.exe: 0xC0000005: Access violation reading location 0x0000000c. Unhandled exception at 0x004010fa in SPXDEC.exe: 0xC0000005: Access violation reading location 0x0000000c. It looks like the same error. I've