Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Inline version of a function returns different value than non-inline version

Tags:

c++

How can two versions of the same function, differing only in one being inline and the other one not, return different values? Here is some code I wrote today and I am not sure how it works.

#include <cmath>
#include <iostream>

bool is_cube(double r)
{
    return floor(cbrt(r)) == cbrt(r);
}

bool inline is_cube_inline(double r)
{
    return floor(cbrt(r)) == cbrt(r);
}

int main()
{
    std::cout << (floor(cbrt(27.0)) == cbrt(27.0)) << std::endl;
    std::cout << (is_cube(27.0)) << std::endl;
    std::cout << (is_cube_inline(27.0)) << std::endl;
}

I would expect all outputs to be equal to 1, but it actually outputs this (g++ 8.3.1, no flags):

1
0
1

instead of

1
1
1

Edit: clang++ 7.0.0 outputs this:

0
0
0

and g++ -Ofast this:

1
1
1
like image 473
zbrojny120 Avatar asked Apr 09 '19 10:04

zbrojny120


People also ask

How are inline functions different from normal functions?

If a function is inline, the compiler places a copy of the code of that function at each point where the function is called at compile time. Normal functions do not have any such functionality. In case of inline function, function calling is replaced by that function definition.

Can inline function return value?

Inline functions are more than a simple copy-paste procedure (in contrast to, say, preprocessor macros). They behave like normal functions, so any return value would be reflected to the caller just like a normal function.

What are inline functions How does the execution of inline functions differ from normal functions give the advantages of inline functions?

Inline functions provide following advantages: 1) Function call overhead doesn't occur. 2) It also saves the overhead of push/pop variables on the stack when function is called. 3) It also saves overhead of a return call from a function.


Video Answer


2 Answers

As observed, using the == operator to compare floating point values has resulted in different outputs with different compilers and at different optimization levels.

One good way to compare floating point values is the relative tolerance test outlined in the article: Floating-point tolerances revisited.

We first calculate the Epsilon (the relative tolerance) value which in this case would be:

double Epsilon = std::max(std::cbrt(r), std::floor(std::cbrt(r))) * std::numeric_limits<double>::epsilon();

And then use it in both the inline and non-inline functions in this manner:

return (std::fabs(std::floor(std::cbrt(r)) - std::cbrt(r)) < Epsilon);

The functions now are:

bool is_cube(double r)
{
    double Epsilon = std::max(std::cbrt(r), std::floor(std::cbrt(r))) * std::numeric_limits<double>::epsilon();    
    return (std::fabs(std::floor(std::cbrt(r)) - std::cbrt(r)) < Epsilon);
}

bool inline is_cube_inline(double r)
{
    double Epsilon = std::max(std::cbrt(r), std::floor(std::cbrt(r))) * std::numeric_limits<double>::epsilon();
    return (std::fabs(std::round(std::cbrt(r)) - std::cbrt(r)) < Epsilon);
}

Now the output will be as expected ([1 1 1]) with different compilers and at different optimization levels.

Live demo

like image 34
P.W Avatar answered Oct 17 '22 23:10

P.W


Explanation

Some compilers (notably GCC) use higher precision when evaluating expressions at compile time. If an expression depends only on constant inputs and literals, it may be evaluated at compile time even if the expression is not assigned to a constexpr variable. Whether or not this occurs depends on:

  • The complexity of the expression
  • The threshold the compiler uses as a cutoff when attempting to perform compile time evaluation
  • Other heuristics used in special cases (such as when clang elides loops)

If an expression is explicitly provided, as in the first case, it has lower complexity and the compiler is likely to evaluate it at compile time.

Similarly, if a function is marked inline, the compiler is more likely to evaluate it at compile time because inline functions raise the threshold at which evaluation can occur.

Higher optimization levels also increase this threshold, as in the -Ofast example, where all expressions evaluate to true on gcc due to higher precision compile-time evaluation.

We can observe this behavior here on compiler explorer. When compiled with -O1, only the function marked inline is evaluated at compile-time, but at -O3 both functions are evaluated at compile-time.

  • -O1: https://godbolt.org/z/u4gh0g
  • -O3: https://godbolt.org/z/nVK4So

NB: In the compiler-explorer examples, I use printf instead iostream because it reduces the complexity of the main function, making the effect more visible.

Demonstrating that inline doesn’t affect runtime evaluation

We can ensure that none of the expressions are evaluated at compile time by obtaining value from standard input, and when we do this, all 3 expressions return false as demonstrated here: https://ideone.com/QZbv6X

#include <cmath>
#include <iostream>

bool is_cube(double r)
{
    return floor(cbrt(r)) == cbrt(r);
}
 
bool inline is_cube_inline(double r)
{
    return floor(cbrt(r)) == cbrt(r);
}

int main()
{
    double value;
    std::cin >> value;
    std::cout << (floor(cbrt(value)) == cbrt(value)) << std::endl; // false
    std::cout << (is_cube(value)) << std::endl; // false
    std::cout << (is_cube_inline(value)) << std::endl; // false
}

Contrast with this example, where we use the same compiler settings but provide the value at compile-time, resulting in the higher-precision compile-time evaluation.

like image 169
Alecto Irene Perez Avatar answered Oct 17 '22 23:10

Alecto Irene Perez