[Bug driver/43687] Unexpected error message for bad command line argument
joseph at codesourcery dot com
gcc-bugzilla@gcc.gnu.org
Thu Apr 15 23:00:00 GMT 2010
------- 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
More information about the Gcc-bugs
mailing list