public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: gdr@codesourcery.com
Cc: gcc@gcc.gnu.org
Subject: Silently checking whether diagnostics would occur
Date: Wed, 13 Sep 2000 08:50:00 -0000	[thread overview]
Message-ID: <200009131550.LAA13911@caip.rutgers.edu> (raw)

Hi Gabriel,

While writing a __builtin_printf expander, I found that it would be
useful to be able to call the printf format checking routines silently
from builtins.c to see if the printf call being expanded passed format
checks before I try to optimize it.  (This needs to happen regardless
of, and independent of, whether the user specifies -Wformat.)  The
current format checking routines are setup to emit warnings at random
points, not to return a handy status code.  (See check_format_info in
c-common.c.)

So rather than do a complete restructuring of the format checking
function, I though it would be much easier and cleaner to be able to
call the checks conceptually like this:

 > check_diagnostics_silently = 1;  /* new global vars */
 > diagnostic_occurred = 0;
 > 
 > <do something which might warn>
 > 
 > if (diagnostic_occurred) <react>
 > check_diagnostics_silently = 0;

and modify diagnostic.c:count_error to do this before anything else:

 >   if (check_diagnostics_silently)
 >     {
 >       diagnostic_occurred = 1;
 >       return 0;
 >     }

This would fool gcc into keeping quiet about the warnings while still
letting me know whether some kind of diagnostic would have issued.
Note the current controls like inhibit_warnings don't seem to do what
quite I want.  It would silence the warnings without me being able to
tell that a warning would have occured.  I also don't want to worry
about side effects modifying gcc's internal state, e.g. errorcount, or
whether the user specified -Werror.  My approach seems to solve all of
these issues.

First of all, I wanted to know if there was already something in there
that I missed which allows me to do this.  Second, if nothing exists
is this approach something you feel would be acceptable into
diagnostic.c?  I'll provide a patch if you react positively.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

             reply	other threads:[~2000-09-13  8:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-13  8:50 Kaveh R. Ghazi [this message]
2000-09-13 13:51 ` Michael Meissner
2000-09-13 16:37 ` Joern Rennecke
2000-09-13 14:33 Kaveh R. Ghazi
2000-09-13 20:37 ` Michael Meissner
2000-09-13 17:38 Mike Stump
2000-09-14  7:43 Kaveh R. Ghazi
2000-09-14  8:31 Kaveh R. Ghazi
2000-09-14  8:42 ` Michael Meissner
2000-09-14 10:47 ` Joseph S. Myers
2000-09-14 12:37 ` Joern Rennecke
2000-09-15 11:12 Kaveh R. Ghazi
2000-09-15 11:25 Kaveh R. Ghazi

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=200009131550.LAA13911@caip.rutgers.edu \
    --to=ghazi@caip.rutgers.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=gdr@codesourcery.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).