public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* warnings and warnings
@ 2024-04-20 22:52 James K. Lowden
  2024-04-22 18:59 ` Richard Biener
  0 siblings, 1 reply; 2+ messages in thread
From: James K. Lowden @ 2024-04-20 22:52 UTC (permalink / raw)
  To: gcc

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.  

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.  

--jkl

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: warnings and warnings
  2024-04-20 22:52 warnings and warnings James K. Lowden
@ 2024-04-22 18:59 ` Richard Biener
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2024-04-22 18:59 UTC (permalink / raw)
  To: James K. Lowden; +Cc: gcc

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-04-22 18:59 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-20 22:52 warnings and warnings James K. Lowden
2024-04-22 18:59 ` Richard Biener

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).