From patchwork Tue Jul 2 13:21:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Marc_Poulhi=C3=A8s?= X-Patchwork-Id: 93234 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3F29A388264A for ; Tue, 2 Jul 2024 13:25:22 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by sourceware.org (Postfix) with ESMTPS id B9367388216C for ; Tue, 2 Jul 2024 13:21:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B9367388216C Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B9367388216C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::232 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719926514; cv=none; b=WCIx/btq0LXD+ROalguQLOanZIyZYxIOhsW0+VCTgEIii+32cTOteMd2wz82qalzWqo4JO0P2GJaHBsGsdFizUNiWBzpM4yde+LnfR/MPrKC/A29AyHgo/vA49THRVeC2xir93U1NFCVVRApEMwPEYTe4MWRgyRZ1xTWBV6QfdM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719926514; c=relaxed/simple; bh=/GxHsv+jg/uNpVUlWo4C8qgCTn2XAywxH5uiAU/z194=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=svrs592JSoYqqBkj5oVsGozbhmFx6UxR2dnjZLxUyKPIonVRhpxdEX0Zs5mYkvXZu2JVedTchpki77sRgfX7qEk+VrAvQwYLuEr9Pchs4Wmytne5FTLCPZf/egVqId0+hQVCnF3g4lA0U5QWIymhXPZ2MvIN4KKMDLRwHJ21oUQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2ec58040f39so40419671fa.2 for ; Tue, 02 Jul 2024 06:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1719926510; x=1720531310; darn=gcc.gnu.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=2hB970Xj3uFG7x1pYRL22JrNBFDkGID6VynyzsvQ3f0=; b=jHfx2KOirORAzucQOWXM1qgd52i8xVPJeve8xL04N9V1TjJ4es2J/uq7Vt/zXzlHrl 6oW7Ll2NtB+AsRCxAH3N/t8nt/V307qqmMPf5FvK1PzxTizHYZgTdEqzDcQFiMNjBhxt 2jo7dWOtNLPBVcAz3zdsmZBUXkouJc1p5mKdBC0MceqmD4Z8IxLHhOOLdA1fYH7dui6N CzZA/ZyUPN0gMEOkzIBH6/MhZ+h6HSEHjNtRFBPUXpfX37m66EulgFDv0hQk+j6v4iGG U4jGNcmZUJLX2mdFvcoUPtSV+wxYcYmGwjDt7GYFmUc25nRsCzoK8r3zbVGdA8aajDwf 8AWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719926510; x=1720531310; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2hB970Xj3uFG7x1pYRL22JrNBFDkGID6VynyzsvQ3f0=; b=qaHrOAk/sJge7fKy0LRyahPpqSxlaDDa1KcXpQg5BsD9O83O7qNLmVf6ERgI4XE3tN 4SKgYtHbL1WaSe4iAEM0R4knuqB+fboO4s4l7f0HhnVDQurJnHTn8f9ca1dcAO+bOT6R qcqvt+YmfY85s4MYwCw/qDyM3aA7YCgI2OrN/Zpmp0WsmEFbhQ9MwJ6W6+428axsTRet SOkeTpOqYZQeRD+k/NalYmwev0Jz96iQbjPacv0BhdRfByY+MR8q86l+D/EaazaX8qy1 2Wbw8lRAbSeZeVfnRFJdUDYeZEflVnwmPq0YKd/uubpnD1hOP2nm9/866igKUa16plLE I5bw== X-Gm-Message-State: AOJu0YyPmL8BRd8CtGGv6sKiSK1pw5LG/v3lgESBtscHL+uKwC7dXPy+ pdN4QvKeB/m+dyRqM8vvQwbDsENrRH6s1v/T6PzcAUCJDiGb2+Q40/RbcYD4BNHeghKBr5V5TF0 = X-Google-Smtp-Source: AGHT+IEGM6rOORl+SAIfFhGbjb1gYje1Uj1eC3yILpfsu3reRTK3ulnZM2shcrvmtjgV69etSsW4ZA== X-Received: by 2002:a2e:a4a2:0:b0:2ec:40ab:694d with SMTP id 38308e7fff4ca-2ee5e3594e5mr52672991fa.1.1719926510173; Tue, 02 Jul 2024 06:21:50 -0700 (PDT) Received: from poulhies-Precision-5550.lan ([2001:861:3382:1a90:53cf:a5ff:fb60:5a70]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4256b09abbfsm197319895e9.35.2024.07.02.06.21.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jul 2024 06:21:49 -0700 (PDT) From: =?utf-8?q?Marc_Poulhi=C3=A8s?= To: gcc-patches@gcc.gnu.org Cc: Steve Baird Subject: [COMMITTED 10/13] ada: Use clause (or use type clause) in a protected operation sometimes ignored. Date: Tue, 2 Jul 2024 15:21:26 +0200 Message-ID: <20240702132130.523603-10-poulhies@adacore.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20240702132130.523603-1-poulhies@adacore.com> References: <20240702132130.523603-1-poulhies@adacore.com> MIME-Version: 1.0 X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces~patchwork=sourceware.org@gcc.gnu.org From: Steve Baird In some cases, a use clause (or a use type clause) occurring within a protected operation is incorrectly ignored. gcc/ada/ * exp_ch9.adb (Expand_N_Protected_Body): Declare new procedure Unanalyze_Use_Clauses and call it before analyzing the newly constructed subprogram body. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/exp_ch9.adb | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/gcc/ada/exp_ch9.adb b/gcc/ada/exp_ch9.adb index a8c70598fa5..939a8e25d5a 100644 --- a/gcc/ada/exp_ch9.adb +++ b/gcc/ada/exp_ch9.adb @@ -8316,6 +8316,11 @@ package body Exp_Ch9 is -- P (Param1 .. ParamN); -- end + procedure Unanalyze_Use_Clauses (Op_Body : Node_Id); + -- Use and Use_Type clauses in the tree rooted at Op_Body + -- that have already been analyzed need to be marked as unanalyzed + -- because otherwise they will be ineffective in their new context. + --------------------------------------- -- Build_Dispatching_Subprogram_Body -- --------------------------------------- @@ -8377,6 +8382,31 @@ package body Exp_Ch9 is Make_Handled_Sequence_Of_Statements (Loc, Stmts)); end Build_Dispatching_Subprogram_Body; + --------------------------- + -- Unanalyze_Use_Clauses -- + --------------------------- + + procedure Unanalyze_Use_Clauses (Op_Body : Node_Id) is + + function Process_One_Node (N : Node_Id) return Traverse_Result; + -- If N is a use or use type node then unanalyze it. + + procedure Process_Tree is new Traverse_Proc (Process_One_Node); + + function Process_One_Node (N : Node_Id) return Traverse_Result is + begin + if Nkind (N) in N_Use_Package_Clause | N_Use_Type_Clause then + Set_Analyzed (N, False); + end if; + return OK; -- return Skip if Is_Analyzed (N) ? + end Process_One_Node; + + -- Start of processing for Analyze_Use_Clauses + + begin + Process_Tree (Op_Body); + end Unanalyze_Use_Clauses; + -- Start of processing for Expand_N_Protected_Body begin @@ -8426,6 +8456,17 @@ package body Exp_Ch9 is Build_Unprotected_Subprogram_Body (Op_Body, Pid); end if; + -- Ugly. + -- We are going to perform name resolution in analysis of + -- this new body, but any already-analyzed use clauses + -- will be ineffective in this new context unless we take + -- action to "reactivate" them. So that's what we do here. + -- We arguably shouldn't be performing name resolution + -- here (just like we shouldn't perform name resolution in + -- an expanded instance body), but that's a larger issue. + + Unanalyze_Use_Clauses (New_Op_Body); + Insert_After (Current_Node, New_Op_Body); Current_Node := New_Op_Body; Analyze (New_Op_Body);