RFC: PR lto/41564: -fdump-tree-all for lto does not work as expected

[Richard Guenther]

On Sat, Jan 2, 2010 at 7:17 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sat, Jan 2, 2010 at 10:05 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Sat, Jan 2, 2010 at 9:18 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Sat, Jan 2, 2010 at 6:05 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>>>> Hi,
>>>>
>>>> When -fdump-tree-all is used with lto, the dump files are generated in
>>>> /tmp instead of the directory containing the output. The problem is
>>>> lto-wrapper translates
>>>>
>>>> /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -o gcc-dg-lto-20081222-31 -fdump-tree-all -v -mtune=generic c_lto_20081222_0.o c_lto_20081222_1.o
>>>>
>>>> to
>>>>
>>>> /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -combine -x lto -c -o /tmp/cclzoEg3.lto.o -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 --fdump-tree-all -mtune=generic c_lto_20081222_0.o c_lto_20081222_1.o
>>>>
>>>> There is no good way to tell which directory should be used for dump.
>>>> This patch adds -dumpdir. lto-wrapper uses it to tell lto1 to dump
>>>> files in the output directory.
>>>>
>>>> Any comments?
>>>
>>> What -dumpbase will lto1 use if compile and link step are combined?
>>> Otherwise I think it's the right thing to do to dump where regular dump
>>> files would be.
>>
>> The gcc driver uses the first input .o file for -dumpbase, which is
>> some random generated out file. Maybe we should use the LTO
>> output name for -dumpbase.
>
>
> This patch on top of my previous patch does it. It will make
> dumpbase consistent no matter how lto1 is used. Should I
> incorporate it into my patch for PR 41564?

I get

$ ./xgcc -B. -c t1.c t2.c -flto -O -fdump-tree-optimized
$ ./xgcc -B. -o t t1.o t2.o -flto -O -fdump-tree-optimized
collect2: lto-wrapper terminated with signal 11 [Segmentation fault]

same with

$ ./xgcc -B. -o t t1.o t2.o -flto -O -fdump-tree-optimized
collect2: lto-wrapper terminated with signal 11 [Segmentation fault]

but yes, I think it should be combined into the fix for PR41564.
I wanted to test what happens with -fwhopr as well (well, it segfaults
like above).

Thanks,
Richard.

> Thanks.
>
>
> --
> H.J.
> ---
> diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
> index 97cd368..f07c5ff 100644
> --- a/gcc/lto-wrapper.c
> +++ b/gcc/lto-wrapper.c
> @@ -258,7 +258,7 @@ run_gcc (unsigned argc, char *argv[])
>   const char **argv_ptr;
>   char *list_option_full = NULL;
>
> -  new_argc += 10;
> +  new_argc += 12;
>   new_argv = (const char **) xcalloc (sizeof (char *), new_argc);
>
>   argv_ptr = new_argv;
> @@ -336,6 +336,9 @@ run_gcc (unsigned argc, char *argv[])
>
>              *argv_ptr++ = "-dumpdir";
>              *argv_ptr++ = output_dir;
> +
> +             *argv_ptr++ = "-dumpbase";
> +             *argv_ptr++ = &argv[i][base - output_dir];
>            }
>        }
>       else
>