Re: passing command-line arguments, still
I'm collecting my remarks in one reply here, hopefully for easier
reading. I want to offer my thanks, and also my assessment of the
situation as I understand it. My critique is intended as purely
constructive.
I understand vaguely what's going on. I'll use the -findicator-column=
form because it works, and because that's today's convention.
I assert:
1. I did define my option to take an argument.
2. The documentation is incomplete and incorrect.
3. The naming convention is inconsistent.
Joseph Myers answered my question directly:
> The .opt files control how options are parsed, both in the driver and
> in the compiler programs such as cc1. Passing of options from the
> driver to those compiler programs is based on specs in the driver; -f
> options are passed down because of the use of %{f*} in cc1_options
> (and the use of %(cc1_options) in the specs for most languages).
IIUC, it's not lang.opt, but lang-specs.h:
$ nl lang-specs.h
1 /* gcc-src/gcc/config/lang-specs.h */
2 {".cob", "@cobol", 0, 1, 0},
3 {".COB", "@cobol", 0, 1, 0},
4 {".cbl", "@cobol", 0, 1, 0},
5 {".CBL", "@cobol", 0, 1, 0},
6 {"@cobol", "cobol1 %i %(cc1_options) %{!fsyntax-only:%
(invoke_as)}", 0, 1, 0},
The contents of that file are unspecified. gccint.info says only:
> 'lang-specs.h'
> This file provides entries for 'default_compilers' in 'gcc.c'
> which override the default of giving an error that a compiler for that
> language is not installed.
I implemented the above by cargo-cult coding. Until today I had no
idea what line 6 does. Now I have only some idea.
I don't understand where the %{} syntax is processed. I'm guessing
autoconf, which on this project is above my pay grade.
On Thu, 17 Mar 2022 17:39:00 +
Jonathan Wakely wrote:
> You didn't define your option to take an argument in the
> .opt file.
Of course I did:
indicator-column
Cobol Joined Separate UInteger Var(indicator_column) Init(0)
IntegerRange(0, 8)
Column after which Region B begins
That says it takes an argument -- either Joined or Separate -- as an
unsigned integer initialized to 0 in the range [0,8]. Not only that,
the option is accepted by gcobol; it's just not passed to the
compiler.
The documentation does not say an option taking an argument must
end in "=" and does not recommend it begin with "f".
Marek Polacek wrote:
> > 2. GCC accepts a -fno- alternative, automatically
>
> Right, unless it's RejectNegative.
Yes, and RejectNegative is an instrument of accidental complexity. If
-f options automatically accept a -fno- option, then a -f option that
does not want a -fno- alternative should use another name. There are
25 other lowercase letters available.
> > 3. The "f" stands for "flag", meaning on/off.
>
> It does stand for "flag", and it looks like at some point in ancient
> history if was on/off, but then came options like -falign-loops=N.
IME, someone made a mistake in the past, and that mistake is now
becoming mistaken for a standard. I don't mind living with some cruft
-- it's not as though gcc is unique in that regard -- but at the same
time I see no reason to vernerate it or perpetuate it.
In plain words, if we recognize that -f indicates an on/off switch,
let's use it that way, deprecate those that don't, and not add new -f
options that take arguments.
One last, final minor point,
> > By default, all options beginning with "f", "W" or "m" are
> > implicitly assumed to take a "no-" form.
> > More accurate would be
> > to say a "fno-" form is automatically accepted or generated.
>
> TBH, I don't see how that would be any more accurate that what we
> have now.
Words matter. No one is assuming anything, a fact hidden by the passive
"are implicitly assumed". I don't know whether -fno- is "accepted" or
"generated", or by what. I'm suggesting the agent be stated and the
verb not hide what's happening. I would say:
"Options beginning with "f", "W" or "m" also
a "no-" form generated by .
I wouldn't say "by default", because it's not by default. It's by
design, and the alternative is contained in the next sentence.
I've said my peace. I have my option, and I'll use it. If any of my
assertions is incorrect, I'd be happy to be corrected. I hope my
observations, if correct, contribute to better option names and
documentation.
My thanks for your help. I'm sure we've spent more time on
this corner of configuration than we expected to.
--jkl
Re: passing command-line arguments, still
On Sat, Mar 19, 2022 at 1:11 PM James K. Lowden
wrote:
>
> I'm collecting my remarks in one reply here, hopefully for easier
> reading. I want to offer my thanks, and also my assessment of the
> situation as I understand it. My critique is intended as purely
> constructive.
>
> I understand vaguely what's going on. I'll use the -findicator-column=
> form because it works, and because that's today's convention.
>
> I assert:
>
> 1. I did define my option to take an argument.
> 2. The documentation is incomplete and incorrect.
> 3. The naming convention is inconsistent.
>
> Joseph Myers answered my question directly:
>
> > The .opt files control how options are parsed, both in the driver and
> > in the compiler programs such as cc1. Passing of options from the
> > driver to those compiler programs is based on specs in the driver; -f
> > options are passed down because of the use of %{f*} in cc1_options
> > (and the use of %(cc1_options) in the specs for most languages).
>
> IIUC, it's not lang.opt, but lang-specs.h:
>
> $ nl lang-specs.h
> 1 /* gcc-src/gcc/config/lang-specs.h */
> 2 {".cob", "@cobol", 0, 1, 0},
> 3 {".COB", "@cobol", 0, 1, 0},
> 4 {".cbl", "@cobol", 0, 1, 0},
> 5 {".CBL", "@cobol", 0, 1, 0},
> 6 {"@cobol", "cobol1 %i %(cc1_options) %{!fsyntax-only:%
> (invoke_as)}", 0, 1, 0},
>
> The contents of that file are unspecified. gccint.info says only:
>
> > 'lang-specs.h'
> > This file provides entries for 'default_compilers' in 'gcc.c'
> > which override the default of giving an error that a compiler for that
> > language is not installed.
>
> I implemented the above by cargo-cult coding. Until today I had no
> idea what line 6 does. Now I have only some idea.
>
> I don't understand where the %{} syntax is processed. I'm guessing
> autoconf, which on this project is above my pay grade.
The %{} syntax is the "Specs language" used for options processing by
GCC. It is not related to autoconf. The options processing is
handled in gcc.c. Please see the comment in gcc/gcc.cc beginning with
"The Specs Language".
GCC definitely could benefit from better documentation and clearer
introductions for beginners. You privately mentioned to me that
documentation is one of your passions. Your assistance to improve the
documentation of GCC would be welcomed.
Thanks, David
>
> On Thu, 17 Mar 2022 17:39:00 +
> Jonathan Wakely wrote:
>
> > You didn't define your option to take an argument in the
> > .opt file.
>
> Of course I did:
>
> indicator-column
> Cobol Joined Separate UInteger Var(indicator_column) Init(0)
> IntegerRange(0, 8)
> Column after which Region B begins
>
> That says it takes an argument -- either Joined or Separate -- as an
> unsigned integer initialized to 0 in the range [0,8]. Not only that,
> the option is accepted by gcobol; it's just not passed to the
> compiler.
>
> The documentation does not say an option taking an argument must
> end in "=" and does not recommend it begin with "f".
>
> Marek Polacek wrote:
> > > 2. GCC accepts a -fno- alternative, automatically
> >
> > Right, unless it's RejectNegative.
>
> Yes, and RejectNegative is an instrument of accidental complexity. If
> -f options automatically accept a -fno- option, then a -f option that
> does not want a -fno- alternative should use another name. There are
> 25 other lowercase letters available.
>
> > > 3. The "f" stands for "flag", meaning on/off.
> >
> > It does stand for "flag", and it looks like at some point in ancient
> > history if was on/off, but then came options like -falign-loops=N.
>
> IME, someone made a mistake in the past, and that mistake is now
> becoming mistaken for a standard. I don't mind living with some cruft
> -- it's not as though gcc is unique in that regard -- but at the same
> time I see no reason to vernerate it or perpetuate it.
>
> In plain words, if we recognize that -f indicates an on/off switch,
> let's use it that way, deprecate those that don't, and not add new -f
> options that take arguments.
>
> One last, final minor point,
>
> > > By default, all options beginning with "f", "W" or "m" are
> > > implicitly assumed to take a "no-" form.
>
> > > More accurate would be
> > > to say a "fno-" form is automatically accepted or generated.
> >
> > TBH, I don't see how that would be any more accurate that what we
> > have now.
>
> Words matter. No one is assuming anything, a fact hidden by the passive
> "are implicitly assumed". I don't know whether -fno- is "accepted" or
> "generated", or by what. I'm suggesting the agent be stated and the
> verb not hide what's happening. I would say:
>
> "Options beginning with "f", "W" or "m" also
>
> a "no-" form generated by .
>
> I wouldn't say "by default", because it's not by default. It's by
> design, and the alternative is contained in the next sentence.
>
> I've said my peace. I have my option, and I'll use
gcc-11-20220319 is now available
Snapshot gcc-11-20220319 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20220319/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision d32402e6167294ad8ba84ffccebff1b098d2b4e1 You'll find: gcc-11-20220319.tar.xz Complete GCC SHA256=922a7ec02dd1cc3a08ca25ceb3c32254bb0f6a84ecc9792795a34f66948aa2cb SHA1=c3f355eaf925b473224af6493e129fdc1b53e7ff Diffs from 11-20220312 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
