From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64600 invoked by alias); 6 Apr 2016 15:07: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 64582 invoked by uid 89); 6 Apr 2016 15:07:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:2600, Hx-spam-relays-external:2600, H*RU:2600 X-HELO: mail-pa0-f42.google.com Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com) (209.85.220.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 06 Apr 2016 15:07:04 +0000 Received: by mail-pa0-f42.google.com with SMTP id fe3so34941555pab.1 for ; Wed, 06 Apr 2016 08:07:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=vNHlEh0CGtIXSsdMWscQV2fEE6v4K9Mg3Kh5YTvhBi4=; b=Om76mCaEaqu9WyRTH6yr0ukQpurhJs3cj7Z32UcYA+HAftm5Wk11MIashwpUEMCaQO Gi/Kni0y9zwEfhFvZSa6GyX/5BXpauj+pjBDe2urlZsK31cuLuC55Pz4DpVvAcgvRRMi o4hdcm7Euls7hcHx52S+qBc0gqxY+NmeLKroX2hypcuWVQDDttG9N26MrhLuGWCNr7Jz x6pKiNALXijEn/CULvN+MVtEj/be36ErwybnIFfhZBrncNxauTKdlby5YQGuNhlRg5oR ymU0FfhVbvqUK2enAugjcLdO18E4Z/kv0I6ZDPF7MIvWukKBj+va+zXc7b2dBqvMWujz 37QA== X-Gm-Message-State: AD7BkJIVihpyGsqTe/wJA5n2lAqJxwc8hHO6lKem/dZPCogI1a3DC1HSGsplPY4LtacLYw== X-Received: by 10.66.152.231 with SMTP id vb7mr71726699pab.132.1459955222178; Wed, 06 Apr 2016 08:07:02 -0700 (PDT) Received: from ?IPv6:2600:1010:b023:634f:a2a8:cdff:fe3e:b48? ([2600:1010:b023:634f:a2a8:cdff:fe3e:b48]) by smtp.googlemail.com with ESMTPSA id dy6sm5711398pab.48.2016.04.06.08.07.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 08:07:00 -0700 (PDT) Subject: Re: [C++ PATCH] PR 70501, ICE in verify ctor sanity To: Jason Merrill References: <5702A3C5.20103@acm.org> <570414B0.7090703@redhat.com> <57042C71.5000205@acm.org> <570521EC.4070104@redhat.com> Cc: GCC Patches From: Nathan Sidwell Message-ID: <57052613.4010100@acm.org> Date: Wed, 06 Apr 2016 15:07:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <570521EC.4070104@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00304.txt.bz2 On 04/06/16 07:49, Jason Merrill wrote: > On 04/05/2016 05:21 PM, Nathan Sidwell wrote: >> On 04/05/16 12:40, Jason Merrill wrote: >> >>> It's not clear to me that we really need a TARGET_EXPR for vector values. Since >>> one element of a vector can't refer to another, we don't need the ctx->ctor >>> handling. Perhaps we should handle vectors like we do PMF types in >>> cxx_eval_bare_aggregate? >> >> That may be abstractly better, but we do currently wrap constructors in >> target_exprs for vector compound_literals (which is what I was >> following). See the get_target_expr_sfinae calls in >> finish_compound_literal for instance. That happens for the '(v4si){(0, >> 0)}' subexpression of the testcase. > > Sure, but that also seems unnecessary; vector rvalues don't have object identity > the way class and array rvalues do. I'll investigate further. At least we have a fallback now. nathan