From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Richard Guenther <rguenther@suse.de>
Cc: gcc@gcc.gnu.org
Subject: Re: Prague GCC folks meeting summary report
Date: Thu, 24 Sep 2009 16:00:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.0909241554040.20240@digraph.polyomino.org.uk> (raw)
In-Reply-To: <alpine.LNX.2.00.0909241234100.4520@zhemvz.fhfr.qr>
On Thu, 24 Sep 2009, Richard Guenther wrote:
> The regular problem of emitting warnings for unreachable code may
> be addressed by using a new variant of debug statements. Those
> would queue up warnings and if still around emit them during
> expansion. Currently queueing a warning can be done with inserting
> a __builtin_warning function call.
If queueing a warning you need to be careful about i18n - probably queue
the exact text that would be emitted (as affected by options such as
-fdiagnostics-show-*) and then make sure it does not get passed through
translation again.
Other cases for queueing warnings are where the issue is not unreachable
code but some other property that may be proved during optimization, such
as whether an expression implicitly converted from signed to unsigned can
ever actually be negative. There are several places where the C front end
lowers expressions (calls c_fully_fold) prematurely to avoid bogus
warnings in such cases, and if all folding (and probably then the other
lowering c_fully_fold does) is to be moved to gimplification time or later
then a solution to these warnings is needed.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2009-09-24 16:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-24 10:35 Richard Guenther
2009-09-24 15:26 ` Jeff Law
2009-09-24 16:00 ` Joseph S. Myers [this message]
2009-09-24 16:34 ` Joseph S. Myers
2009-09-24 21:26 ` Richard Guenther
2009-09-25 19:14 ` Kevin P. Fleming
2009-10-02 0:00 ` Andi Kleen
2009-10-02 0:21 ` Joe Buck
2009-10-02 9:45 ` Richard Guenther
2009-10-02 13:30 ` Andi Kleen
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=Pine.LNX.4.64.0909241554040.20240@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=rguenther@suse.de \
/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).