similar to: [LLVMdev] Integer casting warning, and another set of warnings

I have a warning when building with MSVC2k5, a benign warning, but I am trying to get rid of them. ..\..\..\..\trunk\lib\Transforms\Utils\AddrModeMatcher.cpp(208) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The line of code is: Scale = 1 << Scale; Where Scale is an int64_t, however, 1 is an int32_t (since

In the llvm file include/llvm/Support/DataTypes.h (.in/.cmake), for MSVCit defines some macros that are defined in the cstdint.hpp file in boost (and boost does it better, detailed below): The basic error is: R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(347) : warning C4005: 'INT8_C' : macro redefinition

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

On Tue, May 12, 2009 at 11:55 PM, Chris Lattner <clattner at apple.com> wrote: > Dan, can you add IVUsers.cpp to the appropriate cmakefile? > > -chris > > > On May 12, 2009, at 10:54 PM, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 11:40 PM, Chris Lattner <clattner at apple.com> >> wrote: >>> >>> On May 12, 2009, at 10:24 PM,

In DataTypes.h starting on line 121 are these lines: #define INT8_C(C) C #define UINT8_C(C) C #define INT16_C(C) C #define UINT16_C(C) C #define INT32_C(C) C #define UINT32_C(C) C ## U #define INT64_C(C) ((int64_t) C ## LL) #define UINT64_C(C) ((uint64_t) C ## ULL) They are conflicting with the cstdint when we have updated headers in our MSVC build. I could have sworn I talked about this

Hi Ashok, I created a new Ubuntu 12.04 virtual machine and followed directions except that I know use your cmake command instead of configure, and I got the error below. Any help is very much appreciated. $ /home/ubuntu/bin/bin/clang++ -I /home/ubuntu/bin/include/ tutorial1.cpp In file included from tutorial1.cpp:5: In file included from /home/ubuntu/bin/include/llvm/Support/raw_ostream.h:17:

1 GB should be enough to create a btrfs filesystem, even with 64K page size; hence, make the /dev/sda and /dev/sdb test devices smaller so there is less space taken during the test run. Followup of commit 8ffad75e5b610274a664a00f1f1186070b602e18 and commit 9e9b648770f9b8dbe8f280e4b5d1f80c4d689130. --- docs/guestfs-hacking.pod | 4 ++-- generator/actions.ml | 10 +++++-----

(resending with smaller attachement) Segfault in EE->getPointerToFunction. I think it's blown the stack, gdb reports a never ending backtrace (below). I generate llvm assembly and parse/verify OK. Attached is the assembly. It is the smallest example generated that causes the segfault. If this EE uses a recursive function (??), it seems an inherent limitation in how big llvm functions

On 3/4/20 9:17 AM, Richard W.M. Jones wrote: > Plugins and filters may call this to initiate an asynchronous shutdown > of the server. This would only be used in the connected phase — > plugins should still call exit(3) directly for configuration failure. > > It is equivalent to sending a kill signal to self, but it's cleaner to > have an API for this and better for

Segfault in EE->getPointerToFunction. I think it's blown the stack, gdb reports a never ending backtrace (below). I generate llvm assembly and parse/verify OK. Attached is the assembly. It is the smallest example generated that causes the segfault. If this EE uses a recursive function (??), it seems an inherent limitation in how big llvm functions can be. Simon. gdb backtrace: #0

I get compile errors for just including the "clang/Basic/Diagnostic.h" header file. Is that expected? Should I include anything else? Here are the errors: $ g++ main.cpp -I llvm/tools/clang/include -I llvm/include In file included from llvm/include/llvm/Support/PointerLikeTypeTraits.h:18, from llvm/tools/clang/include/clang/Basic/SourceLocation.h:17,

OK.  Thanks.  I now get the following error (which appears to be a problem w/ the tutorial itself?): $ /home/ubuntu/bin/bin/clang++ -I /home/ubuntu/bin/include/  -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS tutorial1.cpp/tmp/tutorial1-LQ71fW.o: In function `main': tutorial1.cpp:(.text+0x42): undefined reference to `llvm::outs()' tutorial1.cpp:(.text+0x72): undefined reference to

Add -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS to your compilation flag. On 7/10/2012 11:23 AM, NY Knicks Fan wrote: > Hi Ashok, > > I created a new Ubuntu 12.04 virtual machine and followed directions > except that I know use your cmake command instead of configure, and I > got the error below. > > Any help is very much appreciated. > > > $

Previously these were rather small - just 500 MB. This is too small to create a btrfs device on aarch64 (where page size may be 64K), and barely enough even on x86-64. This change makes both these devices 10 GB, and adjusts a few tests so they continue to pass. --- docs/guestfs-hacking.pod | 4 ++-- generator/actions.ml | 17 +++++++++++------ tests/c-api/tests-main.c | 6 +++--- 3 files

Hi Simon, You're probably right. LLVM's instruction selector is recursive so it can run out of stack space. Select_store used to have enormous stack frame (thanks to some gcc issues), we had to do all kinds of tricks to get it under control. I just took a look at it, it's around 0.7k. It used to be around 20k on x86 Mac OS X. It's also possible that it has gotten into a

On Fri, Dec 5, 2008 at 1:58 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > 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

hey guys. Now I am following the "Writing an LLVM Pass", but can't work it out. See what I have done. After completing the exact Makefile and source code under lib/Transforms/Hello, I typed the command "make" instead of "gmake" , then it generated silently "Hello.o" in Debug. But, next, when I tried to generate "hello.bc" by the command

Hi Ashok, $ cd bin/bin $ ./llvm-config --ldflags --libs -L/home/ubuntu/bin/lib   -ldl -lpthread -lLLVMAsmParser -lLLVMTableGen -lLLVMDebugInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInstrumentation -lLLVMInterpreter

steve naroff <snaroff at apple.com> writes: > Folks, > > It appears the Windows build has regressed over the past week. > > The build fails quite early (during the "Performing TableGenStep" > phase). > > Any help/pointers would be appreciated. It breaks for me because the usage of INT64_C, which was introduced on r57663 and 57668. Some googling around

You will need to link to the LLVM/clang libraries. To get the correct flags, you can run: ./llvm-config --ldflags --libs and use the flags reported. On 7/10/2012 11:35 AM, NY Knicks Fan wrote: > OK. Thanks. I now get the following error (which appears to be a > problem w/ the tutorial itself?): > > $ /home/ubuntu/bin/bin/clang++ -I /home/ubuntu/bin/include/ >