similar to: [LLVMdev] dead basic blocks

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

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"

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]

Hello David, I am having an issue with some custom intrinsics that return a token value: InstCombine deletes the users of the token but not the instruction that creates the token itself. The IR is still valid but it's wasted. The source of the issue is coming from an old patch of yours: commit 7204cff0a121ebc770cf81f7f94679ae7324daae Author: David Majnemer <david.majnemer at

I did not observe any assertion. In addition, the documentation ( https://llvm.org/docs/LangRef.html#undefined-values) says: The string ‘undef’ can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. Undefined values may be of any type (other than ‘label’ or ‘ void’) and be used anywhere a constant is permitted. Either way,

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

This has been reported. http://llvm.org/bugs/show_bug.cgi?id=1317 On 4/10/07, Ryan M. Lefever <lefever at crhc.uiuc.edu> wrote: > > I checked out llvm from cvs & llvm-gcc from svn last night and again > tonight. Each time they compiled and installed fine. After installing > them, I recompiled compiler transforms I had written for opt. opt seems > to load the my

Yes, it's still respected in this case, as the only instructions that will be deleted have been RAUW with undef. Originally, all instructions where RAUW but only non-EHPad were deleted (that means EHPad were RAUW but not deleted). Then it was later patched by not RAUW token instructions and now not deleting EHPad nor token instructions. My assumption is that the instructions we wanted to

On my 32 bit linux box, things seam to work find, but on my 64 bit linux box I am getting problems. I have the following c file (lib.c): -------------------------------- #include <stdio.h> void libmethod(){ printf("libmethod()\n"); } ------------------------------- I tried to get a shared library using the following commands: llvm-gcc -emit-llvm -Wall -fPIC -c -o lib.opt.bc

Yup! -bw On Nov 3, 2008, at 7:39 PM, Ryan M. Lefever wrote: > 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] > _______________________________________________ > LLVM Developers mailing list >

As a follow up, if I first convert x.bc to a c file using llc -march=c -o x.c x.bc, and then I use normal gcc to convert x.c to an executable, f() remains a global symbol. Is llvm-nm incorrectly converting the global symbols to local symbols? Ryan M. Lefever wrote: > I have a bitcode file x.bc. When I run llmv-nm on x.bc, it shows that a > function f(), that I've written, is

I checked out llvm from cvs & llvm-gcc from svn last night and again tonight. Each time they compiled and installed fine. After installing them, I recompiled compiler transforms I had written for opt. opt seems to load the my transform libraries fine, but it complains: opt: Unknown command line argument '-mytransform' whenever I try to specify one of my transforms on the opt

How is c's const keyword translated when compiling c into llvm bytecode. I'm specifically interested in const pointer function arguments. Consider a function declared as follows in c: void f(const int* arg); When I examine f in llvm bytecode, how can I tell that arg is a pointer, whose contents can only be read, not written. Regards, Ryan

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

I have a bitcode file x.bc. When I run llmv-nm on x.bc, it shows that a function f(), that I've written, is defined as a global function (text) object, i.e., llvm-nm shows it marked with a 'T'. I have converted x.bc to an executable with the following command: llvm-ld -native -o x.exe x.bc When I run nm on x.exe, it shows that f is now a local function (text) object, i.e., nm

Chris, I'm a little confused. I am experiencing a crash when compiling the llvm-gcc frontend. According to the bugpoint documentation, bugpoint is used to debug "optimizer crashes, miscompilations by optimizers, or bad native code generation," which seems like it implies that the frontend compiles. Also, the http://llvm.org/docs/HowToSubmitABug.html documentation seems to

I have been working on a compilation process that involves steps such as passing an application through transforms that I've written and combining the application with support code that I've written. When I compile an application using my compilation process without debugging, (i.e., "llvm-gcc -g"), everything works fine. However, when I compile an application using my

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 assume that when -O3 (or O2 or O1) is passed to llvm-gcc, then it utilizes opt. How do I determine what passes opt runs? How do I determine what external tools (and arguments) llvm-gcc is invoking? Regards, Ryan