On Nov 7, 2019, Alexandre Oliva <ol...@adacore.com> wrote: > 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# > The resulting behavior (aux_base_name, dump_base_name) > 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 I've implemented this so that, even with a single source file, the executable name is prepended to the aux outputs in the case above. This causes thousands of testsuite failures, as dump files generated by tests that undergo linking were no longer found: since we compile foo.ext -o foo.exe, dumps end up named foo-foo.ext.* rather than foo.ext.*. Although it doesn't seem too hard to fix the testsuite logic, I'm a little hesitant at imposing this change onto such a common case that might hit other tools that use gcc underneath. I'm considering other alternatives, such as: 1. do not take the executable name into account when naming aux outputs of compilations, just like we do today. this makes aux outputs for the same input file overwrite each other. 2. do not take the executable name into account when there is a single input file. same problem as above 3. do not take the executable name into account when it shares the basename with an input file; combine executable basename with input name otherwise. this makes gcc -o foo[.exe] -g -gsplit-dwarf foo.c output foo.dwo rather than foo-foo.dwo, which is nice, but then dwo files compiled for use with foo won't all match foo-*.dwo; it seems more desirable that they all do 4. same as above, but only when there is only one input file, so that after adding bar.c to the command above, you'd get foo-foo.dwo and foo-bar.dwo 5. when there is a single input file, take the basename of the executable alone, rather than combine it with the basename of the input file, to name aux outputs, but still use the extension of the input file, so gcc -o foo foo.c will generate foo.dwo and foo.c.* dumps I dislike the asymmetry in 3., but I would be happy to implement any other, including the testsuite change to accommodate foo-foo.* dumps. Any preferences? Me, I'm leaning towards 5. -- 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);
