From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1802 invoked by alias); 25 Apr 2008 11:37:56 -0000 Received: (qmail 1643 invoked by uid 48); 25 Apr 2008 11:37:12 -0000 Date: Fri, 25 Apr 2008 11:37:00 -0000 Message-ID: <20080425113712.1642.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu 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-04/txt/msg01804.txt.bz2 ------- Comment #4 from jakub at gcc dot gnu dot org 2008-04-25 11:37 ------- The patch didn't come with any testcases, so it is hard to find out what exactly is supposed to mean DECL_BASED_ON_RESTRICT_P on a decl. Is that supposed to be on the same level of indirection as some TYPE_RESTRICT pointer (i.e. say for int *** restrict p; formal decl initialized to p + 32 has DECL_GET_RESTRICT_BASE p), or is it supposed to be one indirection different, (e.g. formal decl initialized to *p + 32 has DECL_GET_RESTRICT_BASE p)? >>From the use in find_decl_base I'd think that it should be the same level, as it will share the alias set with the pointer. ATM gimplify.c sets this as "somehow related to a restricted pointer". Wonder if just making sure that types_compatible_p between the DECL_GET_RESTRICT_BASE and the original decl in find_decl_base and only returning the restrict base if they have compatible types would be sufficient, though that still sounds dangerous. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013