public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jeff Law <law@redhat.com>
Cc: Mikhail Maltsev <maltsevm@gmail.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Add -fchecking
Date: Wed, 28 Oct 2015 10:13:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.11.1510281103590.28064@zhemvz.fhfr.qr> (raw)
In-Reply-To: <562FBA24.2080407@redhat.com>

On Tue, 27 Oct 2015, Jeff Law wrote:

> On 10/27/2015 09:32 AM, Mikhail Maltsev wrote:
> > On 10/27/2015 04:17 PM, Richard Biener wrote:
> > > 
> > > This adds -fchecking as a way to enable internal consistency checks
> > > even in release builds (or disable checking with -fno-checking - up to
> > > a certain extent - with checking enabled).
> > 
> > I remember that Jakub proposed to use __builtin_expect with
> > flag_checking. I wonder, if it is possible to implement without hacking
> > AWK scripts just for this particular case? For example, to define
> > flag_checking to something like
> > 
> > #define flag_checking __builtin_expect (flag_checking_val, CHECKING_P)
> > 
> > (provided that flag_checking_val is the actual value got from
> > command-line options).
> I think this ought to be a follow-up item.  And yes, we're going to need some
> level of indirection so that we're not writing __builtin_expect all over the
> place.

Yeah, we should do that as followup.  We should also make sure to
only make the branch unlikely and not end up with optimizing
all checking code for size (making it even slower than it is now).

Richard.

> Jeff
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

  reply	other threads:[~2015-10-28 10:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-27 13:35 Richard Biener
2015-10-27 15:33 ` Mikhail Maltsev
2015-10-27 18:06   ` Jeff Law
2015-10-28 10:13     ` Richard Biener [this message]
2015-11-07 20:47 ` Gerald Pfeifer
2015-11-08  0:41   ` Jeff Law
2015-11-08  9:12     ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.11.1510281103590.28064@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=maltsevm@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).