The nesC compiler at http://sourceforge.net/projects/nescc/ has historically used a host/target gcc driver to process its files by using an wrapper driver that invokes the target gcc with a -specs option defining a suffix-spec pair describing how to translate its source files. The documentation at http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html suggests that this practice, as shown below, is a legitimate use of the driver: .nc: perl -S nesc-compile %{_*} %{m*} %{D*&U*&A*} %{H} %{I*} %{undef} %{trigraphs} %{i*} %{nostdinc} %{a*} %{g*} %{O*} %{W*} %{w} %{S} %{pedantic*} %{std*} %{ansi} %{traditional} %{v} %{p*} %{f*} %{!fsyntax-only:%{!fnesc-cfile=*:%{!_fnesc-cfile=*:-fnesc-tmpcfile=%g.c}} %{S:%W{o*}%{!o*:-o %b.s}}%{!S:%{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}}} %{fsyntax-only:-o %j} %{-param*} %i -_ASM %Y The change in commit 171307 rejects the options formerly allowed by this spec string: gcc: error: unrecognized command line option ‘-_fnesc-include=nesc_nx’ The wildcard spec string %{_*} no longer allows these options. Explicitly adding %{_fnesc-include=*} didn't work either. 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?
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.)
On Tue, Jul 26, 2011 at 6:31 PM, joseph at codesourcery dot com < gcc-bugzilla@gcc.gnu.org> wrote: > 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). > On one hand, I think a regression like this warrants discussion, as this removes a feature that has been supported by gcc (and arguably documented as supported) for many years. Worst, the people who depend on it are folks who are unlikely to be involved in gcc development and will not be aware of the change until after 4.7.0 comes out and their systems have to be rearchitected to work with new vendor-provided gcc installations. I only found it now because I'm updating an out-of-tree back-end (TI msp430) and most of my practical applications depend on nesC. On the other hand, I'm sympathetic to the position that specs are a matter of internal implementation feature and that the change is reasonable. If that's going to be the resolution, though, the spec files material should be moved to the internals documentation. Peter (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.) > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >