This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

relying on static_assert to test constexpr changes


Many GCC tests for constexpr rely on static_assert to verify things
work correctly.  While testing some changes of my own, I was surprised
to find the static_asserts pass even though my changes did not (see
below).  It took me a while to realize that, and it took printing
the computed constant values via printf() to see they were wrong.
Even a runtime assert() didn't uncover the bug (see below).  After
thinking about it a bit, it makes sense that using the tool under
test to verify its own correctness isn't the most reliable way to
do it.  I've seen it before when testing other software, but it was
eye opening none-the-less to see it happen with a compiler.  Enough
that I think it's worthwhile to share it here.

Martin

$ cat builtin_constexpr.cpp && /home/msebor/build/gcc-70507/gcc/xgcc -B/home/msebor/build/gcc-70507/gcc -Wall -Wextra -Wpedantic builtin_constexpr.cpp && ./a.out
constexpr int f (int x, int y)
{
    int z = 0;
    __builtin_add_overflow (x, y, &z);
    return z;
}

constexpr int z = f (12, 34);

int main ()
{
  static_assert (z == (123 + 456), "z == (123 + 456)");   // passes

  __builtin_printf ("z = %i\n", z);

  if (z != (123 + 456))   // passes too
    __builtin_abort ();
}

z = 0   << yet the output is zero!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]