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=gccview=revrev=165434
Log:
PR debug/44832
*
--- 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=gccview=revrev=162156
Log:
gcc:
PR other/44874
* tree-dump.c
--- 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
--- 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=gccview=revrev=162035
Log:
2010-07-10 Richard Guenther rguent...@suse.de
--- 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
--- 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=21157action=view)
combined ptch for 44832/44874 - WIP
For the unreduced testcase, I see differences regarding the labels
--- 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=21157action=view) [edit]
combined ptch for 44832/44874 - WIP
For the unreduced testcase, I see
--- 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
--- 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
--- 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
---
--- 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
--- 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
--- 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 @@
--- 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
--- 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.0 +0200
+++ y 2010-07-08 13:51:09.0 +0200
@@ -476,12 +476,14 @@
mode
target
vals
+half
ops
op0
op1
--- 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,
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=21150action=view)
proposed patch
(In reply to comment #46)
Could we use a different bit that is currently unused for
--- 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
--- 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
--- 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
--
--- 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.einline22010-07-07 13:59:11.451101846 +0100
@@
--- 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.
--
--- 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
--- 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?
--
--- 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.
--
--- 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
--- 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=21123action=view)
typescript looking at inrements of next_decl_uid
The last ssa name before 1881 in the dump files is 1872; so
--- 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
--- 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
--- 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
--- 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=21124action=view)
less reduced testcase
Reduced at topformflat level 0 only.
--
--- 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=21125action=view)
diff -u -I '^ # DEBUG.*$' t.c.093t.pre t.c.gk.093t.pre
Disregarding where merely the base names of ssa name
--- 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
--- 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
--- 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),
--- 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?
--
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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).
--
--- 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
--- 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=21117action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- 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
--- 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++
54 matches
Mail list logo
