From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9547 invoked by alias); 8 Sep 2010 16:45:09 -0000 Received: (qmail 9491 invoked by uid 22791); 8 Sep 2010 16:45:08 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Sep 2010 16:44:59 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 9FFD1890B6 for ; Wed, 8 Sep 2010 18:44:56 +0200 (CEST) Resent-From: Martin Jambor Resent-Date: Wed, 8 Sep 2010 18:44:56 +0200 Resent-Message-ID: <20100908164456.GA24785@virgil.arch.suse.de> Resent-To: GCC Patches Message-Id: <20100908164332.622577593@virgil.suse.cz> User-Agent: quilt/0.48-4.4 Date: Wed, 08 Sep 2010 17:16:00 -0000 From: Martin Jambor To: GCC Patches Cc: Richard Guenther Subject: [PATCH 0/2] Fix PR 44972 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-09/txt/msg00677.txt.bz2 Hi, the following two patches fix PR 44972 which was caused by transition to MEM_REF. The problem is that MEM_REFs can also act like VIEW_CONVERT_EXPRs and before MEM_REF we would have disqualified many (SRA) accesses with them. When we don't, build_ref_for_offset can find itself unable to create a reference consisting of component_refs and array_refs in a situation when we cannot handle it and ICE. The solution is to make build_ref_for_offset create a MEM_REF which is what both patches do. The first one does this for IPA-SRA, the second one for everyone else (intra-SRA and IPA-CP/inlining). The implementations are very similar but I decided to keep them separate because the IPA-SRA can handle more cases (it may add pointer dereferences) and, more importantly, it relies on force_gimple_operand_gsi (which is already used anyway) which can somehow cope with functions that are not gimple_in_ssa_p. The other users don't need either and I did not want to use force_gimple_operand_gsi there when it is not needed (and I wanted to have things a bit more under control because of an extra layer handling bit-fields). More comments in the two messages. I also intend to try and relax some other checks now that we have MEM_REF but I'd like to do that incrementally (if possible at all). I have bootstrapped and tested both patches on x86_64-linux without any problems. I hope you'll find this approach more-or-less acceptable because it really took me frustratingly long to get here. Thanks, Martin