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

H.J. Lu hjl.tools@gmail.com
Sun Jan 3 16:32:00 GMT 2010


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.

Thanks.


-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-pr41564-9.patch
Type: text/x-csrc
Size: 9059 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100103/009a3740/attachment.bin>


More information about the Gcc-patches mailing list