public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/106572] New: A programmatic list of all possible compiler warnings
@ 2022-08-09 14:40 j.badwaik@fz-juelich.de
  2022-08-09 14:43 ` [Bug c++/106572] " mpolacek at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: j.badwaik@fz-juelich.de @ 2022-08-09 14:40 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

            Bug ID: 106572
           Summary: A programmatic list of all possible compiler warnings
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: j.badwaik@fz-juelich.de
  Target Milestone: ---

It would be an excellent workflow to run your code with `-Weverything` once in
a while just to check which new warnings are triggered by your code. Then,
depending on whether they are useful or not, one can incorporate those warnings
in their normal workflow. 

The alternative is to go through the release notes of every GCC release
everytime and then try to see if there is a warning which interests you. While
this is doable, it requires manual effort, with a possibility that you find no
warning which is useful. Also, depending on the code, it might not be possible
to play with all compiler warnings as soon as the compiler is released, since
you might want to wait for your code to be able to compile with the compiler
before you go there.
All of this makes for a very clumsy workflow with a lot of manual reminders
about what needs to be done.

The `-Weverything` allows for someone to schedule say a monthly CI job which
automatically runs the build with `-Weverything -Werror`. Any new compilers
added and any new warning which affects the current code will automatically be
detected. The user can then make a decision on whether the warning makes enough
sense for them to be used in their production runs.  

Currently, the way to get a list of all warning is very cumbersome. One has to
do:
> g++ -Q --help=warnings | tail -n +2 | awk '{print $1}' | tr '\n' ' '

which blows up the command line for the compilation. 

The request would be to provide either a `-Weverything` flag like clang does or
a `g++ --list-every-warning` to list all warnings in a format which can then be
passed to the compiler.

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

* [Bug c++/106572] A programmatic list of all possible compiler warnings
  2022-08-09 14:40 [Bug c++/106572] New: A programmatic list of all possible compiler warnings j.badwaik@fz-juelich.de
@ 2022-08-09 14:43 ` mpolacek at gcc dot gnu.org
  2022-08-09 14:43 ` pinskia at gcc dot gnu.org
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2022-08-09 14:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Probably a dup of bug 31573.

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

* [Bug c++/106572] A programmatic list of all possible compiler warnings
  2022-08-09 14:40 [Bug c++/106572] New: A programmatic list of all possible compiler warnings j.badwaik@fz-juelich.de
  2022-08-09 14:43 ` [Bug c++/106572] " mpolacek at gcc dot gnu.org
@ 2022-08-09 14:43 ` pinskia at gcc dot gnu.org
  2022-08-09 14:51 ` j.badwaik@fz-juelich.de
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-09 14:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=31573

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-Weverything is useless and was decided years ago gcc was not going to add it.
See PR 31573.

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

* [Bug c++/106572] A programmatic list of all possible compiler warnings
  2022-08-09 14:40 [Bug c++/106572] New: A programmatic list of all possible compiler warnings j.badwaik@fz-juelich.de
  2022-08-09 14:43 ` [Bug c++/106572] " mpolacek at gcc dot gnu.org
  2022-08-09 14:43 ` pinskia at gcc dot gnu.org
@ 2022-08-09 14:51 ` j.badwaik@fz-juelich.de
  2022-08-09 14:53 ` j.badwaik@fz-juelich.de
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: j.badwaik@fz-juelich.de @ 2022-08-09 14:51 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

--- Comment #3 from Jayesh Badwaik <j.badwaik@fz-juelich.de> ---
I don't think any of the previous bug reports address the requirements that
this bug report does. This is not about production runs, this is about
development workflow. Unless the position is that users should not use any
warnings apart from `-Wall -Wextra` ever, the user has to look at what warnings
the compiler offers. 

The current method is a very manual method where I have to browse through the
whole GCC page and get the list of warnings and then manually put them into my
command line to see if any of the code in my repository triggers those
warnings. It will save everyone's time and effort if there was a switch to do
that.

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

* [Bug c++/106572] A programmatic list of all possible compiler warnings
  2022-08-09 14:40 [Bug c++/106572] New: A programmatic list of all possible compiler warnings j.badwaik@fz-juelich.de
                   ` (2 preceding siblings ...)
  2022-08-09 14:51 ` j.badwaik@fz-juelich.de
@ 2022-08-09 14:53 ` j.badwaik@fz-juelich.de
  2022-08-09 15:10 ` pinskia at gcc dot gnu.org
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: j.badwaik@fz-juelich.de @ 2022-08-09 14:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

--- Comment #4 from Jayesh Badwaik <j.badwaik@fz-juelich.de> ---
I don't think any of the previous bug reports address the requirements that
this bug report does. This is not about production runs, this is about
development workflow. Unless the position is that users should not use any
warnings apart from `-Wall -Wextra` ever, the user has to look at what warnings
the compiler offers. 

The current method is a very manual method where I have to browse through the
whole GCC page and get the list of warnings and then manually put them into my
command line to see if any of the code in my repository triggers those
warnings. It will save everyone's time and effort if there was a switch to do
that. It is therefore, actually very useful.

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

* [Bug c++/106572] A programmatic list of all possible compiler warnings
  2022-08-09 14:40 [Bug c++/106572] New: A programmatic list of all possible compiler warnings j.badwaik@fz-juelich.de
                   ` (3 preceding siblings ...)
  2022-08-09 14:53 ` j.badwaik@fz-juelich.de
@ 2022-08-09 15:10 ` pinskia at gcc dot gnu.org
  2022-08-09 15:14 ` pinskia at gcc dot gnu.org
  2022-08-10  7:02 ` rguenth at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-09 15:10 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>which blows up the command line for the compilation. 

You can use a response file and that won't blow up the command line at all.

That is:
g++ -Q --help=warnings | tail -n +2 | awk '{print $1}' | tr '\n' ' ' >
cxxflags.opt

g++ @cxxflags.opt ....

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

* [Bug c++/106572] A programmatic list of all possible compiler warnings
  2022-08-09 14:40 [Bug c++/106572] New: A programmatic list of all possible compiler warnings j.badwaik@fz-juelich.de
                   ` (4 preceding siblings ...)
  2022-08-09 15:10 ` pinskia at gcc dot gnu.org
@ 2022-08-09 15:14 ` pinskia at gcc dot gnu.org
  2022-08-10  7:02 ` rguenth at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-09 15:14 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> >which blows up the command line for the compilation. 
> 
> You can use a response file and that won't blow up the command line at all.
> 
> That is:
> g++ -Q --help=warnings | tail -n +2 | awk '{print $1}' | tr '\n' ' ' >
> cxxflags.opt
> 
> g++ @cxxflags.opt ....

Oh and you don't need the tr either that is any whitespace in a response file
is will be treated as a seperator.
So just:
g++ -Q --help=warnings | tail -n +2 | awk '{print $1}' > cxxflags.opt

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

* [Bug c++/106572] A programmatic list of all possible compiler warnings
  2022-08-09 14:40 [Bug c++/106572] New: A programmatic list of all possible compiler warnings j.badwaik@fz-juelich.de
                   ` (5 preceding siblings ...)
  2022-08-09 15:14 ` pinskia at gcc dot gnu.org
@ 2022-08-10  7:02 ` rguenth at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-08-10  7:02 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's also -Wfoo={1,2,3} and the like, not sure what "everything" would be
here?  The "strictest" level (if the levels order by strictness?)

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

end of thread, other threads:[~2022-08-10  7:02 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-09 14:40 [Bug c++/106572] New: A programmatic list of all possible compiler warnings j.badwaik@fz-juelich.de
2022-08-09 14:43 ` [Bug c++/106572] " mpolacek at gcc dot gnu.org
2022-08-09 14:43 ` pinskia at gcc dot gnu.org
2022-08-09 14:51 ` j.badwaik@fz-juelich.de
2022-08-09 14:53 ` j.badwaik@fz-juelich.de
2022-08-09 15:10 ` pinskia at gcc dot gnu.org
2022-08-09 15:14 ` pinskia at gcc dot gnu.org
2022-08-10  7:02 ` rguenth at gcc dot gnu.org

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