From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116073 invoked by alias); 15 Nov 2019 00:56:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 116062 invoked by uid 89); 15 Nov 2019 00:56:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=4.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SEM_URI,SEM_URIRED,SPF_PASS,URIBL_DBL_SPAM autolearn=no version=3.3.1 spammy=UD:su, H*M:home, H*MI:home, ccache X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Nov 2019 00:56:27 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 08F23560D9; Thu, 14 Nov 2019 19:56:26 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SYY13vJn8Oml; Thu, 14 Nov 2019 19:56:25 -0500 (EST) Received: from free.home (tron.gnat.com [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 63DDC560D5; Thu, 14 Nov 2019 19:56:24 -0500 (EST) Received: from livre.home (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id xAF0u8rB516758 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Nov 2019 21:56:09 -0300 From: Alexandre Oliva To: Richard Biener Cc: gcc-patches@gcc.gnu.org, ebotcazou@adacore.com, joseph@codesourcery.com Subject: Re: introduce -fcallgraph-info option References: <84223B6B-F6F0-4B94-835E-6661E1E1EB6A@suse.de> Date: Fri, 15 Nov 2019 01:01:00 -0000 In-Reply-To: (Richard Biener's message of "Fri, 8 Nov 2019 09:28:47 +0100 (CET)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-11/txt/msg01318.txt.bz2 On Nov 8, 2019, Richard Biener wrote: > Wow, thanks for the elaborate write-up! I wonder if we can > cut&paste this into documentation somewhere appropriate, maybe > there's already a section for "auxiliary compiler outputs". Sure, that makes sense. >> I'm a little hesitant, this amounts to quite significant behavior >> changes. Do these seem acceptable and desirable nevertheless? > I think the current state is somewhat of a mess and in some > cases confusing and your suggestion sounds like an overall > improvement to me (you didn't actually suggest to remove > either of the -dump{base,dir} -auxbase{-strip} options?) I was trying to narrow down the desired behavior before trying to figure out what options we could do away with. If what I proposed was acceptable, I thought we could drop the internal -auxbase* options altogether. However, I missed one relevant case in my analysis. I suggested the auxbase internally derived from dumpbase would drop the dumpbase extension iff the extension matched that of the input file name. That doesn't work when compilation takes an intermediate file rather than the input, e.g., in a -save-temps compilation, in which we'll have separate preprocessing and the actual compiler will take the saved preprocessed input, but should still output dumps to files named after the .c input. ex $CC -S srcdir/foo.c -o objdir/foo.s -save-temps -> objdir/foo.i objdir/foo.s objdir/foo.su objdir/foo.c.#t.original The compilation line would only take the .c from -dumpbase, but since its input is .i, it wouldn't match, and we wouldn't strip the .c from aux outputs, and would instead generate: -> objdir/foo.i objdir/foo.s objdir/foo.c.su objdir/foo.c.#t.original ^^ (which would likely be ok for .su, but quite unexpected for .dwo) In order to address this, I propose we add an internal option (not for the driver), -dumpbase-ext, that names the extension to be discarded from dumpbase to form aux output names. -dumpdir objdir -dumpbase foo.c -dumpbase-ext .c The new -dumpbase-ext option specifies the extension to drop from the specified -dumpbase to form aux output names, but dump output names keep that intermediate extension. When absent, we take it from the main input file. So aux outputs end up as objdir/foo.* whereas dump outputs end up as objdump/foo.c.*, just as expected. We could keep -dumpbase-ext an internal option, used only when doing separate preprocessing, but it might make sense to expose it for use along with -dumpbase for such tools as ccache and distcc, that call the compiler driver with internal .i files, but would still prefer dumps and aux files to be generated just as they would have for the .c files. Specs would change from: %{!dumpbase:-dumpbase %B} %{c|S:%{o*:-auxbase-strip %*} %{!o*:-auxbase %b}}} %{!c:%{!S:-auxbase %b} to %{!dumpdir:%{o*:-dumpdir %:dirname(%*)}} %{c|S:%{!dumpbase:%{o*:-dumpbase %:replace-extension(%:basename(%*) %:extension(%i))} %{!o*:-dumpbase %b}}} %{!c:%{!S:-dumpbase %b} and add to separate preprocessing commands: %{!dumpbase-ext:-dumpbase-ext %:extension(%i)} Then we'd set up aux_base_name from dump_base_name minus the extension, given or taken from main_input_filename. -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Free Software Evangelist Stallman was right, but he's left :( GNU Toolchain Engineer FSMatrix: It was he who freed the first of us FSF & FSFLA board member The Savior shall return (true);