Bug 42685 - [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops" (2)
Summary: [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops" (2)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.5.0
: P1 normal
Target Milestone: 4.5.0
Assignee: Richard Biener
URL:
Keywords: compare-debug-failure
: 42642 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-01-10 23:31 UTC by Zdenek Sojka
Modified: 2022-01-18 23:30 UTC (History)
3 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-01-26 15:15:08


Attachments
reduced testcase (100 bytes, text/plain)
2010-01-10 23:33 UTC, Zdenek Sojka
Details
different reduced testcase (162 bytes, text/plain)
2010-01-12 18:08 UTC, Zdenek Sojka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zdenek Sojka 2010-01-10 23:31:48 UTC
Command line:
g++ -O1 -fcompare-debug -funroll-loops -c testcase.cpp
-fno-web helps even in the nonreduced testcase

Tested revisions:
r155777 - crash
r155680 - crash
r154830 - crash
r153685 - crash

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

Valgrind:
no errors reported
Comment 1 Zdenek Sojka 2010-01-10 23:33:26 UTC
Created attachment 19534 [details]
reduced testcase

Command line:
g++ -O1 -fcompare-debug -funroll-loops -c pr42685.cpp
Comment 2 Zdenek Sojka 2010-01-10 23:41:21 UTC
Could be related to pr42642
Comment 3 Zdenek Sojka 2010-01-12 18:08:46 UTC
Created attachment 19566 [details]
different reduced testcase

I don't know if it's the same problem, but fails with the same flags.

$ gcc -O1 -fcompare-debug -funroll-loops -c pr42685-2.c
gcc: pr42685-2.c: -fcompare-debug failure
Comment 4 Steven Bosscher 2010-01-18 17:00:13 UTC
This still fails, even with Alexandre's patch for bug 42631.

With -fno-web the failure disappears. So this is probably another issue in the webizer.

Investigating -> mine for now.
Comment 5 Steven Bosscher 2010-01-18 19:16:55 UTC
Register number differences appear - again - because a USE operand of a DEBUG_INSN ends up in a web of its own:

--- R1web/pr42685-2.c.167r.web  2010-01-18 11:11:38.000000000 -0800
+++ R2web/pr42685-2.c.167r.web  2010-01-18 11:11:38.000000000 -0800
@@ -7,275 +7,323 @@
 df_worklist_dataflow_doublequeue:n_basic_blocks 55 n_edges 83 count 108 (    2)
 df_worklist_dataflow_doublequeue:n_basic_blocks 55 n_edges 83 count 109 (    2)
 Web oldreg=386 newreg=401
-Updating insn 82 (386->401)
-deferring rescan insn with uid = 82.
-Web oldreg=371 newreg=402
-Updating insn 63 (371->402)
-deferring rescan insn with uid = 63.
-Web oldreg=375 newreg=403
-Updating insn 394 (375->403)
-deferring rescan insn with uid = 394.
+Updating insn 96 (386->401)
+deferring rescan insn with uid = 96.
+Web oldreg=375 newreg=402
+Updating insn 72 (375->402)
+deferring rescan insn with uid = 72.
+Web oldreg=371 newreg=403
+Updating insn 75 (371->403)
+deferring rescan insn with uid = 75.
+Updating insn 468 (375->402)
+deferring rescan insn with uid = 468.

...

@@ -413,12 +474,19 @@
             (label_ref #)
             (pc)))# {*br_true} (expr_list:REG_BR_PROB (const_int 7100 [0x1bbc])
         (nil))
- -> 65)
+ -> 77)

 (note# # # 10 [bb 10] NOTE_INSN_BASIC_BLOCK)

+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI D#2 (zero_extend:DI (reg/v:SI 402 [ i ])))# (nil))
+
+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI D#1 (mult:DI (debug_expr:DI D#2)
+        (const_int 4 [0x4])))# (nil))
+
+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI s (clobber (const_int 0 [0x0])))# (nil))
+
 (insn# # # 10 pr42685-2.c:10 (set (reg:SI 120 out0)
-        (mem/s/j:SI (reg:DI 402 [ ivtmp.5 ]) [0 D.1998->i+0 S4 A32]))# {movsi_internal} (nil))
+        (mem/s/j:SI (reg:DI 403 [ ivtmp.5 ]) [0 D.1998->i+0 S4 A32]))# {movsi_internal} (nil))

 (call_insn# # # 10 pr42685-2.c:10 (parallel [
             (call (mem:DI (symbol_ref:DI ("baz") [flags 0x41]  <function_decl # baz>) [0 S8 A64])


This whole compare-debug stuff makes no sense to me, so I'm not even going to try to come up with a fix. IMHO the proper fix would be to never even try to rename a web that consists of just a single USE. I don't see how that is any more "right" than no debug info at all since no DEF reaches the USE (i.e. uninitialized) so any value represented in the debug info is fair and reasonable.
Comment 6 Steven Bosscher 2010-01-18 19:19:07 UTC
*** Bug 42642 has been marked as a duplicate of this bug. ***
Comment 7 Richard Biener 2010-01-26 15:15:08 UTC
I have an extremely lame patch that fixes both testcases.  s/INSN_P/NONDEBUG_INSN_P/
Comment 8 Richard Biener 2010-01-26 16:27:48 UTC
Fixed.
Comment 9 Richard Biener 2010-01-26 16:27:56 UTC
Subject: Bug 42685

Author: rguenth
Date: Tue Jan 26 16:27:34 2010
New Revision: 156252

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156252
Log:
2010-01-26  Richard Guenther  <rguenther@suse.de>

	PR rtl-optimization/42685
	* web.c (web_main): Ignore DEBUG_INSNs.

	* gcc.dg/pr42685.c: New testcase.
	* g++.dg/other/pr42685.C: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/other/pr42685.C
    trunk/gcc/testsuite/gcc.dg/pr42685.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/web.c