On Thu, 23 Jul 2020, Zhanghaijian (A) wrote:
> Hi,
>
>
>
> This is a simple fix for pr96230.
>
> When the dumpbase is an empty string, we should add check for !*dumpbase in
> process_command.
>
>
>
> The option -dumpbase "" is used gcc-defs.exp:
>
> # This option restores naming of aux and dump output files
>
> # after input files when multiple input files are named,
>
> # instead of getting them combined with the output name.
>
> lappend options "additional_flags=-dumpbase \"\""
>
>
>
> Bootstrap and tested on aarch64 and x86 Linux platform. No new regression
> witnessed.
>
> Any suggestion?
Does it actually do what the above comment suggests? I'd have
naiively assumed that for gcc -S t.c -fdump-tree-optimized -dumpbase ""
I get a ".238t.optimized" file (thus empty dumpbase).
Our docs state
An empty string specified as @var{dumpbase} avoids the influence of the
output basename in the naming of auxiliary and dump outputs during
compilation, computing default values :
@smallexample
gcc -c foo.c -o dir/foobar.o -dumpbase '' ...
@end smallexample
will name aux outputs @file{dir/foo.*} and dump outputs
@file{dir/foo.c.*}. Note how their basenames are taken from the input
name, but the directory still defaults to that of the output.
Alex?
Thanks,
Richard.
>
>
> Thanks,
>
> Haijian Zhang
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
