This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setting a breakpoint on a break statement


Tristan Gingold <gingold@adacore.com> writes:

> > I don't think it is appropriate to change the meaning of
> > forwarder_block_p.  And I'm not sure why you need that patch anyhow,
> > considering the existing code in cleanup_tree_cfg_1.
> Without that change, the rtl jump pass cleans the jump and all the
> previous work is useless.

I see.  Then I think we shoulid tweak the RTL jump pass along the
lines of cleanup_tree_cfg_1.  A function like forwarder_block_p is
conceptually easy to understand.  It becomes harder to understand if
it turns into forwarder_block_when_optimizing_p.

> > Also you should ideally add a test case.
> The effects are only visible for the debugger.  How to write a
> compiler test case for this case ?

For tree level changes, you do it by grepping the dump file.  See many
of the test cases in testsuite/gcc.dg/tree-ssa, and their use of
scan-tree-dump.

For RTL level changes, the dump files are harder to interpret.  But
maybe you could do it by compiling with -gdwarf-2 and looking for a
.loc pseudo-op with the right value in the assembler file (using
scan-assembler).  I don't know if that would really work but it seems
feasible at first glance.  My concern, of course, is that this kind of
change is fragile, and we want to make sure that it does not break
accidentally.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]