search for: get_ptr

Dear all, I compiled c program with llvm and found something strange with function pointer as following small example . ------------- In C Code -------------- float a (int value) { return value + 1; }; typedef float (*funcptr_t) (int); funcptr_t get_ptr(funcptr_t p) { return p; } float result = get_ptr(a)(4); ------------- In LLVM Code -------------- %4 = call float (i32)* (float (i32)*)* @get_ptr(float (i32)* @a1) nounwind ; <float (i32)*> [#uses=1] ~~~~~~~~~~~~~~~~~~~~ VERY STRANGE RETURN TYPE !!! %5 = call float %4(i...

...gt; > I compiled c program with llvm and found something strange with > function pointer as following small example . > > ------------- In C Code -------------- > float a (int value) { > return value + 1; > }; > > typedef float (*funcptr_t) (int); > > funcptr_t get_ptr(funcptr_t p) { > return p; > } > > float result = get_ptr(a)(4); > > ------------- In LLVM Code -------------- > > %4 = call float (i32)* (float (i32)*)* @get_ptr(float (i32)* @a1) > nounwind ;<float (i32)*> [#uses=1] > ~~~~~~~~~~~~~~~~~~~~...

...ut the "float (i32)* (float (i32)*)*", why we use this kind of return type instead of just "float (i32)*". Thanks a lot. Hao On Mon, Apr 12, 2010 at 5:42 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Hao Shen, > >> %4 = call float (i32)* (float (i32)*)* @get_ptr(float (i32)* @a1) >> nounwind ;<float (i32)*>  [#uses=1] >>                ~~~~~~~~~~~~~~~~~~~~  VERY STRANGE RETURN TYPE !!! > > this is a comment, and only exists to help the human reader.  Comments > start with a semi-colon (;).  You can remove them if you like. > &...

I’m not entirely opposed to solution #3. As I said, my concern is that there are cases it would miss. For instance, if I had some code like this: char *get_ptr(char *base, intptr_t offset) { return base + offset; } char *convert_to_ptr(intptr_t ptr_val) { return get_ptr((char*)0, ptr_val); } There the idiom would only appear after inlining, so the front end couldn’t handle it. The current glibc code is implemented with a couple of layers of macros...

...ccording to the description of the 'call' instruction in LLVM Assembly Language Reference Manual (http://llvm.org/docs/LangRef.html#i_call) this is a signature of the pointer to function value being invoked (which includes the return type). In your case the full signature is printed because get_ptr returns a pointer to function (read item 5 in the Arguments section of the 'call' Instruction section). Victor On 12 April 2010 16:58, SHEN Hao <hao.shen at imag.fr> wrote: > I'm sorry that I should remove the comment. > > In fact my question is about the "float...

Hi Hao Shen, > %4 = call float (i32)* (float (i32)*)* @get_ptr(float (i32)* @a1) > nounwind ;<float (i32)*> [#uses=1] > ~~~~~~~~~~~~~~~~~~~~ VERY STRANGE RETURN TYPE !!! this is a comment, and only exists to help the human reader. Comments start with a semi-colon (;). You can remove them if you like. Ciao, Duncan.

Hi everyone, I've got a problem that I would like some input on. The problem basically boils down to a program that I am compiling, whose source I don't control, doing something like this: p = (char*)0 + n where 'n' is an intptr_t-sized value that the program knows is actually a valid address for a pointer. clang translates this as %p = getelementptr inbounds i8, i8*

...re = VBE2_MAGIC; /* Get VBE2 extended data */ rm.eax.w[0] = 0x4F00; /* Get SVGA general information */ @@ -330,7 +335,7 @@ int detect_vesa(struct s_hardware *hardware) __intcall(0x10, &rm, &rm); if (rm.eax.w[0] != 0x004F) { - return -1; + goto out; }; mode_ptr = GET_PTR(gi->video_mode_ptr); @@ -369,7 +374,12 @@ int detect_vesa(struct s_hardware *hardware) hardware->vesa.vmi_count++; } hardware->is_vesa_valid = true; - return 0; + + rv = 0; +out: + lfree(mi); + lfree(gi); + return rv; } /* Try to detect disks from port 0x80 t...

From: Matt Fleming <matt.fleming at linux.intel.com> This series fixes some bugs and switches the elflink branch to be entirely ELF modules. It applies on top of, http://syslinux.zytor.com/archives/2011-April/016369.html The deletions in the diff stat below are mainly from deleting com32/elflink/modules (finally!). Now there should be no duplicate code because we don't need COM32 and