From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8743 invoked by alias); 4 Aug 2009 02:25:51 -0000 Received: (qmail 8728 invoked by uid 22791); 4 Aug 2009 02:25:51 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-yx0-f200.google.com (HELO mail-yx0-f200.google.com) (209.85.210.200) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Aug 2009 02:25:45 +0000 Received: by yxe38 with SMTP id 38so8363095yxe.0 for ; Mon, 03 Aug 2009 19:25:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.151.21 with SMTP id y21mr12076176ybd.151.1249352742847; Mon, 03 Aug 2009 19:25:42 -0700 (PDT) Date: Tue, 04 Aug 2009 03:55:00 -0000 Message-ID: Subject: Tree aliasing From: Andrew Pinski To: GCC Mailing List , Richard Guenther Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-08/txt/msg00047.txt.bz2 I was improving tree aliasing for pointers by adding support a+1 and a not aliasing. But I ran into a bug in the aliasing where: /* If both references are through the same type, they do not alias if the accesses do not overlap. This does extra disambiguation for mixed/pointer accesses but requires strict aliasing. */ if (same_type_for_tbaa (TREE_TYPE (TREE_TYPE (ptr1)), TREE_TYPE (TREE_TYPE (ptr2))) == 1) return ranges_overlap_p (offset1, max_size1, offset2, max_size2); Would return false even. I can't see how this can be true if one pointer is defined as an offset as the other and the offset1 or offset2 are non zero. Can someone explain why this is true? Even nonaliasing_component_refs_p looks to have the same issue if the types are the same, they could be an extra offset from each other, even though the compiler cannot figure that out. I am thinking of when storing the pointer in an array and then accessing that pointer. gcc.dg/20030324-1.c is the testcase where I am running into this bug too. Thanks, Andrew Pinski