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

2020-05-13 Thread Richard Biener via Gcc
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 a correct memory 
> > > type. Since MEM_REF have a base address, which is often a ssa name. 
> > > Athough it is not virtual ssa name. But I find just check ssa name data 
> > > flow is not enough to get the info.
> > > For example, a malloc function allocate some heap memory and record the 
> > > address in a global ptr. On gimple ssa IR, the malloc function return a 
> > > address assigned to a ssa name , then ssa name assign the value to the 
> > > global ptr. When i check ssa name defined by the global ptr, I donot know 
> > > if the ptr point to global memory or local memory.
> > > Please see the gimple code:
> > > _2 = malloc()
> > > ptr = _2
> > > _3 = ptr
> > > MEM_REF[BASE _3]
> > > I wish get _3  is a address pointing to global memory. But just from 
> > > _3=ptr, cannot judge it. 
> > > I wish memory SSA can help solve the problem.
> >
> > memory SSA will not solve this problem.  You can instead query
> > points-to information
> > on _3 for example by calling ptr_deref_may_alias_global_p (_3) which 
> > internally
> > looks at SSA_NAME_PTR_INFO which contains the solution of the
> > points-to computation.
> >
> > Richard.
> >
> > >
> > > Or gcc gives the info at other pass? wish get some advice. Thanks a lot.


Re: size of exception handling (Was: performance of exception handling)

2020-05-13 Thread David Brown

On 13/05/2020 00:48, Jonathan Wakely via Gcc wrote:

On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote:

On Tue, 12 May 2020, 21:57 Freddie Chopin,  wrote:

Anyway... If you have to recompile the toolchain, the problem is still
there. Most of the people (like 99,666%) will not do that for various
reasons. Some don't know how, some use only Windows, some don't have
time to deal with the compilation (the whole toolchain takes around an
hour here, but this excludes the time to prepare the script that builds
it), some other consider the toolchain provided by MCU vendor (or by
ARM) as "tested to work correctly" so they don't want to replace that
with their custom built solution, and so on, and so on...


There is no one-size-fits-all solution that gives everybody their
ideal set of defaults, so we provide configuration options to tune
things for your needs. Complaining that you have to rebuild things to
get different defaults seems silly. Would you prefer we don't offer
the options at all?


And I also never said that every user should rebuild the toolchain.
The options can be used by vendors providing a toolchain for their
hardware, if the verbose handler (or exceptions in general!) are not
appropriate for their users. Just because something isn't the default,
doesn't mean every user needs to change it themselves.


I think complaining about extra unnecessary code (such as string 
handling for std::terminate) is justified - but the complaints should 
not be directed at the gcc or libstdc++ folks.  As you say, /you/ 
provide the options - if the vendors make poor choices of options, then 
it is /they/ who should get the bug reports and complaints.


One option that would be nice (I don't know if it is realistic), would 
be to say that the code should never stop normally.  On many embedded 
systems, main() never exits.  std::terminate() doesn't need any code 
except perhaps to reset the processor (that will be target-specific, of 
course).  exit() can never be called - there is no need for atexit 
functions, terminate handlers, global destructors, or any of the other 
machinery used for controlled shutdown and ending of a program.





And if writing a script and waiting an hour is too much effort to
reduce unwanted overhead, then I guess that overhead isn't such a big
deal anyway.



There are, as Freddie mentions, many other reasons for end-users not 
building their own toolchains.  I have built many cross-gcc toolcahins 
over the years (starting with a gcc 2.95 m68k toolchain over 20 years 
ago, IIRC).  But for most professional embedded development, pre-built 
toolchains from vendors are a requirement - home-built is simply not an 
acceptable option.  Time and effort don't come into it.  (This is a good 
thing for gcc - a fair number of major gcc developers work for companies 
that earn money selling pre-built toolchains.)


Re: Automatically generated ChangeLog files - PHASE 1

2020-05-13 Thread Richard Sandiford
Martin Liška  writes:
> Hi.
>
> Thanks to Jakub, we finally set up an experimental environment:
> gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
>
> The repository now contains a new pre-commit hook that validates
> the git commit format ([1]) and provides a reasonable error message
> when violated. The hook is based on [2] and the page also contains
> a fuzzy definition of what is supported. Cloning [2], one can also
> check what will be added to ChangeLog entries by:
>
> $ ./git_changelog.py /home/marxin/Programming/gcc-reposurgeon-8 
> 8a37df5e5cb2de8302f9412173103593ec53961e
> -- gcc/ChangeLog --
> 2020-01-13  Martin Jambor  
>
>   PR ipa/93223
>   * ipa-cp.c (devirtualization_time_bonus): Check whether isummary is
>   NULL.
> -- gcc/testsuite/ChangeLog --
> 2020-01-13  Martin Jambor  
>
>   PR ipa/93223
>   testsuite/
>   * g++.dg/ipa/pr93223.C: New test.
>
> (one needs [3] Python package for that)

As far as this particular example goes, shouldn't the "testsuite/" line
be dropped from the above?

Thanks,
Richard


Re: Automatically generated ChangeLog files - PHASE 1

2020-05-13 Thread Martin Liška

On 5/13/20 10:16 AM, Richard Sandiford wrote:

As far as this particular example goes, shouldn't the "testsuite/" line
be dropped from the above?


Good point. Fixes now with:

$ ./git_email.py 
patches/0020-IPA-Avoid-segfault-in-devirtualization_time_bonus-PR.patch
Errors:
first line should start with a tab, asterisk and space:"   testsuite/"

Martin


Re: size of exception handling (Was: performance of exception handling)

2020-05-13 Thread Jonathan Wakely via Gcc
On Tue, 12 May 2020, 10:15 Oleg Endo,  wrote:
>
> On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote:
> >
> > I actually have to build my own toolchain instead of the one provided
> > by ARM, because to really NOT use C++ exceptions, you have to recompile
> > the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they
> > provide the "nano" libraries, but I the options they used for newlib
> > don't suit my needs - this is "too minimized"). If you pass these two
> > flags during compilation and linking of your own application, this
> > disables these features only in your code. As libstdc++ is compiled
> > with exceptions and RTTI enabled, ...
>
> IMHO this is a conceptual fail of the whole concept of using pre-
> compiled pre-installed libraries somewhere in the toolchain, in
> particular for this kind of cross-compilation scenario.


The concept works well in other scenarios though. Not everybody has
the same use case or the same needs.


>   Like you say,
> when we set "exceptions off" it usually means for the whole embedded
> app, and the whole embedded app usually means all the OS and runtime
> libraries and everything, not just the user code.
>
> One option is to not use the pre-compiled toolchain libstc++ but build
> it from source (or use another c++ std lib of your choice), as part of
> the whole project, with the desired project settings.


Yes, IMO that's probably the right option if there is no pre-compiled
toolchain that matches your desired configuration.

If there are properties of libstdc++ that make it more difficult than
necessary, we want to know about them.


>
> BTW, just to throw in my 2-cents into the "I'm using MCU" pool of
> pain/joy ... in one of my projects I'm using STM32F051K6U6, 32 KB
> flash, 8 KB RAM, running all C++ code with shared C++ RPC libraries to
> communicate with other (bigger) devices.  Exceptions, RTTI, threads
> have to be turned off and only the header-only things from the stdlib
> can be used and no heap allocations.


Are you using headers that are not part of the freestanding subset? Which ones?

A future version of the C++ standard is probably going to expand the
headers that should be part of freestanding (or replace the concept of
freestanding with something more useful) so it would be good to know
what parts of the standard library people are actually using on
devices like that.


> Otherwise the thing doesn't fit.
> Don't feel like rewriting the whole thing either.  There are some
> annoyances when turning off exceptions and RTTI which results in
> increased code maintenance.


Such as?


> I'd definitely be good and highly
> appreciated if there were any improvements in the area of exception
> handling.
>
> Cheers,
> Oleg
>


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

2020-05-13 Thread 易会战 via Gcc
Which pass computes the points-to info, maybe There are some details? Do you 
know it?



---Original---
From: "Richard Biener"

Re: Automatically generated ChangeLog files - PHASE 1

2020-05-13 Thread Thomas Koenig via Gcc

Hi Martin,


Thanks to Jakub, we finally set up an experimental environment:
gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git


How does one go about testing this?  It would be helpful if you
could explain this assuming that the Fortran people have at best
an extremely shallow knowledge of git and no knowledge of Python :-)

Regards

Thomas



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

2020-05-13 Thread Richard Biener via Gcc
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 a correct 
> > > > memory type. Since MEM_REF have a base address, which is often a ssa 
> > > > name. Athough it is not virtual ssa name. But I find just check ssa 
> > > > name data flow is not enough to get the info.
> > > > For example, a malloc function allocate some heap memory and record the 
> > > > address in a global ptr. On gimple ssa IR, the malloc function return a 
> > > > address assigned to a ssa name , then ssa name assign the value to the 
> > > > global ptr. When i check ssa name defined by the global ptr, I donot 
> > > > know if the ptr point to global memory or local memory.
> > > > Please see the gimple code:
> > > > _2 = malloc()
> > > > ptr = _2
> > > > _3 = ptr
> > > > MEM_REF[BASE _3]
> > > > I wish get _3  is a address pointing to global memory. But just 
> > > > from _3=ptr, cannot judge it. 
> > > > I wish memory SSA can help solve the problem.
> > >
> > > memory SSA will not solve this problem.  You can instead query
> > > points-to information
> > > on _3 for example by calling ptr_deref_may_alias_global_p (_3) which 
> > > internally
> > > looks at SSA_NAME_PTR_INFO which contains the solution of the
> > > points-to computation.
> > >
> > > Richard.
> > >
> > > >
> > > > Or gcc gives the info at other pass? wish get some advice. Thanks a lot.


Re: Automatically generated ChangeLog files - PHASE 1

2020-05-13 Thread Richard Biener via Gcc
On Wed, May 13, 2020 at 11:27 AM Martin Liška  wrote:
>
> On 5/13/20 10:16 AM, Richard Sandiford wrote:
> > As far as this particular example goes, shouldn't the "testsuite/" line
> > be dropped from the above?
>
> Good point. Fixes now with:
>
> $ ./git_email.py 
> patches/0020-IPA-Avoid-segfault-in-devirtualization_time_bonus-PR.patch
> Errors:
> first line should start with a tab, asterisk and space:"testsuite/"

Hmm, it's OK in the commit but it should be omitted in the
ChangeLog files.

Richard.

> Martin


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

2020-05-13 Thread 易会战 via Gcc
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.



---Original---
From: "Richard Biener"

Re: Automatically generated ChangeLog files - PHASE 1

2020-05-13 Thread Jozef Lawrynowicz
Hi,

On Tue, 12 May 2020 11:05:58 +0200
Martin Liška  wrote:

> Hi.
> 
> Thanks to Jakub, we finally set up an experimental environment:
> gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
> 
> The repository now contains a new pre-commit hook that validates
> the git commit format ([1]) and provides a reasonable error message
> when violated. The hook is based on [2] and the page also contains
> a fuzzy definition of what is supported. Cloning [2], one can also
> check what will be added to ChangeLog entries by:
> 
> $ ./git_changelog.py /home/marxin/Programming/gcc-reposurgeon-8 
> 8a37df5e5cb2de8302f9412173103593ec53961e

"git_changelog.py" is nowhere to be found in the gcc-changelog or
gcc-reposurgeon-8 repos. Is it equivalent to any of the other scripts in
gcc-changelog?

Jozef


Re: Automatically generated ChangeLog files - PHASE 1

2020-05-13 Thread Martin Liška

On 5/13/20 11:29 AM, Richard Biener wrote:

Hmm, it's OK in the commit but it should be omitted in the
ChangeLog files.


No, ChangeLog file identification should not be prepended
with a tab.
"testsuite/" will work.

Martin


Re: Automatically generated ChangeLog files - PHASE 1

2020-05-13 Thread Martin Liška

On 5/13/20 11:50 AM, Jozef Lawrynowicz wrote:

"git_changelog.py" is nowhere to be found in the gcc-changelog or
gcc-reposurgeon-8 repos. Is it equivalent to any of the other scripts in
gcc-changelog?


Yes, I made some refactoring and I'm going to send a proper gcc-patches 
submission.
The scripts will be located in contrib folder.

Martin


Re: Automatically generated ChangeLog files - PHASE 1

2020-05-13 Thread Richard Earnshaw
On 12/05/2020 10:05, Martin Liška wrote:
> Hi.
> 
> Thanks to Jakub, we finally set up an experimental environment:
> gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
> 
> The repository now contains a new pre-commit hook that validates
> the git commit format ([1]) and provides a reasonable error message
> when violated. The hook is based on [2] and the page also contains
> a fuzzy definition of what is supported. Cloning [2], one can also
> check what will be added to ChangeLog entries by:
> 
> $ ./git_changelog.py /home/marxin/Programming/gcc-reposurgeon-8
> 8a37df5e5cb2de8302f9412173103593ec53961e
> -- gcc/ChangeLog --

I realize you're trying to create a unique marker, but this is a bit of
a mouthful to type for each entry.  Couldn't we have a simpler unique
syntax which is very unlikely to occur in a normal part of a log file?
Perhaps something like

@@CL gcc

would be equivalent to the above and is much less than half the length
to type.

Also, a marker to indicate the end, so that if git annotations appear,
they can never get appended accidentally, eg, an empty "@@CL" marker
with no directory.


> 2020-01-13  Martin Jambor  
> 
> PR ipa/93223
> * ipa-cp.c (devirtualization_time_bonus): Check whether isummary is
> NULL.
> -- gcc/testsuite/ChangeLog --
> 2020-01-13  Martin Jambor  
> 
> PR ipa/93223
> testsuite/
> * g++.dg/ipa/pr93223.C: New test.
> 
> (one needs [3] Python package for that)
> 
> We encourage people to test both the hook and the script. We hope we'll
> cover
> majority of the used formats. I also support _not_ using DATESTAMP and
> committer
> name, these can be automatically deduced from a commit. That will
> simplify workflow
> as people won't have to adjust a message before pushing.
> 
> Unresolved questions:
> - format of reverted patches
> - what to do with backports
> 
> Here I suggest to use native 'git revert XYZ' and 'git cherry-pick -x XYZ'.
> Doing that the commit messages will provide link to original commit and
> the script
> can later append corresponding 'Backported ..' or 'Reverted' line.
> 
> For the possible issues or questions, please open a Github issue at [4].
> 
> Thoughts?
> Martin
> 
> [1] https://github.com/marxin/git-hooks/tree/gcc-changelog
> [2] https://github.com/marxin/gcc-changelog
> [3] https://gitpython.readthedocs.io/en/stable/intro.html
> [4] https://github.com/marxin/gcc-changelog/issues
> 
>  



DejaGnu/GCC testsuite behavior regarding multiple 'dg-do'

2020-05-13 Thread Thomas Schwinge
Hi!

Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
vs. "new") that ought to return identical results, I found that they
didn't:

@@ -75032,6 +75023,7 @@ PASS: g++.dg/expr/bitfield4.C  -std=c++98 (test for 
excess errors)
 PASS: g++.dg/expr/bitfield5.C  -std=c++14  (test for warnings, line 12)
 PASS: g++.dg/expr/bitfield5.C  -std=c++14  (test for warnings, line 16)
 PASS: g++.dg/expr/bitfield5.C  -std=c++14 (test for excess errors)
+PASS: g++.dg/expr/bitfield5.C  -std=c++14 execution test
 PASS: g++.dg/expr/bitfield5.C  -std=c++17  (test for errors, line 12)
 PASS: g++.dg/expr/bitfield5.C  -std=c++17  (test for errors, line 16)
 PASS: g++.dg/expr/bitfield5.C  -std=c++17 (test for excess errors)
@@ -75041,6 +75033,7 @@ PASS: g++.dg/expr/bitfield5.C  -std=c++2a (test for 
excess errors)
 PASS: g++.dg/expr/bitfield5.C  -std=c++98  (test for warnings, line 12)
 PASS: g++.dg/expr/bitfield5.C  -std=c++98  (test for warnings, line 16)
 PASS: g++.dg/expr/bitfield5.C  -std=c++98 (test for excess errors)
+PASS: g++.dg/expr/bitfield5.C  -std=c++98 execution test
 PASS: g++.dg/expr/bitfield6.C  -std=c++14  (test for warnings, line 10)
 PASS: g++.dg/expr/bitfield6.C  -std=c++14 (test for excess errors)
 PASS: g++.dg/expr/bitfield6.C  -std=c++17  (test for errors, line 10)

..., and several more like that.

'g++.dg/expr/bitfield5.C':

// PR c++/30274
// { dg-do run { target c++14_down } }
// { dg-do compile { target c++17 } }
[...]
  s.x++; // { dg-warning "5:use of an operand of type .bool. in 
.operator\\+\\+. is deprecated" "" { target { ! c++17 } } }
  // { dg-error "forbidden" "" { target c++17 } .-1 }
[...]

So, this is meant to be an execution test for C++14 and older, and a
compile test for C++17 and newer.  This pattern seems to be recognized on
the "new" system, but not on the "old" system, where execution tests
aren't being run, only compile tests.

The "old" system, powerpc64le-unknown-linux-gnu Ubuntu 14.04, has DejaGnu
1.5-3ubuntu1.  Also reproduced on a x86_64-pc-linux-gnu Ubuntu 12.10
system with DejaGnu 1.5-3.

The "new" system, powerpc64le-unknown-linux-gnu Ubuntu 18.04, has DejaGnu
1.6.1-1.  Also reproduced on a x86_64-pc-linux-gnu Ubuntu 18.04 system
with DejaGnu 1.6.1-1.  And: also reproduced on the "old" system, when
instead of system-provided DejaGnu 1.5-3ubuntu1 manually running with
Ubuntu 18.04 DejaGnu 1.6.1-1.

Relevant (but haven't verified) seems to be the following DejaGnu commit:

commit 569f8718b534a2cd9511a7d640352eb0126ff492
Author: Dominik Vogt 
Date:   Mon Mar 28 17:31:07 2016 +1100

* dg.exp (dg-do): Do not change the previously selected action if
a de-selected dg-do is encountered.

Discussed in
,
and this indeed got included for DejaGnu 1.6.

Looking through the GCC testuite for test case files with more than one
'dg-do', the confusing thing is that this pattern has already been used
for a very long time.  See, for example, commit
5bdf05c8743e7486521ce3a3981ac3e6e7850ad0 (r143350, 2009-01-13):

-/* { dg-do run { target powerpc*-*-* } } */
+/* { dg-do run { target { powerpc*-*-* && vmx_hw } } } */
+/* { dg-do compile { target { powerpc*-*-* && { ! vmx_hw } } } } */

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?

I have not found an easy way to express different 'do-what-keyword'
within one test case file that work with old and new DejaGnu.

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

As the failure mode with old DejaGnu is "benign" (only causes missing
execution testing), we could simply move on, and accept non-reproducible
results between different DejaGnu versions?  Kind of lame...  ;-|


Grüße
 Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter


Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

2020-05-13 Thread Segher Boessenkool
On Wed, May 13, 2020 at 01:42:37AM +0100, Maciej W. Rozycki wrote:
> On Sat, 9 May 2020, Eric Botcazou wrote:
> 
> > > Strangely, I failed to find any PR for e200, so maybe some unnoticed ones
> > > are still lying around.
> > 
> > I think that the e200 support was never contributed upstream.
> 
>  Or rather, it wasn't accepted.  Cf. 
> , 
> .

There never has been a patch adding support for e200 submitted.  Only
patches mixing that with a lot of other stuff, like VLE support, which
was not acceptable in that shape at all.

It takes time and effort to not make something like this take (ongoing!)
huge time and effort from others.


Segher


ChangeLog files - server and client scripts

2020-05-13 Thread Martin Liška

Hi.

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
- 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)
- git_commit.py, git_email.py and git_repository.py - helper classes

I also added a new git.config alias: 'gcc-verify' which can be used in the 
following
way:

$ git gcc-verify HEAD~2..HEAD -p -n
Checking 0e4009e9d523270e26856d2441c1be3d8119a477
OK
@@CL contrib
2020-05-13  Martin Liska  

* gcc-changelog/git_check_commit.py: New file.
* gcc-changelog/git_commit.py: New file.
* gcc-changelog/git_email.py: New file.
* gcc-changelog/git_repository.py: New file.
* gcc-changelog/git_update_version.py: New file.
* gcc-git-customization.sh: Add gcc-verify alias.
@@CL
Checking 18edc195442291525e04f0fa4d5ef972155117da
OK
@@CL gcc
2020-05-13  Jakub Jelinek  

PR debug/95080
* cfgrtl.c (purge_dead_edges): Skip over debug and note insns even
if the last insn is a note.
@@CL gcc/testsuite
2020-05-13  Jakub Jelinek  

PR debug/95080
* g++.dg/opt/pr95080.C: New test.
@@CL

Note the -n option which disables _strict mode_ (modification of both ChangeLog
and another files).

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.

What's still missing to be done is format of Revert and Backport commits.
I suggest to use native 'git revert XYZ' and 'git cherry-pick -x XYZ'.
Doing that the commit messages will provide link to original commit and the 
script
can later append corresponding 'Backported ..' or 'Reverted' line.

Thoughts?
Martin
>From 0e4009e9d523270e26856d2441c1be3d8119a477 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 13 May 2020 12:22:39 +0200
Subject: [PATCH] Add gcc-changelog related scripts.

contrib/ChangeLog:

2020-05-13  Martin Liska  

	* gcc-changelog/git_check_commit.py: New file.
	* gcc-changelog/git_commit.py: New file.
	* gcc-changelog/git_email.py: New file.
	* gcc-changelog/git_repository.py: New file.
	* gcc-changelog/git_update_version.py: New file.
	* gcc-git-customization.sh: Add gcc-verify alias.
---
 contrib/gcc-changelog/git_check_commit.py   |  49 ++
 contrib/gcc-changelog/git_commit.py | 536 
 contrib/gcc-changelog/git_email.py  |  92 
 contrib/gcc-changelog/git_repository.py |  60 +++
 contrib/gcc-changelog/git_update_version.py | 105 
 contrib/gcc-git-customization.sh|   2 +
 6 files changed, 844 insertions(+)
 create mode 100755 contrib/gcc-changelog/git_check_commit.py
 create mode 100755 contrib/gcc-changelog/git_commit.py
 create mode 100755 contrib/gcc-changelog/git_email.py
 create mode 100755 contrib/gcc-changelog/git_repository.py
 create mode 100755 contrib/gcc-changelog/git_update_version.py

diff --git a/contrib/gcc-changelog/git_check_commit.py b/contrib/gcc-changelog/git_check_commit.py
new file mode 100755
index 000..b2d1d08a242
--- /dev/null
+++ b/contrib/gcc-changelog/git_check_commit.py
@@ -0,0 +1,49 @@
+#!/usr/bin/env python3
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 3, or (at your option) any later
+# version.
+#
+# GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+# WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+# for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .  */
+
+import argparse
+
+from git_repository import parse_git_revisions
+
+parser = argparse.ArgumentParser(description='Check git ChangeLog format '
+ 'of a commit')
+parser.add_argument('revisions',
+help='Git revisions (e.g. hash~5..hash or just hash)')
+parser.add_argument('-g', '--git-path', default='.',
+help='Path to git repository')
+parser.add_argument('-p', '--print-changelog', action='store_true',
+help='Print final changelog entires')
+parser.add_argument('-n', '--allow-non-strict-mode', action='store_true',
+help='Allow non-strict mode (change in both ChangeLog and '
+'other files.')
+args = parser.parse_args()
+
+retval = 0
+for git_commit in parse_git_revisions(args.git_path, args.revisions,
+  not args.allow_non_strict_mode):
+print('Checking %s' % git_commit.hexsha)
+if git_co

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

2020-05-13 Thread Richard Biener via Gcc
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 a 
> > > > > correct memory type. Since MEM_REF have a base address, which is 
> > > > > often a ssa name. Athough it is not virtual ssa name. But I find just 
> > > > > check ssa name data flow is not enough to get the info.
> > > > > For example, a malloc function allocate some heap memory and record 
> > > > > the address in a global ptr. On gimple ssa IR, the malloc function 
> > > > > return a address assigned to a ssa name , then ssa name assign the 
> > > > > value to the global ptr. When i check ssa name defined by the global 
> > > > > ptr, I donot know if the ptr point to global memory or local memory.
> > > > > Please see the gimple code:
> > > > > _2 = malloc()
> > > > > ptr = _2
> > > > > _3 = ptr
> > > > > MEM_REF[BASE _3]
> > > > > I wish get _3  is a address pointing to global memory. But just 
> > > > > from _3=ptr, cannot judge it. 
> > > > > I wish memory SSA can help solve the problem.
> > > >
> > > > memory SSA will not solve this problem.  You can instead query
> > > > points-to information
> > > > on _3 for example by calling ptr_deref_may_alias_global_p (_3) which 
> > > > internally
> > > > looks at SSA_NAME_PTR_INFO which contains the solution of the
> > > > points-to computation.
> > > >
> > > > Rich

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

2020-05-13 Thread Martin Liška

On 5/13/20 1:05 PM, Martin Liška wrote:

I suggest to use native 'git revert XYZ' and 'git cherry-pick -x XYZ'.


I've prepared a working version of Revert format:
https://github.com/marxin/gcc-changelog/tree/cherry-pick

So using git cherry-pick -x HASH one gets something like:

$ cat patches-artificial/0001-Test-tree.h.patch
From a71eeba28ffa2427d24d5b2654e93b261980b9e3 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 13 May 2020 13:19:22 +0200
Subject: [PATCH] Test tree.h.

gcc/ChangeLog:

2020-01-03  Martin Liska  

PR ipa/12345
* tree.h: Just test it.

(cherry picked from commit a2bdf56b15b51c3a7bd988943bdbc42aa156f133)
---
 gcc/tree.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/tree.h b/gcc/tree.h
index 9ca9ab58ec0..99a9e1a73d9 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -1,6 +1,8 @@
 /* Definitions for the ubiquitous 'tree' type for GNU compilers.
Copyright (C) 1989-2020 Free Software Foundation, Inc.
 
+

+
 This file is part of GCC.
 
 GCC is free software; you can redistribute it and/or modify it under

--
2.26.2

and the script generates:

$ ./git_email.py patches-artificial/0001-Test-tree.h.patch
OK
@@CL gcc
2020-05-13  Martin Liska  

Backport from master:
2020-01-03  Martin Liska  

PR ipa/12345
* tree.h: Just test it.
@@CL

So the datestamp and the author is taken from commit and original authors
are added after 'Backport from master' line. The script scans for the
'(cherry picked from commit' line in the message.

Benefit of the approach is that one can adjust the commit message (which 
influences
ChangeLog output).

Martin


Re: ChangeLog files - server and client scripts

2020-05-13 Thread Martin Liška

The scripts were just installed to master except the git alias.
I'm sending that in a separate patch. Now the alias can be used
from any subfolder in a gcc git repository.

Martin
>From eb47191e8d8cbbda285c4df7eb2d1e98091edab9 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 13 May 2020 14:32:50 +0200
Subject: [PATCH] Add gcc-verify alias.

contrib/ChangeLog:

2020-05-13  Martin Liska  

	* gcc-git-customization.sh: Add gcc-verify alias
	that uses contrib/gcc-changelog/git_check_commit.py.
---
 contrib/gcc-git-customization.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index a932bf8c06a..ce293d1fe42 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -25,6 +25,8 @@ git config alias.svn-rev '!f() { rev=$1; shift; git log --all --grep="^From-SVN:
 git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then c=\${2:-master}; r=\$(git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' \$c | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p'); expr match \${r:-no} '^r[0-9]\\+\$' >/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master}); else c=\${1:-master}; r=\$(git describe --all --match 'basepoints/gcc-[0-9]*' \$c | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)\$,r\\2-0,p'); fi; if test -n \$r; then o=\$(git config --get gcc-config.upstream); rr=\$(echo \$r | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\\(-g[0-9a-f]\\+\\)\\?\$,\\1,p'); if git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$rr >/dev/null; then m=releases/gcc-\$rr; else m=master; fi; git merge-base --is-ancestor \$c \${o:-origin}/\$m && \echo \${r}; fi; }; f"
 git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream); r=\$(echo \$1 | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && exit 1; h=\$(git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse --verify --quiet \${o:-origin}/master); p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p'); git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
 
+git config alias.gcc-verify '!f() { "`git rev-parse --show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
+
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md
-- 
2.26.2



Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

2020-05-13 Thread Maciej W. Rozycki
On Wed, 13 May 2020, Segher Boessenkool wrote:

> > > I think that the e200 support was never contributed upstream.
> > 
> >  Or rather, it wasn't accepted.  Cf. 
> > , 
> > .
> 
> There never has been a patch adding support for e200 submitted.  Only
> patches mixing that with a lot of other stuff, like VLE support, which
> was not acceptable in that shape at all.

 Well, e200 parts are VLE ISA implementations, some of which solely 
(e200z0), so to claim specific e200 support we'd have to have VLE support 
first anyway, even if submitted separately.

> It takes time and effort to not make something like this take (ongoing!)
> huge time and effort from others.

 Sure, I just think we need to get the facts straight.  And I gave 
pointers in case someone came across this discussion sometime and wanted 
to use that stuff locally.

  Maciej


Re: ChangeLog files - server and client scripts

2020-05-13 Thread Richard Earnshaw
On 13/05/2020 12:05, Martin Liška wrote:
> Hi.
> 
> 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
> - 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)
> - git_commit.py, git_email.py and git_repository.py - helper classes
> 
> I also added a new git.config alias: 'gcc-verify' which can be used in
> the following
> way:
> 
> $ git gcc-verify HEAD~2..HEAD -p -n
> Checking 0e4009e9d523270e26856d2441c1be3d8119a477
> OK
> @@CL contrib
> 2020-05-13  Martin Liska  
> 
> * gcc-changelog/git_check_commit.py: New file.
> * gcc-changelog/git_commit.py: New file.
> * gcc-changelog/git_email.py: New file.
> * gcc-changelog/git_repository.py: New file.
> * gcc-changelog/git_update_version.py: New file.
> * gcc-git-customization.sh: Add gcc-verify alias.
> @@CL
> Checking 18edc195442291525e04f0fa4d5ef972155117da
> OK
> @@CL gcc
> 2020-05-13  Jakub Jelinek  
> 
> PR debug/95080
> * cfgrtl.c (purge_dead_edges): Skip over debug and note insns even
> if the last insn is a note.
> @@CL gcc/testsuite
> 2020-05-13  Jakub Jelinek  
> 
> PR debug/95080
> * g++.dg/opt/pr95080.C: New test.
> @@CL
> 
> Note the -n option which disables _strict mode_ (modification of both
> ChangeLog
> and another files).
> 
> 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.
> 
> What's still missing to be done is format of Revert and Backport commits.
> I suggest to use native 'git revert XYZ' and 'git cherry-pick -x XYZ'.
> Doing that the commit messages will provide link to original commit and
> the script
> can later append corresponding 'Backported ..' or 'Reverted' line.
> 
> Thoughts?
> Martin

I've just realized this doesn't give us an easy way to mark changes for
the root-level ChangeLog file, unless, perhaps "@@ CL ." works?

R.


Re: ChangeLog files - server and client scripts

2020-05-13 Thread Martin Liška

On 5/13/20 3:24 PM, Richard Earnshaw wrote:

I've just realized this doesn't give us an easy way to mark changes for
the root-level ChangeLog file, unless, perhaps "@@ CL ." works?


This works fine:
'ChangeLog:'

as seen for instance here:

commit 9ad3c1d81c129fc76594b9df5b798c380cbf03ee
Author: Stefan Schulze Frielinghaus 
Date:   Wed Apr 22 09:20:08 2020 +0200

MAINTAINERS: add myself for write after approval

ChangeLog:

2020-04-22  Stefan Schulze Frielinghaus  

* MAINTAINERS (Write After Approval): add myself


Martin


C-Vise: speed?

2020-05-13 Thread Martin Liška

Hello.

I've made some measurements for GCC PRs that I've reduced recently:

- PR92516 - C++ - 6.5MB
  C-Reduce: 77 minutes
  C-Vise: 35 minutes

- PR94523 - C++ - 2.1MB
  C-Reduce: 33 minutes
  C-Vise: 15 minutes

- PR94632 - C++ - 3.3MB
  C-Reduce: 28 minutes
  C-Vise: 20 minutes

- PR94937 - C++ - 8.5MB
  C-Reduce: 303 minutes
  C-Vise: 242 minutes

Note that I also added cvise-delta, which simulates popular delta tool,
but runs in a parallel mode.

Martin


dejagnu version update?

2020-05-13 Thread Mike Stump via Gcc
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 the failure mode with old DejaGnu is "benign" (only causes missing
> execution testing), we could simply move on, and accept non-reproducible
> results between different DejaGnu versions?  Kind of lame...  ;-|

An ugly wart to be sure.

So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 6, 
and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone want 
to not update dejagnu to require 1.6?

I had previously approved the update to 1.5.3, but no one really wanted it as 
no one updated the requirement.  Let's have the 1.6 discussion.  I'm not only 
inclined to up to 1.6, but to actually edit it in this time.

Anyone strongly against?  Why?

back to cvs, cool

2020-05-13 Thread Mike Stump via Gcc
As seen in recent bug report:

  CVS Commits 2020-05-12 20:40:40 UTC

I guess that git thing was a bust and we're back to using cvs now.  At least 
Ian did up the remote patches to make cvs work better.

Re: back to cvs, cool

2020-05-13 Thread Ian Lance Taylor via Gcc
On Wed, May 13, 2020 at 9:56 AM Mike Stump via Gcc  wrote:
>
> As seen in recent bug report:
>
>   CVS Commits 2020-05-12 20:40:40 UTC
>
> I guess that git thing was a bust and we're back to using cvs now.  At least 
> Ian did up the remote patches to make cvs work better.

In fairness, I worked on it but it was really Jim Kingdon who did the
bulk of the remote CVS support.

Ian


Re: dejagnu version update?

2020-05-13 Thread Jonathan Wakely via Gcc
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.


> > As the failure mode with old DejaGnu is "benign" (only causes missing
> > execution testing), we could simply move on, and accept non-reproducible
> > results between different DejaGnu versions?  Kind of lame...  ;-|
>
> An ugly wart to be sure.
>
> So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 6, 
> and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone want 
> to not update dejagnu to require 1.6?

There are still lots of older systems in use for GCC dev, like all the
POWER servers in the compile farm (but I've put a recent dejagnu in
/opt/cfarm on some of them).

> I had previously approved the update to 1.5.3, but no one really wanted it as 
> no one updated the requirement.  Let's have the 1.6 discussion.  I'm not only 
> inclined to up to 1.6, but to actually edit it in this time.

Would the tests actually refuse to run with an older version?

> Anyone strongly against?  Why?

I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.


Re: ChangeLog files - server and client scripts

2020-05-13 Thread Joseph Myers
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.

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

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

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


Re: dejagnu version update?

2020-05-13 Thread Rob Savoye
On 5/13/20 10:51 AM, Mike Stump wrote:

> So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both
> contain 6, and SLES has 6 and since we've been sitting at 1.4.4 for
> so long, anyone want to not update dejagnu to require 1.6?

  We do still find and fix bugs occasionally. :-) And 1.4.4 was released
16 years ago... Linaro has been using the most recent release for years,
so I think it's a safe upgrade.

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


Re: dejagnu version update?

2020-05-13 Thread Rainer Orth
Jonathan Wakely via Gcc  writes:

>> I had previously approved the update to 1.5.3, but no one really wanted
>> it as no one updated the requirement.  Let's have the 1.6 discussion.
>> I'm not only inclined to up to 1.6, but to actually edit it in this time.
>
> Would the tests actually refuse to run with an older version?
>
>> Anyone strongly against?  Why?
>
> 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.

Rainer

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


Re: dejagnu version update?

2020-05-13 Thread Maciej W. Rozycki via Gcc
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.

  Maciej


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

2020-05-13 Thread 易会战 via Gcc
Thanks, I patch a version, it can give a heap variable info.
Now the curious is the patch version cannot give right answer for variable 
length array. for example,
int func(int m, int n)
{
int array[m][n];
...
}
here array is allocated by alloca, obviously a local variable.
But the original version can check it a local variable.

---Original---
From: "Richard Biener"

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

2020-05-13 Thread 易会战 via Gcc
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.

---Original---
From: "Richard Biener"

Re: dejagnu version update?

2020-05-13 Thread Christophe Lyon via Gcc
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)

>
> > > As the failure mode with old DejaGnu is "benign" (only causes missing
> > > execution testing), we could simply move on, and accept non-reproducible
> > > results between different DejaGnu versions?  Kind of lame...  ;-|
> >
> > An ugly wart to be sure.
> >
> > So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 
> > 6, and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone 
> > want to not update dejagnu to require 1.6?
>
> There are still lots of older systems in use for GCC dev, like all the
> POWER servers in the compile farm (but I've put a recent dejagnu in
> /opt/cfarm on some of them).
>
> > I had previously approved the update to 1.5.3, but no one really wanted it 
> > as no one updated the requirement.  Let's have the 1.6 discussion.  I'm not 
> > only inclined to up to 1.6, but to actually edit it in this time.
>
> Would the tests actually refuse to run with an older version?
>
> > Anyone strongly against?  Why?
>
> I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.