From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) by sourceware.org (Postfix) with ESMTPS id 71A0C385840C for ; Sat, 19 Mar 2022 17:53:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 71A0C385840C Received: by mail-vs1-xe31.google.com with SMTP id 2so3847928vse.4 for ; Sat, 19 Mar 2022 10:53:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=irxu7k5V0mhZt7T+NveDKcomc0hRxnc8YOdvWgyF9OA=; b=BBqZlWzjc+xt4p+wqXpbyzHOV7NYwnzt3h5AnYKmYAGvphPOqOGPN9KmD08VItyM9S /xEpHPB3Obt4ZyUKio5lA00v0NX3yRLZ0SRdWQx03MlTXRD99jEPX22e+sXqNNtcNnuq 17atMz6JUnvKKWSR+HJmCwvrRe0oQzaxM9YBW8L0pj5rxpK+xm3auSAtVNYrmuWNVSIb 7LiOEWdZ+/EBMumYOQMaIOGKV2yKoT3TRSgxTYB2BvXD0LmJaD21AZ6VPWV35MQPu+YA 8eXRu0bLFrGWKszBdqlpkWfy+6cicg/bwtHRmoeTpOJpGBBEpudjuTQsSYpevUFmHN/D Khhw== X-Gm-Message-State: AOAM533fbxR7QgyVwSRY3KQHiAAu9LMp6SFLUrXKmss20Yy9CrV2RcG1 ABnMA2iuXJSjDAEYEXPT1tWIUJSTiVNlKUC7/4muvqkS X-Google-Smtp-Source: ABdhPJz3tEOlo5MtDmUurbqtwiAk+7biwRGb1Xj2kfaBJHseU1tFgN5dd61rTaMBpriogCXKf1ksZp4/wnTtbje54B8= X-Received: by 2002:a67:edd2:0:b0:320:92b6:f9fc with SMTP id e18-20020a67edd2000000b0032092b6f9fcmr5709792vsp.54.1647712396461; Sat, 19 Mar 2022 10:53:16 -0700 (PDT) MIME-Version: 1.0 References: <20220316143409.24cb3e7fd17c6b73acaee586@schemamania.org> <20220317122136.d15c4fd4f6ea9fec2cbc0938@schemamania.org> <20220319131029.49490fb71bf0bbaae4c598bf@schemamania.org> In-Reply-To: <20220319131029.49490fb71bf0bbaae4c598bf@schemamania.org> From: David Edelsohn Date: Sat, 19 Mar 2022 13:53:04 -0400 Message-ID: Subject: Re: passing command-line arguments, still To: GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2022 17:53:19 -0000 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 +0000 > 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