I noticed there are a couple of dump_printf_loc instances in coverage.c not ended with newline. They should be fixed.
David On Tue, Sep 10, 2013 at 6:32 AM, Teresa Johnson <tejohn...@google.com> wrote: > On Mon, Sep 9, 2013 at 9:55 PM, Xinliang David Li <davi...@google.com> wrote: >> looks fine to me. >> >> In the long run, I wonder if the machinery in diagnostic messages can >> be reused for opt-info dumping -- i.e., support different streams. It >> has many nice features including %qD specifier for printing tree >> decls. > > Yes, this would have some advantages such as getting the function name > emitted. > > Teresa > >> >> David >> >> On Mon, Sep 9, 2013 at 12:01 PM, Teresa Johnson <tejohn...@google.com> wrote: >>> I've attached a patch that implements the cleanup of newline emission >>> by the new dump framework as discussed here: >>> >>> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01779.html >>> >>> Essentially, I have removed the leading newline emission from >>> dump_loc, and updated dump_printf_loc invocations to emit a trailing >>> newline as necessary. This will remove unnecessary vertical space in >>> the dump output. >>> >>> I did not do any other cleanup of the existing vectorization messages >>> - there are IMO a lot of messages being emitted by the vectorizer >>> under MSG_NOTE (and probably MSG_MISSED_OPTIMIZATION) that should only >>> be emitted to the dump file under -fdump-tree-... and not emitted >>> under -fopt-info-all. The ones that stay under -fopt-info-all need >>> some formatting/style cleanup. Leaving that for follow-on work. >>> >>> Bootstrapped and tested on x86-64-unknown-linux-gnu. Ok for trunk? >>> >>> Thanks, >>> Teresa >>> >>> -- >>> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413 > > > > -- > Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
