[Bug bootstrap/44832] New: --enable-build-with-cxx Bootstrap comparison failure

[Bug bootstrap/44832] New: --enable-build-with-cxx Bootstrap comparison failure

[amylaar at gcc dot gnu dot org]

r161856, bootstrapped with --enable-build-with-cxx, fails the bootstrap
comparison on i386.o.
By doing a binary search applying the first patch for PR44512
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01765.html
to older revisions, I found that the onset of these comparison failures
is between revision 161800 and 161802.  As 161801 was a fortran-only patch,
161802 seems the likely culprit.


-- 
           Summary: --enable-build-with-cxx Bootstrap comparison failure
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: amylaar at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
OtherBugsDependingO 44433
             nThis:


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

[Bug bootstrap/44832] --enable-build-with-cxx Bootstrap comparison failure

[amylaar at gcc dot gnu dot org]

------- Comment #1 from amylaar at gcc dot gnu dot org  2010-07-06 05:25 -------
Adding -gtoggle to the options to compile the stage3 i386.o gives the same
assembly as stage2.


-- 


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

[Bug bootstrap/44832] --enable-build-with-cxx Bootstrap comparison failure

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2010-07-06 10:22 -------
Huh, I can't see how this should cause a debug compare failure.

Can you attach preprocessed source?


-- 


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

[Bug bootstrap/44832] --enable-build-with-cxx Bootstrap comparison failure

[amylaar at gcc dot gnu dot org]

------- Comment #3 from amylaar at gcc dot gnu dot org  2010-07-06 13:18 -------
Created an attachment (id=21106)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21106&action=view)
i386.c preprocessed source

/user/inria/fsf/161802/bld-1/./prev-gcc/cc1plus -fpreprocessed i386.ii -quiet
-dumpbase i386.c -mtune=generic -march=pentiumpro -auxbase-strip i386.o -g  -O2
-W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version
-fomit-frame-pointer -fno-common  -o i386.s

/user/inria/fsf/161802/bld-1/./prev-gcc/cc1plus -fpreprocessed i386.ii -quiet
-dumpbase i386.c -mtune=generic -march=pentiumpro -auxbase-strip i386.o -g
-gtoggle -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-version -fomit-frame-pointer -fno-common -o i386g.s

[amylaar@laria gcc]$ diff -pU1 '-F^[_a-zA-Z]' i386.s i386g.s|grep -A 10 -B 10
'^[+-].*[0-9](%esp'
-       .loc 2 27855 0
        movzbl  mode_nunits(%ebx), %esi
-       .loc 2 27854 0
        movzbl  mode_inner(%ebx), %edx
-       .loc 2 27858 0
        movl    $0, (%esp)
-       .loc 2 27856 0
        shrb    $2, %al
        movzbl  %al, %eax
-       .loc 2 27854 0
-       movl    %edx, 64(%esp)
-.LVL8487:
-       .loc 2 27857 0
+       movl    %edx, 60(%esp)
        movl    %esi, %edx
-.LVL8488:
-       .loc 2 27856 0
        movl    %eax, 48(%esp)
-.LVL8489:
-       .loc 2 27857 0
        sarl    $31, %edx
        movl    %esi, %eax
-.LVL8490:
        idivl   48(%esp)
-       .loc 2 27858 0
-       movl    64(%esp), %edx
-       .loc 2 27857 0
+       movl    60(%esp), %edx
        movl    %eax, %esi
-.LVL8491:
-       .loc 2 27858 0
        movzbl  mode_size(%edx), %eax
-.LVL8492:
        sall    $3, %eax
@@ -103335,12 +62102,5 @@ _ZL31ix86_expand_vector_init_generalb12m
        movl    %eax, 72(%esp)
-.LVL8493:
-.LBB13227:
--
-.LBB13224:
-.LBB13226:
-.LBB13238:
-.LBB13237:
-.LBB13231:
-       .loc 2 27770 0
        leal    -1(%ecx), %edx
-       .loc 2 27867 0
        xorl    %ebx, %ebx
-       .loc 2 27770 0
-       movl    %edx, 60(%esp)
-       .loc 2 27866 0
+       movl    %edx, 64(%esp)
        movl    256(%esp), %edx
-.LBE13231:
-       .loc 2 27864 0
        addl    $1, %ebx
-.LBB13232:
-       .loc 2 27867 0
        movl    $1, 12(%esp)
-       .loc 2 27866 0
        movl    %edi, 52(%esp)
        movl    (%edx), %eax
-       .loc 2 27867 0
-       movl    60(%esp), %edx
+       movl    64(%esp), %edx
        movl    4(%eax,%edx,4), %eax
@@ -103584,3 +62233,3 @@ _ZL31ix86_expand_vector_init_generalb12m
        movl    %eax, 8(%esp)
-       movl    64(%esp), %eax
+       movl    60(%esp), %eax
        movl    %eax, 4(%esp)
@@ -103589,32 +62238,13 @@ _ZL31ix86_expand_vector_init_generalb12m
        call    _Z13convert_modes12machine_modeS_P7rtx_defi
-.LBE13232:
-       .loc 2 27864 0
        cmpl    %ebx, %esi
        movl    40(%esp), %ecx
-.LBB13233:
-       .loc 2 27867 0
        movl    %eax, %ebp
--
 .L8384:
-.LBB13234:
-       .loc 2 27866 0
        movl    256(%esp), %edx
-       .loc 2 27867 0
        movl    $1, 12(%esp)
-       .loc 2 27866 0
        movl    (%edx), %eax
-.LVL8522:
-       .loc 2 27770 0
-       movl    60(%esp), %edx
+       movl    64(%esp), %edx
        subl    %ebx, %edx
-.LBE13234:
-       .loc 2 27864 0
        addl    $1, %ebx
-.LVL8523:
-.LBB13235:
-       .loc 2 27867 0
        movl    4(%eax,%edx,4), %eax
@@ -103622,3 +62252,3 @@ _ZL31ix86_expand_vector_init_generalb12m
        movl    %eax, 8(%esp)
-       movl    64(%esp), %eax
+       movl    60(%esp), %eax
        movl    %eax, 4(%esp)
@@ -103627,3 +62257,2 @@ _ZL31ix86_expand_vector_init_generalb12m
        call    _Z13convert_modes12machine_modeS_P7rtx_defi
-       .loc 2 27874 0
        movl    %ebp, 16(%esp)
@@ -103633,8 +62262,4 @@ _ZL31ix86_expand_vector_init_generalb12m
        movl    $65, 4(%esp)
-       .loc 2 27867 0
        movl    %eax, %edx
-.LVL8524:


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-06 14:09 -------
Reverting up to r161801 still gets me

> ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug
g++: error: ii386.i: -fcompare-debug failure (length)

so it wasn't r161802.

-fcompare-debug does not fail on the 4.5 branch with that testcase.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|bootstrap                   |debug
     Ever Confirmed|0                           |1
           Keywords|                            |build
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-06 14:09:00
               date|                            |
            Summary|--enable-build-with-cxx     |[4.6 Regression] -fcompare-
                   |Bootstrap comparison failure|debug failure for C++ i386.c
   Target Milestone|---                         |4.6.0


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #5 from amylaar at gcc dot gnu dot org  2010-07-06 14:42 -------
(In reply to comment #4)
> Reverting up to r161801 still gets me
> 
> > ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug
> g++: error: ii386.i: -fcompare-debug failure (length)
> 
> so it wasn't r161802.

Is this command supposed to also give sane results on i686-pc-linux-gnu?
Even when I try this with r161600, it says there is a length failure.
But when I make cc1plus create actual assembly files and assemble / strip
them, the resulting object files compare equal.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #6 from amylaar at gcc dot gnu dot org  2010-07-06 14:51 -------
(In reply to comment #4)
> Reverting up to r161801 still gets me
> 
> > ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug

I've tried this with --save-temps in r161600 and there's lots of differences in
the dump files regarding numbers that won't appear in the output file.
So this is a much stricter comparison check than what we do during bootstrap.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #7 from amylaar at gcc dot gnu dot org  2010-07-06 15:03 -------
(In reply to comment #4)
> ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug

Works with g++ (GCC) 4.6.0 20100613 (experimental), fails with
g++ (GCC) 4.6.0 20100617 (experimental).


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #8 from amylaar at gcc dot gnu dot org  2010-07-06 18:21 -------
(In reply to comment #4)
> Reverting up to r161801 still gets me
> 
> > ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug
> g++: error: ii386.i: -fcompare-debug failure (length)

Works in r160828, fails in r160832.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #9 from amylaar at gcc dot gnu dot org  2010-07-07 01:42 -------
Created an attachment (id=21117)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21117&action=view)
reduced testcase


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #10 from amylaar at gcc dot gnu dot org  2010-07-07 02:00 -------
;; Function void ix86_expand_vector_init_general(bool, machine_mode, rtx, rtx) 
Compiling the reduced testcase in a subdirectory of the r160832 gcc build
directory with:
 ../g++ -B.. -da -march=pentiumpro -mtune=generic -m32 t.c --dump-tree-all -g
-S  -fdump-unnumbered
, I see this in the final dump:

(_ZL31ix86_expand_vector_init_generalb12machine_modeP7rtx_defS1_)

deleting insn with uid = 174.
Failed to expand as dwarf: op1
Reason: DECL has no RTL

;; Function void ix86_expand_vector_init(bool, rtx, rtx)
(_Z23ix86_expand_vector_initbP7rtx_defS0_)

deleting insn with uid = 170.


-- 

amylaar at gcc dot gnu dot org changed:

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


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #11 from amylaar at gcc dot gnu dot org  2010-07-07 02:16 -------
(In reply to comment #10)
> ;; Function void ix86_expand_vector_init_general(bool, machine_mode, rtx, rtx) 
> Compiling the reduced testcase in a subdirectory of the r160832 gcc build
> directory with:
>  ../g++ -B.. -da -march=pentiumpro -mtune=generic -m32 t.c --dump-tree-all -g
> -S  -fdump-unnumbered
> , I see this in the final dump:

Hmm, that's actually the same as for r160828; but still, r160828 passes the
-fcompare-debug debug test with the reduced test case, while r160832 fails it.
Running this test with --save-temps and diffing the output shows that somehow
we end up with different tmp_var_id_num values for variables created by
tree-ssa-pre.c:

--- t.gkd       2010-07-07 03:02:40.831101079 +0100
+++ t.gk.gkd    2010-07-07 03:02:40.886978157 +0100
@@ -454,9 +454,9 @@
 (insn:TI# 0 0 t.c:78 (set (reg/f:SI 2 cx [116])
         (mem/s/f:SI (plus:SI (mult:SI (reg/v:SI 0 ax [orig:80 i ] [80])
                     (const_int 4 [0x4]))
-                (reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_81 S4
A32]))# {*movsi_1} (expr_list:REG_EQUIV (mem/s/f:SI (plus:SI (mult:SI (reg/v:SI
0 ax [orig:80 i ] [80])
+                (reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_82 S4
A32]))# {*movsi_1} (expr_list:REG_EQUIV (mem/s/f:SI (plus:SI (mult:SI (reg/v:SI
0 ax [orig:80 i ] [80])
                     (const_int 4 [0x4]))
-                (reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_81 S4
A32])
+                (reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_82 S4
A32])
         (nil)))
 (insn:TI# 0 0 t.c:78 (set (mem/s/f:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 0
ax [orig:80 i ] [80])
                         (const_int 4 [0x4]))


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenther at suse dot de]

------- Comment #12 from rguenther at suse dot de  2010-07-07 08:38 -------
Subject: Re:  [4.6 Regression] -fcompare-debug failure for
 C++ i386.c

On Wed, 7 Jul 2010, amylaar at gcc dot gnu dot org wrote:

> ------- Comment #11 from amylaar at gcc dot gnu dot org  2010-07-07 02:16 -------
> (In reply to comment #10)
> > ;; Function void ix86_expand_vector_init_general(bool, machine_mode, rtx, rtx) 
> > Compiling the reduced testcase in a subdirectory of the r160832 gcc build
> > directory with:
> >  ../g++ -B.. -da -march=pentiumpro -mtune=generic -m32 t.c --dump-tree-all -g
> > -S  -fdump-unnumbered
> > , I see this in the final dump:
> 
> Hmm, that's actually the same as for r160828; but still, r160828 passes the
> -fcompare-debug debug test with the reduced test case, while r160832 fails it.
> Running this test with --save-temps and diffing the output shows that somehow
> we end up with different tmp_var_id_num values for variables created by
> tree-ssa-pre.c:
> 
> --- t.gkd       2010-07-07 03:02:40.831101079 +0100
> +++ t.gk.gkd    2010-07-07 03:02:40.886978157 +0100
> @@ -454,9 +454,9 @@
>  (insn:TI# 0 0 t.c:78 (set (reg/f:SI 2 cx [116])
>          (mem/s/f:SI (plus:SI (mult:SI (reg/v:SI 0 ax [orig:80 i ] [80])
>                      (const_int 4 [0x4]))
> -                (reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_81 S4
> A32]))# {*movsi_1} (expr_list:REG_EQUIV (mem/s/f:SI (plus:SI (mult:SI (reg/v:SI
> 0 ax [orig:80 i ] [80])
> +                (reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_82 S4
> A32]))# {*movsi_1} (expr_list:REG_EQUIV (mem/s/f:SI (plus:SI (mult:SI (reg/v:SI
> 0 ax [orig:80 i ] [80])
>                      (const_int 4 [0x4]))
> -                (reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_81 S4
> A32])
> +                (reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_82 S4
> A32])
>          (nil)))
>  (insn:TI# 0 0 t.c:78 (set (mem/s/f:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 0
> ax [orig:80 i ] [80])
>                          (const_int 4 [0x4]))

Hm, different SSA name versions are not good - that might cause
code generation differences.  Where do they first differ?

Richard.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #13 from amylaar at gcc dot gnu dot org  2010-07-07 13:15 -------
(In reply to comment #12)
> Hm, different SSA name versions are not good - that might cause
> code generation differences.  Where do they first differ?

t.c.025t.einline2  / t.c.gk.025t.einline2


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #14 from amylaar at gcc dot gnu dot org  2010-07-07 13:22 -------
(In reply to comment #12)
$ diff -u -I '^  # DEBUG.*$' t.c.025t.* t.c.gk.025t.*
--- t.c.025t.einline2   2010-07-07 13:59:11.251978485 +0100
+++ t.c.gk.025t.einline2        2010-07-07 13:59:11.451101846 +0100
@@ -149,14 +161,14 @@
   int i;
   int n;
   struct rtx_def * ops[32];
+  unsigned char D.1889;
   unsigned char D.1888;
-  unsigned char D.1887;
+  int D.1887;
   int D.1886;
-  int D.1885;
   int ix86_isa_flags.6;
-  struct rtx_def * D.1883;
-  struct rtvec_def * D.1882;
-  const unsigned char D.1881;
+  struct rtx_def * D.1884;
+  struct rtvec_def * D.1883;
+  const unsigned char D.1882;
   int mode.5;
   struct rtvec_def * * D.1872;
   int D.1817;
@@ -329,22 +365,26 @@

 <L27>:
   mode.5_58 = (int) mode_12;
-  D.1881_59 = mode_nunits[mode.5_58];
-  n_60 = (int) D.1881_59;
+  D.1882_59 = mode_nunits[mode.5_58];
+  n_60 = (int) D.1882_59;
+  # DEBUG n => n_60
   ix86_expand_vector_init_concat (mode_12, target_10(D), &ops[0], n_60);
   goto <bb 32>;

 half:
   mode.5_61 = (int) mode_12;
-  D.1881_62 = mode_nunits[mode.5_61];
-  n_63 = (int) D.1881_62;
+  D.1882_62 = mode_nunits[mode.5_61];
+  n_63 = (int) D.1882_62;
+  # DEBUG n => n_63
+  # DEBUG i => 0
   goto <bb 26>;

 <bb 25>:
-  D.1882_64 = *D.1872_50;
-  D.1883_66 = D.1882_64->elem[i_65];
-  ops[i_65] = D.1883_66;
+  D.1883_64 = *D.1872_50;
+  D.1884_66 = D.1883_64->elem[i_65];
+  ops[i_65] = D.1884_66;
   i_67 = i_65 + 1;
+  # DEBUG i => i_67

 <bb 26>:
   # i_65 = PHI <0(24), i_67(25)>
@@ -359,25 +401,26 @@

 <L29>:
   ix86_isa_flags.6_68 = ix86_isa_flags;
-  D.1885_69 = ix86_isa_flags.6_68 & 524288;
-  if (D.1885_69 == 0)
+  D.1886_69 = ix86_isa_flags.6_68 & 524288;
+  if (D.1886_69 == 0)
     goto <bb 30> (<L31>);
   else
     goto <bb 29> (<L30>);

 <L30>:
   ix86_isa_flags.6_70 = ix86_isa_flags;
-  D.1886_71 = ix86_isa_flags.6_70 & 131072;
-  if (D.1886_71 == 0)
+  D.1887_71 = ix86_isa_flags.6_70 & 131072;
+  if (D.1887_71 == 0)
     goto <bb 30> (<L31>);
   else
     goto <bb 32>;

 <L31>:
   mode.5_72 = (int) mode_12;
-  D.1887_73 = mode_size[mode.5_72];
-  D.1888_74 = D.1887_73 / 4;
-  if (D.1888_74 == 4)
+  D.1888_73 = mode_size[mode.5_72];
+  D.1889_74 = D.1888_73 / 4;
+  # DEBUG n_words => (int) D.1889_74
+  if (D.1889_74 == 4)
     goto <bb 31>;
   else
     goto <bb 32>;


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2010-07-07 13:23 -------
The reduced testcase doesn't fail for me, the unreduced one fails though.
-fcompare-debug complains about different ORIGINAL_REGNOs and different ivtmp.*
names.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenther at suse dot de]

------- Comment #16 from rguenther at suse dot de  2010-07-07 13:24 -------
Subject: Re:  [4.6 Regression] -fcompare-debug failure for
 C++ i386.c

On Wed, 7 Jul 2010, amylaar at gcc dot gnu dot org wrote:

> ------- Comment #14 from amylaar at gcc dot gnu dot org  2010-07-07 13:22 -------
> (In reply to comment #12)
> $ diff -u -I '^  # DEBUG.*$' t.c.025t.* t.c.gk.025t.*
> --- t.c.025t.einline2   2010-07-07 13:59:11.251978485 +0100
> +++ t.c.gk.025t.einline2        2010-07-07 13:59:11.451101846 +0100
> @@ -149,14 +161,14 @@
>    int i;
>    int n;
>    struct rtx_def * ops[32];
> +  unsigned char D.1889;
>    unsigned char D.1888;
> -  unsigned char D.1887;
> +  int D.1887;
>    int D.1886;
> -  int D.1885;
>    int ix86_isa_flags.6;
> -  struct rtx_def * D.1883;
> -  struct rtvec_def * D.1882;
> -  const unsigned char D.1881;
> +  struct rtx_def * D.1884;
> +  struct rtvec_def * D.1883;
> +  const unsigned char D.1882;
>    int mode.5;
>    struct rtvec_def * * D.1872;
>    int D.1817;
> @@ -329,22 +365,26 @@
> 
>  <L27>:
>    mode.5_58 = (int) mode_12;
> -  D.1881_59 = mode_nunits[mode.5_58];
> -  n_60 = (int) D.1881_59;
> +  D.1882_59 = mode_nunits[mode.5_58];
> +  n_60 = (int) D.1882_59;
> +  # DEBUG n => n_60
>    ix86_expand_vector_init_concat (mode_12, target_10(D), &ops[0], n_60);
>    goto <bb 32>;
> 
>  half:
>    mode.5_61 = (int) mode_12;
> -  D.1881_62 = mode_nunits[mode.5_61];
> -  n_63 = (int) D.1881_62;
> +  D.1882_62 = mode_nunits[mode.5_61];
> +  n_63 = (int) D.1882_62;
> +  # DEBUG n => n_63
> +  # DEBUG i => 0
>    goto <bb 26>;
> 
>  <bb 25>:
> -  D.1882_64 = *D.1872_50;
> -  D.1883_66 = D.1882_64->elem[i_65];
> -  ops[i_65] = D.1883_66;
> +  D.1883_64 = *D.1872_50;
> +  D.1884_66 = D.1883_64->elem[i_65];
> +  ops[i_65] = D.1884_66;
>    i_67 = i_65 + 1;
> +  # DEBUG i => i_67
> 
>  <bb 26>:
>    # i_65 = PHI <0(24), i_67(25)>
> @@ -359,25 +401,26 @@
> 
>  <L29>:
>    ix86_isa_flags.6_68 = ix86_isa_flags;
> -  D.1885_69 = ix86_isa_flags.6_68 & 524288;
> -  if (D.1885_69 == 0)
> +  D.1886_69 = ix86_isa_flags.6_68 & 524288;
> +  if (D.1886_69 == 0)
>      goto <bb 30> (<L31>);
>    else
>      goto <bb 29> (<L30>);
> 
>  <L30>:
>    ix86_isa_flags.6_70 = ix86_isa_flags;
> -  D.1886_71 = ix86_isa_flags.6_70 & 131072;
> -  if (D.1886_71 == 0)
> +  D.1887_71 = ix86_isa_flags.6_70 & 131072;
> +  if (D.1887_71 == 0)
>      goto <bb 30> (<L31>);
>    else
>      goto <bb 32>;
> 
>  <L31>:
>    mode.5_72 = (int) mode_12;
> -  D.1887_73 = mode_size[mode.5_72];
> -  D.1888_74 = D.1887_73 / 4;
> -  if (D.1888_74 == 4)
> +  D.1888_73 = mode_size[mode.5_72];
> +  D.1889_74 = D.1888_73 / 4;
> +  # DEBUG n_words => (int) D.1889_74
> +  if (D.1889_74 == 4)
>      goto <bb 31>;
>    else
>      goto <bb 32>;

Maybe I'm blind, but the SSA name versions are all the same in
the above diff.

Richard.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #17 from amylaar at gcc dot gnu dot org  2010-07-07 13:48 -------
(In reply to comment #16)
> Maybe I'm blind, but the SSA name versions are all the same in
> the above diff.

The ssa name 1881 gets changed to 1882, isn't that significant?


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[jakub at gcc dot gnu dot org]

------- Comment #18 from jakub at gcc dot gnu dot org  2010-07-07 13:55 -------
That's not SSA name, but DECL_UID of the underlying decl.
I believe such changes are considered ok if it just means different gaps
between uids with -g vs. -g0.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2010-07-07 13:57 -------
Yes, that's ok.  I'm re-reducing the testcase (which also fails with
-fno-ivopts).


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #20 from amylaar at gcc dot gnu dot org  2010-07-07 14:00 -------
Created an attachment (id=21123)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21123&action=view)
typescript looking at inrements of next_decl_uid

The last ssa name before 1881 in the dump files is 1872; so the increment to
1873 should be legitimate.
Any idea which of the logged increments I should take a closer look at?


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #21 from amylaar at gcc dot gnu dot org  2010-07-07 14:02 -------
(In reply to comment #19)
> Yes, that's ok.  I'm re-reducing the testcase (which also fails with
> -fno-ivopts).

FWIW I've reduced the testcase with the aim of reproducing the problem in
r160832, which is when the un-reduced testcase first fails.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #22 from amylaar at gcc dot gnu dot org  2010-07-07 14:06 -------
(In reply to comment #18)
> That's not SSA name, but DECL_UID of the underlying decl.
> I believe such changes are considered ok if it just means different gaps
> between uids with -g vs. -g0.

For compiler-generated temporary variables, isn't the DECL_UID part of the
name?
And doesn't that affect hash tables, and thus ordering?


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[jakub at gcc dot gnu dot org]

------- Comment #23 from jakub at gcc dot gnu dot org  2010-07-07 14:25 -------
Hash tables hashed by DECL_UID should be traversed only when the traversal
order doesn't affect code generation.  E.g. Richard fixed a few places to just
set
bits in a bitmap and then iterate over the bitmap for code generation (which
means gaps between uids don't affect code generation, just reordering of decl
uids could).

You can just compare -fdump-final-insns= dumps from the -fcompare-debug
invocation, that's what is actually being compared.  Those dumps are with
TDF_NOUID.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #24 from rguenth at gcc dot gnu dot org  2010-07-07 14:34 -------
Created an attachment (id=21124)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21124&action=view)
less reduced testcase

Reduced at topformflat level 0 only.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2010-07-07 14:48 -------
The first difference appears in .093t.pre (comparing -nouid dumps):

cat ii386.3.3.i.gk.094t.pre | grep -v '# DEBUG' | diff -u ii386.3.3.i.094t.pre
-  | less

 void
_ZL31ix86_expand_vector_init_generalb12machine_modeP7rtx_defS1_.isra.0(boo
l, machine_mode, rtx, rtvec_def**) (bool mmx_ok, machine_mode mode, struct
rtx_d
ef * target, struct rtvec_def * * ISRA.45)
 {
-  int pretmp.167;
   struct rtvec_def * pretmp.166;
   int pretmp.165;
   struct rtvec_def * pretmp.164;
@@ -4625,11 +4624,11 @@
   goto <bb 8>;

 <bb 44>:
-  pretmp.166_99 = *ISRA.45_147(D);
+  pretmp.166_11 = *ISRA.45_147(D);

 <bb 7>:
   # i_173 = PHI <i_13(46), 0(44)>
-  D.xxxx_10 = pretmp.166_99;
+  D.xxxx_10 = pretmp.166_11;
   D.xxxx_12 = D.xxxx_10->elem[i_173];
   ops[i_173] = D.xxxx_12;
   i_13 = i_173 + 1;


where we have differences in assigned value-numbers and walk SCCs in a
different oder.

SCC consists of: i_172 i_21

vs.

SCC consists of: i_173 i_13

thus I think we have to look for an instability in the SCC walker.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #25 from amylaar at gcc dot gnu dot org  2010-07-07 14:47 -------
Created an attachment (id=21125)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21125&action=view)
diff -u -I '^  # DEBUG.*$' t.c.093t.pre t.c.gk.093t.pre

Disregarding where merely the base names of ssa name versions vary according to
the DECL_UID, the first ssa name version change is in 093t.pre


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #27 from amylaar at gcc dot gnu dot org  2010-07-07 14:56 -------
(In reply to comment #26)
> The first difference appears in .093t.pre (comparing -nouid dumps):
> 
> cat ii386.3.3.i.gk.094t.pre | grep -v '# DEBUG' | diff -u ii386.3.3.i.094t.pre
> -  | less

is that .093t.pre or .094t.pre ?
And what revision of trunk are you looking at?


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #28 from rguenth at gcc dot gnu dot org  2010-07-07 15:00 -------
No, the culprit is loop header copying which causes

@@ -2634,8 +2634,8 @@
     goto <bb 8>;

 <bb 8>:
-  # .MEM_6 = PHI <.MEM_106(7), .MEM_105(D)(6)>
-  # .MEM_107 = VDEF <.MEM_6>
+  # .MEM_149 = PHI <.MEM_106(7), .MEM_105(D)(6)>
+  # .MEM_107 = VDEF <.MEM_149>
   ix86_expand_vector_init_concat (mode_1(D), target_14(D), &ops, n_8);
   goto <bb 34>;

@@ -2665,8 +2665,8 @@
     goto <bb 11>;

 <bb 11>:
-  # .MEM_15 = PHI <.MEM_108(10), .MEM_105(D)(9)>
-  # .MEM_109 = VDEF <.MEM_15>
+  # .MEM_6 = PHI <.MEM_108(10), .MEM_105(D)(9)>
+  # .MEM_109 = VDEF <.MEM_6>
   op0_23 = gen_reg_rtx (half_mode_22);
   # .MEM_110 = VDEF <.MEM_109>
   op1_24 = gen_reg_rtx (half_mode_22);
@@ -2826,8 +2826,8 @@

 <bb 23>:
   # word_48 = PHI <word_96(22), word_97(24)>
-  # .MEM_37 = PHI <.MEM_102(22), .MEM_98(24)>
-  # .MEM_128 = VDEF <.MEM_37>
+  # .MEM_26 = PHI <.MEM_102(22), .MEM_98(24)>
+  # .MEM_128 = VDEF <.MEM_26>
   words[i_163] = word_48;
   i_78 = i_163 + 1;
   if (n_words_54 > i_78)


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #29 from amylaar at gcc dot gnu dot org  2010-07-07 15:06 -------
(In reply to comment #26)
> thus I think we have to look for an instability in the SCC walker.

There's a qsort call.  Is compare_ops guaranteed never to return 0 for
items that are not identical?


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #30 from amylaar at gcc dot gnu dot org  2010-07-07 17:27 -------
(In reply to comment #28)
> No, the culprit is loop header copying which causes

I also see changes in the MEM_* after loop header copying.
It happens during the second call of copy_loop_header.  Alas,
it seems that copy_loop_header is innocent, because it gets
different freed ssa name versions for debug / no debug compilation:

Debug:

Breakpoint 5, copy_loop_headers () at ../../gcc/gcc/tree-ssa-loop-ch.c:140
140       loop_optimizer_init (LOOPS_HAVE_PREHEADERS
(gdb) call debug_tree(cfun->gimple_df->free_ssanames)
 <ssa_name 0xb7db20f0 nothrow var <var_decl 0xb7d97060 retval.3>def_stmt 

    version 87 in-free-list>
(gdb) call debug_tree(cfun->gimple_df->free_ssanames->common.chain)
 <ssa_name 0xb7dacfc0 nothrow var <var_decl 0xb7d91d80 retval.1>def_stmt 

    version 83 in-free-list>

No debug:

Breakpoint 5, copy_loop_headers () at ../../gcc/gcc/tree-ssa-loop-ch.c:140
140       loop_optimizer_init (LOOPS_HAVE_PREHEADERS
(gdb) call debug_tree(cfun->gimple_df->free_ssanames)
 <ssa_name 0xb7da5f90 nothrow var <var_decl 0xb7d95060 retval.3>def_stmt 

    version 87 in-free-list>
(gdb) call debug_tree(cfun->gimple_df->free_ssanames->common.chain)
 <ssa_name 0xb7da5db0 nothrow var <var_decl 0xb7d90d80 retval.1>def_stmt 

    version 82 in-free-list>


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #31 from amylaar at gcc dot gnu dot org  2010-07-07 17:50 -------
(In reply to comment #30)
The first difference I seen in debug / no debug values of
cfun->gimple_df->free_ssanames->ssa_name.version for the relevant function
is in vrp.

Debug:

Hardware watchpoint 10: cfun->gimple_df->free_ssanames

Old value = (tree) 0xb7db2330
New value = (tree) 0xb7dacf60
release_ssa_name (var=0xb7dacf60) at ../../gcc/gcc/tree-ssanames.c:241
241     }
2: cfun->gimple_df->free_ssanames->ssa_name.version = 82
(gdb) bt
#0  release_ssa_name (var=0xb7dacf60) at ../../gcc/gcc/tree-ssanames.c:241
#1  0x086a280e in release_defs (stmt=0xb7dacf90)
    at ../../gcc/gcc/tree-ssanames.c:293
#2  0x086d85e6 in remove_range_assertions () at ../../gcc/gcc/tree-vrp.c:5326
#3  execute_vrp () at ../../gcc/gcc/tree-vrp.c:7442
#4  0x084d5797 in execute_one_pass (pass=0x8c42f00)
    at ../../gcc/gcc/passes.c:1576
#5  0x084d5a9d in execute_pass_list (pass=0x8c42f00)
    at ../../gcc/gcc/passes.c:1631
#6  0x084d5ab0 in execute_pass_list (pass=0x8c41d80)
    at ../../gcc/gcc/passes.c:1632
#7  0x085d562a in tree_rest_of_compilation (fndecl=0xb7d88980)
    at ../../gcc/gcc/tree-optimize.c:420
#8  0x0876e5bc in cgraph_expand_function (node=0xb7cf686c)
    at ../../gcc/gcc/cgraphunit.c:1632
#9  0x0876ffd9 in cgraph_expand_all_functions ()
    at ../../gcc/gcc/cgraphunit.c:1711
#10 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1967
#11 0x08770995 in cgraph_finalize_compilation_unit ()
    at ../../gcc/gcc/cgraphunit.c:1171
#12 0x0818863a in cp_write_global_declarations ()
    at ../../gcc/gcc/cp/decl2.c:3925
#13 0x0857c650 in compile_file (argc=21, argv=0xbffff494)
---Type <return> to continue, or q <return> to quit---q
 at ../../gcc/gcc/topleQuit
(gdb) frame 4
#4  0x084d5797 in execute_one_pass (pass=0x8c42f00)
    at ../../gcc/gcc/passes.c:1576
1576          todo_after = pass->execute ();
(gdb) p pass->name
$5 = 0x8aa58e2 "vrp"

No debug:

Hardware watchpoint 12: cfun->gimple_df->free_ssanames

Old value = (tree) 0xb7dad1b0
New value = (tree) 0xb7da5d50
release_ssa_name (var=0xb7da5d50) at ../../gcc/gcc/tree-ssanames.c:241
241     }
3: cfun->gimple_df->free_ssanames->ssa_name.version = 81
1: cfun->decl = (tree) 0xb7d88900
(gdb) bt
#0  release_ssa_name (var=0xb7da5d50) at ../../gcc/gcc/tree-ssanames.c:241
#1  0x086a280e in release_defs (stmt=0xb7da5d80)
    at ../../gcc/gcc/tree-ssanames.c:293
#2  0x086d85e6 in remove_range_assertions () at ../../gcc/gcc/tree-vrp.c:5326
#3  execute_vrp () at ../../gcc/gcc/tree-vrp.c:7442
#4  0x084d5797 in execute_one_pass (pass=0x8c42f00)
    at ../../gcc/gcc/passes.c:1576
#5  0x084d5a9d in execute_pass_list (pass=0x8c42f00)
    at ../../gcc/gcc/passes.c:1631
#6  0x084d5ab0 in execute_pass_list (pass=0x8c41d80)
    at ../../gcc/gcc/passes.c:1632
#7  0x085d562a in tree_rest_of_compilation (fndecl=0xb7d88900)
    at ../../gcc/gcc/tree-optimize.c:420
#8  0x0876e5bc in cgraph_expand_function (node=0xb7cf6498)
    at ../../gcc/gcc/cgraphunit.c:1632
#9  0x0876ffd9 in cgraph_expand_all_functions ()
    at ../../gcc/gcc/cgraphunit.c:1711
#10 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1967
#11 0x08770995 in cgraph_finalize_compilation_unit ()
    at ../../gcc/gcc/cgraphunit.c:1171
#12 0x0818863a in cp_write_global_declarations ()
    at ../../gcc/gcc/cp/decl2.c:3925
#13 0x0857c650 in compile_file (argc=19, argv=0xbffff4b4)
---Type <return> to continue, or q <return> to quit---q
 at ../../gcc/gcc/topleQuit
(gdb) frame 4
#4  0x084d5797 in execute_one_pass (pass=0x8c42f00)
    at ../../gcc/gcc/passes.c:1576
1576          todo_after = pass->execute ();
(gdb) p pass->name
$7 = 0x8aa58e2 "vrp"


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #32 from amylaar at gcc dot gnu dot org  2010-07-07 19:53 -------
tree-vrp.c:find_switch_asserts uses compare_case_labels to sort case labels,
with the main key being the uid of the case label.
We have different case labels when debugging, and their uid sorts differently
in relation to user labels that happen to become case labels.

With debug enabled, the label 'half' is sorted at the start of the array:

(gdb) call debug_tree($49[0])
 <case_label_expr 0xb7dab0b4
    type <void_type 0xb7d00840 void asm_written VOID
        align 8 symtab 0 alias set -1 canonical type 0xb7d00840
        pointer_to_this <pointer_type 0xb7d008a0>>
    side-effects tree_1
    arg 0 <integer_cst 0xb7d18300 type <integer_type 0xb7d002a0 int> constant
5>
    arg 2 <label_decl 0xb7d99bd0 half type <void_type 0xb7d00840 void>
        VOID file t.c line 75 col 1
        align 1 context <function_decl 0xb7d88980 ix86_expand_vector_init>
initial <error_mark 0xb7cf07e0> abstract_origin <label_decl 0xb7cf9f18 half>>
    t.c:73:5>
(gdb) call debug_tree((tree)0xb7d99bd0)
 <label_decl 0xb7d99bd0 half
    type <void_type 0xb7d00840 void asm_written VOID
        align 8 symtab 0 alias set -1 canonical type 0xb7d00840
        pointer_to_this <pointer_type 0xb7d008a0>>
    VOID file t.c line 75 col 1
    align 1 context <function_decl 0xb7d88980 ix86_expand_vector_init> initial
<error_mark 0xb7cf07e0> abstract_origin <label_decl 0xb7cf9f18 half>>
(gdb) p ((tree)0xb7d99bd0)->decl_minimal.uid
$50 = 1877
(gdb) call debug_tree($49[1])
 <case_label_expr 0xb7dab024
    type <void_type 0xb7d00840 void asm_written VOID
        align 8 symtab 0 alias set -1 canonical type 0xb7d00840
        pointer_to_this <pointer_type 0xb7d008a0>>
    side-effects tree_1
    arg 2 <label_decl 0xb7d99c24 L.xxxx type <void_type 0xb7d00840 void>
        used ignored VOID file t.c line 95 col 5
        align 1 context <function_decl 0xb7d88980 ix86_expand_vector_init>
abstract_origin <label_decl 0xb7d93000 L.xxxx>>
    t.c:95:5>
(gdb) p ((tree)0xb7d99c24)->decl_minimal.uid
$51 = 1890


With debug disabled, 'half' sorts at the end of the array:

(gdb) call debug_tree($44[3])
 <case_label_expr 0xb7da4090
    type <void_type 0xb7d00840 void VOID
        align 8 symtab 0 alias set -1 canonical type 0xb7d00840
        pointer_to_this <pointer_type 0xb7d008a0>>
    side-effects tree_1
    arg 0 <integer_cst 0xb7d182a0 type <integer_type 0xb7d002a0 int> constant
3>
    arg 1 <integer_cst 0xb7d182d0 type <integer_type 0xb7d002a0 int> constant
4>
    arg 2 <label_decl 0xb7d98c24 L.27 type <void_type 0xb7d00840 void>
        used ignored VOID file t.c line 67 col 5
        align 1 context <function_decl 0xb7d88900 ix86_expand_vector_init>
abstract_origin <label_decl 0xb7cf9e1c L.0>>
    t.c:67:5>
(gdb) call debug_tree($44[4])
 <case_label_expr 0xb7da40b4
    type <void_type 0xb7d00840 void VOID
        align 8 symtab 0 alias set -1 canonical type 0xb7d00840
        pointer_to_this <pointer_type 0xb7d008a0>>
    side-effects tree_1
    arg 0 <integer_cst 0xb7d18300 type <integer_type 0xb7d002a0 int> constant
5>
    arg 2 <label_decl 0xb7d98c78 half type <void_type 0xb7d00840 void>
        used VOID file t.c line 75 col 1
        align 1 context <function_decl 0xb7d88900 ix86_expand_vector_init>
initial <error_mark 0xb7cf07e0> abstract_origin <label_decl 0xb7cf9f18 half>>
    t.c:73:5>
(gdb) p ((tree)0xb7d98c24)->decl_minimal.uid
$46 = 1892
(gdb) p ((tree)0xb7d98c78)->decl_minimal.uid
$47 = 1893


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #33 from amylaar at gcc dot gnu dot org  2010-07-08 01:00 -------
pop_labels_1 installs the LABEL_DECL of half in BLOCK_VARS:

Breakpoint 16, pop_labels_1 (slot=0xb7d86f94, data=0xb7d95068)
    at ../../gcc/gcc/cp/decl.c:384
384       struct named_label_entry *ent = (struct named_label_entry *) *slot;
(gdb) n
387       pop_label (ent->label_decl, NULL_TREE);
(gdb)
391       TREE_CHAIN (ent->label_decl) = BLOCK_VARS (block);

If we are NOT generating debug info, this is cleared in
remove_unused_scope_block_p:

Hardware watchpoint 15: *$11
(gdb) cont
Continuing.
Hardware watchpoint 15: *$11

Old value = (tree) 0xb7cf9f18
New value = (tree) 0x0
remove_unused_scope_block_p (scope=0xb7d86fa4)
    at ../../gcc/gcc/tree-ssa-live.c:427
427       for (t = &BLOCK_VARS (scope); *t; t = next)

Note this code in lines 478ff:
      else if (debug_info_level == DINFO_LEVEL_NORMAL
               || debug_info_level == DINFO_LEVEL_VERBOSE)
        ;
      else
        {
          *t = TREE_CHAIN (*t);
          next = t;
        }

But if we are generating debug info, this BLOCK_VARS setting remains untouched,
and copied in remap_block:

Breakpoint 14, remap_block (block=0xbfffee6c, id=0xbfffef0c)
    at ../../gcc/gcc/tree-inline.c:616
616       BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block),
(gdb) call debug_tree(old_block->block_vars)
There is no member named block_vars.
(gdb) call debug_tree(old_block->block.vars)
 <label_decl 0xb7cf9f18 half
    type <void_type 0xb7d00840 void asm_written VOID
        align 8 symtab 0 alias set -1 canonical type 0xb7d00840
        pointer_to_this <pointer_type 0xb7d008a0>>
    VOID file t.c line 75 col 1
    align 1 context <function_decl 0xb7d88900 ix86_expand_vector_init_general>
initial <error_mark 0xb7cf07e0>>
(gdb) p old_block->block.vars->common.chain
$21 = (tree) 0x0

to be copied later from expand_call_inline ...

We got this with debug info:

Breakpoint 12, expand_call_inline (fn=0xb7d88980)
    at ../../gcc/gcc/tree-inline.c:3872
3872      if (DECL_INITIAL (fn))
(gdb) s
3873        prepend_lexical_block (id->block, remap_blocks (DECL_INITIAL (fn),
id));
(gdb)
remap_blocks (block=0xb7d95750, id=0xbffff028)
    at ../../gcc/gcc/tree-inline.c:634
634       if (!block)
(gdb) call debug_tree(block)
 <block 0xb7d95750 used
    vars <label_decl 0xb7d99738 half
        type <void_type 0xb7d00840 void asm_written VOID
            align 8 symtab 0 alias set -1 canonical type 0xb7d00840
            pointer_to_this <pointer_type 0xb7d008a0>>
        VOID file t.c line 75 col 1
        align 1 context <function_decl 0xb7d88c00
_ZL31ix86_expand_vector_init_generalb12machine_modeP7rtx_defS1_.isra.0> initial
<error_mark 0xb7cf07e0> abstract_origin <label_decl 0xb7cf9f18 half>>
    subblocks <block 0xb7d95784 used
        vars <var_decl 0xb7d97780 ops type <array_type 0xb7d8cf00>
            addressable used tree_1 decl_5 BLK file t.c line 61 col 13
            size <integer_cst 0xb7d7f5a0 constant 1024>
            unit size <integer_cst 0xb7d901c8 constant 128>
            align 32 context <function_decl 0xb7d88c00
_ZL31ix86_expand_vector_init_generalb12machine_modeP7rtx_defS1_.isra.0>
abstract_origin <var_decl 0xb7d91060 ops> chain <var_decl 0xb7d977e0 n>>
supercontext <block 0xb7d95750>
        subblocks <block 0xb7d957b8 used supercontext <block 0xb7d95784>
            abstract_origin <block 0xb7d95000 used vars <var_decl 0xb7d914e0
n_words>
                supercontext <block 0xb7d95034 used vars <var_decl 0xb7d91060
ops>
                    supercontext <block 0xb7d95068 used vars <label_decl
0xb7cf9f18 half> supercontext <function_decl 0xb7d88900
ix86_expand_vector_init_general> subblocks <block 0xb7d95034>> subblocks <block
0xb7d95000>>>> abstract_origin <block 0xb7d95034>> abstract_origin <block
0xb7d95068>>

and that gets the LABEL_DECL an expedited copy with a relatively low uid:

Hardware watchpoint 10: *$11

Old value = 1853
New value = 1877
0x086ee9cc in copy_node_stat (node=0xb7d99738) at ../../gcc/gcc/tree.c:966
966               DECL_UID (t) = next_decl_uid++;
(gdb) bt
#0  0x086ee9cc in copy_node_stat (node=0xb7d99738) at ../../gcc/gcc/tree.c:966
#1  0x087a315d in copy_decl_no_change (decl=0xb7d99738, id=0xbffff028)
    at ../../gcc/gcc/tree-inline.c:4782
#2  0x087a427c in remap_decl (decl=0xb7d99738, id=0xbffff028)
    at ../../gcc/gcc/tree-inline.c:288
#3  0x087a5534 in remap_decls (decls=<value optimized out>,
    nonlocalized_list=0xb7d95940, id=0xbffff028)
    at ../../gcc/gcc/tree-inline.c:557
#4  0x087a58db in remap_block (block=0xbfffef8c, id=0xbffff028)
    at ../../gcc/gcc/tree-inline.c:616
#5  0x087a5a5e in remap_blocks (block=0xb7d95750, id=0xbffff028)
    at ../../gcc/gcc/tree-inline.c:637
#6  0x087affe0 in expand_call_inline (fn=0xb7d88980)
    at ../../gcc/gcc/tree-inline.c:3873
#7  gimple_expand_calls_inline (fn=0xb7d88980)
    at ../../gcc/gcc/tree-inline.c:4057
#8  optimize_inline_calls (fn=0xb7d88980) at ../../gcc/gcc/tree-inline.c:4207
#9  0x0877e62d in cgraph_early_inlining () at ../../gcc/gcc/ipa-inline.c:1740
#10 0x084d57c7 in execute_one_pass (pass=0x8cdd8e8)
    at ../../gcc/gcc/passes.c:1576
#11 0x084d5acd in execute_pass_list (pass=0x8cdd8e8)
    at ../../gcc/gcc/passes.c:1631
#12 0x084d32d3 in do_per_function_toporder (
    callback=0x84d5ab0 <execute_pass_list>, data=0x8c47c80)
    at ../../gcc/gcc/passes.c:1154
#13 0x084d5b3d in execute_ipa_pass_list (pass=0x8c47b80)
    at ../../gcc/gcc/passes.c:1931
#14 0x08775c84 in ipa_passes () at ../../gcc/gcc/cgraphunit.c:1854
#15 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1923
#16 0x08776435 in cgraph_finalize_compilation_unit ()
    at ../../gcc/gcc/cgraphunit.c:1171
#17 0x0818866a in cp_write_global_declarations ()
    at ../../gcc/gcc/cp/decl2.c:3925
#18 0x0857c680 in compile_file (argc=21, argv=0xbffff494)
    at ../../gcc/gcc/toplev.c:1024
#19 do_compile (argc=21, argv=0xbffff494) at ../../gcc/gcc/toplev.c:2377
#20 toplev_main (argc=21, argv=0xbffff494) at ../../gcc/gcc/toplev.c:2419
#21 0x082b062b in main (argc=21, argv=0xbffff494) at ../../gcc/gcc/main.c:35

whereas in the non-debug case, half is not in such a prominent position:

Breakpoint 11, expand_call_inline (fn=0xb7d88900)
    at ../../gcc/gcc/tree-inline.c:3872
3872      if (DECL_INITIAL (fn))
(gdb) s
3873        prepend_lexical_block (id->block, remap_blocks (DECL_INITIAL (fn),
id));
(gdb)
remap_blocks (block=0xb7d946b4, id=0xbffff048)
    at ../../gcc/gcc/tree-inline.c:634
634       if (!block)
(gdb) call debug_tree(block)
 <block 0xb7d946b4 used
    subblocks <block 0xb7d946e8 used
        vars <var_decl 0xb7d95780 ops type <array_type 0xb7d8cf00>
            addressable used tree_1 decl_5 BLK file t.c line 61 col 13
            size <integer_cst 0xb7d7f5a0 constant 1024>
            unit size <integer_cst 0xb7d8f168 constant 128>
            align 32 context <function_decl 0xb7d88b80
_ZL31ix86_expand_vector_init_generalb12machine_modeP7rtx_defS1_.isra.0>
abstract_origin <var_decl 0xb7d90060 ops> chain <var_decl 0xb7d957e0 n>>
supercontext <block 0xb7d946b4>
        subblocks <block 0xb7d9471c used supercontext <block 0xb7d946e8>
            abstract_origin <block 0xb7d86f3c used
                supercontext <block 0xb7d86f70 used vars <var_decl 0xb7d90060
ops>
                    supercontext <block 0xb7d86fa4 used supercontext
<function_decl 0xb7d88880 ix86_expand_vector_init_general> subblocks <block
0xb7d86f70>> subblocks <block 0xb7d86f3c>>>> abstract_origin <block
0xb7d86f70>> abstract_origin <block 0xb7d86fa4>>


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #34 from amylaar at gcc dot gnu dot org  2010-07-08 01:10 -------
FWIW, this simple patch stops the comparison failures both for my reduced
testcase as for the original testcase.  I'm not sure if we want to
pay the price of carryinig more labels around for -g0, or if we'd rather
fix the ordering issues somehow.

Index: tree-ssa-live.c
===================================================================
--- tree-ssa-live.c     (revision 160832)
+++ tree-ssa-live.c     (working copy)
@@ -476,7 +476,8 @@ remove_unused_scope_block_p (tree scope)
         type is used or not.  */

       else if (debug_info_level == DINFO_LEVEL_NORMAL
-              || debug_info_level == DINFO_LEVEL_VERBOSE)
+              || debug_info_level == DINFO_LEVEL_VERBOSE
+              || 1)
        ;
       else
        {


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenther at suse dot de]

------- Comment #35 from rguenther at suse dot de  2010-07-08 08:46 -------
Subject: Re:  [4.6 Regression] -fcompare-debug failure for
 C++ i386.c

On Thu, 8 Jul 2010, amylaar at gcc dot gnu dot org wrote:

> ------- Comment #34 from amylaar at gcc dot gnu dot org  2010-07-08 01:10 -------
> FWIW, this simple patch stops the comparison failures both for my reduced
> testcase as for the original testcase.  I'm not sure if we want to
> pay the price of carryinig more labels around for -g0, or if we'd rather
> fix the ordering issues somehow.

The ordering issue in VRP needs to be fixed.  The sorting can use
LABEL_DECL_UID which is dense in a given function.  (but watch out
for a -1 value where no UID has been assigned)

Richard.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #36 from amylaar at gcc dot gnu dot org  2010-07-08 11:04 -------
(In reply to comment #35)

> The ordering issue in VRP needs to be fixed.  The sorting can use
> LABEL_DECL_UID which is dense in a given function.  (but watch out
> for a -1 value where no UID has been assigned)

I think that is too late; it would solve this particular failure, but AAUI,
once we allow the relative order of decl_uids to become random, we've lost.

There is also the wider issue that this entire business of allowing decl_uids
to drift as long as ordering is preserved makes impossible to use dump
comparisons as an effective means to determine in what pass things go wrong.
It appears that in general, we use negative decl_uids for debug symbols, yet
we may retain / copy non-debug symbols for reasons of debugging and let
them have positive numbers.
I wonder if it would be feasible to allocate new negative the uids for such
symbols when they only remain for purposes of debugging, and when we somehow
end up merging a debug and non-debug copy, the non-debug with its positive
decl_uid should prevail.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenther at suse dot de]

------- Comment #37 from rguenther at suse dot de  2010-07-08 11:31 -------
Subject: Re:  [4.6 Regression] -fcompare-debug failure for
 C++ i386.c

On Thu, 8 Jul 2010, amylaar at gcc dot gnu dot org wrote:

> ------- Comment #36 from amylaar at gcc dot gnu dot org  2010-07-08 11:04 -------
> (In reply to comment #35)
> 
> > The ordering issue in VRP needs to be fixed.  The sorting can use
> > LABEL_DECL_UID which is dense in a given function.  (but watch out
> > for a -1 value where no UID has been assigned)
> 
> I think that is too late; it would solve this particular failure, but AAUI,
> once we allow the relative order of decl_uids to become random, we've lost.

?  We don't allow the relative order of decl_uids to become random.  Where
do you think that happens?

> There is also the wider issue that this entire business of allowing decl_uids
> to drift as long as ordering is preserved makes impossible to use dump
> comparisons as an effective means to determine in what pass things go wrong.
> It appears that in general, we use negative decl_uids for debug symbols, yet
> we may retain / copy non-debug symbols for reasons of debugging and let
> them have positive numbers.

This is what we have the -nouid modifier for.

> I wonder if it would be feasible to allocate new negative the uids for such
> symbols when they only remain for purposes of debugging, and when we somehow
> end up merging a debug and non-debug copy, the non-debug with its positive
> decl_uid should prevail.

?  You have lost me here again.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #38 from rguenth at gcc dot gnu dot org  2010-07-08 11:45 -------

Index: gcc/tree-vrp.c
===================================================================
--- gcc/tree-vrp.c      (revision 161949)
+++ gcc/tree-vrp.c      (working copy)
@@ -4534,12 +4538,11 @@ compare_case_labels (const void *p1, con
 {
   const_tree const case1 = *(const_tree const*)p1;
   const_tree const case2 = *(const_tree const*)p2;
-  unsigned int uid1 = DECL_UID (CASE_LABEL (case1));
-  unsigned int uid2 = DECL_UID (CASE_LABEL (case2));
+  unsigned int uid1 = LABEL_DECL_UID (CASE_LABEL (case1));
+  unsigned int uid2 = LABEL_DECL_UID (CASE_LABEL (case2));

-  if (uid1 < uid2)
-    return -1;
-  else if (uid1 == uid2)
+  if (uid1 == uid2
+      || uid1 == -1u || uid2 == -1u)
     {
       /* Make sure the default label is first in a group.  */
       if (!CASE_LOW (case1))
@@ -4549,8 +4552,7 @@ compare_case_labels (const void *p1, con
       else
         return tree_int_cst_compare (CASE_LOW (case1), CASE_LOW (case2));
     }
-  else
-    return 1;
+  return uid1 < uid2 ? -1 : 1;
 }

fixes the testcase.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #39 from rguenth at gcc dot gnu dot org  2010-07-08 11:49 -------
So you say during inlining we end up generating DECL copies in a different
_order_ comparing debug vs. non-debug cases?  That would be a bug as well.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #40 from rguenth at gcc dot gnu dot org  2010-07-08 11:53 -------
Indeed we do.  -g vs. -g0 diff of non-debug decl copying:

--- x   2010-07-08 13:51:02.000000000 +0200
+++ y   2010-07-08 13:51:09.000000000 +0200
@@ -476,12 +476,14 @@
 mode
 target
 vals
+half
 ops
 op0
 op1
 half_mode
 n
 i
+code
 rt
 rt
 i
@@ -496,27 +498,25 @@
 elt
 tmp
 tmp
-D.3581
-D.3582
-D.3583
+arg0
 D.3584
 D.3585
 D.3586
 D.3587
 D.3588
-word_mode.14
+D.3589
 D.3590
 D.3591
-D.3592
+word_mode.14
 D.3593
 D.3594
 D.3595
 D.3596
 D.3597
-inner_mode.13
+D.3598
 D.3599
 D.3600
-D.3601
+inner_mode.13
 D.3602
 D.3603
 D.3604
@@ -527,8 +527,11 @@
 D.3609
 D.3610
 D.3611
-ix86_isa_flags.12
+D.3612
 D.3613
+D.3614
+ix86_isa_flags.12
+D.3616
 mode.11
 <L36>
 <L59>
@@ -536,7 +539,6 @@
 <L23>
 <L25>
 <L4>
-half
 <L18>
 <retval>


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #41 from amylaar at gcc dot gnu dot org  2010-07-08 12:01 -------
(In reply to comment #39)
> So you say during inlining we end up generating DECL copies in a different
> _order_ comparing debug vs. non-debug cases?  That would be a bug as well.

Indeed we do; once that is fixed, the vrp ordering should be fixed as well.


(In reply to comment #37)
> This is what we have the -nouid modifier for.

But this doesn't allow us to use diff to tell if the relative order is
OK in one dump while messed up in the other.
It hides all the ordering problems, so this option is no good at all to
track down the pass where things go wrong.

> > I wonder if it would be feasible to allocate new negative the uids for such
Should have read:
I wonder if it would be feasible to allocate new negative uids for such
> > symbols when they only remain for purposes of debugging, and when we somehow
> > end up merging a debug and non-debug copy, the non-debug with its positive
> > decl_uid should prevail.
> 
> ?  You have lost me here again.

That's a tentative idea how not only the ordering problem could be solved,
but also the debug/no-debug variance of decl_uids on declarations / labels
that are present in the no-debug output, to allow for meaningful diffs.

I haven't tried to implement this yet, though.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #42 from amylaar at gcc dot gnu dot org  2010-07-08 12:08 -------
(In reply to comment #40)
> Indeed we do.  -g vs. -g0 diff of non-debug decl copying:

How did you get this dump?  Enumerating DECLs like this in (-nouid) dump
files seems to be an alternative way to solve the dump diff problem.



-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #43 from rguenth at gcc dot gnu dot org  2010-07-08 12:33 -------
I placed a debug_generic_expr () in copy_node_stat and re-directed output ...

Now, I see that in the non-debug case we are copying the LABEL_DECL while
copying statements while in the debug case we are copying it while
copying the block tree.  We have to preserve used labels in
the block tree it's just not trivial to do unless we resort to setting
TREE_USED.

Which would be the following, which also fixes the failure.

Index: tree-ssa-live.c
===================================================================
--- tree-ssa-live.c     (revision 161949)
+++ tree-ssa-live.c     (working copy)
@@ -384,6 +384,9 @@ mark_all_vars_used_1 (tree *tp, int *wal
       set_is_used (t);
     }

+  if (TREE_CODE (t) == LABEL_DECL)
+    TREE_USED (t) = true;
+
   if (IS_TYPE_OR_DECL_P (t))
     *walk_subtrees = 0;

@@ -448,6 +451,13 @@ remove_unused_scope_block_p (tree scope)
       else if (TREE_CODE (*t) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (*t))
        unused = false;

+      /* Labels that are still used in the IL we have to preserve in
+         the block tree as well, otherwise we risk having different
+        ordering in debug vs. non-debug builds during inlining
+        or versioning.  */
+      else if (TREE_CODE (*t) == LABEL_DECL && TREE_USED (*t))
+       unused = false;
+
       /* Remove everything we don't generate debug info for.  */
       else if (DECL_IGNORED_P (*t))
        {


we don't have var annotations for LABEL_DECLs, so a proper solution
would use a bitmap of UIDs to preserve here I guess.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #44 from amylaar at gcc dot gnu dot org  2010-07-08 15:54 -------
(In reply to comment #43)
> Now, I see that in the non-debug case we are copying the LABEL_DECL while
> copying statements while in the debug case we are copying it while
> copying the block tree.  We have to preserve used labels in
> the block tree it's just not trivial to do unless we resort to setting
> TREE_USED.
> 
> Which would be the following, which also fixes the failure.

I have done a --enable-build-with-cxx bootstrap of trunk trevision 161952
with this patch applied (with tabs for leading whitespace in the comment).
The bootstrap finished successfully, and the regression test results
look reasonable, although I still have to generate baseline results to
compare this to.

I have submitted PR other/44874 to track the shortcomings of our debugging
dumps for finding DECL_UID ordering issues.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenther at suse dot de]

------- Comment #45 from rguenther at suse dot de  2010-07-08 16:05 -------
Subject: Re:  [4.6 Regression] -fcompare-debug failure for
 C++ i386.c

On Thu, 8 Jul 2010, amylaar at gcc dot gnu dot org wrote:

> ------- Comment #44 from amylaar at gcc dot gnu dot org  2010-07-08 15:54 -------
> (In reply to comment #43)
> > Now, I see that in the non-debug case we are copying the LABEL_DECL while
> > copying statements while in the debug case we are copying it while
> > copying the block tree.  We have to preserve used labels in
> > the block tree it's just not trivial to do unless we resort to setting
> > TREE_USED.
> > 
> > Which would be the following, which also fixes the failure.
> 
> I have done a --enable-build-with-cxx bootstrap of trunk trevision 161952
> with this patch applied (with tabs for leading whitespace in the comment).
> The bootstrap finished successfully, and the regression test results
> look reasonable, although I still have to generate baseline results to
> compare this to.

Using TREE_USED isn't really applicable here (we do never re-set it
at least).  So an option would be to unconditionally preserve all
!DECL_INGNORED_P labels in BLOCKs.  Or play fancy with a bitmap
or a pointer-map.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #46 from amylaar at gcc dot gnu dot org  2010-07-08 17:21 -------
(In reply to comment #45)
> Using TREE_USED isn't really applicable here (we do never re-set it
> at least).  So an option would be to unconditionally preserve all
> !DECL_INGNORED_P labels in BLOCKs.

Which is what my provisional patch was doing, although it'd need better
commenting and deletion of dead tests / code.

> Or play fancy with a bitmap
> or a pointer-map.

Could we use a different bit that is currently unused for LABEL_DECLs?
(With a suitable accessor macro, of course.)

The name of base.public_flag sounds about right, but might be a bit
dangerous considering the unguarded TREE_PUBLIC accessor and possible
mix-ups when code is meant to test TREE_PUBLIC of declarations.

OTOH it seems that we could safely snarf base.nothrow_flag for LABEL_DECLs.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #47 from amylaar at gcc dot gnu dot org  2010-07-08 20:00 -------
Created an attachment (id=21150)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21150&action=view)
proposed patch

(In reply to comment #46)
> Could we use a different bit that is currently unused for LABEL_DECLs?
> (With a suitable accessor macro, of course.)

Hmm, actually, there should be no problem with changing TREE_USED of a
LABEL_DECL once lang_hooks.parse_file is done with emitting warnings about
undefined-but-used / used-but-not-defined labels.

The problem is clearing them all at or before the start of
remove_unused_locals. It's be easy to do in one frontend, when we do the
warnings, but requiring all the frontends to do it is messy, and it when
remove_unused_locals is called multiple times that'd not reset the used flag
for labels the used of which have been optimized away in the meantime.

I think the TREE_USED as given from the frontends is probably a good enough
approximation if we also take DECL_IGNORED_P into account.

As it happens, TREE_USED is actually cleared by init_vars_expansion, although,
as stated before, it should be good enough without that.

I'm currently testing the attached patch.

Regarding a testcase for our testsuite, I think that would best be done in the
context of PR other/44874.  Although we should be able to reproducibly get
scrabled DECL_UIDs with the old compiler logic, having this translate into
different ssa name versioning or even generated code is less reliable when
you change bits of the compiler or the compiler host / target.
With a dump option to enumerate declarations / labels in DECL_UID order, the
regression test can verify that order matches.
I think this dump option should be default for -fcompare-debug; in that case,
the testcase should be relatively simple.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #48 from amylaar at gcc dot gnu dot org  2010-07-09 03:38 -------
(In reply to comment #47) 
> I'm currently testing the attached patch.
Successfully bootstrapped & ergtested in trunk revision 161952, both
with & without --enable-build-with-cxx.
The only difference in the test results to the baseline was that a timeout
for libmudflap.cth/pass40-frag.c went away to change a pair of FAILs to a pair
of PASSes; this is one of the test that now and then times out on my machine,
depending on load.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #49 from amylaar at gcc dot gnu dot org  2010-07-09 10:02 -------
I'm working on a fix for 44874, it it seems we are missing references of
LABEL_DECLs by gotos.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #50 from amylaar at gcc dot gnu dot org  2010-07-09 11:38 -------
Created an attachment (id=21157)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21157&action=view)
combined ptch for 44832/44874 - WIP

For the unreduced testcase, I see differences regarding the labels do_subreg,
done, and widen.
Any idea why the LABEL_DECLs are kept only when emitting debug information?


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #51 from rguenth at gcc dot gnu dot org  2010-07-09 11:47 -------
(In reply to comment #50)
> Created an attachment (id=21157)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21157&action=view) [edit]
> combined ptch for 44832/44874 - WIP
> 
> For the unreduced testcase, I see differences regarding the labels do_subreg,
> done, and widen.
> Any idea why the LABEL_DECLs are kept only when emitting debug information?

because they are not used?

@@ -477,7 +490,16 @@ remove_unused_scope_block_p (tree scope)
         type is used or not.  */

       else if (debug_info_level == DINFO_LEVEL_NORMAL
-              || debug_info_level == DINFO_LEVEL_VERBOSE)
+              || debug_info_level == DINFO_LEVEL_VERBOSE
+              /* For labels that are still used in the IL, the decision
+                 to preserve them must not depend DEBUG_INFO_LEVEL,
+                 otherwise we risk having different ordering in debug vs.
+                 non-debug builds during inlining or versioning.
+                 A label appearing here (we have already checked
+                 DECL_IGNORED_P) should not be used in the IL unless it has
+                 been explicitly used before, so we use TREE_USED as an
+                 approximation.  */
+              || (TREE_CODE (*t) == LABEL_DECL && TREE_USED (*t)))

please instead add a similar case to that of
TREE_CODE (*t) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (*t) instead of
amending the debuginfo level checks.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #52 from amylaar at gcc dot gnu dot org  2010-07-09 15:06 -------
(In reply to comment #49)
> I'm working on a fix for 44874, it it seems we are missing references of
> LABEL_DECLs by gotos.

Actually, they are marked used when the GIMPLE_LABEL itself is processed.
The problem I was seeing was due to scope blocks vanishing.


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #53 from amylaar at gcc dot gnu dot org  2010-07-10 04:44 -------
A patch has been posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00840.html


-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #54 from amylaar at gcc dot gnu dot org  2010-07-10 09:40 -------
Subject: Bug 44832

Author: amylaar
Date: Sat Jul 10 09:40:36 2010
New Revision: 162035

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162035
Log:
2010-07-10  Richard Guenther  <rguenther@suse.de>
            Joern Rennecke  <joern.rennecke@embecosm.com>

        PR debug/44832
        * tree-ssa-live.c (mark_all_vars_used_1): Set TREE_USED for
        LABEL_DECL.
        (remove_unused_scope_block_p): Don't drop TREE_USED LABEL_DECLs
        unless they have DECL_IGNORED_P set.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-live.c


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

------- Comment #55 from rguenth at gcc dot gnu dot org  2010-07-12 08:06 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[amylaar at gcc dot gnu dot org]

------- Comment #56 from amylaar at gcc dot gnu dot org  2010-07-13 21:56 -------
Subject: Bug 44832

Author: amylaar
Date: Tue Jul 13 21:55:57 2010
New Revision: 162156

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162156
Log:
gcc:
        PR other/44874
        * tree-dump.c (dump_options): Add enumerate_locals entry.
        Add TDF_NOID exclusion to all entry.
        * tree-dump.h (dump_enumerated_decls): Declare.
        * tree-pretty-print.c (dump_generic_node): For TDF_NOID,
        Don't display type uid.
        (print_declaration): Don't crash on TREE_TYPE (t) == 0.
        * tree-pass.h (TDF_ENUMERATE_LOCALS): Define.
        * tree-ssa-live.c: Include gimple.h.
        (numbered_tree_d): New struct.
        (numbered_tree): New typedef.
        (DEF_VEC_O (numbered_tree): New.
        (DEF_VEC_ALLOC_O (numbered_tree, heap)): Likewise.
        (compare_decls_by_uid, dump_enumerated_decls_push): New functions.
        (dump_enumerated_decls): Likewise.
        * tree-optimize.c (execute_cleanup_cfg_post_optimizing): If comparing
        debug info and flag_dump_final_insns, call dump_enumerated_decls.
        * tree-cfg.c (dump_function_to_file): Call dump_enumerated_decls.
        * Makefile.in (tree-ssa-live.o): Depend on $(GIMPLE_H).
gcc/testsuite:
        PR other/44874
        PR debug/44832
        * c-c++-common/pr44832.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/pr44832.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-cfg.c
    trunk/gcc/tree-dump.c
    trunk/gcc/tree-dump.h
    trunk/gcc/tree-optimize.c
    trunk/gcc/tree-pass.h
    trunk/gcc/tree-pretty-print.c
    trunk/gcc/tree-ssa-live.c


-- 


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[aoliva at gcc dot gnu.org]

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

--- Comment #57 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-10-13 20:26:06 UTC ---
Author: aoliva
Date: Wed Oct 13 20:26:02 2010
New Revision: 165434

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165434
Log:
PR debug/44832
* tree-ssa-live.c (mark_all_vars_used_1): Set TREE_USED for
LABEL_DECL.
(remove_unused_scope_block_p): Don't drop TREE_USED LABEL_DECLs
unless they have DECL_IGNORED_P set.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/tree-ssa-live.c