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

[Richard Guenther <richard dot guenther at gmail dot com>]

On Sun, Jan 3, 2010 at 5:32 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Jan 3, 2010 at 4:46 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Sun, Jan 3, 2010 at 12:37 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Sat, Jan 2, 2010 at 2:19 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Sat, Jan 2, 2010 at 12:03 PM, Richard Guenther
>>>> <richard.guenther@gmail.com> wrote:
>>>>> On Sat, Jan 2, 2010 at 8:06 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Sat, Jan 2, 2010 at 10:47 AM, Richard Guenther
>>>>>> <richard.guenther@gmail.com> wrote:
>>>>>>> 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).
>>>>>>>
>>>>>>
>>>>>> This patch should fix it.
>>>>>
>>>>> Thanks. ?And indeed with -fwhopr we now get
>>>>>
>>>>> $ ./xgcc -B. -o t t1.c t2.c -fwhopr -O -fdump-tree-optimized -v
>>>>> ...
>>>>> ?./lto1 -quiet -dumpbase ccNyDgHp.wpa.o -dumpbase t -dumpdir ./
>>>>> -mtune=generic -auxbase-strip /tmp/ccNyDgHp.wpa.ltrans.o -O -version
>>>>> -fdump-tree-optimized -fltrans /tmp/ccNyDgHp.wpa.o -o /tmp/ccIN6FT8.s
>>>>> ...
>>>>> ./lto1 -quiet -dumpbase ccif3J9z.wpa.o -dumpbase t -dumpdir ./
>>>>> -mtune=generic -auxbase-strip /tmp/ccif3J9z.wpa.ltrans.o -O -version
>>>>> -fdump-tree-optimized -fltrans /tmp/ccif3J9z.wpa.o -o /tmp/ccS2qVN9.s
>>>>>
>>>>> thus the dump-file of the first ltrans file gets overwritten by the second one.
>>>>> For ltrans we should append a sequence number to the -dumpbase, like
>>>>> t.ltrans0, t.ltrans1, etc. - also drop the redundant -dumpbase (that is also
>>>>> present in the -flto case).
>>>>
>>>> Here is the updated patch to remove the redundant -dumpbase. However,
>>>> I didn't try to handle dumpbase for WHOPR mode. I only pass ?-dumpbase
>>>> to gcc in LTO mode.. I would prefer to address LTO mode first and open
>>>> a new bug for dumpbase in WHOPR mode.
>>>>
>>>
>>> This patch appends a sequence number to the -dumpbase for LTRANS.
>>> OK for trunk?
>>
>> It doesn't work:
>>
>> $ ./xgcc -B. -o t t1.c t2.c -flto -O
>> lto1: error: could not open ELF file:
>> lto-wrapper: ././xgcc returned 1 exit status
>> collect2: lto-wrapper returned 1 exit status
>
> I can't reproduce it:
>
> [hjl@gnu-34 gcc]$ ls -l t.*.*
> ls: cannot access t.*.*: No such file or directory
> [hjl@gnu-34 gcc]$ ./xgcc -B. -o t t1.c t2.c -flto -O
> [hjl@gnu-34 gcc]$ ./xgcc -B. -o t t1.c t2.c -flto -O -fdump-tree-optimized
> [hjl@gnu-34 gcc]$ ls -l t.*.*
> -rw-rw-r-- 1 hjl hjl 171 2010-01-03 08:27 t.139t.optimized
> [hjl@gnu-34 gcc]$ rm -f t.*.*
> [hjl@gnu-34 gcc]$ ls -l t.*.*
> ls: cannot access t.*.*: No such file or directory
> [hjl@gnu-34 gcc]$ ./xgcc -B. -o t t1.c t2.c -fwhopr -O -fdump-tree-optimized
> [hjl@gnu-34 gcc]$ ls -l t.*.*
> -rw-rw-r-- 1 hjl hjl ?56 2010-01-03 08:27 t.trans0.139t.optimized
> -rw-rw-r-- 1 hjl hjl 115 2010-01-03 08:27 t.trans1.139t.optimized
> [hjl@gnu-34 gcc]$
>
> Here is the new patch to use decimal for sequence number. If it
> still fails for you, please help me reproduce it.

Ah, I forgot to re-build xgcc.  The patch seems to work for me.
It is ok if it passes bootstrap & regtest and if you change
the LTRANS suffix to .ltrans (compared to .trans).

Thanks for fixing this!
Richard.

> Thanks.
>
>
> --
> H.J.
>