On Thu, Aug 29, 2013 at 3:05 AM, Richard Biener <richard.guent...@gmail.com> wrote: >>>> Does >>>> 'make newlines consitent' avoid all the spurious vertical spacing I see >>>> with >>>> -fopt-info? >>> >>> Well, it helps get us there. The problem was that before, since >>> dump_loc was not consistently emitting newlines, the calls had to emit >>> their own newlines manually in the string to ensure there was a >>> newline at all. I was thinking that once this is fixed I could go back >>> and clean up all those calls by removing the newlines in the string. I >>> could split this part into a separate patch and do both at once. >>> >>> However, after thinking about this some more this morning, I am >>> wondering whether it is better to remove the newline emission >>> completely from dump_loc and rely on the caller to put the newline in >>> the string. The reason is that there are 2 high level interfaces to >>> the new dump infrastructure, dump_printf() and dump_printf_loc(). Only >>> the latter invokes dump_loc and gets the newline at the start of the >>> message. The typical usage seems to be to start a message via >>> dump_printf_loc, and then use dump_printf to emit parts of the message >>> (thus not requiring a newline), but I think it may lead to problems to >>> rely on this assumption. >>> >>> So if you agree, I will simply remove the newline altogether from >>> dump_loc, and ensure that all clients of dump_printf/dump_printf_loc >>> include a newline char as appropriate in the string they pass. >> >> >> As a helper function, dump_loc should not blindly emit new line as it >> has no context. I have tried to remove it, and push the newline to >> higher level helpers -- it mostly works, but the vectorizer verbose >> messages need serious clean up -- most of them assume that >> dump_printf_loc does not end with new line, so that the expression >> dump can follow in the same line (the message texts need clean up too >> -- i do not like the === === in info messages). > > I know, but we should really do that cleanup.
I can work on this and will send a separate patch. Teresa -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413