Counter intuitively, asserts hurt gcc static dataflow analysis.

[Jonathan Wakely]

On 9 May 2018 at 09:59, Marc Glisse wrote:
> On Wed, 9 May 2018, Jonathan Wakely wrote:
>
>> 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)
>
>
> This part doesn't work so well, especially with optimizations that duplicate
> code (clone function, thread path, etc). You would need enough optimization
> to see that the arguments are constant, but little enough that it still
> looks like the user's code, and that's a hard compromize between
> __builtin_constant_p and the new __builtin_early_constant_p.

Yes, but luckily giving a warning here would just be QoI. The other
two bullets are the hard requirements for libstdc++'s purposes
(mandatory checking in constexpr that gives an error for failures, and
optional run-time assertions). Warning about cases where the assertion
would fail is nice to have, but not essential.


>
>> - otherwise, check at run-time.
>
>
> --
> Marc Glisse