From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E2CE83858414 for ; Fri, 23 Jun 2023 18:31:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E2CE83858414 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687545085; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2VvqkXhNaQx8GLiGZna+z+kWsNdwd0OU+eWJ3QCec2c=; b=b3dQ4n/zhIShkmYkPJyohkoK1zM6JOJ7halvy4OV5lB5bWD0md13CIqarKwelCrXOwkPKR lHacIEtaTRYLFJw5IdShWokAGeY4FyesOsdyyl/M55+3F5DrQC4Bsd7huxGI2ClZMBszGo p+crTvmF7rHpwQJlHdDhBU2g4UDEyO4= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-330-LYwrO2jCN9GKgaON4hbicw-1; Fri, 23 Jun 2023 14:31:20 -0400 X-MC-Unique: LYwrO2jCN9GKgaON4hbicw-1 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-62ffa44eaf8so11071486d6.0 for ; Fri, 23 Jun 2023 11:31:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687545079; x=1690137079; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2VvqkXhNaQx8GLiGZna+z+kWsNdwd0OU+eWJ3QCec2c=; b=X1LaxiE+4T/n+IlXJs31Dl5RthC5qRfL9wvcjOs+BNatgnyevvMM97Bi6MtYZ8mNf+ xUjEK5Kge0WmWNow7tp0P3CDVW0xEvw6k1D0ITFhzWw5sIUwc4w0rvOYIhB30rFNr6l8 F4w82P3FrXlQ+LYlYLbZ4bg2qSwYdh+zTyvd0UH/L+g5ofYcayHi6PGgFEd2OI5G08DO r5iSTrDj2qiw+7Le86HM5OkysMpN5wCIvFCqGw2sHbikl2O8pJ/QUsUsB9C76yyNEtVz JwLYgse3jrEEmWXDqctSQRvA0mWStqhwADfZ05EDpkmux1I0cH1pQk66OCK2oLyoW2Nl v7nA== X-Gm-Message-State: AC+VfDyRyIhY6tRAWBSSQiun5fFZuF6Gbrbby8t9agLEWrBIsCX4X/XD koDEc3L7iQYTeNp7IV4U2ExaLIk2Hn5god0sNRnmYyvtmIOJ6fTHIBpnQtvCzuLl4aSvdWGm4B1 RGt7mDxjPIv1i X-Received: by 2002:a05:6214:c6c:b0:626:1227:1584 with SMTP id t12-20020a0562140c6c00b0062612271584mr27025215qvj.15.1687545078980; Fri, 23 Jun 2023 11:31:18 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6Z2u76H7T17uVl42a+8ycfcNzC4zPmvesqFjGcKozCZP0ZoTsMBGdpQuROHsFAA4QJzRafzA== X-Received: by 2002:a05:6214:c6c:b0:626:1227:1584 with SMTP id t12-20020a0562140c6c00b0062612271584mr27025193qvj.15.1687545078682; Fri, 23 Jun 2023 11:31:18 -0700 (PDT) Received: from [192.168.1.108] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id lw13-20020a05621457cd00b0062df235c6d9sm65723qvb.18.2023.06.23.11.31.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jun 2023 11:31:18 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2023 14:31:17 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v5 3/5] p1689r5: initial support To: Ben Boeckel Cc: gcc-patches@gcc.gnu.org, nathan@acm.org, fortran@gcc.gnu.org, gcc@gcc.gnu.org, brad.king@kitware.com References: <20230125210636.2960049-1-ben.boeckel@kitware.com> <20230125210636.2960049-4-ben.boeckel@kitware.com> <77ee5db6-e45e-5178-4807-5b2fef29e8c7@redhat.com> <20230620194649.GA186848@farprobe> From: Jason Merrill In-Reply-To: <20230620194649.GA186848@farprobe> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 6/20/23 15:46, Ben Boeckel wrote: > On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote: >> On 1/25/23 13:06, Ben Boeckel wrote: >>> Header units (including the standard library headers) are 100% >>> unsupported right now because the `-E` mechanism wants to import their >>> BMIs. A new mode (i.e., something more workable than existing `-E` >>> behavior) that mocks up header units as if they were imported purely >>> from their path and content would be required. >> >> I notice that the cpp dependency generation tries (in open_file_failed) >> to continue after encountering a missing file, is that not sufficient >> for header units? Or adjustable to be sufficient? > > No. Header units can introduce macros which can be used to modify the > set of modules that are imported. Included headers are "discovered" > dependencies and don't modify the build graph (just add more files that > trigger a rebuild) and can be collected during compilation. Module > dependencies are needed to get the build correct in the first place in > order to: > > - order module compilations in the build graph so that imported modules > are ready before anything using them; and > - computing the set of flags needed for telling the compiler where > imported modules' CMI files should be located. So if the header unit CMI isn't available during dependency generation, would it be better to just #include the header? >>> + if (cpp_opts->deps.format != DEPS_FMT_NONE) >>> + { >>> + if (!fdeps_file) >>> + fdeps_stream = out_stream; >>> + else if (fdeps_file[0] == '-' && fdeps_file[1] == '\0') >>> + fdeps_stream = stdout; >> >> You probably want to check that deps_stream and fdeps_stream don't end >> up as the same stream. > > Hmm. But `stdout` is probably fine to use for both though. Basically: > > if (fdeps_stream == out_stream && fdeps_stream != stdout) > make_diagnostic_noise (); (fdeps_stream == deps_stream, but sure, that's reasonable. >> So, I take it this is the common use case you have in mind, generating >> Make dependencies for the p1689 file? When are you thinking the Make >> dependencies for the .o are generated? At build time? > > Yes. If an included file changes, the scanning should be performed > again. The compilation will have its own `-MF` as well (which should > point to the same files plus the CMI files it ends up reading). > >> I'm a bit surprised you're using .json rather than an extension that >> indicates what the information is. > > I can change that; the filename doesn't *really* matter (e.g., CMake > uses `.ddi` for "dynamic dependency information"). That works. >>> `-M` is about discovered dependencies: those that you find out while >>> doing work. `-fdep-*` is about ordering dependencies: extracting >>> information from file content in order to even order future work around. >> >> I'm not sure I see the distinction; Makefiles also express ordering >> dependencies. In both cases, you want to find out from the files what >> order you will want to process them in when building the project. > > Makefiles can express ordering dependencies, but not the `-M` snippets; > these are for files that, if changed, should trigger a rebuild. This is > fundamentally different than module dependencies which instead indicate > which *compiles* (or CMI generation if using a 2-phase setup) need to > complete before compilation (or CMI generation) of the scanned TU can be > performed. Generally generated headers will be ordered manually in the > build system description. However, maintaining that same level for > in-source dependency information on a per-source level is a *far* higher > burden. The main difference I see is that the CMI might not exist yet. As you say, we don't want to require people to write all the dependencies by hand, but that just means we need to be able to generate the dependencies automatically. In the Make-only model I'm thinking of, one would collect dependencies on an initial failing build, and then start over from the beginning again with the dependencies we discovered. It's the same two-phase scan and build, but one that uses the same compile commands for both phases. Anyway, this isn't an objection to this patch, just another model I also want to support. >>> >> >> Is there a reason not to use the gcc/json.h interface for JSON output? > > This is `libcpp`; is that not a dependency cycle? Ah, indeed. We could move it to libiberty, but it would need significant adjustments to remove its dependencies on other stuff in gcc/. So maybe just add a TODO comment about that, along with adding comments before the functions. Jason