From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29637 invoked by alias); 27 Jul 2008 15:38:14 -0000 Received: (qmail 29456 invoked by alias); 27 Jul 2008 15:37:31 -0000 Date: Sun, 27 Jul 2008 15:38:00 -0000 Message-ID: <20080727153731.29455.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/36830] [4.4 Regression] STORAGE_ERROR raised compiling s-os_lib.adb In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dberlin at dberlin dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-07/txt/msg02029.txt.bz2 ------- Comment #10 from dberlin at gcc dot gnu dot org 2008-07-27 15:37 ------- Subject: Re: [4.4 Regression] STORAGE_ERROR raised compiling s-os_lib.adb No, it doesn't. Even if the op isn't hashed, it is still compared for in vn_reference_op_eq, so at worst the non-hashing will make it compare more vn_reference_op's than it has to, it shouldn't affect correctness. On Sun, Jul 27, 2008 at 5:16 AM, ebotcazou at gcc dot gnu dot org wrote: > > > ------- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-07-27 09:16 ------- > This points to an immediate problem in vn_reference_op_compute_hash: > > /* Compute the hash for a reference operand VRO1. */ > > static hashval_t > vn_reference_op_compute_hash (const vn_reference_op_t vro1) > { > return iterative_hash_expr (vro1->op0, vro1->opcode) > + iterative_hash_expr (vro1->op1, vro1->opcode); > } > > op2 is not hashed (whereas it is on the 4.3 branch). > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36830 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36830