Re: dejagnu version update?

[Jacob Bachmeyer via Gcc]

Rob Savoye wrote:

On 5/14/20 10:08 AM, David Edelsohn wrote:
  

Have you approached the Linux Foundation Core Infrastructure
Initiative for funding for both DejaGNU maintenance (patch backlog)
and refactoring DejaGNU in Python efforts?



  Not that team, the folks I talked to thought I was crazy for wanting
to refactor it. :-) That's been the usual answer from anyone. I even
talked about this at GNU Tools Cauldron once. Seriously though, it'd be
great to analyze the current code base, write an actual design document,
clean internal APIs, and build something we can use for another 30
years.
This is very close to the volunteer work I have been doing on DejaGNU:  
just documenting the existing API would be a major step forwards, with 
follow-up plans to slowly move DejaGNU to more modern Tcl.  Using modern 
Tcl features, like namespaces (introduced in Tcl 8.0) and slave 
interpreters (introduced in Tcl 7.6) would enable significant clean up 
and possibly even simultaneous support for multiple testsuite API 
versions, allowing even backwards-incompatible changes by preserving 
support for the old API and requiring the new API to be requested.



 I'd start by writing a solid expect module for Python, and then
embedding Tcl in Python as a comparability layer. I understand it'd be a
huge project, which is why I haven't done this as a volunteer.
  

Amusingly, I believe both of those may already be in CPAN for Perl 5.  :-)

-- Jacob

Re: dejagnu version update?

[Rob Savoye]

On 5/14/20 5:34 PM, Maciej W. Rozycki wrote:

> And then current development appears ongoing, ferociously indeed, with the 
> last check in literally today (barring my time zone), as indicated here: 
> .

  It's obvious I haven't been paying attention, so much for my
retirement... :-)  That's awesome actually, and it does look active.

>  Other than that what would be the technical advantage from rewriting 
> DejaGnu in Python (/me asking as a Python ignoramus)?

  The main thought was more towards an actual design and clean APIs, and
assuming Tcl/Expect was unmaintained, needed to use something that'll be
around for a few more decades. Assuming Tcl/Expect are maintained
forever, that's a bit of a moot point. Everybody has always complained
about using Tcl in DejaGnu. Python is just much more commonly used in
the current century.

  Right now working through patches is probably more important. :-)
There's zero patches on the DejaGnu savannah site, so I'd ask anybody to
submit them so I don't have to dig them out of email archives.

- rob -

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Thu, 14 May 2020, Rob Savoye wrote:

>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

 Thank you for your contribution to DejaGnu over the years and for your 
input on this occasion.

 However it does not appear to me to be right that Tcl is not maintained, 
as a stable 8.6.10 release has been made as recently as half a year ago. 
And then current development appears ongoing, ferociously indeed, with the 
last check in literally today (barring my time zone), as indicated here: 
.

 Other than that what would be the technical advantage from rewriting 
DejaGnu in Python (/me asking as a Python ignoramus)?

  Maciej

gcc-8-20200514 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20200514 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20200514/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision 62ab8b9114b0bdae508ed76fa9028e0040d35e6b

You'll find:

 gcc-8-20200514.tar.xzComplete GCC

  SHA256=93597d10dd9799b299e25a61f1a4858df5a4d29b02e6b367e9bda44b4045d62d
  SHA1=39a51ce7ba167ea30054bca0efa8257cc4154edc

Diffs from 8-20200507 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: dejagnu version update?

[Tom Tromey]

> "Rob" == Rob Savoye  writes:

Rob>   Not that team, the folks I talked to thought I was crazy for wanting
Rob> to refactor it. :-)

I don't think refactoring dejagnu is crazy, but I think it's pretty hard
to imagine rewriting the gdb test suite in Python.  It's 260 KLOC.

Tom

Re: dejagnu version update?

[Rob Savoye]

On 5/14/20 10:08 AM, David Edelsohn wrote:

> Have you approached the Linux Foundation Core Infrastructure
> Initiative for funding for both DejaGNU maintenance (patch backlog)
> and refactoring DejaGNU in Python efforts?

  Not that team, the folks I talked to thought I was crazy for wanting
to refactor it. :-) That's been the usual answer from anyone. I even
talked about this at GNU Tools Cauldron once. Seriously though, it'd be
great to analyze the current code base, write an actual design document,
clean internal APIs, and build something we can use for another 30
years. I'd start by writing a solid expect module for Python, and then
embedding Tcl in Python as a comparability layer. I understand it'd be a
huge project, which is why I haven't done this as a volunteer.

  I think there has been a bit of a leave it alone so it stays stable
attitude... Bugs in the test framework effect our ability to work on the
toolchain efficiently, but other than the handful of people here, nobody
cares. Forgetting the refactoring daydream, testing patches and doing
releases still needs to be done, so I think we need a long-term solution
and fresh energy.

- rob -
---
https://www.senecass.com

Re: ChangeLog files - server and client scripts

[Joseph Myers]

On Thu, 14 May 2020, Martin Liška wrote:

> On 5/13/20 7:53 PM, Joseph Myers wrote:
> > On Wed, 13 May 2020, Martin Liška wrote:
> > 
> > > I'm sending the gcc-changelog relates scripts which should be added to
> > > contrib
> > > folder. The patch contains:
> > > - git_check_commit.py - checking script that verifies git message format
> > 
> > We need a documentation patch to contribute.html or gitwrite.html that
> > describes the exact commit message format being used.
> 
> Sure, I'm sending patch for that.

Thanks.  There are references to author timestamps there.  The date in a 
ChangeLog entry should always be a commit timestamp, not an author one, so 
author timestamps present either in commit messages or in the git commit 
metadata should be ignored, with only the committer timestamps from the 
git commit metadata being used when generating ChangeLog files.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: dejagnu version update?

[David Edelsohn via Gcc]

On Thu, May 14, 2020 at 12:00 PM Rob Savoye  wrote:
>
> On 5/14/20 8:08 AM, Rainer Orth wrote:
>
> >> stops responding for whatever reason.  I have come up with a solution
> >> (that I'd be happy to upstream, except that DejaGNU maintenance seems to
> >> have been dead for like a year now), which I have also confirmed to be
> >> required with current DejaGNU Git master so it must be a different one,
> >> and I would like to know how it might be related to the bug you mention.
>
>   I feel I need to bring up the issue that DejaGnu is 30 years old, and
> it's two maintainers are either trying to pay bills, or trying to
> retire, or both... This problem will effect more projects in the future,
> not just DejaGnu. I'd love to see if anyone would like to become a
> co-maintainer, who preferably will be actively working for a few decades
> still. I think most people on these lists make their income from working
> on the toolchain, but some of us are still volunteers... and getting
> older every day...
>
>   There is a patch backlog neither of us have even looked at, sorry. I'm
> willing to put some time into this, but I think you all realize the time
> involved to adequately test this. I'm not sure I have enough disk space. :-)
>
>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

I greatly appreciate all of the work that you have invested in the
infrastructure and your continued assistance.

Have you approached the Linux Foundation Core Infrastructure
Initiative for funding for both DejaGNU maintenance (patch backlog)
and refactoring DejaGNU in Python efforts?

Thanks, David

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

Hi Rainer,

> >  Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
> > very week I have been chasing a phenomenon with Expect's `wait' semantics 
> > causing a reliable hang in remote testing if `ssh' to the target board 
> > stops responding for whatever reason.  I have come up with a solution 
> > (that I'd be happy to upstream, except that DejaGNU maintenance seems to 
> > have been dead for like a year now), which I have also confirmed to be 
> > required with current DejaGNU Git master so it must be a different one, 
> > and I would like to know how it might be related to the bug you mention.
> 
> I believe it's
> 
> commit b4e61f85ae26d215e8ad5d6e9fcda6c0745096a1
> Author: Richard Biener 
> Date:   Fri Jul 6 21:35:29 2018 +1000
> 
> * lib/remote.exp (close_wait_program): Use separate kill command
> for each pid.
> 
> Richard pointed me at the 1.6.2 release when I mentioned the issue
> somewhere on a gcc list, and it's his patch, so it's likely to be the
> one.

 Thanks; I have seen it and even backported it to my test environment.  
It does not affect my scenario at all however as the kill commands get 
killed just as Expect's `wait' succeeds and then the subsequent TCL 
`close' invocation made on the pipeline in the caller hangs on wait(2) 
indefinitely.  So it's all the same area, but different modes of failure.  
I'll wrap up on my patches then and post them soon.

> It went into DejaGnu immediately after the 1.6.1. release ;-(

 Well, 1.6.2 has been out for a while now so I guess distros might well 
upgrade.  I think it's one of those packages there is not need with to 
wait for code to settle, as it's for core developers' use.  OTOH it's not 
a big deal for the intended users to check out and install the top of 
trunk version anyway.

  Maciej

Re: dejagnu version update?

[Rob Savoye]

On 5/14/20 8:08 AM, Rainer Orth wrote:

>> stops responding for whatever reason.  I have come up with a solution 
>> (that I'd be happy to upstream, except that DejaGNU maintenance seems to 
>> have been dead for like a year now), which I have also confirmed to be 
>> required with current DejaGNU Git master so it must be a different one, 
>> and I would like to know how it might be related to the bug you mention.

  I feel I need to bring up the issue that DejaGnu is 30 years old, and
it's two maintainers are either trying to pay bills, or trying to
retire, or both... This problem will effect more projects in the future,
not just DejaGnu. I'd love to see if anyone would like to become a
co-maintainer, who preferably will be actively working for a few decades
still. I think most people on these lists make their income from working
on the toolchain, but some of us are still volunteers... and getting
older every day...

  There is a patch backlog neither of us have even looked at, sorry. I'm
willing to put some time into this, but I think you all realize the time
involved to adequately test this. I'm not sure I have enough disk space. :-)

  Personally, I tried to find funding to refactor DejaGnu in Python,
since Tcl is unmaintained too, but nobody was interested.

- rob -
---
https://www.senecass.com

Re: dejagnu version update?

[Rainer Orth]

Hi Maciej,

> On Wed, 13 May 2020, Rainer Orth wrote:
>
>> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
>> 
>> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
>> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
>> indefinitely until one manually kills them.
>
>  Would you mind sharing a reference such as a DejaGNU Git commit ID of the 
> fix for the bug you mean?
>
>  Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
> very week I have been chasing a phenomenon with Expect's `wait' semantics 
> causing a reliable hang in remote testing if `ssh' to the target board 
> stops responding for whatever reason.  I have come up with a solution 
> (that I'd be happy to upstream, except that DejaGNU maintenance seems to 
> have been dead for like a year now), which I have also confirmed to be 
> required with current DejaGNU Git master so it must be a different one, 
> and I would like to know how it might be related to the bug you mention.

I believe it's

commit b4e61f85ae26d215e8ad5d6e9fcda6c0745096a1
Author: Richard Biener 
Date:   Fri Jul 6 21:35:29 2018 +1000

* lib/remote.exp (close_wait_program): Use separate kill command
for each pid.

Richard pointed me at the 1.6.2 release when I mentioned the issue
somewhere on a gcc list, and it's his patch, so it's likely to be the
one.

It went into DejaGnu immediately after the 1.6.1. release ;-(

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: ChangeLog files - server and client scripts

[Martin Liška]

On 5/13/20 7:53 PM, Joseph Myers wrote:

On Wed, 13 May 2020, Martin Liška wrote:


I'm sending the gcc-changelog relates scripts which should be added to contrib
folder. The patch contains:
- git_check_commit.py - checking script that verifies git message format


We need a documentation patch to contribute.html or gitwrite.html that
describes the exact commit message format being used.


Sure, I'm sending patch for that.




- git_update_version.py - a replacement of
maintainer-scripts/update_version_git which
bumps DATESTAMP and generates ChangeLog entries (for now into ChangeLog.test
files)


Where does this check things out?  (The existing ~gccadmin/gcc-checkout
isn't suitable for that, it needs to stay on master to have the correct
version of maintainer-scripts rather than being switched to other
branches, though I suppose a second long-lived checkout that gets updated
automatically could be used.  If you check things out somewhere else
temporarily, it's important to be sure the checkout gets deleted
afterwards rather than having multiple checkouts accumulating.  That's
especially the case if you use a checkout in /tmp as a single GCC
repository clone / checkout uses a significant proportion of the free
space on the root filesystem; /sourceware/snapshot-tmp/gcc has more free
space for large temporary directories.)


Well, we can make a proper git clone of the original repository that will
be used for the daily bumps. I bet we'll have a place for one more clone?




The second part is git hook that will reject all commits for release and
master branches.
that violate ChangeLog format. Right now, strict mode is disabled in the
hooks.


Note that the present state of having GCC-specific patches to the git
hooks is supposed to be a temporary one; we want to move to all relevant
GCC-specific configuration being in refs/meta/config rather than custom
code, so GCC and sourceware can share a single instance of the hooks which
in turn can use the same code as in the upstream AdaCore repository, so
that future updates of the hooks from upstream are easier.  See the issues
I filed at https://github.com/AdaCore/git-hooks/issues for the existing
custom GCC changes and the pull request
https://github.com/AdaCore/git-hooks/pull/12 to bring in implementations
of many of those features (not sure if it covers everything or not).  So
it's important to consider how these checks could be implemented without
needing GCC-specific code directly in these hooks (for example, using the
new hooks.update-hook mechanism added by one of the commits in that pull
request, or getting extra features added to the upstream hooks in a
generic form if necessary).



I welcome the attempt to unify the hooks with AdaCore upstream. I believe this
should not block gcc-changelog attempt now. Later on, we can add it to
hooks.update-hook mechanism.

Thanks,
Martin
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f4732ef6..ffa6db32 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -112,9 +112,14 @@ maintained and kept up to date.  In particular:
 
 ChangeLogs
 
-GCC requires ChangeLog entries for documentation changes; for the web
-pages (apart from java/ and libstdc++/) the CVS
-commit logs are sufficient.
+
+ChangeLog entries are part of git commit messages and are automatically put
+into a corresponding ChangeLog file.  A ChangeLog template can be easily generated
+with ./contrib/mklog script.  GCC offers a checking script that
+verifies a proper ChangeLog formatting (see git gcc-verify git alias).
+for a particular git commit.  The checking script covers most commonly used ChangeLog
+formats and the following paragraphs explain what it supports.
+
 
 See also what the http://www.gnu.org/prep/standards_toc.html";>GNU Coding
@@ -124,19 +129,95 @@ in comments rather than the ChangeLog, though a single line overall
 description of the changes may be useful above the ChangeLog entry for
 a large batch of changes.
 
-For changes that are ported from another branch, we recommend to
-use a single entry whose body contains a verbatim copy of the original
-entries describing the changes on that branch, possibly preceded by a
-single-line overall description of the changes.
+Components
+
+
+git_description - a leading text with git commit description
+author_timestamp - line with timestamp and an author name and email (2 spaces before and after name) 
+example: 2020-04-23␣␣Martin Liska␣␣
+additional_author - line with additional commit author name and email (starting with a tabular and 4 spaces) 
+example: \tMartin Liska␣␣
+changelog_location - a location to a ChangeLog file 
+supported formats: a/b/c/ChangeLog, a/b/c/ChangeLog:, a/b/c/ (where ChangeLog file lives in the folder), \ta/b/c/ and a/b/c
+pr_entry - bug report reference 
+example: \tPR component/12345
+changelog_file - a modified file men

Re: ChangeLog files - server and client scripts (git cherry-pick)

[Martin Liška]

Hello.

I'm sending patch candidate that adds 2 new git aliases:
- gcc-backport - simple alias to 'git cherry-pick -x'
- gcc-revert - it similarly appends '(this reverts commit 
365e3cde4978c6a7dbfa50865720226254c016be)'
to a reverted commit message

The script normally parses content of a git message and adds corresponding 
'Revert:' or
'Backport from master:' lines. Right now, there's missing date of the original 
commit and
author. I hope it's acceptable.

Thoughts?
Martin
>From fd916394f66831ebe8f5cadb455d559aa3917fc3 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 14 May 2020 14:34:18 +0200
Subject: [PATCH] gcc-changelog: introduce gcc-revert and gcc-backport.

contrib/ChangeLog:

2020-05-14  Martin Liska  

	* gcc-changelog/git_commit.py: Add support
	for CHERRY_PICK_PREFIX and REVERT_PREFIX.
	* gcc-changelog/test_email.py: Add 2 new tests.
	* gcc-changelog/test_patches.txt: Add 2 patches.
	* gcc-git-customization.sh: Add gcc-backport and
	gcc-revert aliases.
---
 contrib/gcc-changelog/git_commit.py| 46 ++
 contrib/gcc-changelog/test_email.py| 14 
 contrib/gcc-changelog/test_patches.txt | 88 ++
 contrib/gcc-git-customization.sh   |  3 +
 4 files changed, 140 insertions(+), 11 deletions(-)

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 5214cc36538..bf82f6206b6 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -150,6 +150,8 @@ star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
 LINE_LIMIT = 100
 TAB_WIDTH = 8
 CO_AUTHORED_BY_PREFIX = 'co-authored-by: '
+CHERRY_PICK_PREFIX = '(cherry picked from commit '
+REVERT_PREFIX = '(this reverts commit '
 
 
 class Error:
@@ -221,6 +223,8 @@ class GitCommit:
 self.top_level_authors = []
 self.co_authors = []
 self.top_level_prs = []
+self.cherry_pick = False
+self.revert = False
 
 project_files = [f for f in self.modified_files
  if self.is_changelog_filename(f[0])
@@ -372,7 +376,11 @@ class GitCommit:
 last_entry.author_lines.append(author_tuple)
 continue
 
-if not line.startswith('\t'):
+if line.startswith(CHERRY_PICK_PREFIX):
+self.cherry_pick = True
+elif line.startswith(REVERT_PREFIX):
+self.revert = True
+elif not line.startswith('\t'):
 err = Error('line should start with a tab', line)
 self.errors.append(err)
 elif pr_line:
@@ -500,24 +508,40 @@ class GitCommit:
 err = Error(msg % (entry.folder, changelog_location), file)
 self.errors.append(err)
 
+@classmethod
+def format_authors_in_changelog(cls, authors, timestamp, prefix=''):
+output = ''
+for i, author in enumerate(authors):
+if i == 0:
+output += '%s%s  %s\n' % (prefix, timestamp, author)
+else:
+output += '%s\t%s\n' % (prefix, author)
+output += '\n'
+return output
+
 def to_changelog_entries(self):
+current_timestamp = self.date.strftime('%Y-%m-%d')
 for entry in self.changelog_entries:
 output = ''
 timestamp = entry.datetime
 if not timestamp:
 timestamp = self.date.strftime('%Y-%m-%d')
 authors = entry.authors if entry.authors else [self.author]
-# add Co-Authored-By authors to all ChangeLog entries
-for author in self.co_authors:
-if author not in authors:
-authors.append(author)
-
-for i, author in enumerate(authors):
-if i == 0:
-output += '%s  %s\n' % (timestamp, author)
+if self.cherry_pick or self.revert:
+output += self.format_authors_in_changelog(authors,
+   current_timestamp)
+if self.cherry_pick:
+header = 'Backport from master'
 else:
-output += '\t%s\n' % author
-output += '\n'
+header = 'Revert'
+output += '\t%s:\n' % header
+else:
+# add Co-Authored-By authors to all ChangeLog entries
+for author in self.co_authors:
+if author not in authors:
+authors.append(author)
+
+output += self.format_authors_in_changelog(authors, timestamp)
 for pr in entry.prs:
 output += '\t%s\n' % pr
 for line in entry.lines:
diff --git a/contrib/gcc-changelog/test_email.py b/contrib/gcc-changelog/test_email.py
index 03abc763212..e1d955a9c21 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-chan

Re: dejagnu version update?

[Jonathan Wakely via Gcc]

On Thu, 14 May 2020 at 07:45, Christophe Lyon wrote:
>
> On Wed, 13 May 2020 at 19:44, Jonathan Wakely via Gcc  wrote:
> >
> > On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc  wrote:
> > >
> > > I've changed the subject to match the 2015, 2017 and 2018 email threads.
> > >
> > > On May 13, 2020, at 3:26 AM, Thomas Schwinge  
> > > wrote:
> > > >
> > > > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > > > vs. "new") that ought to return identical results, I found that they
> > > > didn't:
> > >
> > > > I have not found any evidence in DejaGnu master branch that this not
> > > > working would've been a "recent" DejaGnu regression (and then fixed for
> > > > DejaGnu 1.6) -- so do we have to assume that this never worked as
> > > > intended back then?
> > >
> > > Likely not.
> > >
> > > > Per our "Prerequisites for GCC" installation documentation, we currently
> > > > require DejaGnu 1.4.4.  Advancing that to 1.6 is probably out of
> > > > question, given that it has "just" been released (four years ago).
> > >
> > > :-)  A user that wants full coverage should use 1.6, apparently.
> >
> > As documented at
> > https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations
> > anything older than 1.5.3 causes problems for libstdc++ (and probably
> > the rest of GCC) because the options in --target_board get placed
> > after the options in dg-options. If the test depends on the options in
> > dg-options to work properly it might fail. For example, a test that
> > has { dg-options "-O2" } and fails without optimisation would FAIL if
> > you use --target_board=unix/-O0 with dejagnu 1.5.
> >
> I think that was commit:
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commitdiff;h=5256bd82343000c76bc0e48139003f90b6184347
> which for sure was a major change (though I don't see it documented in
> dejagnu/NEWS file)


Yes, that's the one.

Re: how to find variable related to a virtual ssa name

[Richard Biener via Gcc]

On Thu, May 14, 2020 at 6:00 AM 易会战  wrote:
>
> There are some other cases that I cannot get right answer.
> case1: interproceduure
> func(int*arg)
> {
> return arg[0] + arg[1]
> }
> func2()
> {
> int a[10]
> return func(a);
> }
> here func cannot tell arg is local var.
>
> case 2:  global array point to local
> int *array[3]
> int func(int x)
> {
> int sub1[10];
> int sub2[10];
> int sub3[10];
> array[0] = sub1;
> array[1]=sub2;
> array[2]=sub3;
> then refer to array by array[x][y]
> }
> here i refer to local var, but the points-to cannnot give right answer.
>
> I do not know if this is the points-to analysis problem, or improper use it.

GCCs analysis is not powerful enough to provide "right" answers you
are seeking for.  GCCs analysis provides conservative correct answers
for the users it has though which is alias analysis.

Richard.

> ---Original---
> From: "Richard Biener"
> Date: Wed, May 13, 2020 19:10 PM
> To: "易会战";
> Cc: "gcc";
> Subject: Re: how to find variable related to a virtual ssa name
>
> On Wed, May 13, 2020 at 11:38 AM 易会战  wrote:
> >
> > now I am working on gcc-9.3, can you give the specific code location to 
> > check not escaped heap? I try to add a flag.
>
> set_uids_in_ptset
>
> > ---Original---
> > From: "Richard Biener"
> > Date: Wed, May 13, 2020 17:28 PM
> > To: "易会战";
> > Cc: "gcc";
> > Subject: Re: how to find variable related to a virtual ssa name
> >
> > On Wed, May 13, 2020 at 11:08 AM 易会战  wrote:
> > >
> > > yes, it does not escape the function, but indeed allocate memory on heap. 
> > > There is much specific method to judge the memory on heap although not 
> > > escape the function?
> >
> > Not at the moment.  The info is computed by tree-ssa-structalias.c in
> > compute_may_aliases,
> > the pass knows that a variable points to not escaped heap storage but this 
> > is
> > not stored anywhere ready for consumption.  Adding a flag to
> > pt_solution would be easy though.
> >
> > Richard.
> >
> > > ---Original---
> > > From: "Richard Biener"
> > > Date: Wed, May 13, 2020 15:00 PM
> > > To: "易会战";
> > > Cc: "gcc";
> > > Subject: Re: how to find variable related to a virtual ssa name
> > >
> > > On Wed, May 13, 2020 at 6:03 AM 易会战  wrote:
> > > >
> > > > It seems the function ptr_deref_may_alias_global_p cannot give right 
> > > > result.
> > > > For example,
> > > > int func(int size, int i)
> > > > {
> > > > int * sum;
> > > > sum = malloc()
> > > > here some code access sum pointing to memory
> > > > return sum[i]
> > > > }
> > > > ptr_deref_may_alias_global_p tell me it is a local memory access. 
> > > > indeed sum is a local variable, but the pointer point to heap memory.
> > > > In fact there is a similiar function ref_may_alias_global_p, and it 
> > > > give similiar result.
> > >
> > > GCC can be clever and notice your malloc() result does not escape the 
> > > function
> > > which means stores to it are dead once you leave it.  For this reason
> > > it does not
> > > mark the memory global.  So make sure the allocated pointer escapes
> > > and try again.
> > >
> > > >
> > > >
> > > > ---Original---
> > > > From: "Richard Biener"
> > > > Date: Tue, May 12, 2020 22:20 PM
> > > > To: "易会战";
> > > > Cc: "gcc";
> > > > Subject: Re: how to find variable related to a virtual ssa name
> > > >
> > > > On Tue, May 12, 2020 at 4:16 PM 易会战  wrote:
> > > > >
> > > > > thanks a lot. I will check your advice.
> > > > > Can you give some explaination about memory ssa, and how to use it. I 
> > > > > check internal, cannot get it. Maybe you know some examples or some 
> > > > > more materials.
> > > >
> > > > memory SSA in GCC is simply a SSA chain of all memory statements local
> > > > to a function
> > > > with a _single_ underlying variable (.MEM) and thus only one SSA name
> > > > live at the same
> > > > time.  It can be used to quickly traverse stores via use->def chains
> > > > and loads inbetween
> > > > two stores via immediate uses.
> > > >
> > > > Richard.
> > > >
> > > > > ---Original---
> > > > > From: "Richard Biener"
> > > > > Date: Tue, May 12, 2020 22:02 PM
> > > > > To: "易会战";
> > > > > Cc: "gcc";
> > > > > Subject: Re: how to find variable related to a virtual ssa name
> > > > >
> > > > > On Tue, May 12, 2020 at 2:44 PM 易会战 via Gcc  wrote:
> > > > > >
> > > > > > hi, I am working on gcc ssa name. For each function, we can 
> > > > > > traverse all defined ssa name by macro FOR_EACH_SSA_NAME. If a ssa 
> > > > > > name is default definition for a symbol (check 
> > > > > > SSA_NAME_IS_DEFAULT_DEF) , I can get the symbol by SSA_NAME_VAR. 
> > > > > > But for a virtual DEFAULT DEF, I cannot get it, SSA_NAME_VAR return 
> > > > > > a identifier named .MEM. I cannot find which variable related to 
> > > > > > the default definition. Why and how I should find the related 
> > > > > > variable?
> > > > > >
> > > > > >
> > > > > > By the way , I give my current work,  I wish find a MEM_REF 
> > > > > > refer to global/heap memory or local stack. I try my best to get