This is the mail archive of the
mailing list for the GCC project.
Re: relying on static_assert to test constexpr changes
- From: Martin Sebor <msebor at gmail dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 28 Apr 2016 16:04:39 -0600
- Subject: Re: relying on static_assert to test constexpr changes
- Authentication-results: sourceware.org; auth=none
- References: <57228567 dot 6060807 at gmail dot com> <CA+=Sn1k7iayuLttd4S7e--4Jc-NHf7fAYRLkboO2-btqT6x58w at mail dot gmail dot com>
On 04/28/2016 03:54 PM, Andrew Pinski wrote:
On Thu, Apr 28, 2016 at 2:49 PM, Martin Sebor <email@example.com> wrote:
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.
$ 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);
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
z = 0 << yet the output is zero!
How about this doing something like this:
int main ()
int z1 = *(volatile int*)&z;
if (z1 != (123 + 456)) // passes too
Does the above pass now?
Yes, I think that should work. I'm hoping for a solution that
doesn't require linking and running the tests. The approach
you suggest and scanning the tree dump(s) for abort might be
the way to go.