From patchwork Fri Mar 4 20:37:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 592204 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 8CB4C1401DA for ; Sat, 5 Mar 2016 07:37:29 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=VGlji6Zv; dkim-atps=neutral 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:subject:message-id:reply-to:mime-version:content-type; q=dns; s=default; b=bS4Vy6/gby9ulcEin9zzeuE9q08GNQsc7tHQukJBxS1 5ONN2hLkfmnwnqS79oPOAoA5/CtM1Ogc+bDe5Cup81oC2gKGSSGLHBqUQgwzzhVL nWR4YyM47h7GwSGDewFZLXQ2v7oWHCrEG7bxBuaKT0WRM6Mmsk6w+RNssYwxSn1g = 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:subject:message-id:reply-to:mime-version:content-type; s=default; bh=U/Gm9AUPPFFbtHNLs/F8qm+Sn5U=; b=VGlji6ZvkohSJAknS Yu5hRcyFsub0plzff2llIW+NvKXlAT459LeuUp2evpuTtKzwvAUw8ohQgUjmpgVv xD3w39TMq6m0qHr83EHEOdx3GYZWlWcmlmdRd42xhE6km0Z8JHKYzUko4nfCACaT RUC+IKzq9CAXtfiFK0Q2pOO8VI= Received: (qmail 84329 invoked by alias); 4 Mar 2016 20:37:20 -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 84317 invoked by uid 89); 4 Mar 2016 20:37:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=notices, fold_convert 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 04 Mar 2016 20:37:18 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id CD8F5C0005CF for ; Fri, 4 Mar 2016 20:37:15 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-25.phx2.redhat.com [10.3.113.25]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u24KbEbi012072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 4 Mar 2016 15:37:15 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u24KbCpn006904 for ; Fri, 4 Mar 2016 21:37:13 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u24KbBUm006903 for gcc-patches@gcc.gnu.org; Fri, 4 Mar 2016 21:37:11 +0100 Date: Fri, 4 Mar 2016 21:37:11 +0100 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix va_arg ((ap), ...) on s390* with C++14 (PR c++/70084) Message-ID: <20160304203711.GM3017@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes Hi! As mentioned in the PR, on the following testcase we emit invalid error on s390* in the va_arg ((ap), int) case, va_arg (ap, int) is fine (and the former is fine in -std=c++11 or -std=c++98 too). The bug only triggers in constructors (or destructors), and happens because build_va_arg creates ADDR_EXPR that has slightly different type, and has INDIRECT_REF inside of it. copy_tree_body_r notices this and cancels the two, but unlike e.g. build_fold_addr_expr_with_type_loc if (TREE_CODE (t) == INDIRECT_REF) { t = TREE_OPERAND (t, 0); if (TREE_TYPE (t) != ptrtype) t = build1_loc (loc, NOP_EXPR, ptrtype, t); <<<<<<---------- this } it doesn't attempt to handle the case where ADDR_EXPR contained different type from the type of INDIRECT_REF's operand. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, bootstrap/regtest on s390{,x}-linux pending. Ok for trunk if it passes even there? 2016-03-04 Jakub Jelinek PR c++/70084 * tree-inline.c (copy_tree_body_r): When cancelling ADDR_EXPR of INDIRECT_REF and ADDR_EXPR changed type, fold_convert it to the right type. * g++.dg/expr/stdarg3.C: New test. Jakub --- gcc/tree-inline.c.jj 2016-02-12 00:50:55.000000000 +0100 +++ gcc/tree-inline.c 2016-03-04 18:35:28.079458603 +0100 @@ -1266,7 +1266,12 @@ copy_tree_body_r (tree *tp, int *walk_su /* Handle the case where we substituted an INDIRECT_REF into the operand of the ADDR_EXPR. */ if (TREE_CODE (TREE_OPERAND (*tp, 0)) == INDIRECT_REF) - *tp = TREE_OPERAND (TREE_OPERAND (*tp, 0), 0); + { + tree t = TREE_OPERAND (TREE_OPERAND (*tp, 0), 0); + if (TREE_TYPE (t) != TREE_TYPE (*tp)) + t = fold_convert (remap_type (TREE_TYPE (*tp), id), t); + *tp = t; + } else recompute_tree_invariant_for_addr_expr (*tp); --- gcc/testsuite/g++.dg/expr/stdarg3.C.jj 2016-03-04 18:08:22.029669394 +0100 +++ gcc/testsuite/g++.dg/expr/stdarg3.C 2016-03-04 18:06:50.000000000 +0100 @@ -0,0 +1,18 @@ +// PR c++/70084 +// { dg-do compile } + +#include + +struct A +{ + A (const char *f, ...); +}; + +A::A (const char *f, ...) +{ + va_list ap; + va_start (ap, f); + int i = va_arg (ap, int); // { dg-bogus "first argument to 'va_arg' not of type 'va_list'" } + int j = va_arg ((ap), int); // { dg-bogus "first argument to 'va_arg' not of type 'va_list'" } + va_end (ap); +}