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