[LeafStorm]

This reminds me of something my assembly instructor said in class once (paraphrased):

"Once, I was interested in finding out how a C compiler would handle the div instruction. So, I opened up my editor, and wrote this C program:

    void main () {
        printf("%f", 14.0 / 3.0);
    }

I compiled it, and took a look at the generated assembly. How many div instructions do you think it used?

[Various guesses, mostly "one."]

The correct answer is "zero." The compiler figured it out at compile time, and put a constant in instead. So, I decided to put it in a function:

    float divide (float a, float b) {
        return a / b;
    }
    
    void main () {
        printf("%f", divide(a, b));
    }

Guess what happened next.

[Various guesses.]

The f--king compiler optimized it out again!"

[SilasX]

It didn't throw an "undefined variable" error?

[mitchi]

I've done this many times. This is special case that happens if you test with values inside the code. The compiler that I use, Visual C++, is smart enough to know that the result can be known at compile time, so it does just that in (Release). What you need to do is to read the arguments from a file or standard input.

[JshWright]

I don't spend a lot of time looking at complier outputs, but the optimization is quite obvious in the first case. I don't have a clue how it would optimize it out in the second case though...

[praptak]

I believe the second case is quite obvious too, with function inlining (assuming that GP post just forgot to define a and b as constants.)

[Symmetry]

In the second case the divide function isn't being exported from the compilation unit and the compiler can tell[1], so the compiler is free to do whatever it wants with the calling convention and in this case it will choose to inline. And once it's inlined finding the correct answer at compile time is still obvious.

[1] Normally you have to declare a function as 'static' to tell the compiler that the function isn't being exported form the compilation unit, since the compiler isn't supposed to be able to tell the difference between function declarations in the .c file itself and function declarations that were included from .h files. But in this case the function is just defined and never declared, so I presume that's the same as a static declaration.

[Someone]

As mpyne explains, the function still is externally visible.

However, the compiler is perfectly free to both compile it as an external function and inline it wherever it wants. Yes, setting breakpoints on such a function would be 'funny', but that's nothing of real concern to the compiler.

[mpyne]

No, it's still an extern declaration. However the compiler is still allowed to "peek within" an extern function as long as it has the definition available.

You can see this by inspecting the disassembly yourself, you'll see that printf never actually calls divide, and yet the divide function is still defined within the executable output.

[nemetroid]

I think LeafStorm meant to put some constants in the divide call.

[LeafStorm]

Yeah, I did. Sorry about that.

[groovy2shoes]

Lasher is a badass.