I was testing out LTO and found -fdump-tree-all did not work. I even made sure that -fdump-tree-all was added to the command line: /home/pinskia/lto-gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto1 -quiet -dumpbase lua.o -mtune=generic -auxbase-strip /tmp/ccMdUKXU.lto.o -O2 -Wall -version -fdump-tree-all @t.sh And it still does not work.
It works - look into /tmp. $ ./xgcc -B. -o t t.i -flto -fdump-tree-all $ ls /tmp/ ccJKyW5f.o.140t.optimized ccJKyW5f.o.221t.statistics you need to use -save-temps to get nice names here. It also works with your lto1 invocation which would dump in /tmp/lua.o. So, is your complaint that it dumps to /tmp or that it dumps with a cc*.o base if not using -save-temps?
Ok, this works but /tmp seems the wrong place for the dumps. pinskia@gcc13:~/src/lua-5.1.4/src$ !ls ls /tmp/*.[0-9][0-9][0-9]t.* /tmp/lua.o.057t.addressables
*** Bug 41708 has been marked as a duplicate of this bug. ***
One symptom is that (from PR41708) the dg-torture leaves behind dump files in /tmp: [hjl@gnu-26 tmp]$ ls cc* cc04uxjw.o.063t.alias ccij5SzB.o.063t.alias ccS3qzsd.o.063t.alias cc2agDxi.o.063t.alias ccIPR8Wx.o.063t.alias ccsaxP8c.wpa.o.063t.alias cc2P8Is7.o.063t.alias cck79Seb.wpa.o.063t.alias ccsLaryV.wpa.o.063t.alias ...
My /tmp is small so this causes it to be filled up quickly. Is there a simple work around?
Subject: Re: -fdump-tree-all for lto does not work as expected On Tue, 3 Nov 2009, pinskia at gcc dot gnu dot org wrote: > ------- Comment #5 from pinskia at gcc dot gnu dot org 2009-11-03 20:02 ------- > My /tmp is small so this causes it to be filled up quickly. Is there a simple > work around? No. Richard.
Subject: Re: -fdump-tree-all for lto does not work as expected Sent from my iPhone On Nov 4, 2009, at 1:32 AM, "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org > wrote: > > > ------- Comment #6 from rguenther at suse dot de 2009-11-04 09:32 > ------- > Subject: Re: -fdump-tree-all for lto does not work as > expected > > On Tue, 3 Nov 2009, pinskia at gcc dot gnu dot org wrote: > >> ------- Comment #5 from pinskia at gcc dot gnu dot org 2009-11-03 >> 20:02 ------- >> My /tmp is small so this causes it to be filled up quickly. Is >> there a simple >> work around? > > No. Actually thinking about it, setting TMPDIR env is a workaround :) > > Richard. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564 >
Since LTO tree dump is quite different, can't we give it a different command line option, something like -fdump-tree-lto-all, instead of enabling it with -fdump-tree-all?
Subject: Re: -fdump-tree-all for lto does not work as expected On Wed, 23 Dec 2009, hjl dot tools at gmail dot com wrote: > ------- Comment #8 from hjl dot tools at gmail dot com 2009-12-23 21:01 ------- > Since LTO tree dump is quite different, can't we give it a different > command line option, something like -fdump-tree-lto-all, instead of > enabling it with -fdump-tree-all? It isn't really different. This is a driver issue, the dumps use possibly temporary file names as bases. Richard.
(In reply to comment #9) > Subject: Re: -fdump-tree-all for lto does not work as > expected > > On Wed, 23 Dec 2009, hjl dot tools at gmail dot com wrote: > > > ------- Comment #8 from hjl dot tools at gmail dot com 2009-12-23 21:01 ------- > > Since LTO tree dump is quite different, can't we give it a different > > command line option, something like -fdump-tree-lto-all, instead of > > enabling it with -fdump-tree-all? > > It isn't really different. This is a driver issue, the dumps use > possibly temporary file names as bases. > By different, I meant that LTO tree dumps are in a different directory and have different file name suffix that the normal tree dumps. You can't easily tell which tree dumps in the temporary directory are the ones generated by -fdump-tree-all you just ran. It is even worse when -fdump-tree-all -flto is run a few times by the same or different person. I don't think -fdump-tree-all should dump LTO tree by default.
Subject: Re: -fdump-tree-all for lto does not work as expected On Wed, 30 Dec 2009, hjl dot tools at gmail dot com wrote: > ------- Comment #10 from hjl dot tools at gmail dot com 2009-12-30 23:27 ------- > (In reply to comment #9) > > Subject: Re: -fdump-tree-all for lto does not work as > > expected > > > > On Wed, 23 Dec 2009, hjl dot tools at gmail dot com wrote: > > > > > ------- Comment #8 from hjl dot tools at gmail dot com 2009-12-23 21:01 ------- > > > Since LTO tree dump is quite different, can't we give it a different > > > command line option, something like -fdump-tree-lto-all, instead of > > > enabling it with -fdump-tree-all? > > > > It isn't really different. This is a driver issue, the dumps use > > possibly temporary file names as bases. > > > > By different, I meant that LTO tree dumps are in a different directory > and have different file name suffix that the normal tree dumps. > > You can't easily tell which tree dumps in the temporary directory are > the ones generated by -fdump-tree-all you just ran. It is even worse when > -fdump-tree-all -flto is run a few times by the same or different person. > > I don't think -fdump-tree-all should dump LTO tree by default. I think that -flto should use the same temporary file names as -save-temps enabled compiles do. The only sane way to implement your suggestion would be to strip -fdump-* options for the lto1 invocations which would make debugging impossible. Richard.
Created attachment 19433 [details] A patch That is what I have in mind.
(In reply to comment #12) > Created an attachment (id=19433) [edit] > A patch > > That is what I have in mind. > My patch adds -fdump-lto-tree-XXX, which will be converted to -fdump-tree-XXX in LTO1. We can issue an error or ignore it if we aren't in LTO1.
What about -fdump-rtl-* and -fdump-ipa-*? They have the same problem. Note that this still wouldn't get what I would expect when doing gcc -flto -fdump-tree-all -O2 -o t t.c as you'd get a t.c.*.optimized tree dump that has nothing to do with what ends up in the executable. So I don't think the patch would be a strict improvement but instead it causes another confusion (not that the current situation is not confusing but at least it is known). I would like to see an idea how to address the dump-files-in-/tmp with tempfile names issue instead (I'd unconditionally use object file names as dumpbase as -save-temps or separating compiling and linking would do).
Created attachment 19442 [details] A patch 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 where to dump files.
Created attachment 19443 [details] A patch to fix a typo
Yeah, that looks like a good first step.
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00065.html
Subject: Bug 41564 Author: hjl Date: Sun Jan 3 17:03:38 2010 New Revision: 155591 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155591 Log: Pass -dumpbase and -dumpdir to gcc for LTO gcc/ 2010-01-03 H.J. Lu <hongjiu.lu@intel.com> PR lto/41564 * common.opt: Add dumpdir. * gcc.c (cc1_options): Add "-dumpbase %B" only if -dumpbase isn't specified. (option_map): Add --dumpdir. * gcc.h (DEFAULT_WORD_SWITCH_TAKES_ARG): Add dumpdir. * lto-wrapper.c (run_gcc): Add -dumpbase and -dumpdir for -o. * opts.c (decode_options): Try dump_dir_name first if dump_base_name isn't an absolute path. (common_handle_option): Handle OPT_dumpdir. * toplev.c (dump_dir_name): New. (print_switch_values): Also ignore -dumpdir. * toplev.h (dump_dir_name): New. gcc/lto/ 2010-01-03 H.J. Lu <hongjiu.lu@intel.com> PR lto/41564 * lto.c (DUMPBASE_SUFFIX): New. (lto_execute_ltrans): Append a sequence number to -dumpbase for LTRANS. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/gcc.c trunk/gcc/gcc.h trunk/gcc/lto-wrapper.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/opts.c trunk/gcc/toplev.c trunk/gcc/toplev.h
Fixed.