cselib.c hash_rtx hashes based on the address of a symbol or label instead of the contents, assuming that a symbol will be unique and only appear once. Hashing based on the address of internal GCC data structures can produce non-deterministic results. Release: 3.1 (experimental) Environment: powerpc-ibm-aix4.3
Fix: Work-around error by not applying ggc_strdup() to symbols in rs6000.c which covers up the design mistake.
State-Changed-From-To: open->feedback State-Changed-Why: David, you probably have more insight into these things than me, but I know that some of these address-hashing things have been purged. Is this particular report still valid? Thanks Wolfgang
State-Changed-From-To: feedback->open State-Changed-Why: Probably still exists. Thanks for the quick feedback, David! W.
From: David Edelsohn <dje@watson.ibm.com> To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, john@feith.com, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Geoff Keating <geoffk@geoffk.org> Subject: Re: other/4520: cselib.c hash_rtx incorrectly hashes based on rtx address Date: Sat, 21 Dec 2002 13:22:13 -0500 >>>>> bangerth writes: Wolfgang> David, you probably have more insight into these things than Wolfgang> me, but I know that some of these address-hashing things Wolfgang> have been purged. Is this particular report still valid? As far as I can tell, the incorrect hashing of addresses of LABEL_REFS and SYMBOL_REFS in cselib.c:hash_rtx() has not been corrected. The failure is dormant, but I am not sure how it affects PCH restore state. David
From: Geoff Keating <geoffk@geoffk.org> To: dje@watson.ibm.com Cc: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, john@feith.com, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: other/4520: cselib.c hash_rtx incorrectly hashes based on rtx address Date: Sat, 21 Dec 2002 22:56:59 -0800 > Cc: Geoff Keating <geoffk@geoffk.org> > Date: Sat, 21 Dec 2002 13:22:13 -0500 > From: David Edelsohn <dje@watson.ibm.com> > X-OriginalArrivalTime: 21 Dec 2002 18:22:33.0209 (UTC) FILETIME=[EE029E90:01C2A91D] > > >>>>> bangerth writes: > > Wolfgang> David, you probably have more insight into these things than > Wolfgang> me, but I know that some of these address-hashing things > Wolfgang> have been purged. Is this particular report still valid? > > As far as I can tell, the incorrect hashing of addresses of > LABEL_REFS and SYMBOL_REFS in cselib.c:hash_rtx() has not been corrected. > The failure is dormant, but I am not sure how it affects PCH restore > state. cselib.c isn't active when PCH files are saved, so nothing in cselib.c affects PCH. -- - Geoffrey Keating <geoffk@geoffk.org>
The problem still exists in 3.4.
confirmed on mainline (20030523).
Also if we use the address we more likely to have an unstable hastable in we can get a miscompare if we get different address across compilination.
Subject: Bug 4520 Author: sayle Date: Tue Sep 12 16:02:31 2006 New Revision: 116891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116891 Log: PR middle-end/4520 PR bootstrap/28784 * cselib.c (cselib_hash_rtx): Avoid hashing on the address of labels and symbols. Instead use the implementation from cse.c's hash_rtx. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c
Fixed, finally.
Subject: Bug 4520 Author: sayle Date: Mon Sep 18 22:56:44 2006 New Revision: 117042 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117042 Log: PR middle-end/4520 Backport from mainline * cselib.c (cselib_hash_rtx): Avoid hashing on the address of labels and symbols. Instead use the implementation from cse.c's hash_rtx. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cselib.c
Subject: Bug 4520 Author: sayle Date: Tue Sep 19 21:25:28 2006 New Revision: 117062 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117062 Log: PR middle-end/4520 Backport from mainline * cselib.c (cselib_hash_rtx): Avoid hashing on the address of labels and symbols. Instead use the implementation from cse.c's hash_rtx. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/cselib.c