Re: [RFC] More jump threading restrictions in the presence of loops.

[Jeff Law via Gcc-patches]

On 10/6/2021 4:22 AM, Aldy Hernandez wrote:

[Here go the bits by Richi, tested on x86-64 Linux, and ongoing tests
on aarch64 and ppc64le.]

There is a lot of fall-out from this patch, as there were many threading
tests that assumed the restrictions introduced by this patch were valid.
Some tests have merely shifted the threading to after loop
optimizations, but others ended up with no threading opportunities at
all.  Surprisingly some tests ended up with more total threads.  It was
a crapshoot all around.

On a postive note, there are 6 tests that no longer XFAIL, and one
guality test which now passes.

I would appreciate someone reviewing the test changes.  I am unsure
whether some of the tests should be removed, XFAILed, or some other
thing.

I felt a bit queasy about such a fundamental change wrt threading, so I
ran it through my callgrind test harness (.ii files from a bootstrap).
There was no change in overall compilation, DOM, or the VRP threaders.

However, there was a slight increase of 1.63% in the backward threader.
I'm pretty sure we could reduce this if we incorporated the restrictions
into their profitability code.  This way we could stop the search when
we ran into one of these restrictions.  Not sure it's worth it at this
point.

Note, that this ad-hoc testing is not meant to replace a more thorough
SPEC, etc test.

Tested on x86-64 Linux.

OK pending tests on aarch64 and ppc64le?

Co-authored-by: Richard Biener 

0001-Disallow-loop-rotation-and-loop-header-crossing-in-j.patch

 From 5c0fb55b45733ec38918f5d7a576719da32e4a6c Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Mon, 4 Oct 2021 09:47:02 +0200
Subject: [PATCH] Disallow loop rotation and loop header crossing in jump
  threaders.

There is a lot of fall-out from this patch, as there are many threading
tests that assumed the restrictions introduced by this patch were valid.
Some tests have merely shifted the threading to after loop
optimizations, but others ended up with no threading opportunities at
all.  Surprisingly some tests ended up with more total threads.  It was
a crapshoot all around.

On a postive note, there are 6 tests that no longer XFAIL, and one
guality test which now passes.

I would appreciate someone reviewing the test changes.  I am unsure
whether some of the tests should be removed, XFAILed, or some other
thing.

I felt a bit queasy about such a fundamental change wrt threading, so I
ran it through my callgrind test harness (.ii files from a bootstrap).
There was no change in overall compilation, DOM, or the VRP threaders.

However, there was a slight increase of 1.63% in the backward threader.
I'm pretty sure we could reduce this if we incorporated the restrictions
into their profitability code.  This way we could stop the search when
we ran into one of these restrictions.  Not sure it's worth it at this
point.

Note, that this ad-hoc testing is not meant to replace a more thorough
SPEC, etc test.

Tested on x86-64 Linux.

OK pending tests on aarch64 and ppc64le?

Co-authored-by: Richard Biener 

gcc/ChangeLog:

* tree-ssa-threadupdate.c (cancel_thread): Dump threading reason
on the same line as the threading cancellation.
(jt_path_registry::cancel_invalid_paths): Avoid rotating loops.
Avoid threading through loop headers where the path remains in the
loop.

libgomp/ChangeLog:

* testsuite/libgomp.graphite/force-parallel-5.c: Remove xfail.

gcc/testsuite/ChangeLog:

* gcc.dg/Warray-bounds-87.c: Remove xfail.
* gcc.dg/analyzer/pr94851-2.c: Remove xfail.
* gcc.dg/graphite/pr69728.c: Remove xfail.
* gcc.dg/graphite/scop-dsyr2k.c: Remove xfail.
* gcc.dg/graphite/scop-dsyrk.c: Remove xfail.
* gcc.dg/shrink-wrap-loop.c: Remove xfail.
* gcc.dg/loop-8.c: Adjust for new threading restrictions.
* gcc.dg/tree-ssa/ifc-20040816-1.c: Same.
* gcc.dg/tree-ssa/pr21559.c: Same.
* gcc.dg/tree-ssa/pr59597.c: Same.
* gcc.dg/tree-ssa/pr71437.c: Same.
* gcc.dg/tree-ssa/pr77445-2.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-18.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-2a.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-6.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Same.
* gcc.dg/vect/bb-slp-16.c: Same.
* gcc.dg/tree-ssa/ssa-thread-invalid.c: New test.
So there is some light fallout on our friend visium.  I must say that 
having a port which fails to link if there's a call to abort () left in 
the program is awful helpful :-)    I reviewed the half-dozen or so 
tests that fail after this change, they all look like any jump threads 
are for loop rotation.  So I'm inclined to ignore those and just 
generate new baselines for the visium port.


Some additional thoughts on the tests below.  I didn't see anything 
that's worth an objection, but at least in a couple cases there's ways 
to save the 

Re: [PATCH] gcc/configure: check for powerpc64le-unknown-freebsd

[Piotr Kubaj via Gcc-patches]

On 21-10-16 18:57:39, Segher Boessenkool wrote:
> On Sat, Oct 16, 2021 at 04:09:05AM +0200, Piotr Kubaj wrote:
> > Only powerpc64-unknown-freebsd was checked for.
> > 
> > Signed-off-by: Piotr Kubaj 
> 
> Thanks!
> 
> I pushed this now, with commit message (including changelog, which is
> required):

Thank you!

Since powerpc64le-unknown-freebsd is supported also in 9, 10 and 11, can you 
also backport it?

> 
> ===
> gcc/configure: Check for powerpc64le*-*-freebsd*
> 
> Only powerpc64-unknown-freebsd was checked for.
> 
> Signed-off-by: Piotr Kubaj 
> 
> gcc/
>   * configure.ac: Treat powerpc64*-*-freebsd* the same as
>   powerpc64-*-freebsd*.
>   * configure: Regenerate.
> ===
> 
> 
> Segher


signature.asc
Description: PGP signature

[PATCH v6] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

[Raoni Fassina Firmino via Gcc-patches]

Changes since v5[5]:
  - Reworked all builtins to accept the FE_* macros as parameters and
so be agnostic to libc implementations.  Largely based of
fpclassify.  To that end, there is some new files changed:
+ Change the argument list for the builtins declarations in
  builtins.def
+ Added new types in builtin-types.def to use in the buitins
  declarations.
+ Added extra documentation for the builtins on doc/extend.texi,
  similar to fpclassify.
  - Updated doc/md.texi documentation with the new optab behaviors.
  - Updated comments to the expanders and expand handlers to try to
explain whats is going on.
  - Changed the description for the return operand in the RTL template
of the fegetround expander.  Using "(set )", the same way as
rs6000_mffsl expander.
  - Updated testcases with helper macros with the new argument list.

Tested on top of master (f7571527a44808cd7062c77bb9570c13f4f6a126)
on the following plataforms with no regression:
  - powerpc64le-linux-gnu (Power 9)
  - powerpc64le-linux-gnu (Power 8)
  - powerpc64-linux-gnu (Power 9, with 32 and 64 bits tests)

Documentation changes tested on x86_64-redhat-linux.

This approach left me with some hanging problems that I am not quite
sure how to go about it.

First is the different arguments from the C99 functions.  I think the
solution is a macro to correct this, like so:

#define feclearexcept(excepts) \
__builtin_feclearexcept(excepts, FE_DIVBYZERO, FE_INEXACT, \
FE_INVALID, FE_OVERFLOW, FE_UNDERFLOW)

That is automatically always included or included when fenv.h is
included.  Does the preprocessor have this ability? If so, where
should I put it?

But this solution seems to have a problem that it will bypass
-fno-builtin, unless there can be a conditional check for it on the
preprocessor.

Second is the fallback of the expanders.  When the expanders fail it
will leave the function call, which is great, but since the argument
list is different, well, it not is pretty.  There is no execution
problem, since the builtins only having extra arguments, but it
generate extra unnecessary code. Here is an example, a snipped of the
generated assembly from the builtin-feclearexcept-feraiseexcept-1.c
testcase:

# builtin-feclearexcept-feraiseexcept-1.c:36: 
__builtin_feclearexcept(FE_INVALID);  // CALL
lis %r8,0x800
lis %r7,0x1000
lis %r6,0x2000
lis %r5,0x200
lis %r4,0x400
lis %r3,0x2000
bl feclearexcept

I assume I can modify the RTL to remove the unneeded arguments.  If
so, there is pointer where this is done or how I can do it?

I'm also adding some extra documentation for the builtins section, the
doc/extend.texi, close to where the fpclassify documentation is[6],
but I don't know if I'm doing it right, especially changing such a
front facing documentation.

I'm repeating the "changelog" from past versions here for convenience:

Changes since v4[4]:
  - Fixed more spelling and code style.
  - Add more clarification on  comments for feraiseexcept and
feclearexcept expands;

Changes since v3[3]:
  - Fixed fegetround bug on powerpc64 (big endian) that Segher
spotted;

Changes since v2[2]:
  - Added documentation for the new optabs;
  - Remove use of non portable __builtin_clz;
  - Changed feclearexcept and feraiseexcept to accept all 4 valid
flags at the same time and added more test for that case;
  - Extended feclearexcept and feraiseexcept testcases to match
accepting multiple flags;
  - Fixed builtin-feclearexcept-feraiseexcept-2.c testcase comparison
after feclearexcept tests;
  - Updated commit message to reflect change in feclearexcept and
feraiseexcept from the glibc conterpart;
  - Fixed English spelling and typos;
  - Fixed code-style;
  - Changed subject line tag to make clear it is not just rs6000 code.

Changes since v1[1]:
  - Fixed english spelling;
  - Fixed code-style;
  - Changed match operand predicate in feclearexcept and feraiseexcept;
  - Changed testcase options;
  - Minor changes in test code to be C90 compatible;
  - Other minor changes sugested by Segher;
  - Changed subject line tag (not sure if I tagged correctly or should
include optabs: also)

[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552024.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553297.html
[3] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557109.html
[4] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557349.html
[5] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557984.html
[6] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins

 8< 

This optimizations were originally in glibc, but was removed
and suggested that they were a good fit as gcc builtins[1].

feclearexcept and feraiseexcept were extended (in comparison to the
glibc version) to accept any combination of the accepted flags, not
limited to just one flag bit at a time anymore.

Re: [PATCH] gcc/configure: check for powerpc64le-unknown-freebsd

[Segher Boessenkool]

On Sat, Oct 16, 2021 at 04:09:05AM +0200, Piotr Kubaj wrote:
> Only powerpc64-unknown-freebsd was checked for.
> 
> Signed-off-by: Piotr Kubaj 

Thanks!

I pushed this now, with commit message (including changelog, which is
required):

===
gcc/configure: Check for powerpc64le*-*-freebsd*

Only powerpc64-unknown-freebsd was checked for.

Signed-off-by: Piotr Kubaj 

gcc/
* configure.ac: Treat powerpc64*-*-freebsd* the same as
powerpc64-*-freebsd*.
* configure: Regenerate.
===


Segher

[committed] wwwdocs: Update two links related to Go

[Gerald Pfeifer]

These two redirected from golang.org to pkg.go.dev.

---
 htdocs/gcc-5/changes.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-5/changes.html b/htdocs/gcc-5/changes.html
index a346c7f6..05e796dd 100644
--- a/htdocs/gcc-5/changes.html
+++ b/htdocs/gcc-5/changes.html
@@ -598,8 +598,8 @@ version 2 and the current setting.
 GCC 5 provides a complete implementation of the Go 1.4.2
 release.
 Building GCC 5 with Go enabled will install two new
-  programs: https://golang.org/cmd/go/;>go
-  and https://golang.org/cmd/gofmt/;>gofmt.
+  programs: https://pkg.go.dev/cmd/go;>go
+  and https://pkg.go.dev/cmd/gofmt;>gofmt.
   
 
 
-- 
2.33.0

[Patch][GCN] [GCC 11] Backport GCN with LLVM-MC 13 linker fixes to GCC 11

[Tobias Burnus]

This patch is mostly motivated by distribution needs in general
and Debian/Ubuntu needs in particular – but I think it makes
sense for all GCC 11 users.

GCC's AMD GCN support uses LLVM's assembler and linker mc/lld
and thus requires compatibility with LLVM. On mainline, support
for LLVM 13 was added – and I like to see a backport to GCC 11.

In particular, I would like to "git cherry-pick -x' the following patches:

cfa1f8226f2 gcc/configure.ac: fix register issue for global_load assembler 
functions
aad32a00b7d amdgcn: Add -mxnack and -msram-ecc [PR 100208]
5c127c4cac3 amdgcn: Mark s_mulk_i32 as clobbering SCC
 (Outside of this series as it only picks a bug fix)
6ca03ca35a5 amdgcn: Support LLVM 13 assembler syntax
 (-> see remark below)
205dafb6ede amdgcn: Implement -msram-ecc=any
81c362c7c2b amdgcn: Fix assembler version incompatibility
f3d64372d77 amdgcn: fix up offload debug linking with LLVM 13

OK for GCC 11?

[I have build GCC x86-64 with amdgcn offloading enabled both
with LLVM 9 and with LLVM 13; libgomp passes fine with LLVM 9
but with the LLVM 13 build, I see an ICE in lld for some testcases,
which I have not debugged – but GCC itself builds and several
libgomp testcases do pass.]

Tobias

PS: I attached
* the full "git log --stat" for all those patches for references
* as the 4th one, "Support LLVM 13 assembler syntax", does not
  cleanly apply, I attached the full patch.

The reason that the latter does not apply is that mainline changed:
"configure: remove version argument from gcc_GAS_CHECK_FEATURE"
in https://gcc.gnu.org/g:e0b6d0b39c69372e4a66f44d218e0244bb549d83
which was fixed for GCN a bit later in commit
"configure: Adjust several assembler checks to remove an unused parm."
https://gcc.gnu.org/g:e5d9873fcb6f90d03b7534af53de39ec65d0cdc5

The only change is "," to ",," in configure.ac; 'configure' itself
was already fine.
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 24a65327ed97e5d3bab565977051c3421a8ff763
Author: Andrew Stubbs 
Date:   Wed Oct 13 11:53:42 2021 +0100

amdgcn: fix up offload debug linking with LLVM 13

Between LLVM 9 and LLVM 13 the attribute works differently in several ways,
and this needs to be allowed for in GCC and mkoffload independently.

This patch fixes up mkoffload when debug info is enabled, which is made more
complicated because the configure tests checks whether the attribute option
is accepted silently, but does not check if the assembler actually sets the
ELF flags for that attribute, and mkoffload needs to mimick that behaviour
exactly. The patch therefore removes some of the conditionals.

gcc/ChangeLog:

* config/gcn/gcn-hsa.h (S_FIJI): Set unconditionally.
(S_900): Likewise.
(S_906): Likewise.
* config/gcn/gcn.c: Hard code SRAM ECC settings for old 
architectures.
* config/gcn/mkoffload.c (ELFABIVERSION_AMDGPU_HSA): Rename to ...
(ELFABIVERSION_AMDGPU_HSA_V3): ... this.
(ELFABIVERSION_AMDGPU_HSA_V4): New.
(SET_SRAM_ECC_UNSUPPORTED): New.
(copy_early_debug_info): Create elf flags to match the other 
objects.
(main): Just let the attribute flags pass through.

(cherry picked from commit f3d64372d777d7d6068df8167b6751c289963e85)

 gcc/config/gcn/gcn-hsa.h   | 13 +
 gcc/config/gcn/gcn.c   |  6 --
 gcc/config/gcn/mkoffload.c | 36 +---
 3 files changed, 26 insertions(+), 29 deletions(-)

commit b935972b7153b07000f852b7b1f7d10226928bff
Author: Andrew Stubbs 
Date:   Thu Sep 30 17:50:33 2021 +0100

amdgcn: Fix assembler version incompatibility

This is another case of the global_load instruction format changing in LLVM
(because they fixed a bug).  The configure test is already in place to 
detect
what is needed.

gcc/ChangeLog:

* config/gcn/gcn-valu.md (gather_insn_2offsets): Apply
HAVE_GCN_ASM_GLOBAL_LOAD_FIXED.
(scatter_insn_2offsets): Likewise.

(cherry picked from commit 81c362c7c2bccd72d798bf7ea6c74d4b1cc3931f)

 gcc/config/gcn/gcn-valu.md | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

commit 560abb74a462a3eb6f1320cac711c23e26d0f210
Author: Andrew Stubbs 
Date:   Tue Sep 28 16:26:09 2021 +0100

amdgcn: Implement -msram-ecc=any

The option was already there, but just an alias for -msram-ecc=on.  Now that
LLVM13 supports HSACOv4 and the new ELF flags I can implement the option
properly.

The "any" option is the default in order to ensure that library files work
whichever way the user wants, which means we won't need multilibs to support
the different SRAM ECC hardware 

Re: [PATCH v2 0/4] libffi: Sync with upstream

[David Edelsohn via Gcc-patches]

On Sat, Oct 16, 2021 at 3:59 PM H.J. Lu  wrote:
>
> On Sat, Oct 16, 2021 at 12:53 PM David Edelsohn  wrote:
> >
> > On Sat, Oct 16, 2021 at 1:13 PM H.J. Lu  wrote:
> > >
> > > On Sat, Oct 16, 2021 at 10:04 AM David Edelsohn  wrote:
> > > >
> > > > On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu  wrote:
> > > > >
> > > > > On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn  
> > > > > wrote:
> > > > > >
> > > > > > On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu  wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Change in the v2 patch:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Disable static trampolines by default.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > GCC maintained a copy of libffi snapshot from 2009 and 
> > > > > > > > > > > > cherry-picked fixes
> > > > > > > > > > > > from upstream over the last 10+ years.  In the 
> > > > > > > > > > > > meantime, libffi upstream
> > > > > > > > > > > > has been changed significantly with new features, bug 
> > > > > > > > > > > > fixes and new target
> > > > > > > > > > > > support.  Here is a set of patches to sync with libffi 
> > > > > > > > > > > > 3.4.2 release and
> > > > > > > > > > > > make it easier to sync with libffi upstream:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Document how to sync with upstream.
> > > > > > > > > > > > 2. Add scripts to help sync with upstream.
> > > > > > > > > > > > 3. Sync with libffi 3.4.2. This patch is quite big.  It 
> > > > > > > > > > > > is availale at
> > > > > > > > > > > >
> > > > > > > > > > > > https://gitlab.com/x86-gcc/gcc/-/commit/15e80c879c571f79a0e57702848a9df5fba5be2f
> > > > > > > > > > > > 4. Integrate libffi build and testsuite with GCC.
> > > > > > > > > > >
> > > > > > > > > > > How did you test this?  It looks like libgo is the only 
> > > > > > > > > > > consumer of
> > > > > > > > > > > libffi these days.
> > > > > > > > > > > In particular go/libgo seems to be supported on almost 
> > > > > > > > > > > all targets besides
> > > > > > > > > > > darwin/windows - did you test cross and canadian 
> > > > > > > > > > > configurations?
> > > > > > > > > >
> > > > > > > > > > I only tested it on Linux/i686 and Linux/x86-64.   My 
> > > > > > > > > > understanding is that
> > > > > > > > > > the upstream libffi works on Darwin and Windows.
> > > > > > > > > >
> > > > > > > > > > > I applaud the attempt to sync to upsteam but I fear you 
> > > > > > > > > > > won't get any "review"
> > > > > > > > > > > of this massive diff.
> > > > > > > > > >
> > > > > > > > > > I believe that it should just work.  Our libffi is very 
> > > > > > > > > > much out of date.
> > > > > > > > >
> > > > > > > > > Yes, you can hope.  And yes, our libffi is out of date.
> > > > > > > > >
> > > > > > > > > Can you please do the extra step to test one weird 
> > > > > > > > > architecture, namely
> > > > > > > > > powerpc64-aix which is available on the compile-farm?
> > > > > > > >
> > > > > > > > I will give it a try and report back.
> > > > > > > >
> > > > > > > > > If that goes well I think it's good to "hope" at this point 
> > > > > > > > > (and plenty of
> > > > > > > > > time to fix fallout until the GCC 12 release).
> > > > > > > > >
> > > > > > > > > Thus OK after the extra testing dance and waiting until early 
> > > > > > > > > next
> > > > > > > > > week so others can throw in a veto.
> > > > > > >
> > > > > > > I tried to bootstrap GCC master branch on  gcc119.fsffrance.org:
> > > > > > >
> > > > > > > *  MT/MODEL: 8284-22A 
> > > > > > > *
> > > > > > > * Partition: gcc119   
> > > > > > > *
> > > > > > > *System: power8-aix.osuosl.org
> > > > > > > *
> > > > > > > *   O/S: AIX V7.2 7200-04-03-2038
> > > > > > >
> > > > > > > I configured GCC with
> > > > > > >
> > > > > > > --with-as=/usr/bin/as --with-ld=/usr/bin/ld
> > > > > > > --enable-version-specific-runtime-libs --disable-nls
> > > > > > > --enable-decimal-float=dpd --disable-libstdcxx-pch 
> > > > > > > --disable-werror
> > > > > > > --enable-__cxa_atexit --with-gmp=/opt/cfarm --with-mpfr=/opt/cfarm
> > > > > > > --with-mpc=/opt/cfarm --with-isl=/opt/cfarm --prefix=/opt/freeware
> > > > > > > --with-local-prefix=/opt/freeware --enable-languages=c,c++,go
> > > > > > >
> > > > > > > I got
> > > > > > >
> > > > > > > g++   -g -DIN_GCC 

Re: [PATCH v2 0/4] libffi: Sync with upstream

[H.J. Lu via Gcc-patches]

On Sat, Oct 16, 2021 at 12:53 PM David Edelsohn  wrote:
>
> On Sat, Oct 16, 2021 at 1:13 PM H.J. Lu  wrote:
> >
> > On Sat, Oct 16, 2021 at 10:04 AM David Edelsohn  wrote:
> > >
> > > On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu  wrote:
> > > >
> > > > On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn  
> > > > wrote:
> > > > >
> > > > > On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu  wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu  wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > Change in the v2 patch:
> > > > > > > > > > >
> > > > > > > > > > > 1. Disable static trampolines by default.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > GCC maintained a copy of libffi snapshot from 2009 and 
> > > > > > > > > > > cherry-picked fixes
> > > > > > > > > > > from upstream over the last 10+ years.  In the meantime, 
> > > > > > > > > > > libffi upstream
> > > > > > > > > > > has been changed significantly with new features, bug 
> > > > > > > > > > > fixes and new target
> > > > > > > > > > > support.  Here is a set of patches to sync with libffi 
> > > > > > > > > > > 3.4.2 release and
> > > > > > > > > > > make it easier to sync with libffi upstream:
> > > > > > > > > > >
> > > > > > > > > > > 1. Document how to sync with upstream.
> > > > > > > > > > > 2. Add scripts to help sync with upstream.
> > > > > > > > > > > 3. Sync with libffi 3.4.2. This patch is quite big.  It 
> > > > > > > > > > > is availale at
> > > > > > > > > > >
> > > > > > > > > > > https://gitlab.com/x86-gcc/gcc/-/commit/15e80c879c571f79a0e57702848a9df5fba5be2f
> > > > > > > > > > > 4. Integrate libffi build and testsuite with GCC.
> > > > > > > > > >
> > > > > > > > > > How did you test this?  It looks like libgo is the only 
> > > > > > > > > > consumer of
> > > > > > > > > > libffi these days.
> > > > > > > > > > In particular go/libgo seems to be supported on almost all 
> > > > > > > > > > targets besides
> > > > > > > > > > darwin/windows - did you test cross and canadian 
> > > > > > > > > > configurations?
> > > > > > > > >
> > > > > > > > > I only tested it on Linux/i686 and Linux/x86-64.   My 
> > > > > > > > > understanding is that
> > > > > > > > > the upstream libffi works on Darwin and Windows.
> > > > > > > > >
> > > > > > > > > > I applaud the attempt to sync to upsteam but I fear you 
> > > > > > > > > > won't get any "review"
> > > > > > > > > > of this massive diff.
> > > > > > > > >
> > > > > > > > > I believe that it should just work.  Our libffi is very much 
> > > > > > > > > out of date.
> > > > > > > >
> > > > > > > > Yes, you can hope.  And yes, our libffi is out of date.
> > > > > > > >
> > > > > > > > Can you please do the extra step to test one weird 
> > > > > > > > architecture, namely
> > > > > > > > powerpc64-aix which is available on the compile-farm?
> > > > > > >
> > > > > > > I will give it a try and report back.
> > > > > > >
> > > > > > > > If that goes well I think it's good to "hope" at this point 
> > > > > > > > (and plenty of
> > > > > > > > time to fix fallout until the GCC 12 release).
> > > > > > > >
> > > > > > > > Thus OK after the extra testing dance and waiting until early 
> > > > > > > > next
> > > > > > > > week so others can throw in a veto.
> > > > > >
> > > > > > I tried to bootstrap GCC master branch on  gcc119.fsffrance.org:
> > > > > >
> > > > > > *  MT/MODEL: 8284-22A   
> > > > > >   *
> > > > > > * Partition: gcc119 
> > > > > >   *
> > > > > > *System: power8-aix.osuosl.org  
> > > > > >   *
> > > > > > *   O/S: AIX V7.2 7200-04-03-2038
> > > > > >
> > > > > > I configured GCC with
> > > > > >
> > > > > > --with-as=/usr/bin/as --with-ld=/usr/bin/ld
> > > > > > --enable-version-specific-runtime-libs --disable-nls
> > > > > > --enable-decimal-float=dpd --disable-libstdcxx-pch --disable-werror
> > > > > > --enable-__cxa_atexit --with-gmp=/opt/cfarm --with-mpfr=/opt/cfarm
> > > > > > --with-mpc=/opt/cfarm --with-isl=/opt/cfarm --prefix=/opt/freeware
> > > > > > --with-local-prefix=/opt/freeware --enable-languages=c,c++,go
> > > > > >
> > > > > > I got
> > > > > >
> > > > > > g++   -g -DIN_GCC -fno-exceptions -fno-rtti 
> > > > > > -fasynchronous-unwind-tables -W
> > > > > > -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> > > > > > -Wmissing-format-at
> > > > > > tribute -Woverloaded-virtual -pedantic -Wno-long-long 
> > > > > > -Wno-variadic-macros -Wno-
> > > > > > 

Re: [PATCH v2 0/4] libffi: Sync with upstream

[David Edelsohn via Gcc-patches]

On Sat, Oct 16, 2021 at 1:13 PM H.J. Lu  wrote:
>
> On Sat, Oct 16, 2021 at 10:04 AM David Edelsohn  wrote:
> >
> > On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu  wrote:
> > >
> > > On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn  wrote:
> > > >
> > > > On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu  wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu  wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Change in the v2 patch:
> > > > > > > > > >
> > > > > > > > > > 1. Disable static trampolines by default.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > GCC maintained a copy of libffi snapshot from 2009 and 
> > > > > > > > > > cherry-picked fixes
> > > > > > > > > > from upstream over the last 10+ years.  In the meantime, 
> > > > > > > > > > libffi upstream
> > > > > > > > > > has been changed significantly with new features, bug fixes 
> > > > > > > > > > and new target
> > > > > > > > > > support.  Here is a set of patches to sync with libffi 
> > > > > > > > > > 3.4.2 release and
> > > > > > > > > > make it easier to sync with libffi upstream:
> > > > > > > > > >
> > > > > > > > > > 1. Document how to sync with upstream.
> > > > > > > > > > 2. Add scripts to help sync with upstream.
> > > > > > > > > > 3. Sync with libffi 3.4.2. This patch is quite big.  It is 
> > > > > > > > > > availale at
> > > > > > > > > >
> > > > > > > > > > https://gitlab.com/x86-gcc/gcc/-/commit/15e80c879c571f79a0e57702848a9df5fba5be2f
> > > > > > > > > > 4. Integrate libffi build and testsuite with GCC.
> > > > > > > > >
> > > > > > > > > How did you test this?  It looks like libgo is the only 
> > > > > > > > > consumer of
> > > > > > > > > libffi these days.
> > > > > > > > > In particular go/libgo seems to be supported on almost all 
> > > > > > > > > targets besides
> > > > > > > > > darwin/windows - did you test cross and canadian 
> > > > > > > > > configurations?
> > > > > > > >
> > > > > > > > I only tested it on Linux/i686 and Linux/x86-64.   My 
> > > > > > > > understanding is that
> > > > > > > > the upstream libffi works on Darwin and Windows.
> > > > > > > >
> > > > > > > > > I applaud the attempt to sync to upsteam but I fear you won't 
> > > > > > > > > get any "review"
> > > > > > > > > of this massive diff.
> > > > > > > >
> > > > > > > > I believe that it should just work.  Our libffi is very much 
> > > > > > > > out of date.
> > > > > > >
> > > > > > > Yes, you can hope.  And yes, our libffi is out of date.
> > > > > > >
> > > > > > > Can you please do the extra step to test one weird architecture, 
> > > > > > > namely
> > > > > > > powerpc64-aix which is available on the compile-farm?
> > > > > >
> > > > > > I will give it a try and report back.
> > > > > >
> > > > > > > If that goes well I think it's good to "hope" at this point (and 
> > > > > > > plenty of
> > > > > > > time to fix fallout until the GCC 12 release).
> > > > > > >
> > > > > > > Thus OK after the extra testing dance and waiting until early next
> > > > > > > week so others can throw in a veto.
> > > > >
> > > > > I tried to bootstrap GCC master branch on  gcc119.fsffrance.org:
> > > > >
> > > > > *  MT/MODEL: 8284-22A 
> > > > > *
> > > > > * Partition: gcc119   
> > > > > *
> > > > > *System: power8-aix.osuosl.org
> > > > > *
> > > > > *   O/S: AIX V7.2 7200-04-03-2038
> > > > >
> > > > > I configured GCC with
> > > > >
> > > > > --with-as=/usr/bin/as --with-ld=/usr/bin/ld
> > > > > --enable-version-specific-runtime-libs --disable-nls
> > > > > --enable-decimal-float=dpd --disable-libstdcxx-pch --disable-werror
> > > > > --enable-__cxa_atexit --with-gmp=/opt/cfarm --with-mpfr=/opt/cfarm
> > > > > --with-mpc=/opt/cfarm --with-isl=/opt/cfarm --prefix=/opt/freeware
> > > > > --with-local-prefix=/opt/freeware --enable-languages=c,c++,go
> > > > >
> > > > > I got
> > > > >
> > > > > g++   -g -DIN_GCC -fno-exceptions -fno-rtti 
> > > > > -fasynchronous-unwind-tables -W
> > > > > -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> > > > > -Wmissing-format-at
> > > > > tribute -Woverloaded-virtual -pedantic -Wno-long-long 
> > > > > -Wno-variadic-macros -Wno-
> > > > > overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE 
> > > > > -static-libstd
> > > > > c++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o 
> > > > > build/genenums \
> > > > > build/genenums.o build/read-md.o build/errors.o 
> > > > > ../build-powerpc-ibm-aix7.2.
> > > > > 

Re: [PATCH] Fix handling of flag_rename_registers.

[Jeff Law]

On 10/15/2021 9:27 AM, Martin Liška wrote:

On 10/14/21 16:27, Jeff Law wrote:
So what's the preferred way to handle this?  We're in the process of 
evaluating -frename-registers on our target right now and subject to 
verification of a couple issues, our inclination is to turn it on for 
our target at -O2.


Jeff


I think the best approach is doing that in 
TARGET_OPTION_OPTIMIZATION_TABLE like c6x does:


static const struct default_options c6x_option_optimization_table[] =
  {
    { OPT_LEVELS_1_PLUS, OPT_frename_registers, NULL, 1 },
...
}

ACK.  So nothing particularly special :-)

jeff

[PATCH] Change set_ptr_nonull to set_ptr_nonnull in comments

[H.J. Lu via Gcc-patches]

* value-query.cc (get_ssa_name_ptr_info_nonnull): Change
set_ptr_nonull to set_ptr_nonnull in comments.
---
 gcc/value-query.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/value-query.cc b/gcc/value-query.cc
index ab133aab114..17ebd86ce5f 100644
--- a/gcc/value-query.cc
+++ b/gcc/value-query.cc
@@ -296,7 +296,7 @@ get_ssa_name_ptr_info_nonnull (const_tree name)
 return false;
   /* TODO Now pt->null is conservatively set to true in PTA
  analysis. vrp is the only pass (including ipa-vrp)
- that clears pt.null via set_ptr_nonull when it knows
+ that clears pt.null via set_ptr_nonnull when it knows
  for sure. PTA will preserves the pt.null value set by VRP.
 
  When PTA analysis is improved, pt.anything, pt.nonlocal
-- 
2.32.0

Re: [PATCH v2 0/4] libffi: Sync with upstream

[Ian Lance Taylor via Gcc-patches]

On Sat, Oct 16, 2021 at 10:14 AM H.J. Lu via Gcc-patches
 wrote:
>
> Go on master branch isn't buildable on AIX.  What should I do
> next to get my libffi sync patches into master branch?

Is the only problem you are having the missing-objcopy problem?  To
fix that one, install the GNU binutils.

There are people who regularly use gccgo on AIX and send fixes for it,
I don't think it could be very badly broken.

Ian

Re: [Patch] (was: Re: [r12-4457 Regression] FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test on Linux/x86_64)

[Jan Hubicka via Gcc-patches]

> 
> Fortran has for a long time 'character(len=5), allocatable" or
> "character(len=*)". In the first case, the "5" can be ignored as both
> caller and callee know the length. In the second case, the length is
> determined by the argument, but it cannot be changed.
> 
> Since a not-that-short while, 'len=:' together with allocatable/pointer
> is supported.
> 
> In the latter case, the value can be change when the array
> association/allocation is changed.
> 
> I attached a patch, which was not tested. I am not quite sure whether
> the pointer address can actually escape or not - I think cannot but I
> played safe.
> 
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

> Fortran: Fix fn spec for character-returning functions
> 
> gcc/fortran/ChangeLog
>   * trans-types.c (create_fn_spec): For character-returning functions,
>   set the hidden string-length argument to 'R' only when the "len=:",
>   i.e. deferred length which goes alongside with allocatable/pointer.
> 
> diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
> index 220976babb8..637d2c71d01 100644
> --- a/gcc/fortran/trans-types.c
> +++ b/gcc/fortran/trans-types.c
> @@ -3008,7 +3008,14 @@ create_fn_spec (gfc_symbol *sym, tree fntype)
>   }
>if (sym->ts.type == BT_CHARACTER)
>   {
> -   spec[spec_len++] = 'R';
> +   if (!sym->ts.u.cl->length
> +   && ((sym->attr.allocatable && sym->attr.target)
> +   || sym->attr.pointer))
> + spec[spec_len++] = '.';
> +   if (!sym->ts.u.cl->length && sym->attr.allocatable)
> + spec[spec_len++] = 'w';
> +   else
> + spec[spec_len++] = 'R';
> spec[spec_len++] = ' ';

Thanks a lot! I was just looking into that function and was quite
confused on what is going there. Are you going to commit the patch?
Also escaping is quite important bit of information so it would be
good to figure out if it really can escape rather than playing safe.

Honza
>   }
>  }

[Patch] (was: Re: [r12-4457 Regression] FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test on Linux/x86_64)

[Tobias Burnus]

Hi Honza,

On 16.10.21 20:23, Jan Hubicka via Gcc-patches wrote:

FAIL: gfortran.dg/deferred_type_param_6.f90   -O1  execution test
FAIL: gfortran.dg/deferred_type_param_6.f90   -Os  execution test

Sorry for the breakage.  This time it seems like bug in Fortran FE
which was previously latent:

__attribute__((fn spec (". . R ")))
void subfunc (character(kind=1)[1:..__result] * & __result, integer(kind=8) * 
.__result)


...

Fortran has for a long time 'character(len=5), allocatable" or
"character(len=*)". In the first case, the "5" can be ignored as both
caller and callee know the length. In the second case, the length is
determined by the argument, but it cannot be changed.

Since a not-that-short while, 'len=:' together with allocatable/pointer
is supported.

In the latter case, the value can be change when the array
association/allocation is changed.

I attached a patch, which was not tested. I am not quite sure whether
the pointer address can actually escape or not - I think cannot but I
played safe.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
Fortran: Fix fn spec for character-returning functions

gcc/fortran/ChangeLog
	* trans-types.c (create_fn_spec): For character-returning functions,
	set the hidden string-length argument to 'R' only when the "len=:",
	i.e. deferred length which goes alongside with allocatable/pointer.

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 220976babb8..637d2c71d01 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -3008,7 +3008,14 @@ create_fn_spec (gfc_symbol *sym, tree fntype)
 	}
   if (sym->ts.type == BT_CHARACTER)
 	{
-	  spec[spec_len++] = 'R';
+	  if (!sym->ts.u.cl->length
+	  && ((sym->attr.allocatable && sym->attr.target)
+		  || sym->attr.pointer))
+	spec[spec_len++] = '.';
+	  if (!sym->ts.u.cl->length && sym->attr.allocatable)
+	spec[spec_len++] = 'w';
+	  else
+	spec[spec_len++] = 'R';
 	  spec[spec_len++] = ' ';
 	}
 }

Re: [r12-4457 Regression] FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test on Linux/x86_64

[Jan Hubicka via Gcc-patches]

Hi,
> 
> FAIL: gfortran.dg/deferred_type_param_6.f90   -O1  execution test
> FAIL: gfortran.dg/deferred_type_param_6.f90   -Os  execution test
Sorry for the breakage.  This time it seems like bug in Fortran FE
which was previously latent:

__attribute__((fn spec (". . R ")))
void subfunc (character(kind=1)[1:..__result] * & __result, integer(kind=8) * 
.__result)
{
  # PT = nonlocal 
  character(kind=1)[1:..__result] * & __result_3(D) = __result;
  # PT = nonlocal null 
  integer(kind=8) * .__result_5(D) = .__result;
  integer(kind=4) _1;

   [local count: 1073741824]:
  *__result_3(D) = 
  # USE = nonlocal escaped { D.4230 } (nonlocal, escaped)
  _1 = _gfortran_compare_string (5, , 5, &"FIVEC"[1]{lb: 1 sz: 1});
  if (_1 != 0)
goto ; [0.04%]
  else
goto ; [99.96%]

   [local count: 429496]:
  # USE = nonlocal escaped null 
  # CLB = nonlocal escaped null 
  _gfortran_stop_numeric (10, 0);

   [local count: 1073312329]:
  *.__result_5(D) = 5;
  return;
}

The fnspec ". . R " specifies that .__result is readonly however we
have:
  *.__result_5(D) = 5;

I am not sure I understand fortran FE well enough to figure out why
it is set so.  The function is declared as:

  function subfunc() result(res)
character(len=:), pointer :: res
res => fifec
if (len(res) /= 5) STOP 9
if (res /= "FIVEC") STOP 10
  end function subfunc

and we indeed optimize load of the result:
-  # USE = nonlocal escaped { D.4252 D.4254 } (nonlocal, escaped)
-  # CLB = nonlocal escaped { D.4254 } (escaped)
+  # USE = nonlocal escaped 
+  # CLB = { D.4254 }
   subfunc (, );
-  .s2_34 = slen.4;
-  # PT = nonlocal escaped null { D.4254 } (escaped)
-  s2_35 = pstr.5;
   pstr.5 ={v} {CLOBBER};

and I think tat is what breaks the testcase (I also verified that
ignoring the fnspec 'R' fixes it).

Honza
> 
> with GCC configured with
> 
> ../../gcc/configure 
> --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-4457/usr
>  --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
> --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
> --enable-libmpx x86_64-linux --disable-bootstrap
> 
> To reproduce:
> 
> $ cd {build_dir}/gcc && make check 
> RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
> --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check 
> RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
> --target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check 
> RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
> --target_board='unix{-m64}'"
> $ cd {build_dir}/gcc && make check 
> RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
> --target_board='unix{-m64\ -march=cascadelake}'"
> 
> (Please do not reply to this email, for question about this report, contact 
> me at skpgkp2 at gmail dot com)

Re: [PATCH v2 0/4] libffi: Sync with upstream

[H.J. Lu via Gcc-patches]

On Sat, Oct 16, 2021 at 10:04 AM David Edelsohn  wrote:
>
> On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu  wrote:
> >
> > On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn  wrote:
> > >
> > > On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu  wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu  wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
> > > > >  wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu  wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Change in the v2 patch:
> > > > > > > > >
> > > > > > > > > 1. Disable static trampolines by default.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > GCC maintained a copy of libffi snapshot from 2009 and 
> > > > > > > > > cherry-picked fixes
> > > > > > > > > from upstream over the last 10+ years.  In the meantime, 
> > > > > > > > > libffi upstream
> > > > > > > > > has been changed significantly with new features, bug fixes 
> > > > > > > > > and new target
> > > > > > > > > support.  Here is a set of patches to sync with libffi 3.4.2 
> > > > > > > > > release and
> > > > > > > > > make it easier to sync with libffi upstream:
> > > > > > > > >
> > > > > > > > > 1. Document how to sync with upstream.
> > > > > > > > > 2. Add scripts to help sync with upstream.
> > > > > > > > > 3. Sync with libffi 3.4.2. This patch is quite big.  It is 
> > > > > > > > > availale at
> > > > > > > > >
> > > > > > > > > https://gitlab.com/x86-gcc/gcc/-/commit/15e80c879c571f79a0e57702848a9df5fba5be2f
> > > > > > > > > 4. Integrate libffi build and testsuite with GCC.
> > > > > > > >
> > > > > > > > How did you test this?  It looks like libgo is the only 
> > > > > > > > consumer of
> > > > > > > > libffi these days.
> > > > > > > > In particular go/libgo seems to be supported on almost all 
> > > > > > > > targets besides
> > > > > > > > darwin/windows - did you test cross and canadian configurations?
> > > > > > >
> > > > > > > I only tested it on Linux/i686 and Linux/x86-64.   My 
> > > > > > > understanding is that
> > > > > > > the upstream libffi works on Darwin and Windows.
> > > > > > >
> > > > > > > > I applaud the attempt to sync to upsteam but I fear you won't 
> > > > > > > > get any "review"
> > > > > > > > of this massive diff.
> > > > > > >
> > > > > > > I believe that it should just work.  Our libffi is very much out 
> > > > > > > of date.
> > > > > >
> > > > > > Yes, you can hope.  And yes, our libffi is out of date.
> > > > > >
> > > > > > Can you please do the extra step to test one weird architecture, 
> > > > > > namely
> > > > > > powerpc64-aix which is available on the compile-farm?
> > > > >
> > > > > I will give it a try and report back.
> > > > >
> > > > > > If that goes well I think it's good to "hope" at this point (and 
> > > > > > plenty of
> > > > > > time to fix fallout until the GCC 12 release).
> > > > > >
> > > > > > Thus OK after the extra testing dance and waiting until early next
> > > > > > week so others can throw in a veto.
> > > >
> > > > I tried to bootstrap GCC master branch on  gcc119.fsffrance.org:
> > > >
> > > > *  MT/MODEL: 8284-22A   
> > > >   *
> > > > * Partition: gcc119 
> > > >   *
> > > > *System: power8-aix.osuosl.org  
> > > >   *
> > > > *   O/S: AIX V7.2 7200-04-03-2038
> > > >
> > > > I configured GCC with
> > > >
> > > > --with-as=/usr/bin/as --with-ld=/usr/bin/ld
> > > > --enable-version-specific-runtime-libs --disable-nls
> > > > --enable-decimal-float=dpd --disable-libstdcxx-pch --disable-werror
> > > > --enable-__cxa_atexit --with-gmp=/opt/cfarm --with-mpfr=/opt/cfarm
> > > > --with-mpc=/opt/cfarm --with-isl=/opt/cfarm --prefix=/opt/freeware
> > > > --with-local-prefix=/opt/freeware --enable-languages=c,c++,go
> > > >
> > > > I got
> > > >
> > > > g++   -g -DIN_GCC -fno-exceptions -fno-rtti 
> > > > -fasynchronous-unwind-tables -W
> > > > -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> > > > -Wmissing-format-at
> > > > tribute -Woverloaded-virtual -pedantic -Wno-long-long 
> > > > -Wno-variadic-macros -Wno-
> > > > overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE 
> > > > -static-libstd
> > > > c++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o 
> > > > build/genenums \
> > > > build/genenums.o build/read-md.o build/errors.o 
> > > > ../build-powerpc-ibm-aix7.2.
> > > > 4.0/libiberty/libiberty.a
> > > > ld: 0711-317 ERROR: Undefined symbol: lexer_line
> > > > ld: 0711-317 ERROR: Undefined symbol: .yylex(char const**)
> > > > ld: 0711-317 ERROR: Undefined symbol: .yybegin(char const*)
> > > > ld: 0711-317 ERROR: Undefined symbol: lexer_toplevel_done
> > > > ld: 0711-317 ERROR: 

Re: [PATCH v2 0/4] libffi: Sync with upstream

[David Edelsohn via Gcc-patches]

On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu  wrote:
>
> On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn  wrote:
> >
> > On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu  wrote:
> > >
> > > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu  wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
> > > >  wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu  wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Change in the v2 patch:
> > > > > > > >
> > > > > > > > 1. Disable static trampolines by default.
> > > > > > > >
> > > > > > > >
> > > > > > > > GCC maintained a copy of libffi snapshot from 2009 and 
> > > > > > > > cherry-picked fixes
> > > > > > > > from upstream over the last 10+ years.  In the meantime, libffi 
> > > > > > > > upstream
> > > > > > > > has been changed significantly with new features, bug fixes and 
> > > > > > > > new target
> > > > > > > > support.  Here is a set of patches to sync with libffi 3.4.2 
> > > > > > > > release and
> > > > > > > > make it easier to sync with libffi upstream:
> > > > > > > >
> > > > > > > > 1. Document how to sync with upstream.
> > > > > > > > 2. Add scripts to help sync with upstream.
> > > > > > > > 3. Sync with libffi 3.4.2. This patch is quite big.  It is 
> > > > > > > > availale at
> > > > > > > >
> > > > > > > > https://gitlab.com/x86-gcc/gcc/-/commit/15e80c879c571f79a0e57702848a9df5fba5be2f
> > > > > > > > 4. Integrate libffi build and testsuite with GCC.
> > > > > > >
> > > > > > > How did you test this?  It looks like libgo is the only consumer 
> > > > > > > of
> > > > > > > libffi these days.
> > > > > > > In particular go/libgo seems to be supported on almost all 
> > > > > > > targets besides
> > > > > > > darwin/windows - did you test cross and canadian configurations?
> > > > > >
> > > > > > I only tested it on Linux/i686 and Linux/x86-64.   My understanding 
> > > > > > is that
> > > > > > the upstream libffi works on Darwin and Windows.
> > > > > >
> > > > > > > I applaud the attempt to sync to upsteam but I fear you won't get 
> > > > > > > any "review"
> > > > > > > of this massive diff.
> > > > > >
> > > > > > I believe that it should just work.  Our libffi is very much out of 
> > > > > > date.
> > > > >
> > > > > Yes, you can hope.  And yes, our libffi is out of date.
> > > > >
> > > > > Can you please do the extra step to test one weird architecture, 
> > > > > namely
> > > > > powerpc64-aix which is available on the compile-farm?
> > > >
> > > > I will give it a try and report back.
> > > >
> > > > > If that goes well I think it's good to "hope" at this point (and 
> > > > > plenty of
> > > > > time to fix fallout until the GCC 12 release).
> > > > >
> > > > > Thus OK after the extra testing dance and waiting until early next
> > > > > week so others can throw in a veto.
> > >
> > > I tried to bootstrap GCC master branch on  gcc119.fsffrance.org:
> > >
> > > *  MT/MODEL: 8284-22A 
> > > *
> > > * Partition: gcc119   
> > > *
> > > *System: power8-aix.osuosl.org
> > > *
> > > *   O/S: AIX V7.2 7200-04-03-2038
> > >
> > > I configured GCC with
> > >
> > > --with-as=/usr/bin/as --with-ld=/usr/bin/ld
> > > --enable-version-specific-runtime-libs --disable-nls
> > > --enable-decimal-float=dpd --disable-libstdcxx-pch --disable-werror
> > > --enable-__cxa_atexit --with-gmp=/opt/cfarm --with-mpfr=/opt/cfarm
> > > --with-mpc=/opt/cfarm --with-isl=/opt/cfarm --prefix=/opt/freeware
> > > --with-local-prefix=/opt/freeware --enable-languages=c,c++,go
> > >
> > > I got
> > >
> > > g++   -g -DIN_GCC -fno-exceptions -fno-rtti 
> > > -fasynchronous-unwind-tables -W
> > > -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> > > -Wmissing-format-at
> > > tribute -Woverloaded-virtual -pedantic -Wno-long-long 
> > > -Wno-variadic-macros -Wno-
> > > overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE 
> > > -static-libstd
> > > c++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o 
> > > build/genenums \
> > > build/genenums.o build/read-md.o build/errors.o 
> > > ../build-powerpc-ibm-aix7.2.
> > > 4.0/libiberty/libiberty.a
> > > ld: 0711-317 ERROR: Undefined symbol: lexer_line
> > > ld: 0711-317 ERROR: Undefined symbol: .yylex(char const**)
> > > ld: 0711-317 ERROR: Undefined symbol: .yybegin(char const*)
> > > ld: 0711-317 ERROR: Undefined symbol: lexer_toplevel_done
> > > ld: 0711-317 ERROR: Undefined symbol: .yyend()
> > > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more 
> > > information.
> > > collect2: error: ld returned 8 exit status
> > > Makefile:3000: recipe for target 'build/gengtype' failed
> > > gmake[5]: *** [build/gengtype] Error 1
> > >
> > > 

Re: [PATCH] Ranger : Do not process abnormal ssa-names.

[Iain Sandoe via Gcc-patches]

> On 16 Oct 2021, at 10:27, Andrew Pinski via Gcc-patches 
>  wrote:
> 
> On Fri, Oct 15, 2021 at 6:53 AM Andrew MacLeod via Gcc-patches
>  wrote:
>> 
>> I've been looking at the pathological time issue ranger has with the
>> testcase from, uh..  PR 97623 I think.  I've lost the details, but
>> kept the file since it was showing unpleasant behaviour.
>> 
>> Most of the time is spent in callbacks from substitute_and_fold to
>> value_on_edge()  dealing with PHI results and arguments.  Turns out, its
>> virtually all wasted time dealing with SSA_NAMES with the
>> OCCURS_IN_ABNORMAL_PHI flag set..
>> 
>> This patch tells ranger not to consider any SSA_NAMEs which occur in
>> abnormal PHIs.  This reduces the memory footprint of all the caches, and
>> also has a ripple effect with the new threader code which uses the GORI
>> exports and imports tables, making it faster as well as no ssa-name with
>> the abnormal flag set will be entered into the tables.
>> 
>> That alone was not quite enough, as all the sheer volume of call backs
>> still took time,  so I added checks in the value_of_* class of routines
>> used by substitute_and_fold to indicate there is no constant value
>> available for any SSA_NAME with that flag set.
>> 
>> On my x86_64 box, before this change, that test case looked like:
>> 
>> tree VRP   :   7.76 (  4%)   0.23 ( 5%)   8.02
>> (  4%)   537k (  0%)
>> tree VRP threader  :   7.20 (  4%)   0.08 (  2%) 7.28 (
>> 4%)   392k (  0%)
>> tree Early VRP :  39.22 ( 22%)   0.07 (  2%) 39.44 (
>> 22%)  1142k (  0%)
>> 
>> And with this patch , the results are:
>> 
>>  tree VRP   :   7.57 (  6%)   0.26 ( 5%)   7.85
>> (  6%)   537k (  0%)
>>  tree VRP threader  :   0.62 (  0%)   0.02 ( 0%)   0.65
>> (  0%)   392k (  0%)
>>  tree Early VRP :   4.00 (  3%)   0.01 ( 0%)   4.03
>> (  3%)  1142k (  0%)
>> 
>> Which is a significant improvement, both for EVRP and the threader..
>> 
>> The patch adjusts the ranger folder, as well as the hybrid folder.
>> 
>> bootstrapped on x86_64-pc-linux-gnu with no regressions and no missed
>> cases that I have been able to find.
> 
> Did you test it with go enabled?
> Because others and myself are now running into a bootstrap failure
> most likely due to this patch.
> The number of SSA_NAME_OCCURS_IN_ABNORMAL_PHI in go is increased due
> to -fnon-call-exceptions being true there.

and, presumably for similar reasons, there are around 25 Ada regressions on 
several platforms.
the acats output is probably not as helpful as Andrew’s ICE.
Iain

(possibly, there are some D / libphobos regressions too - but I didn’t bisect 
those)

> 
> Thanks,
> Andrew Pinski
> PS here is the ICE for me:
> libtool: compile:
> /home/apinski/src/upstream-gcc/gcc/objdir/./gcc/gccgo
> -B/home/apinski/src/upstream-gcc/gcc/objdir/./gcc/
> -B/home/apinski/upstream-gcc/x86_64-pc-linux-gnu/bin/
> -B/home/apinski/upstream-gcc/x86_64-pc-linux-gnu/lib/ -isystem
> /home/apinski/upstream-gcc/x86_64-pc-linux-gnu/include -isystem
> /home/apinski/upstream-gcc/x86_64-pc-linux-gnu/sys-include
> -fchecking=1 -minline-all-stringops -O2 -g -m32 -I . -c
> -fgo-pkgpath=cmd/go/internal/modget
> /home/apinski/src/upstream-gcc/gcc/libgo/go/cmd/go/internal/modget/get.go
> /home/apinski/src/upstream-gcc/gcc/libgo/go/cmd/go/internal/modget/query.go
> -o cmd/go/internal/modget.o
> during GIMPLE pass: evrp
> In function ‘cmd/go/internal/modget.resolver.resolveQueries’:
> go1: internal compiler error: tree check: expected class ‘type’, have
> ‘exceptional’ (error_mark) in useless_type_conversion_p, at
> gimple-expr.c:87
> 0x862719 tree_class_check_failed(tree_node const*, tree_code_class,
> char const*, int, char const*)
>/home/apinski/src/upstream-gcc/gcc/gcc/tree.c:8739
> 0x7910ed tree_class_check(tree_node*, tree_code_class, char const*,
> int, char const*)
>/home/apinski/src/upstream-gcc/gcc/gcc/tree.h:3556
> 0x7910ed useless_type_conversion_p(tree_node*, tree_node*)
>/home/apinski/src/upstream-gcc/gcc/gcc/gimple-expr.c:87
> 0xf81a58 verify_gimple_phi
>/home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.c:5128
> 0xf81a58 verify_gimple_in_cfg(function*, bool)
>/home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.c:5457
> 0xe54a57 execute_function_todo
>/home/apinski/src/upstream-gcc/gcc/gcc/passes.c:2042
> 0xe5546e execute_todo
>/home/apinski/src/upstream-gcc/gcc/gcc/passes.c:2096
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> 
>> 
>> I don't want to push it quite yet as I wanted feedback to make sure we
>> don't actually do anything I'm not aware of with SSA_NAMES which have
>> the ABNORMAL_PHI flag set.  Most of the code i can find in VRP and
>> vr-values appears to punt, so I presume not even considering 

[r12-4457 Regression] FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

99b287b8ef51a0be52f7400879a619dc5f993f31 is the first bad commit
commit 99b287b8ef51a0be52f7400879a619dc5f993f31
Author: Jan Hubicka 
Date:   Sat Oct 16 14:45:06 2021 +0200

Fix wrong code in ldost-strlen-1.c

caused

FAIL: gfortran.dg/deferred_type_param_6.f90   -O1  execution test
FAIL: gfortran.dg/deferred_type_param_6.f90   -Os  execution test

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-4457/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: Fix wrong code in ldist-strlen-1.c

[H.J. Lu via Gcc-patches]

On Sat, Oct 16, 2021 at 8:46 AM Richard Biener via Gcc-patches
 wrote:
>
> On October 16, 2021 2:47:51 PM GMT+02:00, Jan Hubicka via Gcc-patches 
>  wrote:
> >Hi,
> >while updating compute_points_to_sets I missed that the code not only
> >sets the nonlocal/escaped flags but also initializes pt.  With my
> >previous change if uses_global_memory is false pt is not updated
> >correctly which may lead to wrong code.
> >
> >This is fixed by the following patch I comitted to avoid strange
> >misoptimizations.
> >
> >Bootstrapped/regtested x86_64-linux and also tested with LTO.

This caused:

FAIL: gfortran.dg/deferred_type_param_6.f90   -O1  execution test

on Linux/x86-64.  -march=cascadelake may be needed to reproduce it.

> OK.
>
> Richard.
>
> >Honza
> >
> >gcc/ChangeLog:
> >
> >   PR tree-optimization/102720
> >   * tree-ssa-structalias.c (compute_points_to_sets): Fix producing
> >   of call used and clobbered sets.
> >
> >diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
> >index 6f12a66ee0d..2e6513bb72a 100644
> >--- a/gcc/tree-ssa-structalias.c
> >+++ b/gcc/tree-ssa-structalias.c
> >@@ -7541,17 +7541,18 @@ compute_points_to_sets (void)
> > determine_global_memory_access (stmt, NULL,
> > _global_memory,
> > _global_memory);
> >-if (!uses_global_memory)
> >-  ;
> >-else if ((vi = lookup_call_use_vi (stmt)) != NULL)
> >+if ((vi = lookup_call_use_vi (stmt)) != NULL)
> >   {
> > *pt = find_what_var_points_to (cfun->decl, vi);
> > /* Escaped (and thus nonlocal) variables are always
> >implicitly used by calls.  */
> > /* ???  ESCAPED can be empty even though NONLOCAL
> >always escaped.  */
> >-pt->nonlocal = uses_global_memory;
> >-pt->escaped = uses_global_memory;
> >+if (uses_global_memory)
> >+  {
> >+pt->nonlocal = uses_global_memory;
> >+pt->escaped = uses_global_memory;
> >+  }
> >   }
> > else if (uses_global_memory)
> >   {
> >@@ -7572,17 +7573,18 @@ compute_points_to_sets (void)
> > determine_global_memory_access (stmt, _global_memory,
> > NULL, NULL);
> >
> >-if (!writes_global_memory)
> >-  ;
> >-else if ((vi = lookup_call_clobber_vi (stmt)) != NULL)
> >+if ((vi = lookup_call_clobber_vi (stmt)) != NULL)
> >   {
> > *pt = find_what_var_points_to (cfun->decl, vi);
> > /* Escaped (and thus nonlocal) variables are always
> >implicitly clobbered by calls.  */
> > /* ???  ESCAPED can be empty even though NONLOCAL
> >always escaped.  */
> >-pt->nonlocal = writes_global_memory;
> >-pt->escaped = writes_global_memory;
> >+if (writes_global_memory)
> >+  {
> >+pt->nonlocal = writes_global_memory;
> >+pt->escaped = writes_global_memory;
> >+  }
> >   }
> > else if (writes_global_memory)
> >   {
>


-- 
H.J.

[committed] wwwdocs: Switch www.dwarfstd.org to https

[Gerald Pfeifer]

The www.dwarfstd.org webmasters suggested (via a redirect) to adjust
http links to https.

---
 htdocs/gcc-4.7/changes.html | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-4.7/changes.html b/htdocs/gcc-4.7/changes.html
index 5103e5ee..dae1735d 100644
--- a/htdocs/gcc-4.7/changes.html
+++ b/htdocs/gcc-4.7/changes.html
@@ -994,13 +994,13 @@ void set_portb (uint8_t value)
 GCC now supports various new GNU extensions to the DWARF debugging
 information format, like
 http://www.dwarfstd.org/ShowIssue.php?issue=100909.1;>entry
+href="https://www.dwarfstd.org/ShowIssue.php?issue=100909.1;>entry
 value and http://www.dwarfstd.org/ShowIssue.php?issue=100909.2;>call
+href="https://www.dwarfstd.org/ShowIssue.php?issue=100909.2;>call
 site information, http://www.dwarfstd.org/ShowIssue.php?issue=140425.1;>typed DWARF 
stack
+href="https://www.dwarfstd.org/ShowIssue.php?issue=140425.1;>typed DWARF 
stack
 or http://www.dwarfstd.org/ShowIssue.php?issue=110722.1;>a
+href="https://www.dwarfstd.org/ShowIssue.php?issue=110722.1;>a
 more compact macro representation.  Support for these extensions
 has been added to GDB 7.4. They can be disabled through the
 -gstrict-dwarf command-line option.
-- 
2.33.0

[committed] wwwdocs: Update Co-Authored-By reference on GitHub

[Gerald Pfeifer]

---
 htdocs/codingconventions.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index 21cc95de..e4d30510 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -146,7 +146,7 @@ a large batch of changes.
 changelog_file_comment - line that follows a 
changelog_file with description of changes in the file;
 must start with \t
 co_authored_by - https://docs.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors;>GitHub
 format
+
href="https://docs.github.com/en/github/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors;>GitHub
 format
 for a Co-Authored-By
 
 
-- 
2.33.0

Re: Fix wrong code in ldist-strlen-1.c

[Richard Biener via Gcc-patches]

On October 16, 2021 2:47:51 PM GMT+02:00, Jan Hubicka via Gcc-patches 
 wrote:
>Hi,
>while updating compute_points_to_sets I missed that the code not only
>sets the nonlocal/escaped flags but also initializes pt.  With my
>previous change if uses_global_memory is false pt is not updated
>correctly which may lead to wrong code.
>
>This is fixed by the following patch I comitted to avoid strange
>misoptimizations.
>
>Bootstrapped/regtested x86_64-linux and also tested with LTO.

OK. 

Richard. 

>Honza
>
>gcc/ChangeLog:
>
>   PR tree-optimization/102720
>   * tree-ssa-structalias.c (compute_points_to_sets): Fix producing
>   of call used and clobbered sets.
>
>diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
>index 6f12a66ee0d..2e6513bb72a 100644
>--- a/gcc/tree-ssa-structalias.c
>+++ b/gcc/tree-ssa-structalias.c
>@@ -7541,17 +7541,18 @@ compute_points_to_sets (void)
> determine_global_memory_access (stmt, NULL,
> _global_memory,
> _global_memory);
>-if (!uses_global_memory)
>-  ;
>-else if ((vi = lookup_call_use_vi (stmt)) != NULL)
>+if ((vi = lookup_call_use_vi (stmt)) != NULL)
>   {
> *pt = find_what_var_points_to (cfun->decl, vi);
> /* Escaped (and thus nonlocal) variables are always
>implicitly used by calls.  */
> /* ???  ESCAPED can be empty even though NONLOCAL
>always escaped.  */
>-pt->nonlocal = uses_global_memory;
>-pt->escaped = uses_global_memory;
>+if (uses_global_memory)
>+  {
>+pt->nonlocal = uses_global_memory;
>+pt->escaped = uses_global_memory;
>+  }
>   }
> else if (uses_global_memory)
>   {
>@@ -7572,17 +7573,18 @@ compute_points_to_sets (void)
> determine_global_memory_access (stmt, _global_memory,
> NULL, NULL);
> 
>-if (!writes_global_memory)
>-  ;
>-else if ((vi = lookup_call_clobber_vi (stmt)) != NULL)
>+if ((vi = lookup_call_clobber_vi (stmt)) != NULL)
>   {
> *pt = find_what_var_points_to (cfun->decl, vi);
> /* Escaped (and thus nonlocal) variables are always
>implicitly clobbered by calls.  */
> /* ???  ESCAPED can be empty even though NONLOCAL
>always escaped.  */
>-pt->nonlocal = writes_global_memory;
>-pt->escaped = writes_global_memory;
>+if (writes_global_memory)
>+  {
>+pt->nonlocal = writes_global_memory;
>+pt->escaped = writes_global_memory;
>+  }
>   }
> else if (writes_global_memory)
>   {

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

[Jonathan Wakely via Gcc-patches]

On Sat, 16 Oct 2021, 14:49 François Dumont via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

> Hi
>
>  Here is the new proposal. My only concern is that we are also using
> hash or equal_to functors in the guard destructor.
>


Can we catch any exception there, invalidate all iterators, and not rethrow
the exception?


>  I am going to enhance merge normal implementation to make use of
> the cached hash code when hash functors are the same between the source
> and destination of nodes. Maybe I'll be able to make use of it in Debug
> implementation too.
>
> François
>
>
> On 14/10/21 10:23 am, Jonathan Wakely wrote:
> > On Wed, 13 Oct 2021 at 18:10, François Dumont via Libstdc++
> >  wrote:
> >> Hi
> >>
> >>   libstdc++: [_GLIBCXX_DEBUG] Implement unordered container merge
> >>
> >>   The _GLIBCXX_DEBUG unordered containers need a dedicated merge
> >> implementation
> >>   so that any existing iterator on the transfered nodes is properly
> >> invalidated.
> >>
> >>   Add typedef/using declaration for everything used as-is from
> normal
> >> implementation.
> >>
> >>   libstdc++-v3/ChangeLog:
> >>
> >>   * include/debug/safe_container.h (_Safe_container<>): Make
> >> all methods
> >>   protected.
> >>   * include/debug/safe_unordered_container.h
> >>   (_Safe_unordered_container<>::_M_invalide_all): Make
> public.
> >>   (_Safe_unordered_container<>::_M_invalide_if): Likewise.
> >> (_Safe_unordered_container<>::_M_invalide_local_if): Likewise.
> >>   * include/debug/unordered_map
> >>   (unordered_map<>::mapped_type, pointer, const_pointer):
> New
> >> typedef.
> >>   (unordered_map<>::reference, const_reference,
> >> difference_type): New typedef.
> >>   (unordered_map<>::get_allocator, empty, size, max_size):
> >> Add usings.
> >>   (unordered_map<>::bucket_count, max_bucket_count, bucket):
> >> Add usings.
> >>   (unordered_map<>::hash_function, key_equal, count,
> >> contains): Add usings.
> >>   (unordered_map<>::operator[], at, rehash, reserve): Add
> usings.
> >>   (unordered_map<>::merge): New.
> >>   (unordered_multimap<>::mapped_type, pointer,
> >> const_pointer): New typedef.
> >>   (unordered_multimap<>::reference, const_reference,
> >> difference_type): New typedef.
> >>   (unordered_multimap<>::get_allocator, empty, size,
> >> max_size): Add usings.
> >>   (unordered_multimap<>::bucket_count, max_bucket_count,
> >> bucket): Add usings.
> >>   (unordered_multimap<>::hash_function, key_equal, count,
> >> contains): Add usings.
> >>   (unordered_multimap<>::rehash, reserve): Add usings.
> >>   (unordered_multimap<>::merge): New.
> >>   * include/debug/unordered_set
> >>   (unordered_set<>::mapped_type, pointer, const_pointer):
> New
> >> typedef.
> >>   (unordered_set<>::reference, const_reference,
> >> difference_type): New typedef.
> >>   (unordered_set<>::get_allocator, empty, size, max_size):
> >> Add usings.
> >>   (unordered_set<>::bucket_count, max_bucket_count, bucket):
> >> Add usings.
> >>   (unordered_set<>::hash_function, key_equal, count,
> >> contains): Add usings.
> >>   (unordered_set<>::rehash, reserve): Add usings.
> >>   (unordered_set<>::merge): New.
> >>   (unordered_multiset<>::mapped_type, pointer,
> >> const_pointer): New typedef.
> >>   (unordered_multiset<>::reference, const_reference,
> >> difference_type): New typedef.
> >>   (unordered_multiset<>::get_allocator, empty, size,
> >> max_size): Add usings.
> >>   (unordered_multiset<>::bucket_count, max_bucket_count,
> >> bucket): Add usings.
> >>   (unordered_multiset<>::hash_function, key_equal, count,
> >> contains): Add usings.
> >>   (unordered_multiset<>::rehash, reserve): Add usings.
> >>   (unordered_multiset<>::merge): New.
> >>   *
> >> testsuite/23_containers/unordered_map/debug/merge1_neg.cc: New test.
> >>   *
> >> testsuite/23_containers/unordered_map/debug/merge2_neg.cc: New test.
> >>   *
> >> testsuite/23_containers/unordered_map/debug/merge3_neg.cc: New test.
> >>   *
> >> testsuite/23_containers/unordered_map/debug/merge4_neg.cc: New test.
> >>   *
> >> testsuite/23_containers/unordered_multimap/debug/merge1_neg.cc: New
> test.
> >>   *
> >> testsuite/23_containers/unordered_multimap/debug/merge2_neg.cc: New
> test.
> >>   *
> >> testsuite/23_containers/unordered_multimap/debug/merge3_neg.cc: New
> test.
> >>   *
> >> testsuite/23_containers/unordered_multimap/debug/merge4_neg.cc: New
> test.
> >>   *
> >> 

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

[François Dumont via Gcc-patches]

Hi

    Here is the new proposal. My only concern is that we are also using 
hash or equal_to functors in the guard destructor.


    I am going to enhance merge normal implementation to make use of 
the cached hash code when hash functors are the same between the source 
and destination of nodes. Maybe I'll be able to make use of it in Debug 
implementation too.


François


On 14/10/21 10:23 am, Jonathan Wakely wrote:

On Wed, 13 Oct 2021 at 18:10, François Dumont via Libstdc++
 wrote:

Hi

  libstdc++: [_GLIBCXX_DEBUG] Implement unordered container merge

  The _GLIBCXX_DEBUG unordered containers need a dedicated merge
implementation
  so that any existing iterator on the transfered nodes is properly
invalidated.

  Add typedef/using declaration for everything used as-is from normal
implementation.

  libstdc++-v3/ChangeLog:

  * include/debug/safe_container.h (_Safe_container<>): Make
all methods
  protected.
  * include/debug/safe_unordered_container.h
  (_Safe_unordered_container<>::_M_invalide_all): Make public.
  (_Safe_unordered_container<>::_M_invalide_if): Likewise.
(_Safe_unordered_container<>::_M_invalide_local_if): Likewise.
  * include/debug/unordered_map
  (unordered_map<>::mapped_type, pointer, const_pointer): New
typedef.
  (unordered_map<>::reference, const_reference,
difference_type): New typedef.
  (unordered_map<>::get_allocator, empty, size, max_size):
Add usings.
  (unordered_map<>::bucket_count, max_bucket_count, bucket):
Add usings.
  (unordered_map<>::hash_function, key_equal, count,
contains): Add usings.
  (unordered_map<>::operator[], at, rehash, reserve): Add usings.
  (unordered_map<>::merge): New.
  (unordered_multimap<>::mapped_type, pointer,
const_pointer): New typedef.
  (unordered_multimap<>::reference, const_reference,
difference_type): New typedef.
  (unordered_multimap<>::get_allocator, empty, size,
max_size): Add usings.
  (unordered_multimap<>::bucket_count, max_bucket_count,
bucket): Add usings.
  (unordered_multimap<>::hash_function, key_equal, count,
contains): Add usings.
  (unordered_multimap<>::rehash, reserve): Add usings.
  (unordered_multimap<>::merge): New.
  * include/debug/unordered_set
  (unordered_set<>::mapped_type, pointer, const_pointer): New
typedef.
  (unordered_set<>::reference, const_reference,
difference_type): New typedef.
  (unordered_set<>::get_allocator, empty, size, max_size):
Add usings.
  (unordered_set<>::bucket_count, max_bucket_count, bucket):
Add usings.
  (unordered_set<>::hash_function, key_equal, count,
contains): Add usings.
  (unordered_set<>::rehash, reserve): Add usings.
  (unordered_set<>::merge): New.
  (unordered_multiset<>::mapped_type, pointer,
const_pointer): New typedef.
  (unordered_multiset<>::reference, const_reference,
difference_type): New typedef.
  (unordered_multiset<>::get_allocator, empty, size,
max_size): Add usings.
  (unordered_multiset<>::bucket_count, max_bucket_count,
bucket): Add usings.
  (unordered_multiset<>::hash_function, key_equal, count,
contains): Add usings.
  (unordered_multiset<>::rehash, reserve): Add usings.
  (unordered_multiset<>::merge): New.
  *
testsuite/23_containers/unordered_map/debug/merge1_neg.cc: New test.
  *
testsuite/23_containers/unordered_map/debug/merge2_neg.cc: New test.
  *
testsuite/23_containers/unordered_map/debug/merge3_neg.cc: New test.
  *
testsuite/23_containers/unordered_map/debug/merge4_neg.cc: New test.
  *
testsuite/23_containers/unordered_multimap/debug/merge1_neg.cc: New test.
  *
testsuite/23_containers/unordered_multimap/debug/merge2_neg.cc: New test.
  *
testsuite/23_containers/unordered_multimap/debug/merge3_neg.cc: New test.
  *
testsuite/23_containers/unordered_multimap/debug/merge4_neg.cc: New test.
  *
testsuite/23_containers/unordered_multiset/debug/merge1_neg.cc: New test.
  *
testsuite/23_containers/unordered_multiset/debug/merge2_neg.cc: New test.
  *
testsuite/23_containers/unordered_multiset/debug/merge3_neg.cc: New test.
  *
testsuite/23_containers/unordered_multiset/debug/merge4_neg.cc: New test.
  *
testsuite/23_containers/unordered_set/debug/merge1_neg.cc: New test.
  *
testsuite/23_containers/unordered_set/debug/merge2_neg.cc: New test.
  *
testsuite/23_containers/unordered_set/debug/merge3_neg.cc: New test.
  *
testsuite/23_containers/unordered_set/debug/merge4_neg.cc: New test.
  * 

Fix wrong code in ldist-strlen-1.c

[Jan Hubicka via Gcc-patches]

Hi,
while updating compute_points_to_sets I missed that the code not only
sets the nonlocal/escaped flags but also initializes pt.  With my
previous change if uses_global_memory is false pt is not updated
correctly which may lead to wrong code.

This is fixed by the following patch I comitted to avoid strange
misoptimizations.

Bootstrapped/regtested x86_64-linux and also tested with LTO.

Honza

gcc/ChangeLog:

PR tree-optimization/102720
* tree-ssa-structalias.c (compute_points_to_sets): Fix producing
of call used and clobbered sets.

diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 6f12a66ee0d..2e6513bb72a 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -7541,17 +7541,18 @@ compute_points_to_sets (void)
  determine_global_memory_access (stmt, NULL,
  _global_memory,
  _global_memory);
- if (!uses_global_memory)
-   ;
- else if ((vi = lookup_call_use_vi (stmt)) != NULL)
+ if ((vi = lookup_call_use_vi (stmt)) != NULL)
{
  *pt = find_what_var_points_to (cfun->decl, vi);
  /* Escaped (and thus nonlocal) variables are always
 implicitly used by calls.  */
  /* ???  ESCAPED can be empty even though NONLOCAL
 always escaped.  */
- pt->nonlocal = uses_global_memory;
- pt->escaped = uses_global_memory;
+ if (uses_global_memory)
+   {
+ pt->nonlocal = uses_global_memory;
+ pt->escaped = uses_global_memory;
+   }
}
  else if (uses_global_memory)
{
@@ -7572,17 +7573,18 @@ compute_points_to_sets (void)
  determine_global_memory_access (stmt, _global_memory,
  NULL, NULL);
 
- if (!writes_global_memory)
-   ;
- else if ((vi = lookup_call_clobber_vi (stmt)) != NULL)
+ if ((vi = lookup_call_clobber_vi (stmt)) != NULL)
{
  *pt = find_what_var_points_to (cfun->decl, vi);
  /* Escaped (and thus nonlocal) variables are always
 implicitly clobbered by calls.  */
  /* ???  ESCAPED can be empty even though NONLOCAL
 always escaped.  */
- pt->nonlocal = writes_global_memory;
- pt->escaped = writes_global_memory;
+ if (writes_global_memory)
+   {
+ pt->nonlocal = writes_global_memory;
+ pt->escaped = writes_global_memory;
+   }
}
  else if (writes_global_memory)
{

Re: [PATCH v2 0/4] libffi: Sync with upstream

[H.J. Lu via Gcc-patches]

On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn  wrote:
>
> On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu  wrote:
> >
> > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu  wrote:
> > >
> > > On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
> > >  wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu  wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu  wrote:
> > > > > > >
> > > > > > > Change in the v2 patch:
> > > > > > >
> > > > > > > 1. Disable static trampolines by default.
> > > > > > >
> > > > > > >
> > > > > > > GCC maintained a copy of libffi snapshot from 2009 and 
> > > > > > > cherry-picked fixes
> > > > > > > from upstream over the last 10+ years.  In the meantime, libffi 
> > > > > > > upstream
> > > > > > > has been changed significantly with new features, bug fixes and 
> > > > > > > new target
> > > > > > > support.  Here is a set of patches to sync with libffi 3.4.2 
> > > > > > > release and
> > > > > > > make it easier to sync with libffi upstream:
> > > > > > >
> > > > > > > 1. Document how to sync with upstream.
> > > > > > > 2. Add scripts to help sync with upstream.
> > > > > > > 3. Sync with libffi 3.4.2. This patch is quite big.  It is 
> > > > > > > availale at
> > > > > > >
> > > > > > > https://gitlab.com/x86-gcc/gcc/-/commit/15e80c879c571f79a0e57702848a9df5fba5be2f
> > > > > > > 4. Integrate libffi build and testsuite with GCC.
> > > > > >
> > > > > > How did you test this?  It looks like libgo is the only consumer of
> > > > > > libffi these days.
> > > > > > In particular go/libgo seems to be supported on almost all targets 
> > > > > > besides
> > > > > > darwin/windows - did you test cross and canadian configurations?
> > > > >
> > > > > I only tested it on Linux/i686 and Linux/x86-64.   My understanding 
> > > > > is that
> > > > > the upstream libffi works on Darwin and Windows.
> > > > >
> > > > > > I applaud the attempt to sync to upsteam but I fear you won't get 
> > > > > > any "review"
> > > > > > of this massive diff.
> > > > >
> > > > > I believe that it should just work.  Our libffi is very much out of 
> > > > > date.
> > > >
> > > > Yes, you can hope.  And yes, our libffi is out of date.
> > > >
> > > > Can you please do the extra step to test one weird architecture, namely
> > > > powerpc64-aix which is available on the compile-farm?
> > >
> > > I will give it a try and report back.
> > >
> > > > If that goes well I think it's good to "hope" at this point (and plenty 
> > > > of
> > > > time to fix fallout until the GCC 12 release).
> > > >
> > > > Thus OK after the extra testing dance and waiting until early next
> > > > week so others can throw in a veto.
> >
> > I tried to bootstrap GCC master branch on  gcc119.fsffrance.org:
> >
> > *  MT/MODEL: 8284-22A   
> >   *
> > * Partition: gcc119 
> >   *
> > *System: power8-aix.osuosl.org  
> >   *
> > *   O/S: AIX V7.2 7200-04-03-2038
> >
> > I configured GCC with
> >
> > --with-as=/usr/bin/as --with-ld=/usr/bin/ld
> > --enable-version-specific-runtime-libs --disable-nls
> > --enable-decimal-float=dpd --disable-libstdcxx-pch --disable-werror
> > --enable-__cxa_atexit --with-gmp=/opt/cfarm --with-mpfr=/opt/cfarm
> > --with-mpc=/opt/cfarm --with-isl=/opt/cfarm --prefix=/opt/freeware
> > --with-local-prefix=/opt/freeware --enable-languages=c,c++,go
> >
> > I got
> >
> > g++   -g -DIN_GCC -fno-exceptions -fno-rtti 
> > -fasynchronous-unwind-tables -W
> > -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> > -Wmissing-format-at
> > tribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> > -Wno-
> > overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE 
> > -static-libstd
> > c++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o build/genenums \
> > build/genenums.o build/read-md.o build/errors.o 
> > ../build-powerpc-ibm-aix7.2.
> > 4.0/libiberty/libiberty.a
> > ld: 0711-317 ERROR: Undefined symbol: lexer_line
> > ld: 0711-317 ERROR: Undefined symbol: .yylex(char const**)
> > ld: 0711-317 ERROR: Undefined symbol: .yybegin(char const*)
> > ld: 0711-317 ERROR: Undefined symbol: lexer_toplevel_done
> > ld: 0711-317 ERROR: Undefined symbol: .yyend()
> > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more 
> > information.
> > collect2: error: ld returned 8 exit status
> > Makefile:3000: recipe for target 'build/gengtype' failed
> > gmake[5]: *** [build/gengtype] Error 1
> >
> > David, is there an instruction to bootstrap GCC on AIX?
>
> The CompileFarm page in the GCC wiki has instructions under "build tips":
>
> https://gcc.gnu.org/wiki/CompileFarm#Services_and_software_installed_on_farm_machines
>
> The error that you show might be due to not having /opt/freeware/bin
> first in your path and the 

Re: [PATCH] Ranger : Do not process abnormal ssa-names.

[Andrew Pinski via Gcc-patches]

On Fri, Oct 15, 2021 at 6:53 AM Andrew MacLeod via Gcc-patches
 wrote:
>
> I've been looking at the pathological time issue ranger has with the
> testcase from, uh..  PR 97623 I think.  I've lost the details, but
> kept the file since it was showing unpleasant behaviour.
>
> Most of the time is spent in callbacks from substitute_and_fold to
> value_on_edge()  dealing with PHI results and arguments.  Turns out, its
> virtually all wasted time dealing with SSA_NAMES with the
> OCCURS_IN_ABNORMAL_PHI flag set..
>
> This patch tells ranger not to consider any SSA_NAMEs which occur in
> abnormal PHIs.  This reduces the memory footprint of all the caches, and
> also has a ripple effect with the new threader code which uses the GORI
> exports and imports tables, making it faster as well as no ssa-name with
> the abnormal flag set will be entered into the tables.
>
> That alone was not quite enough, as all the sheer volume of call backs
> still took time,  so I added checks in the value_of_* class of routines
> used by substitute_and_fold to indicate there is no constant value
> available for any SSA_NAME with that flag set.
>
> On my x86_64 box, before this change, that test case looked like:
>
> tree VRP   :   7.76 (  4%)   0.23 ( 5%)   8.02
> (  4%)   537k (  0%)
> tree VRP threader  :   7.20 (  4%)   0.08 (  2%) 7.28 (
> 4%)   392k (  0%)
> tree Early VRP :  39.22 ( 22%)   0.07 (  2%) 39.44 (
> 22%)  1142k (  0%)
>
> And with this patch , the results are:
>
>   tree VRP   :   7.57 (  6%)   0.26 ( 5%)   7.85
> (  6%)   537k (  0%)
>   tree VRP threader  :   0.62 (  0%)   0.02 ( 0%)   0.65
> (  0%)   392k (  0%)
>   tree Early VRP :   4.00 (  3%)   0.01 ( 0%)   4.03
> (  3%)  1142k (  0%)
>
> Which is a significant improvement, both for EVRP and the threader..
>
> The patch adjusts the ranger folder, as well as the hybrid folder.
>
> bootstrapped on x86_64-pc-linux-gnu with no regressions and no missed
> cases that I have been able to find.

Did you test it with go enabled?
Because others and myself are now running into a bootstrap failure
most likely due to this patch.
The number of SSA_NAME_OCCURS_IN_ABNORMAL_PHI in go is increased due
to -fnon-call-exceptions being true there.

Thanks,
Andrew Pinski
PS here is the ICE for me:
libtool: compile:
/home/apinski/src/upstream-gcc/gcc/objdir/./gcc/gccgo
-B/home/apinski/src/upstream-gcc/gcc/objdir/./gcc/
-B/home/apinski/upstream-gcc/x86_64-pc-linux-gnu/bin/
-B/home/apinski/upstream-gcc/x86_64-pc-linux-gnu/lib/ -isystem
/home/apinski/upstream-gcc/x86_64-pc-linux-gnu/include -isystem
/home/apinski/upstream-gcc/x86_64-pc-linux-gnu/sys-include
-fchecking=1 -minline-all-stringops -O2 -g -m32 -I . -c
-fgo-pkgpath=cmd/go/internal/modget
/home/apinski/src/upstream-gcc/gcc/libgo/go/cmd/go/internal/modget/get.go
/home/apinski/src/upstream-gcc/gcc/libgo/go/cmd/go/internal/modget/query.go
-o cmd/go/internal/modget.o
during GIMPLE pass: evrp
In function ‘cmd/go/internal/modget.resolver.resolveQueries’:
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at
gimple-expr.c:87
0x862719 tree_class_check_failed(tree_node const*, tree_code_class,
char const*, int, char const*)
/home/apinski/src/upstream-gcc/gcc/gcc/tree.c:8739
0x7910ed tree_class_check(tree_node*, tree_code_class, char const*,
int, char const*)
/home/apinski/src/upstream-gcc/gcc/gcc/tree.h:3556
0x7910ed useless_type_conversion_p(tree_node*, tree_node*)
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-expr.c:87
0xf81a58 verify_gimple_phi
/home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.c:5128
0xf81a58 verify_gimple_in_cfg(function*, bool)
/home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.c:5457
0xe54a57 execute_function_todo
/home/apinski/src/upstream-gcc/gcc/gcc/passes.c:2042
0xe5546e execute_todo
/home/apinski/src/upstream-gcc/gcc/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


>
> I don't want to push it quite yet as I wanted feedback to make sure we
> don't actually do anything I'm not aware of with SSA_NAMES which have
> the ABNORMAL_PHI flag set.  Most of the code i can find in VRP and
> vr-values appears to punt, so I presume not even considering those names
> is fine?
>
> This also seems like something that might be worth back-porting,
> especially the hybrid pass parts...
>
> Andrew
>
>