0

When analyzing the binary code generated by g++ 5.2.0, I found that the compiler frequently allocates memory that seems not used by any program elements. Below is an example.

The source code is

void
cxx_pretty_printer::declarator (tree t)
{
  this->direct_declarator (t); // A virtual function call
}

and the generated binary

0x8427ce8   _ZN18cxx_pretty_printer10declaratorEP9tree_node:
0x8427ce8   push    %ebp
0x8427ce9   mov     %esp, %ebp
0x8427ceb   sub     $0x8, %esp
0x8427cee   mov     0x8(%ebp), %eax
0x8427cf1   mov     0x0(%eax), %eax
0x8427cf3   add     $0x4c, %eax
0x8427cf6   mov     0x0(%eax), %eax
0x8427cf8   sub     $0x8, %esp
0x8427cfb   pushl   0xc(%ebp)
0x8427cfe   pushl   0x8(%ebp)
0x8427d01   call    *0x0(%eax,0)
0x8427d03   add     $0x10, %esp
0x8427d06   nop 
0x8427d07   leave   
0x8427d08   ret

I don't quite understand why the code at 0x8427ceb and 0x8427cf8 should exist. The compiler decreases the stack register, which seems to me that it is allocating some space on the stack. However, this space is never used by anything.

Is there any particular reason that makes g++ do this? The options I used are

-O2 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
too honest for this site
  • 12,050
  • 4
  • 30
  • 52
uraj
  • 339
  • 1
  • 10
  • What optimization flags are you using? You might compile with `g++ -Wall -O3 -fverbose-asm -S` then look into the produced `.s` assembler file (and perhaps even `-fdump-tree-all` to understand, thru hundreds of dumped files, what is happening *inside* the compiler). – Basile Starynkevitch Nov 04 '15 at 20:45
  • 2
    `Is there any particular reason that makes g++ do this?`: In God We trust. A compiler makes certain "optimization" that you can/must not be aware of. – 101010 Nov 04 '15 at 20:45
  • 3
    What optimizations did you enable? Also, some of this may be due to stack alignment requirements for function calls. – EOF Nov 04 '15 at 20:46
  • And you added the C tag because it starts with the same letter, I presume? – too honest for this site Nov 04 '15 at 20:53
  • @BasileStarynkevitch I've updated the questions with the options I used. – uraj Nov 04 '15 at 20:53
  • @EOF I've updated the questions with the options I used. – uraj Nov 04 '15 at 20:54
  • @Olaf I don't think this is C++ specific, although I didn't try similar things for C. – uraj Nov 04 '15 at 20:55
  • @uraj: This is very specific! C++ is not "C with classes". – too honest for this site Nov 04 '15 at 20:56
  • @Olaf Then you must know the reason for this right? Otherwise how do you know this is C++ specific? – uraj Nov 04 '15 at 20:57
  • @uraj: Last comment: This might be a very specific pattern the compiler generates. It might very well be different even for small changes to your code. Read about compiler construction and code generation, optimisation, how OOP functionality are transformed to machine language, etc. Foir more details learn/practice some decades CS&related, including compiler construction. – too honest for this site Nov 04 '15 at 21:01
  • @Olaf If you have no clear strong evidence showing this is C++ specific, then there IS A POSSIBILITY that this question is related to C as well. Besides, I'm a CS PhD student and I know well about the stuff you mentioned. – uraj Nov 04 '15 at 21:04
  • @uraj: Yes, some of my students also tell me they know better. Until they fail their test. Don't start an argumentum ad verecundiam with me. That just shows lack of actual knowledge/experience. act is you shall not add C tag for C++ questions. You could add Oberon, Java or Rust tags with much higher rectification here. I'd complain less if that was just a function. – too honest for this site Nov 04 '15 at 21:09
  • @Olaf See my own answer, dear professor. – uraj Nov 04 '15 at 21:20
  • 2
    @uraj You don't tag a question `C` just because the same issue might be present in C even though that's not where you encountered it. Should I tag a grammar question about uncountable nouns in English with `Swedish` because the same issue might exist in Swedish? – David Schwartz Nov 04 '15 at 21:23
  • @DavidSchwartz I added the `c` tag because my knowledge tells me this is likely related to C as well. Adding the tag can draw attention from people good at C and increase the chance for this question to be answered. In your example, if adding `Swedish` helps the question get answered, why not? – uraj Nov 04 '15 at 21:34
  • let's tag this question Perl too in case the same issue shows up there – M.M Nov 04 '15 at 21:44
  • @uraj Because using a tag that may or may not relate to the question just to get the attention of people looking for that tag is abusive. Tags are a give and take -- by placing a particular tag on a question, you are promising people that the question will be about that subject and therefore their interest in the question is justified. But you didn't carry your end of the bargain by making sure it was actually relevant. – David Schwartz Nov 04 '15 at 21:44
  • A [MCVE](http://stackoverflow.com/help/mcve) would improve this question – M.M Nov 04 '15 at 21:46
  • Honestly, I am most appalled by the `add $0x10, %esp` *right before* `leave`. – EOF Nov 04 '15 at 21:52
  • @DavidSchwartz That's a valid point and I buy that. – uraj Nov 04 '15 at 21:52
  • @EOF My guess is these two lines are generated at different phases of optimization so g++ fails to consider them together. – uraj Nov 04 '15 at 22:01

1 Answers1

-1

As EOF mentioned in the comment, this is due to stack alignment and is subject to change by setting the option -mpreferred-stack-boundary. The credit goes to this answer https://stackoverflow.com/a/1061942/696110

The option mentioned affects C compilation as well.

Community
  • 1
  • 1
uraj
  • 339
  • 1
  • 10