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