From patchwork Fri Dec 6 23:46:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1205311 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-515395-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="UGQftGyn"; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="Jd22VIXe"; 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 47V8Q01vbXz9sPK for ; Sat, 7 Dec 2019 10:47:02 +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:references:mime-version :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=mwYWaGbaC5EwBk8/yfkEQ6P1637h9oiwqM+GbIP8IvOUJvMvRGexN m1Baq/3mITzdl5FCA+csumys2d79sbHf34xQSAZx5SHDfsYmXcamXfDW1/UvpFWK 7Ua7uoS2TZb0qho+AQL9CxlY9tOfsJrUfJS8bcq1jPxEcneNgVQT4k= 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:references:mime-version :in-reply-to:content-type:content-transfer-encoding; s=default; bh=esLm8f7mxjEx50lY12KQSsTodLc=; b=UGQftGynBiiWOMMOruumMFzDcAki 4Qhx99xURrvImSYYFNDlR/0Rt+aL63+iiXAZbXsgTMxycE/WVYbsl63lnySB16d9 7i2jLzi6lo7m4i4mwRDRW3aGkQMol0y8ZazPV7/u6/eYu2YMppAhtL8Gy2wL9I75 /m6e0j0BvpFjE0U= Received: (qmail 108562 invoked by alias); 6 Dec 2019 23:46:50 -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 108445 invoked by uid 89); 6 Dec 2019 23:46:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=H*i:sk:251bcca, H*f:sk:251bcca, cp_save_expr, H*MI:sk:251bcca X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2019 23:46:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575676006; 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=S7jKnpYU3DO1edMwqEfgA8CZK4GmWYSlkTYeJG9HxvI=; b=Jd22VIXeuY32HTOyVnT7KxRF7VJsPpxnz1f56btVvbYFUcLf2swAD4CMBx+TDduxhcvanl KxIkgtypdsDakqGfHhXaNrWDkthMaC1Fzeho6x0TYN73dZDJoOJ3JQ3xvEelQcWZJicjRe GuTcQzeU/JNZC7jzFWP9FK1+LDLTxm0= 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-332-LlCf9aAnPMSfUEHO2qHI6A-1; Fri, 06 Dec 2019 18:46:44 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E3512DB21 for ; Fri, 6 Dec 2019 23:46:43 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-59.ams2.redhat.com [10.36.117.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7B4E260BF4; Fri, 6 Dec 2019 23:46:43 +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 xB6NkfNG001386; Sat, 7 Dec 2019 00:46:41 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id xB6Nkeuj001385; Sat, 7 Dec 2019 00:46:40 +0100 Date: Sat, 7 Dec 2019 00:46:40 +0100 From: Jakub Jelinek To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: [committed] Fix up xvalue handling in ?: with omitted middle operand (PR c++/92831) Message-ID: <20191206234640.GK10088@tucnak> Reply-To: Jakub Jelinek References: <20191206162836.GE10088@tucnak> <251bcca7-3964-3879-b19f-344da9a325a8@redhat.com> MIME-Version: 1.0 In-Reply-To: <251bcca7-3964-3879-b19f-344da9a325a8@redhat.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 Content-Disposition: inline X-IsSubscribed: yes On Fri, Dec 06, 2019 at 02:31:55PM -0500, Jason Merrill wrote: > > Note, just to double check g++ doesn't ICE on expr1 ? : expr2 GNU extension, > > I also wrote the attached testcase, but unlike the testcase included in the > > patch which behaves the same with patched g++ as does recent clang++, the > > testcase with expr1 ? : expr2 (omitted second operand) actually never > > extends the lifetime of any temporary (that is the baz function), unlike > > clang++ which extends the lifetime of expr2 if expr1 is false, and doesn't > > extend lifetime of anything if expr1 is true. This is outside of the scope > > of the standard, so no idea what is correct, so I'm just asking how it > > should behave. > > I would expect one or the other to be extended. I imagine that clang not > extending expr1 is a bug due to however they avoid evaluating it twice. > > > extend_ref_init_temps_1 is never called in that case when the expression is COND_EXPR. > > I think the problem is in build_conditional_expr_1, which needs to treat > xvalues properly in the handling of this extension, i.e. > > > - if (lvalue_p (arg1)) > > + if (glvalue_p (arg1)) > > arg2 = arg1 = cp_stabilize_reference (arg1); Indeed, that fixes it and you've preapproved a patch doing that on IRC, which I've committed to trunk now that it successfully bootstrapped/regtested on x86_64-linux and i686-linux. Thanks. 2019-12-07 Jason Merrill Jakub Jelinek PR c++/92831 * call.c (build_conditional_expr_1): For ?: with omitted middle operand use cp_stabilize_reference if arg1 is glvalue_p rather than just if it is lvalue_p. * g++.dg/ext/temp-extend1.C: New test. Jakub --- gcc/cp/call.c.jj 2019-12-06 21:15:48.842199643 +0100 +++ gcc/cp/call.c 2019-12-06 22:01:18.737636630 +0100 @@ -5077,7 +5077,7 @@ build_conditional_expr_1 (const op_locat warn_for_omitted_condop (loc, arg1); /* Make sure that lvalues remain lvalues. See g++.oliva/ext1.C. */ - if (lvalue_p (arg1)) + if (glvalue_p (arg1)) arg2 = arg1 = cp_stabilize_reference (arg1); else arg2 = arg1 = cp_save_expr (arg1); --- gcc/testsuite/g++.dg/ext/temp-extend1.C.jj 2019-12-06 22:10:45.489814074 +0100 +++ gcc/testsuite/g++.dg/ext/temp-extend1.C 2019-12-06 22:10:09.495374051 +0100 @@ -0,0 +1,43 @@ +// PR c++/92831 +// { dg-do run { target c++11 } } +// { dg-options "" } + +template using id = T; +struct S { S () : s (false) { ++c; } S (bool x) : s (x) { ++c; } ~S () { --c; }; bool s; static int c; }; +int S::c = 0; + +void +foo (int i) +{ + const bool&& a + = id{false, true, false}[i].s + ? id{true, false}[i].s : id{true, false, true, false}[i].s; + if (S::c != (i ? 2 : 4)) + __builtin_abort (); +} + +void +baz (int i) +{ + const bool&& a = id{false, true, false}[i].s + ? : id{true, false, true, false}[i].s; + if (S::c != (i ? 3 : 4)) + __builtin_abort (); +} + +int +main () +{ + foo (0); + if (S::c != 0) + __builtin_abort (); + foo (1); + if (S::c != 0) + __builtin_abort (); + baz (0); + if (S::c != 0) + __builtin_abort (); + baz (1); + if (S::c != 0) + __builtin_abort (); +}