From patchwork Thu May 10 12:00:47 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 158258 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 03B44B6FAF for ; Thu, 10 May 2012 22:01:05 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1337256066; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=5QIP5n/FA1TypwRbnvZnLseM5KY=; b=g/jZmufZ0rcVVRt lRvaT/teKb/+/11oI4r9Ky5yUbUgHjEJQIh5MSXH1vD+cKy1oSFNpG5RPnU/hQEO Pyxx4EEK3CBnZezIiJyhsrsY0PtrfSwrADmN3tXgXUftJUuV3xfeyMJHcZAnplxp yqpq7UniMvsB74Y1seW6HYY/9XfQ= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=S85qvEb98Bb5rDckQ9Z2n/RVhIUkUTzjmZF+0xoEM6CLFIWeBELBhfGwjgx3+o pM0nMfqRF1FW3XDb0ziQNThi/eUc0RecI+mb/nlYDcUvPT2ETtRQMlX9QiejhOKV 86NbQLV3r42JSg7ppWzPsyvhHlfawk1MEzstDuj+Uzs74=; Received: (qmail 24196 invoked by alias); 10 May 2012 12:01:01 -0000 Received: (qmail 24188 invoked by uid 22791); 10 May 2012 12:01:00 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-yw0-f47.google.com (HELO mail-yw0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 May 2012 12:00:48 +0000 Received: by yhjj56 with SMTP id j56so1527746yhj.20 for ; Thu, 10 May 2012 05:00:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.169.65 with SMTP id ac1mr3684749igc.54.1336651247267; Thu, 10 May 2012 05:00:47 -0700 (PDT) Received: by 10.42.171.130 with HTTP; Thu, 10 May 2012 05:00:47 -0700 (PDT) In-Reply-To: <201205101226.02368.ebotcazou@adacore.com> References: <201205101226.02368.ebotcazou@adacore.com> Date: Thu, 10 May 2012 14:00:47 +0200 Message-ID: Subject: Re: [PATCH] Remove TYPE_IS_SIZETYPE From: Richard Guenther To: Eric Botcazou Cc: Richard Guenther , gcc-patches@gcc.gnu.org X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Thu, May 10, 2012 at 12:26 PM, Eric Botcazou wrote: >> As far as I can see this happens when we fold >> >>  (bitsizetype) (#1 + 7) * 8 + 7  PLUS_EXPR  1 >> >> which we fold to >> >>  ((bitsizetype) (#1 + 7) + 1) * 8 >> >> The #1 + 7 expression is computed in sizetype (which is now unsigned >> and thus has defined overflow - thus we cannot optimize the widening >> to bitsizetype). > > I see, thanks for the investigation. > >> As I previously suggested we can put in special knowledge into >> size_binop, or maybe better, provide abstraction for conversion >> of sizetype to bitsizetype that would associate the type >> conversions.  The original plan was of course to at some point >> have PLUSNV_EXPR so we can explicitely mark #1 + 7 as not >> overflowing.  It might be that introducing those just for >> size expressions right now (and then dropping them down >> to regular PLUS_EXPRs during gimplification) might be >> something to explore for 4.8. > > OK, I'll think about it.  No objections by me to going ahead with the patches. For example fixes the specific testcase you provided. I suppose if stor-layout.c would be more carefully handle advancing offset/bitpos, avoding repeated translations between them, those issues would not exist. Of course the mere existence of DECL_OFFSET_ALIGN complicates matters for no good reasons (well, at least I did not find a good use of it until now ...). Richard. > -- > Eric Botcazou Index: stor-layout.c =================================================================== --- stor-layout.c (revision 187364) +++ stor-layout.c (working copy) @@ -791,6 +791,10 @@ start_record_layout (tree t) tree bit_from_pos (tree offset, tree bitpos) { + if (TREE_CODE (offset) == PLUS_EXPR) + offset = size_binop (PLUS_EXPR, + fold_convert (bitsizetype, TREE_OPERAND (offset, 0)), + fold_convert (bitsizetype, TREE_OPERAND (offset, 1))); return size_binop (PLUS_EXPR, bitpos, size_binop (MULT_EXPR, fold_convert (bitsizetype, offset),