top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration
Print Preview

Function Parameters vs. Prologue (fastcall + O1 + -fschedule-insns2)

0 votes

I'm curious about what is causing this reordering (prologue with the function parameters):

# gcc structs.c -o structs -m32 -O1 -fschedule-insns2

(gdb) disas main
Dump of assembler code for function main:
 0x0804868c : push %ebp
 0x0804868d : mov $0x3,%edx
 0x08048692 : mov %esp,%ebp
 0x08048694 : mov $0x2,%ecx
 0x08048699 : and $0xfffffff0,%esp
 0x0804869c : call 0x804845c 

The code:

__attribute__((fastcall)) void funcao(int i, int a) {
int main() {

 int i, a;
 i = 2;
 i = 3;

 funcao(i, a);

When I remove one of them (fastcall or schedule-insns2), the binary is generated in logic order:

(gdb) disas main
Dump of assembler code for function main:
 0x08048340 : push %ebp
 0x08048341 : mov %esp,%ebp
 0x08048343 : and $0xfffffff0,%esp
 0x08048346 : sub $0x10,%esp
 0x08048349 : movl $0x3,0x4(%esp)
 0x08048351 : movl $0x2,(%esp)
 0x08048358 : call 0x8048450 

... or

(gdb) disas main
Dump of assembler code for function main:
 0x0804868c : push %ebp
 0x0804868d : mov %esp,%ebp
 0x0804868f : and $0xfffffff0,%esp
 0x08048692 : mov $0x3,%edx
 0x08048697 : mov $0x2,%ecx
 0x0804869c : call 0x804845c 

Someone knows something about the combined use of the fastcall attribute and schedule-insns2 option? Is there an issue?

posted Jun 18, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

1 Answer

0 votes

I know that -fschedule-insns2 reorder the instructions to avoid bubble, but I did a benchmark that resulted in a more fast code without this reordering.

answer Jun 19, 2013 by anonymous
File a missed-optimization bug report?
I'm not really sure what you are asking.
Similar Questions
0 votes

If I compile my embedded program with options "-g -O1" I obtain an elf file with debug information. I can objcopy the elf file to a binary or hex file that can be loaded to flash, effectively striping out the debug
information leaving only the optimized code in ROM.

But if I re-build with options the same except omit the -g option, obviously I will have no symbols in the elf file making debugging impossible or at least more difficult. However, when I object copy this elf to a binary or hex file they are different somewhat than the binary or hex produced with options -g present. At least with 4.7.3 the main difference, as seen with objdump, is in the prologue to certain function calls with only a few bytes different in total code length on a fairly large embedded application (arm). So -g has some effect on the actual code produced it appears.

Is this difference expected? Should -g cause changes in the actual code generated and not just add debug symbols to the elf? Possibly it is related to the optimization level? I have not checked to see if the
results differ with higher or lower levels than -O1.

I have seen several opinions regarding this but no authoritative answer. The gcc manual also does not really answer this.

+1 vote

in the following code func.c :

 int Myfunc1(int i, int z)
 return i;

 int main()
 int ans;

 /* casting the function into an 'int (int)' function */
 ans = ((int(*)(int))(Myfunc1))(5);

 printf("ans: %dnn", ans);

 return 0;

I tried to cast an int(int,int) function into an int(int) function an got the gcc warning and note:

 func.c:13:32: warning: function called through a non-compatible type [enabled by default]
 func.c:13:32: note: if this code is reached, the program will abort

and when trying to run I get:

 Illegal instruction (core dumped)

But if i compile this file with a .cpp ending with the gcc compiler it works OK.

+5 votes

Even I have similar problem:

int (*pfun)(void);
int *pInt = 0;
void fun1()
    int i = 5; /* Local to fun1*/

    printf("Outer function");
    pInt = &i; /* As I know address of local variable is valid till function execution */

    int fun2()
      printf("%d", *pInt);
    /* fun2 address assign to pfun so that It can be called even after completion of fun1 */
    pfun = fun2;

int main()
    return 0;

Can someone please explain ? I am getting *pInt value 5.

+1 vote

Here's a small piece of code:

 static struct {
 const char fmt[10];
 } const x = { "%dn" };
 static const char * const fmt = "%dn";
 printf(fmt, 1);
 printf(x.fmt, 1);

The second printf produces a warning:

 test.c:105:10: warning: format string is not a string literal
 printf(x.fmt, 1);

From my point of view both format strings are identical. Why can't gcc deduce the format string in the second case?

Useful Links with Similar Problem
Contact Us
+91 9880187415
#470/147, 3rd Floor, 5th Main,
HSR Layout Sector 7,
Bangalore - 560102,
Karnataka INDIA.