From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107112 invoked by alias); 16 Jan 2019 11:59:19 -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 107093 invoked by uid 89); 16 Jan 2019 11:59:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Jan 2019 11:59:18 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 119D3C0BFBA1; Wed, 16 Jan 2019 11:59:17 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-18.ams2.redhat.com [10.36.116.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A712F6061B; Wed, 16 Jan 2019 11:59:16 +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 x0GBxE50016679; Wed, 16 Jan 2019 12:59:14 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x0GBxC8d016678; Wed, 16 Jan 2019 12:59:12 +0100 Date: Wed, 16 Jan 2019 11:59:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Martin =?utf-8?B?TGnFoWth?= , GCC Patches , Jan Hubicka Subject: Re: [PATCH] Reset proper type on vector types (PR middle-end/88587). Message-ID: <20190116115911.GR30353@tucnak> Reply-To: Jakub Jelinek References: <0d2f9afa-b0fb-b81b-aba4-1f7f1faa5f35@suse.cz> <65b91fc9-fcf5-8b73-94dc-2a16317fc59c@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00901.txt.bz2 On Wed, Jan 16, 2019 at 12:50:23PM +0100, Richard Biener wrote: > I guess so. There's not much we can do about this other than making > DECL_MODE dynamic the same way as TYPE_MODE. I still believe > this is the wrong direction and instead RTL expansion should properly > adjust DECL_RTL and generally on GIMPLE we shouldn't need to > commit to modes early at all... Are there cases where DECL_MODE (decl) should not be equal to TYPE_MODE (TREE_TYPE (decl))? Is that for structs with flexible array members where the initializer is filling up the flexible array member, or something different? E.g. in expand_debug* it shouldn't be hard to use TYPE_MODE if VECTOR_TYPE_P (TREE_TYPE (decl)), but there are many other uses of DECL_MODE. Jakub