public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "manu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
Date: Tue, 22 Jan 2008 09:04:00 -0000	[thread overview]
Message-ID: <20080122075120.15495.qmail@sourceware.org> (raw)
In-Reply-To: <bug-31349-13350@http.gcc.gnu.org/bugzilla/>



------- Comment #8 from manu at gcc dot gnu dot org  2008-01-22 07:51 -------
Can't  we get this fixed soon? It is marked as a P2 regression.

(In reply to comment #7)
> Subject: Re:  [4.3 Regression] gcc -v --help returns no options

> You can find out all the options supported by a given language, 
> including the ones that it shares with other languages and including 
> those that do not have a description by using the --help=<language> 
> feature.  For example:

So, instead of the current:

The following options are specific to the language C:
 No options with the desired characteristics were found

can't be said better:

No options are specific to the language C:
 Use --help=c to list options supported by the language C.


>    % gcc --help=java
>    The following options are supported by the language Java:

I should note that 

% gcc -v --help=c

returns the following for me

The following options are language-independent:
  --help                      Display this information
  --help=<class>              Display descriptions of a specific class of
                              options.  <class> is one or more of optimizers,
                              target, warnings, undocumented, params

I think it should say "The following options are supported by the language C".
Yes, some of those options may work on other languages, but they also may not
work in all of them. Language-independent is ambiguous.

> So I think that the bone of contention here is what should be listed by 
> "--help -v".  I think that leaving out options which have no description 
> is a good default.  If for no other reason than to encourage people to 
> write descriptions for the options so that they are then listed in the 
> --help output.

I don't think it works like this. Few GCC devs would bother to use --help to
find options. On the other hand, users will likely report a bug whenever they
find "This switch lacks documentation".

> Do you still feel that "--help -v" should list undocumented options ?

I understand Brooks was asking to list options supported by each language
rather than options specific to each language. Either way seems correct as long
as you can get the other. He also was asking to list supported options without
its description (independently whether they are documented or not) at the top
as in:

The Fortran front end recognizes the following options:

  -I, -Wall, -Wconversion, -fopenmp, -fpreprocessed, -fshort-enums

  -J<directory>               Put MODULE files in 'directory'
  -Waliasing                  Warn about possible aliasing of dummy arguments


My proposal would be:

1) Change the current empty message to mention --help=<language> as described
above.

2) List all options with --help -v, even if they are undocumented (abusing of
-Wextra for this seems unjustified to me). I would further propose that if
checking is enabled, then show the message "This switch lacks documentation",
otherwise (for releases) just show the empty string "".

Can we agree on this?


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
   Last reconfirmed|2007-03-25 22:48:12         |2008-01-22 07:51:20
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349


  parent reply	other threads:[~2008-01-22  7:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-25 21:42 [Bug other/31349] New: " brooks at gcc dot gnu dot org
2007-03-25 21:48 ` [Bug other/31349] [4.3 Regression] " pinskia at gcc dot gnu dot org
2007-06-29 18:05 ` mmitchel at gcc dot gnu dot org
2007-07-03 10:59 ` nickc at redhat dot com
2007-07-03 16:27 ` nickc at redhat dot com
2007-07-03 19:45 ` brooks at gcc dot gnu dot org
2007-07-03 19:46 ` brooks at gcc dot gnu dot org
2007-07-04 13:40 ` nickc at redhat dot com
2008-01-22  9:04 ` manu at gcc dot gnu dot org [this message]
2008-01-23 13:55 ` nickc at redhat dot com
2008-01-23 14:21 ` nickc at redhat dot com
2008-02-19 10:36 ` nickc at gcc dot gnu dot org
2008-02-19 11:21 ` manu at gcc dot gnu dot org
2008-02-19 14:13 ` nickc at redhat dot com
2008-02-19 14:45 ` manu at gcc dot gnu dot org
2008-02-19 15:12 ` nickc at redhat dot com
2008-02-19 16:15 ` manu at gcc dot gnu dot org

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=20080122075120.15495.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).