This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: introduce -fcallgraph-info option


On Nov  8, 2019, Richard Biener <rguenther@suse.de> 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);


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]