gcc and pow in a C program

[gamblor01]

I found some interesting behavior when discussing the pow function from Math.h with someone. I am well aware of the need to compile with the -lm flag, but to my surprise this actually isn't necessary if the arguments to the pow function are literals. For example, this program compiles in gcc without using -lm:

#include <stdio.h>
#include <math.h>

int main()
{
  double b = 2.0;
  double e = 3.0;
  double bCubed = pow(2.0, 3.0);

  printf("%f cubed is %f\n", b, bCubed);
  return 0;
}

If I try to change the call to any of these:

  double bCubed = pow(2.0, e);

  double bCubed = pow(b, 3.0);

  double bCubed = pow(b, e);

Then the -lm option is required or else it can't compile.

So does anyone know why it's necessary to use -lm when the argument(s) is/are variable(s) but it works fine if both arguments are literal values?

As a side note, any of the above compile with g++ however. Also, if it helps, this is the version of gcc I'm using:

gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)

This doesn't happen on my Mac however that is running: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5484)

[bwkaz]

This is a wild guess, but I would not be surprised if gcc was inlining the call to pow() when you gave it two literal values. (Alternately, if gcc wasn't inlining anything, but was just omitting the call to pow() and setting eCubed to 8.0 directly: doing the computation at compile time.) If there's no function call, then there's no need for the library.

If you know assembly, you can probably disassemble the output file and see whether there's a function call happening at that point in the code...

[gamblor01]

I knew I could count on you bwkaz! You're right -- this particular version of GCC was being sneaky (also known as "optimizing" the code)!!

I simply put the code with literals inside of foo.c and the code with variables inside of foo2.c and then used gcc -S on both of them. Notice that there is no call to the pow function inside of foo.s while there is inside of foo2.s:

% grep 'call' foo*.s
foo2.s:	call	pow
foo2.s:	call	printf
foo.s:	call	printf

Thanks for the tip!

[bwkaz]

Heh -- I was looking at a completely unrelated thing the other day (MPFR), and found a list of software using it: one of the programs listed was GCC. They linked to the GCC bug that tracked this optimization, and also the changelog entry talking about it:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
http://gcc.gnu.org/gcc-4.3/changes.html#mpfropts

The second link in particular should be relevant. Of course, you already figured this out, so whatever.