public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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



  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).