On Jan 3, 2014, at 8:52, [email protected] wrote: > > Are there any flags that control the debug info =93level=94 other than vt= > able > > optimization and -flimit-debug-info? > > > > None that spring immediately to my mind. > > > > I think it would make sense to keep the -flimit-debug-info name as the > > umbrella flag name; > > > While I realize I disagreed with you about this earlier in the thread, I've > mostly come around here, in the sense that I hope most users using this > flag are using it because what they really want is "I'm compiling part of > my project with debug info enabled and can't rely on other compile units to > have debug info". > > Though there's probably some users with -fno-limit-debug-info because it > was broken... > > > > it=92s a generic term and our users are already vaguely familiar with it. > > > I think it's too generic and our users may only be familiar with it when it > hurt them, without knowing why (without knowing whether it was a bug, for > example). > > > > On top of that, before last week, we didn=92t even bother documenting wha= > t > > the flag does exactly anyway, so there is little harm in changing its > > semantics to cover additional fine-grained flags. > > > > Mostly agree. > > > > Then we could introduce a more descriptive name for what used to be > > -flimit-debug-info, e.g., -fno-forward-decl-debug-types (better suggestio= > ns > > are welcome) > > > > 1) -flimit-debug-info > > > > I'd still be inclined to introduce a better name for -flimit-debug-info as > an alias that we document going forward. Possibly in the affirmative > "-fstandalone-debug" (ie: emit all the relevant debug info as if this > translation unit were standalone/had no reliance on other object files). > Open to other names. Or perhaps this is the right place to reuse GCC's > -femit-class-debug-always?
I really like the -fstandalone-debug name as an umbrella. > > Personally I'm OK stopping there and not providing fine-grained access to > the two separate optimizations until we have a use-case. > > If someone really wants subflags (Chandler mentioned a preference, but I > assume it's not binding/authoritative) I'm happy to bikeshed their names. > I’m all for avoiding the bikeshedding, so let’s revisit that when we find a use-case. > -femit-class-debug-on-complete-types ? I don't know - it'll be verbose no > matter how we phrase it. > > -femit-class-debug-on-dynamic-types > > > > | > > +- -fno-forward-decl-debug-types (the old limit-debug-info) > > | > > +- -fno-emit-class-debug-always (the new flag) > > > > Eric mentioned that on a cursory inspection of GCC, this flag controlled > other things as well as the vtable optimization and he might not be > comfortable using that name while not implementing the same semantics as > GCC. > That is fine with me. We could introduce -fstandalone-debug as a new alias to -fno-limit-debug-info and make the vtable optimization contingent on debug level being =< standalone (née limited), and make -flimit-debug-info into a hidden backwards compatibility option and document -fstandalone-debug in the manpage and online help. Would that work for you? -- adrian > > > > > If we don=92t want to change the meaning of limited debug info, we could = > have > > > > 2) -fpartial-debug-info (a new umbrella flag) > > | > > +- -flimit-debug-info (unchanged) > > | > > +- -fno-emit-class-debug-always (idem) > > > > I=92m leaning slightly towards option 1. > > > > > (though we could probably do an analysis on -flimit-debug-info and see > > what > > > the size win really is since it's been fixed - maybe it's not even wort= > h > > > keeping and we could just make the flag a no-op instead) > > Did I hear somebody volunteering? > > > > Possibly, at some point. > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
