Bug 104180 - [11/12/13/14 Regression] '-fcompare-debug' failure (length) w/ -O1
Summary: [11/12/13/14 Regression] '-fcompare-debug' failure (length) w/ -O1
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 12.0
: P2 normal
Target Milestone: 11.5
Assignee: Not yet assigned to anyone
URL:
Keywords: compare-debug-failure
Depends on:
Blocks: gstatement-frontiers-compare-debug
  Show dependency treegraph
 
Reported: 2022-01-22 08:31 UTC by Arseny Solokha
Modified: 2023-07-07 10:42 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2022-01-22 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arseny Solokha 2022-01-22 08:31:36 UTC
g++ 12.0.0 20220109 snapshot (g:90045c5df5b3c8853e7740fb72a11aead1c489bb) fails -fcompare-debug check when compiling the following testcase, reduced from gcc/testsuite/gcc.dg/torture/pr89223.c, w/ -O1:

int a[5];

void
c ()
{
  unsigned int b;

  for (b = 3; ; b--)
    a[b] = ({ a[b + 1]; });
}

% g++-12.0.0 -O1 -fcompare-debug -c lluhupiv.c
g++-12.0.0: error: lluhupiv.c: '-fcompare-debug' failure (length)

--- lluhupiv.c.gkd	2022-01-22 15:27:16.168639041 +0700
+++ lluhupiv.gk.c.gkd	2022-01-22 15:27:16.239634334 +0700
@@ -33,7 +33,7 @@
      (nil))
 (insn # 0 0 3 (set (mem:SI (plus:DI (mult:DI (reg:DI 2 cx [orig:87 b ] [87])
                     (const_int 4 [0x4]))
-                (reg/f:DI 5 di [86])) [ a[b_3]+0 S4 A32])
+                (reg/f:DI 5 di [86])) [ MEM <int[5]> [(int *)&a][b_3]+0 S4 A32])
         (reg:SI 4 si [orig:82 _2 ] [82])) "lluhupiv.c":9:10# {*movsi_internal}
      (expr_list:REG_DEAD (reg:SI 4 si [orig:82 _2 ] [82])
         (expr_list:REG_DEAD (reg:DI 2 cx [orig:87 b ] [87])
Comment 1 Jakub Jelinek 2022-01-22 11:13:33 UTC
Started with r11-963-g80d6f89e78fc3b772701988cc73aa8e8006283be
which has been backported to 10.x in r10-8355-g7d919c33fbd29
Comment 2 Andrew Pinski 2022-01-22 12:06:53 UTC
[apinski@xeond2 src]$ diff -up t.cc.*original t.gk.cc.*original |less
--- t.cc.005t.original  2022-01-22 03:44:26.901343652 -0800
+++ t.gk.cc.005t.original       2022-01-22 03:44:27.005343663 -0800
@@ -6,13 +6,19 @@
 {
   unsigned int b;

+  # DEBUG BEGIN STMT;
     unsigned int b;
+  # DEBUG BEGIN STMT;
   <<cleanup_point <<< Unknown tree: expr_stmt
     (void) (b = 3) >>>>>;
   <D.2374>:;
+  # DEBUG BEGIN STMT;
   <<cleanup_point <<< Unknown tree: expr_stmt
-    (void) (a[b] = a[b + 1]) >>>>>;
+    (void) (a[b] = # DEBUG BEGIN STMT;
+    a[b + 1];) >>>>>;
+  # DEBUG BEGIN STMT;
   <<cleanup_point (void) b-- >>;
+  # DEBUG BEGIN STMT;
   goto <D.2374>;
 }



And then we gimplify:
+  # DEBUG BEGIN_STMT
+  # DEBUG BEGIN_STMT
   b = 3;
   <D.2374>:
-  _1 = b + 1;
-  _2 = a[_1];
-  a[b] = _2;
+  # DEBUG BEGIN_STMT
+  _1 = &a[b];
+  # DEBUG BEGIN_STMT
+  _2 = b + 1;
+  _3 = a[_2];
+  *_1 = _3;
+  # DEBUG BEGIN_STMT
   b = b + 4294967295;
+  # DEBUG BEGIN_STMT
   goto <D.2374>;
Comment 3 Andrew Pinski 2022-01-22 12:07:59 UTC
Similar in nature to PR 100733 and PR 103788.
Comment 4 Jakub Jelinek 2022-01-22 12:19:24 UTC
If it is because of -gstatement-frontiers, I've ran out of ideas how to fix them.
So unless Alexandre is willing to look at it, I'd suggest to at least turn -gstatement-frontiers off by default.
Comment 5 Richard Biener 2022-01-24 09:10:10 UTC
I think it's reasonable to turn them off (OTOH we then probably lose all test coverage).  IIRC gdb doensn't handle any of the advanced debug stuff GCC emits
(like views)?
Comment 6 Arseny Solokha 2022-01-24 09:30:50 UTC
Meanwhile, I've finally added -gno-statement-frontiers to my testing scripts.
Comment 7 Alexandre Oliva 2022-02-17 06:23:19 UTC
I've recommended before that, without any plan to implement consumers for this debug information, keeping it in place is mostly wasteful.  AFAICT other debug stmts issued by front-ends could hit the same issue, but those are only theoretical IIRC.  On the one hand, disabling the feature would hide the known problem that codegen is sensitive to such debug stmts, but on the other, we can cross that bridge if we get to it again.
Comment 8 Jakub Jelinek 2022-06-28 10:47:51 UTC
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
Comment 9 Richard Biener 2023-07-07 10:42:03 UTC
GCC 10 branch is being closed.