From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18405 invoked by alias); 4 Oct 2019 04:44:52 -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 18143 invoked by uid 89); 4 Oct 2019 04:44:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 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; Fri, 04 Oct 2019 04:44:50 +0000 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 226C481F0C for ; Fri, 4 Oct 2019 04:44:49 +0000 (UTC) Received: by mail-qk1-f197.google.com with SMTP id z128so5159831qke.8 for ; Thu, 03 Oct 2019 21:44:49 -0700 (PDT) Received: from [192.168.1.116] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id t199sm2454404qke.36.2019.10.03.21.44.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Oct 2019 21:44:47 -0700 (PDT) Subject: Re: [C++ PATCH] Improve cxx_fold_indirect_ref (PR c++/71504, take 2) To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Jonathan Wakely , Marek Polacek References: <20190927203104.GY15914@tucnak> <688ebe68-e83f-9559-a1c7-883758b2bd74@redhat.com> <20191003182507.GT15914@tucnak> <459890e3-81ef-896f-83b0-d9251e0d3966@redhat.com> <20191003205743.GV15914@tucnak> From: Jason Merrill Message-ID: <9b1c3e3e-a615-e28a-dfd6-714b2a7d5f30@redhat.com> Date: Fri, 04 Oct 2019 04:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20191003205743.GV15914@tucnak> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00275.txt.bz2 On 10/3/19 4:57 PM, Jakub Jelinek wrote: > On Thu, Oct 03, 2019 at 03:57:17PM -0400, Jason Merrill wrote: >> That sounds better. > > Ok. > >>> And, second comment, not 100% sure about the unions, e.g. whether we >>> shouldn't somehow try to figure what is the active union member and only use >>> the active one rather than trying all. >> >> Hmm, good question. Can we get away with not recursing for unions? Trying >> all of them might end up choosing an inactive member that shares a common >> initial sequence with the active member. Which is OK for reads, but not for >> writes. > > Nothing in check-c++-all cares about unions there, so like this? > Worst case if we have a testcase that will break because of that > we'll need to figure out what to do. But in unions it could very well just > find an inactive member without common initial sequence that just happens to > have the right type at the same offset. > > So, is the following ok for trunk if it passes full bootstrap/regtest? > In attachment is the interdiff from the previous patch. OK, thanks. Jason