From patchwork Thu Nov 28 14:24:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julian Brown X-Patchwork-Id: 1202084 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-514770-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="poGyD0sq"; 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 47P0Jf2322z9sPJ for ; Fri, 29 Nov 2019 01:24:33 +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:subject:message-id:mime-version:content-type; q=dns; s= default; b=sJhJstBavfNfesx2iBQ+Iz30LJnpK+9trp463IB2vNp3QM/6CAhnP 0avvXjy4QdEzXbASESgLicmmWIlLfHXIeU8UHz531SUYP+ArZIXmXNTy0MG6hi/f kywIraw0JZsube2WIlOUmXZzz5FDSfUc/M2/Eu1azBPIZie1QHZV0U= 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:mime-version:content-type; s= default; bh=owq9dOVn+xuO4KTwir0nGByl0Ug=; b=poGyD0sqlhscNN8I8iCy YlpY+JghEuPjotVp/T/cFD4r78lyCnWSgo/ZWRxT+F8LmdOlt9brRRJo2FUOBGva wl1hiB7hORBWyi8MJX+O0c8ZsGmCXGH4/6q9tB9Jl8hSZZG7XKnmge2oQmriPC6J oj+JiLTXiYUPpAvUdX+a6OE= Received: (qmail 92976 invoked by alias); 28 Nov 2019 14:24:25 -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 92881 invoked by uid 89); 28 Nov 2019 14:24:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=flat X-HELO: esa1.mentor.iphmx.com Received: from esa1.mentor.iphmx.com (HELO esa1.mentor.iphmx.com) (68.232.129.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Nov 2019 14:24:14 +0000 IronPort-SDR: TUiIFA1S1LcLmQq6uOxF9azjHBKvNNI3xJN3my7nvs4n9xagZV2/nH1evjpvNAjZSutqu5YN9M CzfREiMBOcZqAY6skK0Rdp/AUXdI8AxtpIKVgem+5lBQToKYu2RA/z6YkNlYYOzxPm6eXnUlpO qJ2HHn0wtyHVz49qlShDMYljKK9HeUY0IE4Pc+R3AWFTfwEIsv03rTdTAzm1pSXTBngvQfLv68 ++/Iugzg9XqfqcwlWXKGX6WaPXqkx8ZO35iVbb403rH5f6VjnXrNWy29olf5CnkEddOsTLHflX i44= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 28 Nov 2019 06:24:08 -0800 IronPort-SDR: ogkfpW/0vhJUHfcAvhDel4UEdFwn+yRthdlILjyZM7AonHBlnUhW3ISLt9EzSpRi3SjwJd0bpe mm50xu+yUDQ2wbFgzHSADqp4PjtS10sBAYWeiHuV3KNEKG0MLMJMqbD6/Fr7bERcGwu5E587nv fzEL7rQX/QMjwraBzhkJb22eax9ABQMIGZ15bfIuX8klTqQ+pwhlPHFCH13TOJWlgXQhiYBzF8 92HZJqj5Atkky1Jjo9qW+1khqJ5tyydp9loBKBrmGh9h0VvXioaP/eHj9n3yJU7zvYh5exhfhv AFA= Date: Thu, 28 Nov 2019 14:24:02 +0000 From: Julian Brown To: , Joseph Myers , "Thomas Schwinge" Subject: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation Message-ID: <20191128142402.2949931d@squid.athome> MIME-Version: 1.0 X-IsSubscribed: yes As mentioned in PR91985, offloading compilation is broken at present because of an issue with LTO streaming. With thanks to Joseph for hints, here's a solution. Unlike e.g. the _FloatN types, when decimal floating-point types are enabled, common tree nodes are created for each float type size (e.g. dfloat32_type_node) and also a pointer to each type is created (e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node emits these like: (dfloat32_type_node) (dfloat64_type_node) (dfloat128_type_node) * (dfloat32_ptr_type_node) * (dfloat64_ptr_type_node) * (dfloat128_ptr_type_node) I.e., with explicit emission of a copy of the pointed-to type following the pointer itself. When DFP is disabled, we instead get: <<< error >>> <<< error >>> <<< error >>> <<< error >>> <<< error >>> <<< error >>> So, the number of nodes emitted during LTO write-out in the host/read-in in the offload compiler do not match. This patch restores the number of nodes emitted by creating dfloatN_ptr_type_node as generic pointers rather than treating them as flat error_type_nodes. I don't think there's an easy way of creating an "error_type_node *", nor do I know if that would really be preferable. Tested with offloading to NVPTX & bootstrapped. OK to apply? Thanks, Julian ChangeLog gcc/ * tree.c (build_common_tree_nodes): Use pointer type for dfloat32_ptr_type_node, dfloat64_ptr_type_node and dfloat128_ptr_type_node when decimal floating point support is disabled. commit 17119773a8a45af098364b4faafe68f2e868479a Author: Julian Brown Date: Wed Nov 27 18:41:56 2019 -0800 Fix decimal floating-point LTO streaming for offloading compilation gcc/ * tree.c (build_common_tree_nodes): Use pointer type for dfloat32_ptr_type_node, dfloat64_ptr_type_node and dfloat128_ptr_type_node when decimal floating point support is disabled. diff --git a/gcc/tree.c b/gcc/tree.c index 5ae250ee595..db3f225ea7f 100644 --- a/gcc/tree.c +++ b/gcc/tree.c @@ -10354,6 +10354,15 @@ build_common_tree_nodes (bool signed_char) layout_type (dfloat128_type_node); dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); } + else + { + /* These must be pointers else tree-streamer.c:record_common_node will emit + a different number of nodes depending on DFP availability, which breaks + offloading compilation. */ + dfloat32_ptr_type_node = ptr_type_node; + dfloat64_ptr_type_node = ptr_type_node; + dfloat128_ptr_type_node = ptr_type_node; + } complex_integer_type_node = build_complex_type (integer_type_node, true); complex_float_type_node = build_complex_type (float_type_node, true);