From: Richard Biener <richard.guenther@gmail.com>
To: "James K. Lowden" <jklowden@schemamania.org>
Cc: gcc@gcc.gnu.org
Subject: Re: warnings and warnings
Date: Mon, 22 Apr 2024 20:59:37 +0200 [thread overview]
Message-ID: <CAFiYyc1g0TVJEWrnf1LUq1c92G1kCAQci-u2uXpjuxm54V3BNA@mail.gmail.com> (raw)
In-Reply-To: <20240420185250.05104659901ca18b0c6cb842@schemamania.org>
On Sun, Apr 21, 2024 at 11:06 PM James K. Lowden
<jklowden@schemamania.org> wrote:
>
> I have two simple questions, I hope!
>
> 1. Is there a set of flags that, when compiling gcc, is meant to
> produce no warnings? I get a surfeit of warnings with my particular
> favorite options.
-w is supposed to do that
> 2. Are the libgcc functions warning_at() and error_at() intended for
> use by all front-ends? As of now, our COBOL front-end formats its own
> messages with fprintf(3). I would like to emulate normal gcc behavior,
> where warnings can be turned on and off, and (especially) elevated to
> errors with -Werror. I'm guessing we'd gain access to that
> functionality automatically if we engaged with the standard diagnositic
> framework, if there is one.
>
> I'm a little doubtful these are the keys to that kingdom, though. The
> comments regarding location_t and the location database seem very
> C-specific.
Yes, the tools from diagnostic{-core,}.h are usable from all frontends.
The location_t is a libcpp thing but it's the location how it is tracked
through the middle-end and also for debug information generation
so you might want to at least emulate that even when you are not
using the preprocessor. The important part is to manage a line-map
here.
Richard.
> --jkl
prev parent reply other threads:[~2024-04-22 18:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-20 22:52 James K. Lowden
2024-04-22 18:59 ` Richard Biener [this message]
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=CAFiYyc1g0TVJEWrnf1LUq1c92G1kCAQci-u2uXpjuxm54V3BNA@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=jklowden@schemamania.org \
/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).