This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Counter intuitively, asserts hurt gcc static dataflow analysis.
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: John Carter <john dot carter at taitradio dot com>, gcc-help <gcc-help at gcc dot gnu dot org>
- Date: Wed, 9 May 2018 09:40:14 +0100
- Subject: Re: Counter intuitively, asserts hurt gcc static dataflow analysis.
- References: <CAFD1m3FNaL4_T=hwUSi6Li+8P3+WiV8jL=2H_QuziqsE2MX6Ug@mail.gmail.com> <874ljnv6xz.fsf@mid.deneb.enyo.de>
On 4 May 2018 at 15:20, Florian Weimer wrote:
> * John Carter:
>
>> But compile with ...
>> gcc -O3 -W -Wall -Wextra -o a a.c
>> ...now results in NO warnings!
>>
>> ie. Although gcc _knows_ the assert _will_ trigger at run time... it can't
>> tell me at compile time anymore.
>>
>> ie. Counter intuitively, adding asserts and error checks to my code has
>> made me less safe.
>
> In glibc, we could warn if the assert expression is constant and
> false. But I'm worried that this will produce lots and lots of false
> positives after inlining, loop unrolling, and other optimizations.
>
> Has anyone tried something like this?
I've been experimenting with something like that for assertions inside
libstdc++. I want assertions that meet these properties:
- enforced at compile time in constexpr evaluation (i.e. produce a
compile-time error, not a runtime call to abort)
- otherwise, issue a compile-time warning if the arguments are
constant (using __builtin_constant_p)
- otherwise, check at run-time.