On Fri, Nov 19, 2021 at 10:38:41AM +0100, Richard Biener via Gcc-patches wrote:
> > Yup. Though there is a 1:1 equivalence right now, conceptually other
> > kinds of debug marker stmts, and of debug bind stmts, could be
> > introduced, and then the macros would be adjusted to encompass the new
> > functionality, covering presumably different options as well.
> >
> > By removing the macros, every use of the options would have to be
> > reassessed to tell whether it needs to be changed to cover the new
> > features, or left alone because it's really meant to refer to that
> > specific option.
> >
> > So I find the abstraction useful. However, I don't have plans to add
> > other kinds of debug stmts, and I don't know of anyone else who does, so
> > I won't stand in the way if others think removing these abstractions is
> > a positive change.
>
> Since the patch keeps some abstraction but not all I think we should
> keep them all for now.
Yeah, e.g. there has been discussions about deferring some warnings until
later so we omit less often false positives about dead code that we optimize
away, and one suggested approach was to represent those warnings as special
debug stmts. Those would appear in the IL regardless of the
-fvariable-tracking-assignments option, so MAY_HAVE_DEBUG_STMTS could
become
debug_nonbind_markers_p || flag_var_tracking_assignments ||
cfun->may_have_warnings
where the last one would be set if we emit any such warning stmts into the
IL.
Jakub
