similar to: [LLVMdev] c const

> How is c's const keyword translated when compiling c into > llvm bytecode. It isn't. You can verify this quite simply with the following test program: void a(const void *p) { } void b(void *p) { } $ clang --emit-llvm test.c ; ModuleID = 'foo' define void @a(i8* %p) { entry: %p.addr = alloca i8* ; <i8**> [#uses=1] %allocapt = bitcast

This property isn't preserved on the llvm ir, because const can always be cast away. If you want mod information, then I suggest using the aliasanalysis interface to get mod ref info for a call. -Chris http://nondot.org/sabre http://llvm.org On Aug 8, 2007, at 12:07 AM, "Ryan M. Lefever" <lefever at crhc.uiuc.edu> wrote: > How is c's const keyword translated

Hi, I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. int func() { const int *arr; arr[0] = 1; } $ llvm-gcc main.c -c; echo $? 0 $ gcc main.c -c main.c: In function 'func': main.c:4: error: assignment of read-only location The difference disappears when arr[0] is replaced by *arr. (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't

I don't mean to be a pain, but I was thinking about this a bit more. Does gcc ignore the const keyword? If not, why has LLVM chosen to deviate from gcc with respect to the const keyword? If so, then why do we bother using const in LLVM API code? I'm just curious and wanted to understand the thinking behind not preserving const. Thanks, Ryan Chris Lattner wrote: > This property

This certainly doesn't occur in gcc mainline. In fact, I improved the error message, and added a error test to gcc just yesterday. On 8/9/07, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 8 Aug 2007, Nikhil A. Patil wrote: > > I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. > > Looks like a bug, please file a bugzilla entry. >

I don't follow what you mean - gcc doesn't ignore const and llvm doesn't deviate from gcc nor from the relevant language standards. Note that if you declare a global as const that we do capture this in the ir - what specifically do you want? Please provide an example. -Chris http://nondot.org/sabre http://llvm.org On Aug 14, 2007, at 11:58 PM, "Ryan M. Lefever"

On Wed, 8 Aug 2007, Nikhil A. Patil wrote: > I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. Looks like a bug, please file a bugzilla entry. -Chris > int func() > { > const int *arr; > arr[0] = 1; > } > > $ llvm-gcc main.c -c; echo $? > 0 > > $ gcc main.c -c > main.c: In function 'func': > main.c:4: error:

On Thu, 9 Aug 2007, Daniel Berlin wrote: > This certainly doesn't occur in gcc mainline. > In fact, I improved the error message, and added a error test to gcc > just yesterday. Yep, clang reports: t.c:4:12: error: read-only variable is not assignable arr[0] = 1; ~~~~~~ ^ 1 diagnostic generated. so this is specific to llvm-gcc somehow. -Chris > On 8/9/07, Chris

Is it possible to use dynamic library (*.so *.dll) from bytecode? If "yes" - how? -- WBR, Yaroslav Kavenchuk.

On Jun 18, 2008, at 6:48 AM, Yaroslav Kavenchuk wrote: > Is it possible to use dynamic library (*.so *.dll) from bytecode? > If "yes" - how? dlopen? That's be one way. Also, most systems have shared libraries in /usr/lib and these routines are meant to be linked against and used. For example, on darwin, there sinf is resolved from a shared library, you declare it and

Thanks for your response. When I attempt to get the parameter attribute lists for the function and its call sites, the list is NULL. Is there someone else I should be looking to get the parameter attributes? Chris Lattner wrote: > On Wed, 30 Apr 2008, Ryan M. Lefever wrote: >> I have a c function that takes a char as a parameter. When it is >> compiled to bytecode, it gets

I have a c function that takes a char as a parameter. When it is compiled to bytecode, it gets translated to i8 signext. Why is signext getting added to the type? It doesn't get added if the parameter is an int. Is there a way to alter the parameter in the c code so that it simply gets translated to an i8, or is there a way in LLVM to modify the parameter's type? By the way, I am

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? Ryan M. Lefever wrote: > I also tried iterating

Consider the following c code: #include <stdlib.h> int main(int argc, char** argv){ if(malloc(sizeof(int)) == NULL){ return 0; } else{ return 1; } } When I compile it with -O3, it produces the following bytecode: define i32 @main(i32 %argc, i8** %argv) { entry: ret i32 1 } Is this an error? It should be possible for malloc to return NULL, if it can not allocate more

I am writing a transformation that needs to add a call to a function F() at the beginning of main() with the addresses of argc and argv as parameters to F(). However, the bytecode file I'm transforming has not allocated space on the stack for argc and argv. So, I developed my transformation to change main() from: ----- int main(int %argc, sbyte** %argv){ entry: ... // some use of

Does llvm-gcc support the -fPIC option? I am using LLVM on both 32 bit linux and 64 bit linux, if that matters. Regards, Ryan -- Ryan M. Lefever [http://www.crhc.uiuc.edu/~lefever/index.html]

Hi, I want to know the variable mapping between the source and llvm bytecode. It seems that current llvm debugging information cannot provide this mapping directly. Here is my examples (llvm 2.7). In this exmaple, I want to know the mapping: tmp<--->%4. But current llvm's debugging information can only provide that the instruction "%4 = add nsw i32 %3, 2" is at line 3 in

It appears that the only thing that has parameter attributes is the function type. However, you can't simply change a function's type without reconstructing the whole function, can you? Also, am I correct that it would not be safe to remove the parameter attribute's from a FunctionType? Ryan M. Lefever wrote: > Thanks for your response. When I attempt to get the parameter

To what do variable size LLVM alloca instructions get translated, when they are turned into machine code? I compiled a piece of code to bitcode and disassembled it. The disassembled code showed that there were alloca instructions with variable-sized parameters within the bitcode. When I turned the bitcode into machine code, I performed an nm on the result but didn't see any symbols

Hi, I'm sorry I forgot to mention I am compiling the bitcode using the JIT. The actual error, I get when I'm trying to get the function to the pointer. I'm using a custom front end that translates Android's Dalvik bytecode into LLVM bitcode based on Android ICS's modified LLVM version. Thanks, On Mon, Feb 20, 2012 at 7:55 PM, James Molloy <James.Molloy at arm.com>