gcc-9-20210527 is now available
Snapshot gcc-9-20210527 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210527/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 923f77e5a2bd6f62500a04e947a6739fbbf5ce08 You'll find: gcc-9-20210527.tar.xzComplete GCC SHA256=980e259ed75f9a5f38b5bf39edeecdeaef2dfa88c0cc3781f7238f944bfb7de4 SHA1=64e0eb76a3acf460f5e476f6e2b4f79d4a2dc7a0 Diffs from 9-20210520 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Good supply chain
Dear Sir/Madam: We understand from your information posted on Google. that you are in the market for Plastic industry. We would like to take this opportunity to introduce our company and products, with the hope that we may work with Bright Ideas Imports in the future. Our company is professional in Plastic mould for nearlly 24 years, We Specialized manufacture in Injection mould, Plastic parts Rubber parts,Metal parts, Assembly, Packaging. Our products include Drone Parts, Drone Filter and Camera Filter, Automobile, Medical device and Household items, Industrial and Electrical appliances, Display and Consumer product, Pleasure products etc. We've won high reputation from our customers all over the world, if you want know more about our company, please visit our website: www.starda-mould.com Should any of these items be of interest to you, please let us know. We will be happy to discuss the future project. We look forward to receiving your reply soon. Thanks and Best Regards Sophia Liao
Re: GCC Rust git branch
Hi Philip,
Philip Herron writes:
> As some of you might know, I have been working on GCC Rust over on
> GitHub https://github.com/Rust-GCC/gccrs. As the project is moving
> forward and enforcing GCC copyright assignments for contributors, I
> would like to create a branch on the GCC git repo to show the intention
> to be upstream with GCC someday.
I tried building GCC Rust on ppc64le. With the attached patches,
"make check-rust" succeeds with:
=== rust Summary ===
# of expected passes2368
# of expected failures 26
Thomas
>From 42099a90a23c31d1af95ceac590938d50a362cf9 Mon Sep 17 00:00:00 2001
From: Thomas Fitzsimmons
Date: Thu, 27 May 2021 21:53:29 -0400
Subject: [PATCH 1/2] rs6000: Override TARGET_RUST_OS_INFO in linux64.h
Both config/rs6000/sysv4.h and config/rs6000/linux64.h define
TARGET_RUST_OS_INFO, and both are included in that order in tm.h. This
change eliminates the error directive, permitting the more specific
definition in linux64.h to override the prior definition in sysv4.h.
gcc/ChangeLog:
2021-05-27 Thomas Fitzsimmons
* config/rs6000/linux64.h: Undefine TARGET_RUST_OS_INFO before
defining it.
---
gcc/config/rs6000/linux64.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gcc/config/rs6000/linux64.h b/gcc/config/rs6000/linux64.h
index fbd8cf0a693..536007ca685 100644
--- a/gcc/config/rs6000/linux64.h
+++ b/gcc/config/rs6000/linux64.h
@@ -314,9 +314,8 @@ extern int dot_symbols;
} \
while (0)
-#ifdef TARGET_RUST_OS_INFO
-# error "TARGET_RUST_OS_INFO already defined in linux64.h (rs6000) - c++ undefines it and redefines it."
-#endif
+/* Override less-specific rs6000/sysv4.h definition. */
+#undef TARGET_RUST_OS_INFO
#define TARGET_RUST_OS_INFO() \
do { \
GNU_USER_TARGET_RUST_OS_INFO(); \
--
2.30.0
>From cd4d663c13d27a53ccabeef3d7d8cffa7a5a5365 Mon Sep 17 00:00:00 2001
From: Thomas Fitzsimmons
Date: Thu, 27 May 2021 21:55:46 -0400
Subject: [PATCH 2/2] rs6000: Recognize GNU Rust when producing epilogue
Handling the GNU Rust language when writing a function's epilogue is
necessary to avoid an internal compiler error.
gcc/ChangeLog:
2021-05-27 Thomas Fitzsimmons
Mark Wielaard
* config/rs6000/rs6000-logue.c (rs6000_output_function_epilogue):
Set language type field to 0 for GNU Rust.
Co-Authored-By: Mark Wielaard
---
gcc/config/rs6000/rs6000-logue.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/config/rs6000/rs6000-logue.c b/gcc/config/rs6000/rs6000-logue.c
index b0ac183ceff..7da8db6d232 100644
--- a/gcc/config/rs6000/rs6000-logue.c
+++ b/gcc/config/rs6000/rs6000-logue.c
@@ -5262,12 +5262,13 @@ rs6000_output_function_epilogue (FILE *file)
use language_string.
C is 0. Fortran is 1. Ada is 3. Modula-2 is 8. C++ is 9.
Java is 13. Objective-C is 14. Objective-C++ isn't assigned
- a number, so for now use 9. LTO, Go, D, and JIT aren't assigned
- numbers either, so for now use 0. */
+ a number, so for now use 9. LTO, Go, D, Rust, and JIT aren't
+ assigned numbers either, so for now use 0. */
if (lang_GNU_C ()
|| ! strcmp (language_string, "GNU GIMPLE")
|| ! strcmp (language_string, "GNU Go")
|| ! strcmp (language_string, "GNU D")
+ || ! strcmp (language_string, "GNU Rust")
|| ! strcmp (language_string, "libgccjit"))
i = 0;
else if (! strcmp (language_string, "GNU F77")
--
2.30.0
Re: GCC Rust git branch
On Mon, May 24, 2021 at 9:25 AM Philip Herron wrote: > Hi everyone, > > As some of you might know, I have been working on GCC Rust over on > GitHub https://github.com/Rust-GCC/gccrs. As the project is moving > forward and enforcing GCC copyright assignments for contributors, I > would like to create a branch on the GCC git repo to show the intention > to be upstream with GCC someday. > [snip] Separately, some contributors have expressed interest in maintaining the > GCC style communications of using a mailing list and irc. Is it > reasonable for this project to get a r...@gcc.gnu.org? > That makes sense to me; I think overseers@ can help set up a new mailing list. Jason
Re: GCC 9.4 Release Candidate available
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
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
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
>From c5e228d0b49154e78feb8f64659ce491bdf118c1 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu, 27 May 2021 23:54:52 -0400
Subject: [PATCH] c++: 'this' adjustment for devirtualized call
To: gcc-patc...@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 000..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 000..6139385192d
--- /dev/null
+++ b/gcc/testsuit
