[Bug driver/49858] lost ability to use driver for external language support?

[bigotp at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858

--- Comment #2 from Peter A. Bigot <bigotp at acm dot org> 2011-07-27 00:38:16 UTC ---
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.
>