[Bug debug/43222] two DEBUG i = 0 generated after loop copy header

2010-06-11 Thread aoliva at gcc dot gnu dot org


--- Comment #7 from aoliva at gcc dot gnu dot org  2010-06-11 11:45 ---
Not a bug


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222



[Bug debug/43222] two DEBUG i = 0 generated after loop copy header

2010-06-02 Thread aoliva at gcc dot gnu dot org


--- Comment #6 from aoliva at gcc dot gnu dot org  2010-06-02 06:28 ---
Andrew, the debug stmts are indeed originally from the loop header's PHI nodes.
Before ch we have:

i_1 = init;
# i = i_1
goto header;

body:
i_3 = whatever(i_2);
# i = i_3

header:
i_2 = PHI i_1, i_3;
# i = i_2
if (cond) goto body; else goto exit;

copy_loop_header turns this into:

i_1 = init;
# i = i_1

copy:
i_4 = PHI i_1;
# i = i_4
if (cond) goto body; else goto exit;

body:
i_3 = whatever(i_2);
# i = i_3

header:
i_2 = PHI i_3;
# i = i_2
if (cond) goto body; else goto exit;

and that's correct.  Then cfgcleanup realizes the headers can be merged with
their preds, and that kills the PHI nodes, but there's no reason why this
should kill the debug stmts.

Of course we could arrange for some cleanup passes to detect and remove debug
stmts in case they become redundant, but I don't see that we have a bug here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222



[Bug debug/43222] two DEBUG i = 0 generated after loop copy header

2010-03-02 Thread jakub at gcc dot gnu dot org


--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-02 11:12 ---
The extra DEBUG stmts or DEBUG_INSNs only consume memory, they shouldn't affect
debug info generation, though perhaps it wouldn't hurt once or twice during
gimple optimizations and once or twice during RTL optimizations to get rid of
redundant DEBUG stmts resp. DEBUG_INSNs (where redundant is one where for the
same variable there is another DEBUG stmt or DEBUG_INSN after it not separated
by any real statements or insns/labels.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222



[Bug debug/43222] two DEBUG i = 0 generated after loop copy header

2010-03-01 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2010-03-01 23:05 ---
And there are actually two duplicated debug statements.  One for the i = 0 and
then one for i = i_11


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222



[Bug debug/43222] two DEBUG i = 0 generated after loop copy header

2010-03-01 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2010-03-01 23:14 ---
Here is a simplier testcase which shows the problem is even worse:
int gif_read_lzw(int input_code_size)
{
  int i;
  short code_size = 0;
  for (i = 0; i  input_code_size; i ++)
code_size ++;

  return code_size;
}

--- CUT ---
We have now 8 debug statements after loop copy header when we really only need
4 (2 before the loop and 2 inside the loop).  Why are we duplicating already
emitted debug statements?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222



[Bug debug/43222] two DEBUG i = 0 generated after loop copy header

2010-03-01 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2010-03-01 23:20 ---
And nothing removes the duplicated debug statements that are outside the loop
until rtl dce comes around.  And it removes the debug statements which had line
information too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222



[Bug debug/43222] two DEBUG i = 0 generated after loop copy header

2010-03-01 Thread jakub at gcc dot gnu dot org


--- Comment #4 from jakub at gcc dot gnu dot org  2010-03-02 07:54 ---
Line info on debug stmts/DEBUG_INSNs is ignored.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222