[Bug debug/105415] New: [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2

[Bug debug/105415] New: [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

            Bug ID: 105415
           Summary: [10/11/12 Regression] '-fcompare-debug' failure w/ -O2
                    -ftree-parallelize-loops=2
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: compare-debug-failure
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: aarch64-linux-gnu

gcc 12.0.1 20220424 snapshot (g:6b7441a46c771aa6ecdc0c8ed96197417d036b9a) fails
-fcompare-debug check when compiling the following testcase w/ -O2
-ftree-parallelize-loops=2:

int m;
static int n;

void
foo (void)
{
  int s = 0;

  while (m < 1)
    {
      s += n;
      ++m;
    }
}

void
bar (int *arr, int i)
{
  while (i < 1)
    arr[i++] = 1;
}

% aarch64-linux-gnu-gcc-12.0.1 -O2 -fcompare-debug -ftree-parallelize-loops=2
-c plkjnne3.c
aarch64-linux-gnu-gcc-12.0.1: error: plkjnne3.c: '-fcompare-debug' failure

--- plkjnne3.c.gkd      2022-04-28 09:43:03.113041561 +0700
+++ plkjnne3.gk.c.gkd   2022-04-28 09:43:03.148041580 +0700
@@ -388,7 +388,7 @@
 1:   int i;
 2:   signed int D.xxxx;

-;; Function bar._loopfn.0 (bar._loopfn.0, funcdef_no=2, cgraph_uid=3,
symbol_order=4)
+;; Function bar._loopfn.0 (bar._loopfn.0, funcdef_no=2, cgraph_uid=3,
symbol_order=5)

 (note # 0 0 NOTE_INSN_DELETED)
 (note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)

[Bug debug/105415] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.4

[Bug debug/105415] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-04-28
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Bisecting that right now..

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11/12 Regression]       |[9/10/11/12 Regression]
                   |'-fcompare-debug' failure   |'-fcompare-debug' failure
                   |w/ -O2                      |w/ -O2
                   |-ftree-parallelize-loops=2  |-ftree-parallelize-loops=2
                   |                            |since
                   |                            |r7-4900-g59ec925b1199f9
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
With -fno-common, started with r7-4900-g59ec925b1199f9.

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What I see is that for the n variable we create a varpool_node during the FE
finish_decl, then during symbol_table::remove_unreachable_nodes it is removed,
but with -g (and only with that, not with -g0) we create yet another
varpool_node for the same variable during sched1 pass because we have:
(debug_insn 7 6 8 3 (var_location:SI D#1 (mem/c:SI (symbol_ref:DI ("n") [flags
0x82]  <var_decl 0x7fb3041bdf30 n>) [1 n+0 S4 A32])) "pr105415.c":11:9 -1
     (nil))
as the only reference to n and in:
#0  varpool_node::get_create (decl=<var_decl 0x7fffea3e7f30 n>) at
../../gcc/varpool.cc:153
#1  0x0000000000c7cfb9 in symtab_node::get_create (node=<var_decl
0x7fffea3e7f30 n>) at ../../gcc/cgraph.h:3362
#2  0x0000000000c77730 in compare_base_symbol_refs (x_base=0x7fffea2c8a78,
y_base=0x7fffea2c8a28, distance=0x0) at ../../gcc/alias.cc:2223
#3  0x0000000000c77b67 in base_alias_check (x=0x7fffea2cc1e0,
x_base=0x7fffea2c8a28, y=0x7fffea2c8a78, y_base=0x7fffea2c8a78,
x_mode=E_SImode, y_mode=E_SImode)
    at ../../gcc/alias.cc:2309
#4  0x0000000000c7b066 in write_dependence_p (mem=0x7fffea2cc000,
x=0x7fffea2c5a38, x_mode=E_VOIDmode, x_addr=0x7fffea2cc1e0,
mem_canonicalized=false, x_canonicalized=false, 
    writep=false) at ../../gcc/alias.cc:3156
#5  0x0000000000c7b285 in anti_dependence (mem=0x7fffea2cc000,
x=0x7fffea2c5a38) at ../../gcc/alias.cc:3183
#6  0x0000000002652e29 in sched_analyze_1 (deps=0x7fffffffd240,
x=0x7fffea2c5ca8, insn=0x7fffea3efac0) at ../../gcc/sched-deps.cc:2501
#7  0x000000000265407c in sched_analyze_insn (deps=0x7fffffffd240,
x=0x7fffea2c5ca8, insn=0x7fffea3efac0) at ../../gcc/sched-deps.cc:2931
#8  0x0000000002656c52 in deps_analyze_insn (deps=0x7fffffffd240,
insn=0x7fffea3efac0) at ../../gcc/sched-deps.cc:3683
#9  0x000000000265723d in sched_analyze (deps=0x7fffffffd240,
head=0x7fffea3ef880, tail=0x7fffea3efac0) at ../../gcc/sched-deps.cc:3829
#10 0x0000000001375306 in compute_block_dependences (bb=0) at
../../gcc/sched-rgn.cc:2733
#11 0x0000000001377154 in sched_rgn_compute_dependencies (rgn=1) at
../../gcc/sched-rgn.cc:3360
#12 0x000000000137677c in schedule_region (rgn=1) at
../../gcc/sched-rgn.cc:3113
#13 0x000000000137797f in schedule_insns () at ../../gcc/sched-rgn.cc:3518
#14 0x0000000001378224 in rest_of_handle_sched () at
../../gcc/sched-rgn.cc:3722
create the varpool node again.  Which shifts the node->order of later created
cgraph or varpool nodes.

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Wonder about:
--- gcc/alias.cc.jj     2022-02-21 16:51:50.261232505 +0100
+++ gcc/alias.cc        2022-04-28 11:57:18.940425126 +0200
@@ -2219,8 +2219,10 @@ compare_base_symbol_refs (const_rtx x_ba
          || (!TREE_STATIC (x_decl) && !TREE_PUBLIC (x_decl)))
        return 0;

-      symtab_node *x_node = symtab_node::get_create (x_decl)
-                           ->ultimate_alias_target ();
+      symtab_node *x_node = symtab_node::get (x_decl);
+      if (x_node == NULL)
+       return 0;
+      x_node = x_node->ultimate_alias_target ();
       /* External variable cannot be in section anchor.  */
       if (!x_node->definition)
        return 0;
It would surprise me if we needed to create varpool nodes so late, if they
don't exist, with the exception of DEBUG_INSNs referencing already removed
symbols I don't see the reason why the varpool nodes wouldn't be present.
Another option would be for the x_node == NULL case to use x_decl rather than
x_node->decl, i.e. just assume x_decl isn't an alias if it doesn't have a
varpool node.

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've included debug printouts into the if (x_node == NULL) body before return
0;
and sort -u of the dump shows in powerpc64le-linux bootstrap so far (still
ongoing) shows:
../../gcc/fortran/decl.cc match_attr_spec *.LC320
../../gcc/fortran/decl.cc match_attr_spec *.LC455
../../gcc/fortran/decl.cc match_attr_spec *.LC456
../../gcc/fortran/decl.cc match_attr_spec *.LC457
../../gcc/fortran/decl.cc match_attr_spec *.LC458
../../gcc/fortran/decl.cc match_attr_spec *.LC459
../../gcc/fortran/decl.cc match_attr_spec *.LC460
../../gcc/fortran/decl.cc match_attr_spec *.LC461
../../gcc/fortran/decl.cc match_attr_spec *.LC462
../../gcc/fortran/decl.cc match_attr_spec *.LC463
../../gcc/fortran/decl.cc match_attr_spec *.LC464
../../gcc/fortran/decl.cc match_attr_spec *.LC465
../../gcc/fortran/decl.cc match_attr_spec *.LC466
../../gcc/fortran/decl.cc match_attr_spec *.LC467
../../gcc/fortran/decl.cc match_attr_spec *.LC468
../../gcc/fortran/decl.cc match_attr_spec *.LC469
../../gcc/fortran/decl.cc match_attr_spec *.LC470
../../gcc/fortran/decl.cc match_attr_spec *.LC471
../../gcc/fortran/decl.cc match_attr_spec *.LC472
../../gcc/fortran/decl.cc match_attr_spec *.LC473
../../gcc/fortran/decl.cc match_attr_spec *.LC474
../../gcc/fortran/decl.cc match_attr_spec *.LC475
../../gcc/fortran/decl.cc match_attr_spec *.LC476
../../gcc/fortran/parse.cc next_statement *.LC704
../../gcc/fortran/scanner.cc gfc_next_char_literal *.LC52
../../gcc/fortran/scanner.cc gfc_next_char_literal *.LC53
../../gcc/fortran/scanner.cc gfc_next_char_literal *.LC57
../../gcc/fortran/scanner.cc load_file *.LC102
so seems decls without varpool nodes are mostly constant pool decls.
So perhaps
--- gcc/alias.cc.jj     2022-04-28 12:33:15.169434009 +0200
+++ gcc/alias.cc        2022-04-28 13:47:34.402456905 +0200
@@ -2219,12 +2219,19 @@ compare_base_symbol_refs (const_rtx x_ba
          || (!TREE_STATIC (x_decl) && !TREE_PUBLIC (x_decl)))
        return 0;

-      symtab_node *x_node = symtab_node::get_create (x_decl)
-                           ->ultimate_alias_target ();
-      /* External variable cannot be in section anchor.  */
-      if (!x_node->definition)
+      symtab_node *x_node = symtab_node::get (x_decl);
+      tree x_decl2 = x_decl;
+      if (x_node != NULL)
+       {
+         x_node = x_node->ultimate_alias_target ();
+         /* External variable cannot be in section anchor.  */
+         if (!x_node->definition)
+           return 0;
+         x_decl2 = x_node->decl;
+       }
+      else if (DECL_EXTERNAL (x_decl))
        return 0;
-      x_base = XEXP (DECL_RTL (x_node->decl), 0);
+      x_base = XEXP (DECL_RTL (x_decl2), 0);
       /* If not in anchor, we can disambiguate.  */
       if (!SYMBOL_REF_HAS_BLOCK_INFO_P (x_base))
        return 0;
might be better.

[Bug debug/105415] [9/10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:02f03c5c826d0cb7c32398af0c4282921e6e072a

commit r13-68-g02f03c5c826d0cb7c32398af0c4282921e6e072a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon May 2 11:30:58 2022 +0200

    expand: Throw away non-external decls without varpool nodes [PR105415]

    The following testcase fails -fcompare-debug on aarch64-linux.  The problem
    is that for the n variable we create a varpool node, then remove it again
    because the var isn't really used, but it keeps being referenced in debug
    stmts/insns with -g.  Later during sched1 pass we ask whether the n var
    can be modified through some store to an anchored variable and with -g
    we create a new varpool node for it again just so that we can find its
    ultimate alias target.  Even later on we create some cgraph node for the
    loop parallelization, but as there has been an extra varpool node creation
    in between, we get higher node->order with -g than without.

    The patch fixes that by throwing variables without varpool nodes away
    during expansion time, they are very unlikely to actually end up with
    useful debug info anyway.

    I've bootstrapped/regtested the following on x86_64-linux and i686-linux,
    then bootstrapped with the patch reverted, reapplied the patch and did make
    cc1plus in stage3.  The debug section sizes are identical, .debug_info and
    .debug_loc is identical too, so I think we don't lose any debug info
through
    it.
    So at least on cc1plus it makes no difference.

    2022-05-02  Jakub Jelinek  <jakub@redhat.com>

            PR debug/105415
            * cfgexpand.cc (expand_debug_expr): Don't make_decl_rtl_for_debug
            if there is no symtab node for the VAR_DECL.

            * gcc.dg/pr105415.c: New test.

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12/13 Regression]  |[9/10/11/12 Regression]
                   |'-fcompare-debug' failure   |'-fcompare-debug' failure
                   |w/ -O2                      |w/ -O2
                   |-ftree-parallelize-loops=2  |-ftree-parallelize-loops=2
                   |since                       |since
                   |r7-4900-g59ec925b1199f9     |r7-4900-g59ec925b1199f9

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk.  Not really sure about backports, the exact symtab order
member values I think shouldn't actually affect code generations, so besides
-fcompare-debug it probably isn't that urgent.

[Bug debug/105415] [9/10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Arseny Solokha <asolokha at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression]     |[9/10/11/12/13 Regression]
                   |'-fcompare-debug' failure   |'-fcompare-debug' failure
                   |w/ -O2                      |w/ -O2
                   |-ftree-parallelize-loops=2  |-ftree-parallelize-loops=2
                   |since                       |since
                   |r7-4900-g59ec925b1199f9     |r7-4900-g59ec925b1199f9

--- Comment #8 from Arseny Solokha <asolokha at gmx dot com> ---
I still get a similar failure w/ gcc 13.0.0 20220515 snapshot:

@@ -360,7 +360,7 @@
 1:   int i;
 2:   signed int D.xxxx;

-;; Function bar._loopfn.0 (bar._loopfn.0, funcdef_no=2, cgraph_uid=3,
symbol_order=5)
+;; Function bar._loopfn.0 (bar._loopfn.0, funcdef_no=2, cgraph_uid=3,
symbol_order=6)

 (note # 0 0 NOTE_INSN_DELETED)
 (note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)

upon the following change to the original testcase:

@@ -4,13 +4,10 @@ static int n;
 void
 foo (void)
 {
-  int s = 0;
+  int *arr[] = { &n, &n, &n };
+  int unused = n;

-  while (m < 1)
-    {
-      s += n;
-      ++m;
-    }
+  m = 0;
 }

 void

Do you want me to open a separate PR for that?

[Bug debug/105415] [9/10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sure, that must be a different problem.

[Bug debug/105415] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug debug/105415] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug middle-end/105415] [11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.