From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121296 invoked by alias); 21 Aug 2015 14:18:02 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 120974 invoked by uid 48); 21 Aug 2015 14:17:57 -0000 From: "ibuclaw at gdcproject dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/67304] Allow front-ends to share command-line options with different behaviours Date: Fri, 21 Aug 2015 14:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ibuclaw at gdcproject dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-08/txt/msg01494.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304 --- Comment #3 from Iain Buclaw --- (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.