Re: setting a breakpoint on a break statement
On Mar 14, 2007, at 3:16 PM, Ian Lance Taylor wrote: Tristan Gingold [EMAIL PROTECTED] writes: in some cases, a breakpoint can't be set on a continue or break statement. Here is a simple example: The reason is quiet simple: even at -O0 -g, there is no insn (and no BB) corresponding to the break/continue statement. Here is a small patch which fixes the issue. I wonder if this is the right approach. This patch makes the code generated at -O0 uglier... Thanks for sending the patch. Procedural note: patches should be sent to [EMAIL PROTECTED], and should have a ChangeLog entry. Thank you for the procedure. I will follow it when I submit the patch formally 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. 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 ? Thanks, Tristan.
Re: setting a breakpoint on a break statement
Tristan Gingold [EMAIL PROTECTED] 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
Re: setting a breakpoint on a break statement
Tristan Gingold [EMAIL PROTECTED] writes: in some cases, a breakpoint can't be set on a continue or break statement. Here is a simple example: The reason is quiet simple: even at -O0 -g, there is no insn (and no BB) corresponding to the break/continue statement. Here is a small patch which fixes the issue. I wonder if this is the right approach. This patch makes the code generated at -O0 uglier... Thanks for sending the patch. Procedural note: patches should be sent to [EMAIL PROTECTED], and should have a ChangeLog entry. 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. Also you should ideally add a test case. Thanks. Ian
Re: setting a breakpoint on a break statement
On 3/14/07, Tristan Gingold [EMAIL PROTECTED] wrote: Hi, in some cases, a breakpoint can't be set on a continue or break statement. Here is a simple example: I think this is also related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609 Yes, yes I have the whole bugzilla memorized. :) -- Pinski
