similar to: [LLVMdev] possible regression regarding bitcasts?

This isn't due to the bitcasts, it's crashing trying to verify the use of the memcpy intrinsic. Please file a bug report so we can track this, and please include your excellent testcase! Nick On 8 June 2010 10:10, Bagel <bagel99 at gmail.com> wrote: > The following code works on 2.7, but causes an assertion on recent > snapshots. > Has something changed regarding bitcasts

I have a 'CONGESTION' Status with R2 protocol. While testing this scenario sip GW--?Asterisk ?Digium E1 R2 Protocol?Cisco E1 R2 protocol?sip Gw Find below my error and configuration ,where are the errors in my configuration ? ========================================================================= Connected to Asterisk SVN-branch-1.6.2-r235775 currently running on

Hi, I don't think we should make bit casts between pointers with different address spaces illegal. Address spaces are not required to be disjoint. In the N1169 spec, it says A non-null pointer into an address space A can be cast to a pointer into another address space B, but such a cast is undefined if the source pointer does not point to a location in B. If the address spaces

Hi, i have the following code: define internal %"struct.dexter::ConditionConstant"* @_ZN6dexter18BinaryConditionAdd8evaluateEv5(%"class.dexter::BinaryConditionAdd"*) { entry: %1 = getelementptr inbounds %"class.dexter::BinaryConditionAdd"* %0, i32 0, i32 0, i32 1 %2 = load %"class.dexter::BaseCondition"** %1, align 8 %3 = bitcast

Should LLVM make bitcasts between pointers with different address spaces illegal? This will require a small clarification in the documentation and an assertion check added to the verifier, but I think this would be a good approach. The reason being is that in different address spaces, pointers are not always the same size. This could be limited to make it legal only if the size of the pointer

On Sep 7, 2012, at 11:10 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Mon Ping Wang wrote: >> Hi, >> >> I don't think we should make bit casts between pointers with different >> address spaces illegal. Address spaces are not required to be disjoint. >> In the N1169 spec, it says >> A non-null pointer into an address space A can be cast to a

Dear all, I just stumbled over the following instruction in the LLVM IR of a C program compiled with clang: %26 = call i32 (...)* bitcast (i32 (i32, i32, i32, i32, i32)* @KeWaitForSingleObject to i32 (...)*)(i32 %23, i32 %24, i32 %25, i32 0, i32 0) Since our LLVM Parser choked on this instruction, I tried to check the documentation, but did not find anything about such nested bitcasts within

On Sep 8, 2012, at 12:21 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Mon Ping Wang wrote: >> >> On Sep 7, 2012, at 11:10 PM, Nick Lewycky<nicholas at mxc.ca> wrote: >> >>> Mon Ping Wang wrote: >>>> Hi, >>>> >>>> I don't think we should make bit casts between pointers with different >>>> address

Mon Ping Wang wrote: > Hi, > > I don't think we should make bit casts between pointers with different > address spaces illegal. Address spaces are not required to be disjoint. > In the N1169 spec, it says > A non-null pointer into an address space A can be cast to a pointer into > another address space B, but such a cast is undefined if the source > pointer does not

Mon Ping Wang wrote: > > On Sep 7, 2012, at 11:10 PM, Nick Lewycky<nicholas at mxc.ca> wrote: > >> Mon Ping Wang wrote: >>> Hi, >>> >>> I don't think we should make bit casts between pointers with different >>> address spaces illegal. Address spaces are not required to be disjoint. >>> In the N1169 spec, it says >>> A

This code lives in DAGCombiner.cpp: ------------- // Turn 'store float 1.0, Ptr' -> 'store int 0x12345678, Ptr' if (ConstantFPSDNode *CFP = dyn_cast<ConstantFPSDNode>(Value)) { // NOTE: If the original store is volatile, this transform must not increase // the number of stores. For example, on x86-32 an f64 can be stored in one // processor operation but

I have been trying to compile some Llvm code that I generate, and I am running into a problem assembling my ll code. Here is a snippet of the code I am trying to compile: %loc0 = alloca i32 call void @llvm.dbg.declare( { }* bitcast(i32* %loc0 to { }*), { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) ) I get an error from the second line of code: Invalid

> call void @llvm.dbg.declare( { }* bitcast(i32* %loc0 to { }*), { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) ) This is not legal. The distinction here is that the bitcast as an argument is a constant expression and requires constant arguments, and %loc0 is not constant. Introducing the temp variable is the "right way" to do this. - Daniel -----

We are seeing some behavior we don't understand. Some of our functions are not showing up in the Call Graph because their calls contain bitcasts. The Call Graph then considers them to be external nodes. The calls look as follows: %tmp35 = call i32 (...)* bitcast (i32 (i32, i8*, i32*)* @convert to i32 (...)*)( i32 %tmp33, i8* %tmp34, i8* %tmp30 ) ; <i32> [#uses=1] After looking

Hello, Ben > This may be more related to gcc, but we're wondering why the initial > call to a function without a prototype contained a bitcast while a > function with a prototype does not. We can go into the code and add > prototypes and get around the problem, but we'd like to better > understand what's going on to see if a better solution exists. This is correct

Hello, > The function is declared in a header file. How? As 'void openBMPJPG()' ? > After linkingall the files together, the callee function is called in > the way bellow: 'void openBMPJPG()' will give you varargs function declaration. So, actually you're calling no-args function via vargargs declaration. Thus bitcast there. -- With best regards, Anton

ok.. you are right. I had not inserted the AllocaInst in the function. Thanks a lot for solving my problem yet again :) --- On Mon, 11/17/08, Eli Friedman <eli.friedman at gmail.com> wrote: > From: Eli Friedman <eli.friedman at gmail.com> > Subject: Re: Assertion `castIsValid(getOpcode(), S, Ty) && "Illegal BitCast"' faile > To: bhavi63 at yahoo.com

Here's a piece of code that behaves in a way that appears insane to me; I'm hoping that someone can either explain to me why this is the right behavior, or label it a bug. target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "i386-apple-darwin8" define i32

Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and DisableSymbolSearching to cause malloc and free calls to be handled by my logging functions. Sorry for the unnecessary list mail. Is it possible to find out the size and beginning pointer of the current stack frame, from a function operating outside of the virtual machine, but called by a function within it? Thanks, Daniel

Daniel Waterworth skrev: > Thanks very much. I only have one more question, (hopefully), which > is, is there a better way of finding the direction of stack growth > other than: > > static bool StackCmp(void *ptr) { > volatile int a; > return (void *)&a > ptr; > } > > bool FindStackDirection() { > volatile int a; > return StackCmp((void