On 11/8/19, Richard Biener <rguent...@suse.de> wrote: > On Thu, 7 Nov 2019, Alexandre Oliva wrote: > >> On Nov 7, 2019, Richard Biener <rguent...@suse.de> wrote: >> >> > (also raises the question why we have both -dumpbase and -auxbase ...) >> >> https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html >> >> This was before -dumpdir, however. >> >> Here's the current logic for aux_base_name: >> >> -c or -S with -o [odir/]obase.oext: [odir/]obase >> otherwise, given input [idir/]ibase.iext: ibase >> >> Whereas the current logic for dump_base_name, once aux_base_name has >> been determined as [auxdir/]auxbase, is: >> >> given -dumpbase ddir/dbase: ddir/dbase >> otherwise, given -dumpdir ddir and -dumpbase dbase: ddir/dbase >> otherwise, given -dumpbase dbase: [auxdir/]dbase >> otherwise, given -dumpdir ddir: ddir/ibase.iext >> otherwise: [auxdir/]ibase.iext >> >> Relevant cases to consider: (aux, dump) for each compilation with >> CC='gcc -fstack-usage -fdump-tree-original' >> >> compiling without -o: (ibase, ibase.iext) >> ex $CC -c srcdir/foo.c srcdir/x/bar.c >> -> foo.o foo.su foo.c.#t.original >> + bar.o bar.su bar.c.#t.original >> >> compiling with -o: ([odir/]obase, [odir/]ibase.iext) >> ex $CC -c srcdir/foo.c -o objdir/foobaz.o -Dfoobaz >> -> objdir/foobaz.o objdir/foobaz.su objdir/foo.c.#t.original >> >> compiling multiple sources with -dumpbase: (ibase, [ddir/]dbase) >> ex $CC -dumpbase outdir/runme.dump -c srcdir/foo.c srcdir/x/bar.c >> -> foo.o foo.su outdir/runme.dump.#t.original >> + bar.o bar.su outdir/runme.dump.#t.original (dupe) >> >> compiling and linking with -o: (ibase, ibase.iext) >> ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c >> -> /tmp/temp().o foo.su foo.c.#t.original >> + /tmp/temp().o bar.su bar.c.#t.original >> + outdir/runme >> >> lto-recompiling and linking with -o: (/tmp/obase.temp().ltrans#.ltrans, >> odir/obase.ltrans#) >> ex $CC -o outdir/runme ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand >> -> /tmp/runme.temp().ltrans0.ltrans.o /tmp/runme.temp().ltrans0.ltrans.su >> + outdir/runme.ltrans0.#r.expand >> + outdir/runme >> >> lto-recompiling and linking without -o: (/tmp/temp().ltrans#.ltrans, >> /tmp/temp().ltrans#.o) >> ex $CC ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand >> -> /tmp/temp().ltrans0.ltrans.o /tmp/temp().ltrans0.ltrans.su >> + /tmp/temp().ltrans0.#r.expand >> + a.out >> >> >> If we were to unify auxbase and dumpbase, I'd take the opportunity to >> fix the -o objdir/foobaz.o compilation to output dumps named after >> objdir/foobaz or objdir/foobaz-foo.c rather than ./foo.c; for >> outdir/runme.dump to be used as a prefix for aux and dump names, so that >> we wouldn't create and then overwrite outdir/runme.dump, and so that >> other compilations of foo.c and bar.c wouldn't overwrite the .su files, >> but rather create outdir/runme.dump-{foo,bar}.* dumps and aux files; and >> likewise use outdir/runme.ltrans0 or a.out.ltrans0 for the .su and >> .expand files. >> >> >> The logic I suggest is involves combining some of the -auxbase and some >> of the -dumpbase logic, namely: >> >> In the driver: >> >> compiling a single source idir/ibase.iext: >> >> -o odir/obase.oext specified: default -dumpdir odir -dumpbase >> obase.iext >> -o obase.oext specified: default -dumpbase obase.iext >> -o ibase.oext implied: default -dumpbase ibase.iext >> >> compiling multiple sources named as ibase.iext for linking: >> >> -dumpbase [ddir/]dbase specified: make it -dumpbase >> [ddir/]dbase-ibase.iext >> -o odir/output specified: default -dumpdir odir -dumpbase >> output-ibase.iext >> -o output specified: default -dumpbase output-ibase.iext >> -o a.out implied: default -dumpbase a.out-ibase.iext >> >> LTO recompiling: >> >> same as above, with each ibase.iext set to ltrans# >> >> >> In the compiler, set dump_base_name to: >> >> Given -dumpbase ddir/dbase: ddir/dbase >> otherwise, given -dumpdir ddir and -dumpbase dbase: ddir/dbase >> otherwise, given -dumpbase dbase: dbase >> >> and copy aux_base_name from dump_base_name, but if it ends in .iext, >> drop the extension. >> >> The resulting behavior (aux_base_name, dump_base_name) >> >> compiling without -o: (ibase, ibase.iext) unchanged >> ex $CC -c srcdir/foo.c srcdir/x/bar.c >> -> foo.o foo.su foo.c.#t.original >> + bar.o bar.su bar.c.#t.original >> >> compiling with -o: ([odir/]obase, [odir/]obase.iext) >> ex $CC -c srcdir/foo.c -o objdir/foobaz.o -Dfoobaz >> -> objdir/foobaz.o objdir/foobaz.su objdir/foobaz.c.#t.original >> >> compiling multiple sources with -dumpbase: ([ddir]/dbase, [ddir/]dbase) >> ex $CC -dumpbase outdir/runme.dump -c srcdir/foo.c srcdir/x/bar.c >> -> foo.o outdir/runme.dump-foo.su outdir/runme.dump-foo.c.#t.original >> + bar.o outdir/runme.dump-bar.su outdir/runme.dump-bar.c.#t.original >> >> compiling and linking with -o: (outdir/runme-ibase, >> outdir/runme-ibase.iext) >> ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c >> -> /tmp/temp().o outdir/runme-foo.su outdir/runme-foo.c.#t.original >> + /tmp/temp().o outdir/runme-bar.su outdir/runme-bar.c.#t.original >> + outdir/runme >> >> lto-recompiling and linking with -o: (outdir/runme.ltrans#, >> outdir/runme.ltrans#) >> ex $CC -o outdir/runme ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand >> -> /tmp/runme.temp().ltrans0.ltrans.o outdir/runme.ltrans0.su >> + outdir/runme.ltrans0.#r.expand >> + outdir/runme >> >> lto-recompiling and linking without -o: (a.out.ltrans#, a.out.ltrans#) >> ex $CC ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand >> -> /tmp/temp().ltrans0.ltrans.o a.out.ltrans0.su >> + a.out.ltrans0.#r.expand >> + a.out > > 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". > >> 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?)
If you're touching the -auxbase option... is that related to the other options starting with -aux at all? If so, bug 26613 might be related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613 > > Of course, others please feel free to comment (but let's not start > bikeshedding too much...). > > Thanks a lot! > Richard. >
