[Bug middle-end/32003] Undocumened -fdump-tree options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003 --- Comment #4 from Martin Sebor --- With most of the documentation for each option consisting of "the file name is made by appending .xxx to the source file name" I agree that in its current form and state of completion the documentation isn't very useful. I also suspect that providing descriptions for the currently undocumented options and saying much more than what's in the boilerplate blurb above is unlikely. I like the idea of providing a generic description instead, as long is it makes it easy to derive the option names. I had to figure out by trial and error that the name of the option controlling the Object Size Checking dumps is -fdump-tree-objsz (by using -fdump-tree-all, looking at the suffix of the two dump files, and appending it to -fdump-tree-). But after some experimenting and poking around in the manual I realize there's a better way to do it: 1) Run GCC with -fdump-passes and look for the pass code (e.g., objsz for Object Size Checking). 2) Append the pass code to the -fdump-tree- (or -fdump-rtl-) option to enable the dump. 3) Use the pass code to find the name of the dump file created by GCC for the pass (unless overridden). So maybe this would be sufficient documentation for all the options. The one thing missing is a description of what each of those passes actually does. For some it's fairly obvious but for others not so much. Maybe a brief description could be added to GCC's -fdump-passes output to help figure that out (e.g., under -fdump-passes=verbose if we want to keep the current output unchanged). How does this sound?
[Bug middle-end/32003] Undocumened -fdump-tree options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek ---
I don't see much value in documenting those. It seems to me that we should
simply document that the format is -fdump-{tree,ipa,rtl}-[-].
[Bug middle-end/32003] Undocumened -fdump-tree options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003 Martin Sebor changed: What|Removed |Added Last reconfirmed|2012-01-28 00:00:00 |2016-5-5 CC||msebor at gcc dot gnu.org Known to fail||4.3.0, 4.5.3, 4.8.3, 4.9.3, ||5.3.0, 6.1.0 --- Comment #2 from Martin Sebor --- The -fdump-tree-objsz is also undocumented. I tried to get a comprehensive list of all undocumented tree dumps. Here's what I came up with for GCC 6.1. It looks like the vast majority of them are, in fact, undocumented. ipa-afdo ipa-build_ssa_passes ipa-cdtor ipa-chkp_cleanup ipa-chkp_ecleanup ipa-chkp_passes ipa-chkp_versioning ipa-comdats ipa-cp ipa-devirt ipa-dispachercalls ipa-emutls ipa-free-inline-summary ipa-hsa ipa-icf ipa-increase_alignment ipa-inline ipa-ipa_oacc ipa-ipa_oacc_kernels ipa-opt_local_passes ipa-profile ipa-profile_estimate ipa-pta1 ipa-pure-const ipa-simdclone ipa-single-use ipa-static-var ipa-targetclone ipa-tmipa ipa-visibility ipa-whole-program statistics aprefetch asan0 asan1 bswap ccp1 cdce cddce1 ch1 chkp chkpopt ch_vect copyprop1 cplxlower0 cplxlower1 crited1 cselim cunroll cunrolli dce1 dom1 dse1 ealias early_optimizations eh ehcleanup1 ehdisp ehopt einline eipa_sra esra fab1 feedback_fnsplit fix_loops fixup_cfg1 fnsplit forwprop1 fre1 graphite graphite0 hsagen ifcombine ifcvt inline_param1 isolate-paths ivcanon ivopts laddress ldist lim1 local-pure-const1 loop loopdone loopinit lower lower_vaarg mergephi1 no_loop nothrow oacc_kernels objsz1 ompexp ompexpssa1 omplower omptargetlink parloops1 pcom phicprop1 phiopt1 phiprop profile_estimate reassoc1 recip release_ssa resx retslot sancov1 sancov_O0 sanopt sccp simduid1 sincos slp1 slsr split-paths stdarg strlen switchconv tailc tailr1 tmedge tmlower tmmark tmmemopt tracer tsan0 tsan1 ubsan uncprop1 uninit1 unswitch veclower veclower21 vrp1 vtable-verify widening_mul
[Bug middle-end/32003] Undocumened -fdump-tree options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||documentation
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-01-28
Component|driver |middle-end
Ever Confirmed|0 |1
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-28
02:56:50 UTC ---
{memsyms, TDF_MEMSYMS},
Is now just the same as vops.
stmtaddr just prints out the actually address of the gimple/tree.
Confirmed.
