From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 4C2A43855164 for ; Thu, 1 Dec 2022 17:14:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4C2A43855164 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 0ED3E1FD80; Thu, 1 Dec 2022 17:14:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669914872; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Np1hGvrM3kGmmHFVLToTYevriaiwOpEqldWeH4csNkw=; b=rU+AUow+L2DSmdOpsYGEcfNXoF1klH2q0WWH/kOIlQBZvFoJmrODrGhARRGeGE3ibBfOF7 RBHCDvI3Rm8Zjnke3ijJRmVLOq6F/ZdZ4osMb2KbukYpIV2v8Tc2MmIrazGqIh2A7HeUQs W7O8J4/MOOsmjPejBXhBtReak7OML1A= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669914872; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Np1hGvrM3kGmmHFVLToTYevriaiwOpEqldWeH4csNkw=; b=XD70pwJ/DiFVlfFAewdXYeenEp39XOOynyhnjAnK8SfsddJ9qnpe4N8vG5UVxQW7vPsIdY O1VCdF5suYsgyxAw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 011BA2C141; Thu, 1 Dec 2022 17:14:28 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 1C9C5653D; Thu, 1 Dec 2022 17:14:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 1B41160F7; Thu, 1 Dec 2022 17:14:31 +0000 (UTC) Date: Thu, 1 Dec 2022 17:14:31 +0000 (UTC) From: Michael Matz To: "James K. Lowden" cc: gcc@gcc.gnu.org Subject: Re: access to include path in front end In-Reply-To: <20221201111126.3c0789057cdd420d930836a0@schemamania.org> Message-ID: References: <20221129100804.c5b3e5bc669ff92f2100c3a3@schemamania.org> <20221201111126.3c0789057cdd420d930836a0@schemamania.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hey, On Thu, 1 Dec 2022, James K. Lowden wrote: > > E.g. look in gcc.cc for '@c' (matching the file extension) how that > > entry uses '%(cpp_unique_options)', and how cpp_unique_options is > > defined for the specs language: > > > > INIT_STATIC_SPEC ("cpp_unique_options", &cpp_unique_options), > > > > and > > > > static const char *cpp_unique_options = > > "%{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %@{I*&F*} %{P} %I\ > > Please tell me if this looks right and complete to you: > > 1. Add an element to the static_specs array: > > INIT_STATIC_SPEC ("cobol_options", &cobol_options), That, or expand its contents where you'd use '%(cobol_options)' in the strings. > > 2. Define the referenced structure: > > static const char *cobol_options = "%{v} %@{I*&F*}" > or just > static const char *cobol_options = "%{v} %@{I*}" > > because I don't know what -F does, or if I need it. I.e. as long as it's that short expanding inline would work nicely. > I'm using "cobol_options" instead of "cobol_unique_options" because the > options aren't unique to Cobol, and because only cpp seems to have > unique options. > > I'm including %{v} against the future, when the cobol1 compiler > supports a -v option. Makes sense. > 3. Correct the entries in the default_compilers array. Currently I > have in cobol/lang-specs.h: > > {".cob", "@cobol", 0, 0, 0}, > {".COB", "@cobol", 0, 0, 0}, > {".cbl", "@cobol", 0, 0, 0}, > {".CBL", "@cobol", 0, 0, 0}, > {"@cobol", > "cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)}", > 0, 0, 0}, > > That last one is a doozy. Is it even slightly right? It misses %(cpp_unique_options) which was the reason why your -I arguments weren't passed to cobol1. You would just your new %(cobol_options), or simply '%{v} %{I*}' directly in addition to cc1_options. > IIUC, I should at > least remove > > %{!fsyntax-only:%(invoke_as)} > > because I don't need the options from the invoke_as string in gcc.cc. I think you do, as cobol1 will write out assembler code (it does, right?), so to get an object file the driver needs to invoke 'as' as well. Basically invoke_as tacks another command to run at the end of the already build command line (the one that above would start with 'cobol1 inputfile.cob ... all the options ...'. It will basically tack the equivalent of '| as tempfile.s -o realoutput.o' to the end (which eventually will make the driver executate that command as well). > That would still leave me with too much, because cobol1 ignores most of > the options cc1 accepts. What would you do? I would go through all cc1_options and see if they _really_ shouldn't be interpreted by cobol1. I guess for instance '-Ddefine' really doesn't make sense, but e.g. '-m...' and '-f...' do, and maybe -quiet as well, and suchlike. In that case I'd just use cc1_options (in addition to your new %{I*} snippet). If you then really determine, that no, most options do not make sense you need to extract a subset of cc1_options that do, and write them into the @cobol entry. Look e.g. what the fortran frontend does (in fortran/lang-specs.h) it simply attaches more things to cc1_options. > I don't understand the relationship between default_compliers and > static_specs. static_specs lists the names of 'variables' you can use within the specs strings, and to what they should expand. E.g. when I would want to use '%(foobar)' in any of my specs strings that needs to be registered in static_spec[]: INIT_STATIC_SPEC ("foobar", &a_variable_containing_a_string) The specs parse would then replace '%(foobar)' in specs strings with whatever that variable contains. Using such variables mostly makes sense if you want to enable users (who can provide their own specs file) to refer to well-known snippets maintained by GCC itself. For most such strings it's not necessary, and you'd be fine with the approach of fortran: #define MY_FOOBAR_STRING "%{v} ... this and that ..." ... {@mylang, ... "lang1 %i " MY_FOOBAR_STRING "" ... } > I have made no special provision for "compiler can deal with > multiple source files", except that cobol1 accepts multiple source > files on the command line, and iterates over them. If that's enough, > then I'll set compiler::combinable to 1. No good advise here for combinable. Try it :) > As I mentioned, for a year I've been able to avoid the Specs Language, > apparently because some things happen by default. The options defined > in cobol/lang.opt are passed from gcobol to cobol1. The value of the > -findicator-column option is available (but only if the option starts > with "f"; -indicator-column doesn't work). cobol1 sees the value of > -fmax-errors. That's because "%{f*}" is contained in %(cc1_options): 'pass on all options starting with "f"', and because you listed cc1_options in your cobol1 command line. Ciao, Michael.