public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/45419] New: -fcompare-debug failure at -O3
@ 2010-08-26 17:09 zsojka at seznam dot cz
2010-08-26 17:13 ` [Bug debug/45419] " zsojka at seznam dot cz
` (18 more replies)
0 siblings, 19 replies; 21+ messages in thread
From: zsojka at seznam dot cz @ 2010-08-26 17:09 UTC (permalink / raw)
To: gcc-bugs
Command line:
$ gcc -fcompare-debug -O3 testcase-min6.i
Compiler output:
$ gcc -fcompare-debug -O3 testcase-min6.i -w
gcc: error: testcase-min6.i: -fcompare-debug failure (length)
Tested revisions:
r163468 - fail
r162940 - OK
r161659 - OK
r161170 - OK
The failure keeps appearing and disappearing when little changes are made - in
the original testcase, even removing -pipe or adding -save-temps caused the
failure to disappear.
--
Summary: -fcompare-debug failure at -O3
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
@ 2010-08-26 17:13 ` zsojka at seznam dot cz
2010-08-26 17:46 ` hjl dot tools at gmail dot com
` (17 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: zsojka at seznam dot cz @ 2010-08-26 17:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from zsojka at seznam dot cz 2010-08-26 17:12 -------
Created an attachment (id=21572)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21572&action=view)
testcase
Delta (with line granularity) fails to reduce the file further. The difference
in debug and non-debug runs is very small:
$ diff pr45419.*gkd
19581c19581
< (compare:CCZ (mem/c:QI (symbol_ref:DI ("buf.3274") [flags 0x2]
<var_decl # buf>) [ MEM[(char *)&buf]+0 S1 A256])
---
> (compare:CCZ (mem/c:QI (symbol_ref:DI ("buf.3274") [flags 0x2] <var_decl # buf>) [ MEM[(const char *)&buf]+0 S1 A256])
19913c19913
< (compare:CCZ (mem/c:QI (symbol_ref:DI ("buf.3274") [flags 0x2]
<var_decl # buf>) [ MEM[(char *)&buf]+0 S1 A256])
---
> (compare:CCZ (mem/c:QI (symbol_ref:DI ("buf.3274") [flags 0x2] <var_decl # buf>) [ MEM[(const char *)&buf]+0 S1 A256])
only "const" is missing/added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
2010-08-26 17:13 ` [Bug debug/45419] " zsojka at seznam dot cz
@ 2010-08-26 17:46 ` hjl dot tools at gmail dot com
2010-08-26 17:58 ` jakub at gcc dot gnu dot org
` (16 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: hjl dot tools at gmail dot com @ 2010-08-26 17:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from hjl dot tools at gmail dot com 2010-08-26 17:46 -------
I can't reproduce it on Fedora 13. But valgrind reports:
Compiler executable checksum: d32748fe5bfee4f2f9ecf4e95f2e1498
==17242== Conditional jump or move depends on uninitialised value(s)
==17242== at 0x7ED1AF: walk_gimple_stmt (gimple.c:1627)
==17242== by 0xB20D9E: dump_enumerated_decls (tree-ssa-live.c:1261)
==17242== by 0xA7CD39: execute_cleanup_cfg_post_optimizing
(tree-optimize.c:214)
==17242== by 0x8F342C: execute_one_pass (passes.c:1568)
==17242== by 0x8F3615: execute_pass_list (passes.c:1623)
==17242== by 0xA7D3D3: tree_rest_of_compilation (tree-optimize.c:452)
==17242== by 0xD0BB5E: cgraph_expand_function (cgraphunit.c:1469)
==17242== by 0xD0BDF6: cgraph_expand_all_functions (cgraphunit.c:1548)
==17242== by 0xD0C41B: cgraph_optimize (cgraphunit.c:1804)
==17242== by 0xD09E6C: cgraph_finalize_compilation_unit (cgraphunit.c:1012)
==17242== by 0x4B238D: c_write_global_declarations (c-decl.c:9735)
==17242== by 0x9EA743: compile_file (toplev.c:983)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
2010-08-26 17:13 ` [Bug debug/45419] " zsojka at seznam dot cz
2010-08-26 17:46 ` hjl dot tools at gmail dot com
@ 2010-08-26 17:58 ` jakub at gcc dot gnu dot org
2010-08-26 18:37 ` zsojka at seznam dot cz
` (15 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-08-26 17:58 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from jakub at gcc dot gnu dot org 2010-08-26 17:58 -------
Unfortunately can't reproduce it myself, neither with bootstrapped, nor with
just stage1 built gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (2 preceding siblings ...)
2010-08-26 17:58 ` jakub at gcc dot gnu dot org
@ 2010-08-26 18:37 ` zsojka at seznam dot cz
2010-08-26 19:49 ` hjl dot tools at gmail dot com
` (14 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: zsojka at seznam dot cz @ 2010-08-26 18:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from zsojka at seznam dot cz 2010-08-26 18:37 -------
Created an attachment (id=21574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21574&action=view)
different testcase
Thank you for answers! This not yet reduced testcase fails in a similiar way
(r163468, x86_64-linux). It needs only -O2 to reproduce.
$ gcc -std=gnu++0x -fcompare-debug -O2 040.ii -w
gcc: error: 040.ii: -fcompare-debug failure (length)
$ diff 040.*gkd
54739c54739
< (const_int 8 [0x8]))) [ MEM[(const struct OverflowSafeInt
&)&CMD_ERROR + 8].m_value+0 S8 A64])
---
> (const_int 8 [0x8]))) [ MEM[(struct OverflowSafeInt *)&CMD_ERROR + 8B].m_value+0 S8 A64])
It shows 3 differences:
missing const
& -> * (PR45408)
8 -> 8B
Information about gcc used:
$ /mnt/svn/gcc-trunk/binary-163468-lto-fortran-checking-yes-rtl-df/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-163468-lto-fortran-checking-yes-rtl-df/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-163468-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk/configure
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-163468-lto-fortran-checking-yes-rtl-df/
--enable-checking=yes,rtl,df
Thread model: posix
gcc version 4.6.0 20100823 (experimental) (GCC)
$ cat /proc/sys/kernel/randomize_va_space
0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (3 preceding siblings ...)
2010-08-26 18:37 ` zsojka at seznam dot cz
@ 2010-08-26 19:49 ` hjl dot tools at gmail dot com
2010-08-26 20:02 ` hjl dot tools at gmail dot com
` (13 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: hjl dot tools at gmail dot com @ 2010-08-26 19:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from hjl dot tools at gmail dot com 2010-08-26 19:48 -------
valgrind issue is caused by revision 162156:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00510.html
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amylaar at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (4 preceding siblings ...)
2010-08-26 19:49 ` hjl dot tools at gmail dot com
@ 2010-08-26 20:02 ` hjl dot tools at gmail dot com
2010-08-30 12:53 ` jakub at gcc dot gnu dot org
` (12 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: hjl dot tools at gmail dot com @ 2010-08-26 20:02 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from hjl dot tools at gmail dot com 2010-08-26 20:02 -------
(In reply to comment #4)
> Created an attachment (id=21574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21574&action=view) [edit]
> different testcase
>
> Thank you for answers! This not yet reduced testcase fails in a similiar way
> (r163468, x86_64-linux). It needs only -O2 to reproduce.
>
> $ gcc -std=gnu++0x -fcompare-debug -O2 040.ii -w
> gcc: error: 040.ii: -fcompare-debug failure (length)
> $ diff 040.*gkd
> 54739c54739
> < (const_int 8 [0x8]))) [ MEM[(const struct OverflowSafeInt
> &)&CMD_ERROR + 8].m_value+0 S8 A64])
> ---
> > (const_int 8 [0x8]))) [ MEM[(struct OverflowSafeInt *)&CMD_ERROR + 8B].m_value+0 S8 A64])
>
> It shows 3 differences:
> missing const
> & -> * (PR45408)
> 8 -> 8B
>
>
This is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00006.html
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu dot
| |org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2010-08-26 20:02:30
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (5 preceding siblings ...)
2010-08-26 20:02 ` hjl dot tools at gmail dot com
@ 2010-08-30 12:53 ` jakub at gcc dot gnu dot org
2010-08-30 14:05 ` jakub at gcc dot gnu dot org
` (11 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-08-30 12:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from jakub at gcc dot gnu dot org 2010-08-30 12:53 -------
Created an attachment (id=21593)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21593&action=view)
gcc46-pr45419.patch
Fix for the valgrind issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (6 preceding siblings ...)
2010-08-30 12:53 ` jakub at gcc dot gnu dot org
@ 2010-08-30 14:05 ` jakub at gcc dot gnu dot org
2010-08-30 14:29 ` jakub at gcc dot gnu dot org
` (10 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-08-30 14:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from jakub at gcc dot gnu dot org 2010-08-30 14:05 -------
The other issue comes from MEM_ATTRS caching.
mem_attrs_htab_eq
considers MEM_EXPR to be equal if:
279 && (p->expr == q->expr
280 || (p->expr != NULL_TREE && q->expr != NULL_TREE
281 && operand_equal_p (p->expr, q->expr, 0))));
With -g there happens to be a different MEM_ATTRS in the cache than without -g,
and as both are operand_equal_p, gcc doesn't care which one it chooses.
As -fcompare-debug does a textual comparison, I guess we'd for
-fdump-final-insns need to dump something that is stable. E.g. it could print
just iterative_hash_expr (MEM_EXPR (memref), 0) instead of printing the
expression. I'm not sure whether that would fix this completely, because
I believe if there are collisions, mem_attrs_htab_eq could return true even if
mem_attrs_htab_hash is different. Therefore perhaps mem_attrs_htab_eq should
also check (size_t) iterative_hash_expr (p->expr, 0) == (size_t)
iterative_hash_expr (q->expr, 0) if operand_equal_p returned true.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (7 preceding siblings ...)
2010-08-30 14:05 ` jakub at gcc dot gnu dot org
@ 2010-08-30 14:29 ` jakub at gcc dot gnu dot org
2010-08-30 14:30 ` rguenther at suse dot de
` (9 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-08-30 14:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from jakub at gcc dot gnu dot org 2010-08-30 14:29 -------
Unfortunately printing iterative_hash_expr for MEM_EXPR if final_insns_dump_p
is actually worse, because iterative_hash_expr uses DECL_UID, which isn't
guaranteed to be the same between -g and -g0.
So, either we shouldn't print MEM_EXPR at all for final_insns_dump_p, or come
up with iterative_hash_expr alternative which doesn't hash using DECL_UIDs, but
DECL_NAME.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (8 preceding siblings ...)
2010-08-30 14:29 ` jakub at gcc dot gnu dot org
@ 2010-08-30 14:30 ` rguenther at suse dot de
2010-08-30 17:17 ` jakub at gcc dot gnu dot org
` (8 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: rguenther at suse dot de @ 2010-08-30 14:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from rguenther at suse dot de 2010-08-30 14:30 -------
Subject: Re: -fcompare-debug failure at -O3
On Mon, 30 Aug 2010, jakub at gcc dot gnu dot org wrote:
> ------- Comment #9 from jakub at gcc dot gnu dot org 2010-08-30 14:29 -------
> Unfortunately printing iterative_hash_expr for MEM_EXPR if final_insns_dump_p
> is actually worse, because iterative_hash_expr uses DECL_UID, which isn't
> guaranteed to be the same between -g and -g0.
> So, either we shouldn't print MEM_EXPR at all for final_insns_dump_p, or come
> up with iterative_hash_expr alternative which doesn't hash using DECL_UIDs, but
> DECL_NAME.
Or dump MEM_EXPR caching?
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (9 preceding siblings ...)
2010-08-30 14:30 ` rguenther at suse dot de
@ 2010-08-30 17:17 ` jakub at gcc dot gnu dot org
2010-09-02 12:22 ` aoliva at gcc dot gnu dot org
` (7 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-08-30 17:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from jakub at gcc dot gnu dot org 2010-08-30 17:17 -------
Subject: Bug 45419
Author: jakub
Date: Mon Aug 30 17:17:15 2010
New Revision: 163654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163654
Log:
PR debug/45419
* tree-ssa-live.c (dump_enumerated_decls): Clear the whole wi variable.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-live.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (10 preceding siblings ...)
2010-08-30 17:17 ` jakub at gcc dot gnu dot org
@ 2010-09-02 12:22 ` aoliva at gcc dot gnu dot org
2010-09-03 9:00 ` aoliva at gcc dot gnu dot org
` (6 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2010-09-02 12:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from aoliva at gcc dot gnu dot org 2010-09-02 12:21 -------
'been looking into this as well. cp/pt.c -fcompare-debug fails for me on
x86_64-linux-gnu.
I'm not sure yet why we get different different types for the integer_csts in
operand 0 of MEM_REFs, but it occurred to me that we could add a flag to
operand_equal_p to check that all types are the same. Ideally, we'd have
corresponding flags for hashing as well, but not necessarly for correctness.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (11 preceding siblings ...)
2010-09-02 12:22 ` aoliva at gcc dot gnu dot org
@ 2010-09-03 9:00 ` aoliva at gcc dot gnu dot org
2010-09-03 9:06 ` rguenther at suse dot de
` (5 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2010-09-03 9:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from aoliva at gcc dot gnu dot org 2010-09-03 08:59 -------
The different types arise when, say, we copyprop a const-unqualified variable
into a MEM_REF that used to reference a const-qualified temp. The top-level
const qualifications are irrelevant at that point, for we're dealing with
rvalues of pointer types. I'm experimenting with simply dropping the
TYPE_QUALS test from tree-pretty-print. This fixed the pt.c -fcompare-debug
problem. Richard, is there any reason for top-level qualifiers to be relevant
in MEM_REF operands?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (12 preceding siblings ...)
2010-09-03 9:00 ` aoliva at gcc dot gnu dot org
@ 2010-09-03 9:06 ` rguenther at suse dot de
2010-09-04 15:27 ` aoliva at gcc dot gnu dot org
` (4 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: rguenther at suse dot de @ 2010-09-03 9:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from rguenther at suse dot de 2010-09-03 09:06 -------
Subject: Re: -fcompare-debug failure at -O3
On Fri, 3 Sep 2010, aoliva at gcc dot gnu dot org wrote:
> ------- Comment #13 from aoliva at gcc dot gnu dot org 2010-09-03 08:59 -------
> The different types arise when, say, we copyprop a const-unqualified variable
> into a MEM_REF that used to reference a const-qualified temp. The top-level
> const qualifications are irrelevant at that point, for we're dealing with
> rvalues of pointer types. I'm experimenting with simply dropping the
> TYPE_QUALS test from tree-pretty-print. This fixed the pt.c -fcompare-debug
> problem. Richard, is there any reason for top-level qualifiers to be relevant
> in MEM_REF operands?
Hmm, not really. But in the end at some point I want to drop the
fancy printing of MEM_REFs.
What you can do is instead of
dump_generic_node (buffer, TREE_TYPE (TREE_OPERAND (node, 1)),
spc, flags | TDF_SLIM, false);
do
dump_generic_node (buffer, TYPE_MAIN_VARIANT (TREE_TYPE
(TREE_OPERAND (node, 1))),
spc, flags | TDF_SLIM, false);
as that is what matters. Or even better, see if the issue goes away
when you change the gimplifier to use the main variant in the first
place. That's sth I would prefer - not sure why I missed that.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (13 preceding siblings ...)
2010-09-03 9:06 ` rguenther at suse dot de
@ 2010-09-04 15:27 ` aoliva at gcc dot gnu dot org
2010-09-04 15:27 ` aoliva at gcc dot gnu dot org
` (3 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2010-09-04 15:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from aoliva at gcc dot gnu dot org 2010-09-04 15:27 -------
*** Bug 45408 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (14 preceding siblings ...)
2010-09-04 15:27 ` aoliva at gcc dot gnu dot org
@ 2010-09-04 15:27 ` aoliva at gcc dot gnu dot org
2010-09-08 21:54 ` aoliva at gcc dot gnu dot org
` (2 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2010-09-04 15:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from aoliva at gcc dot gnu dot org 2010-09-04 15:26 -------
Got a patch
--
aoliva at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (15 preceding siblings ...)
2010-09-04 15:27 ` aoliva at gcc dot gnu dot org
@ 2010-09-08 21:54 ` aoliva at gcc dot gnu dot org
2010-09-08 21:56 ` aoliva at gcc dot gnu dot org
2010-09-13 3:42 ` aoliva at gcc dot gnu dot org
18 siblings, 0 replies; 21+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2010-09-08 21:54 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from aoliva at gcc dot gnu dot org 2010-09-08 21:54 -------
Subject: Bug 45419
Author: aoliva
Date: Wed Sep 8 21:53:48 2010
New Revision: 164031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164031
Log:
PR debug/45419
PR debug/45408
* tree-pretty-print.c (dump_generic_node): Disregard top-level
qualifiers in otherwise equal MEM_REF pointer types.
* fold-const.c (operand_equal_p): Compare pointer type of MEM_REFs.
* tree.c (iterative_hash_expr): Hash the pointer type of MEM_REFs.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (16 preceding siblings ...)
2010-09-08 21:54 ` aoliva at gcc dot gnu dot org
@ 2010-09-08 21:56 ` aoliva at gcc dot gnu dot org
2010-09-13 3:42 ` aoliva at gcc dot gnu dot org
18 siblings, 0 replies; 21+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2010-09-08 21:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from aoliva at gcc dot gnu dot org 2010-09-08 21:56 -------
Fixed
--
aoliva at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
` (17 preceding siblings ...)
2010-09-08 21:56 ` aoliva at gcc dot gnu dot org
@ 2010-09-13 3:42 ` aoliva at gcc dot gnu dot org
18 siblings, 0 replies; 21+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2010-09-13 3:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from aoliva at gcc dot gnu dot org 2010-09-13 03:42 -------
Subject: Bug 45419
Author: aoliva
Date: Mon Sep 13 03:42:07 2010
New Revision: 164242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164242
Log:
PR debug/45604
PR debug/45419
PR debug/45408
* tree-pretty-print.c (dump_generic_node): Disregard top-level
types of MEM_REF pointer types to the same type.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-pretty-print.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/45419] -fcompare-debug failure at -O3
[not found] <bug-45419-4@http.gcc.gnu.org/bugzilla/>
@ 2010-10-08 4:41 ` aoliva at gcc dot gnu.org
0 siblings, 0 replies; 21+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-10-08 4:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
--- Comment #20 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-10-08 04:41:09 UTC ---
Author: aoliva
Date: Fri Oct 8 04:40:59 2010
New Revision: 165149
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165149
Log:
PR debug/45673
PR debug/45604
PR debug/45419
PR debug/45408
* tree-pretty-print.c (dump_generic_node): Explicitly dump the
type of MEM_REFs to INTEGER_CSTs.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-pretty-print.c
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2010-10-08 4:41 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-26 17:09 [Bug debug/45419] New: -fcompare-debug failure at -O3 zsojka at seznam dot cz
2010-08-26 17:13 ` [Bug debug/45419] " zsojka at seznam dot cz
2010-08-26 17:46 ` hjl dot tools at gmail dot com
2010-08-26 17:58 ` jakub at gcc dot gnu dot org
2010-08-26 18:37 ` zsojka at seznam dot cz
2010-08-26 19:49 ` hjl dot tools at gmail dot com
2010-08-26 20:02 ` hjl dot tools at gmail dot com
2010-08-30 12:53 ` jakub at gcc dot gnu dot org
2010-08-30 14:05 ` jakub at gcc dot gnu dot org
2010-08-30 14:29 ` jakub at gcc dot gnu dot org
2010-08-30 14:30 ` rguenther at suse dot de
2010-08-30 17:17 ` jakub at gcc dot gnu dot org
2010-09-02 12:22 ` aoliva at gcc dot gnu dot org
2010-09-03 9:00 ` aoliva at gcc dot gnu dot org
2010-09-03 9:06 ` rguenther at suse dot de
2010-09-04 15:27 ` aoliva at gcc dot gnu dot org
2010-09-04 15:27 ` aoliva at gcc dot gnu dot org
2010-09-08 21:54 ` aoliva at gcc dot gnu dot org
2010-09-08 21:56 ` aoliva at gcc dot gnu dot org
2010-09-13 3:42 ` aoliva at gcc dot gnu dot org
[not found] <bug-45419-4@http.gcc.gnu.org/bugzilla/>
2010-10-08 4:41 ` aoliva at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).