[Bug driver/43687] Unexpected error message for bad command line argument

[Bug driver/43687] Unexpected error message for bad command line argument

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.6.0
      Known to fail|                            |

--- Comment #17 from Joseph S. Myers <jsm28 at gcc dot gnu.org> 2011-03-23 00:23:51 UTC ---
The issue here with diagnostics for "--" options is fixed in 4.6.  (There will
still be some cases where a diagnostic ends up using a canonical form of an
option, but unknown "--" options like this will be diagnosed by the driver in
their original forms.)

[Bug driver/43687] Unexpected error message for bad command line argument

[joseph at codesourcery dot com]

------- Comment #16 from joseph at codesourcery dot com  2010-04-15 23:00 -------
Subject: Re:  Unexpected error message for bad command line
 argument

On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:

> ------- Comment #15 from manu at gcc dot gnu dot org  2010-04-15 22:42 -------
> (In reply to comment #14)
> > 
> > But for the -Werror=foo issue I'd have thought that making it send the 
> > -Wfoo option through the existing option processing machinery - as if both 
> > were specified consecutively on the command line - should suffice.  That 
> > seems largely independent of my proposal, and avoids any issues with 
> > needing functions to be present for all front ends.
> 
> That is not how it works. Not sure whether such approach would work at all. 
> 
> But that still doesn't solve the PR I mentioned because sending -Wfoo through
> the option machinery does not turn options enabled by Wfoo into errors. Even
> worse, what do you suggest for -Wno-error=foo?

Just as -Wfoo for each foo is a separate option that may have its own 
case, so it would seem that -Werror=foo and -Wno-error=foo are also rather 
like separate options.  That is, the -Wfoo processing code should take 
information about which derived option was passed, and use it both for 
setting variables and enabling / disabling errors (possibly calling a 
"process -W option" helper function for each option it implies).

But I don't want to design a detailed fix for each bug now.  The general 
idea is that you have code using cases rather than function pointers that 
works for -Wfoo and -Wno-foo and -Wfoo=bar, and if it can also handle 
-Werror=foo and -Wno-error=foo then you should avoid complications arising 
from the use of function pointers.


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[manu at gcc dot gnu dot org]

------- Comment #15 from manu at gcc dot gnu dot org  2010-04-15 22:42 -------
(In reply to comment #14)
> 
> But for the -Werror=foo issue I'd have thought that making it send the 
> -Wfoo option through the existing option processing machinery - as if both 
> were specified consecutively on the command line - should suffice.  That 
> seems largely independent of my proposal, and avoids any issues with 
> needing functions to be present for all front ends.

That is not how it works. Not sure whether such approach would work at all. 

But that still doesn't solve the PR I mentioned because sending -Wfoo through
the option machinery does not turn options enabled by Wfoo into errors. Even
worse, what do you suggest for -Wno-error=foo?


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[joseph at codesourcery dot com]

------- Comment #14 from joseph at codesourcery dot com  2010-04-15 22:32 -------
Subject: Re:  Unexpected error message for bad command line
 argument

On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:

> ------- Comment #13 from manu at gcc dot gnu dot org  2010-04-15 22:21 -------
> (In reply to comment #12)
> > 
> > I don't see adding function pointers as a particular improvement over the 
> > existing code where switch statements can already handle group options 
> 
> That code does not work when options are disabled/enabled from anywhere else
> apart from the command line. See PR40989.

What I'd imagine for options enabled from pragmas / attributes is that 
there would be a record kept of the state of options before defaults were 
applied, and such a late-applied option would effectively be appended to 
those on the command line, with the defaults then reapplied to determine 
the options subsequently in effect (or in effect for an individual 
function, etc.).

But for the -Werror=foo issue I'd have thought that making it send the 
-Wfoo option through the existing option processing machinery - as if both 
were specified consecutively on the command line - should suffice.  That 
seems largely independent of my proposal, and avoids any issues with 
needing functions to be present for all front ends.


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[manu at gcc dot gnu dot org]

------- Comment #13 from manu at gcc dot gnu dot org  2010-04-15 22:21 -------
(In reply to comment #12)
> 
> I don't see adding function pointers as a particular improvement over the 
> existing code where switch statements can already handle group options 

That code does not work when options are disabled/enabled from anywhere else
apart from the command line. See PR40989.

With function pointers we can do:

+         if (option->var_type == CLVC_BOOLEAN)
+           {
+             if (option->set)
+               option->set (1);
+             if (option->flag_var)
+               *(int *) option->flag_var = 1;
+           }


> including setting option variables only if they are still -1 (as done for 
> various options at present); marking group options only seems useful to me 
> if the .opt file also lists implications so that the ordering rules are 
> handled automatically.

This could be implemented later by extending Group to Group(option1,option2).
Then the awk scripts would generate the set_ function. But the function
pointers seem as a first step to me.

But if you think it is a bad idea, I will stop now rather than go on and waste
my time.


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[joseph at codesourcery dot com]

------- Comment #12 from joseph at codesourcery dot com  2010-04-15 22:01 -------
Subject: Re:  Unexpected error message for bad command line
 argument

On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:

> I just want to know whether my current approach is feasible or will be
> overridden by this work, so I don't waste my free time on this.

I do not advise stopping fixing bugs just because some future work may 
implement a more general infrastructure.  I would expect the changes for 
the multilibs proposal to involve a long series of incremental patches 
against trunk rather than a single large patch dump (given that it 
involves an audit of all specs for all targets for all options defined in 
specs, and those are liable to change fast, working other than on trunk 
would be a bad idea).

I don't see adding function pointers as a particular improvement over the 
existing code where switch statements can already handle group options 
including setting option variables only if they are still -1 (as done for 
various options at present); marking group options only seems useful to me 
if the .opt file also lists implications so that the ordering rules are 
handled automatically.


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[manu at gcc dot gnu dot org]

------- Comment #11 from manu at gcc dot gnu dot org  2010-04-15 21:42 -------
(In reply to comment #10)
> 
> We haven't determined who will end up implementing the proposal or 
> produced an implementation design at that level of detail, but personally 

You make it sound as a project that will take years to get done.

I just want to know whether my current approach is feasible or will be
overridden by this work, so I don't waste my free time on this.

Basically, group options are marked as such in *.opt and a function pointer is
added for each option. The awk scripts assign the function set_Woption to this
pointer. This function is hand-written right now but in the future it could be
autogenerated. When the option is enabled/disabled, the set_W function is
called.

If you want I can provide a concrete patch.


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[joseph at codesourcery dot com]

------- Comment #10 from joseph at codesourcery dot com  2010-04-15 21:30 -------
Subject: Re:  Unexpected error message for bad command line
 argument

On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:

> ------- Comment #9 from manu at gcc dot gnu dot org  2010-04-15 20:52 -------
> (In reply to comment #8)
> > 
> > We have not yet begun implementation.  For the semantics of group options, 
> > see Appendix 1 in my proposal (if -Wx implies -Wy and -Wz, then -Wno-y -Wx 
> > and -Wx -Wno-y both should disable -Wy but enable -Wz).
> 
> Fair enough this is what i was planning to implement. But my question is how
> you plan to implement this?

We haven't determined who will end up implementing the proposal or 
produced an implementation design at that level of detail, but personally 
I would envisage that the .opt files would contain information about what 
options imply what sets of other options (and what options are exact 
aliases of other options) and that the awk scripts would generate 
appropriate datastructures to be used by code shared by the driver and cc1 
etc.; certainly any code specific to a particular option, that is needed 
to determine the set of enabled features that are potentially relevant to 
multilib selection, must go somewhere that can be linked into both the 
driver and cc1.  As well as back ends contributing code to be linked in 
both places, it's possible that front ends will also contribute such code 
(linked into all of cc1, cc1plus etc.), but generic descriptions in .opt 
files are preferred where possible.

(There are certainly complications such as the implications of options 
from -On depending on both target and optimization level; I was imagining 
those would be resolved in the course of implementation rather than 
producing a detailed design for every patch in a long series up front.  I 
should also point out that the focus of the planned work is the 
improvements to multilib selection, so some cleanups may end up not being 
implemented if they end up proving not to be relevant to sharing 
option-processing and feature-calculation code between the driver and cc1 
and creating options structures that can be compared in the driver for 
multilib selection.)


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[manu at gcc dot gnu dot org]

------- Comment #9 from manu at gcc dot gnu dot org  2010-04-15 20:52 -------
(In reply to comment #8)
> 
> We have not yet begun implementation.  For the semantics of group options, 
> see Appendix 1 in my proposal (if -Wx implies -Wy and -Wz, then -Wno-y -Wx 
> and -Wx -Wno-y both should disable -Wy but enable -Wz).

Fair enough this is what i was planning to implement. But my question is how
you plan to implement this?


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[joseph at codesourcery dot com]

------- Comment #8 from joseph at codesourcery dot com  2010-04-15 20:37 -------
Subject: Re:  Unexpected error message for bad command line
 argument

On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:

> (In reply to comment #6)
> > Subject: Re:   New: Unexpected error message for bad command
> >  line argument
> > 
> > My multilib selection proposal 
> > <http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html> envisages the driver 
> > having a better structured notion of what options exist (shared with cc1), 
> 
> Do you have preliminary patches? I am trying to implement handling group
> options (-Wimplicit) in a more consistent way  but that would require to break
> up the global options.c in per-FE files to avoid problems with undefined
> functions. Is this part of your plan / conflicting with it / indifferent ?

We have not yet begun implementation.  For the semantics of group options, 
see Appendix 1 in my proposal (if -Wx implies -Wy and -Wz, then -Wno-y -Wx 
and -Wx -Wno-y both should disable -Wy but enable -Wz).


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[manu at gcc dot gnu dot org]

------- Comment #7 from manu at gcc dot gnu dot org  2010-04-15 20:00 -------
(In reply to comment #6)
> Subject: Re:   New: Unexpected error message for bad command
>  line argument
> 
> My multilib selection proposal 
> <http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html> envisages the driver 
> having a better structured notion of what options exist (shared with cc1), 

Do you have preliminary patches? I am trying to implement handling group
options (-Wimplicit) in a more consistent way  but that would require to break
up the global options.c in per-FE files to avoid problems with undefined
functions. Is this part of your plan / conflicting with it / indifferent ?


--- gcc/doc/options.texi        (revision 158350)
+++ gcc/doc/options.texi        (working copy)
@@ -141,10 +141,16 @@ will check and convert the argument befo
 option handler.  @code{UInteger} should also be used on options like
 @code{-falign-loops} where both @code{-falign-loops} and
 @code{-falign-loops}=@var{n} are supported to make sure the saved
 options are given a full integer.

+@item Group
+This option controls other options. There must be a corresponding
+function @code{set_OPTION} defined somewhere that specifies which
+further actions are taken when this option is enabled/disabled.
+
+
 @item Var(@var{var})
 The state of this option should be stored in variable @var{var}.
 The way that the state is stored depends on the type of option:

 @itemize @bullet




> in which context the -- to -f mapping might be implemented through a more 
> general system of option aliases rather than the present textual 
> translation.  So those changes should make it easier to give better 
> diagnostics here (and more generally to improve how GCC handles -- 
> options).
> 


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[joseph at codesourcery dot com]

------- Comment #6 from joseph at codesourcery dot com  2010-04-15 19:50 -------
Subject: Re:   New: Unexpected error message for bad command
 line argument

My multilib selection proposal 
<http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html> envisages the driver 
having a better structured notion of what options exist (shared with cc1), 
in which context the -- to -f mapping might be implemented through a more 
general system of option aliases rather than the present textual 
translation.  So those changes should make it easier to give better 
diagnostics here (and more generally to improve how GCC handles -- 
options).


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[wilson at codesourcery dot com]

------- Comment #5 from wilson at codesourcery dot com  2010-04-09 22:16 -------
Subject: Re:  Unexpected error message for bad command line
 argument

On 04/09/2010 02:34 PM, wilson at gcc dot gnu dot org wrote:
> POSIX says that for command line arguments "-a -d", "-d -a", "-da", and "-ad"
> are all equivalent.

Sorry, this is an overstatement.  I didn't mean to imply that option 
order doesn't matter.  So I should have said that "-d -a" and "-da" are 
equivalent, which is not true in gcc.

Jim


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[wilson at gcc dot gnu dot org]

------- Comment #4 from wilson at gcc dot gnu dot org  2010-04-09 21:34 -------
I don't think this is documented anywhere.  Not in gcc at least.

POSIX says that for command line arguments "-a -d", "-d -a", "-da", and "-ad"
are all equivalent.  Many GNU tools do not conform to this rule.  A long time
ago there was a push to try to fix all GNU tools.  The GNU solution was based
on the idea that POSIX says nothing about command line arguments that start
with two dashes, so we only had to ensure that all long options started with
two dashes.

For GCC, step1 of the solution was to add a translation table to map new --X
options to existing options.  To make the translation table shorter, there was
a default rule added for -f options, so that we didn't have to list them all. 
Hence any -- option not already in the table is assumed to be a -f option.

There was no step2 GCC solution, as people stopped caring, and then people
started forgetting why we were even doing this.

Anyways, printing the translated option name in an error message is wrong, and
should be fixed.


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[manu at gcc dot gnu dot org]

------- Comment #3 from manu at gcc dot gnu dot org  2010-04-09 07:28 -------
(In reply to comment #1)
> This is actually expected, though I cannot find it documented anywhere.  I
> thought I had saw it in the documentation at one point.  Almost all --* options
> are converted over to -f* to conform to the GNU coding style of long option
> names.

Even if it is expected, it is a hack and totally confusing for users. I don't
see a problem of leaving this open as a way to say: "We are happy if someone
fixes this without breaking anything else".

And even if what you say about GNU coding style were true, this is not how most
GNU programs behave nowadays, so perhaps the coding style is outdated.

grep --hlep
grep: unrecognized option `--hlep'

gcc --hlep test.c
cc1: error: unrecognized command line option "-fhlep"

Commandline handling on the driver is one of those hackish parts of the
compiler that everybody is afraid to touch, and the longer it takes, the more
difficult it becomes.

So CONFIRMED and patches welcome.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-09 07:28:04
               date|                            |


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

[Bug driver/43687] Unexpected error message for bad command line argument

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2010-04-08 22:40 -------
option_map has:
   {"--", "-f", "*j"}
And has been there since:
------------------------------------------------------------------------
r3686 | rms | 1993-03-08 21:47:14 -0800 (Mon, 08 Mar 1993) | 4 lines

Handle long options by translation to old-style ones.
(translate_options): New function.
(option_map): New table.


So it has been there since GCC 2.4.0 :).


-- 


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

[Bug driver/43687] Unexpected error message for bad command line argument

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2010-04-08 22:35 -------
This is actually expected, though I cannot find it documented anywhere.  I
thought I had saw it in the documentation at one point.  Almost all --* options
are converted over to -f* to conform to the GNU coding style of long option
names.


-- 


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