From patchwork Tue Dec 10 15:14:43 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 299490 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 57C642C04C9 for ; Wed, 11 Dec 2013 09:26:59 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=c46hMH6tSFFFcvUPk1 41Q0Y3w5gOeXtI+b01wwoPfvx38SfHmCsqrQO6T7XF7MzS8Xa3G/oVE1U9KJFc7x 7OhrDX6bH/Q5WXs9j5qNCrVCX560p24iEnRAbvkKNIbk3HFIyJtpnlzEywD0WuXt 1pqMehH9XjkGG7D589I2qBa0I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=rT9eHnx4wQZN8wK0NuNa2q9Q 0jQ=; b=JrUWYzYJV4FIJPfVMgw5KyZuxnKtdwsDjenY0JtTye7JcehfW4+cEtwY fmKX9B5xioKOC4x4T0QMjFd85QR+d4Vgcqgw9bI6p+YNyLVUIXpGEjFRsQOhE0Is RCPlM7DCpAUwrJ/7lY4M+s55tu0MIBVDwU7gLpDx5xoIzGz4fHE= Received: (qmail 13718 invoked by alias); 10 Dec 2013 15:14:55 -0000 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 Received: (qmail 13697 invoked by uid 89); 10 Dec 2013 15:14:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f174.google.com Received: from Unknown (HELO mail-wi0-f174.google.com) (209.85.212.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 10 Dec 2013 15:14:52 +0000 Received: by mail-wi0-f174.google.com with SMTP id z2so5563920wiv.13 for ; Tue, 10 Dec 2013 07:14:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.173.163 with SMTP id bl3mr21527998wjc.10.1386688483351; Tue, 10 Dec 2013 07:14:43 -0800 (PST) Received: by 10.195.12.114 with HTTP; Tue, 10 Dec 2013 07:14:43 -0800 (PST) In-Reply-To: References: <1492537.Ex4gsrNT5I@polaris> <20131210102228.GO892@tucnak.redhat.com> <3796925.A4rkQImdcP@polaris> Date: Tue, 10 Dec 2013 16:14:43 +0100 Message-ID: Subject: Re: [REPOST] Invalid Code when reading from unaligned zero-sized array From: Richard Biener To: Eric Botcazou Cc: Jakub Jelinek , GCC Patches , Bernd Edlinger , Jeff Law X-IsSubscribed: yes On Tue, Dec 10, 2013 at 4:02 PM, Richard Biener wrote: > On Tue, Dec 10, 2013 at 11:53 AM, Eric Botcazou wrote: >>> What we support is out of bounds accesses for heap vars if the var's type >>> has flexible array member or something we treat similarly and there is the >>> possibility that there could be payload after the heap var that could be >>> accessed from the flexible array members or similar arrays. >> >> My question was about the above similar arrays, i.e. whether we consider all >> trailing arrays in structures as flexible-like or not. No strong opinion. > > Yes we do, even for struct { struct { int a; char a[1] } }; (note the not really > "trailing" as there is padding after the trailing array). We do take > size limitations from a DECL (if we see one) into account to limit the > effect of this trailing-array-supporting, so it effectively only applies to > indirect accesses (and the padding example above, you can use the whole > padding if DECL_SIZE allows that). > >>> So, I don't see what is the big deal with BLKmode, because all the cases >>> which actually could have flexible array member extra payloads (or similar) >>> must necessarily live in memory, if it is the compiler that decides whether >>> to put it into memory or keep in registers etc., then it can't be heap >>> allocated. >> >> The invariant is that types for which objects can effectively have variable >> size must have BLKmode, otherwise you need to add very ugly code in the RTL >> expander to mask the lie. > > I wonder if we can make the expander more rely on the DECLs mode > and optimize only the DECLs mode (if we can constrain its size via > DECL_SIZE) to non-BLKmode instead of doing that for the TYPEs mode. > Yes, you'd have DECL_MODE != TYPE_MODE that way. > > Or rather I wonder if the expander doesn't already work that way > (looks at DECL_MODE). To speak in patches (completely untested) - sth like the following ontop of making more types have BLKmode: > Richard. > >> -- >> Eric Botcazou Index: gcc/stor-layout.c =================================================================== --- gcc/stor-layout.c (revision 205857) +++ gcc/stor-layout.c (working copy) @@ -569,8 +569,17 @@ layout_decl (tree decl, unsigned int kno bitsize_unit_node)); if (code != FIELD_DECL) - /* For non-fields, update the alignment from the type. */ - do_type_align (type, decl); + { + /* For non-fields, update the alignment from the type. */ + do_type_align (type, decl); + /* Optimize the mode of the decl. + ??? Ensure choosen mode alignment fits decl alignment. */ + if (DECL_MODE (decl) == BLKmode + && DECL_SIZE (decl) + && compare_tree_int (DECL_SIZE (t), MAX_FIXED_MODE_SIZE) <= 0) + DECL_MODE (decl) + = mode_for_size (TREE_INT_CST_LOW (DECL_SIZE (decl)), MODE_INT, 1); + } else /* For fields, it's a bit more complicated... */ {