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

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

[ibuclaw at gdcproject dot org]

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

            Bug ID: 67304
           Summary: Allow front-ends to share command-line options with
                    different behaviours
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Marking as enhancement, as I'm sure that my situation is pretty unique (also
coming from a frontend maintained outside of gcc).

There are a couple of compiler-provided features in my frontend's frontend that
does the following for any provided source code to the compiler:
- Generate documentation.
- Generate 'header' sources.

Both come with independent options to set either the output file or directory.

Because they are 'generator' features, and do not have any effect on the
compilation process or codegen (unlike, for instance -fno-bounds-check), I'm a
bit wary of using an -fxxx option for them.

The upstream reference compiler uses the following options:

---
-D             generate documentation
-Dd<directory> write documentation file to directory
-Df<filename>  write documentation file to filename
-H             generate 'header' file
-Hd<directory> write 'header' file to directory
-Hf<filename>  write 'header' file to filename
---

Whilst it may seem natural to use the same options (also a win for existing
build tools), alas this is no good because C/C++ claims both -D and -H as
theirs and theirs only.  This seems overtly restricted.

For me, it makes more sense if the generated options.[ch] files had two levels
for handling front-end provided options.
1. To determine if the language handles -X
2. To forward -X to the language specific handler for processing/help/errors.

However I am not too familiar with the awk files used in the process, so I'm
not sure how much of an undertaking this will be.


N.B.  There's been a -J option in my frontend for some 12 years now, I'm not
sure if this precedes Fortran (long before my time when I picked up the
compiler), but Fortran claims it as theirs.  However I use it for something
completely different, and I guess it's only pure chance that we share identical
command-line usage. ;)

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

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
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?

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Iain Buclaw from comment #0)
> However I am not too familiar with the awk files used in the process, so I'm
> not sure how much of an undertaking this will be.

>From my own experience, being familiar with awk is not really needed. You just
need to figure out what C++ code you want to generate (options.c, options.h)
and how it will interact with the rest of GCC. I will suggest that you actually
prototype your changes directly hacking options.c and options.h, then you
modify the awk scripts to generate that code. Modifying the scripts is not that
complex, just printing the right things at the right place (probably our awk
scripts can be very much cleaned up and optimized but it hasn't been an issue
so far).
>From gcc-bugs-return-495348-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 21 13:12:20 2015
Return-Path: <gcc-bugs-return-495348-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24194 invoked by alias); 21 Aug 2015 13:12:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24165 invoked by uid 48); 21 Aug 2015 13:12:16 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67306] Patterns ICEs when moved using "simplify and match"
Date: Fri, 21 Aug 2015 13:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on assigned_to everconfirmed
Message-ID: <bug-67306-4-nIOUaev8i4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67306-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67306-4@http.gcc.gnu.org/bugzilla/>
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/msg01490.txt.bz2
Content-length: 579

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg306

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-08-21
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, indeed.  Mine.

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

[ibuclaw at gdcproject dot org]

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.