GCC 9.4 Release Candidate available

GCC 9.4 Release Candidate available

[Richard Biener]

The first release candidate for GCC 9.4 is available from

https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210519/

and shortly its mirrors.  It has been generated from git commit
8091c46cf736124a106922ddfd1fdb99f33b0241.

I have so far bootstrapped and tested the release candidate
on {x86_64,i586,aarch64,ppc64le,s390x,riscv64,ppc,ppc64,armv7l}-linux.

Please test it and report any issues to bugzilla.

If all goes well I'd like to release 9.4 on Friday, June 28th.

Re: GCC 9.4 Release Candidate available

[Richard Biener]

On Wed, 19 May 2021, Richard Biener wrote:

> 
> The first release candidate for GCC 9.4 is available from
> 
> https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210519/
> 
> and shortly its mirrors.  It has been generated from git commit
> 8091c46cf736124a106922ddfd1fdb99f33b0241.
> 
> I have so far bootstrapped and tested the release candidate
> on {x86_64,i586,aarch64,ppc64le,s390x,riscv64,ppc,ppc64,armv7l}-linux.
> 
> Please test it and report any issues to bugzilla.
> 
> If all goes well I'd like to release 9.4 on Friday, June 28th.

May 28th, of course.

Richard.

Re: GCC 9.4 Release Candidate available

[Iain Sandoe]

Richard Biener <rguenther@suse.de> wrote:

>
> The first release candidate for GCC 9.4 is available from
>
> https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210519/
>
> and shortly its mirrors.  It has been generated from git commit
> 8091c46cf736124a106922ddfd1fdb99f33b0241.
>
> I have so far bootstrapped and tested the release candidate
> on {x86_64,i586,aarch64,ppc64le,s390x,riscv64,ppc,ppc64,armv7l}-linux.

(unfortunately very little time available at the moment for Darwin)
I bootstrapped/tested i686-darwin9,10 powerpc-darwin9, x86_64-darwin10..20
with no show-stoppers seen.

Iain
 

Re: GCC 9.4 Release Candidate available

[William Seurer]

Bootstrapped and tested it on powerpc64 power 7 and 8 BE and 8, 9, and 
10 LE and saw nothing untoward.

On 5/19/21 5:28 AM, Richard Biener wrote:
> The first release candidate for GCC 9.4 is available from
>
> https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210519/
>
> and shortly its mirrors.  It has been generated from git commit
> 8091c46cf736124a106922ddfd1fdb99f33b0241.
>
> I have so far bootstrapped and tested the release candidate
> on {x86_64,i586,aarch64,ppc64le,s390x,riscv64,ppc,ppc64,armv7l}-linux.
>
> Please test it and report any issues to bugzilla.
>
> If all goes well I'd like to release 9.4 on Friday, June 28th.

Re: GCC 9.4 Release Candidate available

[Jason Merrill]

PR100797 seems like a P1 regression from 9.3, I'd like to fix it before the
release.

On Tue, May 25, 2021 at 5:36 PM William Seurer via Gcc <gcc@gcc.gnu.org>
wrote:

> Bootstrapped and tested it on powerpc64 power 7 and 8 BE and 8, 9, and
> 10 LE and saw nothing untoward.
>
> On 5/19/21 5:28 AM, Richard Biener wrote:
> > The first release candidate for GCC 9.4 is available from
> >
> > https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210519/
> >
> > and shortly its mirrors.  It has been generated from git commit
> > 8091c46cf736124a106922ddfd1fdb99f33b0241.
> >
> > I have so far bootstrapped and tested the release candidate
> > on {x86_64,i586,aarch64,ppc64le,s390x,riscv64,ppc,ppc64,armv7l}-linux.
> >
> > Please test it and report any issues to bugzilla.
> >
> > If all goes well I'd like to release 9.4 on Friday, June 28th.
>
>

Re: GCC 9.4 Release Candidate available

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

On 5/27/21 11:59 PM, Jason Merrill wrote:
> PR100797 seems like a P1 regression from 9.3, I'd like to fix it before 
> the release.

Here's a candidate patch.  Going to bed now.

Jason

[-- Attachment #2: 0001-c-this-adjustment-for-devirtualized-call.patch --]
[-- Type: text/x-patch, Size: 5292 bytes --]

From c5e228d0b49154e78feb8f64659ce491bdf118c1 Mon Sep 17 00:00:00 2001
From: Jason Merrill <jason@redhat.com>
Date: Thu, 27 May 2021 23:54:52 -0400
Subject: [PATCH] c++: 'this' adjustment for devirtualized call
To: gcc-patches@gcc.gnu.org

My patch for 95719 made us do a better job of finding the actual virtual
function we want to call, but didn't update the 'this' pointer adjustment to
match.

This backport also incorporates a bit of the r11-1638 reorganization.

	PR c++/100797
	PR c++/95719

gcc/cp/ChangeLog:

	* call.c (build_over_call): Adjust base_binfo in
	resolves_to_fixed_type_p case.

gcc/testsuite/ChangeLog:

	* g++.dg/inherit/virtual15.C: New test.
	* g++.dg/inherit/virtual15a.C: New test.
---
 gcc/cp/call.c                             | 44 +++++++++++++----------
 gcc/testsuite/g++.dg/inherit/virtual15.C  | 18 ++++++++++
 gcc/testsuite/g++.dg/inherit/virtual15a.C | 19 ++++++++++
 3 files changed, 62 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/inherit/virtual15.C
 create mode 100644 gcc/testsuite/g++.dg/inherit/virtual15a.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7f76bd905ca..304c01619da 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8309,19 +8309,6 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
 	  || CLASSTYPE_FINAL (TYPE_METHOD_BASETYPE (TREE_TYPE (fn))))
 	flags |= LOOKUP_NONVIRTUAL;
 
-      /* If we know the dynamic type of the object, look up the final overrider
-	 in the BINFO.  */
-      if (DECL_VINDEX (fn) && (flags & LOOKUP_NONVIRTUAL) == 0
-	  && resolves_to_fixed_type_p (arg))
-	{
-	  tree binfo = cand->conversion_path;
-	  if (BINFO_TYPE (binfo) != DECL_CONTEXT (fn))
-	    binfo = lookup_base (binfo, DECL_CONTEXT (fn), ba_unique,
-				 NULL, complain);
-	  fn = lookup_vfn_in_binfo (DECL_VINDEX (fn), binfo);
-	  flags |= LOOKUP_NONVIRTUAL;
-	}
-
       /* [class.mfct.nonstatic]: If a nonstatic member function of a class
 	 X is called for an object that is not of type X, or of a type
 	 derived from X, the behavior is undefined.
@@ -8331,10 +8318,6 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
       gcc_assert (TYPE_PTR_P (parmtype));
       /* Convert to the base in which the function was declared.  */
       gcc_assert (cand->conversion_path != NULL_TREE);
-      converted_arg = build_base_path (PLUS_EXPR,
-				       arg,
-				       cand->conversion_path,
-				       1, complain);
       /* Check that the base class is accessible.  */
       if (!accessible_base_p (TREE_TYPE (argtype),
 			      BINFO_TYPE (cand->conversion_path), true))
@@ -8349,10 +8332,33 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
       /* If fn was found by a using declaration, the conversion path
 	 will be to the derived class, not the base declaring fn. We
 	 must convert from derived to base.  */
-      base_binfo = lookup_base (TREE_TYPE (TREE_TYPE (converted_arg)),
+      base_binfo = lookup_base (cand->conversion_path,
 				TREE_TYPE (parmtype), ba_unique,
 				NULL, complain);
-      converted_arg = build_base_path (PLUS_EXPR, converted_arg,
+
+      /* If we know the dynamic type of the object, look up the final overrider
+	 in the BINFO.  */
+      if (DECL_VINDEX (fn) && (flags & LOOKUP_NONVIRTUAL) == 0
+	  && resolves_to_fixed_type_p (arg))
+	{
+	  tree ov = lookup_vfn_in_binfo (DECL_VINDEX (fn), base_binfo);
+
+	  /* And unwind base_binfo to match.  If we don't find the type we're
+	     looking for in BINFO_INHERITANCE_CHAIN, we're looking at diamond
+	     inheritance; for now do a normal virtual call in that case.  */
+	  tree octx = DECL_CONTEXT (ov);
+	  tree obinfo = base_binfo;
+	  while (obinfo && !SAME_BINFO_TYPE_P (BINFO_TYPE (obinfo), octx))
+	    obinfo = BINFO_INHERITANCE_CHAIN (obinfo);
+	  if (obinfo)
+	    {
+	      fn = ov;
+	      base_binfo = obinfo;
+	      flags |= LOOKUP_NONVIRTUAL;
+	    }
+	}
+
+      converted_arg = build_base_path (PLUS_EXPR, arg,
 				       base_binfo, 1, complain);
 
       argarray[j++] = converted_arg;
diff --git a/gcc/testsuite/g++.dg/inherit/virtual15.C b/gcc/testsuite/g++.dg/inherit/virtual15.C
new file mode 100644
index 00000000000..ebd8e3ad29b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/inherit/virtual15.C
@@ -0,0 +1,18 @@
+// PR c++/100797
+// { dg-do run }
+
+bool ok = false;
+struct S1 { virtual ~S1() {} };
+struct S2 { virtual void f1() = 0; };
+struct S3: S1, S2 {
+    void f1() { f2(); }
+    virtual void f2() = 0;
+};
+struct S4: S3 {
+  void f2() { ok = true; }
+  using S2::f1;
+};
+int main() {
+  S4().f1();
+  if (!ok) __builtin_abort ();
+}
diff --git a/gcc/testsuite/g++.dg/inherit/virtual15a.C b/gcc/testsuite/g++.dg/inherit/virtual15a.C
new file mode 100644
index 00000000000..6139385192d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/inherit/virtual15a.C
@@ -0,0 +1,19 @@
+// PR c++/100797 plus diamond inheritance
+// { dg-do run }
+
+bool ok = false;
+struct S1 { virtual ~S1() {} };
+struct S2 { virtual void f1() = 0; };
+struct S3: S1, virtual S2 {
+    void f1() { f2(); }
+    virtual void f2() = 0;
+};
+struct SX: virtual S2 { };
+struct S4: SX, S3 {
+  void f2() { ok = true; }
+  using S2::f1;
+};
+int main() {
+  S4().f1();
+  if (!ok) __builtin_abort ();
+}
-- 
2.27.0

Re: GCC 9.4 Release Candidate available

[Richard Biener]

On Fri, May 28, 2021 at 7:12 AM Jason Merrill via Gcc <gcc@gcc.gnu.org> wrote:
>
> On 5/27/21 11:59 PM, Jason Merrill wrote:
> > PR100797 seems like a P1 regression from 9.3, I'd like to fix it before
> > the release.
>
> Here's a candidate patch.  Going to bed now.

I have bootstrapped and tested it on x86_64-unknown-linux-gnu, pushed it
to the gcc-9 branch and will do RC2 now with a release scheduled for
Tuesday so we have a chance to push fixes to trunk and 10/11 branches
before that.

Richard.

> Jason