[Bug debug/42631] New: "-fcompare-debug failure" with "-O1 -funroll-loops"

[Bug debug/42631] New: "-fcompare-debug failure" with "-O1 -funroll-loops"

[zsojka at seznam dot cz]

Command line:
gcc -O1 -funroll-loops -fcompare-debug -c testcase.c

Tested revisions:
r155643 - crash (x86_64)
r155290 - crash (x86)
r153685 - crash (x86_64)

Output:
$ /mnt/svn/gcc-trunk/binary-153685-lto/bin/gcc -O1 -funroll-loops
-fcompare-debug -c testcase.c
gcc: testcase.c: -fcompare-debug failure

================== testcase.c ==================
void foo()
{
  unsigned k; /* doesn't crash with 'int' or when initialized */
  while (--k > 0);
}
================================================


-- 
           Summary: "-fcompare-debug failure" with "-O1 -funroll-loops"
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86(_64)-pc-linux-gnu
GCC target triplet: x86(_64)-pc-linux-gnu


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-06 12:00 -------
Confirmed.  We have regno differences.

-(insn# 0 0 t.c:4 (set (reg/v:SI 0 ax [orig:67 k ] [67])
+(insn# 0 0 t.c:4 (set (reg/v:SI 0 ax [orig:68 k ] [68])

works ok with -fno-var-tracking-assignments.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
          Component|debug                       |rtl-optimization
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-01-06 12:00:18
               date|                            |
            Summary|"-fcompare-debug failure"   |[4.5 Regression] "-fcompare-
                   |with "-O1 -funroll-loops"   |debug failure" with "-O1 -
                   |                            |funroll-loops"
   Target Milestone|---                         |4.5.0


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-01-06 12:00:18         |2010-01-06 12:33:14
               date|                            |


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[steven at gcc dot gnu dot org]

------- Comment #2 from steven at gcc dot gnu dot org  2010-01-06 23:48 -------
Works with -fno-web.


-- 


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[steven at gcc dot gnu dot org]

------- Comment #3 from steven at gcc dot gnu dot org  2010-01-06 23:53 -------
In the .loop2_done dump, the RTL looks like this:

    7 NOTE_INSN_BASIC_BLOCK
    6 NOTE_INSN_FUNCTION_BEG
   22 {r63:SI=r62:SI-0x1;clobber flags:CC;}
   23 {r64:SI=r63:SI&0x7;clobber flags:CC;}
   26: debug k => r62:SI
   27 {r62:SI=r62:SI-0x1;clobber flags:CC;}
      REG_UNUSED: flags:CC
   28: debug k => r62:SI
   29 flags:CCZ=cmp(r62:SI,0x0)
   30 pc={(flags:CCZ!=0x0)?L225:pc}
      REG_BR_PROB: 0x2198
      REG_DEAD: flags:CCZ


And in the .web dump, the registers have been renamed:

    7 NOTE_INSN_BASIC_BLOCK
    6 NOTE_INSN_FUNCTION_BEG
   22 {r63:SI=r62:SI-0x1;clobber flags:CC;}
   23 {r64:SI=r63:SI&0x7;clobber flags:CC;}
   26: debug k => r66:SI
   27 {r68:SI=r67:SI-0x1;clobber flags:CC;}
      REG_UNUSED: flags:CC
   28: debug k => r68:SI
   29 flags:CCZ=cmp(r68:SI,0x0)
   30 pc={(flags:CCZ!=0x0)?L225:pc}
      REG_BR_PROB: 0x2198
      REG_DEAD: flags:CCZ


Note the changes in insn 26 and insn 27. The use of reg 62 in debug_insn 26 is
put in its own web, because the webizer hasn't found a DEF for it -- so it
splits the live ranges of reg 62 into a single live range for the debug_insn
and a new live range for the def of insn 27 and all uses reached by this def.

Alexandre, does the position of debug_insn 26 look right to you?


-- 


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[aoliva at gcc dot gnu dot org]

------- Comment #4 from aoliva at gcc dot gnu dot org  2010-01-07 13:53 -------
Yeah, it surprised me a bit too, but now that I looked into it I see it makes
perfect sense.  There was a PHI node before the debug stmt that expanded into
this debug insn.  The variable is indeed live at that location, even though in
the first loop iteration it won't have been initialized yet.  So the note is
absolutely correct, and we somehow have to deal with it.


-- 


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[steven at gcc dot gnu dot org]

------- Comment #5 from steven at gcc dot gnu dot org  2010-01-07 19:54 -------
Makes no sense to me => unassigned.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[aoliva at gcc dot gnu dot org]

------- Comment #6 from aoliva at gcc dot gnu dot org  2010-01-07 20:44 -------
Mine


-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[aoliva at gcc dot gnu dot org]

------- Comment #7 from aoliva at gcc dot gnu dot org  2010-01-08 01:01 -------
The interesting question to ask is *why* web regards three different uses of
the same uninitialized pseudo as different webs.  That's what doesn't make
sense to me.  Apparently DF avoids dealing with uninitialized variables while
constructing UD chains.  If this was improved (say, creating an artificial def
for the uninitialized pseudo), this symptom (the -fcompare-debug failure) would
be automatically fixed.  However, I can come up with a kludge for web, such as
special-casing uninitialized uses in debug insns or so.  Thoughts?


-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven at gcc dot gnu dot
                   |                            |org


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[aoliva at gcc dot gnu dot org]

------- Comment #8 from aoliva at gcc dot gnu dot org  2010-01-08 01:27 -------
Kenny, you think we should fix DF to create artificial defs for uninitialized
vars, or use some kludge in web to avoid creating one web per uninitialized
use?


-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zadeck at naturalbridge dot
                   |                            |com


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[zadeck at naturalbridge dot com]

------- Comment #9 from zadeck at naturalbridge dot com  2010-01-08 01:56 -------
Alexandre, 
i am surprised that we have gotten this far and never seen this kind of
failure. 
I had actually thought that there were earlier passes that added
initialization.  If that is true, then the real question is why did they fail
to make this go away earlier.    

on the other hand, if there is nothing to resolve these earlier, then i guess
we need to fix it up here.   But again, i am surprised that this is the first
time we have seen this problem.  


-- 


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[aoliva at gcc dot gnu dot org]

------- Comment #10 from aoliva at gcc dot gnu dot org  2010-01-08 02:43 -------
Well, it's not like accessing an uninitialized variable is well-defined, so
it's not like our splitting into multiple webs is wrong, or could possibly
generate incorrect results.  The only reason we notice this is that it gets us
different results precisely for a test framework designed to be picky about
minute differences, even if in the end they don't make any difference in terms
of program behavior.

Just to be clear, although the references were *originally* part of a loop,
when the loop was unrolled, the failing bits became part of an pre-loop block,
so there's nothing that could actually fail here in terms of codegen, AFAICT.


-- 


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[zadeck at naturalbridge dot com]

------- Comment #11 from zadeck at naturalbridge dot com  2010-01-08 03:52 -------
I really do not know what to say here.  There is a first do no harm principal
here.   it does not sound like this is really a bug and i do not think that
mucking with the compiler to make a test on a program that has undefined
behavior is really the right thing to do.    

this really is not so much a df question as a question for what kinds of
behavior are we going to consider to be "correct".

kenny


-- 


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[aoliva at gcc dot gnu dot org]

------- Comment #12 from aoliva at gcc dot gnu dot org  2010-01-08 05:27 -------
It is a bug.  The compiler shouldn't generate different code depending on -g,
and that's what's (potentially) going on here.  That the code is undefined per
a language standard shouldn't take precedence over a more general design
principle in GCC: we should still emit the same code, crash or exhibit
otherwise undefined behavior in just the same way.  Surely you wouldn't like to
have a surprise such as finding out the crash or the bug you're hunting
disappears when you recompile the program with -g, would you?  That's the kind
of bug that -fcompare-debug is designed to catch, and that's what it just did. 
Now, since leaving the bug in *would* do harm (as above), the question is
whether to fix it in DF or in web.  I'm ambivalent, but I'd rather not put time
into either one if it's going to be rejected in favor of the other.


-- 


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[aoliva at gcc dot gnu dot org]

------- Comment #13 from aoliva at gcc dot gnu dot org  2010-01-09 14:42 -------
Subject: Bug 42631

Author: aoliva
Date: Sat Jan  9 14:41:51 2010
New Revision: 155765

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155765
Log:
gcc/ChangeLog:
PR debug/42631
* web.c (union_defs): Add used argument, to combine uses of
uninitialized regs.
(entry_register): Adjust type and tests of used argument.
(web_main): Widen used for new use.  Pass it to union_defs.
* df.h (union_defs): Adjust prototype.
gcc/testsuite/ChangeLog:
PR debug/42631
* gcc.dg/pr42631.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/pr42631.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/df.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/web.c


-- 


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

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[aoliva at gcc dot gnu dot org]

------- Comment #14 from aoliva at gcc dot gnu dot org  2010-01-09 14:50 -------
Fixed


-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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