This is the mail archive of the gcc-help@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]

Re: Counter intuitively, asserts hurt gcc static dataflow analysis.


> With an assert() modified to give compile-time warnings when possible,
you will generally have run-time costs.

Hmm. Not true,  the __builtin_choose_expr( __builtin_constant_p(exp))
completely vanishes at run time in optimized code.

The only downsides are....
 * it does something slightly different to the posix standard. Hence
probably should have a slightly different name.
* it's a gcc extension (but seems to work well with clang)
* it doesn't work with C++



On Fri, May 11, 2018 at 6:21 PM, David Brown <david@westcontrol.com> wrote:

>
>
> On 10/05/18 00:30, John Carter wrote:
>
> It catches things that can be inlined but seen as constant at comile time.
>>
>> I think as gcc's optimizer get's smarter this will be quite a win.
>>
>> It also basically subsumes static_assert()
>>
>
> This does not replace static_assert.  The key point about static_assert is
> that it is /always/ static - zero cost at run-time or code size.  You know
> that is the case when you write it, and other people reading the code know
> that.  So static_asserts are always free, and can be used liberally.  With
> an assert() modified to give compile-time warnings when possible, you will
> generally have run-time costs.
>
>
>
>


-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

-- 
This Communication is Confidential. We only send and receive email on the

basis of the terms set out at www.taitradio.com/email_disclaimer 
<http://www.taitradio.com/email_disclaimer>


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