From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 4B99C3858406 for ; Tue, 10 Aug 2021 20:56:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B99C3858406 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-wr1-x42f.google.com with SMTP id l18so28107432wrv.5 for ; Tue, 10 Aug 2021 13:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=urWXt7I1Hfz2kLZ5kNEI3freSTy2UZOb5l30GjkFJo4=; b=PLbpYdSOF0MATwii2A5IBu81OEglwgsnPV4bsJqhOvhl1RZEBMsoupb+vsdLyUqbzB RqIjuO46A3pWPYCuce+xzjhombAIZy68cQU+SK55tAhv8MtZghONDkZgZHmp6Ed91eF4 N0CvyMW8hP8Ao5NHT98AsVL2D+lW2pMG51MK5dOuire2zUKyZkzz6E8UytReRQqn5zKn B1LlPni0VSKwbISQusF76/6qNwFv8P4fRs8jY2qgHf7OzpYhbg8f7SY4ocAwf4InEfFs 2pmd3fOz8YPDsaa/CfGoy+JLM5JtetSnWjbi9IFh/qn8PlSt8j32LCa8HsDdJlSPM4rB A1qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=urWXt7I1Hfz2kLZ5kNEI3freSTy2UZOb5l30GjkFJo4=; b=BWO4HAkh3MN5XLcxFMH49jfKQdIoUzieBMzufnkHdqf0i8N+5PIPFDt7Q1fM9MjnZ8 v1fPjR2XBeWoEOSZ/T9gcItEJojG5c2rqkt3UFQrmcW+KcqVXSUto3qr+FQEVGp59jDk FWXthNKBg8Z6o2/Q4/T8z8NFMuV4sFiyu/R+mo9o3bC0VCTF+xL+bFYkJ8d466hqN96Q TnoslxuZQBciD80yJFUpIIYs+emJeCcpUaKh1AEPhVBpSM5EFUv4tVLbzDb80/N7osHH wxM4Vu0K0mS/VExNxvpHeEsJwdPyePozMUzfjCDAN/T1pS2RiNNz6auClSYYKQYyM04Y tkEw== X-Gm-Message-State: AOAM533fSbI+XnkG28XNdPt/ZjAUudyXuNT+1i+OaLZW3WRSjXMFORvX GjC1kqRtt8k+XZUFYoMqNPRpRA== X-Google-Smtp-Source: ABdhPJxq+3Ke3dURGasTjbNk4MFhnP8+e6Z02Q8mvrCBJaMTNUFnyFfDo6BLigPn2rPTbHvIaIj6iA== X-Received: by 2002:a05:6000:1051:: with SMTP id c17mr29833064wrx.280.1628628966344; Tue, 10 Aug 2021 13:56:06 -0700 (PDT) Received: from arcturus.localnet ([2a01:cb10:8647:7500:91f1:5b1d:74b:10d6]) by smtp.gmail.com with ESMTPSA id l9sm10151419wrt.95.2021.08.10.13.56.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Aug 2021 13:56:05 -0700 (PDT) From: Eric Botcazou X-Google-Original-From: Eric Botcazou To: Bernd Edlinger Cc: gcc-patches@gcc.gnu.org, Richard Biener , Arnaud Charlet Subject: Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions Date: Tue, 10 Aug 2021 22:56:39 +0200 Message-ID: <1703105.VLH7GnMWUR@arcturus> In-Reply-To: References: <1886121.usQuhbGJ8B@arcturus> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 20:56:17 -0000 > Ah, thanks, I tried it but the defs__struct1IP function has > DECL_IGNORED_P = false when I build it with -gnatD. > > So that would not be affected by setting DECL_SOURCE_LOCATION to > UNKNOWN_LOCATION as done in the proposed patch, because that is only > done for functions with DECL_IGNORED_P = true. Ouch, I should have checked it myself... Thanks for doing the investigation. > Then we have ordinary functions with DECL_IGNORED_P = false, > but they are morphed into a thunk calling a similar looking function > and the thunk has now DECL_IGNORED_P = true, and all debug info > removed, except the DECL_SOURCE_LOCATION. To make this even worse, > the similar looking function is inlined into the thunk again, and > all debug info is again stripped away. > > And when this happens it is desirable to at least see the source line where > the original function was declared. > > > As an example, please consider this test case: > > $ cat test.ads > package test is > > type Func_Ptr is access function (X : Integer) return Integer; > > function Test1 (X : Integer) return Integer; > function Test2 (X : Integer) return Integer; > function DoIt (X : Integer; Func : Func_Ptr) return Integer; > > end test; > $ cat test.ads > package test is > > type Func_Ptr is access function (X : Integer) return Integer; > > function Test1 (X : Integer) return Integer; > function Test2 (X : Integer) return Integer; > function DoIt (X : Integer; Func : Func_Ptr) return Integer; > > end test; > > $ cat test.adb > package body test is > > function Test1 (X : Integer) return Integer is > begin > return X; > end Test1; > > function Test2 (X : Integer) return Integer is > begin > return X; > end Test2; > > function DoIt (X : Integer; Func : Func_Ptr) return Integer is > begin > return Func (X); > end DoIt; > > end test; > > $ cat main.adb > with Ada.Text_IO; use Ada.Text_IO; > with test; use test; > > procedure Main is > > X : Integer := 7; > Y : Integer := DoIt (X, Test1'Access); > Z : Integer := DoIt (X, Test2'Access); > > begin > Put_Line (X'Img & " " & Y'Img & " " & Z'Img); > end Main; > > $ gnatmake -f -g -O2 main.adb -save-temp -fdump-tree-all-lineno > > Now Test1 and Test2 are ordinary functions, but Test2 ends up as > DECL_IGNORED_P = true, that happens between test.adb.052t.local-fnsummary2 > and test.adb.092t.fixup_cfg3: Ouch (bis). Quite unexpected that DECL_IGNORED_P is set out of nowhere. It's Identical Code Folding which turns Test2 into a thunk? > in test.adb.052t.local-fnsummary2 we have: > > integer test.test1 (integer x) > { > [local count: 1073741824]: > [test.adb:5:7] return x_1(D); > > } > > and > > integer test.test2 (integer x) > { > [local count: 1073741824]: > [test.adb:10:7] return x_1(D); > > } > > > but in test.adb.092t.fixup_cfg3 > > we have > > integer test.test1 (integer x) > { > [local count: 1073741824]: > [test.adb:5:7] return x_1(D); > > } > > and > > integer test.test2 (integer x) > { > integer D.4674; > integer retval.5; > integer _4; > > [local count: 1073741824]: > # DEBUG x => x_1(D) > _4 = x_1(D); > # DEBUG x => NULL > retval.5_2 = _4; > return retval.5_2; > > } > > > the line numbers are gone, and the function has DECL_IGNORED_P, > but still a useful DECL_SOURCE_LOCATION, I don't know > where the DECL_SOURCE_LOCATION can be seen in the dump files, > but from debugging this effect, I know that quite well. > > This second effect is why as a special case DECL_IGNORED_P functions > with valid looking DECL_SOURCE_LOCATION have now a .loc statement, > because that is less surprising to a user than having no line numbers > at all here. OK, thanks for the explanation, the patch is OK then. -- Eric Botcazou