From patchwork Wed Aug 21 08:31:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pierre-Marie de Rodat X-Patchwork-Id: 1150697 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-507426-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="Lx0qf20G"; 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 46D1BW62lYz9sBp for ; Wed, 21 Aug 2019 18:32:51 +1000 (AEST) 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:mime-version:content-type; q=dns; s=default; b=jsxlXnpg8r6PeMmDvdvmXH9HKJUQfY3FyShpVFuHV/p5iUaDZR BK5Mz2FqwTJCjtyNfYkqLBRTUPDlnk2hOzNVY3W+ww8q/mtBIN58TOVIt8AxAYkT 6gEsds5Cp1+arObNVdyfuyVjhbCgp+7drOxgkrNvmnmh56TttudU063aw= 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:mime-version:content-type; s= default; bh=sFYV/bLsFZypi41uyC4bIZfJN3M=; b=Lx0qf20GCNzxyIIp8AjM f80Wb4xBZVsSjawXaTFEK1qGUHZk5Xk8/sRojbjxPuxkMpborKmwPmZfjZL8FQ3T Xy90P6xsOimDIWmZOwMfp1rPciIKj5ncmdSIaARC13TvVO1MjNnhe7UbnhTi0h/a Npi9fYLrVPjNwmeX3dIpIPk= Received: (qmail 95680 invoked by alias); 21 Aug 2019 08:31:48 -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 95616 invoked by uid 89); 21 Aug 2019 08:31:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Aug 2019 08:31:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1382A1163FC; Wed, 21 Aug 2019 04:31:43 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 223KN5WZvKNC; Wed, 21 Aug 2019 04:31:43 -0400 (EDT) Received: from tron.gnat.com (tron.gnat.com [205.232.38.10]) by rock.gnat.com (Postfix) with ESMTP id 022081163EA; Wed, 21 Aug 2019 04:31:43 -0400 (EDT) Received: by tron.gnat.com (Postfix, from userid 4862) id 00E2A646; Wed, 21 Aug 2019 04:31:43 -0400 (EDT) Date: Wed, 21 Aug 2019 04:31:42 -0400 From: Pierre-Marie de Rodat To: gcc-patches@gcc.gnu.org Cc: Gary Dismukes Subject: [Ada] Undefined master in task with limited class-wide aliased entry formal Message-ID: <20190821083142.GA71886@adacore.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes In the case of a task declaring an entry with an aliased formal parameter of a limited class-wide type, the front end was creating a master object (_master) for the access type generated for such an entry formal inside the task specification, even though such access types don't need an associated master. The master object wasn't being copied into the procedure expanded for the task body, but a renaming for the master appeared in the statements of the task body, and the LLVM back end rejects this since the master object doesn't appear in the expanded task procedure (for some reason, gigi doesn't complain). This is fixed by suppressing the creation of the master object in the case where the access-to-limited-class-wide access type is the type of a component in an entry's parameter block. This is similar to the suppression done for the master object in other cases, where the access type designates a type explicitly containing tasks (though the suppression involves testing Comes_From_Source in that case). No simple test (and this only affects the LLVM-based compiler). Tested on x86_64-pc-linux-gnu, committed on trunk 2019-08-21 Gary Dismukes gcc/ada/ * exp_ch3.adb (Build_Master): Suppress call to Build_Class_Wide_Master in the case where the access-to-limited-class-wide type was created for a component in an entry's formal parameter block (Is_Parameter_Block_Component_Type), to prevent a master from being created for such access types generated by the front end in a task spec for entry formals in a parameter block. Add a ??? about whether this suppression should be done more generally (such as by using Comes_From_Source). --- gcc/ada/exp_ch3.adb +++ gcc/ada/exp_ch3.adb @@ -5518,7 +5518,14 @@ package body Exp_Ch3 is -- Note: This code covers access-to-limited-interfaces because they -- can be used to reference tasks implementing them. - elsif Is_Limited_Class_Wide_Type (Desig_Typ) + -- Suppress the master creation for access types created for entry + -- formal parameters (parameter block component types). Seems like + -- suppression should be more general for compiler-generated types, + -- but testing Comes_From_Source, like the code above does, may be + -- too general in this case (affects some test output)??? + + elsif not Is_Param_Block_Component_Type (Ptr_Typ) + and then Is_Limited_Class_Wide_Type (Desig_Typ) and then Tasking_Allowed then Build_Class_Wide_Master (Ptr_Typ);