From: Eric Botcazou <botcazou@adacore.com>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: gcc-patches@gcc.gnu.org, Richard Biener <rguenther@suse.de>,
Arnaud Charlet <charlet@adacore.com>
Subject: Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions
Date: Tue, 10 Aug 2021 22:56:39 +0200 [thread overview]
Message-ID: <1703105.VLH7GnMWUR@arcturus> (raw)
In-Reply-To: <AM8PR10MB470804C696B1838E0D68856BE4F79@AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM>
> 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)
> {
> <bb 2> [local count: 1073741824]:
> [test.adb:5:7] return x_1(D);
>
> }
>
> and
>
> integer test.test2 (integer x)
> {
> <bb 2> [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)
> {
> <bb 2> [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;
>
> <bb 2> [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
next prev parent reply other threads:[~2021-08-10 20:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-26 16:45 Bernd Edlinger
2021-08-02 13:07 ` Eric Botcazou
2021-08-02 17:18 ` Bernd Edlinger
2021-08-04 14:33 ` Eric Botcazou
2021-08-04 17:59 ` Bernd Edlinger
2021-08-09 14:37 ` Eric Botcazou
2021-08-10 7:23 ` Richard Biener
2021-08-10 15:46 ` Eric Botcazou
2021-08-10 9:43 ` Bernd Edlinger
2021-08-10 20:56 ` Eric Botcazou [this message]
2021-08-11 5:27 ` Bernd Edlinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1703105.VLH7GnMWUR@arcturus \
--to=botcazou@adacore.com \
--cc=bernd.edlinger@hotmail.de \
--cc=charlet@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).