From patchwork Wed Jan 23 09:48:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 1029825 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-494585-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="WAvygfEO"; 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 43l0qW2nlRz9s9G for ; Wed, 23 Jan 2019 20:49:09 +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:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=jWi4W+1fd+cLC0Pb azhLcvPSL0AuzYhFUom1sR/iQvWtHi0ZsCt6NhHoNGHMxT1xCg8xRFHmesU7g8TO iLEhAQwVSnmHNIStCDOTGt+RRp30xhO44QcmJFqCYVUfQpueTpoxGFM1iq2bxVXZ V32tp1hFlGKYBG0A0ZLx/HdKWRM= 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:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=rBJgdl1Nd4EiX6hVRrJh5F ulC1Y=; b=WAvygfEOv/nMEqwm9fmMTL18RQGzSG62kQsvV+A2s34vZbRtx9ULLx x7vi6g7z5w+FccN916RE2PWE/2voND3LJSZQ+azAl2VE/jrSLyZhf6X18tDMaGib s7O0SLWwqsu2tSIh4cYtPpWwkn8ctT13xW4HjLuCY6vUlEViFtGP0= Received: (qmail 73026 invoked by alias); 23 Jan 2019 09:48:43 -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 69980 invoked by uid 89); 23 Jan 2019 09:48:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Jan 2019 09:48:40 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id C5C4481388 for ; Wed, 23 Jan 2019 10:48:37 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqGuU7QrFb4r for ; Wed, 23 Jan 2019 10:48:37 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id A4B768137C for ; Wed, 23 Jan 2019 10:48:37 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [patch] Fix segfault during inlining of thunk Date: Wed, 23 Jan 2019 10:48:23 +0100 Message-ID: <7237749.isj1USbTg8@polaris> MIME-Version: 1.0 Hi, this is a regression present in Ada on the mainline since we switched to using the internal support for thunks: expand_thunk segfaults during inlining when trying to access the DECL_RESULT of the special alias built to make the call from the thunk local, if the DECL_RESULT of the thunk is DECL_BY_REFERENCE. It turns out that neither the C++ nor the Ada front-end builds the DECL_RESULT of this special alias (the C++ front-end apparently doesn't even build that of the thunk itself so expand_thunk has code to patch this up). Moreover it's a bit strange to first try: restmp = gimple_fold_indirect_ref (resdecl); i.e. build the dereference using the type of resdecl and then use the type of the DECL_RESULT of the alias if this failed. So the attached fix changes this to using the type of resdecl in the latter case too. Bootstrapped/regtested on x86_64-suse-linux, OK for the mainline? 2019-01-22 Eric Botcazou * cgraphunit.c (cgraph_node::expand_thunk): When expanding a GIMPLE thunk that returns by reference, use the type of the return object of the thunk instead of that of the alias to build the dereference. 2019-01-23 Eric Botcazou * gnat.dg/specs/opt4.ads: New test. Index: cgraphunit.c =================================================================== --- cgraphunit.c (revision 268071) +++ cgraphunit.c (working copy) @@ -1916,10 +1916,9 @@ cgraph_node::expand_thunk (bool output_a restmp = gimple_fold_indirect_ref (resdecl); if (!restmp) restmp = build2 (MEM_REF, - TREE_TYPE (TREE_TYPE (DECL_RESULT (alias))), + TREE_TYPE (TREE_TYPE (resdecl)), resdecl, - build_int_cst (TREE_TYPE - (DECL_RESULT (alias)), 0)); + build_int_cst (TREE_TYPE (resdecl), 0)); } else if (!is_gimple_reg_type (restype)) {