[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