This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/67304] Allow front-ends to share command-line options with different behaviours


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304

--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to joseph@codesourcery.com from comment #1)
> On Fri, 21 Aug 2015, ibuclaw at gdcproject dot org wrote:
> 
> > -D             generate documentation
> 
> The driver needs to know what's an option and what's an option argument, 
> so that it can identify input files and know what front end or front ends 
> to run.  How would you expect it to distinguish your front end's -D (an 
> option on its own) from the C "-D foo" (option with separate argument)?  
> Or are you only interested in these options for a language-specific driver 
> program, not with the generic "gcc" driver?

If I were to assume that the driver for each language (g++, gfortran, gcj)
would be considered part of the generic "gcc" driver, then it would be the
latter rather than the former.

If it is indeed the former, then you might ignore the next comment, which is by
and large just me thinking out loud with not a good deal of understanding this
particular component of gcc.

The desired behaviour I've got in mind, is that from knowing which
language-specific options each front-end uses (by collecting all options from
lang.opt), the decoding process becomes:

if (option->flags & lang_specific_mask)
  lang_specific[lang]->decode(argv + i, &opt_array[num_decoded_options]);

Where:
 - lang_specific_mask: Starts off being whatever language the driver defaults
to compiling for (CL_CXX for g++, etc...), but is overridden given the -Xlang
option.
 - lang_specific[lang]->decode: Calls an auto generated function from the
language-specific lang.opt input files (options-cxx.c)

However this would, in trying to consider all angles, add some extra bloat with
the duplications of "shared-but-not-common" handlers, unless some clever
merging is done.  I guess it would also mean that the entire command-line
decoding process may need to be rolled back and restarted if an -Xnew-lang
option is encountered.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]