http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-07-26 23:31:27 UTC --- On Tue, 26 Jul 2011, bigotp at acm dot org wrote: > Is there a mechanism by which the driver can be informed of options that it > should allow in this situation, given that the list of these options is not > known at the time the driver is compiled? No. By design there is now a structured notion of options shared by the driver and cc1 and a single mechanism for option parsing, that consistently rejects unknown options rather than having them sometimes only inconsistently rejected depending on which phases of compilation are run, and that is intended in future to support multilib selection based on logical option state rather than option text, and maybe eventually disallowing options without --help text. It was a mistake that specs were ever documented in the user manual; they should be considered a purely internal interface between different parts of GCC. It is not expected that you can drop in support for new languages without at least part of that support being present when GCC is built (GNU/Linux distributors may include the minimal set of files defining specs and options for languages such as D and Pascal when they build their main GCC packages, for example, so that the driver then supports those languages even though the language compilers themselves are built separately). (I do not rule out that the plugin mechanism could be extended in future to allow driver plugins, that might modify the unknown option handling, but the change away from allowing arbitrary options that just happen to be matched by some spec, to having a structured notion allowing a meaningful enumeration of all supported options and their associated properties, is deliberate. It would also be reasonable to provide a way to export the properties of GCC's options for use in external wrappers to know what options take arguments. But processing options unknown to GCC is outside the intended uses of the driver at present, although you may be able to find a hack where your wrapper hides them within options known to GCC that take an argument but where the driver doesn't validate that argument in any way; -fplugin-arg-* might be the most sensible option to use.)
