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

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

[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

[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

[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

[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: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

[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

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

[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

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

[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

[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

dejagnu version update?

[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?

Re: dejagnu version update?

[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: back to cvs, cool

[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?

[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

back to cvs, cool

[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: ChangeLog files - server and client scripts

[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?

[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?

[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

[易会战 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

[易会战 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: how to find variable related to a virtual ssa name

[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

[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

[易会战 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"

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

[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

ChangeLog files - server and client scripts

[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 

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

[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

[易会战 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

[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: how to find variable related to a virtual ssa name

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

Re: Automatically generated ChangeLog files - PHASE 1

[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: Automatically generated ChangeLog files - PHASE 1

[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

[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
> 
>  

C-Vise: speed?

[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

Re: ChangeLog files - server and client scripts

[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

[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

Re: [PR 95013] EOF location is at end of file

[Christophe Lyon via Gcc-patches]

On Wed, 13 May 2020 at 02:24, H.J. Lu via Gcc-patches
 wrote:
>
> On Tue, May 12, 2020 at 2:24 PM Nathan Sidwell  wrote:
> >
> > My recent C++ parser change to pay attention to EOF location uncovered a
> > separate bug.  The preprocesor's EOF logic would set the EOF location to
> > be the beginning of the last line of text in the file -- not the 'line'
> > after that, which contains no characters.  Mostly.  This fixes things so
> > that when we attempt to read the last line of the main file, we don't
> > pop the buffer until the tokenizer has a chance to create an EOF token
> > with the correct location information.  It is then responsible for
> > popping the buffer.  As it happens, raw string literal tokenizing
> > contained a bug -- it would increment the line number prematurely,
> > because it cached buffer->cur in a local variable, but checked
> > buffer->cur before updating it to figure out if it was at end of file.
> > We fix up that too.
> >
> > The EOF token intentionally doesn't have a column number -- it's not a
> > position on a line, it's a non-existant line.
> >
> > The testsuite churn is just correcting the EOF location diagnostics.
> > This time I've made sure to check all testsuites, sorry obj-c++ folks.
> >
> > pushed to master.
> >
> > nathan
> >
> > --
> > Nathan Sidwell
>
> I got
>
> ERROR: gcc.dg/unclosed-init.c: syntax error in target selector ".+1"
> for " dg-error 3 "-: expected '.' at end of input" { target *-*-* }
> .+1 "
> ERROR: gcc.dg/unclosed-init.c: syntax error in target selector ".+1"
> for " dg-error 3 "-: expected '.' at end of input" { target *-*-* }
> .+1 "
> ERROR: gcc.dg/unclosed-init.c: syntax error in target selector ".+1"
> for " dg-error 3 "-: expected '.' at end of input" { target *-*-* }
> .+1 "
> ERROR: gcc.dg/unclosed-init.c: syntax error in target selector ".+1"
> for " dg-error 3 "-: expected '.' at end of input" { target *-*-* }
> .+1 "
> ERROR: gcc.dg/unclosed-init.c: syntax error in target selector ".+1"
> for " dg-error 3 "-: expected '.' at end of input" { target *-*-* }
> .+1 "
> ERROR: gcc.dg/unclosed-init.c: syntax error in target selector ".+1"
> for " dg-error 3 "-: expected '.' at end of input" { target *-*-* }
> .+1 "
>
> on Linux/x86:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2020-May/072573.html
>

The updated testcase was missing a comment. I pushed this obvious fix:

commit a7b7818f3dbd14cc7577d25dcebaded07395c476
Author: Christophe Lyon 
Date:   Wed May 13 06:41:19 2020 +

[PR 95013] Fix gcc.dg/unclosed-init.c

2020-05-13  Christophe Lyon  

PR preprocessor/95013
* gcc.dg/unclosed-init.c: Add missing comment in dg-error.

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5a4215b..03b61dd 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-05-13  Christophe Lyon  
+
+   PR preprocessor/95013
+   * gcc.dg/unclosed-init.c: Add missing comment in dg-error.
+
 2020-05-13  Bin Cheng  

PR tree-optimization/94969
diff --git a/gcc/testsuite/gcc.dg/unclosed-init.c
b/gcc/testsuite/gcc.dg/unclosed-init.c
index 16c42c4..0a0ca21 100644
--- a/gcc/testsuite/gcc.dg/unclosed-init.c
+++ b/gcc/testsuite/gcc.dg/unclosed-init.c
@@ -1,3 +1,3 @@
 int unclosed[] = { /* { dg-message "18: to match this '.'" } */
   42
- /* { dg-error "-: expected '.' at end of input" { target *-*-* } .+1 } */
+ /* { dg-error "-: expected '.' at end of input" "" { target *-*-* } .+1 } */


Thanks,

Christophe

>
> --
> H.J.

[Bug debug/95098] Out of scope variable visible during debugging at Og

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95098

Richard Biener  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||edlinger at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Don't see this with gdb:

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 4 at 0x4004bd: file z.c, line 11.
Starting program: /home/rguenther/obj/gcc/a.out 

Temporary breakpoint 4, main () at z.c:11
11  int main() { b(); }
(gdb) s

Breakpoint 3, b () at z.c:4
4   for (g_2 = 21; (g_2 < (-27)); g_2 = 0)
(gdb) p l_9
No symbol "l_9" in current context.
(gdb) info locals
l_10 = 

note there _is_ l_9 in the DWARF, even with a location:

 <2>: Abbrev Number: 8 (DW_TAG_lexical_block)
   DW_AT_low_pc  : 0xa
   DW_AT_high_pc : 0x0
 <3>: Abbrev Number: 9 (DW_TAG_variable)
   DW_AT_name: l_9
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 7
   DW_AT_decl_column : 7
   DW_AT_type: <0xeb>
   DW_AT_location: 10 byte block: 3 0 0 0 0 0 0 0 0 9f 
(DW_OP_addr: 0; DW_OP_stack_value)

but

 :
   0:   c7 05 00 00 00 00 15movl   $0x15,0x0(%rip)# a 
   7:   00 00 00 
   a:   c3  retq   

and certainly the DW_AT_high_pc of the lexical block looks "odd" - the
block is not existent.  Assembly:

b:
.LFB0:
.file 1 "z.c"
.loc 1 2 9 view -0
.cfi_startproc
.loc 1 3 5 view .LVU1
.loc 1 4 5 view .LVU2
.loc 1 4 14 is_stmt 0 view .LVU3
movl$21, g_2(%rip)
.loc 1 4 20 is_stmt 1 view .LVU4
.LBB2:
.loc 1 7 2 view .LVU5
.LVL0:
.loc 1 8 2 view .LVU6
.LBE2:
.loc 1 10 1 is_stmt 0 view .LVU7
ret

so you can see .LBB2 to .LBE2 do not contain any actual instructions.
GIMPLE we expand from:

 b ()
{
   [local count: 1073741824]:
  [z.c:3:5] # DEBUG BEGIN_STMT
  [z.c:4:5] # DEBUG BEGIN_STMT
  [z.c:4:14] g_2 = 21;
  [z.c:4:20] # DEBUG BEGIN_STMT
  [z.c:7:2] # DEBUG BEGIN_STMT
  [z.c:7:7] # DEBUG l_9 => [z.c:7:13] 
  [z.c:8:2] # DEBUG BEGIN_STMT
  [z.c:8:2] return;

does lldb try to interpret location views yet?  I suppose it might get
confused about the is_stmt 0 on the movl and only stop at ret
even though the "last" location on that is line 10 (but is_stmt 0 again).

It's difficult to produce a meaningful line-number program for the
resulting assembler ;)

[Bug preprocessor/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:a7b7818f3dbd14cc7577d25dcebaded07395c476

commit r11-346-ga7b7818f3dbd14cc7577d25dcebaded07395c476
Author: Christophe Lyon 
Date:   Wed May 13 06:41:19 2020 +

[PR 95013] Fix gcc.dg/unclosed-init.c

2020-05-13  Christophe Lyon  

PR preprocessor/95013
* gcc.dg/unclosed-init.c: Add missing comment in dg-error.

[Bug tree-optimization/92177] [10 Regression] gcc.dg/vect/bb-slp-22.c FAILs

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177

--- Comment #13 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:ff9d4e09566e24d4dff10adeaef109823266c7bd

commit r10-8140-gff9d4e09566e24d4dff10adeaef109823266c7bd
Author: Richard Biener 
Date:   Tue May 5 15:38:24 2020 +0200

testsuite/92177 - adjust expected patterns for gcc.dg/vect/bb-slp-22.c

We now always vectorize two BBs, adjust the selector to also scan
for integer multiplication vectorization explicitely.

2020-05-05  Richard Biener  

PR testsuite/92177
* gcc.dg/vect/bb-slp-22.c: Adjust.

[Bug c++/95100] New: xxx_view adaptors don't work with pipeline operator

[rhalbersma at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95100

Bug ID: 95100
   Summary:  xxx_view adaptors don't work with pipeline
operator
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhalbersma at gmail dot com
  Target Milestone: ---

Combining the std::ranges::xxx_view adaptors with the pipeline operator does
not compile, in contrast to the supposedly expression equivalent
std::ranges:views::xxx 

#include 
#include  
#include 

int main() {
auto v = std::vector { 1, 2, 3, 4, 5, 6 };

// OK
for (auto elem : std::ranges::views::reverse(v)) {
std::cout << elem << ',';
}

// OK
for (auto elem : std::ranges::reverse_view(v)) {
std::cout << elem << ',';
}

// OK
for (auto elem : v | std::ranges::views::reverse) {
std::cout << elem << ',';
}

// error: missing template arguments before ')' token
for (auto elem : v | std::ranges::reverse_view) {
std::cout << elem << ',';
}

// OK
for (auto elem : v | std::ranges::views::transform([](auto e) { return e +
1; })) {
std::cout << elem << ',';
}

// error: class template argument deduction failed:
for (auto elem : v | std::ranges::transform_view([](auto e) { return e + 1;
})) {
std::cout << elem << ',';
}
}

See online example on Wandbox here:
https://wandbox.org/permlink/E6ScFmm8DdmkFo74

Tested this also for drop_view, take_view, filter_view etc., with similar
results (not shown for brevity in the code snippet).

[Bug tree-optimization/95019] Optimizer produces suboptimal code related to -ftree-ivopts

[zhongyunde at tom dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019

--- Comment #2 from zhongyunde at tom dot com  ---
It is a generic issue for all targets, such as x86, it also don't enpand IVOPTs
as index is not used for DEST and Src directly. we may need expand IVOPTs, then
different targets can select different one according their Cost model.
Now, it seems ok for x86 as it have load/store insns folded the lshift operand,
so it doesn't need separate lshift operand in loop body .

== base on the ARM gcc 9.2.1 on https://gcc.godbolt.org, You'll get
separate lshift operand lsl in loop kernel, and ARM64 gcc 8.2 will use ldr
x3, [x1, x4, lsl 3] to avoid the separate lshift operand. so we can see all
target dont select an IV with Step 8. 
C0ADA(unsigned long long, long long*, long long*):
push{r4, r5, r6, r7, lr}@
mov r4, r0@ len, tmp135
mov r5, r1@ len, tmp136
orrsr1, r4, r5  @ tmp137, len
beq .L1 @,
mov r1, #0@ C05A1,
.L3:
lsl r0, r1, #3@ _2, C05A1,
add ip, r2, r1, lsl #3@ tmp120, Src, C05A1,
ldr lr, [r2, r0]  @ _4, *_3
ldr ip, [ip, #4]  @ _4, *_3
umull   r6, r7, lr, lr@ tmp125, _4, _4
mul ip, lr, ip@ tmp122, _4, tmp122
addsr1, r1, r4  @ C05A1, C05A1, len
subsr4, r4, #1  @ len, len,
sbc r5, r5, #0@ len, len,
add r0, r3, r0@ tmp121, Dest, _2
add r7, r7, ip, lsl #1@,, tmp122,
orrslr, r4, r5  @ tmp138, len
stm r0, {r6-r7}   @ *_5, tmp125
bne .L3 @,
.L1:
pop {r4, r5, r6, r7, lr}  @
bx  lr  @

Thanks for your notice.

[Bug ipa/94947] [8/9/10 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:a68d4b47a6b5b23a5d7ab3b358f559f41568512f

commit r10-8142-ga68d4b47a6b5b23a5d7ab3b358f559f41568512f
Author: Richard Biener 
Date:   Thu May 7 14:06:02 2020 +0200

ipa/94947 - avoid using externally_visible_p ()

externally_visible_p wasn't the correct predicate to use (even if it
worked), instead we should use DECL_EXTERNAL || TREE_PUBLIC.

2020-05-07  Richard Biener  

PR ipa/94947
* tree-ssa-structalias.c (refered_from_nonlocal_fn): Use
DECL_EXTERNAL || TREE_PUBLIC instead of externally_visible.
(refered_from_nonlocal_var): Likewise.
(ipa_pta_execute): Likewise.

Re: [PR77691] x86-vxworks malloc aligns to 8 bytes like solaris

[Alexandre Oliva]

Hello, Jonathan,

On May  9, 2020, Jonathan Wakely  wrote:

> On 08/05/20 17:22 -0300, Alexandre Oliva wrote:

>> (Couldn't r1->allocate(2, alignof(char)) possibly return a pointer
>> that's *not* aligned?  Maybe we should drop the test even
>> if !defined(BAD_MAX_ALIGN_T).)

> Yes.

> Different malloc implementations interpret the C standard differently
> here. One interpretation is that all allocations must be aligned to
> alignof(max_align_t) but another is that allocations smaller than that
> don't need to meet that requirement. An object that is two bytes in
> size cannot require 16-byte alignment (otherwise its sizeof would be
> 16 too).

I understand you're talking about malloc because that's what our
implementation ultimately uses, but my question was on language
lawyering, on whether C++ would mandate more alignment than requested by
the caller of allocate.  If it were to do so, I wonder what the point of
specifying the alignment explicitly would be.

> Please do remove that line of the test, instead of wrapping it in the
> #ifdef.

> OK for master.

Thanks, here's what I'm installing in master.


x86-vxworks malloc aligns to 8 bytes like solaris

From: Alexandre Oliva 

Vxworks 7's malloc, like Solaris', only ensures 8-byte alignment of
returned pointers on 32-bit x86, though GCC's stddef.h defines
max_align_t with 16-byte alignment for __float128.  This patch enables
on x86-vxworks the same memory_resource workaround used for x86-solaris.

The testsuite also had a workaround, defining BAD_MAX_ALIGN_T and
xfailing the test; extend those to x86-vxworks as well, and remove the
check for char-aligned requested allocation to be aligned like
max_align_t.  With that change, the test passes on x86-vxworks; I'm
guessing that's the same reason for the test not to pass on
x86-solaris (and on x86_64-solaris -m32), so with the fix, I'm
tentatively removing the xfail.


for libstdc++-v3/ChangeLog

PR libstdc++/77691
* include/experimental/memory_resource
(__resource_adaptor_imp::do_allocate): Handle max_align_t on
x86-vxworks as on x86-solaris.
(__resource_adaptor_imp::do_deallocate): Likewise.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Drop xfail.
(BAD_MAX_ALIGN_T): Define on x86-vxworks as on x86-solaris.
(test03): Drop max-align test for char-aligned alloc.
---
 libstdc++-v3/include/experimental/memory_resource  |4 ++--
 .../memory_resource/new_delete_resource.cc |4 +---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/experimental/memory_resource 
b/libstdc++-v3/include/experimental/memory_resource
index 850a78d..1c4de70 100644
--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -413,7 +413,7 @@ namespace pmr {
   do_allocate(size_t __bytes, size_t __alignment) override
   {
// Cannot use max_align_t on 32-bit Solaris x86, see PR libstdc++/77691
-#if ! (defined __sun__ && defined __i386__)
+#if ! ((defined __sun__ || defined __VXWORKS__) && defined __i386__)
if (__alignment == alignof(max_align_t))
  return _M_allocate(__bytes);
 #endif
@@ -439,7 +439,7 @@ namespace pmr {
   do_deallocate(void* __ptr, size_t __bytes, size_t __alignment) noexcept
   override
   {
-#if ! (defined __sun__ && defined __i386__)
+#if ! ((defined __sun__ || defined __VXWORKS__) && defined __i386__)
if (__alignment == alignof(max_align_t))
  return (void) _M_deallocate(__ptr, __bytes);
 #endif
diff --git 
a/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc 
b/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
index 8a98954..65a42da 100644
--- a/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
+++ b/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
@@ -17,13 +17,12 @@
 
 // { dg-do run { target c++14 } }
 // { dg-require-cstdint "" }
-// { dg-xfail-run-if "PR libstdc++/77691" { { i?86-*-solaris2.* 
x86_64-*-solaris2.* } && ilp32 } }
 
 #include 
 #include 
 #include 
 
-#if defined __sun__ && defined __i386__
+#if (defined __sun__ || defined __VXWORKS__) && defined __i386__
 // See PR libstdc++/77691
 # define BAD_MAX_ALIGN_T 1
 #endif
@@ -128,7 +127,6 @@ test03()
 
   p = r1->allocate(2, alignof(char));
   VERIFY( bytes_allocated == 2 );
-  VERIFY( aligned(p) );
   r1->deallocate(p, 2, alignof(char));
   VERIFY( bytes_allocated == 0 );
 


-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

[PATCH] Fix -fcompare-debug issue in purge_dead_edges [PR95080]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase fails with -fcompare-debug, the bug used to be latent
since introduction of -fcompare-debug.
The loop at the start of purge_dead_edges behaves differently between -g0
and -g - if the last insn is a DEBUG_INSN, then it skips not just
DEBUG_INSNs but also NOTEs until it finds some other real insn (or bb head),
while with -g0 it will not skip any NOTEs, so if we have
real_insn
note
debug_insn // not present with -g0
then with -g it might remove useless REG_EH_REGION from real_insn, while
with -g0 it will not.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

Yet another option would be not skipping NOTE_P in the loop; I couldn't find
in history rationale for why it is done.

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.

* g++.dg/opt/pr95080.C: New test.

--- gcc/cfgrtl.c.jj 2020-04-17 10:32:58.589780140 +0200
+++ gcc/cfgrtl.c2020-05-12 21:02:09.808395583 +0200
@@ -3100,7 +3100,7 @@ purge_dead_edges (basic_block bb)
   bool found;
   edge_iterator ei;
 
-  if (DEBUG_INSN_P (insn) && insn != BB_HEAD (bb))
+  if ((DEBUG_INSN_P (insn) || NOTE_P (insn)) && insn != BB_HEAD (bb))
 do
   insn = PREV_INSN (insn);
 while ((DEBUG_INSN_P (insn) || NOTE_P (insn)) && insn != BB_HEAD (bb));
--- gcc/testsuite/g++.dg/opt/pr95080.C.jj   2020-05-12 21:01:09.804295824 
+0200
+++ gcc/testsuite/g++.dg/opt/pr95080.C  2020-05-12 21:00:52.738551862 +0200
@@ -0,0 +1,41 @@
+// PR debug/95080
+// { dg-do compile }
+// { dg-options "-Og -fcse-follow-jumps -fnon-call-exceptions -fcompare-debug" 
}
+
+char *a;
+
+void baz ();
+
+static inline bool
+bar ()
+{
+  int j = a[0] - 1;
+  switch (j)
+{
+case 0:
+case 2:
+  return true;
+default:
+  return false;
+}
+}
+
+static inline bool
+foo ()
+{
+  if (bar ())
+baz ();
+  return 0;
+}
+
+struct S
+{
+  int h;
+   ~S ();
+};
+
+S::~S ()
+{
+  if (a[0] == 0)
+foo () != h;
+}

Jakub

Re: [PATCH] Fix -fcompare-debug issue in purge_dead_edges [PR95080]

[Richard Biener]

On Wed, 13 May 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase fails with -fcompare-debug, the bug used to be latent
> since introduction of -fcompare-debug.
> The loop at the start of purge_dead_edges behaves differently between -g0
> and -g - if the last insn is a DEBUG_INSN, then it skips not just
> DEBUG_INSNs but also NOTEs until it finds some other real insn (or bb head),
> while with -g0 it will not skip any NOTEs, so if we have
> real_insn
> note
> debug_insn // not present with -g0
> then with -g it might remove useless REG_EH_REGION from real_insn, while
> with -g0 it will not.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

OK.

Thanks,
Richard.

> Yet another option would be not skipping NOTE_P in the loop; I couldn't find
> in history rationale for why it is done.
> 
> 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.
> 
>   * g++.dg/opt/pr95080.C: New test.
> 
> --- gcc/cfgrtl.c.jj   2020-04-17 10:32:58.589780140 +0200
> +++ gcc/cfgrtl.c  2020-05-12 21:02:09.808395583 +0200
> @@ -3100,7 +3100,7 @@ purge_dead_edges (basic_block bb)
>bool found;
>edge_iterator ei;
>  
> -  if (DEBUG_INSN_P (insn) && insn != BB_HEAD (bb))
> +  if ((DEBUG_INSN_P (insn) || NOTE_P (insn)) && insn != BB_HEAD (bb))
>  do
>insn = PREV_INSN (insn);
>  while ((DEBUG_INSN_P (insn) || NOTE_P (insn)) && insn != BB_HEAD (bb));
> --- gcc/testsuite/g++.dg/opt/pr95080.C.jj 2020-05-12 21:01:09.804295824 
> +0200
> +++ gcc/testsuite/g++.dg/opt/pr95080.C2020-05-12 21:00:52.738551862 
> +0200
> @@ -0,0 +1,41 @@
> +// PR debug/95080
> +// { dg-do compile }
> +// { dg-options "-Og -fcse-follow-jumps -fnon-call-exceptions 
> -fcompare-debug" }
> +
> +char *a;
> +
> +void baz ();
> +
> +static inline bool
> +bar ()
> +{
> +  int j = a[0] - 1;
> +  switch (j)
> +{
> +case 0:
> +case 2:
> +  return true;
> +default:
> +  return false;
> +}
> +}
> +
> +static inline bool
> +foo ()
> +{
> +  if (bar ())
> +baz ();
> +  return 0;
> +}
> +
> +struct S
> +{
> +  int h;
> +   ~S ();
> +};
> +
> +S::~S ()
> +{
> +  if (a[0] == 0)
> +foo () != h;
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[Bug tree-optimization/95051] error: invalid RHS for gimple memory store:

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95051

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:3d96f7b92415b7a277a87e7825efc958030e20b6

commit r11-348-g3d96f7b92415b7a277a87e7825efc958030e20b6
Author: Martin Liska 
Date:   Wed May 13 09:52:21 2020 +0200

Simplify test-case options.

PR sanitizer/95051
* gcc.dg/asan/pr95051.c: Simplify options as -fsanitize=address
and -O2 were enough to trigger the original ICE.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018

--- Comment #29 from Thomas Koenig  ---
It is also interesting that this variant

--- a/libgfortran/generated/in_pack_i4.c
+++ b/libgfortran/generated/in_pack_i4.c
@@ -88,7 +88,7 @@ internal_pack_4 (gfc_array_i4 * source)
   count[0]++;
   /* Advance to the next source element.  */
   index_type n = 0;
-  while (count[n] == extent[n])
+  while (n < dim && count[n] == extent[n])
 {
   /* When we get to the end of a dimension, reset it and increment
  the next dimension.  */
@@ -100,7 +100,6 @@ internal_pack_4 (gfc_array_i4 * source)
   if (n == dim)
 {
   src = NULL;
-  break;
 }
   else
 {

does not get peeled.

[Bug testsuite/95092] new test case gcc.dg/asan/pr95051.c fails

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95092

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #1 from Martin Liška  ---
Fixed now.

Re: [PATCH] Add -fsplit-dwarf

[Richard Biener via Gcc-patches]

On Wed, May 13, 2020 at 1:40 AM Fangrui Song via Gcc-patches
 wrote:
>
> -fsplit-dwarf is similar to -gsplit-dwarf, but does not enable debugging
> information by itself. This makes it easier to be plugged into a build
> system without worrying that unnecessary debugging information may be
> generated.

Hmm.  I think having both -fsplit-dwarf and -gsplit-dwarf is confusing.  Doesn't
feeding -g0 -gsplit-dwarf into the build system work with a later -g then
enabling debug info generation?

Having said that my preference would be (in the following order):

 1) make -gsplit-dwarf not imply -g
 2) add -gsplit-dwarf0 implying -g0 (and maybe accept -gsplit-dwarf[012])

for 1) the ship may have sailed.  For 2) it might be confused
with -gdwarf2 so maybe it should be -g0split-dwarf.  Eh.

I still like 1) most.

Oh, and -gsplit-dwarf is largely unmaintained.

Did I mention I dislike -fsplit-dwarf? ;)

Richard.

> 2020-05-12  Fangrui Song  
>
> PR debug/95096
> * common.opt: Add -fsplit-dwarf.
> * doc/invoke.texi: Document it.
> ---
>  gcc/common.opt  | 4 
>  gcc/doc/invoke.texi | 8 
>  2 files changed, 12 insertions(+)
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 4464049fc1f..07aa9f28002 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2515,6 +2515,10 @@ fsingle-precision-constant
>  Common Report Var(flag_single_precision_constant) Optimization
>  Convert floating point constants to single precision constants.
>
> +fsplit-dwarf
> +Common Driver Var(dwarf_split_debug_info) Init(0)
> +If debug information is enabled, generate debug information in separate .dwo 
> files.
> +
>  fsplit-ivs-in-unroller
>  Common Report Var(flag_split_ivs_in_unroller) Init(1) Optimization
>  Split lifetimes of induction variables when loops are unrolled.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 850aeac033d..6590e60f5b3 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -448,6 +448,7 @@ Objective-C and Objective-C++ Dialects}.
>  -femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
>  -fno-eliminate-unused-debug-symbols  -femit-class-debug-always @gol
>  -fno-merge-debug-strings  -fno-dwarf2-cfi-asm @gol
> +-fsplit-dwarf @gol
>  -fvar-tracking  -fvar-tracking-assignments}
>
>  @item Optimization Options
> @@ -8771,6 +8772,13 @@ also be used to change an absolute path to a relative 
> path by using
>  are location independent, but may require an extra command to tell GDB
>  where to find the source files. See also @option{-ffile-prefix-map}.
>
> +@item -fsplit-dwarf
> +@opindex fsplit-dwarf
> +If DWARF debugging information is enabled, separate as much debugging
> +information as possible into a separate output file with the extension
> +@file{.dwo}. This is similar to @option{-gsplit-dwarf}, but this option
> +does not enable debugging information by itself.
> +
>  @item -fvar-tracking
>  @opindex fvar-tracking
>  Run variable tracking pass.  It computes where variables are stored at each
> --
> 2.26.2.645.ge9eca65c58-goog
>

[Bug ipa/94947] [8/9/10 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:67d00c438285ecf9b8e96c12d1f6b05fd2ea3c21

commit r10-8141-g67d00c438285ecf9b8e96c12d1f6b05fd2ea3c21
Author: Richard Biener 
Date:   Tue May 5 13:09:50 2020 +0200

ipa/94947 - fix test for externally visible variables for IPA PTA

This fixes lack of an escape point of externally declared variables.

2020-05-05  Richard Biener  

PR ipa/94947
* tree-ssa-structalias.c (ipa_pta_execute): Use
varpool_node::externally_visible_p ().
(refered_from_nonlocal_var): Likewise.

* gcc.dg/torture/pr94947-1.c: New testcase.
* gcc.dg/torture/pr94947-2.c: Likewise.

[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:f884bef2105d748fd7869cd641cbb4f6b6bb

commit r11-349-gf884bef2105d748fd7869cd641cbb4f6b6bb
Author: Tobias Burnus 
Date:   Wed May 13 10:06:45 2020 +0200

[Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690)

gcc/fortran/
2020-05-13  Tobias Burnus  

PR fortran/94690
* openmp.c (OMP_DISTRIBUTE_CLAUSES): Add OMP_CLAUSE_LASTPRIVATE.
(gfc_resolve_do_iterator): Skip the private handling for SIMD as
that is handled by ME code.
* trans-openmp.c (gfc_trans_omp_do): Don't add private/lastprivate
for dovar_found == 0, unless !simple.

libgomp/
2020-05-13  Tobias Burnus  

PR fortran/94690
* testsuite/libgomp.fortran/pr66199-3.f90: New.
* testsuite/libgomp.fortran/pr66199-4.f90: New.
* testsuite/libgomp.fortran/pr66199-5.f90: New.
* testsuite/libgomp.fortran/pr66199-6.f90: New.
* testsuite/libgomp.fortran/pr66199-7.f90: New.
* testsuite/libgomp.fortran/pr66199-8.f90: New.
* testsuite/libgomp.fortran/pr66199-9.f90: New.

[PATCH] tree-optimization/33315 - common stores during sinking

[Richard Biener]

This implements commoning of stores to a common successor in
a simple ad-hoc way.  I've decided to put it into the code sinking
pass since, well, it sinks stores.  It's still separate since
it does not really sink code into less executed places.

It's ad-hoc since it does not perform any dataflow or alias analysis
but simply only considers trailing stores in a block, iteratively
though.  If the stores are from different values a PHI node is
inserted to merge them.  gcc.dg/tree-ssa/split-path-7.c shows
that path splitting will eventually undo this very transform,
I've decided to not bother with it and simply disable sinking for
the particular testcase.

Doing this transform is good for code size when the stores are
from constants, once we have to insert PHIs the situation becomes
less clear but it's a transform we do elsewhere as well
(cselim for one), and reversing the transform should be easy.

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Any comments?

2020-05-13  Richard Biener  

PR tree-optimization/33315
* tree-ssa-sink.c: Include tree-eh.h.
(sink_code_in_bb): Return TODO_cleanup_cfg if we commonized
and sunk stores.  Implement store commoning by sinking to
the successor.

* gcc.dg/tree-ssa/ssa-sink-13.c: New testcase.
* gcc.dg/tree-ssa/ssa-sink-14.c: Likewise.
* gcc.dg/tree-ssa/split-path-7.c: Disable sinking.
---
 gcc/testsuite/gcc.dg/tree-ssa/split-path-7.c |   2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-13.c  |  25 
 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-14.c  |  17 +++
 gcc/tree-ssa-sink.c  | 168 ++-
 4 files changed, 207 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-13.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-14.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/split-path-7.c 
b/gcc/testsuite/gcc.dg/tree-ssa/split-path-7.c
index 3d6186b34d9..a5df75c9b72 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/split-path-7.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/split-path-7.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fsplit-paths -fno-tree-cselim 
-fdump-tree-split-paths-details -w" } */
+/* { dg-options "-O2 -fsplit-paths -fno-tree-cselim -fno-tree-sink 
-fdump-tree-split-paths-details -w" } */
 
 
 struct _reent
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-13.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-13.c
new file mode 100644
index 000..a65ba35d4ba
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-13.c
@@ -0,0 +1,25 @@
+/* PR33315 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-sink" } */
+
+int num;
+int a[20];
+
+void test ()
+{
+  int i;
+  int *ptr;
+  ptr = & a[0];
+  i = num;
+  if ( i == 1) *(ptr+0) = 0;
+  if ( i != 1) *(ptr+0) = 0;
+  if ( i == 2) *(ptr+1) = 0;
+  if ( i != 2) *(ptr+1) = 0;
+  if ( i == 3) *(ptr+2) = 0;
+  if ( i != 3) *(ptr+2) = 0;
+}
+
+/* We should sink/merge all stores and end up with a single BB.  */
+
+/* { dg-final { scan-tree-dump-times "MEM\[^\n\r\]* = 0;" 3 "sink" } } */
+/* { dg-final { scan-tree-dump-times "preds) > 1
+  && (phi = get_virtual_phi (bb)))
+{
+  /* Repeat until no more common stores are found.  */
+  while (1)
+   {
+ gimple *first_store = NULL;
+ auto_vec  vdefs;
+
+ /* Search for common stores defined by all virtual PHI args.
+???  Common stores not present in all predecessors could
+be handled by inserting a forwarder to sink to.  Generally
+this involves deciding which stores to do this for if
+multiple common stores are present for different sets of
+predecessors.  See PR11832 for an interesting case.  */
+ for (unsigned i = 0; i < gimple_phi_num_args (phi); ++i)
+   {
+ tree arg = gimple_phi_arg_def (phi, i);
+ gimple *def = SSA_NAME_DEF_STMT (arg);
+ if (! is_gimple_assign (def)
+ || stmt_can_throw_internal (cfun, def))
+   {
+ /* ???  We could handle some cascading with the def being
+another PHI.  We'd have to insert multiple PHIs for
+the rhs then though (if they are not all equal).  */
+ first_store = NULL;
+ break;
+   }
+ /* ???  Do not try to do anything fancy with aliasing, thus
+do not sink across non-aliased loads (or even stores,
+so different store order will make the sinking fail).  */
+ bool all_uses_on_phi = true;
+ imm_use_iterator iter;
+ use_operand_p use_p;
+ FOR_EACH_IMM_USE_FAST (use_p, iter, arg)
+   if (USE_STMT (use_p) != phi)
+ {
+   all_uses_on_phi = false;
+   break;
+ }
+ if (! all_uses_on_phi)
+   {
+ 

Re: [PATCH] Fold single imm use of a FMA if it is a negation [PR95060]

[Richard Biener]

On Wed, 13 May 2020, Jakub Jelinek wrote:

> Hi!
> 
> match.pd already has simplifications for negation of a FMA (FMS, FNMA, FNMS)
> call if it is single use, but when the widening_mul pass discovers FMAs,
> nothing folds the statements anymore.
> 
> So, the following patch adjusts the widening_mul pass to handle that.
> 
> I had to adjust quite a lot of tests, because they have in them nested FMAs
> (one FMA feeding another one) and the patch results in some (equivalent) 
> changes
> in the chosen instructions, previously the negation of one FMA's result
> would result in the dependent FMA being adjusted for the negation, but now
> instead the first FMA is adjusted.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2020-05-13  Jakub Jelinek  
> 
>   PR tree-optimization/95060
>   * tree-ssa-math-opts.c (convert_mult_to_fma_1): Fold a NEGATE_EXPR
>   if it is the single use of the FMA internal builtin.
> 
>   * gcc.target/i386/avx512f-pr95060.c: New test.
>   * gcc.target/i386/fma_double_1.c: Adjust expected insn counts.
>   * gcc.target/i386/fma_double_2.c: Likewise.
>   * gcc.target/i386/fma_double_3.c: Likewise.
>   * gcc.target/i386/fma_double_4.c: Likewise.
>   * gcc.target/i386/fma_double_5.c: Likewise.
>   * gcc.target/i386/fma_double_6.c: Likewise.
>   * gcc.target/i386/fma_float_1.c: Likewise.
>   * gcc.target/i386/fma_float_2.c: Likewise.
>   * gcc.target/i386/fma_float_3.c: Likewise.
>   * gcc.target/i386/fma_float_4.c: Likewise.
>   * gcc.target/i386/fma_float_5.c: Likewise.
>   * gcc.target/i386/fma_float_6.c: Likewise.
>   * gcc.target/i386/l_fma_double_1.c: Likewise.
>   * gcc.target/i386/l_fma_double_2.c: Likewise.
>   * gcc.target/i386/l_fma_double_3.c: Likewise.
>   * gcc.target/i386/l_fma_double_4.c: Likewise.
>   * gcc.target/i386/l_fma_double_5.c: Likewise.
>   * gcc.target/i386/l_fma_double_6.c: Likewise.
>   * gcc.target/i386/l_fma_float_1.c: Likewise.
>   * gcc.target/i386/l_fma_float_2.c: Likewise.
>   * gcc.target/i386/l_fma_float_3.c: Likewise.
>   * gcc.target/i386/l_fma_float_4.c: Likewise.
>   * gcc.target/i386/l_fma_float_5.c: Likewise.
>   * gcc.target/i386/l_fma_float_6.c: Likewise.
> 
> --- gcc/tree-ssa-math-opts.c.jj   2020-03-26 09:14:53.367045348 +0100
> +++ gcc/tree-ssa-math-opts.c  2020-05-12 12:06:19.718387179 +0200
> @@ -2930,6 +2930,35 @@ convert_mult_to_fma_1 (tree mul_result,
> fprintf (dump_file, "\n");
>   }
>  
> +  /* If the FMA result is negated in a single use, fold the negation
> +  too.  */
> +  orig_stmt = gsi_stmt (gsi);
> +  use_operand_p use_p;
> +  gimple *neg_stmt;
> +  if (is_gimple_call (orig_stmt)
> +   && gimple_call_internal_p (orig_stmt)
> +   && gimple_call_lhs (orig_stmt)
> +   && TREE_CODE (gimple_call_lhs (orig_stmt)) == SSA_NAME
> +   && single_imm_use (gimple_call_lhs (orig_stmt), _p, _stmt)
> +   && is_gimple_assign (neg_stmt)
> +   && gimple_assign_rhs_code (neg_stmt) == NEGATE_EXPR
> +   && !stmt_could_throw_p (cfun, neg_stmt))
> + {
> +   gsi = gsi_for_stmt (neg_stmt);
> +   if (fold_stmt (, follow_all_ssa_edges))
> + {
> +   if (maybe_clean_or_replace_eh_stmt (neg_stmt, gsi_stmt (gsi)))
> + gcc_unreachable ();
> +   update_stmt (gsi_stmt (gsi));
> +   if (dump_file && (dump_flags & TDF_DETAILS))
> + {
> +   fprintf (dump_file, "Folded FMA negation ");
> +   print_gimple_stmt (dump_file, gsi_stmt (gsi), 0, TDF_NONE);
> +   fprintf (dump_file, "\n");
> + }
> + }
> + }
> +
>widen_mul_stats.fmas_inserted++;
>  }
>  }
> --- gcc/testsuite/gcc.target/i386/avx512f-pr95060.c.jj2020-05-12 
> 12:17:16.052468438 +0200
> +++ gcc/testsuite/gcc.target/i386/avx512f-pr95060.c   2020-05-12 
> 12:16:52.333826884 +0200
> @@ -0,0 +1,22 @@
> +/* PR tree-optimization/95060 */
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -ffast-math -mavx512f" } */
> +/* { dg-final { scan-assembler "\tvfnmsub" } } */
> +/* { dg-final { scan-assembler-not "\tvfmadd" } } */
> +
> +#define N 32
> +float r[N], a[N], b[N], c[N];
> +
> +void
> +foo (void)
> +{
> +  for (int i = 0; i < N; i++)
> +r[i] = -(a[i] * b[i]) - c[i];
> +}
> +
> +void
> +bar (void)
> +{
> +  for (int i = 0; i < N; i++)
> +r[i] = -(a[i] * b[i] + c[i]);
> +}
> --- gcc/testsuite/gcc.target/i386/fma_double_1.c.jj   2020-01-12 
> 11:54:37.943390325 +0100
> +++ gcc/testsuite/gcc.target/i386/fma_double_1.c  2020-05-13 
> 09:55:10.878118046 +0200
> @@ -8,11 +8,9 @@
>  
>  #include "fma_1.h"
>  
> -/* { dg-final { scan-assembler-times "vfmadd132sd" 4  } } */
> +/* { dg-final { scan-assembler-times "vfmadd132sd" 8  } } */
>  /* { dg-final { scan-assembler-times "vfmadd231sd" 4  } } */
> -/* { dg-final { scan-assembler-times 

[Bug debug/95098] New: Out of scope variable visible during debugging at Og

[massarelli at diag dot uniroma1.it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95098

Bug ID: 95098
   Summary: Out of scope variable visible during debugging at Og
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: massarelli at diag dot uniroma1.it
  Target Milestone: ---

Variable l_9 is visible when the debugger hit line 4.

$ cat a.c
int g_2, a;
int b() {
  char l_10;
  for (g_2 = 21; (g_2 < (-27)); g_2 = 0)
return g_2;
  {
int *l_9 = 
return;
  }
}
int main() { b(); }

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/gcc_build --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200508 (experimental) (GCC) 

$ lldb -v
  lldb version 11.0.0
  clang revision 23cbea9a04e023d5b79dfee5964fae769340c993
  llvm revision 23cbea9a04e023d5b79dfee5964fae769340c993

$ gcc -Og -g -o opt a.c

$ lldb opt 
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b main
Breakpoint 1: where = opt`main at a.c:11:14, address = 0x0040048d
(lldb) r
Process 61 launched: 'opt' (x86_64)
Process 61 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.1
frame #0: 0x0040048d opt`main at a.c:11:14
   8return;
   9  }
   10   }
-> 11   int main() { b(); }
(lldb) s
Process 61 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x00400482 opt`b at a.c:4:12
   1int g_2, a;
   2int b() {
   3  char l_10;
-> 4  for (g_2 = 21; (g_2 < (-27)); g_2 = 0)
   5return g_2;
   6  {
   7int *l_9 = 
(lldb) frame var -s -g
LOCAL: (char) l_10 = 
STATIC: (int *) l_9 = 0x0060102c
GLOBAL: (int) g_2 = 0
GLOBAL: (int) a = 0

[Bug tree-optimization/95097] Missed optimization with bitfield value ranges

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95097

--- Comment #3 from Richard Biener  ---
Just to quote EVRP sees

   :
  _1 = VIEW_CONVERT_EXPR(f);
  _2 = _1 & 1048575;
  if (_2 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  _3 = f.x;
  _4 = (unsigned int) _3;
  y_8 = _4 * 4096;
  if (y_8 <= 199)

thus the f.x != 0 test has been folded by one of those $?%&! permature
fold-const transforms to

  if ((BIT_FIELD_REF  & 1048575) != 0)

the fix is to get rid of those (and fix the "fallout").

[Bug tree-optimization/95019] Optimizer produces suboptimal code related to -ftree-ivopts

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019

--- Comment #3 from bin cheng  ---
(In reply to zhongyu...@tom.com from comment #2)
> It is a generic issue for all targets, such as x86, it also don't enpand
Yes, as said it's because SCEV currently doesn't model this, so it's not target
specific.

> IVOPTs as index is not used for DEST and Src directly. we may need expand
Yes, extending IVOPTs to handle this case (and cases from other PRs) seems
promising.
Anyway, patch is welcome, and I can do the review.

Thanks,
> IVOPTs, then different targets can select different one according their Cost
> model.
> Now, it seems ok for x86 as it have load/store insns folded the lshift
> operand, so it doesn't need separate lshift operand in loop body .
> 
> == base on the ARM gcc 9.2.1 on https://gcc.godbolt.org, You'll get
> separate lshift operand lsl in loop kernel, and ARM64 gcc 8.2 will use ldr  
> x3, [x1, x4, lsl 3] to avoid the separate lshift operand. so we can see all
> target dont select an IV with Step 8. 
> C0ADA(unsigned long long, long long*, long long*):
> push{r4, r5, r6, r7, lr}@
> mov r4, r0@ len, tmp135
> mov r5, r1@ len, tmp136
> orrsr1, r4, r5  @ tmp137, len
> beq .L1 @,
> mov r1, #0@ C05A1,
> .L3:
> lsl r0, r1, #3@ _2, C05A1,
> add ip, r2, r1, lsl #3@ tmp120, Src, C05A1,
> ldr lr, [r2, r0]  @ _4, *_3
> ldr ip, [ip, #4]  @ _4, *_3
> umull   r6, r7, lr, lr@ tmp125, _4, _4
> mul ip, lr, ip@ tmp122, _4, tmp122
> addsr1, r1, r4  @ C05A1, C05A1, len
> subsr4, r4, #1  @ len, len,
> sbc r5, r5, #0@ len, len,
> add r0, r3, r0@ tmp121, Dest, _2
> add r7, r7, ip, lsl #1@,, tmp122,
> orrslr, r4, r5  @ tmp138, len
> stm r0, {r6-r7}   @ *_5, tmp125
> bne .L3 @,
> .L1:
> pop {r4, r5, r6, r7, lr}  @
> bx  lr  @
> 
> Thanks for your notice.

Re: testsuite: Fix up gcc.dg/asan/pr95051.c testcase [PR95051]

[Martin Liška]

On 5/12/20 9:23 PM, Jakub Jelinek wrote:

Hi!

On Tue, May 12, 2020 at 12:06:25PM -0700, H.J. Lu wrote:

Excess errors:
cc1: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'


asan.exp adds -fsanitize=address which is incompatible with 
-fsanitize=kernel-address,
so we need to disable it first.


Sorry for the breakage, I added this test late after I made tests.
There's a simplification where the test-case failes also with 
-fsanitize=address -O2.

Martin



Tested on x86_64-linux -m32/-m64, committed to trunk as obvious.

2020-05-12  Jakub Jelinek  

PR sanitizer/95051
* gcc.dg/asan/pr95051.c: Add -fno-sanitize=all to dg-options.

--- gcc/testsuite/gcc.dg/asan/pr95051.c.jj  2020-05-12 11:25:46.209148953 
+0200
+++ gcc/testsuite/gcc.dg/asan/pr95051.c 2020-05-12 21:12:28.170118274 +0200
@@ -1,6 +1,6 @@
  /* PR sanitizer/95051 */
  /* { dg-do compile } */
-/* { dg-options "-fsanitize=kernel-address --param=asan-stack=1 -O2" } */
+/* { dg-options "-fno-sanitize=all -fsanitize=kernel-address --param=asan-stack=1 
-O2" } */
  
  struct a {

struct {


Jakub



>From 678e6b5c127307f29f0ce883497d4e7af399399c Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 12 May 2020 22:02:24 +0200
Subject: [PATCH] Simplify test-case options.

gcc/testsuite/ChangeLog:

2020-05-12  Martin Liska  

	PR sanitizer/95051
	* gcc.dg/asan/pr95051.c: Simplify options as -fsanitize=address
	and -O2 were enough to trigger the original ICE.
---
 gcc/testsuite/gcc.dg/asan/pr95051.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/asan/pr95051.c b/gcc/testsuite/gcc.dg/asan/pr95051.c
index caa5e667209..e32c04599a8 100644
--- a/gcc/testsuite/gcc.dg/asan/pr95051.c
+++ b/gcc/testsuite/gcc.dg/asan/pr95051.c
@@ -1,6 +1,6 @@
 /* PR sanitizer/95051 */
 /* { dg-do compile } */
-/* { dg-options "-fno-sanitize=all -fsanitize=kernel-address --param=asan-stack=1 -O2" } */
+/* { dg-options "-O2" } */
 
 struct a {
   struct {
-- 
2.26.2

[Bug libgcc/95099] New: Build a cross compiler for m32c on Windows (Cygwin)

[dj_adilovic at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95099

Bug ID: 95099
   Summary: Build a cross compiler for m32c on Windows (Cygwin)
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dj_adilovic at hotmail dot com
  Target Milestone: ---

Hi Everybody,
i want to Build a cross compiler for the m32c-elf.
but i get a Error during make the newlib-3.1.0.
The error lock like:
during RTL pass: pro_and_epilogue
../../../../../../newlib-3.1.0/newlib/libc/argz/argz_add.c: In function
‘argz_add’:
../../../../../../newlib-3.1.0/newlib/libc/argz/argz_add.c:32:1: internal
compiler error: in leaf_function_p, at final.c:4473
   32 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [Makefile:399: lib_a-argz_add.o] Error 1
make[8]: Leaving directory
'/home/cross/m32c-newlib/m32c-elf/m32cm/newlib/libc/argz'
make[7]: *** [Makefile:683: all-recursive] Error 1
make[7]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/m32cm/newlib/libc'
make[6]: *** [Makefile:641: all-recursive] Error 1
make[6]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/m32cm/newlib'
make[5]: *** [Makefile:452: all] Error 2
make[5]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/m32cm/newlib'
make[4]: *** [Makefile:1260: multi-do] Error 1
make[4]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/newlib'
make[3]: *** [Makefile:1176: all-multi] Error 2
make[3]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/newlib'
make[2]: *** [Makefile:452: all] Error 2
make[2]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/newlib'
make[1]: *** [Makefile:8496: all-target-newlib] Error 2
make[1]: Leaving directory '/home/cross/m32c-newlib'
make: *** [Makefile:883: all] Error 2

can somone help me.
Thank you

[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691

--- Comment #42 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:883246530f1bb10d854f455e1c3d55b93675690a

commit r11-347-g883246530f1bb10d854f455e1c3d55b93675690a
Author: Alexandre Oliva 
Date:   Wed May 13 04:49:00 2020 -0300

x86-vxworks malloc aligns to 8 bytes like solaris

Vxworks 7's malloc, like Solaris', only ensures 8-byte alignment of
returned pointers on 32-bit x86, though GCC's stddef.h defines
max_align_t with 16-byte alignment for __float128.  This patch enables
on x86-vxworks the same memory_resource workaround used for x86-solaris.

The testsuite also had a workaround, defining BAD_MAX_ALIGN_T and
xfailing the test; extend those to x86-vxworks as well, and remove the
check for char-aligned requested allocation to be aligned like
max_align_t.  With that change, the test passes on x86-vxworks; I'm
guessing that's the same reason for the test not to pass on
x86-solaris (and on x86_64-solaris -m32), so with the fix, I'm
tentatively removing the xfail.


for libstdc++-v3/ChangeLog

PR libstdc++/77691
* include/experimental/memory_resource
(__resource_adaptor_imp::do_allocate): Handle max_align_t on
x86-vxworks as on x86-solaris.
(__resource_adaptor_imp::do_deallocate): Likewise.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Drop xfail.
(BAD_MAX_ALIGN_T): Define on x86-vxworks as on x86-solaris.
(test03): Drop max-align test for char-aligned alloc.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018

--- Comment #30 from Richard Biener  ---
(In reply to Thomas Koenig from comment #29)
> It is also interesting that this variant
> 
> --- a/libgfortran/generated/in_pack_i4.c
> +++ b/libgfortran/generated/in_pack_i4.c
> @@ -88,7 +88,7 @@ internal_pack_4 (gfc_array_i4 * source)
>count[0]++;
>/* Advance to the next source element.  */
>index_type n = 0;
> -  while (count[n] == extent[n])
> +  while (n < dim && count[n] == extent[n])
>  {
>/* When we get to the end of a dimension, reset it and increment
>   the next dimension.  */
> @@ -100,7 +100,6 @@ internal_pack_4 (gfc_array_i4 * source)
>if (n == dim)
>  {
>src = NULL;
> -  break;
>  }
>else
>  {
> 
> does not get peeled.

More optimal would be

count[0]--;
>/* Advance to the next source element.  */
>index_type n = 0;
while (count[n] == 0)
  {
...
  }

note completely peeling the inner loop isn't as bad as it looks, it's
basically making the whole loop

  while (1)
{
  for (count[0] = 0; count[0] < extent[0]; ++count[0])
{
  /* Copy the data.  */
  *(dest++) = *src;
  /* Advance to the next element.  */
  src += stride0;
}
  if (dim == 1)
break;
  count[0] = 0;
  src -= stride[0] * extent[0];
  count[1]++;
  if (count[1] != extent[1])
continue;
  if (dim == 2)
break;
  count[1] = 0;
  src -= stride[1] * extent[1];
  count[2]++;
  if (count[2] != extent[2])
continue;
  if (dim == 3)
break;
...
}

which should be quite optimal for speed (branch-prediction wise).  One
might want to try to optimize code size a bit, sure.  Sacrifying a bit
of speed at the loop exit could be setting extent[n > dim] = 1 and
dropping the if (dim == N) break; checks, leaving just the last.
Likewise changing the iteration from extent[N] to zero might make
the tests smaller.  Then as commented in the code pre-computing the
products might help as well - you get one additional load of course.
Interleaving extent and the product data arrays would help cache
locality.

Note writing the loop as above will make GCC recognize it as a loop
nest.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018

--- Comment #28 from Richard Biener  ---
> It the growth limit seems could be refined. The ^ is an exponent operation,
> right?

Yes.  The idea is to limit growth more when there is no benefit of unrolling
detected by the cost model (which currently simply counts likely eliminated
stmts).

(In reply to Jiu Fu Guo from comment #27)
> (In reply to Jiu Fu Guo from comment #26)
> > (In reply to Richard Biener from comment #20)
> > > (In reply to Jiu Fu Guo from comment #18)
> > > > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > > > if the loop has multi-exits or upbound is not a fixed number, we may 
> > > > not do
> > > > 'complete unroll' for the loop, except -funroll-all-loops is specified.
> > > 
> > > That doens't make much sense (-funroll-all-loops is RTL unroller only).
> > 
> 
> For the loop which has multi-exits, it may not helpful to unroll it,
> especially "complete unroll" may be not helpful. Like loop in in_pack_i4.c.
> Since it would early exit, some iterations(may most iterations) were not
> executed.
> 
> Is it a good idea to disable the GIMPLE cunroll for this kind of loop? RTL
> unroll_stupid does not unroll this kind of loop either.

Well, GIMPLE cunroll specifically handles the situation of peeling such loops
and has a separate --param to control how many extra branches it may introduce
for those exits.  Generally disabling unrolling of such loops isn't a good
idea,
the reason for completely unrolling loops is abstraction removal and not
necessarily producing more optimal loop kernels (the loop is gone afterwards).

One of my TODO items is to work on its costing model to the extent that
we run value-numbering on the unrolled body (that's already done) and
roll back the unrolling if there wasn't any visible benefit.  The difficult
cases are like those in SPEC calculix where for full benefit you need to
unroll the 5(!) innermost loops and to even see any benefit you need to
unroll the 3 innermost loops.

[Bug tree-optimization/95097] Missed optimization with bitfield value ranges

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95097

Andrew Pinski  changed:

   What|Removed |Added

 Blocks|85316   |
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
The problem is if (f.x) gets lowered too early.
This is not directly a VPR issue either.
Changing the code slightly:
#include 
struct foo {
uint32_t x:20;
};
int bar(struct foo f)
{

   uint32_t y = (uint32_t)f.x;
if (y) {
y *= 4096;
if (y<200) return 1;
else return 2;
}
return 3;
}

GCC is able to optimize it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug tree-optimization/92177] [10 Regression] gcc.dg/vect/bb-slp-22.c FAILs

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #12 from Richard Biener  ---
.

[PATCH] Fold single imm use of a FMA if it is a negation [PR95060]

[Jakub Jelinek via Gcc-patches]

Hi!

match.pd already has simplifications for negation of a FMA (FMS, FNMA, FNMS)
call if it is single use, but when the widening_mul pass discovers FMAs,
nothing folds the statements anymore.

So, the following patch adjusts the widening_mul pass to handle that.

I had to adjust quite a lot of tests, because they have in them nested FMAs
(one FMA feeding another one) and the patch results in some (equivalent) changes
in the chosen instructions, previously the negation of one FMA's result
would result in the dependent FMA being adjusted for the negation, but now
instead the first FMA is adjusted.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-05-13  Jakub Jelinek  

PR tree-optimization/95060
* tree-ssa-math-opts.c (convert_mult_to_fma_1): Fold a NEGATE_EXPR
if it is the single use of the FMA internal builtin.

* gcc.target/i386/avx512f-pr95060.c: New test.
* gcc.target/i386/fma_double_1.c: Adjust expected insn counts.
* gcc.target/i386/fma_double_2.c: Likewise.
* gcc.target/i386/fma_double_3.c: Likewise.
* gcc.target/i386/fma_double_4.c: Likewise.
* gcc.target/i386/fma_double_5.c: Likewise.
* gcc.target/i386/fma_double_6.c: Likewise.
* gcc.target/i386/fma_float_1.c: Likewise.
* gcc.target/i386/fma_float_2.c: Likewise.
* gcc.target/i386/fma_float_3.c: Likewise.
* gcc.target/i386/fma_float_4.c: Likewise.
* gcc.target/i386/fma_float_5.c: Likewise.
* gcc.target/i386/fma_float_6.c: Likewise.
* gcc.target/i386/l_fma_double_1.c: Likewise.
* gcc.target/i386/l_fma_double_2.c: Likewise.
* gcc.target/i386/l_fma_double_3.c: Likewise.
* gcc.target/i386/l_fma_double_4.c: Likewise.
* gcc.target/i386/l_fma_double_5.c: Likewise.
* gcc.target/i386/l_fma_double_6.c: Likewise.
* gcc.target/i386/l_fma_float_1.c: Likewise.
* gcc.target/i386/l_fma_float_2.c: Likewise.
* gcc.target/i386/l_fma_float_3.c: Likewise.
* gcc.target/i386/l_fma_float_4.c: Likewise.
* gcc.target/i386/l_fma_float_5.c: Likewise.
* gcc.target/i386/l_fma_float_6.c: Likewise.

--- gcc/tree-ssa-math-opts.c.jj 2020-03-26 09:14:53.367045348 +0100
+++ gcc/tree-ssa-math-opts.c2020-05-12 12:06:19.718387179 +0200
@@ -2930,6 +2930,35 @@ convert_mult_to_fma_1 (tree mul_result,
  fprintf (dump_file, "\n");
}
 
+  /* If the FMA result is negated in a single use, fold the negation
+too.  */
+  orig_stmt = gsi_stmt (gsi);
+  use_operand_p use_p;
+  gimple *neg_stmt;
+  if (is_gimple_call (orig_stmt)
+ && gimple_call_internal_p (orig_stmt)
+ && gimple_call_lhs (orig_stmt)
+ && TREE_CODE (gimple_call_lhs (orig_stmt)) == SSA_NAME
+ && single_imm_use (gimple_call_lhs (orig_stmt), _p, _stmt)
+ && is_gimple_assign (neg_stmt)
+ && gimple_assign_rhs_code (neg_stmt) == NEGATE_EXPR
+ && !stmt_could_throw_p (cfun, neg_stmt))
+   {
+ gsi = gsi_for_stmt (neg_stmt);
+ if (fold_stmt (, follow_all_ssa_edges))
+   {
+ if (maybe_clean_or_replace_eh_stmt (neg_stmt, gsi_stmt (gsi)))
+   gcc_unreachable ();
+ update_stmt (gsi_stmt (gsi));
+ if (dump_file && (dump_flags & TDF_DETAILS))
+   {
+ fprintf (dump_file, "Folded FMA negation ");
+ print_gimple_stmt (dump_file, gsi_stmt (gsi), 0, TDF_NONE);
+ fprintf (dump_file, "\n");
+   }
+   }
+   }
+
   widen_mul_stats.fmas_inserted++;
 }
 }
--- gcc/testsuite/gcc.target/i386/avx512f-pr95060.c.jj  2020-05-12 
12:17:16.052468438 +0200
+++ gcc/testsuite/gcc.target/i386/avx512f-pr95060.c 2020-05-12 
12:16:52.333826884 +0200
@@ -0,0 +1,22 @@
+/* PR tree-optimization/95060 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -ffast-math -mavx512f" } */
+/* { dg-final { scan-assembler "\tvfnmsub" } } */
+/* { dg-final { scan-assembler-not "\tvfmadd" } } */
+
+#define N 32
+float r[N], a[N], b[N], c[N];
+
+void
+foo (void)
+{
+  for (int i = 0; i < N; i++)
+r[i] = -(a[i] * b[i]) - c[i];
+}
+
+void
+bar (void)
+{
+  for (int i = 0; i < N; i++)
+r[i] = -(a[i] * b[i] + c[i]);
+}
--- gcc/testsuite/gcc.target/i386/fma_double_1.c.jj 2020-01-12 
11:54:37.943390325 +0100
+++ gcc/testsuite/gcc.target/i386/fma_double_1.c2020-05-13 
09:55:10.878118046 +0200
@@ -8,11 +8,9 @@
 
 #include "fma_1.h"
 
-/* { dg-final { scan-assembler-times "vfmadd132sd" 4  } } */
+/* { dg-final { scan-assembler-times "vfmadd132sd" 8  } } */
 /* { dg-final { scan-assembler-times "vfmadd231sd" 4  } } */
-/* { dg-final { scan-assembler-times "vfmsub132sd" 4  } } */
+/* { dg-final { scan-assembler-times "vfmsub132sd" 8  } } */
 /* { dg-final { scan-assembler-times "vfmsub231sd" 4  } } */
-/* { dg-final { scan-assembler-times "vfnmadd132sd" 4  } } */
 /* { 

[Bug rtl-optimization/95102] New: missed if-conversion

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95102

Bug ID: 95102
   Summary: missed if-conversion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

If you rewrite gcc.target/i386/pr54855-9.c to a form GIMPLE looks like after
some PRE you end up with

typedef float vec __attribute__((vector_size(16)));

vec
foo (vec x, float a)
{
  if (!(x[0] < a))
x[0] = a;
  return x;
}

which is no longer recognized as the same and emits

foo:
.LFB0:
.cfi_startproc
comiss  %xmm0, %xmm1
ja  .L2
movss   %xmm1, %xmm0
.L2:
ret

instead of

foo:
.LFB1:  
.cfi_startproc
minss   %xmm1, %xmm0
ret

this is because RTL if-conversion does not recognize

7: r86:SF=vec_select(r84:V4SF,parallel)
8: flags:CCFP=cmp(r85:SF,r86:SF)
  REG_DEAD r86:SF
9: pc={(flags:CCFP>0)?L14:pc}
  REG_DEAD flags:CCFP
  REG_BR_PROB 536870916

   10: NOTE_INSN_BASIC_BLOCK 3
   12: r84:V4SF=vec_merge(vec_duplicate(r85:SF),r84:V4SF,0x1)
  REG_DEAD r85:SF

   14: L14:
   15: NOTE_INSN_BASIC_BLOCK 4
   20: xmm0:V4SF=r84:V4SF

the form it does recognize is

8: r82:SF=vec_select(r84:V4SF,parallel)
9: flags:CCFP=cmp(r85:SF,r82:SF)
   10: pc={(flags:CCFP>0)?L28:pc}
  REG_DEAD flags:CCFP
  REG_BR_PROB 536870916

   28: L28:
   14: NOTE_INSN_BASIC_BLOCK 3
5: r85:SF=r82:SF
  REG_DEAD r82:SF

   15: L15:
   16: NOTE_INSN_BASIC_BLOCK 4
   18: r87:V4SF=vec_merge(vec_duplicate(r85:SF),r84:V4SF,0x1)

[Bug rtl-optimization/95102] missed if-conversion

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95102

--- Comment #1 from Richard Biener  ---
OK, so one reason is that

  if (!can_conditionally_move_p (x_mode))
return FALSE;

returns false for E_V4SFmode on x86.  min/max detection is based
on fp_cmov expansion for scalar FP on x86 though (with its own
problems, see PR95083).

[RFC PATCH v2] cgraph support for late declare variant resolution

[Jakub Jelinek via Gcc-patches]

Hi!

This is a new version of the
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg01493.html
patch.  Unlike the previous version, this one actually works properly
except for LTO, bootstrapped/regtested on x86_64-linux and i686-linux
too.

In short, #pragma omp declare variant is a directive which allows
redirection of direct calls to certain function to other calls with a
scoring system and some of those decisions need to be deferred until after
IPA.  The patch represents them with calls to an artificial FUNCTION_DECL
with declare_variant_alt in the cgraph_node set.

Honza/Martin, are the cgraph related changes acceptable to you?

For LTO, the patch only saves/restores the two cgraph_node bits added in the
patch, but doesn't yet stream out and back in the on the side info for the
declare_variant_alt.  For the LTO partitioning, I believe those artificial
FUNCTION_DECLs with declare_variant_alt need to go into partition together
with anything that calls them (possibly duplicated), any way how to achieve
that?  Say if declare variant artificial fn foobar is directly
called from all of foo, bar and baz and not from qux and we want 4
partitions, one for each of foo, bar, baz, qux, then foobar is needed in the
first 3 partitions, and the IPA_REF_ADDRs recorded for foobar that right
after IPA the foobar call will be replaced with calls to foobar1, foobar2,
foobar3 or foobar (non-artificial) can of course stay in different
partitions if needed.

2020-05-13  Jakub Jelinek  

* Makefile.in (GTFILES): Add omp-general.c.
* cgraph.h (struct cgraph_node): Add declare_variant_alt and
calls_declare_variant_alt members and initialize them in the
ctor.
* ipa.c (symbol_table::remove_unreachable_nodes): Handle direct
calls to declare_variant_alt nodes.
* lto-cgraph.c (lto_output_node): Write declare_variant_alt
and calls_declare_variant_alt.
(input_overwrite_node): Read them back.
* omp-simd-clone.c (simd_clone_create): Copy calls_declare_variant_alt
bit.
* tree-inline.c (expand_call_inline): Or in calls_declare_variant_alt
bit.
(tree_function_versioning): Copy calls_declare_variant_alt bit.
* omp-offload.c (execute_omp_device_lower): Call
omp_resolve_declare_variant on direct function calls.
(pass_omp_device_lower::gate): Also enable for
calls_declare_variant_alt functions.
* omp-general.c (omp_maybe_offloaded): Return false after inlining.
(omp_context_selector_matches): Handle the case when
cfun->curr_properties has PROP_gimple_any bit set.
(struct omp_declare_variant_entry): New type.
(struct omp_declare_variant_base_entry): New type.
(struct omp_declare_variant_hasher): New type. 
(omp_declare_variant_hasher::hash, omp_declare_variant_hasher::equal):
New methods.
(omp_declare_variants): New variable.
(struct omp_declare_variant_alt_hasher): New type.
(omp_declare_variant_alt_hasher::hash,
omp_declare_variant_alt_hasher::equal): New methods.
(omp_declare_variant_alt): New variables.
(omp_resolve_late_declare_variant): New function.
(omp_resolve_declare_variant): Call omp_resolve_late_declare_variant
when called late.  Create a magic declare_variant_alt fndecl and
cgraph node and return that if decision needs to be deferred until
after gimplification.
* cgraph.c (symbol_table::create_edge): Or in calls_declare_variant_alt
bit.

* c-c++-common/gomp/declare-variant-14.c: New test.

--- gcc/Makefile.in.jj  2020-05-12 21:20:52.701547377 +0200
+++ gcc/Makefile.in 2020-05-13 11:34:54.869947514 +0200
@@ -2616,6 +2616,7 @@ GTFILES = $(CPPLIB_H) $(srcdir)/input.h
   $(srcdir)/omp-offload.h \
   $(srcdir)/omp-offload.c \
   $(srcdir)/omp-expand.c \
+  $(srcdir)/omp-general.c \
   $(srcdir)/omp-low.c \
   $(srcdir)/targhooks.c $(out_file) $(srcdir)/passes.c $(srcdir)/cgraphunit.c \
   $(srcdir)/cgraphclones.c \
--- gcc/cgraph.h.jj 2020-05-12 21:20:47.433626426 +0200
+++ gcc/cgraph.h2020-05-13 11:34:54.870947499 +0200
@@ -937,7 +937,8 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cg
   split_part (false), indirect_call_target (false), local (false),
   versionable (false), can_change_signature (false),
   redefined_extern_inline (false), tm_may_enter_irr (false),
-  ipcp_clone (false), m_uid (uid), m_summary_id (-1)
+  ipcp_clone (false), declare_variant_alt (false),
+  calls_declare_variant_alt (false), m_uid (uid), m_summary_id (-1)
   {}
 
   /* Remove the node from cgraph and all inline clones inlined into it.
@@ -1539,6 +1540,11 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cg
   unsigned tm_may_enter_irr : 1;
   /* True if this was a clone created by ipa-cp.  */
   unsigned ipcp_clone : 1;
+  /* True if this is the deferred declare variant resolution artificial
+ function.  */
+  

RE: [GCC][PATCH][ARM]: Fix the wrong code-gen generated by MVE vector load/store intrinsics (PR94959).

[Srinath Parvathaneni]

Hi,

> -Original Message-
> From: Christophe Lyon 
> Sent: 13 May 2020 11:20
> To: Srinath Parvathaneni 
> Cc: gcc Patches ; Richard Earnshaw
> 
> Subject: Re: [GCC][PATCH][ARM]: Fix the wrong code-gen generated by MVE
> vector load/store intrinsics (PR94959).
> 
> Hi,
> 
> 
> On Wed, 13 May 2020 at 11:47, Srinath Parvathaneni
>  wrote:
> >
> > Hello,
> >
> > Few MVE intrinsics like vldrbq_s32, vldrhq_s32 etc., the assembler
> instructions generated by current compiler are wrong.
> > eg: vldrbq_s32 generates an assembly instructions `vldrb.s32 q0,[ip]`.
> > But as per Arm-arm second argument in above instructions must also be a
> low register (<= r7).
> 
> How did you catch this? Does gas complain?

This was caught by running CMSIS-DSP testsuite and yes gas was complaining.

> 
> If so, then do the existing tests pass (I mean before your patch)?

All the existing tests are passing because the instructions generated in this 
tests always
has the low registers ( <=R7) for second argument and that is because these 
tests are
simple intrinsics calls.
But modifying the testcase as mentioned in PR94959, surfaced the problem fixed 
by this patch.

> 
> > This patch fixes this issue by creating a new predicate
> "mve_memory_operand" and constraint "Ux" which allows low registers
> > as arguments to the generated instructions depending on the mode of the
> argument.
> > A new constraint "Ul" is created to handle loading to PC-relative addressing
> modes for vector store/load intrinsiscs.
> >
> > All the corresponding MVE intrinsic generating wrong code-gen as
> vldrbq_s32 are modified in this patch.
> >
> >
> > Please refer to M-profile Vector Extension (MVE) intrinsics [1] and Armv8-
> M Architecture Reference Manual [2] for more details.
> > [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
> > [2] https://developer.arm.com/docs/ddi0553/latest
> >
> > Regression tested on arm-none-eabi and found no regressions.
> >
> > Ok for trunk? If ok, can I also back-port this patch to GCC-10 branch?
> >
> > Thanks,
> > Srinath.
> >
> > gcc/ChangeLog:
> >
> > 2020-05-13  Srinath Parvathaneni  
> > Andre Vieira  
> >
> > PR target/94959
> > * config/arm/arm-protos.h (arm_mode_base_reg_class): Function
> > declaration.
> > (mve_vector_mem_operand): Likewise.
> > * config/arm/arm.c (thumb2_legitimate_address_p): For MVE target
> check
> > the load from memory to a core register is legitimate for give mode.
> > (mve_vector_mem_operand): Define function.
> > (arm_print_operand): Modify comment.
> > (arm_mode_base_reg_class): Define.
> > * config/arm/arm.h (MODE_BASE_REG_CLASS): Modify to add check
> for
> > TARGET_HAVE_MVE and expand to arm_mode_base_reg_class on
> TRUE.
> > * config/arm/constraints.md (Ux): Likewise.
> > (Ul): Likewise.
> > * config/arm/mve.md (mve_mov): Replace constraint Us with Ux and
> also
> > add support for missing Vector Store Register and Vector Load 
> > Register.
> > Add a new alternative to support load from memory to PC (or label) 
> > in
> > vector store/load.
> > (mve_vstrbq_): Modify constraint Us to Ux.
> > (mve_vldrbq_): Modify constriant Us to Ux, predicate to
> > mve_memory_operand and also modify the MVE instructions to emit.
> > (mve_vldrbq_z_): Modify constraint Us to Ux.
> > (mve_vldrhq_fv8hf): Modify constriant Us to Ux, predicate to
> > mve_memory_operand and also modify the MVE instructions to emit.
> > (mve_vldrhq_): Modify constriant Us to Ux, predicate to
> > mve_memory_operand and also modify the MVE instructions to emit.
> > (mve_vldrhq_z_fv8hf): Likewise.
> > (mve_vldrhq_z_): Likewise.
> > (mve_vldrwq_fv4sf): Likewise.
> > (mve_vldrwq_v4si): Likewise.
> > (mve_vldrwq_z_fv4sf): Likewise.
> > (mve_vldrwq_z_v4si): Likewise.
> > (mve_vld1q_f): Modify constriant Us to Ux.
> > (mve_vld1q_): Likewise.
> > (mve_vstrhq_fv8hf): Modify constriant Us to Ux, predicate to
> > mve_memory_operand.
> > (mve_vstrhq_p_fv8hf): Modify constriant Us to Ux, predicate to
> > mve_memory_operand and also modify the MVE instructions to emit.
> > (mve_vstrhq_p_): Likewise.
> > (mve_vstrhq_): Modify constriant Us to Ux, predicate to
> > mve_memory_operand.
> > (mve_vstrwq_fv4sf): Modify constriant Us to Ux.
> > (mve_vstrwq_p_fv4sf): Modify constriant Us to Ux and also modify the
> MVE
> > instructions to emit.
> > (mve_vstrwq_p_v4si): Likewise.
> > (mve_vstrwq_v4si): Likewise.Modify constriant Us to Ux.
> > * config/arm/predicates.md (mve_memory_operand): Define.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2020-05-13  Srinath Parvathaneni  
> >
> > PR target/94959
> > 

[PATCH] Remove SLP_INSTANCE_GROUP_SIZE

[Richard Biener]

This removes the SLP_INSTANCE_GROUP_SIZE member since the number of
lanes throughout a SLP subgraph is not necessarily constant.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2020-05-13  Richard Biener  

* tree-vectorizer.h (SLP_INSTANCE_GROUP_SIZE): Remove.
(_slp_instance::group_size): Likewise.
* tree-vect-loop.c (vectorizable_reduction): The group size
is the number of lanes in the node.
* tree-vect-slp.c (vect_attempt_slp_rearrange_stmts): Likewise.
(vect_analyze_slp_instance): Do not set SLP_INSTANCE_GROUP_SIZE,
verify it matches the instance trees number of lanes.
(vect_slp_analyze_node_operations_1): Use the numer of lanes
in the node as group size.
(vect_bb_vectorization_profitable_p): Use the instance root
number of lanes for the size of life.
(vect_schedule_slp_instance): Use the number of lanes as
group_size.
* tree-vect-stmts.c (vectorizable_load): Remove SLP instance
parameter.  Use the number of lanes of the load for the group
size in the gap adjustment code.
(vect_analyze_stmt): Adjust.
(vect_transform_stmt): Likewise.
---
 gcc/tree-vect-loop.c  |  2 +-
 gcc/tree-vect-slp.c   | 28 +---
 gcc/tree-vect-stmts.c | 13 ++---
 gcc/tree-vectorizer.h |  8 
 4 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 180790abf42..a1f52dcc2ad 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -6574,7 +6574,7 @@ vectorizable_reduction (loop_vec_info loop_vinfo,
 which each SLP statement has its own initial value and in which
 that value needs to be repeated for every instance of the
 statement within the initial vector.  */
-  unsigned int group_size = SLP_INSTANCE_GROUP_SIZE (slp_node_instance);
+  unsigned int group_size = SLP_TREE_SCALAR_STMTS (slp_node).length ();
   if (!neutral_op
  && !can_duplicate_and_interleave_p (loop_vinfo, group_size,
  TREE_TYPE (vectype_out)))
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index f9ad0821fa0..6f623955ce5 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1810,7 +1810,6 @@ vect_slp_rearrange_stmts (slp_tree node, unsigned int 
group_size,
 static bool
 vect_attempt_slp_rearrange_stmts (slp_instance slp_instn)
 {
-  unsigned int group_size = SLP_INSTANCE_GROUP_SIZE (slp_instn);
   unsigned int i, j;
   unsigned int lidx;
   slp_tree node, load;
@@ -1821,14 +1820,16 @@ vect_attempt_slp_rearrange_stmts (slp_instance 
slp_instn)
   /* Compare all the permutation sequences to the first one.  We know
  that at least one load is permuted.  */
   node = SLP_INSTANCE_LOADS (slp_instn)[0];
-  if (!node->load_permutation.exists ())
+  if (!SLP_TREE_LOAD_PERMUTATION (node).exists ())
 return false;
+  unsigned int group_size = SLP_TREE_LOAD_PERMUTATION (node).length ();
   for (i = 1; SLP_INSTANCE_LOADS (slp_instn).iterate (i, ); ++i)
 {
-  if (!load->load_permutation.exists ())
+  if (!SLP_TREE_LOAD_PERMUTATION (load).exists ()
+ || SLP_TREE_LOAD_PERMUTATION (load).length () != group_size)
return false;
-  FOR_EACH_VEC_ELT (load->load_permutation, j, lidx)
-   if (lidx != node->load_permutation[j])
+  FOR_EACH_VEC_ELT (SLP_TREE_LOAD_PERMUTATION (load), j, lidx)
+   if (lidx != SLP_TREE_LOAD_PERMUTATION (node)[j])
  return false;
 }
 
@@ -2151,7 +2152,6 @@ vect_analyze_slp_instance (vec_info *vinfo,
  /* Create a new SLP instance.  */
  new_instance = XNEW (class _slp_instance);
  SLP_INSTANCE_TREE (new_instance) = node;
- SLP_INSTANCE_GROUP_SIZE (new_instance) = group_size;
  SLP_INSTANCE_UNROLLING_FACTOR (new_instance) = unrolling_factor;
  SLP_INSTANCE_LOADS (new_instance) = vNULL;
  SLP_INSTANCE_ROOT_STMT (new_instance) = constructor ? stmt_info : 
NULL;
@@ -2240,6 +2240,12 @@ vect_analyze_slp_instance (vec_info *vinfo,
 
  vinfo->slp_instances.safe_push (new_instance);
 
+ /* ???  We've replaced the old SLP_INSTANCE_GROUP_SIZE with
+the number of scalar stmts in the root in a few places.
+Verify that assumption holds.  */
+ gcc_assert (SLP_TREE_SCALAR_STMTS (SLP_INSTANCE_TREE (new_instance))
+   .length () == group_size);
+
  if (dump_enabled_p ())
{
  dump_printf_loc (MSG_NOTE, vect_location,
@@ -2670,7 +2676,7 @@ vect_slp_analyze_node_operations_1 (vec_info *vinfo, 
slp_tree node,
vf = loop_vinfo->vectorization_factor;
   else
vf = 1;
-  unsigned int group_size = SLP_INSTANCE_GROUP_SIZE (node_instance);
+  unsigned int group_size = SLP_TREE_SCALAR_STMTS (node).length ();
   tree vectype = STMT_VINFO_VECTYPE (stmt_info);
   

Re: [GCC][PATCH][ARM]: Fix the wrong code-gen generated by MVE vector load/store intrinsics (PR94959).

[Christophe Lyon via Gcc-patches]

On Wed, 13 May 2020 at 13:45, Srinath Parvathaneni
 wrote:
>
> Hi,
>
> > -Original Message-
> > From: Christophe Lyon 
> > Sent: 13 May 2020 11:20
> > To: Srinath Parvathaneni 
> > Cc: gcc Patches ; Richard Earnshaw
> > 
> > Subject: Re: [GCC][PATCH][ARM]: Fix the wrong code-gen generated by MVE
> > vector load/store intrinsics (PR94959).
> >
> > Hi,
> >
> >
> > On Wed, 13 May 2020 at 11:47, Srinath Parvathaneni
> >  wrote:
> > >
> > > Hello,
> > >
> > > Few MVE intrinsics like vldrbq_s32, vldrhq_s32 etc., the assembler
> > instructions generated by current compiler are wrong.
> > > eg: vldrbq_s32 generates an assembly instructions `vldrb.s32 q0,[ip]`.
> > > But as per Arm-arm second argument in above instructions must also be a
> > low register (<= r7).
> >
> > How did you catch this? Does gas complain?
>
> This was caught by running CMSIS-DSP testsuite and yes gas was complaining.
>
> >
> > If so, then do the existing tests pass (I mean before your patch)?
>
> All the existing tests are passing because the instructions generated in this 
> tests always
> has the low registers ( <=R7) for second argument and that is because these 
> tests are
> simple intrinsics calls.
> But modifying the testcase as mentioned in PR94959, surfaced the problem 
> fixed by this patch.

Thanks for the clarification.

But after a quick look it seems your patch does not modify the code in
the tests, only the scan-assembler directives.
Don't you need to modify the actual test code, such that they fail
without your fix?


>
> >
> > > This patch fixes this issue by creating a new predicate
> > "mve_memory_operand" and constraint "Ux" which allows low registers
> > > as arguments to the generated instructions depending on the mode of the
> > argument.
> > > A new constraint "Ul" is created to handle loading to PC-relative 
> > > addressing
> > modes for vector store/load intrinsiscs.
> > >
> > > All the corresponding MVE intrinsic generating wrong code-gen as
> > vldrbq_s32 are modified in this patch.
> > >
> > >
> > > Please refer to M-profile Vector Extension (MVE) intrinsics [1] and Armv8-
> > M Architecture Reference Manual [2] for more details.
> > > [1] https://developer.arm.com/architectures/instruction-sets/simd-
> > isas/helium/mve-intrinsics
> > > [2] https://developer.arm.com/docs/ddi0553/latest
> > >
> > > Regression tested on arm-none-eabi and found no regressions.
> > >
> > > Ok for trunk? If ok, can I also back-port this patch to GCC-10 branch?
> > >
> > > Thanks,
> > > Srinath.
> > >
> > > gcc/ChangeLog:
> > >
> > > 2020-05-13  Srinath Parvathaneni  
> > > Andre Vieira  
> > >
> > > PR target/94959
> > > * config/arm/arm-protos.h (arm_mode_base_reg_class): Function
> > > declaration.
> > > (mve_vector_mem_operand): Likewise.
> > > * config/arm/arm.c (thumb2_legitimate_address_p): For MVE target
> > check
> > > the load from memory to a core register is legitimate for give 
> > > mode.
> > > (mve_vector_mem_operand): Define function.
> > > (arm_print_operand): Modify comment.
> > > (arm_mode_base_reg_class): Define.
> > > * config/arm/arm.h (MODE_BASE_REG_CLASS): Modify to add check
> > for
> > > TARGET_HAVE_MVE and expand to arm_mode_base_reg_class on
> > TRUE.
> > > * config/arm/constraints.md (Ux): Likewise.
> > > (Ul): Likewise.
> > > * config/arm/mve.md (mve_mov): Replace constraint Us with Ux and
> > also
> > > add support for missing Vector Store Register and Vector Load 
> > > Register.
> > > Add a new alternative to support load from memory to PC (or 
> > > label) in
> > > vector store/load.
> > > (mve_vstrbq_): Modify constraint Us to Ux.
> > > (mve_vldrbq_): Modify constriant Us to Ux, predicate 
> > > to
> > > mve_memory_operand and also modify the MVE instructions to emit.
> > > (mve_vldrbq_z_): Modify constraint Us to Ux.
> > > (mve_vldrhq_fv8hf): Modify constriant Us to Ux, predicate to
> > > mve_memory_operand and also modify the MVE instructions to emit.
> > > (mve_vldrhq_): Modify constriant Us to Ux, predicate 
> > > to
> > > mve_memory_operand and also modify the MVE instructions to emit.
> > > (mve_vldrhq_z_fv8hf): Likewise.
> > > (mve_vldrhq_z_): Likewise.
> > > (mve_vldrwq_fv4sf): Likewise.
> > > (mve_vldrwq_v4si): Likewise.
> > > (mve_vldrwq_z_fv4sf): Likewise.
> > > (mve_vldrwq_z_v4si): Likewise.
> > > (mve_vld1q_f): Modify constriant Us to Ux.
> > > (mve_vld1q_): Likewise.
> > > (mve_vstrhq_fv8hf): Modify constriant Us to Ux, predicate to
> > > mve_memory_operand.
> > > (mve_vstrhq_p_fv8hf): Modify constriant Us to Ux, predicate to
> > > mve_memory_operand and also modify the MVE instructions to emit.
> > > (mve_vstrhq_p_): Likewise.
> > > (mve_vstrhq_): Modify 

Re: [PR 95013] EOF location is at end of file

[Nathan Sidwell]

On 5/13/20 2:44 AM, Christophe Lyon wrote:

On Wed, 13 May 2020 at 02:24, H.J. Lu via Gcc-patches



 [PR 95013] Fix gcc.dg/unclosed-init.c

 2020-05-13  Christophe Lyon  

 PR preprocessor/95013
 * gcc.dg/unclosed-init.c: Add missing comment in dg-error.


Thanks for beating me to it.

nathan

--
Nathan Sidwell

[Bug target/95099] Build a cross compiler for m32c on Windows (Cygwin)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95099

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 83670.

*** This bug has been marked as a duplicate of bug 83670 ***

[Bug target/83670] [8/9/10/11 Regression] m32c ICE in leaf_function_p, at final.c:4368

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
Summary|m32c ICE in |[8/9/10/11 Regression] m32c
   |leaf_function_p, at |ICE in leaf_function_p, at
   |final.c:4368|final.c:4368

[Bug target/83670] m32c ICE in leaf_function_p, at final.c:4368

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670

Andrew Pinski  changed:

   What|Removed |Added

 CC||dj_adilovic at hotmail dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 95099 has been marked as a duplicate of this bug. ***

Re: ChangeLog files - server and client scripts

[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

[Bug middle-end/95052] [9/10/11 Regression] Excess padding of partially initialized strings/char arrays

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95052

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
Summary|Excess padding of partially |[9/10/11 Regression] Excess
   |initialized strings/char|padding of partially
   |arrays  |initialized strings/char
   ||arrays

[Bug tree-optimization/95034] Failure to convert xor pattern (made out of or+and) to xor

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95034

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[PATCH] Add default revisions argument for git_check_commit.py.

[Martin Liška]

A small tweak to the script that I'm going to install.

Martin

contrib/ChangeLog:

2020-05-13  Martin Liska  

* gcc-changelog/git_check_commit.py: Add default argument HEAD
for revisions and improve error message output.
---
 contrib/gcc-changelog/git_check_commit.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


diff --git a/contrib/gcc-changelog/git_check_commit.py b/contrib/gcc-changelog/git_check_commit.py
index b2d1d08a242..8553c90a96f 100755
--- a/contrib/gcc-changelog/git_check_commit.py
+++ b/contrib/gcc-changelog/git_check_commit.py
@@ -22,7 +22,7 @@ from git_repository import parse_git_revisions
 
 parser = argparse.ArgumentParser(description='Check git ChangeLog format '
  'of a commit')
-parser.add_argument('revisions',
+parser.add_argument('revisions', default='HEAD', nargs='?',
 help='Git revisions (e.g. hash~5..hash or just hash)')
 parser.add_argument('-g', '--git-path', default='.',
 help='Path to git repository')
@@ -36,9 +36,9 @@ 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)
+res = 'OK' if git_commit.success else 'FAILED'
+print('Checking %s: %s' % (git_commit.hexsha, res))
 if git_commit.success:
-print('OK')
 if args.print_changelog:
 git_commit.print_output()
 else:

[Bug fortran/95104] Segfault on a legal WAIT statement

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104

--- Comment #1 from Bill Long  ---
The program appears to be legal and should execute and print 0.  

The last paragraph of 12.7.2 WAIT statement (current Fortran standard) is


Execution of a WAIT statement specifying a unit that does not exist, has no
file connected to it, or is not open for asynchronous input/output is
permitted, provided that the WAIT statement has no ID= specifier; such a WAIT
statement does not cause an error or end-of-file condition to occur.

[Bug fortran/91731] Configure error on building MPICH

[keroro.90 at hotmail dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731

keroro.90 at hotmail dot it changed:

   What|Removed |Added

 CC||keroro.90 at hotmail dot it

--- Comment #8 from keroro.90 at hotmail dot it ---
Steve workaround also worked for me (Fedora 32 + MPICH).
I just had to replace setenv with export as follows:
export PATH="~/work/x/bin:$PATH"   
export FFLAGS="-w -fallow-argument-mismatch -O2"

Hope this helps.

Re: [PATCH PR94969]Add unit distant vector to DDR in case of invariant access functions

[Christophe Lyon via Gcc-patches]

Hi Bin,


On Mon, 11 May 2020 at 14:54, Richard Biener via Gcc-patches
 wrote:
>
> On Mon, May 11, 2020 at 7:52 AM bin.cheng via Gcc-patches
>  wrote:
> >
> > Hi,
> > As analyzed in PR94969, data dependence analysis now misses dependence 
> > vector for specific case in which DRs in DDR have the same invariant access 
> > functions.  This simple patch fixes the issue by also covering invariant 
> > cases.  Bootstrap and test on x86_64, is it OK?
>
> OK.
>
> Thanks,
> Richard.
>
> > Thanks,
> > bin
> >
> > 2020-05-11  Bin Cheng  
> >
> > PR tree-optimization/94969
> > * tree-data-dependence.c (constant_access_functions): Rename to...
> > (invariant_access_functions): ...this.  Add parameter.  Check for
> > invariant access function, rather than constant.
> > (build_classic_dist_vector): Call above function.
> > * tree-loop-distribution.c (pg_add_dependence_edges): Add comment.
> >
> > gcc/testsuite
> > 2020-05-11  Bin Cheng  
> >
> > PR tree-optimization/94969
> > * gcc.dg/tree-ssa/pr94969.c: New test.

The new test fails on arm and aarch64 and probably everywhere:
gcc.dg/tree-ssa/pr94969.c: dump file does not exist
UNRESOLVED: gcc.dg/tree-ssa/pr94969.c scan-tree-dump-not Loop 1
distributed: split to 3 loops "ldist"

Can you fix this?

Thanks

Re: [PATCH] x86: Properly count cost of XMM register push

[Uros Bizjak via Gcc-patches]

On Wed, May 13, 2020 at 1:05 PM Uros Bizjak  wrote:
>
> On Tue, May 12, 2020 at 10:07 PM H.J. Lu  wrote:
> >
> > Update STV pass to properly count cost of XMM register push.  In 32-bit
> > mode, to convert XMM register push in DImode, we do an XMM store in
> > DImode, followed by 2 memory pushes in SImode, instead of 2 integer
> > register pushes in SImode.  To convert XM register push in SImode, we
> > do an XMM register to integer register move in SImode, followed an
> > integer register push in SImode, instead of an integer register push in
> > SImode.  In 64-bit mode, we do an XMM register to integer register move
> > in SImode or DImode, followed an integer register push in SImode or
> > DImode, instead of an integer register push SImode or DImode.
> >
> > Tested on Linux/x86 and Linux/x86-64.
>
> I think it is better to implement XMM register pushes, and split them
> after reload to a sequence of:
>
> (set (reg:P SP_REG) (plus:P SP_REG) (const_int -8)))
> (set (match_dup 0) (match_dup 1))
>
> This is definitely better than trips through memory to stack.

Attached (untested patch) allows fake pushes from XMM registers, so
STV pass can allow pushes.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 722eb9b5ec8..9f741ce7602 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1049,6 +1049,9 @@
 ;; SWI and DWI together.
 (define_mode_iterator SWIDWI [QI HI SI DI (TI "TARGET_64BIT")])
 
+;; SWI48 and DWI together.
+(define_mode_iterator SWI48DWI [SI DI (TI "TARGET_64BIT")])
+
 ;; GET_MODE_SIZE for selected modes.  As GET_MODE_SIZE is not
 ;; compile time constant, it is faster to use  than
 ;; GET_MODE_SIZE (mode).  For XFmode which depends on
@@ -1670,8 +1673,8 @@
 ;; Push/pop instructions.
 
 (define_insn "*push2"
-  [(set (match_operand:DWI 0 "push_operand" "=<")
-   (match_operand:DWI 1 "general_no_elim_operand" "riF*o"))]
+  [(set (match_operand:DWI 0 "push_operand" "=<,<")
+   (match_operand:DWI 1 "general_no_elim_operand" "riF*o,v"))]
   ""
   "#"
   [(set_attr "type" "multi")
@@ -1685,13 +1688,14 @@
   "ix86_split_long_move (operands); DONE;")
 
 (define_insn "*pushdi2_rex64"
-  [(set (match_operand:DI 0 "push_operand" "=<,!<")
-   (match_operand:DI 1 "general_no_elim_operand" "re*m,n"))]
+  [(set (match_operand:DI 0 "push_operand" "=<,<,!<")
+   (match_operand:DI 1 "general_no_elim_operand" "re*m,v,n"))]
   "TARGET_64BIT"
   "@
push{q}\t%1
+   #
#"
-  [(set_attr "type" "push,multi")
+  [(set_attr "type" "push,multi,multi")
(set_attr "mode" "DI")])
 
 ;; Convert impossible pushes of immediate to existing instructions.
@@ -1726,11 +1730,13 @@
 })
 
 (define_insn "*pushsi2"
-  [(set (match_operand:SI 0 "push_operand" "=<")
-   (match_operand:SI 1 "general_no_elim_operand" "ri*m"))]
+  [(set (match_operand:SI 0 "push_operand" "=<,<")
+   (match_operand:SI 1 "general_no_elim_operand" "ri*m,v"))]
   "!TARGET_64BIT"
-  "push{l}\t%1"
-  [(set_attr "type" "push")
+  "@
+   push{l}\t%1
+   #"
+  [(set_attr "type" "push,multi")
(set_attr "mode" "SI")])
 
 ;; emit_push_insn when it calls move_by_pieces requires an insn to
@@ -1739,11 +1745,13 @@
 
 ;; For TARGET_64BIT we always round up to 8 bytes.
 (define_insn "*push2_rex64"
-  [(set (match_operand:SWI124 0 "push_operand" "=X")
-   (match_operand:SWI124 1 "nonmemory_no_elim_operand" "r"))]
+  [(set (match_operand:SWI124 0 "push_operand" "=X,X")
+   (match_operand:SWI124 1 "nonmemory_no_elim_operand" "r,v"))]
   "TARGET_64BIT"
-  "push{q}\t%q1"
-  [(set_attr "type" "push")
+  "@
+   push{q}\t%q1
+   #"
+  [(set_attr "type" "push,multi")
(set_attr "mode" "DI")])
 
 (define_insn "*push2"
@@ -1754,6 +1762,18 @@
   [(set_attr "type" "push")
(set_attr "mode" "SI")])
 
+(define_split
+  [(set (match_operand:SWI48DWI 0 "push_operand")
+   (match_operand:SWI48DWI 1 "sse_reg_operand"))]
+  "TARGET_SSE && reload_completed"
+  [(set (reg:P SP_REG) (plus:P (reg:P SP_REG) (match_dup 2)))
+(set (match_dup 0) (match_dup 1))]
+{
+  operands[2] = GEN_INT (-PUSH_ROUNDING (GET_MODE_SIZE (mode)));
+  /* Preserve memory attributes. */
+  operands[0] = replace_equiv_address (operands[0], stack_pointer_rtx);
+})
+
 (define_insn "*push2_prologue"
   [(set (match_operand:W 0 "push_operand" "=<")
(match_operand:W 1 "general_no_elim_operand" "r*m"))

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

[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

[Bug c++/95103] New: Unexpected -Wclobbered in bits/vector.tcc with -O2

[sbergman at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95103

Bug ID: 95103
   Summary: Unexpected -Wclobbered in bits/vector.tcc with -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I have seen this with at least some GCC 7, and still see it with GCC 10 and
with recent trunk:

> $ cat test.cc
> #include 
> #include 
> struct S {
> S(int);
> ~S();
> };
> void f1();
> bool f2(char const (& s)[3]) {
> for (int i = 0; i != 2; ++i) {
> if (s[i] != 'x') {
> return false;
> }
> }
> return true;
> }
> void f3() {
> std::vector v;
> for (int i = 0; i != 2; ++i) {
> if (!f2("xx")) f1();
> v.push_back(0);
> }
> std::jmp_buf b;
> setjmp(b);
> }

> $ g++ -Wclobbered -O2 -c test.cc
> In file included from /usr/include/c++/10/vector:72,
>  from test.cc:2:
> /usr/include/c++/10/bits/vector.tcc: In function ‘void f3()’:
> /usr/include/c++/10/bits/vector.tcc:441:15: warning: variable ‘__new_finish’ 
> might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
>   441 |   pointer __new_finish(__new_start);
>   |   ^~~~

Re: [PATCH] x86: Properly count cost of XMM register push

[H.J. Lu via Gcc-patches]

On Wed, May 13, 2020 at 5:04 AM Uros Bizjak  wrote:
>
> On Wed, May 13, 2020 at 1:05 PM Uros Bizjak  wrote:
> >
> > On Tue, May 12, 2020 at 10:07 PM H.J. Lu  wrote:
> > >
> > > Update STV pass to properly count cost of XMM register push.  In 32-bit
> > > mode, to convert XMM register push in DImode, we do an XMM store in
> > > DImode, followed by 2 memory pushes in SImode, instead of 2 integer
> > > register pushes in SImode.  To convert XM register push in SImode, we
> > > do an XMM register to integer register move in SImode, followed an
> > > integer register push in SImode, instead of an integer register push in
> > > SImode.  In 64-bit mode, we do an XMM register to integer register move
> > > in SImode or DImode, followed an integer register push in SImode or
> > > DImode, instead of an integer register push SImode or DImode.
> > >
> > > Tested on Linux/x86 and Linux/x86-64.
> >
> > I think it is better to implement XMM register pushes, and split them
> > after reload to a sequence of:
> >
> > (set (reg:P SP_REG) (plus:P SP_REG) (const_int -8)))
> > (set (match_dup 0) (match_dup 1))
> >
> > This is definitely better than trips through memory to stack.
>
> Attached (untested patch) allows fake pushes from XMM registers, so
> STV pass can allow pushes.

The problem isn't STV pass.  The IRA pass won't assign hard register for

(insn 28 27 29 3 (set (mem:DI (pre_dec:SI (reg/f:SI 7 sp)) [2  S8 A64])
(reg/v:DI 85 [ target ])) "x.i":19:5 40 {*pushdi2}
 (expr_list:REG_DEAD (reg/v:DI 85 [ target ])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil

and the reload pass turns into


(insn 28 27 29 3 (set (mem:DI (pre_dec:SI (reg/f:SI 7 sp)) [2  S8 A64])
(mem/c:DI (plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])) [8 %sfp+-8 S8 A64])) "x.i":19:5
40 {*pushdi2}
 (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))

-- 
H.J.

[Bug fortran/95104] New: Segfault on a legal WAIT statement

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104

Bug ID: 95104
   Summary: Segfault on a legal WAIT statement
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
  program test
  wait (10, iostat=ios)
  print *, ios
  close (10)
  end program test


> gfortran test.f90
> ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f3f0334159f in ???
#1  0x4007f6 in ???
#2  0x4008c7 in ???
#3  0x7f3f0332c349 in ???
#4  0x4006f9 in ???
at ../sysdeps/x86_64/start.S:120
#5  0x in ???
Segmentation fault (core dumped)
longb@jupiter:/cray/css/users/longb/spr/jira/22703> gfortran --version
GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[PATCH] add vectype parameter to add_stmt_cost hook

[Richard Biener]

This adds a vectype parameter to add_stmt_cost which avoids the need
to pass down a (wrong) stmt_info just to carry this information.
Useful for invariants which do not have a stmt_info associated.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2020-05-13  Richard Biener  

* target.def (add_stmt_cost): Add new vectype parameter.
* targhooks.c (default_add_stmt_cost): Adjust.
* targhooks.h (default_add_stmt_cost): Likewise.
* config/aarch64/aarch64.c (aarch64_add_stmt_cost): Take new
vectype parameter.
* config/arm/arm.c (arm_add_stmt_cost): Likewise.
* config/i386/i386.c (ix86_add_stmt_cost): Likewise.
* config/rs6000/rs6000.c (rs6000_add_stmt_cost): Likewise.

* tree-vectorizer.h (stmt_info_for_cost::vectype): Add.
(dump_stmt_cost): Add new vectype parameter.
(add_stmt_cost): Likewise.
(record_stmt_cost): Likewise.
(record_stmt_cost): Add overload with old signature.
* tree-vect-loop.c (vect_compute_single_scalar_iteration_cost):
Adjust.
(vect_get_known_peeling_cost): Likewise.
(vect_estimate_min_profitable_iters): Likewise.
* tree-vectorizer.c (dump_stmt_cost): Add new vectype parameter.
* tree-vect-stmts.c (record_stmt_cost): Likewise.
(vect_prologue_cost_for_slp_op): Remove stmt_vec_info parameter
and pass down correct vectype and NULL stmt_info.
(vect_model_simple_cost): Adjust.
(vect_model_store_cost): Likewise.
---
 gcc/config/aarch64/aarch64.c |  5 ++---
 gcc/config/arm/arm.c |  7 +++
 gcc/config/i386/i386.c   |  5 ++---
 gcc/config/rs6000/rs6000.c   |  5 ++---
 gcc/target.def   |  2 +-
 gcc/targhooks.c  |  5 ++---
 gcc/targhooks.h  |  2 +-
 gcc/tree-vect-loop.c | 46 +++-
 gcc/tree-vect-stmts.c| 17 ++--
 gcc/tree-vectorizer.c|  2 +-
 gcc/tree-vectorizer.h| 27 --
 11 files changed, 65 insertions(+), 58 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 434e095cb66..70aa2f752b5 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -13753,15 +13753,14 @@ aarch64_sve_adjust_stmt_cost (class vec_info *vinfo, 
vect_cost_for_stmt kind,
 static unsigned
 aarch64_add_stmt_cost (class vec_info *vinfo, void *data, int count,
   enum vect_cost_for_stmt kind,
-  struct _stmt_vec_info *stmt_info, int misalign,
-  enum vect_cost_model_location where)
+  struct _stmt_vec_info *stmt_info, tree vectype,
+  int misalign, enum vect_cost_model_location where)
 {
   unsigned *cost = (unsigned *) data;
   unsigned retval = 0;
 
   if (flag_vect_cost_model)
 {
-  tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
   int stmt_cost =
aarch64_builtin_vectorization_cost (kind, vectype, misalign);
 
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index d50781953c0..56d6be02996 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -309,7 +309,7 @@ static int arm_builtin_vectorization_cost (enum 
vect_cost_for_stmt type_of_cost,
 static unsigned arm_add_stmt_cost (vec_info *vinfo, void *data, int count,
   enum vect_cost_for_stmt kind,
   struct _stmt_vec_info *stmt_info,
-  int misalign,
+  tree vectype, int misalign,
   enum vect_cost_model_location where);
 
 static void arm_canonicalize_comparison (int *code, rtx *op0, rtx *op1,
@@ -12133,15 +12133,14 @@ arm_builtin_vectorization_cost (enum 
vect_cost_for_stmt type_of_cost,
 static unsigned
 arm_add_stmt_cost (vec_info *vinfo, void *data, int count,
   enum vect_cost_for_stmt kind,
-  struct _stmt_vec_info *stmt_info, int misalign,
-  enum vect_cost_model_location where)
+  struct _stmt_vec_info *stmt_info, tree vectype,
+  int misalign, enum vect_cost_model_location where)
 {
   unsigned *cost = (unsigned *) data;
   unsigned retval = 0;
 
   if (flag_vect_cost_model)
 {
-  tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
   int stmt_cost = arm_builtin_vectorization_cost (kind, vectype, misalign);
 
   /* Statements in an inner loop relative to the loop being
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index f7a4bae49bb..060e2df62ea 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -21886,15 +21886,14 @@ ix86_init_cost (class loop *)
 static unsigned
 ix86_add_stmt_cost (class vec_info *vinfo, void *data, int count,
enum vect_cost_for_stmt kind,
-   

[PATCH] [V2] rs6000: Add vec_extracth and vec_extractl

[Bill Schmidt via Gcc-patches]

From: Kelvin Nilsen 

Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
vextddvhx, along with built-in access and overloaded built-in
access to these insns.

Changes from previous patch:
 * Removed the int iterators
 * Created separate expansions and insns
vextractl
vextractl_internal
vextractr
vextractr_internal
 * Adjusted rs6000-builtin.def entries to match the new expansion
   names

I didn't understand the comment about moving the decision making
part to the built-in handling code.  All the built-in handling
does is a table-driven call to the expansions; this logic *is*
the built-in handling code.  I don't see any way to simplify that.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions, using a Power9 configuration.  Is this okay for
master?

Thanks,
Bill


[gcc]

2020-05-12  Kelvin Nilsen  

* config/rs6000/altivec.h (vec_extractl): New #define.
(vec_extracth): Likewise.
* config/rs6000/altivec.md (UNSPEC_EXTRACTL): New constant.
(UNSPEC_EXTRACTR): Likewise.
(vextractl): New expansion.
(vextractl_internal): New insn.
(vextractr): New expansion.
(vextractr_internal): New insn.
* config/rs6000/rs6000-builtin.def (__builtin_altivec_vextdubvlx):
New built-in function.
(__builtin_altivec_vextduhvlx): Likewise.
(__builtin_altivec_vextduwvlx): Likewise.
(__builtin_altivec_vextddvlx): Likewise.
(__builtin_altivec_vextdubvhx): Likewise.
(__builtin_altivec_vextduhvhx): Likewise.
(__builtin_altivec_vextduwvhx): Likewise.
(__builtin_altivec_vextddvhx): Likewise.
(__builtin_vec_extractl): New overloaded built-in function.
(__builtin_vec_extracth): Likewise.
* config/rs6000/rs6000-call.c (altivec_overloaded_builtins):
Define overloaded forms of __builtin_vec_extractl and
__builtin_vec_extracth.
(builtin_function_type): Add cases to mark arguments of new
built-in functions as unsigned.
(rs6000_common_init_builtins): Add
opaque_ftype_opaque_opaque_opaque_opaque.
* config/rs6000/rs6000.md (du_or_d): New mode attribute.
* doc/extend.texi (PowerPC AltiVec Built-in Functions Available
for a Future Architecture): Add description of vec_extractl and
vec_extractr built-in functions.

[gcc/testsuite]

2020-05-10  Kelvin Nilsen  

* gcc.target/powerpc/vec-extracth-0.c: New.
* gcc.target/powerpc/vec-extracth-1.c: New.
* gcc.target/powerpc/vec-extracth-2.c: New.
* gcc.target/powerpc/vec-extracth-3.c: New.
* gcc.target/powerpc/vec-extracth-4.c: New.
* gcc.target/powerpc/vec-extracth-5.c: New.
* gcc.target/powerpc/vec-extracth-6.c: New.
* gcc.target/powerpc/vec-extracth-7.c: New.
* gcc.target/powerpc/vec-extracth-be-0.c: New.
* gcc.target/powerpc/vec-extracth-be-1.c: New.
* gcc.target/powerpc/vec-extracth-be-2.c: New.
* gcc.target/powerpc/vec-extracth-be-3.c: New.
* gcc.target/powerpc/vec-extractl-0.c: New.
* gcc.target/powerpc/vec-extractl-1.c: New.
* gcc.target/powerpc/vec-extractl-2.c: New.
* gcc.target/powerpc/vec-extractl-3.c: New.
* gcc.target/powerpc/vec-extractl-4.c: New.
* gcc.target/powerpc/vec-extractl-5.c: New.
* gcc.target/powerpc/vec-extractl-6.c: New.
* gcc.target/powerpc/vec-extractl-7.c: New.
* gcc.target/powerpc/vec-extractl-be-0.c: New.
* gcc.target/powerpc/vec-extractl-be-1.c: New.
* gcc.target/powerpc/vec-extractl-be-2.c: New.
* gcc.target/powerpc/vec-extractl-be-3.c: New.
---
 gcc/config/rs6000/altivec.h   |  3 +
 gcc/config/rs6000/altivec.md  | 62 +++
 gcc/config/rs6000/rs6000-builtin.def  | 13 
 gcc/config/rs6000/rs6000-call.c   | 39 +++-
 gcc/config/rs6000/rs6000.md   | 10 +++
 gcc/doc/extend.texi   | 56 +
 .../gcc.target/powerpc/vec-extracth-0.c   | 33 ++
 .../gcc.target/powerpc/vec-extracth-1.c   | 32 ++
 .../gcc.target/powerpc/vec-extracth-2.c   | 31 ++
 .../gcc.target/powerpc/vec-extracth-3.c   | 30 +
 .../gcc.target/powerpc/vec-extracth-4.c   | 31 ++
 .../gcc.target/powerpc/vec-extracth-5.c   | 29 +
 .../gcc.target/powerpc/vec-extracth-6.c   | 31 ++
 .../gcc.target/powerpc/vec-extracth-7.c   | 30 +
 .../gcc.target/powerpc/vec-extracth-be-0.c| 32 ++
 .../gcc.target/powerpc/vec-extracth-be-1.c| 30 +
 .../gcc.target/powerpc/vec-extracth-be-2.c| 30 +
 .../gcc.target/powerpc/vec-extracth-be-3.c| 30 +
 .../gcc.target/powerpc/vec-extractl-0.c   | 33 ++
 .../gcc.target/powerpc/vec-extractl-1.c   | 32 ++
 

Ping: [PATCH] wwwdocs: Add D front-end section for GCC 10 changes

[Iain Buclaw via Gcc-patches]

Ping.

On 07/05/2020 16:04, Iain Buclaw via Gcc-patches wrote:
> Hi,
> 
> Updated the patch to include missed changes, and slighted reworded some 
> entries
> to make them clearer/read easier.
> 
> OK to commit?
> 
> Iain.
> 
> ---
>  htdocs/gcc-10/changes.html | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index 41c2dc0d..f10cfd56 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -432,6 +432,41 @@ a work-in-progress.
>
>  
>  
> +D
> +
> +  Support for static foreach has been implemented.
> +  Aliases can now be created directly from any __trait that
> +  return symbols or tuples.  Previously, an AliasSeq was
> +  necessary in order to alias their return.
> +  
> +  It is now possible to detect the language ABI specified for a struct,
> +  class, or interface using __traits(getLinkage, ...)
> +  Support for core.math.toPrec intrinsics have been added.
> +  These intrinsics guarantee the rounding to specific floating-point
> +  precisions at required points in the code.
> +  
> +  Support for pragma(inline) has been implemented.  
> Previously
> +  the pragma was recognized, but had no effect on the compilation.
> +  
> +  Optional parentheses in asm operands are now deprecated 
> and
> +  will be removed in a future release.
> +  
> +  All content imported files are now included in the make dependency list
> +  when compiling with -M.
> +  
> +  Compiler recognized attributes provided by the 
> gcc.attribute
> +  module will now take effect when applied to function prototypes as well
> +  as when applied to full function declarations.
> +  
> +  Added --enable-libphobos-checking configure option to
> +  control whether run-time checks are compiled into the D runtime 
> library.
> +  
> +  Added --with-libphobos-druntime-only configure option to
> +  allow specifying whether to build only the core D runtime library, or
> +  both the core and standard libraries into libphobos.
> +  
> +
> +
>  Fortran
>  
>use_device_addr of version 5.0 of the
> 

Re: [PATCH] contrib/vimrc: Reduce textwidth for commit messages

[Martin Liška]

On 5/4/20 8:18 PM, Martin Liška wrote:

I support the patch,


And as there's no feedback I also installed the patch.

Martin

libbacktrace patch committed: Mark state unused in ztest.c test_large

[Ian Lance Taylor via Gcc-patches]

This libbacktrace patch marks the state parameter of test_large in
ztest.c as ATTRIBUTE_UNUSED.  The parameter is not used if HAVE_ZLIB
is not defined.  Bootstrapped and ran libbacktrace tests on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian

2020-05-13  Ian Lance Taylor  

* ztest.c (test_large): Mark state ATTRIBUTE_UNUSED.
diff --git a/libbacktrace/ztest.c b/libbacktrace/ztest.c
index 2663c90061a..39476704972 100644
--- a/libbacktrace/ztest.c
+++ b/libbacktrace/ztest.c
@@ -294,7 +294,7 @@ average_time (const size_t *times, size_t trials)
 /* Test a larger text, if available.  */
 
 static void
-test_large (struct backtrace_state *state)
+test_large (struct backtrace_state *state ATTRIBUTE_UNUSED)
 {
 #ifdef HAVE_ZLIB
   unsigned char *orig_buf;

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111

--- Comment #4 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #3)
> The test case I uploaded only shows the failure, it won't work if gcc worked
> as I expect it. I'll try to get a better testcase, unfortunately a small
> coroutine testcase is still some work.

yeah, I have some boiler-plate code in headers in the GCC test-suite that can
help.

[C++] some cleanup patches

[Nathan Sidwell]

I've committed this set of minor cleanups from the modules branch.

nathan
--
Nathan Sidwell
2020-05-13  Nathan Sidwell  

	Formatting fixups & some simplifications.
	* pt.c (spec_hash_table): New typedef.
	(decl_specializations, type_specializations): Use it.
	(retrieve_specialization): Likewise.
	(register_specialization): Remove unnecessary casts.
	(push_template_decl_real): Reformat.
	(instantiate_class_template_1): Use more RAII.
	(make_argument_pack): Simplify.
	(instantiate_template_1): Use gcc_checking_assert for expensive
	asserts.
	(instantiate_decl): Likewise.
	(resolve_typename_type): Reformat comment.
	* semantics.c (struct deferred_access): Remove unnecessary GTY on
	member.
	(begin_class_definition): Fix formatting.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 7911293571e..ff15a926db9 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -48,9 +48,9 @@ along with GCC; see the file COPYING3.  If not see
returning an int.  */
 typedef int (*tree_fn_t) (tree, void*);
 
-/* The PENDING_TEMPLATES is a TREE_LIST of templates whose
-   instantiations have been deferred, either because their definitions
-   were not yet available, or because we were putting off doing the work.  */
+/* The PENDING_TEMPLATES is a list of templates whose instantiations
+   have been deferred, either because their definitions were not yet
+   available, or because we were putting off doing the work.  */
 struct GTY ((chain_next ("%h.next"))) pending_template
 {
   struct pending_template *next;
@@ -116,9 +116,10 @@ struct spec_hasher : ggc_ptr_hash
   static bool equal (spec_entry *, spec_entry *);
 };
 
-static GTY (()) hash_table *decl_specializations;
-
-static GTY (()) hash_table *type_specializations;
+/* The general template is not in these tables.  */
+typedef hash_table spec_hash_table;
+static GTY (()) spec_hash_table *decl_specializations;
+static GTY (()) spec_hash_table *type_specializations;
 
 /* Contains canonical template parameter types. The vector is indexed by
the TEMPLATE_TYPE_IDX of the template parameter. Each element is a
@@ -1278,7 +1279,7 @@ retrieve_specialization (tree tmpl, tree args, hashval_t hash)
 {
   spec_entry *found;
   spec_entry elt;
-  hash_table *specializations;
+  spec_hash_table *specializations;
 
   elt.tmpl = tmpl;
   elt.args = args;
@@ -1573,10 +1574,9 @@ register_specialization (tree spec, tree tmpl, tree args, bool is_friend,
   if (hash == 0)
 	hash = spec_hasher::hash ();
 
-  slot =
-	decl_specializations->find_slot_with_hash (, hash, INSERT);
+  slot = decl_specializations->find_slot_with_hash (, hash, INSERT);
   if (*slot)
-	fn = ((spec_entry *) *slot)->spec;
+	fn = (*slot)->spec;
   else
 	fn = NULL_TREE;
 }
@@ -4474,7 +4466,7 @@ reduce_template_parm_level (tree index, tree type, int levels, tree args,
   TEMPLATE_PARM_PARAMETER_PACK (tpi)
 	= TEMPLATE_PARM_PARAMETER_PACK (index);
 
-	/* Template template parameters need this.  */
+  /* Template template parameters need this.  */
   tree inner = decl;
   if (TREE_CODE (decl) == TEMPLATE_DECL)
 	{
@@ -5705,8 +5697,7 @@ push_template_decl_real (tree decl, bool is_friend)
  template  friend void A::f();
is not primary.  */
 is_primary = false;
-  else if (TREE_CODE (decl) == TYPE_DECL
-	   && LAMBDA_TYPE_P (TREE_TYPE (decl)))
+  else if (TREE_CODE (decl) == TYPE_DECL && LAMBDA_TYPE_P (TREE_TYPE (decl)))
 is_primary = false;
   else
 is_primary = template_parm_scope_p ();
@@ -5845,8 +5836,7 @@ push_template_decl_real (tree decl, bool is_friend)
   if (!ctx
   || TREE_CODE (ctx) == FUNCTION_DECL
   || (CLASS_TYPE_P (ctx) && TYPE_BEING_DEFINED (ctx))
-  || (TREE_CODE (decl) == TYPE_DECL
-	  && LAMBDA_TYPE_P (TREE_TYPE (decl)))
+  || (TREE_CODE (decl) == TYPE_DECL && LAMBDA_TYPE_P (TREE_TYPE (decl)))
   || (is_friend && !DECL_TEMPLATE_INFO (decl)))
 {
   if (DECL_LANG_SPECIFIC (decl)
@@ -11752,13 +11743,10 @@ instantiate_class_template_1 (tree type)
 		continue;
 
 	  /* Build new CLASSTYPE_NESTED_UTDS.  */
+	  bool class_template_p = (TREE_CODE (t) != ENUMERAL_TYPE
+   && TYPE_LANG_SPECIFIC (t)
+   && CLASSTYPE_IS_TEMPLATE (t));
 
-	  tree newtag;
-	  bool class_template_p;
-
-	  class_template_p = (TREE_CODE (t) != ENUMERAL_TYPE
-  && TYPE_LANG_SPECIFIC (t)
-  && CLASSTYPE_IS_TEMPLATE (t));
 	  /* If the member is a class template, then -- even after
 		 substitution -- there may be dependent types in the
 		 template argument list for the class.  We increment
@@ -11767,7 +11755,7 @@ instantiate_class_template_1 (tree type)
 		 when outside of a template.  */
 	  if (class_template_p)
 		++processing_template_decl;
-	  newtag = tsubst (t, args, tf_error, NULL_TREE);
+	  tree newtag = tsubst (t, args, tf_error, NULL_TREE);
 	  if (class_template_p)
 		--processing_template_decl;
 	  if (newtag == error_mark_node)
@@ -11834,6 

[C++] simplify typedef access checking

[Nathan Sidwell]

I discovered template typedef access checking was more expensive than it 
need be.  The call of get_types_needed_access_check in the 
FOR_EACH_VEC_SAFE_ELT is the moral equivalent of


  for (size_t pos = 0; pos != strlen (string); pos++)'

Let's not do that.

nathan

--
Nathan Sidwell
2020-05-13  Nathan Sidwell  

	* pt.c (perform_typedefs_access_check): Cache expensively
	calculated object references.
	(check_auto_in_tmpl_args): Just assert we do not get unexpected
	nodes, rather than silently do nothing.
	(append_type_to_template_for_access): Likewise, cache expensie
	object reference.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index a732ced2d8d..a36f603761c 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -11521,26 +11512,28 @@ perform_typedefs_access_check (tree tmpl, tree targs)
 	  && TREE_CODE (tmpl) != FUNCTION_DECL))
 return;
 
-  FOR_EACH_VEC_SAFE_ELT (get_types_needing_access_check (tmpl), i, iter)
-{
-  tree type_decl = iter->typedef_decl;
-  tree type_scope = iter->context;
-
-  if (!type_decl || !type_scope || !CLASS_TYPE_P (type_scope))
-	continue;
+  if (vec *tdefs
+  = get_types_needing_access_check (tmpl))
+FOR_EACH_VEC_ELT (*tdefs, i, iter)
+  {
+	tree type_decl = iter->typedef_decl;
+	tree type_scope = iter->context;
 
-  if (uses_template_parms (type_decl))
-	type_decl = tsubst (type_decl, targs, tf_error, NULL_TREE);
-  if (uses_template_parms (type_scope))
-	type_scope = tsubst (type_scope, targs, tf_error, NULL_TREE);
+	if (!type_decl || !type_scope || !CLASS_TYPE_P (type_scope))
+	  continue;
 
-  /* Make access check error messages point to the location
- of the use of the typedef.  */
-  iloc_sentinel ils (iter->locus);
-  perform_or_defer_access_check (TYPE_BINFO (type_scope),
- type_decl, type_decl,
- tf_warning_or_error);
-}
+	if (uses_template_parms (type_decl))
+	  type_decl = tsubst (type_decl, targs, tf_error, NULL_TREE);
+	if (uses_template_parms (type_scope))
+	  type_scope = tsubst (type_scope, targs, tf_error, NULL_TREE);
+
+	/* Make access check error messages point to the location
+	   of the use of the typedef.  */
+	iloc_sentinel ils (iter->locus);
+	perform_or_defer_access_check (TYPE_BINFO (type_scope),
+   type_decl, type_decl,
+   tf_warning_or_error);
+  }
 }
 
 static tree
@@ -29225,25 +29218,13 @@ check_auto_in_tmpl_args (tree tmpl, tree args)
 vec *
 get_types_needing_access_check (tree t)
 {
-  tree ti;
-  vec *result = NULL;
-
-  if (!t || t == error_mark_node)
-return NULL;
-
-  if (!(ti = get_template_info (t)))
-return NULL;
+  gcc_checking_assert ((CLASS_TYPE_P (t) || TREE_CODE (t) == FUNCTION_DECL));
+  
+  if (tree ti = get_template_info (t))
+if (TI_TEMPLATE (ti))
+  return TI_TYPEDEFS_NEEDING_ACCESS_CHECKING (ti);
 
-  if (CLASS_TYPE_P (t)
-  || TREE_CODE (t) == FUNCTION_DECL)
-{
-  if (!TI_TEMPLATE (ti))
-	return NULL;
-
-  result = TI_TYPEDEFS_NEEDING_ACCESS_CHECKING (ti);
-}
-
-  return result;
+  return NULL;
 }
 
 /* Append the typedef TYPE_DECL used in template T to a list of typedefs
@@ -29328,9 +29309,11 @@ append_type_to_template_for_access_check (tree templ,
   gcc_assert (type_decl && (TREE_CODE (type_decl) == TYPE_DECL));
 
   /* Make sure we don't append the type to the template twice.  */
-  FOR_EACH_VEC_SAFE_ELT (get_types_needing_access_check (templ), i, iter)
-if (iter->typedef_decl == type_decl && scope == iter->context)
-  return;
+  if (vec *tdefs
+  = get_types_needing_access_check (templ))
+FOR_EACH_VEC_ELT (*tdefs, i, iter)
+  if (iter->typedef_decl == type_decl && scope == iter->context)
+	return;
 
   append_type_to_template_for_access_check_1 (templ, type_decl,
 	  scope, location);

[Bug lto/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value

[ostash at ostash dot kiev.ua]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #10 from Viktor Ostashevskyi  ---
Hello,

During GCC 10.1.0 bootstrap in LTO+PGO mode, configured as:

Configured with: ../gcc-10.1.0/configure --disable-multiarch
--disable-libquadmath --disable-libquadmath-support --disable-libssp
--disable-libstdcxx-pch --disable-multilib --disable-nls
--enable-checking=release --enable-__cxa_atexit --enable-languages=c,c++
--enable-libstdcxx-debug --enable-lto --enable-plugin --enable-threads=posix
--enable-tls --with-build-config=bootstrap-lto
--with-default-libstdcxx-abi=gcc4-compatible --with-linker-hash-style=gnu
--with-system-zlib --with-zstd=no --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu

I got following ICE:

/ostash/buildtc10/gcc-10.1.0-build/./prev-gcc/xgcc
-B/ostash/buildtc10/gcc-10.1.0-build/./prev-gcc/
-B/ostash/tc10/x86_64-pc-linux-gnu/bin/ -B/ostash/tc10/x86_64-pc-linux-gnu/bin/
-B/ostash/tc10/x86_64-pc-linux-gnu/lib/ -isystem
/ostash/tc10/x86_64-pc-linux-gnu/include -isystem
/ostash/tc10/x86_64-pc-linux-gnu/sys-include-c -DHAVE_CONFIG_H
-fprofile-use -flto=jobserver -frandom-seed=1  -I.
-I../../gcc-10.1.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE -fcf-protection
../../gcc-10.1.0/libiberty/hashtab.c -o hashtab.o
during IPA pass: fnsummary
../../gcc-10.1.0/libiberty/hashtab.c:997:1: internal compiler error: in
stream_out_histogram_value, at value-prof.c:338
  997 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [hashtab.o] Error 1
make[3]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build/libiberty'
make[2]: *** [all-stagefeedback-libiberty] Error 2
make[2]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build'
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build'
make: *** [profiledbootstrap] Error 2


I can provide gcda files if needed.

[Bug target/95112] New: i386 procedures have prolog endbr32

[akobets at mail dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95112

Bug ID: 95112
   Summary: i386 procedures have prolog endbr32
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akobets at mail dot ru
  Target Milestone: ---

gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu1)

Test file:
===
void test()
{
}
===

Buld:
i686-linux-gnu-gcc -c -fno-PIC -mno-mmx -mno-sse -O2 -fomit-frame-pointer
-ffreestanding -fno-stack-protector --no-exceptions test.c

Result:
i686-linux-gnu-objdump -d test.o

test.o: file format elf32-i386


disassembling section .text:

 :
   0:   f3 0f 1e fb endbr32 
   4:   c3  ret
==
Please help me find way to build clear code.
__attribute__((naked)) do not resolve problem.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jared.martinsen at fiserv dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

Jared  changed:

   What|Removed |Added

 CC||jared.martinsen at fiserv dot 
com

--- Comment #211 from Jared  ---
Are these errors the same as described above?

It give the following 2 errors:
ld: The value 0xfe38a260 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in
section index 222 of file
/library/home/build/tapecut5/code/lib/libsubo.a[file1.o]
ld: The value 0xfe587970 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in
section index 2125 of file
/library/home/build/tapecut5/code/lib/libsubo.a[file2.o] 


Using gcc version 4.2.3.  On 64 bit HP-UX
Here is the raw command line.
/usr/local/bin/g++ /library/home/build/tapecut5/code/obj/ocu00.o -z
-L/usr/local/lib/hpux32 -lxerces-c -lxerces-depdom -
L/opt/eloquence/8.2/lib/hpux32 -leqdb -limage3k -lfwutil
-L/library/home/build/tapecut5/code/lib -lsubo -lsubr -L/librar
y/home/build/tapecut5/code/spx/lib -lspx -lm  -lcrypto -lssl -o
/library/home/build/tapecut5/code/bin/spectrum 

Is there a fix for this?  Newer compiler or an option?

[Bug tree-optimization/95113] [10/11 Regression] Wrong code w/ -O2 -fexceptions -fnon-call-exceptions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.2
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r10-3542-g0b92cf305dcf34387a8e2564e55ca8948df3b47a

[Bug middle-end/95108] [9/10/11 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Jakub Jelinek  ---
Created attachment 48523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48523=edit
gcc11-pr95108.patch

Untested fix.

Re: [PATCH] c++: SFINAE for invalid delete-expression [PR79706]

[Jason Merrill via Gcc-patches]

On 5/12/20 11:36 PM, Patrick Palka wrote:

This fixes SFINAE when substitution yields an invalid delete-expression
due to the pertinent deallocation function being marked deleted or
otherwise inaccessible.

We need to check for an erroneous result from build_op_delete_call and
exit early in that case, so that we don't build a COND_EXPR around the
erroneous call which finish_decltype_type would then quietly accept.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?


OK.


gcc/cp/ChangeLog:

PR c++/79706
* init.c (build_vec_delete_1): Return error_mark_node if
deallocate_expr is error_mark_node.
(build_delete): Return error_mark_node if do_delete is
error_mark_node.

gcc/testsuite/ChangeLog:

PR c++/79706
* g++.dg/template/sfinae30.C: New test.
---
  gcc/cp/init.c|  8 ++--
  gcc/testsuite/g++.dg/template/sfinae30.C | 21 +
  2 files changed, 27 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/template/sfinae30.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index e2e547afd96..c1047dbb1cc 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -4076,7 +4076,9 @@ build_vec_delete_1 (location_t loc, tree base, tree 
maxindex, tree type,
  }
  
body = loop;

-  if (!deallocate_expr)
+  if (deallocate_expr == error_mark_node)
+return error_mark_node;
+  else if (!deallocate_expr)
  ;
else if (!body)
  body = deallocate_expr;
@@ -4993,7 +4995,9 @@ build_delete (location_t loc, tree otype, tree addr,
return expr;
  }
  
-  if (do_delete)

+  if (do_delete == error_mark_node)
+return error_mark_node;
+  else if (do_delete)
  {
tree do_delete_call_expr = extract_call_expr (do_delete);
if (TREE_CODE (do_delete_call_expr) == CALL_EXPR)
diff --git a/gcc/testsuite/g++.dg/template/sfinae30.C 
b/gcc/testsuite/g++.dg/template/sfinae30.C
new file mode 100644
index 000..82f31aaa625
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/sfinae30.C
@@ -0,0 +1,21 @@
+// PR c++/79706
+// { dg-do compile { target c++11 } }
+
+struct A {
+  void operator delete(void*) = delete;
+private:
+  void operator delete[](void*);
+};
+
+extern A *p;
+
+template
+auto foo(T *t) -> decltype(delete t); // { dg-error "use of deleted function" }
+
+template
+auto bar(T *t) -> decltype(delete[] t); // { dg-error "private within this 
context" }
+
+void baz() {
+  foo(p); // { dg-error "no match" }
+  bar(p); // { dg-error "no match" }
+}

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111

--- Comment #6 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #5)
> This snippet from cppreference:
> 
>   If the coroutine is a non-static member function, such as task 
>   my_class::method1(int x) const;, its Promise type is 
>   std::coroutine_traits, const my_class&, int>::promise_type
> 
> implies that both gcc and my interpretation are wrong. gcc passes a pointer
> for the lambda, and I'd like the lambda to be passed by value. The
> difference between gcc and cppreference is trivial, and both of them make
> coroutine lambdas unusable if they contain state and if the lambda is
> asynchronous.

( assuming that this is the problem, I haven't yet had a chance to check *
could still be a bug ;) ).

I have a pending change to pass a reference to the lambda object to the traits,
promise preview and allocator lookups.

This was a source of considerable discussion amongst the implementors (GCC,
clang, MSVC) about how the std should be interpreted.  The change I mention
will make the lambda capture object pointer behave in the same manner as 'this'
(which was the intended behaviour as determined by the long discussion).  MSVC
implements this now, and clang will be changing to match it also.

That won't solve any lifetime issue with the capture object - you will still
need to ensure that it exists for the duration of the coroutine * as you would
for a class instance with a method coroutine *.

We (at least several of us) agree that this is a source of easy programming
errors - and I expect there to be some revisiting in c++23.  That's a
considerable challenge in the face of a mutable lambda - maybe (thinking aloud)
needs something like Apple blocks, but with an automatic promotion of the
closure to a heap object if it escapes the creating scope.