passing command-line arguments, still

passing command-line arguments, still

[James K. Lowden]

[I sent this to gcc-help by mistake. I'm reposting it here in case
anyone has a suggestion. I did take dje's advice, and deleted the build
directory, except that I preserved config.status and regenerated
Makefile.  The observed behavior remains unchanged.  TIA.]

https://git.symas.net:443/cobolworx/gcc-cobol/

My first question regards command-line options.  I've had no trouble
defining switches (-f-foo), but no luck defining an option that takes
an argument.  The latter are accepted by gcobol and not passed to
cobol1.  

In cobol/lang.opt, I have:

indicator-column
Cobol Joined Separate UInteger Var(indicator_column) Init(0)
IntegerRange(0, 8) -indicator-column=<n>	Column after which
Region B begins

strace(1) shows the problem:

[pid 683008] execve("../../../build/gcc/gcobol",
["../../../build/gcc/gcobol", "-main", "-o", "obj/SG105A", "-B",
"../../../build/gcc/", "-f-flex-debug", "-f-yacc-debug",
"-indicator-column", "1", "cbl/SG105A.cbl", "-lgcobol", "-lm", "-ldl"],
0x55a19b487940 /* 36 vars */ <unfinished ...>

gcobol is being invoked with 3 options used by cobol1:
      "-f-flex-debug", "-f-yacc-debug", "-indicator-column", "1"

where -indicator-column takes an argument, "1".  But it's not  passed to
cobol1: 

[pid 683008] <... execve resumed>)      = 0
[pid 683009] execve("../../../build/gcc/cobol1",
["../../../build/gcc/cobol1", "cbl/SG105A.cbl", "-quiet", "-dumpbase",
"SG105A.cbl", "-main", "-mtune=generic", "-march=x86-64", "-auxbase",
"SG105A", "-f-flex-debug", "-f-yacc-debug", "-o", "/tmp/ccIBQZv1.s"],
0x1578290 /* 40 vars */ <unfinished ...>

The stanza in cobol/lang.opt looks similar to others in
fortran/lang.opt. The gcc internals don't mention anything else that I
could find that needs to be done.  I've done a complete rebuild after
"make distclean".  And still no joy.

We are working with a gcc fork of 10.2.  Our log message says (in part):

    The "tiny" branch was started with the 10.2.1
origin/releases/gcc-10 branch> c806314b32987096d79de21e72dc0cf783e51d57)

What am I missing, please?

--jkl

Re: passing command-line arguments, still

[Marek Polacek]

On Wed, Mar 16, 2022 at 02:34:09PM -0400, James K. Lowden wrote:
> [I sent this to gcc-help by mistake. I'm reposting it here in case
> anyone has a suggestion. I did take dje's advice, and deleted the build
> directory, except that I preserved config.status and regenerated
> Makefile.  The observed behavior remains unchanged.  TIA.]
> 
> https://git.symas.net:443/cobolworx/gcc-cobol/
> 
> My first question regards command-line options.  I've had no trouble
> defining switches (-f-foo), but no luck defining an option that takes
> an argument.  The latter are accepted by gcobol and not passed to
> cobol1.  

Let's avoid -f-foo; use -ffoo instead, like the rest of GCC.
 
> In cobol/lang.opt, I have:
> 
> indicator-column

Make this 'findicator-column='.  Does that help?

> Cobol Joined Separate UInteger Var(indicator_column) Init(0)
> IntegerRange(0, 8) -indicator-column=<n>	Column after which
> Region B begins
> 
> strace(1) shows the problem:
> 
> [pid 683008] execve("../../../build/gcc/gcobol",
> ["../../../build/gcc/gcobol", "-main", "-o", "obj/SG105A", "-B",
> "../../../build/gcc/", "-f-flex-debug", "-f-yacc-debug",
> "-indicator-column", "1", "cbl/SG105A.cbl", "-lgcobol", "-lm", "-ldl"],
> 0x55a19b487940 /* 36 vars */ <unfinished ...>
> 
> gcobol is being invoked with 3 options used by cobol1:
>       "-f-flex-debug", "-f-yacc-debug", "-indicator-column", "1"
> 
> where -indicator-column takes an argument, "1".  But it's not  passed to
> cobol1: 
> 
> [pid 683008] <... execve resumed>)      = 0
> [pid 683009] execve("../../../build/gcc/cobol1",
> ["../../../build/gcc/cobol1", "cbl/SG105A.cbl", "-quiet", "-dumpbase",
> "SG105A.cbl", "-main", "-mtune=generic", "-march=x86-64", "-auxbase",
> "SG105A", "-f-flex-debug", "-f-yacc-debug", "-o", "/tmp/ccIBQZv1.s"],
> 0x1578290 /* 40 vars */ <unfinished ...>
> 
> The stanza in cobol/lang.opt looks similar to others in
> fortran/lang.opt. The gcc internals don't mention anything else that I
> could find that needs to be done.  I've done a complete rebuild after
> "make distclean".  And still no joy.

doc/options.texi describes options relative well, I think.
 
> We are working with a gcc fork of 10.2.  Our log message says (in part):
> 
>     The "tiny" branch was started with the 10.2.1
> origin/releases/gcc-10 branch> c806314b32987096d79de21e72dc0cf783e51d57)
> 
> What am I missing, please?
> 
> --jkl
> 

Marek

Re: passing command-line arguments, still

[James K. Lowden]

On Wed, 16 Mar 2022 14:45:33 -0400
Marek Polacek <polacek@redhat.com> wrote:

Hi Marek, 

> Let's avoid -f-foo; use -ffoo instead, like the rest of GCC.

Sure. I hadn't noticed the distinction. 

> > In cobol/lang.opt, I have:
> > 
> > indicator-column
> 
> Make this 'findicator-column='.  Does that help?

Yes, with that change, the option & argument are passed.  But ... why?

It's my understanding that the -f prefix indicates a switch, meaning:  

1.  It does not take an argument
2.  GCC accepts a  -fno- alternative, automatically
3.  The "f" stands for "flag", meaning on/off.  

My option has no alternative, if you'll pardon the pun.  I don't see
the point in confusing the user by suggesting it does.  

The fine manual says:

     By default, all options beginning with "f", "W" or "m" are
     implicitly assumed to take a "no-" form.  This form should not be
     listed separately.  If an option beginning with one of these
     letters does not have a "no-" form, you can use the
     'RejectNegative' property to reject it.

That isn't quite accurate.  The "no-" form isn't "implicitly assumed".
What would "explicitly assumed" look like, btw?  More accurate would be
to say a "fno-" form is automatically accepted or generated. Computer
code does not make assumptions; programmers do.  

Elsewhere: 

   * An option definition record.  These records have the following
     fields:
       1. the name of the option, with the leading "-" removed
       2. a space-separated list of option properties (*note Option
          properties::)
       3. the help text to use for '--help' (omitted if the second field
          contains the 'Undocumented' property).

Nowhere is it suggested that options that take arguments should have a
leading "f" or trailing "=".  

The *name* of the option doesn't include "="; it can be invoked Joined
or Separate.  Why does adding the "=" even work?  

> doc/options.texi describes options relative well, I think.

That's good to know; at least you're not telling me it's horribly out
of date.  I am puzzled, though, because AFAICT that document doen't
indicate why a leading "f" or trailing "=" controls whether or not an
option taking an argument is passed to the compiler. 

Regards, 

--jkl

Re: passing command-line arguments, still

[Jonathan Wakely]

On Thu, 17 Mar 2022 at 16:22, James K. Lowden wrote:
>
> On Wed, 16 Mar 2022 14:45:33 -0400
> Marek Polacek <polacek@redhat.com> wrote:
>
> Hi Marek,
>
> > Let's avoid -f-foo; use -ffoo instead, like the rest of GCC.
>
> Sure. I hadn't noticed the distinction.

There are no existing options of the form -f-foo, only -ffoo.

There is the -I- option, but it's weird and deprecated, and I don't
suggest using it as good style.


> > > In cobol/lang.opt, I have:
> > >
> > > indicator-column
> >
> > Make this 'findicator-column='.  Does that help?
>
> Yes, with that change, the option & argument are passed.  But ... why?
>
> It's my understanding that the -f prefix indicates a switch, meaning:
>
> 1.  It does not take an argument

There are lots of counterexamples such as -fplugin= and -fuse-ld=

And -fdiagnostics-column-origin=n which looks similar to what you want
to do, i.e. it takes a numeric argument. Note that it's declared with
an '=' in the name:

fdiagnostics-column-origin=
Common Joined RejectNegative UInteger

> That's good to know; at least you're not telling me it's horribly out
> of date.  I am puzzled, though, because AFAICT that document doen't
> indicate why a leading "f" or trailing "=" controls whether or not an
> option taking an argument is passed to the compiler.

Somebody will correct me if I'm wrong, but I think the leading f has
nothing to do with it. The point is just that -ffoo arg is two
separate options to the driver, and I don't think it knows that it
needs to pass the second one to the compiler process alongside the
first one. You didn't define your option to take an argument in the
.opt file.

Re: passing command-line arguments, still

[Joseph Myers]

On Thu, 17 Mar 2022, James K. Lowden wrote:

> That's good to know; at least you're not telling me it's horribly out
> of date.  I am puzzled, though, because AFAICT that document doen't
> indicate why a leading "f" or trailing "=" controls whether or not an
> option taking an argument is passed to the compiler. 

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).

If you want to pass down options from the driver that don't follow any 
existing naming convention, your language specs will need to contain the 
corresponding rules for passing down those options.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: passing command-line arguments, still

[Marek Polacek]

On Thu, Mar 17, 2022 at 12:21:36PM -0400, James K. Lowden wrote:
> On Wed, 16 Mar 2022 14:45:33 -0400
> Marek Polacek <polacek@redhat.com> wrote:
> 
> Hi Marek, 
> 
> > Let's avoid -f-foo; use -ffoo instead, like the rest of GCC.
> 
> Sure. I hadn't noticed the distinction. 
> 
> > > In cobol/lang.opt, I have:
> > > 
> > > indicator-column
> > 
> > Make this 'findicator-column='.  Does that help?
> 
> Yes, with that change, the option & argument are passed.  But ... why?

I think Jon and Joseph answered your questions now.
 
> It's my understanding that the -f prefix indicates a switch, meaning:  
> 
> 1.  It does not take an argument

It may, as Jon showed.

> 2.  GCC accepts a  -fno- alternative, automatically

Right, unless it's RejectNegative.

> 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.
 
> My option has no alternative, if you'll pardon the pun.  I don't see
> the point in confusing the user by suggesting it does.  
> 
> The fine manual says:
> 
>      By default, all options beginning with "f", "W" or "m" are
>      implicitly assumed to take a "no-" form.  This form should not be
>      listed separately.  If an option beginning with one of these
>      letters does not have a "no-" form, you can use the
>      'RejectNegative' property to reject it.
> 
> That isn't quite accurate.  The "no-" form isn't "implicitly assumed".
> What would "explicitly assumed" look like, btw?  

I guess that you'd have two separate entries in whatever.opt:

ffoo
...

fno-foo
...

> More accurate would be
> to say a "fno-" form is automatically accepted or generated. Computer
> code does not make assumptions; programmers do.  

TBH, I don't see how that would be any more accurate that what we have now.


Anyway, did you figure it out or are there some lingering questions?

Marek

Re: passing command-line arguments, still

[James K. Lowden]

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 +0000
Jonathan Wakely <jwakely.gcc@gmail.com> 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 <polacek@redhat.com> 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 
	<accept/produce/create>
	a "no-" form generated by <technology>.  

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

[David Edelsohn]

On Sat, Mar 19, 2022 at 1:11 PM James K. Lowden
<jklowden@schemamania.org> 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 +0000
> Jonathan Wakely <jwakely.gcc@gmail.com> 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 <polacek@redhat.com> 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
>         <accept/produce/create>
>         a "no-" form generated by <technology>.
>
> 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

[Jonathan Wakely]

On Sat, 19 Mar 2022 at 17:53, David Edelsohn wrote:
> 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".

And https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

Re: passing command-line arguments, still

[Jonathan Wakely]

On Sat, 19 Mar 2022 at 17:10, James K. Lowden wrote:
> > > 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.

Why should the historical convention that hasn't been true for years
win over the current one that is in wide usage?

Trying to revert to some idealised point in history will just cause
pain and break things now. It's better to just accept that the
original meaning mutated and "on/off flag" is no longer true.