From patchwork Fri Feb 9 06:22:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 871218 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-472918-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="UcIZBJyq"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3zd4jw3ZGtz9sPk for ; Fri, 9 Feb 2018 17:22:43 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=lwT5m5Kc8cStAbM6B11K0v6r+OOte cwCkIPyOHSMPvf3eQdis1S3giISKv6yO9g5eYGCkj6Sypra9tGU7U/TyHUYckyBZ yqsiQSxIF60e4NJ9PBVgTV1xgEtCf3I8ogmHUlS33WjPjT6NGZOEGHTjnn6GPI1O YJlFL470lvFTqE= 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:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=48YmUvYeKuLfrvG5TobtrOT+SIs=; b=UcI ZBJyqBBRPUZHXyV9NvJCEAfr/g0Jr7JOwExptGycxd02ASJbNNefPMmLOsIqGcLy TWJOwRjVIMl5aNsHMaZDf8i8chG97XB0G2yqAYEm+KYWNqracDHyR7RtmU2dMrk3 /+RGVauPvS+MN+G5C1zRpDw+ioTYuOMupj2s5Usw= Received: (qmail 112011 invoked by alias); 9 Feb 2018 06:22:34 -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 112002 invoked by uid 89); 9 Feb 2018 06:22:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-12.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Feb 2018 06:22:32 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C06E69BA56; Fri, 9 Feb 2018 06:22:22 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-56.ams2.redhat.com [10.36.116.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F3EC610083A3; Fri, 9 Feb 2018 06:22:18 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id w196MGZu032514; Fri, 9 Feb 2018 07:22:16 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w196MEiw032486; Fri, 9 Feb 2018 07:22:14 +0100 Date: Fri, 9 Feb 2018 07:22:14 +0100 From: Jakub Jelinek To: Richard Biener , Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix handling of variable length fields in structures (PR c/82210) Message-ID: <20180209062214.GB5867@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-IsSubscribed: yes Hi! When placing a variable length field into a structure, we need to update rli->offset_align for the next field. We do: rli->offset_align = MIN (rli->offset_align, desired_align); which updates it according to the start of that VLA field, the problem is that if the field doesn't have a size that is a multiple of this alignment rli->offset_align will not reflect properly the alignment of the end of that field. E.g. on the testcase, we have a VLA array aligned as a whole (the field itself) to 16 bytes / 128 bits, so rli->offset_align remains 128. The array has element size 2 bytes / 16 bits, times function argument, so the end of the field is worst case aligned just to 16 bits; if we keep rli->offset_align as 128 for the next field, then DECL_OFFSET_ALIGN is too large. DECL_FIELD_OFFSET documented as: /* In a FIELD_DECL, this is the field position, counting in bytes, of the DECL_OFFSET_ALIGN-bit-sized word containing the bit closest to the beginning of the structure. */ and when gimplifying COMPONENT_REFs with that field we: tree offset = unshare_expr (component_ref_field_offset (t)); tree field = TREE_OPERAND (t, 1); tree factor = size_int (DECL_OFFSET_ALIGN (field) / BITS_PER_UNIT); /* Divide the offset by its alignment. */ offset = size_binop_loc (loc, EXACT_DIV_EXPR, offset, factor); and later on multiply it again by DECL_OFFSET_ALIGN. The EXACT_DIV_EXPR isn't exact. Fixed by lowering the rli->offset_align if the size isn't a multiple of the align. We don't have a multiple_of_p variant that would compute highest power of two number the expression is known to be a multiple of, so I'm just checking the most common case, where the size is a multiple of the starting alignment, and otherwise just compute it very conservatively. This will be lower than necessary say for __attribute__((aligned (16))) short field[2 * size]; - just 16 bits instead of 32. In theory we could do a binary search on power of two numbers in between that high initial rli->offset_align for which the first multiple_of_p failed, and the conservative guess we do to improve it. If you think it is worth it, I can code it up. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2018-02-09 Jakub Jelinek PR c/82210 * stor-layout.c (place_field): For variable length fields, adjust offset_align afterwards not just based on the field's alignment, but also on the size. * gcc.c-torture/execute/pr82210.c: New test. Jakub --- gcc/stor-layout.c.jj 2018-01-16 16:07:57.000000000 +0100 +++ gcc/stor-layout.c 2018-02-08 13:48:32.380582662 +0100 @@ -1622,6 +1622,30 @@ place_field (record_layout_info rli, tre = size_binop (PLUS_EXPR, rli->offset, DECL_SIZE_UNIT (field)); rli->bitpos = bitsize_zero_node; rli->offset_align = MIN (rli->offset_align, desired_align); + + if (!multiple_of_p (bitsizetype, DECL_SIZE (field), + bitsize_int (rli->offset_align))) + { + tree type = strip_array_types (TREE_TYPE (field)); + /* The above adjusts offset_align just based on the start of the + field. The field might not have a size that is a multiple of + that offset_align though. If the field is an array of fixed + sized elements, assume there can be any multiple of those + sizes. If it is a variable length aggregate or array of + variable length aggregates, assume worst that the end is + just BITS_PER_UNIT aligned. */ + if (TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST) + { + if (TREE_INT_CST_LOW (TYPE_SIZE (type))) + { + unsigned HOST_WIDE_INT sz + = least_bit_hwi (TREE_INT_CST_LOW (TYPE_SIZE (type))); + rli->offset_align = MIN (rli->offset_align, sz); + } + } + else + rli->offset_align = MIN (rli->offset_align, BITS_PER_UNIT); + } } else if (targetm.ms_bitfield_layout_p (rli->t)) { --- gcc/testsuite/gcc.c-torture/execute/pr82210.c.jj 2018-02-08 13:59:37.247901958 +0100 +++ gcc/testsuite/gcc.c-torture/execute/pr82210.c 2018-02-08 13:59:14.185912469 +0100 @@ -0,0 +1,26 @@ +/* PR c/82210 */ + +void +foo (int size) +{ + int i; + struct S { + __attribute__((aligned (16))) struct T { short c; } a[size]; + int b[size]; + } s; + + for (i = 0; i < size; i++) + s.a[i].c = 0x1234; + for (i = 0; i < size; i++) + s.b[i] = 0; + for (i = 0; i < size; i++) + if (s.a[i].c != 0x1234 || s.b[i] != 0) + __builtin_abort (); +} + +int +main () +{ + foo (15); + return 0; +}