From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1542 invoked by alias); 15 Jan 2020 20:53:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 1325 invoked by uid 89); 15 Jan 2020 20:53:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=shut X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Jan 2020 20:53:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579121584; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cr39PubktG2G9Jks9QvL1b339fiY+6vW5DMkCY6jKtI=; b=WjabhTfET4rN42m72n3zlquNdFHzZoQdbgqIgZzc5GFUYCWPh93m1wy6iepLeYGPPExfEJ vskSTqDePOv1VHVascckl/2BEhdcG3x7qc/StReaBfWv7jvF97dMSLcTcVK2yjPmZGJRrl /xag1heYJonJRFCbQEYaMP/vga2NMQ8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-253-dN1nU6zwN9aQBH8846nluQ-1; Wed, 15 Jan 2020 15:53:01 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F309B8010C1; Wed, 15 Jan 2020 20:52:59 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-74.brq.redhat.com [10.40.204.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 816585D9C9; Wed, 15 Jan 2020 20:52:59 +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 00FKqv3l017462; Wed, 15 Jan 2020 21:52:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 00FKqvfb017461; Wed, 15 Jan 2020 21:52:57 +0100 Date: Wed, 15 Jan 2020 21:49:00 -0000 From: Jakub Jelinek To: Martin Sebor , Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] adjust object size computation for union accesses and PHIs (PR 92765) Message-ID: <20200115205257.GY10088@tucnak> Reply-To: Jakub Jelinek References: <64a504e5-8e1f-682a-0443-e74e62d3aac1@gmail.com> MIME-Version: 1.0 In-Reply-To: <64a504e5-8e1f-682a-0443-e74e62d3aac1@gmail.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00915.txt.bz2 On Wed, Jan 15, 2020 at 01:18:54PM +0000, Martin Sebor wrote: > @@ -4099,14 +4122,18 @@ determine_min_objsize (tree dest) >=20=20 > init_object_sizes (); >=20=20 > - if (compute_builtin_object_size (dest, 2, &size)) > - return size; > - > /* Try to determine the size of the object through the RHS > of the assign statement. */ > if (TREE_CODE (dest) =3D=3D SSA_NAME) > { > gimple *stmt =3D SSA_NAME_DEF_STMT (dest); > + > + /* Determine the size of the largest object when DEST refers > + to two or more via a PHI, otherwise the smallest. */ > + int ostype =3D gimple_code (stmt) =3D=3D GIMPLE_PHI ? 0 : 2; > + if (compute_builtin_object_size (dest, ostype, &size)) > + return size; > + > if (!is_gimple_assign (stmt)) > return HOST_WIDE_INT_M1U; >=20=20 > @@ -4118,6 +4145,10 @@ determine_min_objsize (tree dest) > return determine_min_objsize (dest); > } >=20=20 > + /* Try to determine the size of the referenced object itself. */ > + if (compute_builtin_object_size (dest, 2, &size)) > + return size; > + This looks wrong. For one, this function is used for two purposes now and you tweak it for one, but more importantly, whether he initial stmt you see is a PHI or not can't make a difference, how is that case e.g. different from _1 =3D PHI <_3, _4>; _2 =3D _1 + 1; and asking about _2? For _1, you'd use (correctly) the maximum, but if called on _2, you'd ask (wrongly) for minimum instead of maximum. > /* The size of a flexible array cannot be determined. Otherwise, > - for arrays with more than one element, return the size of its > - type. GCC itself misuses arrays of both zero and one elements > - as flexible array members so they are excluded as well. */ > + unless the reference involves a union, for arrays with more than > + one element, return the size of its type. GCC itself misuses > + arrays of both zero and one elements as flexible array members > + so they are excluded as well. */ > if (TREE_CODE (type) !=3D ARRAY_TYPE > - || !array_at_struct_end_p (dest)) > + || (!component_ref_via_union_p (dest) > + && !array_at_struct_end_p (dest))) > { > tree type_size =3D TYPE_SIZE_UNIT (type); > if (type_size && TREE_CODE (type_size) =3D=3D INTEGER_CST This also looks like a hack to shut up the particular testcases instead of really playing with what the IL provides. Instead of the unions, consider e.g. C++ placement new, have a pointer to a buffer into which you placement new one structure, take address of some member in it, pass it to something, if it doesn't have a destructor do a C++ placement new into the same buffer but with different structure, take address of a different member with the same address as the first member, do the str*cmp on it that invokes this stuff. SCCVN will (likely) find out that the values of those two pointers are the same and just use the former pointer in the latter case. Jakub