[PR58479] introduce a param to limit debug stmts count

Mike Stump mikestump@comcast.net
Sat Mar 15 05:51:00 GMT 2014


On Mar 14, 2014, at 7:45 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> In some cases, the resulting executable code is none, but the debug stmts
> add up to millions.

I’d like to think there is a better theoretic answer to the specific problem…  trimming random debug info I think just invites a bad experience where people want to know what is going on and to them it just feels like a bad compiler that just randomly messed up debug info.  A user that wants faster compilation can refrain from using -g, or use -g1?

For example, if there truly is no code, removing all scopes that have no instruction between the start and the end along with all the debug info that goes with those scopes.  If there is one instruction, seems tome that it should be hard to have more than a few debug statements per instruction.  If there are more than 5, it would be curious to review each one and ask the question, is this useful and interesting?  I’d like to think there are entire classes of useless things that can be removed with no loss to the debug experience.


More information about the Gcc-patches mailing list