[committed] wwwdocs: Remove extraneous space around tags.

[Gerald Pfeifer]

It's generally a good idea, but now that we have been moving more
towards our web pages (HTML files) being more self contained including
DOCTYPE and common headers as opposed to more pre-processing upon
deployment, consistency in the sources has become more important
to allow for easier automated changes en large.

I will continue to put focus on that going forward; this is just a
small step removing extraneous space between  and ;
and it separates the  sections of those files touch by a blank
line where that's not the case yet.

Pushed.

Gerald

---
 htdocs/egcs-1.0/buildstat.html   | 4 +++-
 htdocs/egcs-1.1/buildstat.html   | 3 ++-
 htdocs/egcs-1.1/egcs-1.1-branch.html | 3 ++-
 htdocs/gcc-2.95/branch.html  | 2 +-
 htdocs/gcc-2.95/buildstat.html   | 2 +-
 htdocs/spam.html | 2 +-
 6 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/htdocs/egcs-1.0/buildstat.html b/htdocs/egcs-1.0/buildstat.html
index 66777148..da2a391f 100644
--- a/htdocs/egcs-1.0/buildstat.html
+++ b/htdocs/egcs-1.0/buildstat.html
@@ -1,10 +1,12 @@
 
 
+
 
 
- Build and Test status for EGCS 1.0
+Build and Test status for EGCS 1.0
 https://gcc.gnu.org/gcc.css"; />
 
+
 
 Build and Test status for EGCS 1.0
 
diff --git a/htdocs/egcs-1.1/buildstat.html b/htdocs/egcs-1.1/buildstat.html
index 64b4865c..6844d39c 100644
--- a/htdocs/egcs-1.1/buildstat.html
+++ b/htdocs/egcs-1.1/buildstat.html
@@ -1,8 +1,9 @@
 
 
+
 
 
- Build and Test status for EGCS 1.1
+Build and Test status for EGCS 1.1
 https://gcc.gnu.org/gcc.css"; />
 
 
diff --git a/htdocs/egcs-1.1/egcs-1.1-branch.html 
b/htdocs/egcs-1.1/egcs-1.1-branch.html
index c4cbf147..8da07327 100644
--- a/htdocs/egcs-1.1/egcs-1.1-branch.html
+++ b/htdocs/egcs-1.1/egcs-1.1-branch.html
@@ -1,8 +1,9 @@
 
 
+
 
 
-EGCS 1.1 branch 
+EGCS 1.1 branch
 https://gcc.gnu.org/gcc.css"; />
 
 
diff --git a/htdocs/gcc-2.95/branch.html b/htdocs/gcc-2.95/branch.html
index 03746846..e4f20f80 100644
--- a/htdocs/gcc-2.95/branch.html
+++ b/htdocs/gcc-2.95/branch.html
@@ -3,7 +3,7 @@
 
 
 
-GCC 2.95 branch 
+GCC 2.95 branch
 https://gcc.gnu.org/gcc.css"; />
 
 
diff --git a/htdocs/gcc-2.95/buildstat.html b/htdocs/gcc-2.95/buildstat.html
index 1823fba6..c6029e45 100644
--- a/htdocs/gcc-2.95/buildstat.html
+++ b/htdocs/gcc-2.95/buildstat.html
@@ -3,7 +3,7 @@
 
 
 
- Build status for GCC 2.95
+Build status for GCC 2.95
 https://gcc.gnu.org/gcc.css"; />
 
 
diff --git a/htdocs/spam.html b/htdocs/spam.html
index 2196a83b..8db948d4 100644
--- a/htdocs/spam.html
+++ b/htdocs/spam.html
@@ -3,7 +3,7 @@
 
 
 
- Dealing with SPAM 
+Dealing with SPAM
 https://gcc.gnu.org/gcc.css"; />
 
 
-- 
2.26.0

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Martin Liška]

On 4/9/20 10:13 AM, Jonathan Wakely wrote:

On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:

Note that the matching is not 1-to-1. Array vs non-array and
aligned vs non-aligned seem important, but sized and unsized delete can
both match the same new, IIUC.


Right.


Not sure about the nothrow versions...


This is valid, and mixes the nothrow new with non-nothrow delete:

delete new (std::nothrow) int;



All right, there's a patch candidate that comes up with the list of possible 
pairs.
For better readability, I present demangled names:

$ cat /tmp/pairs.txt | c++filt
  "operator new(unsigned long):operator delete(void*)" ,
  "operator new(unsigned long):operator delete(void*, unsigned long)" ,
  "operator new(unsigned long):operator delete(void*, std::nothrow_t 
const&)" ,
  "operator new(unsigned long, std::nothrow_t const&):operator 
delete(void*)" ,
  "operator new(unsigned long, std::nothrow_t const&):operator delete(void*, 
unsigned long)" ,
  "operator new(unsigned long, std::nothrow_t const&):operator delete(void*, 
std::nothrow_t const&)" ,
  /* non-[] operators with alignment.  */
  "operator new(unsigned long, std::align_val_t):operator delete(void*, 
unsigned long, std::align_val_t)" ,
  "operator new(unsigned long, std::align_val_t):operator delete(void*, 
std::align_val_t)" ,
  "operator new(unsigned long, std::align_val_t):operator delete(void*, 
std::align_val_t, std::nothrow_t const&)" ,
  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete(void*, unsigned long, std::align_val_t)" ,
  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete(void*, std::align_val_t)" ,
  "operator new(unsigned long, std::align_val_t, std::nothrow_t const&):operator 
delete(void*, std::align_val_t, std::nothrow_t const&)" ,
  /* [] operators.  */
   "operator new[](unsigned long):operator delete[](void*)" ,
   "operator new[](unsigned long):operator delete[](void*, unsigned 
long)" ,
   "operator new[](unsigned long):operator delete[](void*, std::nothrow_t 
const&)" ,
   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*)" ,
   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*, unsigned long)" ,
   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*, std::nothrow_t const&)" ,
  /* [] operators with alignment.  */
   "operator new[](unsigned long, std::align_val_t):operator delete[](void*, 
unsigned long, std::align_val_t)" ,
   "operator new[](unsigned long, std::align_val_t):operator delete[](void*, 
std::align_val_t)" ,
   "operator new[](unsigned long, std::align_val_t):operator delete[](void*, 
std::align_val_t, std::nothrow_t const&)" ,
   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, unsigned long, std::align_val_t)",
   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, std::align_val_t)",
   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, std::align_val_t, std::nothrow_t const&)",

Marc pointed out that some targets do not use the leading '_' (or use 2 
dashes?) for mangled named?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Thanks,
Martin
>From aa7102bcd698b6f132e0b9ffecd847d68083039b Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 9 Apr 2020 15:50:58 +0200
Subject: [PATCH] List valid pairs for new and delete operators.

gcc/ChangeLog:

2020-04-09  Martin Liska  

	PR c++/94314
	* cgraphclones.c (set_new_clone_decl_and_node_flags): Drop
	DECL_IS_REPLACEABLE_OPERATOR during cloning.
	* tree-ssa-dce.c (valid_new_delete_pair_p): New function.
	(propagate_necessity): Check operator names.
	(perform_tree_ssa_dce): Delete valid_pairs.

gcc/testsuite/ChangeLog:

2020-04-09  Martin Liska  

	PR c++/94314
	* g++.dg/pr94314-4.C: New test.
---
 gcc/cgraphclones.c   |  2 +
 gcc/testsuite/g++.dg/pr94314-4.C | 33 
 gcc/tree-ssa-dce.c   | 93 
 3 files changed, 118 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr94314-4.C

diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index c73b8f810f0..8f541a28b6e 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -165,6 +165,7 @@ set_new_clone_decl_and_node_flags (cgraph_node *new_node)
   DECL_STATIC_DESTRUCTOR (new_node->decl) = 0;
   DECL_SET_IS_OPERATOR_NEW (new_node->decl, 0);
   DECL_SET_IS_OPERATOR_DELETE (new_node->decl, 0);
+  DECL_IS_REPLACEABLE_OPERATOR (new_node->decl) = 0;
 
   new_node->externally_visible = 0;
   new_node->local = 1;
@@ -1030,6 +1031,7 @@ cgraph_node::create_version_clone_with_body
   DECL_STATIC_DE

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Apr 2020 at 09:08, Martin Liška  wrote:
> Marc pointed out that some targets do not use the leading '_' (or use 2 
> dashes?) for mangled named?

Double underscore at the start. I think darwin uses that.

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Martin Liška]

On 4/10/20 10:18 AM, Jonathan Wakely wrote:

On Fri, 10 Apr 2020 at 09:08, Martin Liška  wrote:

Marc pointed out that some targets do not use the leading '_' (or use 2 
dashes?) for mangled named?


Double underscore at the start. I think darwin uses that.



Ah yeah, not dashes, but underscores ;)
It's fixed in attached patch that I've been testing right now.

Martin
>From 4043b187ee8e6d7d0c05a6463e38ca54ba4acf75 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 9 Apr 2020 15:50:58 +0200
Subject: [PATCH] List valid pairs for new and delete operators.

gcc/ChangeLog:

2020-04-09  Martin Liska  

	PR c++/94314
	* cgraphclones.c (set_new_clone_decl_and_node_flags): Drop
	DECL_IS_REPLACEABLE_OPERATOR during cloning.
	* tree-ssa-dce.c (valid_new_delete_pair_p): New function.
	(propagate_necessity): Check operator names.
	(perform_tree_ssa_dce): Delete valid_pairs.

gcc/testsuite/ChangeLog:

2020-04-09  Martin Liska  

	PR c++/94314
	* g++.dg/pr94314-4.C: New test.
---
 gcc/cgraphclones.c   |  2 +
 gcc/testsuite/g++.dg/pr94314-4.C | 33 +++
 gcc/tree-ssa-dce.c   | 99 
 3 files changed, 124 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr94314-4.C

diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index c73b8f810f0..8f541a28b6e 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -165,6 +165,7 @@ set_new_clone_decl_and_node_flags (cgraph_node *new_node)
   DECL_STATIC_DESTRUCTOR (new_node->decl) = 0;
   DECL_SET_IS_OPERATOR_NEW (new_node->decl, 0);
   DECL_SET_IS_OPERATOR_DELETE (new_node->decl, 0);
+  DECL_IS_REPLACEABLE_OPERATOR (new_node->decl) = 0;
 
   new_node->externally_visible = 0;
   new_node->local = 1;
@@ -1030,6 +1031,7 @@ cgraph_node::create_version_clone_with_body
   DECL_STATIC_DESTRUCTOR (new_decl) = 0;
   DECL_SET_IS_OPERATOR_NEW (new_decl, 0);
   DECL_SET_IS_OPERATOR_DELETE (new_decl, 0);
+  DECL_IS_REPLACEABLE_OPERATOR (new_decl) = 0;
 
   /* Create the new version's call-graph node.
  and update the edges of the new node. */
diff --git a/gcc/testsuite/g++.dg/pr94314-4.C b/gcc/testsuite/g++.dg/pr94314-4.C
new file mode 100644
index 000..afa2a443dc4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr94314-4.C
@@ -0,0 +1,33 @@
+/* PR c++/94314.  */
+/* { dg-do run } */
+/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */
+/* { dg-additional-options "-fdelete-null-pointer-checks" } */
+
+#include 
+
+int count = 0;
+
+__attribute__((malloc, noinline)) void* operator new[](__SIZE_TYPE__ sz) {
+  ++count;
+  return ::operator new(sz);
+}
+
+void operator delete[](void* ptr) noexcept {
+  --count;
+  ::operator delete(ptr);
+}
+
+void operator delete[](void* ptr, __SIZE_TYPE__ sz) noexcept {
+  --count;
+  ::operator delete(ptr, sz);
+}
+
+int main() {
+  delete[] new int[1];
+  if (count != 0)
+__builtin_abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "Deleting : operator delete" "cddce1"} } */
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index fd5f24c746c..f66069e410d 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -646,6 +646,76 @@ degenerate_phi_p (gimple *phi)
   return true;
 }
 
+/* Valid pairs of new and delete operators for DCE.  */
+static hash_set *valid_pairs = NULL;
+
+/* Return that NEW_CALL and DELETE_CALL are a valid pair of new
+   and delete  operators.  */
+
+static bool
+valid_new_delete_pair_p (gimple *new_call, gimple *delete_call)
+{
+  const char *new_name
+= IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (gimple_call_fndecl (new_call)));
+  const char *delete_name
+= IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (gimple_call_fndecl (delete_call)));
+
+  if (new_name[0] == '_' and new_name[1] == '_')
+++new_name;
+  if (delete_name[0] == '_' and delete_name[1] == '_')
+++delete_name;
+
+  char *needle = concat (new_name, ":", delete_name, NULL);
+
+  if (valid_pairs == NULL)
+{
+  valid_pairs = new hash_set ();
+  /* Invalid pairs:
+	 non-[] and []
+	 aligned and non-aligned
+  */
+
+  const char *pairs[] = {
+	  /* non-[] operators.  */
+	  "_Znwm:_ZdlPv" ,
+	  "_Znwm:_ZdlPvm" ,
+	  "_Znwm:_ZdlPvRKSt9nothrow_t" ,
+	  "_ZnwmRKSt9nothrow_t:_ZdlPv" ,
+	  "_ZnwmRKSt9nothrow_t:_ZdlPvm" ,
+	  "_ZnwmRKSt9nothrow_t:_ZdlPvRKSt9nothrow_t" ,
+	  /* non-[] operators with alignment.  */
+	  "_ZnwmSt11align_val_t:_ZdlPvmSt11align_val_t" ,
+	  "_ZnwmSt11align_val_t:_ZdlPvSt11align_val_t" ,
+	  "_ZnwmSt11align_val_t:_ZdlPvSt11align_val_tRKSt9nothrow_t" ,
+	  "_ZnwmSt11align_val_tRKSt9nothrow_t:_ZdlPvmSt11align_val_t" ,
+	  "_ZnwmSt11align_val_tRKSt9nothrow_t:_ZdlPvSt11align_val_t" ,
+	  "_ZnwmSt11align_val_tRKSt9nothrow_t:_ZdlPvSt11align_val_tRKSt9nothrow_t" ,
+	  /* [] operators.  */
+	   "_Znam:_ZdaPv" ,
+	   "_Znam:_ZdaPvm" ,
+	   "_Znam:_ZdaPvRKSt9nothrow_t" ,
+	   "_ZnamRKSt9nothrow_t:_ZdaPv" ,
+	   "_ZnamRKSt9nothrow_t:_ZdaPvm" ,
+	   "_ZnamRKSt9nothrow_t:_ZdaPvRKSt9nothrow_t" ,
+	  /* [] operators 

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Marc Glisse]

On Fri, 10 Apr 2020, Martin Liška wrote:


On 4/9/20 10:13 AM, Jonathan Wakely wrote:

On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:

Note that the matching is not 1-to-1. Array vs non-array and
aligned vs non-aligned seem important, but sized and unsized delete can
both match the same new, IIUC.


Right.


Not sure about the nothrow versions...


This is valid, and mixes the nothrow new with non-nothrow delete:

delete new (std::nothrow) int;



All right, there's a patch candidate that comes up with the list of possible 
pairs.

For better readability, I present demangled names:

$ cat /tmp/pairs.txt | c++filt
  "operator new(unsigned long):operator delete(void*)" ,
	  "operator new(unsigned long):operator delete(void*, unsigned long)" 
,
	  "operator new(unsigned long):operator delete(void*, std::nothrow_t 
const&)" ,
	  "operator new(unsigned long, std::nothrow_t const&):operator 
delete(void*)" ,
	  "operator new(unsigned long, std::nothrow_t const&):operator 
delete(void*, unsigned long)" ,
	  "operator new(unsigned long, std::nothrow_t const&):operator 
delete(void*, std::nothrow_t const&)" ,

  /* non-[] operators with alignment.  */
	  "operator new(unsigned long, std::align_val_t):operator 
delete(void*, unsigned long, std::align_val_t)" ,
	  "operator new(unsigned long, std::align_val_t):operator 
delete(void*, std::align_val_t)" ,
	  "operator new(unsigned long, std::align_val_t):operator 
delete(void*, std::align_val_t, std::nothrow_t const&)" ,
	  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete(void*, unsigned long, std::align_val_t)" ,
	  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete(void*, std::align_val_t)" ,
	  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete(void*, std::align_val_t, std::nothrow_t const&)" ,

  /* [] operators.  */
   "operator new[](unsigned long):operator delete[](void*)" ,
	   "operator new[](unsigned long):operator delete[](void*, unsigned 
long)" ,
	   "operator new[](unsigned long):operator delete[](void*, 
std::nothrow_t const&)" ,
	   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*)" ,
	   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*, unsigned long)" ,
	   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*, std::nothrow_t const&)" ,

  /* [] operators with alignment.  */
	   "operator new[](unsigned long, std::align_val_t):operator 
delete[](void*, unsigned long, std::align_val_t)" ,
	   "operator new[](unsigned long, std::align_val_t):operator 
delete[](void*, std::align_val_t)" ,
	   "operator new[](unsigned long, std::align_val_t):operator 
delete[](void*, std::align_val_t, std::nothrow_t const&)" ,
	   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, unsigned long, std::align_val_t)",
	   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, std::align_val_t)",
	   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, std::align_val_t, std::nothrow_t const&)",


Marc pointed out that some targets do not use the leading '_' (or use 2 
dashes?) for mangled named?

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.


How do you handle platforms where size_t is not unsigned long?

--
Marc Glisse

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Iain Sandoe via Gcc-patches]

Marc Glisse  wrote:


On Fri, 10 Apr 2020, Martin Liška wrote:


On 4/9/20 10:13 AM, Jonathan Wakely wrote:

On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:

Note that the matching is not 1-to-1. Array vs non-array and
aligned vs non-aligned seem important, but sized and unsized delete can
both match the same new, IIUC.

Right.

Not sure about the nothrow versions...

This is valid, and mixes the nothrow new with non-nothrow delete:
delete new (std::nothrow) int;


All right, there's a patch candidate that comes up with the list of  
possible pairs.

For better readability, I present demangled names:

$ cat /tmp/pairs.txt | c++filt
  "operator new(unsigned long):operator delete(void*)" ,
  "operator new(unsigned long):operator delete(void*, unsigned long)" ,
  "operator new(unsigned long):operator delete(void*, std::nothrow_t 
const&)" ,
  "operator new(unsigned long, std::nothrow_t const&):operator 
delete(void*)" ,
  "operator new(unsigned long, std::nothrow_t const&):operator delete(void*, 
unsigned long)" ,
  "operator new(unsigned long, std::nothrow_t const&):operator delete(void*, 
std::nothrow_t const&)" ,
  /* non-[] operators with alignment.  */
  "operator new(unsigned long, std::align_val_t):operator delete(void*, 
unsigned long, std::align_val_t)" ,
  "operator new(unsigned long, std::align_val_t):operator delete(void*, 
std::align_val_t)" ,
  "operator new(unsigned long, std::align_val_t):operator delete(void*, 
std::align_val_t, std::nothrow_t const&)" ,
  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete(void*, unsigned long, std::align_val_t)" ,
  "operator new(unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete(void*, std::align_val_t)" ,
  "operator new(unsigned long, std::align_val_t, std::nothrow_t const&):operator 
delete(void*, std::align_val_t, std::nothrow_t const&)" ,
  /* [] operators.  */
   "operator new[](unsigned long):operator delete[](void*)" ,
   "operator new[](unsigned long):operator delete[](void*, unsigned 
long)" ,
   "operator new[](unsigned long):operator delete[](void*, std::nothrow_t 
const&)" ,
   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*)" ,
   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*, unsigned long)" ,
   "operator new[](unsigned long, std::nothrow_t const&):operator 
delete[](void*, std::nothrow_t const&)" ,
  /* [] operators with alignment.  */
   "operator new[](unsigned long, std::align_val_t):operator delete[](void*, 
unsigned long, std::align_val_t)" ,
   "operator new[](unsigned long, std::align_val_t):operator delete[](void*, 
std::align_val_t)" ,
   "operator new[](unsigned long, std::align_val_t):operator delete[](void*, 
std::align_val_t, std::nothrow_t const&)" ,
   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, unsigned long, std::align_val_t)",
   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, std::align_val_t)",
   "operator new[](unsigned long, std::align_val_t, std::nothrow_t 
const&):operator delete[](void*, std::align_val_t, std::nothrow_t const&)",

Marc pointed out that some targets do not use the leading '_' (or use 2  
dashes?) for mangled named?


This is USER_LABEL_PREFIX.  Several targets, including Darwin, do use it.

Other than pre-pending the U_L_P, name mangling on Darwin (and I’d imagine  
any other Itanium ABI platform) is as per ABI.



Patch can bootstrap on x86_64-linux-gnu and survives regression tests.


How do you handle platforms where size_t is not unsigned long?

--
Marc Glisse

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Jakub Jelinek via Gcc-patches]

On Fri, Apr 10, 2020 at 10:29:29AM +0200, Martin Liška wrote:
> +/* Valid pairs of new and delete operators for DCE.  */
> +static hash_set *valid_pairs = NULL;
> +
> +/* Return that NEW_CALL and DELETE_CALL are a valid pair of new
> +   and delete  operators.  */
> +
> +static bool
> +valid_new_delete_pair_p (gimple *new_call, gimple *delete_call)
> +{
> +  const char *new_name
> += IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (gimple_call_fndecl 
> (new_call)));
> +  const char *delete_name
> += IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (gimple_call_fndecl 
> (delete_call)));
> +
> +  if (new_name[0] == '_' and new_name[1] == '_')
> +++new_name;
> +  if (delete_name[0] == '_' and delete_name[1] == '_')
> +++delete_name;
> +
> +  char *needle = concat (new_name, ":", delete_name, NULL);
> +
> +  if (valid_pairs == NULL)
> +{
> +  valid_pairs = new hash_set ();
> +  /* Invalid pairs:
> +  non-[] and []
> +  aligned and non-aligned
> +  */
> +
> +  const char *pairs[] = {
> +   /* non-[] operators.  */
> +   "_Znwm:_ZdlPv" ,
> +   "_Znwm:_ZdlPvm" ,

Formatting, I think the /* and "_Z should be two columns from const char,
and no space before ,
Not sure I like using the : and using a hash table looks like an overkill to
me, don't we have only 8 options, and most of them with different identifier
lengths?  The concat itself will take a while...
And, what's worse, the m in there is really different on different targets.
It can be j, m or y depending on what fundamental type size_t is.

So why not (completely untested):

static bool
valid_new_delete_pair_p (gimple *new_call, gimple *delete_call)
{
  tree new_asm = DECL_ASSEMBLER_NAME (gimple_call_fndecl (new_call));
  tree delete_asm = DECL_ASSEMBLER_NAME (gimple_call_fndecl (delete_call));
  const char *new_name = IDENTIFIER_POINTER (new_asm);
  const char *delete_name = IDENTIFIER_POINTER (delete_asm);
  unsigned int new_len = IDENTIFIER_LENGTH (mew_asm);
  unsigned int delete_len = IDENTIFIER_LENGTH (delete_asm);
  if (new_name < 5 || delete_len < 6)
return false;
  if (new_name[0] == '_')
++new_name, --new_len;
  if (new_name[0] == '_')
++new_name, --new_len;
  if (delete_name[0] == '_')
++delete_name, --delete_len;
  if (delete_name[0] == '_')
++delete_name, --delete_len;
  if (new_len < 4 || delete_len < 5)
return false;
  /* *_len is now just the length after initial underscores.  */
  if (new_name[0] != 'Z' || new_name[1] != 'n')
return false;
  if (delete_name[0] != 'Z' || delete_name[1] != 'd')
return false;
  /* _Znw must match _Zdl, _Zna must match _Zda.  */
  if ((new_name[2] != 'w' || delete_name[2] != 'l')
  && (new_name[2] != 'a' || delete_name[2] != 'a'))
return false;
  if (new_name[3] != 'j' && new_name[3] != 'm' && new_name[3] != 'y')
return false;
  if (delete_name[3] != 'P' || delete_name[4] != 'v')
return false;
  if (new_len == 4
  || (new_len == 18 && !memcmp (new_name + 4, "RKSt9nothrow_t", 14)))
{
  /* _ZnXY or _ZnXYRKSt9nothrow_t matches
 _ZdXPv, _ZdXPvY and _ZdXPvRKSt9nothrow_t.  */
  if (delete_len == 5)
return true;
  if (delete_len == 6 && delete_name[5] == new_name[3])
return true;
  if (delete_len == 19 && !memcmp (delete_name + 5, "RKSt9nothrow_t", 14))
return true;
}
  else if ((new_len == 19 && !memcmp (new_name + 4, "St11align_val_t", 15))
   || (new_len == 33
   && !memcmp (new_name + 4, "St11align_val_tRKSt9nothrow_t", 29)))
{
  /* _ZnXYSt11align_val_t or _ZnXYSt11align_val_tRKSt9nothrow_t matches
 _ZdXPvSt11align_val_t or _ZdXPvYSt11align_val_t or  or
 _ZdXPvSt11align_val_tRKSt9nothrow_t.  */
  if (delete_len == 20 && !memcmp (delete_name + 5, "St11align_val_t", 15))
return true;
  if (delete_len == 21
  && delete_name[5] == new_name[3]
  && !memcmp (delete_name + 6, "St11align_val_t", 15))
return true;
  if (delete_len == 34
  && !memcmp (delete_name + 5, "St11align_val_tRKSt9nothrow_t", 29))
return true;
}
  return false;
}

Jakub

[PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

[Kito Cheng]

  - Implied rule are introduced into latest RISC-V ISA spec.

  - Only implemented D implied F-extension. Zicsr and Zifence are not
implement yet, so the rule not included in this patch.

  - Pass preprocessed arch string to arch.

  - Verified with binutils 2.30 and 2.34.

gcc/ChangeLog

* common/config/riscv/riscv-common.c (riscv_implied_info_t): New.
(riscv_implied_info): New.
(riscv_subset_list): Add handle_implied_ext.
(riscv_subset_list::to_string): New parameter version_p to
control output format.
(riscv_subset_list::handle_implied_ext): New.
(riscv_subset_list::parse_std_ext): Call handle_implied_ext.
(riscv_arch_str): New parameter version_p to control output format.
(riscv_expand_arch): New.
* config/riscv/riscv-protos.h (riscv_arch_str): New parameter,
version_p.
* config/riscv/riscv.h (riscv_expand_arch): New,
(EXTRA_SPEC_FUNCTIONS): Define.
(ASM_SPEC): Transform -march= via riscv_expand_arch.

gcc/testsuite/ChangeLog

* gcc.target/riscv/arch-6.c: New.
* gcc.target/riscv/attribute-11.c: New.
* gcc.target/riscv/attribute-12.c: New.
---
 gcc/common/config/riscv/riscv-common.c| 85 ---
 gcc/config/riscv/riscv-protos.h   |  2 +-
 gcc/config/riscv/riscv.h  |  7 +-
 gcc/testsuite/gcc.target/riscv/arch-6.c   |  5 ++
 gcc/testsuite/gcc.target/riscv/attribute-11.c |  6 ++
 gcc/testsuite/gcc.target/riscv/attribute-12.c |  6 ++
 6 files changed, 99 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-11.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-12.c

diff --git a/gcc/common/config/riscv/riscv-common.c 
b/gcc/common/config/riscv/riscv-common.c
index a2e8d7003cc..2df93460165 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -44,6 +44,20 @@ struct riscv_subset_t
   struct riscv_subset_t *next;
 };
 
+/* Type for implied ISA info.  */
+struct riscv_implied_info_t
+{
+  const char *ext;
+  const char *implied_ext;
+};
+
+/* Implied ISA info, must end with NULL sentinel.  */
+riscv_implied_info_t riscv_implied_info[] =
+{
+  {"d", "f"},
+  {NULL, NULL}
+};
+
 /* Subset list.  */
 class riscv_subset_list
 {
@@ -73,6 +87,8 @@ private:
   const char *parse_multiletter_ext (const char *, const char *,
 const char *);
 
+  void handle_implied_ext (const char *, int, int);
+
 public:
   ~riscv_subset_list ();
 
@@ -82,7 +98,7 @@ public:
  int major_version = RISCV_DONT_CARE_VERSION,
  int minor_version = RISCV_DONT_CARE_VERSION) const;
 
-  std::string to_string () const;
+  std::string to_string (bool) const;
 
   unsigned xlen() const {return m_xlen;};
 
@@ -140,10 +156,11 @@ riscv_subset_list::add (const char *subset, int 
major_version,
   m_tail = s;
 }
 
-/* Convert subset info to string with explicit version info.  */
+/* Convert subset info to string with explicit version info,
+   VERSION_P to determine append version info or not.  */
 
 std::string
-riscv_subset_list::to_string () const
+riscv_subset_list::to_string (bool version_p) const
 {
   std::ostringstream oss;
   oss << "rv" << m_xlen;
@@ -153,14 +170,20 @@ riscv_subset_list::to_string () const
 
   while (subset != NULL)
 {
-  if (!first)
+  /* For !version_p, we only separate extension with underline for
+multi-letter extension.  */
+  if (!first &&
+ (version_p || subset->name.length() > 1))
oss << '_';
   first = false;
 
-  oss << subset->name
- << subset->major_version
- << 'p'
- << subset->minor_version;
+  oss << subset->name;
+
+  if (version_p)
+   oss  << subset->major_version
+<< 'p'
+<< subset->minor_version;
+
   subset = subset->next;
 }
 
@@ -394,11 +417,38 @@ riscv_subset_list::parse_std_ext (const char *p)
 
   subset[0] = std_ext;
 
+  handle_implied_ext (subset, major_version, minor_version);
+
   add (subset, major_version, minor_version);
 }
   return p;
 }
 
+
+/* Check any implied extensions for EXT with version
+   MAJOR_VERSION.MINOR_VERSION.  */
+void
+riscv_subset_list::handle_implied_ext (const char *ext,
+  int major_version,
+  int minor_version)
+{
+  riscv_implied_info_t *implied_info;
+  for (implied_info = &riscv_implied_info[0];
+   implied_info->ext;
+   ++implied_info)
+{
+  if (strcmp (ext, implied_info->ext) != 0)
+   continue;
+
+  /* Skip if implied extension already present.  */
+  if (lookup (implied_info->implied_ext))
+   continue;
+
+  /* TODO: Implied extension might use different version.  */
+  add (implied_info->imp

[PATCH v2 1/2] RISC-V: Update march parser

[Kito Cheng]

 - The arch string rule has changed in latest spec, it introduced new
   multi-letter extension prefix with 'h' and 'z', and drop `sx`. also
   adjust parsing order for 's' and 'x'.

gcc/ChangeLog

* riscv-common.c (parse_sv_or_non_std_ext): Rename to
parse_multiletter_ext.
(parse_multiletter_ext): Add parsing `h` and `z`, drop `sx`,
adjust parsing order for 's' and 'x'.

gcc/testsuite/ChangeLog

* gcc.target/riscv/arch-3.c: Adjust option.
* gcc.target/riscv/arch-5.c: New.
* gcc.target/riscv/attribute-9.c: Adjust option and test
condition.
---
 gcc/common/config/riscv/riscv-common.c   | 40 ++--
 gcc/testsuite/gcc.target/riscv/arch-3.c  |  2 +-
 gcc/testsuite/gcc.target/riscv/arch-5.c  |  5 +++
 gcc/testsuite/gcc.target/riscv/attribute-9.c |  4 +-
 4 files changed, 28 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-5.c

diff --git a/gcc/common/config/riscv/riscv-common.c 
b/gcc/common/config/riscv/riscv-common.c
index d2ef83b1971..a2e8d7003cc 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -70,8 +70,8 @@ private:
 
   const char *parse_std_ext (const char *);
 
-  const char *parse_sv_or_non_std_ext (const char *, const char *,
-  const char *);
+  const char *parse_multiletter_ext (const char *, const char *,
+const char *);
 
 public:
   ~riscv_subset_list ();
@@ -357,7 +357,7 @@ riscv_subset_list::parse_std_ext (const char *p)
 {
   char subset[2] = {0, 0};
 
-  if (*p == 'x' || *p == 's')
+  if (*p == 'x' || *p == 's' || *p == 'h' || *p == 'z')
break;
 
   if (*p == '_')
@@ -399,20 +399,20 @@ riscv_subset_list::parse_std_ext (const char *p)
   return p;
 }
 
-/* Parsing function for non-standard and supervisor extensions.
+/* Parsing function for multi-letter extensions.
 
Return Value:
  Points to the end of extensions.
 
Arguments:
  `p`: Current parsing position.
- `ext_type`: What kind of extensions, 'x', 's' or 'sx'.
+ `ext_type`: What kind of extensions, 's', 'h', 'z' or 'x'.
  `ext_type_str`: Full name for kind of extension.  */
 
 const char *
-riscv_subset_list::parse_sv_or_non_std_ext (const char *p,
-   const char *ext_type,
-   const char *ext_type_str)
+riscv_subset_list::parse_multiletter_ext (const char *p,
+ const char *ext_type,
+ const char *ext_type_str)
 {
   unsigned major_version = 0;
   unsigned minor_version = 0;
@@ -429,11 +429,6 @@ riscv_subset_list::parse_sv_or_non_std_ext (const char *p,
   if (strncmp (p, ext_type, ext_type_len) != 0)
break;
 
-  /* It's non-standard supervisor extension if it prefix with sx.  */
-  if ((ext_type[0] == 's') && (ext_type_len == 1)
- && (*(p + 1) == 'x'))
-   break;
-
   char *subset = xstrdup (p);
   char *q = subset;
   const char *end_of_version;
@@ -494,21 +489,26 @@ riscv_subset_list::parse (const char *arch, location_t 
loc)
   if (p == NULL)
 goto fail;
 
-  /* Parsing non-standard extension.  */
-  p = subset_list->parse_sv_or_non_std_ext (p, "x", "non-standard extension");
+  /* Parsing supervisor extension.  */
+  p = subset_list->parse_multiletter_ext (p, "s", "supervisor extension");
 
   if (p == NULL)
 goto fail;
 
-  /* Parsing supervisor extension.  */
-  p = subset_list->parse_sv_or_non_std_ext (p, "s", "supervisor extension");
+  /* Parsing hypervisor extension.  */
+  p = subset_list->parse_multiletter_ext (p, "h", "hypervisor extension");
 
   if (p == NULL)
 goto fail;
 
-  /* Parsing non-standard supervisor extension.  */
-  p = subset_list->parse_sv_or_non_std_ext
-(p, "sx", "non-standard supervisor extension");
+  /* Parsing sub-extensions.  */
+  p = subset_list->parse_multiletter_ext (p, "z", "sub-extension");
+
+  if (p == NULL)
+goto fail;
+
+  /* Parsing non-standard extension.  */
+  p = subset_list->parse_multiletter_ext (p, "x", "non-standard extension");
 
   if (p == NULL)
 goto fail;
diff --git a/gcc/testsuite/gcc.target/riscv/arch-3.c 
b/gcc/testsuite/gcc.target/riscv/arch-3.c
index 6aaa0a650fa..124699405c5 100644
--- a/gcc/testsuite/gcc.target/riscv/arch-3.c
+++ b/gcc/testsuite/gcc.target/riscv/arch-3.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O -march=rv32ixbar_sabc_sxfoo -mabi=ilp32" } */
+/* { dg-options "-O -march=rv32isabc_xbar -mabi=ilp32" } */
 int foo()
 {
 }
diff --git a/gcc/testsuite/gcc.target/riscv/arch-5.c 
b/gcc/testsuite/gcc.target/riscv/arch-5.c
new file mode 100644
index 000..b0a1bd445fe
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-5.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-O -march=rv32isabc_hghi_zfoo_x

[PATCH, vect] Check alignment for no peeling gaps handling

[Kewen.Lin via Gcc-patches]

Hi,

This is one fix following Richi's comments here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542232.html

I noticed the current half vector support for no peeling gaps
handled some cases which never check the half size vector
support.  By further investigation, those cases are safe
to play without peeling gaps due to ideal alignment.  It
means they don't require half vector handlings, we should
avoid to use half vector for them.

The fix is to add alignment check as a part of conditions for
half vector support avoiding redundant half vector codes.

Bootstrapped/regtested on powerpc64le-linux-gnu P8, while
aarch64-linux-gnu testing is ongoing.

Is it ok for trunk if all testings are fine?

BR,
Kewen


gcc/ChangeLog

2020-MM-DD  Kewen Lin  

* gcc/tree-vect-stmts.c (vectorizable_load): Check alignment to avoid
redundant half vector handlings for no peeling gaps.
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 7f3a9fb5fb3..bfd2fabaa81 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9582,6 +9582,12 @@ vectorizable_load (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
  {
tree ltype = vectype;
tree new_vtype = NULL_TREE;
+   unsigned HOST_WIDE_INT gap
+ = DR_GROUP_GAP (first_stmt_info);
+   unsigned int vect_align
+ = vect_known_alignment_in_bytes (first_dr_info);
+   unsigned int scalar_dr_size
+ = vect_get_scalar_dr_size (first_dr_info);
/* If there's no peeling for gaps but we have a gap
   with slp loads then load the lower half of the
   vector only.  See get_group_load_store_type for
@@ -9589,11 +9595,10 @@ vectorizable_load (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
if (slp
&& loop_vinfo
&& !LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo)
-   && DR_GROUP_GAP (first_stmt_info) != 0
-   && known_eq (nunits,
-(group_size
- - DR_GROUP_GAP (first_stmt_info)) * 2)
-   && known_eq (nunits, group_size))
+   && gap != 0
+   && known_eq (nunits, (group_size - gap) * 2)
+   && known_eq (nunits, group_size)
+   && gap >= (vect_align / scalar_dr_size))
  {
tree half_vtype;
new_vtype
@@ -9608,10 +9613,9 @@ vectorizable_load (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
if (ltype != vectype
&& memory_access_type == VMAT_CONTIGUOUS_REVERSE)
  {
-   unsigned HOST_WIDE_INT gap
- = DR_GROUP_GAP (first_stmt_info);
-   gap *= tree_to_uhwi (TYPE_SIZE_UNIT (elem_type));
-   tree gapcst = build_int_cst (ref_type, gap);
+   unsigned HOST_WIDE_INT gap_offset
+ = gap * tree_to_uhwi (TYPE_SIZE_UNIT (elem_type));
+   tree gapcst = build_int_cst (ref_type, gap_offset);
offset = size_binop (PLUS_EXPR, offset, gapcst);
  }
data_ref

Re: [PATCH] cselib, var-tracking: Improve debug info after the cselib sp tracking changes [PR94495]

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 09, 2020 at 10:57:46PM +0200, Christophe Lyon via Gcc-patches wrote:
> This patch makes GCC fail to build newlib when configured for
> aarch64_be-none-elf:
> 0x10c488c vt_expand_var_loc_chain
> 
> /tmp/9192639_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/var-tracking.c:8355

Seems it is the cselib_record_sp_cfa_base_equiv part of the patch (reverting
the add_stores change doesn't make the ICE go away).
The following fixes it, but don't have cycles to properly test it right now:

2020-04-10  Jakub Jelinek  

PR debug/94495
* cselib.c (cselib_record_sp_cfa_base_equiv): Set PRESERVED_VALUE_P on
val->val_rtx.

--- gcc/cselib.c.jj 2020-04-09 21:20:59.457529812 +0200
+++ gcc/cselib.c2020-04-10 11:49:45.820124893 +0200
@@ -2695,7 +2695,10 @@ cselib_record_sp_cfa_base_equiv (HOST_WI
 = cselib_lookup_from_insn (plus_constant (Pmode, sp_derived_value, offset),
   Pmode, 1, VOIDmode, insn);
   if (val != NULL)
-cselib_record_set (stack_pointer_rtx, val, NULL);
+{
+  PRESERVED_VALUE_P (val->val_rtx) = 1;
+  cselib_record_set (stack_pointer_rtx, val, NULL);
+}
 }
 
 /* Return true if V is SP_DERIVED_VALUE_P (or SP_DERIVED_VALUE_P + CONST_INT)

Jakub

[committed] libphobos: Use libdruntime as a convenience library for libphobos.

[Iain Buclaw via Gcc-patches]

Hi,

As a prerequesite for PR94304, it becomes easier to manage selectively
compiling sublibraries when there's only one library to link to.

So a druntime convenience library is built to be part of phobos, however
separate druntime library is still built and installed, to allow linking
only to the core runtime explicitly, rather than pulling in the entire
standard library with it.

The gdc driver no longer generates an '-lgdruntime' option, and the
inclusion of the libdruntime library path has been removed from the
testsuite.

Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.

Regards
Iain.

---
gcc/d/ChangeLog:

* d-spec.cc (LIBDRUNTIME): Remove.
(LIBDRUNTIME_PROFILE): Remove.
(lang_specific_driver): Don't link in libgdruntime.

gcc/testsuite/ChangeLog:

* lib/gdc.exp (gdc_link_flags): Remove libdruntime library path.

libphobos/ChangeLog:

* d_rules.am (libdgruntime_la_LINK): Move to libdruntime/Makefile.am.
(libgphobos_la_LINK): Move to src/Makefile.am
* libdruntime/Makefile.am: Add libgdruntime_convenience library.
* libdruntime/Makefile.in: Regenerate.
* src/Makefile.am (libgphobos_la_LIBADD): Add libgdruntime_convenience
library.
(libgphobos_la_DEPENDENCIES): Likewise.
* src/Makefile.in: Regenerate.
* testsuite/lib/libphobos.exp: Remove libdruntime library paths.
* testsuite/testsuite_flags.in: Likewise.
---
 gcc/d/d-spec.cc|  14 +--
 gcc/testsuite/lib/gdc.exp  |  14 +--
 libphobos/d_rules.am   |  11 --
 libphobos/libdruntime/Makefile.am  |  17 
 libphobos/libdruntime/Makefile.in  | 133 +
 libphobos/src/Makefile.am  |  13 ++-
 libphobos/src/Makefile.in  |  28 +++---
 libphobos/testsuite/lib/libphobos.exp  |   4 -
 libphobos/testsuite/testsuite_flags.in |   1 -
 9 files changed, 160 insertions(+), 75 deletions(-)

diff --git a/gcc/d/d-spec.cc b/gcc/d/d-spec.cc
index 8a0c7ca471c..e0844222520 100644
--- a/gcc/d/d-spec.cc
+++ b/gcc/d/d-spec.cc
@@ -44,13 +44,6 @@ along with GCC; see the file COPYING3.  If not see
 #define LIBPHOBOS_PROFILE LIBPHOBOS
 #endif
 
-#ifndef LIBDRUNTIME
-#define LIBDRUNTIME "gdruntime"
-#endif
-#ifndef LIBDRUNTIME_PROFILE
-#define LIBDRUNTIME_PROFILE LIBDRUNTIME
-#endif
-
 /* What do with libgphobos.  */
 enum phobos_action
 {
@@ -322,7 +315,7 @@ lang_specific_driver (cl_decoded_option 
**in_decoded_options,
 
   /* Make sure to have room for the trailing NULL argument.
  - needstdcxx might add `-lstdcxx'
- - libphobos adds `-Bstatic -lphobos -ldruntime -Bdynamic'
+ - libphobos adds `-Bstatic -lphobos -Bdynamic'
  - only_source adds 1 more arg, also maybe add `-o'.  */
   num_args = argc + need_stdcxx + shared_libgcc + need_phobos * 4 + 2;
   new_decoded_options = XNEWVEC (cl_decoded_option, num_args);
@@ -442,11 +435,6 @@ lang_specific_driver (cl_decoded_option 
**in_decoded_options,
   CL_DRIVER, &new_decoded_options[j]);
   added_libraries++;
   j++;
-  generate_option (OPT_l,
-  saw_profile_flag ? LIBDRUNTIME_PROFILE : LIBDRUNTIME, 1,
-  CL_DRIVER, &new_decoded_options[j]);
-  added_libraries++;
-  j++;
 
 #ifdef HAVE_LD_STATIC_DYNAMIC
   if (phobos_library == PHOBOS_DYNAMIC && static_link)
diff --git a/gcc/testsuite/lib/gdc.exp b/gcc/testsuite/lib/gdc.exp
index ddc6d9026a2..3912d9c1e21 100644
--- a/gcc/testsuite/lib/gdc.exp
+++ b/gcc/testsuite/lib/gdc.exp
@@ -146,16 +146,11 @@ proc gdc_link_flags { paths } {
append flags "-L${gccpath}/libphobos/src/.libs "
append ld_library_path ":${gccpath}/libphobos/src/.libs"
}
-   if { [file exists 
"${gccpath}/libphobos/libdruntime/.libs/libgdruntime.a"] \
-|| [file exists 
"${gccpath}/libphobos/libdruntime/.libs/libgdruntime.${shlib_ext}"] } {
-   append flags "-L${gccpath}/libphobos/libdruntime/.libs "
-   append ld_library_path ":${gccpath}/libphobos/libdruntime/.libs"
-   }
# Static linking is default. If only the shared lib is available adjust
# flags to always use it. If both are available, set SHARED_OPTION which
# will be added to PERMUTE_ARGS
-   if { [file exists 
"${gccpath}/libphobos/libdruntime/.libs/libgdruntime.${shlib_ext}"] } {
-   if { [file exists 
"${gccpath}/libphobos/libdruntime/.libs/libgdruntime.a"] } {
+   if { [file exists 
"${gccpath}/libphobos/src/.libs/libgphobos.${shlib_ext}"] } {
+   if { [file exists "${gccpath}/libphobos/src/.libs/libgphobos.a"] } {
set SHARED_OPTION "-shared-libphobos"
} else {
append flags "-shared-libphobos "
@@ -181,11 +176,6 @@ proc gdc_link_flags { paths } {
append flags "-B${libphobos} -L${libphobos} "
append ld_library_path ":${libphobos}"
   

Re: [PATCH, Fortran] -- PR fortran/87923 -- fix ICE when resolving I/O tags and simplify io.c

[Rainer Orth]

Hi Fritz,

> Thanks very much for the review.
>
> On Thu, Apr 9, 2020 at 5:21 AM Tobias Burnus  wrote:
>>
>> Hi,
>>
>> On 4/6/20 7:25 PM, Fritz Reese via Fortran wrote:
>>
>> > The attached patch fixes PR 87923 while also simplifying the code in
>> > io.c.
>>
>> Thanks for the work, which looks great; it is a bit lengthy
>> but mostly moving code or mechanical (%C → %L).
>> It also has an impressive amount of new test cases!
>
> I also wished the patch could be easier on the eyes, but alas
> sometimes this is the price of progress. :-)
>
>> * First line in git commit "Fix fortran/87923 -- ICE(s) when resolving
>> I/O tags."
>>It helps with doing patch archeology if they are the same – or if the
>> GIT one
>>is a substring of the email subject. (If it is about a PR, searching
>> for the PR
>>usually works, but also not al emails have the PR number in the subject.)
>>For this patch, you use:
>>email: "[PATCH, Fortran] -- PR fortran/87923 -- fix ICE when resolving
>> I/O tags and simplify io.c"
>>GIT: "Fix fortran/87923 -- ICE(s) when resolving I/O tags."
>
> Yes, that is a good point. I will alter the commit summary to match
> the email subject.
>
>> * Please check whether the ChangeLog lines are too long; I didn't count
>>but it looks as if they might be too long. For sure, they
>>were too long for your mail program …
>
> I copied the git commit message from the log, which git formats with
> an extra level of indentation. I wrapped the raw ChangeLog entries and
> commit message to 80 characters, but after the extra indentation my
> mail client indeed wrapped the lines during post-processing. I suppose
> I should wrap these each to 76 to account for git's indentation. That
> certainly makes "git log" look better.
>
>> * In the following comment, you have two empty tailing lines:
>>
>> +   Tag expressions are already resolved by resolve_tag, which includes
>> +   verifying the type, that they are scalar, and verifying that BT_CHARACTER
>> +   tags are of default kind.
>> +
>> +   */
>
> Oops!
>
>
> I will commit the patch with these fixes rebased on master after one
> final build+test. Thanks again for taking a look.

one new testcases comes up as UNRESOLVED everywhere:

+UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-not original 
"volatile.*?ivar_noasync"
+UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
original "volatile.*?ccvar_async" 1
+UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
original "volatile.*?darrvar_async" 1
+UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
original "volatile.*?dvar_async" 1
+UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
original "volatile.*?ivar_async" 1
+UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
original "volatile.*?lvar_async" 1
+UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
original "volatile.*?rvar_async" 1

gfortran.dg/asynchronous_5.f03   -O  : dump file does not exist

It has several scan-tree-dump* checks, but no corresponding
-fdump-tree-* option.  Please fix (and make sure not to look only for
FAILs during regtesting in the future).

Rainer

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

[PATCH] arc:commited: Allow more ABIs in GLIBC_DYNAMIC_LINKER

[Claudiu Zissulescu via Gcc-patches]

Backport to gcc9:

Enable big-endian suffixed dynamic linker per glibc multi-abi support.

And to avoid a future churn and version pairingi hassles, also allow
arc700 although glibc for ARC currently doesn't support it.

gcc/
-xx-xx  Vineet Gupta 

   * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700
---
 gcc/ChangeLog  | 6 ++
 gcc/config/arc/linux.h | 3 ++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 836a20f79d1..be4384eb0ef 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-10  Claudiu Zissulescu  
+
+   Backport from trunk
+   2020-0-31  Vineet Gupta 
+   * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700.
+
 2020-04-09  Michael Meissner  
 
Back port from trunk
diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
index 270ca907d87..7d07adc4257 100644
--- a/gcc/config/arc/linux.h
+++ b/gcc/config/arc/linux.h
@@ -29,7 +29,8 @@ along with GCC; see the file COPYING3.  If not see
 }  \
   while (0)
 
-#define GLIBC_DYNAMIC_LINKER   "/lib/ld-linux-arc.so.2"
+#define GLIBC_DYNAMIC_LINKER   \
+  "/lib/ld-linux-arc%{mbig-endian:eb}%{mcpu=arc700:700}.so.2"
 #define UCLIBC_DYNAMIC_LINKER  "/lib/ld-uClibc.so.0"
 
 /* Note that the default is to link against dynamic libraries, if they are
-- 
2.24.1

Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

[Claudiu Zissulescu Ianculescu via Gcc-patches]

Done.

Thank you for your support,
Claudiu

On Thu, Apr 9, 2020 at 2:38 AM Vineet Gupta  wrote:
>
> Hi Claudiu,
>
> For glibc needs can this be backported to gcc-9 please !
>
> Thx,
> -Vineet
>
> On 3/31/20 3:06 AM, Claudiu Zissulescu Ianculescu wrote:
> > Pushed.
> >
> > Thank you,
> > Claudiu
> >
> > On Sun, Mar 29, 2020 at 2:05 AM Vineet Gupta via Gcc-patches
> >  wrote:
> >> Enable big-endian suffixed dynamic linker per glibc multi-abi support.
> >>
> >> And to avoid a future churn and version pairingi hassles, also allow
> >> arc700 although glibc for ARC currently doesn't support it.
> >>
> >> gcc/
> >> -xx-xx  Vineet Gupta 
> >> +
> >> +   * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700
> >>
> >> Signed-off-by: Vineet Gupta 
> >> ---
> >>  gcc/ChangeLog  | 4 
> >>  gcc/config/arc/linux.h | 2 +-
> >>  2 files changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> >> index 86ad683a6cb0..c26a748fd51b 100644
> >> --- a/gcc/ChangeLog
> >> +++ b/gcc/ChangeLog
> >> @@ -1,3 +1,7 @@
> >> +2020-03-28  Vineet Gupta 
> >> +
> >> +   * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700
> >> +
> >>  2020-03-28  Jakub Jelinek  
> >>
> >> PR c/93573
> >> diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
> >> index 0b99da3fcdaf..1bbeccee7115 100644
> >> --- a/gcc/config/arc/linux.h
> >> +++ b/gcc/config/arc/linux.h
> >> @@ -29,7 +29,7 @@ along with GCC; see the file COPYING3.  If not see
> >>  }  \
> >>while (0)
> >>
> >> -#define GLIBC_DYNAMIC_LINKER   "/lib/ld-linux-arc.so.2"
> >> +#define GLIBC_DYNAMIC_LINKER   
> >> "/lib/ld-linux-arc%{mbig-endian:eb}%{mcpu=arc700:700}.so.2"
> >>  #define UCLIBC_DYNAMIC_LINKER  "/lib/ld-uClibc.so.0"
> >>
> >>  /* Note that the default is to link against dynamic libraries, if they are
> >> --
> >> 2.20.1
> >>
> > ___
> > linux-snps-arc mailing list
> > linux-snps-...@lists.infradead.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=MrObyH2ki95_7m_xHpnWX-k9eIMOsxMuSa48qhxYOCY&s=3ggbGwaiJuSFnFECy0ItuwBBMDAcriwCdSc3GA0UFig&e=
>

ICE on wrong colde [PR94192]

[Linus König]

Hi,

I fixed the style issues. However, omitting the checks for NULL produced 
several regressions in my previous tests.


Best regards,

Linus König

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 23b5a2b4439..ca149c0dd00 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12607,6 +12607,7 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
{
  gfc_error ("Array pointer %qs at %L must have a deferred shape or "
 "assumed rank", sym->name, &sym->declared_at);
+ sym->error = 1;
  return false;
}
 }
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 66ed925c10d..08342905286 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4089,10 +4089,19 @@ returnNull:
 static gfc_expr *
 simplify_bound (gfc_expr *array, gfc_expr *dim, gfc_expr *kind, int upper)
 {
+  gfc_symbol *array_sym;
   gfc_ref *ref;
   gfc_array_spec *as;
   int d;
 
+  /* Do not attempt to resolve if error has already been issued.  */
+  if (array && array->symtree && array->symtree->n.sym)
+{
+  array_sym = array->symtree->n.sym;
+  if (array_sym->error)
+   return NULL;
+}
+
   if (array->ts.type == BT_CLASS)
 return NULL;
 

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

[Thomas Schwinge]

Hi Tobias!

On 2020-04-08T09:55:24+0200, Tobias Burnus  wrote:
> I have now committed this patch
> as r10-7614-g13e41d8b9d3d7598c72c38acc86a3d97046c8373,
> reading "so we shall accept it" as approval …

That's OK.  As I said: "I'm not at all familiar with the front ends'
scoping implementation", and don't currently have time to learn about
that.  So, either you're confident that you're doing the right things
there (which I shall assume, given that you didn't explicitly ask whether
you're doing the right things), or you need to wait for somebody else to
review the patch.

Reviewers don't know everything -- certainly I don't ;-) -- and don't
have bandwidth to learn everything.  And even if a proper review is done,
often enough the reviewer fails to foresee the one detail that should've
been caught.  Hence, I'm happy to incrementally improve things, as long
as a patch isn't regressing any (or, too many) other things, and isn't
conceptually questionable (both of which doesn't apply here).  That's why
I said "we shall accept [the patch]" -- meaning "approved for commit,
without my proper review".


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

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

[Thomas Schwinge]

Hi Tobias!

I do see the new 'libgomp.oacc-c++/declare-pr94120.C' (see below, for
reference) FAIL for '-foffload=nvptx-none' execution testing.  The reason
is that the 'C' array doesn't have the content it's checked to have.

Now, my question, shouldn't it be changed like the attached patch, or
similar, because we actually first need to return from function 'f' in
order for the 'copyout(C)' to be executed?

Or, otherwise, what's the use of the 'copyout' clause with OpenACC
'declare'?  I suppose it's only meant to be used with function arguments,
because for every locally-defined variable (like 'C' in
'libgomp.oacc-c++/declare-pr94120.C'), that variable will be gone just
after the 'copyout' is executed, so the 'copyout' conceptually
equals/acts as 'create' in that case.  However, OpenACC explicitly does
allow 'copyout' in certain scenarios.  Do you think my interpretation is
correct, or what am I missing?  (In case the answer isn't obvious to you,
too, please file an issue with OpenACC, linking to this email for
reference.)

However, GCC doesn't like my changes either; actually two errors are
diagnosed:

[...]/libgomp.oacc-c++/declare-pr94120.C: In function ‘void f(int*)’:
[...]/libgomp.oacc-c++/declare-pr94120.C:21:30: error: array section in 
‘#pragma acc declare’
   21 | #pragma acc declare copyout (C[0:N])
  |  ^
[...]/libgomp.oacc-c++/declare-pr94120.C:21:30: error: ‘C’ must be a 
variable declared in the same scope as ‘#pragma acc declare’

Please have a look, and as necessary file GCC PRs, and XFAIL the
'libgomp.oacc-c++/declare-pr94120.C' execution testing for
'-DACC_MEM_SHARED=0'.


Grüße
 Thomas


On 2020-03-11T13:28:44+0100, Tobias Burnus  wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C
> @@ -0,0 +1,57 @@
> +#include 
> +#include 
> +
> +#define N 8
> +
> +namespace one {
> +  int A[N] = { 1, 2, 3, 4, 5, 6, 7, 8 };
> +  #pragma acc declare copyin (A)
> +};
> +
> +namespace outer {
> +  namespace inner {
> +int B[N];
> +#pragma acc declare create (B)
> +  };
> +};
> +
> +static void
> +f (void)
> +{
> +  int i;
> +  int C[N];
> +  #pragma acc declare copyout (C)
> +
> +  if (!acc_is_present (&one::A, sizeof (one::A)))
> +abort ();
> +
> +  if (!acc_is_present (&outer::inner::B, sizeof (outer::inner::B)))
> +abort ();
> +
> +#pragma acc parallel
> +  for (i = 0; i < N; i++)
> +{
> +  outer::inner::B[i] = one::A[i];
> +  C[i] = outer::inner::B[i];
> +}
> +
> +  for (i = 0; i < N; i++)
> +{
> +  if (C[i] != i + 1)
> + abort ();
> +}
> +
> +#pragma acc parallel
> +  for (i = 0; i < N; i++)
> +if (outer::inner::B[i] != i + 1)
> +  abort ();
> +}
> +
> +
> +int
> +main (int argc, char **argv)
> +{
> +  f ();
> +
> +  return 0;
> +}


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From cdb045dbfaec6dfca1cc49aa4d9b1fc79fc7837e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 10 Apr 2020 14:50:28 +0200
Subject: [PATCH] [WIP] Fix 'libgomp.oacc-c++/declare-pr94120.C' [PR94120]

---
 .../libgomp.oacc-c++/declare-pr94120.C| 25 +++
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C b/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C
index 1e1254187ea..bad74865135 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C
+++ b/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C
@@ -16,11 +16,11 @@ namespace outer {
 };
 
 static void
-f (void)
+f (int *C)
 {
+#pragma acc declare copyout (C[0:N])
+
   int i;
-  int C[N];
-  #pragma acc declare copyout (C)
 
   if (!acc_is_present (&one::A, sizeof (one::A)))
 abort ();
@@ -28,6 +28,9 @@ f (void)
   if (!acc_is_present (&outer::inner::B, sizeof (outer::inner::B)))
 abort ();
 
+  if (!acc_is_present (C, N * sizeof *C))
+abort ();
+
 #pragma acc parallel
   for (i = 0; i < N; i++)
 {
@@ -35,12 +38,6 @@ f (void)
   C[i] = outer::inner::B[i];
 }
 
-  for (i = 0; i < N; i++)
-{
-  if (C[i] != i + 1)
-	abort ();
-}
-
 #pragma acc parallel
   for (i = 0; i < N; i++)
 if (outer::inner::B[i] != i + 1)
@@ -51,7 +48,15 @@ f (void)
 int
 main (int argc, char **argv)
 {
-  f ();
+  int C[N];
+
+  f (C);
+
+  for (int i = 0; i < N; i++)
+{
+  if (C[i] != i + 1)
+	abort ();
+}
 
   return 0;
 }
-- 
2.17.1

[PATCH 3/5] testsuite: [arm/mve] Fix mve_move_gpr_to_gpr.c

[Christophe Lyon via Gcc-patches]

This test can pass with a hard-float toolchain, provided we don't
force -mfloat-abi=softfp.

This patch removes this useless option, as well as -save-temps which
is implied by arm_v8_1m_mve_fp.

2020-04-10  Christophe Lyon  

gcc/tesuite/
* gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c: Remove
useless options.
---
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
index 374bc4d..53300e5 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
 /* { dg-add-options arm_v8_1m_mve_fp } */
-/* { dg-additional-options "-O2 -mfloat-abi=softfp --save-temps" } */
+/* { dg-additional-options "-O2" } */
 
 #include "arm_mve.h"
 
-- 
2.7.4

[PATCH 1/5] testsuite: [arm] Add arm_softfp_ok and arm_hard_ok effective targets.

[Christophe Lyon via Gcc-patches]

For arm-linux-gnueabi* targets, a toolchain cannot support the
float-abi opposite to the one it has been configured for: since glibc
does not support such multilibs, we end up lacking gnu/stubs-*.h when
including stdint.h for instance.

This patch introduces two new effective targets to detect whether we
can compile tests with -mfloat-abi=softfp or -mfloat-abi=hard.

This enables to make such tests unsupported rather than fail.

2020-04-10  Christophe Lyon  

gcc/testsuite/
* lib/target-supports.exp (arm_softfp_ok): New effective target.
(arm_hard_ok): Likewise.
---
 gcc/testsuite/lib/target-supports.exp | 20 
 1 file changed, 20 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 3758bb3..6c8dd01 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4739,6 +4739,26 @@ proc check_effective_target_default_branch_protection { 
} {
 return [check_configured_with "enable-standard-branch-protection"]
 }
 
+# Return 1 if this is an ARM target supporting -mfloat-abi=softfp.
+
+proc check_effective_target_arm_softfp_ok { } {
+return [check_no_compiler_messages arm_softfp_ok object {
+   #include 
+   int dummy;
+   int main (void) { return 0; }
+   } "-mfloat-abi=softfp"]
+}
+
+# Return 1 if this is an ARM target supporting -mfloat-abi=hard.
+
+proc check_effective_target_arm_hard_ok { } {
+return [check_no_compiler_messages arm_hard_ok object {
+   #include 
+   int dummy;
+   int main (void) { return 0; }
+   } "-mfloat-abi=hard"]
+}
+
 # Return 1 if the target supports ARMv8.1-M MVE with floating point
 # instructions, 0 otherwise.  The test is valid for ARM.
 # Record the command line options needed.
-- 
2.7.4

[PATCH 5/5] testsuite: [arm/mve] Include arm_mve.h in arm_v8_1m_mve_ok

[Christophe Lyon via Gcc-patches]

Since arm_mve.h includes stdint.h, its use requires the presence of
the right gnu/stub-*.h, so make sure to include it when checking the
arm_v8_1m_mve_ok_nocache effective target, otherwise we can decide MVE
is supported while it's not really. This makes several tests
unsupported rather than fail.

2020-04-10  Christophe Lyon  

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_1m_mve_ok_nocache): Include
arm_mve.h.
---
 gcc/testsuite/lib/target-supports.exp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 6c8dd01..d16498d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4965,6 +4965,7 @@ proc check_effective_target_arm_v8_1m_mve_ok_nocache { } {
#if __ARM_BIG_ENDIAN
#error "MVE intrinsics are not supported in Big-Endian mode."
#endif
+   #include 
 } "$flags -mthumb"] } {
 set et_arm_v8_1m_mve_flags "$flags -mthumb --save-temps"
 return 1
-- 
2.7.4

[PATCH 4/5] testsuite: [arm/mve] Use dg-add-options arm_v8_1m_mve in MVE tests

[Christophe Lyon via Gcc-patches]

Several ARM/MVE tests can be compiled even if the toolchain does not
support -mfloat-abi=hard (softfp is OK).

Use dg-add-options arm_v8_1m_mve or arm_v8_1m_mve_fp instead of using
dg-additional-options.

2020-04-10  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/mve/intrinsics/mve_vector_float.c: Use
arm_v8_1m_mve_fp.
* gcc.target/arm/mve/intrinsics/mve_vector_float1.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_int.c: Use
arm_v8_1m_mve.
* gcc.target/arm/mve/intrinsics/mve_vector_int1.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_int2.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint1.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint2.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c  | 2 +-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c | 2 +-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c | 2 +-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c| 2 +-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c   | 2 +-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int2.c   | 2 +-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint.c   | 2 +-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint1.c  | 2 +-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint2.c  | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
index 881157f..6519b81 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
index 9515ed6..855e3b8 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
index 3ce8ea3..e3cf8f8 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
index dab0705..e70cbc1 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c
index e54516b..b13d0a8 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int2.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve

[PATCH 2/5] testsuite: [arm/mve] Use arm_softfp and arm_hard as needed in MVE tests

[Christophe Lyon via Gcc-patches]

Some MVE tests explicitly test a -mfloat-abi=hard option, but we need
to check that the toolchain actually supports it (which may not be the
case for arm-linux-gnueabi* targets).

We also make use of dg-add-options arm_v8_1m_mve_fp and arm_v8_1m_mve
instead of duplicating the corresponding options in
dg-additional-options where we keep only -mfloat-abi to override the
option selected by arm_v8_1m_mve_fp.

2020-04-10  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c: Use arm_hard_ok
effective target and arm_v8_1m_mve_fp options.
* gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c: Use arm_softfp_ok
effective target and arm_v8_1m_mve_fp options.
* gcc.target/arm/mve/intrinsics/mve_fpu1.c: Use arm_hard_ok
effective target and arm_v8_1m_mve options.
* gcc.target/arm/mve/intrinsics/mve_fpu2.c: Use arm_softfp_ok
effective target and arm_v8_1m_mve options.
---
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c | 4 +++-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c | 4 +++-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c| 4 +++-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c| 4 +++-
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
index 1462dd4..0fa3afd 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
@@ -1,6 +1,8 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfloat-abi=hard 
-mthumb -mfpu=auto --save-temps" } */
+/* { dg-additional-options "-mfloat-abi=hard" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
index d528133..1fca110 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
@@ -1,5 +1,7 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfloat-abi=softfp 
-mthumb -mfpu=auto --save-temps" } */
+/* { dg-require-effective-target arm_softfp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+/* { dg-additional-options "-mfloat-abi=softfp" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
index 59ca724..726f9ec 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
@@ -1,6 +1,8 @@
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard -mthumb 
-mfpu=auto --save-temps" } */
+/* { dg-additional-options "-mfloat-abi=hard" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
index ce297ea..7f39905 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
@@ -1,6 +1,8 @@
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-require-effective-target arm_softfp_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=softfp 
-mthumb -mfpu=auto --save-temps" } */
+/* { dg-additional-options "-mfloat-abi=softfp" } */
 
 #include "arm_mve.h"
 
-- 
2.7.4

Re: [PATCH] Handle 'omp declare target' attribute set for both OpenACC and OpenMP 'target' [PR89433, PR93465]

[Thomas Schwinge]

Hi!

On 2020-03-04T20:07:46+0100, Jakub Jelinek  wrote:
> On Wed, Mar 04, 2020 at 08:27:10PM +0100, Thomas Schwinge wrote:
>> ... which as of PR89433 commit b48f44bf77a39fefc238a16cf1225c6464c82406 
>> causes
>> an ICE.  Not sure if this is actually supposed to be valid or invalid code.
>> Until the interactions between OpenACC and OpenMP 'target' get defined
>> properly, make this a compile-time error.
>>
>>  gcc/
>>  PR middle-end/89433
>>  PR middle-end/93465
>>  * omp-general.c (oacc_verify_routine_clauses): Diagnose if
>>  "#pragma omp declare target" has also been applied.
>>  gcc/testsuite/
>>  PR middle-end/89433
>>  PR middle-end/93465
>>  * c-c++-common/goacc-gomp/pr93465-1.c: New file.
>
> Ok for trunk.

Thanks for the review, and sorry for the delay; now pushed to master
branch in commit ff3f862b451496dd4afbe2dbfae82afab59a42c6 "Handle 'omp
declare target' attribute set for both OpenACC and OpenMP 'target'
[PR89433, PR93465]", see attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From ff3f862b451496dd4afbe2dbfae82afab59a42c6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 4 Mar 2020 17:58:33 +0100
Subject: [PATCH] Handle 'omp declare target' attribute set for both OpenACC
 and OpenMP 'target' [PR89433, PR93465]

... which as of PR89433 commit b48f44bf77a39fefc238a16cf1225c6464c82406 causes
an ICE.  Not sure if this is actually supposed to be valid or invalid code.
Until the interactions between OpenACC and OpenMP 'target' get defined
properly, make this a compile-time error.

	gcc/
	PR middle-end/89433
	PR middle-end/93465
	* omp-general.c (oacc_verify_routine_clauses): Diagnose if
	"#pragma omp declare target" has also been applied.
	gcc/testsuite/
	PR middle-end/89433
	PR middle-end/93465
	* c-c++-common/goacc-gomp/pr93465-1.c: New file.
---
 gcc/ChangeLog |  7 +++
 gcc/omp-general.c | 13 +
 gcc/testsuite/ChangeLog   |  6 ++
 .../c-c++-common/goacc-gomp/pr93465-1.c   | 56 +++
 4 files changed, 82 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/goacc-gomp/pr93465-1.c

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index bce700e472e..33e980bd977 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2020-04-10  Thomas Schwinge  
+
+	PR middle-end/89433
+	PR middle-end/93465
+	* omp-general.c (oacc_verify_routine_clauses): Diagnose if
+	"#pragma omp declare target" has also been applied.
+
 2020-04-09  Jozef Lawrynowicz  
 
 	* config/msp430/msp430.c (msp430_expand_epilogue): Use emit_jump_insn
diff --git a/gcc/omp-general.c b/gcc/omp-general.c
index f107f4c050f..49023f42c47 100644
--- a/gcc/omp-general.c
+++ b/gcc/omp-general.c
@@ -1776,6 +1776,19 @@ oacc_verify_routine_clauses (tree fndecl, tree *clauses, location_t loc,
 = lookup_attribute ("omp declare target", DECL_ATTRIBUTES (fndecl));
   if (attr != NULL_TREE)
 {
+  /* Diagnose if "#pragma omp declare target" has also been applied.  */
+  if (TREE_VALUE (attr) == NULL_TREE)
+	{
+	  /* See ; the semantics of combining
+	 OpenACC and OpenMP 'target' are not clear.  */
+	  error_at (loc,
+		"cannot apply %<%s%> to %qD, which has also been"
+		" marked with an OpenMP 'declare target' directive",
+		routine_str, fndecl);
+	  /* Incompatible.  */
+	  return -1;
+	}
+
   /* If a "#pragma acc routine" has already been applied, just verify
 	 this one for compatibility.  */
   /* Collect previous directive's clauses.  */
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index bced3e27d86..235d481e6cf 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-10  Thomas Schwinge  
+
+	PR middle-end/89433
+	PR middle-end/93465
+	* c-c++-common/goacc-gomp/pr93465-1.c: New file.
+
 2020-04-10  Iain Buclaw  
 
 	* lib/gdc.exp (gdc_link_flags): Remove libdruntime library paths.
diff --git a/gcc/testsuite/c-c++-common/goacc-gomp/pr93465-1.c b/gcc/testsuite/c-c++-common/goacc-gomp/pr93465-1.c
new file mode 100644
index 000..c8b9135d997
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc-gomp/pr93465-1.c
@@ -0,0 +1,56 @@
+#pragma omp declare target
+#pragma acc routine seq /* { dg-error "cannot apply '#pragma acc routine' to '\(void \)?f1\(\\(\\)\)?', which has also been marked with an OpenMP 'declare target' directive" } */
+void f1 (void) {}
+#pragma omp end declare target
+
+#pragma omp declare target
+void f1 (void);
+
+#pragma acc routine seq /* { dg-error "cannot apply '#pragma acc routine' to '\(void \)?f1\(\\(\\)\)?', which has also been marked with an OpenMP 'declare target' directive" } */
+void f1 (void);
+
+
+
+#pragma omp declare target
+#pragma acc routine /* { dg-error "cannot apply '#pragma ac

Re: [Patch] libgomp – fix handling of 'target enter data'

[Thomas Schwinge]

Hi!

On 2020-03-31T19:41:40+0200, Tobias Burnus  wrote:
> libgomp – fix handling of 'target enter data'
>
>   * target.c (GOMP_target_enter_exit_data): Handle PSET/MAP_POINTER.
>   * testsuite/libgomp.fortran/target-enter-data-1.f90: New.
>
>  libgomp/target.c   | 13 +++-
>  .../libgomp.fortran/target-enter-data-1.f90| 36 
> ++
>  2 files changed, 48 insertions(+), 1 deletion(-)

> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> @@ -2480,7 +2480,9 @@ GOMP_target_enter_exit_data (int device, size_t mapnum, 
> void **hostaddrs,
>   }
>  }
>
> -  size_t i;
> +  /* The variables are mapped separately such that they can be released
> + independently.  */
> +  size_t i, j;
>if ((flags & GOMP_TARGET_FLAG_EXIT_DATA) == 0)
>  for (i = 0; i < mapnum; i++)
>if ((kinds[i] & 0xff) == GOMP_MAP_STRUCT)
> @@ -2489,6 +2491,15 @@ GOMP_target_enter_exit_data (int device, size_t 
> mapnum, void **hostaddrs,
>&kinds[i], true, GOMP_MAP_VARS_ENTER_DATA);
> i += sizes[i];
>   }
> +  else if ((kinds[i] & 0xff) == GOMP_MAP_TO_PSET)
> + {
> +   for (j = i + 1; j < mapnum; j++)
> + if (!GOMP_MAP_POINTER_P (get_kind (true, kinds, j) & 0xff))
> +   break;
> +   gomp_map_vars (devicep, j-i, &hostaddrs[i], NULL, &sizes[i],
> +  &kinds[i], true, GOMP_MAP_VARS_ENTER_DATA);
> +   i += j - i - 1;
> + }
>else
>   gomp_map_vars (devicep, 1, &hostaddrs[i], NULL, &sizes[i], &kinds[i],
>  true, GOMP_MAP_VARS_ENTER_DATA);

Aha, thanks -- that resolves doubts I had (but Julian and I couldn't
allocate time to track down): see 'GOMP_target_enter_exit_data' mentioned
in 
ff., for example.


Isn't that a pretty severe Fortran OpenMP offloading issue, and should
get a PR allocated, and fixed on release branches, too?


> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90
> @@ -0,0 +1,36 @@
> +program main
> +[...]

I pushed to master branch commit 6b816a5f0ed078cb2d380e10e68a95fb7e3d6778
"Add 'dg-do run' to 'libgomp.fortran/target-enter-data-1.f90'", see
attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 6b816a5f0ed078cb2d380e10e68a95fb7e3d6778 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 1 Apr 2020 23:26:56 +0200
Subject: [PATCH] Add 'dg-do run' to 'libgomp.fortran/target-enter-data-1.f90'
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fix-up for commit 689418b97e5eb6a221871a2439bca3e6283ac579 "libgomp – fix
handling of 'target enter data'".

	libgomp/
	* testsuite/libgomp.fortran/target-enter-data-1.f90: Add 'dg-do
	run'.
---
 libgomp/ChangeLog | 5 +
 libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90 | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 0e4958f0c67..beff3d65b44 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-10  Thomas Schwinge  
+
+	* testsuite/libgomp.fortran/target-enter-data-1.f90: Add 'dg-do
+	run'.
+
 2020-04-08  Tobias Burnus  
 
 	PR middle-end/94120
diff --git a/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90 b/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90
index 91dedebf0a0..39faffd44c2 100644
--- a/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90
+++ b/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90
@@ -1,3 +1,5 @@
+! { dg-do run }
+
 program main
   implicit none
   integer, allocatable, dimension(:) :: AA, BB, CC, DD
-- 
2.17.1

Test cases for mixed structured/dynamic data lifetimes with OpenACC [PR92843] (was: [PATCH 0/3] Mixed static/dynamic data lifetimes with OpenACC (PR92843))

[Thomas Schwinge]

Hi!

On 2020-01-17T12:18:18-0800, Julian Brown  wrote:
> This patch series provides fixes for some cases of mixing static and

(It's "structured", not "static".)  ;-)

> dynamic data lifetimes in OpenACC, hopefully addressing some of Thomas's
> concerns in PR92843 -- in particular that an "exit data"-type operation on
> a given variable inside a structured block (also mapping that variable)
> should be a no-op.
>
> On further investigation of related patterns, other cases of mixing static
> and dynamic lifetimes also turn out to problematic at present. Some of
> these cases are handled by this patch series, and others are diagnosed
> as errors (rather than allowing silent and hard-to-diagnose failures
> later during runtime).
>
> The first two patches are sufficient to fix the test case introduced
> for PR92843, and the third patch provides further support/diagnostics
> for dynamic unmapping operations taking place within structured blocks.
>
> Further commentary provided alongside individual patches. Tested with
> offloading to NVPTX, also with a version of my refcount-verification patch
> (not currently on trunk).
>
> I believe this (at least the first two parts) fixes a regression (for
> the pr92843-1.c test case), so OK for stage 4?

Thanks for your continued work here.

The code changes will need further review and discussion, but the thing
is: the test cases you provided already PASS now (on master branch, and
also on releases/gcc-9 branch, which is the first branch to implement
these semantics), so I now already pushed these test cases to master
branch in commit be9862dd96945772ae0692bc95b37ec6dbcabda0 "Test cases for
mixed structured/dynamic data lifetimes with OpenACC [PR92843]", and to
releases/gcc-9 branch in commit 3c7a476c5ad3761cb5373f8c59a92e04525c5638
"Test cases for mixed structured/dynamic data lifetimes with OpenACC
[PR92843]", see attached.  (That's with all XFAILs removed, meaning that
the XFAILs will need to be re-instantiated with the code changes that
actually break the respective functionality.)


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From be9862dd96945772ae0692bc95b37ec6dbcabda0 Mon Sep 17 00:00:00 2001
From: Julian Brown 
Date: Fri, 17 Jan 2020 13:18:18 -0800
Subject: [PATCH] Test cases for mixed structured/dynamic data lifetimes with
 OpenACC [PR92843]

	libgomp/
	PR libgomp/92843
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c:
	New file.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2-lib.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3-lib.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4-lib.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5-lib.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6-lib.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7-lib.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8-lib.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8.c:
	Likewise.
---
 libgomp/ChangeLog |  37 
 .../static-dynamic-lifetimes-1-lib.c  |   3 +
 .../static-dynamic-lifetimes-1.c  | 160 +++
 .../static-dynamic-lifetimes-2-lib.c  |   3 +
 .../static-dynamic-lifetimes-2.c  | 166 
 .../static-dynamic-lifetimes-3-lib.c  |   3 +
 .../static-dynamic-lifetimes-3.c  | 183 ++
 .../static-dynamic-lifetimes-4-lib.c  |   3 +
 .../static-dynamic-lifetimes-4.c  |  64 ++
 .../static-dynamic-lifetimes-5-lib.c  |   3 +
 .../static-dynamic-lifetimes-5.c  |  56 ++
 .../static-dynamic-lifetimes-6-lib.c  |   3 +
 .../static-dynamic-lifetimes-6.c  |  42 
 .../static-dynamic-lifetimes-7-lib.c  |   3 +
 .../static-dynamic-lifetimes-7.c  |  42 
 .../static-dynamic-lifetimes-8-lib.c  |   3 +
 .../static-dynamic-lifetimes-8.c  |  47 +
 17 files changed, 821 insertions(+)
 create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c
 create mode 100644 libgomp/tests

Re: [Patch] libgomp – fix handling of 'target enter data'

[Jakub Jelinek via Gcc-patches]

On Fri, Apr 10, 2020 at 04:31:37PM +0200, Thomas Schwinge wrote:
> Aha, thanks -- that resolves doubts I had (but Julian and I couldn't
> allocate time to track down): see 'GOMP_target_enter_exit_data' mentioned
> in 
> ff., for example.
> 
> 
> Isn't that a pretty severe Fortran OpenMP offloading issue, and should
> get a PR allocated, and fixed on release branches, too?

On branches where target enter data is actually accepted we could backport
it, sure.

Jakub

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

[Jason Merrill via Gcc-patches]

On 4/9/20 4:23 PM, Martin Sebor wrote:

On 4/9/20 1:32 PM, Jason Merrill wrote:

On 4/9/20 3:24 PM, Martin Sebor wrote:

On 4/9/20 1:03 PM, Jason Merrill wrote:

On 4/8/20 1:23 PM, Martin Sebor wrote:

On 4/7/20 3:36 PM, Marek Polacek wrote:

On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote:

On 4/7/20 1:50 PM, Marek Polacek wrote:
On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via 
Gcc-patches wrote:

Among the numerous regressions introduced by the change committed
to GCC 9 to allow string literals as template arguments is a 
failure
to recognize the C++ nullptr and GCC's __null constants as 
pointers.
For one, I didn't realize that nullptr, being a null pointer 
constant,
doesn't have a pointer type, and two, I didn't think of __null 
(which

is a special integer constant that NULL sometimes expands to).

The attached patch adjusts the special handling of trailing zero
initializers in reshape_init_array_1 to recognize both kinds of
constants and avoid treating them as zeros of the array integer
element type.  This restores the expected diagnostics when either
constant is used in the initializer list.

Martin


PR c++/94510 - nullptr_t implicitly cast to zero twice in 
std::array


gcc/cp/ChangeLog:

PR c++/94510
* decl.c (reshape_init_array_1): Exclude mismatches with 
all kinds

of pointers.

gcc/testsuite/ChangeLog:

PR c++/94510
* g++.dg/init/array57.C: New test.
* g++.dg/init/array58.C: New test.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a127734af69..692c8ed73f4 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6041,9 +6041,14 @@ reshape_init_array_1 (tree elt_type, 
tree max_index, reshape_iter *d,

   TREE_CONSTANT (new_init) = false;
 /* Pointers initialized to strings must be treated as 
non-zero

- even if the string is empty.  */
+ even if the string is empty.  Handle all kinds of pointers,
+ including std::nullptr and GCC's __nullptr, neither of which
+ has a pointer type.  */
 tree init_type = TREE_TYPE (elt_init);
-  if (POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type)
+  bool init_is_ptr = (POINTER_TYPE_P (init_type)
+  || NULLPTR_TYPE_P (init_type)
+  || null_node_p (elt_init));
+  if (POINTER_TYPE_P (elt_type) != init_is_ptr
 || !type_initializer_zero_p (elt_type, elt_init))
   last_nonzero = index;


It looks like this still won't handle e.g. pointers to member 
functions,

e.g.

struct S { };
int arr[3] = { (void (S::*) ()) 0, 0, 0 };

would still be accepted.  You could use TYPE_PTR_OR_PTRMEM_P 
instead of

POINTER_TYPE_P to catch this case.


Good catch!  That doesn't fail because unlike null data member 
pointers
which are represented as -1, member function pointers are 
represented

as a zero.

I had looked for an API that would answer the question: "is this
expression a pointer?" without having to think of all the different
kinds of them but all I could find was null_node_p().  Is this a 
rare,

isolated case that having an API like that wouldn't be worth having
or should I add one like in the attached update?

Martin



PR c++/94510 - nullptr_t implicitly cast to zero twice in std::array

gcc/cp/ChangeLog:

PR c++/94510
* decl.c (reshape_init_array_1): Exclude mismatches with all 
kinds

of pointers.
* gcc/cp/cp-tree.h (null_pointer_constant_p): New function.


(Drop the gcc/cp/.)


+/* Returns true if EXPR is a null pointer constant of any type.  */
+
+inline bool
+null_pointer_constant_p (tree expr)
+{
+  STRIP_ANY_LOCATION_WRAPPER (expr);
+  if (expr == null_node)
+    return true;
+  tree type = TREE_TYPE (expr);
+  if (NULLPTR_TYPE_P (type))
+    return true;
+  if (POINTER_TYPE_P (type))
+    return integer_zerop (expr);
+  return null_member_pointer_value_p (expr);
+}
+


We already have a null_ptr_cst_p so it would be sort of confusing 
to have
this as well.  But are you really interested in whether it's a 
null pointer,

not just a pointer?


The goal of the code is to detect a mismatch in "pointerness" between
an initializer expression and the type of the initialized element, so
it needs to know if the expression is a pointer (non-nulls pointers
are detected in type_initializer_zero_p).  That means testing a number
of IMO unintuitive conditions:

   TYPE_PTR_OR_PTRMEM_P (TREE_TYPE (expr))
   || NULLPTR_TYPE_P (TREE_TYPE (expr))
   || null_node_p (expr)

I don't know if this type of a query is common in the C++ FE but 
unless

this is an isolated use case then besides fixing the bug I thought it
would be nice to make it easier to get the test above right, or at 
least

come close to it.

Since null_pointer_constant_p already exists (but isn't suitable here
because it returns true for plain literal zeros)


Why is that unsuitable?  A literal zero is a perfectly good 
zero-initializer for a pointer.


Right, that's why it's not suitable here.  Because a literal zero
is also not a pointer.

The question the code ask

Re: [PATCH, Fortran] -- PR fortran/87923 -- fix ICE when resolving I/O tags and simplify io.c

[Fritz Reese via Gcc-patches]

On Fri, Apr 10, 2020 at 8:14 AM Rainer Orth  
wrote:
>
> Hi Fritz,
[...]
> one new testcases comes up as UNRESOLVED everywhere:
>
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-not 
> original "volatile.*?ivar_noasync"
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
> original "volatile.*?ccvar_async" 1
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
> original "volatile.*?darrvar_async" 1
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
> original "volatile.*?dvar_async" 1
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
> original "volatile.*?ivar_async" 1
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
> original "volatile.*?lvar_async" 1
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03   -O   scan-tree-dump-times 
> original "volatile.*?rvar_async" 1
>
> gfortran.dg/asynchronous_5.f03   -O  : dump file does not exist
>
> It has several scan-tree-dump* checks, but no corresponding
> -fdump-tree-* option.  Please fix (and make sure not to look only for
> FAILs during regtesting in the future).
>
> Rainer

Ah! My mistake... I will fix and look for this in the future.

Fritz

Re: ICE on wrong colde [PR94192]

[Fritz Reese via Gcc-patches]

On Fri, Apr 10, 2020 at 8:27 AM Linus König  wrote:
>
> Hi,
>
> I fixed the style issues. However, omitting the checks for NULL produced
> several regressions in my previous tests.
>

The style looks good. Please share testcases which exhibit the
regressions. They will also need to be included in
gcc/testsuite/gfortran.dg/ as part of the final commit. I am not aware
of a good source of documentation for writing the testcases
appropriate for DejaGnu, but you can examine other testcases to see
some examples. I can help you format the testcases as well. For the
final commit, a ChangeLog entry will also be necessary: take a look at
gcc/fortran/ChangeLog and match the format of previous entries. In
this case an entry for this patch might look something like this:

2020-04-10  Linus König  

PR fortran/94192
* resolve.c (resolve_fl_var_and_proc): Mark invalid array pointer
symbol with error.
* simplify.c (simplify_bound): Don't simplify if an error was
already reported.


With this patch, I am not convinced that NULL components would be
handled properly. It appears that if array is NULL, the new check will
not pass and the next line "array->ts.type == BT_CLASS" will segfault.
If array->symtree is NULL and the next two checks for BT_CLASS and
EXPR_VARIABLE do not pass, then the line "as = array->symtree->n.sym"
will segfault. Perhaps seeing the relevant testcases will clarify the
conditions which this patch covers.

If you believe the NULL guards are required, please consider the
following replacement for the code in simplify_bound, which would
protect the surrounding code as well:

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index f63f63c9ef6..20d02210971 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4155,10 +4155,14 @@ returnNull:
 static gfc_expr *
 simplify_bound (gfc_expr *array, gfc_expr *dim, gfc_expr *kind, int upper)
 {
+  gfc_symbol *array_sym;
   gfc_ref *ref;
   gfc_array_spec *as;
   int d;

+  if (!array)
+return NULL;
+
   if (array->ts.type == BT_CLASS)
 return NULL;

@@ -4169,8 +4173,16 @@ simplify_bound (gfc_expr *array, gfc_expr *dim,
gfc_expr *kind, int upper)
   goto done;
 }

+  if (!array->symtree)
+return NULL;
+
+  /* Do not attempt to resolve if error has already been issued.  */
+  array_sym = array->symtree->n.sym;
+  if (!array_sym || array_sym->error)
+return NULL;
+
   /* Follow any component references.  */
-  as = array->symtree->n.sym->as;
+  as = array_sym->as;
   for (ref = array->ref; ref; ref = ref->next)
 {
   switch (ref->type)


---
Fritz Reese

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

On Thu, 9 Apr 2020, Patrick Palka wrote:
> On Thu, 9 Apr 2020, Jason Merrill wrote:
> 
> > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > When evaluating the initializer of 'a' in the following example
> > > 
> > >struct A { A *p = this; };
> > >constexpr A foo() { return {}; }
> > >constexpr A a = foo();
> > > 
> > > the PLACEHOLDER_EXPR for 'this' in the aggregate initializer returned by 
> > > foo
> > > gets resolved to the RESULT_DECL of foo.  But due to guaranteed RVO, the
> > > 'this'
> > > should really be resolved to '&a'.
> > 
> > > It seems to me that the right approach would be to immediately resolve the
> > > PLACEHOLDER_EXPR to the correct target object during evaluation of 
> > > 'foo()',
> > > so
> > > that we could use 'this' to access objects adjacent to the current object 
> > > in
> > > the
> > > ultimate storage location.  (I think #c2 of PR c++/94537 is an example of
> > > such
> > > usage of 'this', which currently doesn't work.  But as #c1 shows we don't
> > > seem
> > > to handle this case correctly in non-constexpr initialization either.)
> > 
> > As I commented in the PR, the standard doesn't require this to work because 
> > A
> > is trivially copyable, and our ABI makes it impossible.  But there's still a
> > constexpr bug when we add
> > 
> > A() = default; A(const A&);
> > 
> > clang doesn't require the constructors to make this work for constant
> > initialization, but similarly can't make it work for non-constant
> > initialization.
> 
> That makes a lot of sense, thanks for the detailed explanation.
> 
> > 
> > > I haven't yet been able to make a solution using the above approach work 
> > > --
> > > making sure we use the ultimate object instead of the RESULT_DECL whenever
> > > we
> > > access ctx->global->values is proving to be tricky and subtle.
> > 
> > Do we need to go through ctx->global->values?  Would it work for the
> > RESULT_DECL case in cxx_eval_constant_expression to go to straight to
> > ctx->object or ctx->ctor instead?
> 
> I attempted that at some point, but IIRC we still end up not resolving
> some RESULT_DECLs because not all of them get processed through
> cxx_eval_constant_expression before we manipulate ctx->global->values
> with them.  I'll try this approach more carefully and report back with
> more specifics.

It turns out that immediately resolving RESULT_DECLs/'this' to the
ultimate ctx->object would not interact well with constexpr_call
caching:

  struct A { A() = default; A(const A&); A *ap = this; };
  constexpr A foo() { return {}; }
  constexpr A a = foo();
  constexpr A b = foo();
  static_assert(b.ap == &b); // fails

Evaluation of the first call to foo() returns {&a}, since we resolve
'this' to &a due to guaranteed RVO, and we cache this result.
Evaluation of the second call to foo() just returns the cached result
from the constexpr_call cache, and so we get {&a} again.

So it seems we would have to mark the result of a constexpr call as not
cacheable whenever this RVO applies during its evaluation, even when
doing the RVO has no observable difference in the final result (i.e. the
constructor does not try to save the 'this' pointer).

Would the performance impact of disabling caching whenever RVO applies
during constexpr call evaluation be worth it, or should we go with
something like my first patch which "almost works," and which marks a
constexpr call as not cacheable only when we replace a RESULT_DECL in
the result of the call?

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Jason Merrill via Gcc-patches]

On 4/10/20 1:04 PM, Patrick Palka wrote:

On Thu, 9 Apr 2020, Patrick Palka wrote:

On Thu, 9 Apr 2020, Jason Merrill wrote:


On 4/8/20 7:49 PM, Patrick Palka wrote:

When evaluating the initializer of 'a' in the following example

struct A { A *p = this; };
constexpr A foo() { return {}; }
constexpr A a = foo();

the PLACEHOLDER_EXPR for 'this' in the aggregate initializer returned by foo
gets resolved to the RESULT_DECL of foo.  But due to guaranteed RVO, the
'this'
should really be resolved to '&a'.



It seems to me that the right approach would be to immediately resolve the
PLACEHOLDER_EXPR to the correct target object during evaluation of 'foo()',
so
that we could use 'this' to access objects adjacent to the current object in
the
ultimate storage location.  (I think #c2 of PR c++/94537 is an example of
such
usage of 'this', which currently doesn't work.  But as #c1 shows we don't
seem
to handle this case correctly in non-constexpr initialization either.)


As I commented in the PR, the standard doesn't require this to work because A
is trivially copyable, and our ABI makes it impossible.  But there's still a
constexpr bug when we add

A() = default; A(const A&);

clang doesn't require the constructors to make this work for constant
initialization, but similarly can't make it work for non-constant
initialization.


That makes a lot of sense, thanks for the detailed explanation.




I haven't yet been able to make a solution using the above approach work --
making sure we use the ultimate object instead of the RESULT_DECL whenever
we
access ctx->global->values is proving to be tricky and subtle.


Do we need to go through ctx->global->values?  Would it work for the
RESULT_DECL case in cxx_eval_constant_expression to go to straight to
ctx->object or ctx->ctor instead?


I attempted that at some point, but IIRC we still end up not resolving
some RESULT_DECLs because not all of them get processed through
cxx_eval_constant_expression before we manipulate ctx->global->values
with them.  I'll try this approach more carefully and report back with
more specifics.


It turns out that immediately resolving RESULT_DECLs/'this' to the
ultimate ctx->object would not interact well with constexpr_call
caching:

   struct A { A() = default; A(const A&); A *ap = this; };
   constexpr A foo() { return {}; }
   constexpr A a = foo();
   constexpr A b = foo();
   static_assert(b.ap == &b); // fails

Evaluation of the first call to foo() returns {&a}, since we resolve
'this' to &a due to guaranteed RVO, and we cache this result.
Evaluation of the second call to foo() just returns the cached result
from the constexpr_call cache, and so we get {&a} again.

So it seems we would have to mark the result of a constexpr call as not
cacheable whenever this RVO applies during its evaluation, even when
doing the RVO has no observable difference in the final result (i.e. the
constructor does not try to save the 'this' pointer).

Would the performance impact of disabling caching whenever RVO applies
during constexpr call evaluation be worth it, or should we go with
something like my first patch which "almost works," and which marks a
constexpr call as not cacheable only when we replace a RESULT_DECL in
the result of the call?


Could we search through the result of the call for ctx->object and cache 
if we don't find it?


Jason

Re: [PATCH v2 1/2] RISC-V: Update march parser

[Jim Wilson]

On Fri, Apr 10, 2020 at 2:20 AM Kito Cheng  wrote:
>  - The arch string rule has changed in latest spec, it introduced new
>multi-letter extension prefix with 'h' and 'z', and drop `sx`. also
>adjust parsing order for 's' and 'x'.

This is OK.

Jim

Re: [PATCH] c++: make __is_constructible work with paren-init of aggrs [PR94149]

[Jason Merrill via Gcc-patches]

On 4/9/20 5:00 PM, Marek Polacek wrote:

In C++20 this is well-formed:

   using T = int[2];
   T t(1, 2);

which means that std::is_constructible_v should be true.
But constructible_expr immediately returned the error_mark_node when it
saw a list with more than one element.  To give accurate results in
C++20, we have to try initializing the aggregate from a parenthesized list of
values.

To not repeat the same mistake as in c++/93790, if there's only one
element, I'm trying {} only when () didn't succeed.  is_constructible5.C
verifies this.

Jon, in paren-init24.C std::is_nothrow_constructible_v doesn't work,
I'm getting
  error: invalid 'static_cast' from type 'int' to type 'int [1]'
and
  error: functional cast to array type 'int [2]'

Are these the issues you had in mind when we spoke earlier today?

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK.


PR c++/94149
* method.c (constructible_expr): In C++20, try using parenthesized
initialization of aggregates to determine the result of
__is_constructible.

* g++.dg/cpp2a/paren-init24.C: New test.
* g++.dg/cpp2a/paren-init25.C: New test.
* g++.dg/ext/is_constructible5.C: New test.
---
  gcc/cp/method.c  | 42 ++--
  gcc/testsuite/g++.dg/cpp2a/paren-init24.C| 26 
  gcc/testsuite/g++.dg/cpp2a/paren-init25.C| 25 
  gcc/testsuite/g++.dg/ext/is_constructible5.C | 16 
  4 files changed, 106 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init24.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init25.C
  create mode 100644 gcc/testsuite/g++.dg/ext/is_constructible5.C

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 9a21bfc1f66..2fb0de288a2 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1799,12 +1799,48 @@ constructible_expr (tree to, tree from)
  {
if (from == NULL_TREE)
return build_value_init (strip_array_types (to), tf_none);
-  else if (TREE_CHAIN (from))
-   return error_mark_node; // too many initializers
-  from = build_stub_object (TREE_VALUE (from));
+  const int len = list_length (from);
+  if (len > 1)
+   {
+ if (cxx_dialect < cxx2a)
+   /* Too many initializers.  */
+   return error_mark_node;
+
+ /* In C++20 this is well-formed:
+  using T = int[2];
+  T t(1, 2);
+which means that std::is_constructible_v
+should be true.  */
+ vec *v;
+ vec_alloc (v, len);
+ for (tree t = from; t; t = TREE_CHAIN (t))
+   {
+ tree stub = build_stub_object (TREE_VALUE (t));
+ constructor_elt elt = { NULL_TREE, stub };
+ v->quick_push (elt);
+   }
+ from = build_constructor (init_list_type_node, v);
+ CONSTRUCTOR_IS_DIRECT_INIT (from) = true;
+ CONSTRUCTOR_IS_PAREN_INIT (from) = true;
+   }
+  else
+   from = build_stub_object (TREE_VALUE (from));
expr = perform_direct_initialization_if_possible (to, from,
/*cast*/false,
tf_none);
+  /* If t(e) didn't work, maybe t{e} will.  */
+  if (expr == NULL_TREE
+ && len == 1
+ && cxx_dialect >= cxx2a)
+   {
+ from = build_constructor_single (init_list_type_node, NULL_TREE,
+  from);
+ CONSTRUCTOR_IS_DIRECT_INIT (from) = true;
+ CONSTRUCTOR_IS_PAREN_INIT (from) = true;
+ expr = perform_direct_initialization_if_possible (to, from,
+   /*cast*/false,
+   tf_none);
+   }
  }
return expr;
  }
diff --git a/gcc/testsuite/g++.dg/cpp2a/paren-init24.C 
b/gcc/testsuite/g++.dg/cpp2a/paren-init24.C
new file mode 100644
index 000..a636a28ee6d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/paren-init24.C
@@ -0,0 +1,26 @@
+// PR c++/94149 - make __is_constructible work with paren-init of aggrs.
+// { dg-do compile { target c++2a } }
+
+#include 
+
+int main()
+{
+  using T = int[1];
+  T t(1);
+
+  static_assert(__is_constructible(T, int));
+  static_assert(!__is_constructible(T, int, int));
+  static_assert(std::is_constructible_v);
+  //FIXME: libstdc++ problem?
+  //static_assert(std::is_nothrow_constructible_v);
+
+  using T2 = int[2];
+  T2 t2(1);
+  T2 t3(1, 2);
+
+  static_assert(__is_constructible(T2, int));
+  static_assert(__is_constructible(T2, int, int));
+  static_assert(std::is_constructible_v);
+  // FIXME libstdc++ problem?
+  //static_assert(std::is_nothrow_constructible_v);
+}
diff --git a/gcc/testsuite/g++.dg/cpp2a/paren-init25.C 
b/gcc/testsuite/g++.dg/cpp2a/paren-init25.C
new file mode 100644
index 000..53855a9ef9e
--- /dev/nul

Re: [PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

[Jim Wilson]

On Fri, Apr 10, 2020 at 2:20 AM Kito Cheng  wrote:
>   - Implied rule are introduced into latest RISC-V ISA spec.
>   - Only implemented D implied F-extension. Zicsr and Zifence are not
> implement yet, so the rule not included in this patch.
>   - Pass preprocessed arch string to arch.
>   - Verified with binutils 2.30 and 2.34.

This is OK.

Do we really need this now?  It is a new feature not a bug fix, so it
might be better to wait until we reach stage1.  We have limited time
to test this before the gcc-10 release.

Jim

[PR C++ 94426] Lambda linkage

[Nathan Sidwell]

My fix for 94147 was confusing no-linkage with internal linkage, at the 
language level.  That's wrong. (the std is confusing here, because it 
describes linkage of names (which is wrong), and lambdas have no names)


Lambdas with extra-scope, have linkage.  However, at the 
implementation-level that linkage is at least as restricted as the 
linkage of the extra-scope decl.


Further, when instantiating a variable initialized by a lambda, we must 
determine the visibility of the variable itself, before instantiating 
its initializer.  If the template arguments are internal (or 
no-linkage), the variable will have internal linkage, regardless of the 
linkage of the template it is instantiated from.  We need to know that 
before instantiating the lambda, so we can restrict its linkage correctly.


I'll commit this in a few days.

nathan
--
Nathan Sidwell
2020-04-10  Nathan Sidwell  

	PR c++/94426 = lambdas with internal linkage are different to no-linkage
	* decl2.c (determine_visibility): A lambda's visibility is
	affected by its extra scope.
	* pt.c (instantiate_decl): Determine var's visibility before
	instantiating its initializer.
	* tree.c (no_linkage_check): Revert code looking at visibility of
	lambda's extra scope.
	gcc/cp/
	* g++.dg/cpp0x/lambda/pr94426-[12].C: New.
	* g++.dg/abi/lambda-vis.C: Drop a warning.
	* g++.dg/cpp0x/lambda/lambda-mangle.C: Lambda visibility on
	variable changes.
	* g++.dg/opt/dump1.C: Drop warnings of no import.

diff --git c/gcc/cp/decl2.c w/gcc/cp/decl2.c
index 6cf72b432e2..293df990435 100644
--- c/gcc/cp/decl2.c
+++ w/gcc/cp/decl2.c
@@ -2527,6 +2527,21 @@ determine_visibility (tree decl)
   else if (DECL_LANG_SPECIFIC (decl) && DECL_USE_TEMPLATE (decl))
 template_decl = decl;
 
+  if (TREE_CODE (decl) == TYPE_DECL
+  && LAMBDA_TYPE_P (TREE_TYPE (decl))
+  && CLASSTYPE_LAMBDA_EXPR (TREE_TYPE (decl)) != error_mark_node)
+if (tree extra = LAMBDA_TYPE_EXTRA_SCOPE (TREE_TYPE (decl)))
+  {
+	/* The lambda's visibility is limited by that of its extra
+	   scope.  */
+	int vis = 0;
+	if (TYPE_P (extra))
+	  vis = type_visibility (extra);
+	else
+	  vis = expr_visibility (extra);
+	constrain_visibility (decl, vis, false);
+  }
+
   /* If DECL is a member of a class, visibility specifiers on the
  class can influence the visibility of the DECL.  */
   tree class_type = NULL_TREE;
diff --git c/gcc/cp/pt.c w/gcc/cp/pt.c
index 050a57b2e2e..0a8ec3198d2 100644
--- c/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -25541,6 +25541,14 @@ instantiate_decl (tree d, bool defer_ok, bool expl_inst_class_mem_p)
   c_inhibit_evaluation_warnings = 0;
 }
 
+  if (VAR_P (d))
+{
+  /* The variable might be a lambda's extra scope, and that
+	 lambda's visibility depends on D's.  */
+  maybe_commonize_var (d);
+  determine_visibility (d);
+}
+
   /* Mark D as instantiated so that recursive calls to
  instantiate_decl do not try to instantiate it again.  */
   DECL_TEMPLATE_INSTANTIATED (d) = 1;
diff --git c/gcc/cp/tree.c w/gcc/cp/tree.c
index d1192b7e094..1d311b0fe61 100644
--- c/gcc/cp/tree.c
+++ w/gcc/cp/tree.c
@@ -2780,9 +2780,10 @@ verify_stmt_tree (tree t)
   cp_walk_tree (&t, verify_stmt_tree_r, &statements, NULL);
 }
 
-/* Check if the type T depends on a type with no linkage and if so, return
-   it.  If RELAXED_P then do not consider a class type declared within
-   a vague-linkage function to have no linkage.  */
+/* Check if the type T depends on a type with no linkage and if so,
+   return it.  If RELAXED_P then do not consider a class type declared
+   within a vague-linkage function to have no linkage.  Remember:
+   no-linkage is not the same as internal-linkage*/
 
 tree
 no_linkage_check (tree t, bool relaxed_p)
@@ -2801,17 +2802,6 @@ no_linkage_check (tree t, bool relaxed_p)
   tree extra = LAMBDA_TYPE_EXTRA_SCOPE (t);
   if (!extra)
 	return t;
-
-  /* If the mangling scope is internal-linkage or not repeatable
-	 elsewhere, the lambda effectively has no linkage.  (Sadly
-	 we're not very careful with the linkages of types.)  */
-  if (TREE_CODE (extra) == VAR_DECL
-	  && !(TREE_PUBLIC (extra)
-	   && (processing_template_decl
-		   || (DECL_LANG_SPECIFIC (extra) && DECL_USE_TEMPLATE (extra))
-		   /* DECL_COMDAT is set too late for us to check.  */
-		   || DECL_VAR_DECLARED_INLINE_P (extra
-	return t;
 }
 
   /* Otherwise there's no point in checking linkage on template functions; we
diff --git c/gcc/testsuite/g++.dg/abi/lambda-vis.C w/gcc/testsuite/g++.dg/abi/lambda-vis.C
index 89683b2076a..c1033f501a3 100644
--- c/gcc/testsuite/g++.dg/abi/lambda-vis.C
+++ w/gcc/testsuite/g++.dg/abi/lambda-vis.C
@@ -2,7 +2,7 @@
 // { dg-options "-fno-inline" }
 
 template int sfoo (T); // { dg-warning "used but never defined" }
-template int gfoo (T); // { dg-warning "used but never defined" }
+template int gfoo (T); // OK, but not completable
 template int ifoo (T); // OK
 template struct Wrapper {};
 template Wrapper cap

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

On Fri, 10 Apr 2020, Jason Merrill wrote:

> On 4/10/20 1:04 PM, Patrick Palka wrote:
> > On Thu, 9 Apr 2020, Patrick Palka wrote:
> > > On Thu, 9 Apr 2020, Jason Merrill wrote:
> > > 
> > > > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > > > When evaluating the initializer of 'a' in the following example
> > > > > 
> > > > > struct A { A *p = this; };
> > > > > constexpr A foo() { return {}; }
> > > > > constexpr A a = foo();
> > > > > 
> > > > > the PLACEHOLDER_EXPR for 'this' in the aggregate initializer returned
> > > > > by foo
> > > > > gets resolved to the RESULT_DECL of foo.  But due to guaranteed RVO,
> > > > > the
> > > > > 'this'
> > > > > should really be resolved to '&a'.
> > > > 
> > > > > It seems to me that the right approach would be to immediately resolve
> > > > > the
> > > > > PLACEHOLDER_EXPR to the correct target object during evaluation of
> > > > > 'foo()',
> > > > > so
> > > > > that we could use 'this' to access objects adjacent to the current
> > > > > object in
> > > > > the
> > > > > ultimate storage location.  (I think #c2 of PR c++/94537 is an example
> > > > > of
> > > > > such
> > > > > usage of 'this', which currently doesn't work.  But as #c1 shows we
> > > > > don't
> > > > > seem
> > > > > to handle this case correctly in non-constexpr initialization either.)
> > > > 
> > > > As I commented in the PR, the standard doesn't require this to work
> > > > because A
> > > > is trivially copyable, and our ABI makes it impossible.  But there's
> > > > still a
> > > > constexpr bug when we add
> > > > 
> > > > A() = default; A(const A&);
> > > > 
> > > > clang doesn't require the constructors to make this work for constant
> > > > initialization, but similarly can't make it work for non-constant
> > > > initialization.
> > > 
> > > That makes a lot of sense, thanks for the detailed explanation.
> > > 
> > > > 
> > > > > I haven't yet been able to make a solution using the above approach
> > > > > work --
> > > > > making sure we use the ultimate object instead of the RESULT_DECL
> > > > > whenever
> > > > > we
> > > > > access ctx->global->values is proving to be tricky and subtle.
> > > > 
> > > > Do we need to go through ctx->global->values?  Would it work for the
> > > > RESULT_DECL case in cxx_eval_constant_expression to go to straight to
> > > > ctx->object or ctx->ctor instead?
> > > 
> > > I attempted that at some point, but IIRC we still end up not resolving
> > > some RESULT_DECLs because not all of them get processed through
> > > cxx_eval_constant_expression before we manipulate ctx->global->values
> > > with them.  I'll try this approach more carefully and report back with
> > > more specifics.
> > 
> > It turns out that immediately resolving RESULT_DECLs/'this' to the
> > ultimate ctx->object would not interact well with constexpr_call
> > caching:
> > 
> >struct A { A() = default; A(const A&); A *ap = this; };
> >constexpr A foo() { return {}; }
> >constexpr A a = foo();
> >constexpr A b = foo();
> >static_assert(b.ap == &b); // fails
> > 
> > Evaluation of the first call to foo() returns {&a}, since we resolve
> > 'this' to &a due to guaranteed RVO, and we cache this result.
> > Evaluation of the second call to foo() just returns the cached result
> > from the constexpr_call cache, and so we get {&a} again.
> > 
> > So it seems we would have to mark the result of a constexpr call as not
> > cacheable whenever this RVO applies during its evaluation, even when
> > doing the RVO has no observable difference in the final result (i.e. the
> > constructor does not try to save the 'this' pointer).
> > 
> > Would the performance impact of disabling caching whenever RVO applies
> > during constexpr call evaluation be worth it, or should we go with
> > something like my first patch which "almost works," and which marks a
> > constexpr call as not cacheable only when we replace a RESULT_DECL in
> > the result of the call?
> 
> Could we search through the result of the call for ctx->object and cache if we
> don't find it?

Hmm, I think the result of the call could still depend on ctx->object
without ctx->object explicitly appearing in the result.  Consider the
following testcase:

  struct A {
A() = default; A(const A&);
constexpr A(const A *q) : d{this - p} { }
long d = 0;
  };

  constexpr A baz(const A *q) { return A(p); };
  constexpr A a = baz(&a);
  constexpr A b = baz(&a); // no error

The initialization of 'b' should be ill-formed, but the result of the
first call to baz(&a) would be {0}, so we would cache it and then reuse
the result when initializing 'b'.

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

On Fri, 10 Apr 2020, Patrick Palka wrote:

> On Fri, 10 Apr 2020, Jason Merrill wrote:
> 
> > On 4/10/20 1:04 PM, Patrick Palka wrote:
> > > On Thu, 9 Apr 2020, Patrick Palka wrote:
> > > > On Thu, 9 Apr 2020, Jason Merrill wrote:
> > > > 
> > > > > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > > > > When evaluating the initializer of 'a' in the following example
> > > > > > 
> > > > > > struct A { A *p = this; };
> > > > > > constexpr A foo() { return {}; }
> > > > > > constexpr A a = foo();
> > > > > > 
> > > > > > the PLACEHOLDER_EXPR for 'this' in the aggregate initializer 
> > > > > > returned
> > > > > > by foo
> > > > > > gets resolved to the RESULT_DECL of foo.  But due to guaranteed RVO,
> > > > > > the
> > > > > > 'this'
> > > > > > should really be resolved to '&a'.
> > > > > 
> > > > > > It seems to me that the right approach would be to immediately 
> > > > > > resolve
> > > > > > the
> > > > > > PLACEHOLDER_EXPR to the correct target object during evaluation of
> > > > > > 'foo()',
> > > > > > so
> > > > > > that we could use 'this' to access objects adjacent to the current
> > > > > > object in
> > > > > > the
> > > > > > ultimate storage location.  (I think #c2 of PR c++/94537 is an 
> > > > > > example
> > > > > > of
> > > > > > such
> > > > > > usage of 'this', which currently doesn't work.  But as #c1 shows we
> > > > > > don't
> > > > > > seem
> > > > > > to handle this case correctly in non-constexpr initialization 
> > > > > > either.)
> > > > > 
> > > > > As I commented in the PR, the standard doesn't require this to work
> > > > > because A
> > > > > is trivially copyable, and our ABI makes it impossible.  But there's
> > > > > still a
> > > > > constexpr bug when we add
> > > > > 
> > > > > A() = default; A(const A&);
> > > > > 
> > > > > clang doesn't require the constructors to make this work for constant
> > > > > initialization, but similarly can't make it work for non-constant
> > > > > initialization.
> > > > 
> > > > That makes a lot of sense, thanks for the detailed explanation.
> > > > 
> > > > > 
> > > > > > I haven't yet been able to make a solution using the above approach
> > > > > > work --
> > > > > > making sure we use the ultimate object instead of the RESULT_DECL
> > > > > > whenever
> > > > > > we
> > > > > > access ctx->global->values is proving to be tricky and subtle.
> > > > > 
> > > > > Do we need to go through ctx->global->values?  Would it work for the
> > > > > RESULT_DECL case in cxx_eval_constant_expression to go to straight to
> > > > > ctx->object or ctx->ctor instead?
> > > > 
> > > > I attempted that at some point, but IIRC we still end up not resolving
> > > > some RESULT_DECLs because not all of them get processed through
> > > > cxx_eval_constant_expression before we manipulate ctx->global->values
> > > > with them.  I'll try this approach more carefully and report back with
> > > > more specifics.
> > > 
> > > It turns out that immediately resolving RESULT_DECLs/'this' to the
> > > ultimate ctx->object would not interact well with constexpr_call
> > > caching:
> > > 
> > >struct A { A() = default; A(const A&); A *ap = this; };
> > >constexpr A foo() { return {}; }
> > >constexpr A a = foo();
> > >constexpr A b = foo();
> > >static_assert(b.ap == &b); // fails
> > > 
> > > Evaluation of the first call to foo() returns {&a}, since we resolve
> > > 'this' to &a due to guaranteed RVO, and we cache this result.
> > > Evaluation of the second call to foo() just returns the cached result
> > > from the constexpr_call cache, and so we get {&a} again.
> > > 
> > > So it seems we would have to mark the result of a constexpr call as not
> > > cacheable whenever this RVO applies during its evaluation, even when
> > > doing the RVO has no observable difference in the final result (i.e. the
> > > constructor does not try to save the 'this' pointer).
> > > 
> > > Would the performance impact of disabling caching whenever RVO applies
> > > during constexpr call evaluation be worth it, or should we go with
> > > something like my first patch which "almost works," and which marks a
> > > constexpr call as not cacheable only when we replace a RESULT_DECL in
> > > the result of the call?
> > 
> > Could we search through the result of the call for ctx->object and cache if 
> > we
> > don't find it?
> 
> Hmm, I think the result of the call could still depend on ctx->object
> without ctx->object explicitly appearing in the result.  Consider the
> following testcase:
> 
>   struct A {
> A() = default; A(const A&);
> constexpr A(const A *q) : d{this - p} { }

Oops sorry, that 'q' should be a 'p'.

> long d = 0;
>   };
> 
>   constexpr A baz(const A *q) { return A(p); };

And same here.

>   constexpr A a = baz(&a);
>   constexpr A b = baz(&a); // no error
> 
> The initialization of 'b' should be ill-formed, but the result of the
> first call to baz(&a) would be {0}, so we would cache it and then reuse
> the result when initial

Re: Merge from master to gccgo branch

[Ian Lance Taylor via Gcc-patches]

On Tue, Apr 7, 2020 at 12:30 PM Ian Lance Taylor  wrote:
>
> On Mon, Apr 6, 2020 at 5:51 PM Ian Lance Taylor  wrote:
> >
> > I merged master revision 52fa80f853c0b0f623ea9e4c7198e324ce44ff30 to
> > the gccgo branch.
>
> Another merge from master to gccgo branch, of revision
> 50c7853216e8511971c55b51d7fe29173db4749b.

This time merged master revision
e26bd694c790b7c8f68c6736b2683c60a8fcbcfe to gccgo branch.

Ian

Re: [committed] PR target/94530 (was [PATCH] PR target/48240)

[Christophe Lyon via Gcc-patches]

Hi,

On Thu, 9 Apr 2020 at 10:57, Andrea Corallo  wrote:
>
> Hi all,
>
> Second version of the patch for PR94530 (pr num fixed) addressing
> comments.
>
> Bootstrapped on aarch64-unknown-linux-gnu.
>
> Committed.
>

The new test causes an ICE:

FAIL: gcc.target/aarch64/pr94530.c (internal compiler error)
FAIL: gcc.target/aarch64/pr94530.c (test for excess errors)
Excess errors:
during RTL pass: tag_collision_avoidance
/gcc/testsuite/gcc.target/aarch64/pr94530.c:9:1: internal compiler
error: Segmentation fault
0xd58bcf crash_signal
/gcc/toplev.c:328
0x11d47f3 valid_src_p
/gcc/config/aarch64/falkor-tag-collision-avoidance.c:541
0x11d47f3 get_load_info
/gcc/config/aarch64/falkor-tag-collision-avoidance.c:644
0x11d58c7 record_loads
/gcc/config/aarch64/falkor-tag-collision-avoidance.c:774
0x11d58c7 execute_tag_collision_avoidance()
/gcc/config/aarch64/falkor-tag-collision-avoidance.c:827
0x11d6588 pass_tag_collision_avoidance::execute(function*)
/gcc/config/aarch64/falkor-tag-collision-avoidance.c:874

Can you check?

Thanks,

Christophe

> Andrea
>
> gcc/ChangeLog
>
> 2020-04-09  Andrea Corallo  
>
> PR target/pr94530
> * config/aarch64/falkor-tag-collision-avoidance.c
> (valid_src_p): Fix missing rtx type check.
>
> gcc/testsuite/ChangeLog
>
> 2020-04-09  Andrea Corallo  
>
> * gcc.target/aarch64/pr94530.c: New test.
>

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Jason Merrill via Gcc-patches]

On 4/10/20 2:15 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Patrick Palka wrote:


On Fri, 10 Apr 2020, Jason Merrill wrote:


On 4/10/20 1:04 PM, Patrick Palka wrote:

On Thu, 9 Apr 2020, Patrick Palka wrote:

On Thu, 9 Apr 2020, Jason Merrill wrote:


On 4/8/20 7:49 PM, Patrick Palka wrote:

When evaluating the initializer of 'a' in the following example

 struct A { A *p = this; };
 constexpr A foo() { return {}; }
 constexpr A a = foo();

the PLACEHOLDER_EXPR for 'this' in the aggregate initializer returned
by foo
gets resolved to the RESULT_DECL of foo.  But due to guaranteed RVO,
the
'this'
should really be resolved to '&a'.



It seems to me that the right approach would be to immediately resolve
the
PLACEHOLDER_EXPR to the correct target object during evaluation of
'foo()',
so
that we could use 'this' to access objects adjacent to the current
object in
the
ultimate storage location.  (I think #c2 of PR c++/94537 is an example
of
such
usage of 'this', which currently doesn't work.  But as #c1 shows we
don't
seem
to handle this case correctly in non-constexpr initialization either.)


As I commented in the PR, the standard doesn't require this to work
because A
is trivially copyable, and our ABI makes it impossible.  But there's
still a
constexpr bug when we add

A() = default; A(const A&);

clang doesn't require the constructors to make this work for constant
initialization, but similarly can't make it work for non-constant
initialization.


That makes a lot of sense, thanks for the detailed explanation.




I haven't yet been able to make a solution using the above approach
work --
making sure we use the ultimate object instead of the RESULT_DECL
whenever
we
access ctx->global->values is proving to be tricky and subtle.


Do we need to go through ctx->global->values?  Would it work for the
RESULT_DECL case in cxx_eval_constant_expression to go to straight to
ctx->object or ctx->ctor instead?


I attempted that at some point, but IIRC we still end up not resolving
some RESULT_DECLs because not all of them get processed through
cxx_eval_constant_expression before we manipulate ctx->global->values
with them.  I'll try this approach more carefully and report back with
more specifics.


It turns out that immediately resolving RESULT_DECLs/'this' to the
ultimate ctx->object would not interact well with constexpr_call
caching:

struct A { A() = default; A(const A&); A *ap = this; };
constexpr A foo() { return {}; }
constexpr A a = foo();
constexpr A b = foo();
static_assert(b.ap == &b); // fails

Evaluation of the first call to foo() returns {&a}, since we resolve
'this' to &a due to guaranteed RVO, and we cache this result.
Evaluation of the second call to foo() just returns the cached result
from the constexpr_call cache, and so we get {&a} again.

So it seems we would have to mark the result of a constexpr call as not
cacheable whenever this RVO applies during its evaluation, even when
doing the RVO has no observable difference in the final result (i.e. the
constructor does not try to save the 'this' pointer).

Would the performance impact of disabling caching whenever RVO applies
during constexpr call evaluation be worth it, or should we go with
something like my first patch which "almost works," and which marks a
constexpr call as not cacheable only when we replace a RESULT_DECL in
the result of the call?


Could we search through the result of the call for ctx->object and cache if we
don't find it?


Hmm, I think the result of the call could still depend on ctx->object
without ctx->object explicitly appearing in the result.  Consider the
following testcase:

   struct A {
 A() = default; A(const A&);
 constexpr A(const A *q) : d{this - p} { }


Oops sorry, that 'q' should be a 'p'.


 long d = 0;
   };

   constexpr A baz(const A *q) { return A(p); };


And same here.


   constexpr A a = baz(&a);
   constexpr A b = baz(&a); // no error

The initialization of 'b' should be ill-formed, but the result of the
first call to baz(&a) would be {0}, so we would cache it and then reuse
the result when initializing 'b'.


Ah, true.  Can we still cache if we're initializing something that isn't 
TREE_STATIC?


Jason

[RFC][PR target PR90000] (rs6000) Compile time hog w/impossible asm constraint lra loop

[will schmidt via Gcc-patches]

[RFC][PR target/9] Compile time hog w/impossible asm constraint lra loop

Hi,
  RFC for a bandaid/patch to partially address target PR/9.

This adds an escape condition from the forever loop where 
LRA gets stuck while attempting to handle constraints from an 
instruction that has previously suffered an impossible constraint error.

This is somewhat inspired by MAX_RELOAD_INSNS_NUMBER as
seen in lra-constraints.c lra_constraints().   This utilizes the
existing counter variable lra_constraint_iter.

More needs to be done here, as this does replace a spin-forever
situation with an ICE.

Thanks
-Will


gcc/
2020-04-10  Will Schmidt  

* lra.c: Add include of rtl-error.h.
(MAX_LRA_CONSTRAINT_PASSES): New define.
(lra): Add check of lra_constraint_iter value.



diff --git a/gcc/lra.c b/gcc/lra.c
index 5e8b75b..36f5dd9 100644
--- a/gcc/lra.c
+++ b/gcc/lra.c
@@ -116,15 +116,22 @@ along with GCC; see the file COPYING3.If not see
 #include "ira.h"
 #include "recog.h"
 #include "expr.h"
 #include "cfgrtl.h"
 #include "cfgbuild.h"
+#include "rtl-error.h"
 #include "lra.h"
 #include "lra-int.h"
 #include "print-rtl.h"
 #include "function-abi.h"
 
+/*  Bail-out from lra-constraint processing.
+  This band-aid prevents an infinite loop after we have previously
+  experienced an invalid constraint error, and our lra processing
+  has gotten stuck repeatedly inserting instructions.  (PR/90060) */
+#define  MAX_LRA_CONSTRAINT_PASSES 100
+
 /* Dump bitmap SET with TITLE and BB INDEX.  */
 void
 lra_dump_bitmap_with_title (const char *title, bitmap set, int index)
 {
   unsigned int i;
@@ -2520,10 +2527,17 @@ lra (FILE *f)
  if (! live_p) {
/* We need the correct reg notes for work of constraint sub-pass.  
*/
lra_create_live_ranges (true, true);
live_p = true;
  }
+ if (lra_constraint_iter > MAX_LRA_CONSTRAINT_PASSES)
+   {
+ internal_error
+   ("maximum number of lra constraint passes achieved (%d)",
+MAX_LRA_CONSTRAINT_PASSES);
+  break;
+ }
}
   /* Don't clear optional reloads bitmap until all constraints are
 satisfied as we need to differ them from regular reloads.  */
   bitmap_clear (&lra_optional_reload_pseudos);
   bitmap_clear (&lra_subreg_reload_pseudos);

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

On Fri, 10 Apr 2020, Jason Merrill wrote:
> On 4/10/20 2:15 PM, Patrick Palka wrote:
> > On Fri, 10 Apr 2020, Patrick Palka wrote:
> > 
> > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > 
> > > > On 4/10/20 1:04 PM, Patrick Palka wrote:
> > > > > On Thu, 9 Apr 2020, Patrick Palka wrote:
> > > > > > On Thu, 9 Apr 2020, Jason Merrill wrote:
> > > > > > 
> > > > > > > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > > > > > > When evaluating the initializer of 'a' in the following example
> > > > > > > > 
> > > > > > > >  struct A { A *p = this; };
> > > > > > > >  constexpr A foo() { return {}; }
> > > > > > > >  constexpr A a = foo();
> > > > > > > > 
> > > > > > > > the PLACEHOLDER_EXPR for 'this' in the aggregate initializer
> > > > > > > > returned
> > > > > > > > by foo
> > > > > > > > gets resolved to the RESULT_DECL of foo.  But due to guaranteed
> > > > > > > > RVO,
> > > > > > > > the
> > > > > > > > 'this'
> > > > > > > > should really be resolved to '&a'.
> > > > > > > 
> > > > > > > > It seems to me that the right approach would be to immediately
> > > > > > > > resolve
> > > > > > > > the
> > > > > > > > PLACEHOLDER_EXPR to the correct target object during evaluation
> > > > > > > > of
> > > > > > > > 'foo()',
> > > > > > > > so
> > > > > > > > that we could use 'this' to access objects adjacent to the
> > > > > > > > current
> > > > > > > > object in
> > > > > > > > the
> > > > > > > > ultimate storage location.  (I think #c2 of PR c++/94537 is an
> > > > > > > > example
> > > > > > > > of
> > > > > > > > such
> > > > > > > > usage of 'this', which currently doesn't work.  But as #c1 shows
> > > > > > > > we
> > > > > > > > don't
> > > > > > > > seem
> > > > > > > > to handle this case correctly in non-constexpr initialization
> > > > > > > > either.)
> > > > > > > 
> > > > > > > As I commented in the PR, the standard doesn't require this to
> > > > > > > work
> > > > > > > because A
> > > > > > > is trivially copyable, and our ABI makes it impossible.  But
> > > > > > > there's
> > > > > > > still a
> > > > > > > constexpr bug when we add
> > > > > > > 
> > > > > > > A() = default; A(const A&);
> > > > > > > 
> > > > > > > clang doesn't require the constructors to make this work for
> > > > > > > constant
> > > > > > > initialization, but similarly can't make it work for non-constant
> > > > > > > initialization.
> > > > > > 
> > > > > > That makes a lot of sense, thanks for the detailed explanation.
> > > > > > 
> > > > > > > 
> > > > > > > > I haven't yet been able to make a solution using the above
> > > > > > > > approach
> > > > > > > > work --
> > > > > > > > making sure we use the ultimate object instead of the
> > > > > > > > RESULT_DECL
> > > > > > > > whenever
> > > > > > > > we
> > > > > > > > access ctx->global->values is proving to be tricky and subtle.
> > > > > > > 
> > > > > > > Do we need to go through ctx->global->values?  Would it work for
> > > > > > > the
> > > > > > > RESULT_DECL case in cxx_eval_constant_expression to go to straight
> > > > > > > to
> > > > > > > ctx->object or ctx->ctor instead?
> > > > > > 
> > > > > > I attempted that at some point, but IIRC we still end up not
> > > > > > resolving
> > > > > > some RESULT_DECLs because not all of them get processed through
> > > > > > cxx_eval_constant_expression before we manipulate
> > > > > > ctx->global->values
> > > > > > with them.  I'll try this approach more carefully and report back
> > > > > > with
> > > > > > more specifics.
> > > > > 
> > > > > It turns out that immediately resolving RESULT_DECLs/'this' to the
> > > > > ultimate ctx->object would not interact well with constexpr_call
> > > > > caching:
> > > > > 
> > > > > struct A { A() = default; A(const A&); A *ap = this; };
> > > > > constexpr A foo() { return {}; }
> > > > > constexpr A a = foo();
> > > > > constexpr A b = foo();
> > > > > static_assert(b.ap == &b); // fails
> > > > > 
> > > > > Evaluation of the first call to foo() returns {&a}, since we resolve
> > > > > 'this' to &a due to guaranteed RVO, and we cache this result.
> > > > > Evaluation of the second call to foo() just returns the cached result
> > > > > from the constexpr_call cache, and so we get {&a} again.
> > > > > 
> > > > > So it seems we would have to mark the result of a constexpr call as
> > > > > not
> > > > > cacheable whenever this RVO applies during its evaluation, even when
> > > > > doing the RVO has no observable difference in the final result (i.e.
> > > > > the
> > > > > constructor does not try to save the 'this' pointer).
> > > > > 
> > > > > Would the performance impact of disabling caching whenever RVO applies
> > > > > during constexpr call evaluation be worth it, or should we go with
> > > > > something like my first patch which "almost works," and which marks a
> > > > > constexpr call as not cacheable only when we replace a RESULT_DECL in
> > > > > the result of the call?
> > > > 
> > > > Could we search through the result o

[PATCH][PR target/94542]Don't allow PC-relative addressing for TLS data

[acsawdey via Gcc-patches]

One of the things that address_to_insn_form() is used for is determining 
whether a PC-relative addressing instruction could be used. In 
particular predicate pcrel_external_address and function 
prefixed_paddi_p() both use it for this purpose. So what emerged in 
PR/94542 is that it should be looking to see if the associated 
symbol_ref is a TLS symbol of some kind. TLS symbols cannot be addressed 
with PC-relative. This patch fixes both places in address_to_insn_form() 
where it is looking at a symbol_ref.


Regression tests passed with trunk 
38e62001c576b8c6ba2e08eb4673d69ec4c5b0f9 on ppc64le power9, and 
PC-relative code is now correct. OK for trunk?


Thanks!
   Aaron

2020-04-10  Aaron Sawdey  

PR target/94542
* config/rs6000/rs6000.c (address_to_insn_form): Do not attempt to
use PC-relative addressing for TLS references.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 2b6613bcb7e..c77e60a718f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -24824,15 +24824,21 @@ address_to_insn_form (rtx addr,
   if (GET_RTX_CLASS (GET_CODE (addr)) == RTX_AUTOINC)
 return INSN_FORM_UPDATE;
 
-  /* Handle PC-relative symbols and labels.  Check for both local and external
- symbols.  Assume labels are always local.  */
+  /* Handle PC-relative symbols and labels.  Check for both local and
+ external symbols.  Assume labels are always local. TLS symbols
+ are not PC-relative.  */
   if (TARGET_PCREL)
 {
-  if (SYMBOL_REF_P (addr) && !SYMBOL_REF_LOCAL_P (addr))
-	return INSN_FORM_PCREL_EXTERNAL;
-
-  if (SYMBOL_REF_P (addr) || LABEL_REF_P (addr))
+  if (LABEL_REF_P (addr))
 	return INSN_FORM_PCREL_LOCAL;
+
+  if (SYMBOL_REF_P (addr) && !SYMBOL_REF_TLS_MODEL (addr))
+	{
+	  if (!SYMBOL_REF_LOCAL_P (addr))
+	return INSN_FORM_PCREL_EXTERNAL;
+	  else
+	return INSN_FORM_PCREL_LOCAL;
+	}
 }
 
   if (GET_CODE (addr) == CONST)
@@ -24866,14 +24872,19 @@ address_to_insn_form (rtx addr,
 return INSN_FORM_BAD;
 
   /* Check for local and external PC-relative addresses.  Labels are always
- local.  */
+ local.  TLS symbols are not PC-relative.  */
   if (TARGET_PCREL)
 {
-  if (SYMBOL_REF_P (op0) && !SYMBOL_REF_LOCAL_P (op0))
-	return INSN_FORM_PCREL_EXTERNAL;
-
-  if (SYMBOL_REF_P (op0) || LABEL_REF_P (op0))
+  if (LABEL_REF_P (op0))
 	return INSN_FORM_PCREL_LOCAL;
+
+  if (SYMBOL_REF_P (op0) && !SYMBOL_REF_TLS_MODEL (op0))
+	{
+	  if (!SYMBOL_REF_LOCAL_P (op0))
+	return INSN_FORM_PCREL_EXTERNAL;
+	  else
+	return INSN_FORM_PCREL_LOCAL;
+	}
 }
 
   /* If it isn't PC-relative, the address must use a base register.  */

[committed] coroutines: Revise await expansions [PR94528]

[Iain Sandoe]

The expansions for await expressions were specific to particular
cases, this revises it to be more generic and thus handles the case
that triggered the PR.  Most of the change is code-factoring.

Tested on x86_64-linux/darwin (and powerpc64-linux-gnu)
approved by Nathan on the PR thread (I fixed the comments that
refered to a following patch),

applied to master
thanks
Iain

a: Revise co_await statement walkers.

We want to process the co_awaits one statement at a time.
We also want to be able to determine the insertion points for
new bind scopes needed to cater for temporaries that are
captured by reference and have lifetimes that need extension
to the end of the full expression.  Likewise, the handling of
captured references in the evaluation of conditions might
result in the need to make a frame copy.

This reorganises the statement walking code to make it easier to
extend for these purposes.

b: Factor reference-captured temp code.

We want to be able to use the code that writes a new bind expr
with vars (and their initializers) from several places, so split
that out of the maybe_promote_captured_temps() function into a
new replace_statement_captures ().  Update some comments.

c: Generalize await statement expansion.

This revises the expansion to avoid the need to expand conditionally
on the tree type.  It resolves PR 94528.

gcc/cp/ChangeLog:

2020-04-10  Iain Sandoe  

PR c++/94528
* coroutines.cc (co_await_expander): Remove.
(expand_one_await_expression): New.
(process_one_statement): New.
(await_statement_expander): New.
(build_actor_fn): Revise to use per-statement expander.
(struct susp_frame_data): Reorder and comment.
(register_awaits): Factor code.
(replace_statement_captures): New, factored from...
(maybe_promote_captured_temps):.. here.
(await_statement_walker): Revise to process per statement.
(morph_fn_to_coro): Use revised susp_frame_data layout.

gcc/testsuite/ChangeLog:

2020-04-10  Iain Sandoe  

PR c++/94528
* g++.dg/coroutines/pr94528.C: New test.

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index ab06c0aef54..57172853639 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1359,6 +1359,13 @@ struct coro_aw_data
   unsigned index;  /* This is our current resume index.  */
 };
 
+/* Lighweight search for the first await expression in tree-walk order.
+   returns:
+ The first await expression found in STMT.
+ NULL_TREE if there are none.
+   So can be used to determine if the statement needs to be processed for
+   awaits.  */
+
 static tree
 co_await_find_in_subtree (tree *stmt, int *do_subtree ATTRIBUTE_UNUSED, void 
*d)
 {
@@ -1371,57 +1378,33 @@ co_await_find_in_subtree (tree *stmt, int *do_subtree 
ATTRIBUTE_UNUSED, void *d)
   return NULL_TREE;
 }
 
-/* When we come here:
-the first operand is the [currently unused] handle for suspend.
-the second operand is the var to be copy-initialized
-the third operand is 'o' (the initializer for the second)
- as defined in [await.expr] (3.3)
-the fourth operand is the mode as per the comment on build_co_await ().
+/* Starting with a statment:
 
-   When we leave:
-   the IFN_CO_YIELD carries the labels of the resume and destroy
-   branch targets for this await.  */
+   stmt => some tree containing one or more await expressions.
 
-static tree
-co_await_expander (tree *stmt, int * /*do_subtree*/, void *d)
-{
-  if (STATEMENT_CLASS_P (*stmt) || !EXPR_P (*stmt))
-return NULL_TREE;
+   We replace the statement with:
+{
+  initialise awaitable
+  if (!ready)
+   {
+ suspension context.
+   }
+  resume:
+   revised statement with one await expression rewritten to its
+   await_resume() return value.
+   }
+
+   We then recurse into the initializer and the revised statement
+   repeating this replacement until there are no more await expressions
+   in either.  */
 
+static tree *
+expand_one_await_expression (tree *stmt, tree *await_expr, void *d)
+{
   coro_aw_data *data = (coro_aw_data *) d;
-  enum tree_code stmt_code = TREE_CODE (*stmt);
-  tree stripped_stmt = *stmt;
-  tree *buried_stmt = NULL;
-  tree saved_co_await = NULL_TREE;
-  enum tree_code sub_code = NOP_EXPR;
-
-  if (stmt_code == MODIFY_EXPR || stmt_code == INIT_EXPR)
-{
-  sub_code = TREE_CODE (TREE_OPERAND (stripped_stmt, 1));
-  if (sub_code == CO_AWAIT_EXPR)
-   saved_co_await = TREE_OPERAND (stripped_stmt, 1); /* Get the RHS.  */
-  else if (tree r
-  = cp_walk_tree (&TREE_OPERAND (stripped_stmt, 1),
-  co_await_find_in_subtree, &buried_stmt, NULL))
-   saved_co_await = r;
-}
-  else if (stmt_code == CALL_EXPR)
-{
-  if (tree r = cp_walk_tree (&stripped_stmt, co_await_find_in_subtree,
-&buried_stmt, NULL))
-   saved_co_await = r;
- 

Re: [PATCH] On PPC32 GCC9 or later can throw an ICE when built with older GCCs

[Hans-Peter Nilsson]

On Mon, 6 Apr 2020, Gustavo Romero via Gcc-patches wrote:
> When GCC9 is built with older GCC (4.7) on FreeBSD 32-bit on PowerPC an ICE
> is generated on stage 1 when selftests are performed.
>
> After an investigation the root cause was traced to an unnecessary and
> harmful instantiation of a new dump_context singleton class in order to
> simply get the current activated instance.
>
> I was only able to reproduce it on FreeBSD 32-bit but it can affect other
> 32-bit OSs in my understanding, and even 64-bit on certain cases I believe,
> although I was not able to reproduce it on 64-bit FreeBSD or Linux.
>
> On FreeBSD 12 32-bit the bug reproduces 100% when GCC9 is built with base
> GCC 4.7. For additional details, please see:
>
> * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242506 and
> * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243666
>
> Gustavo Romero (1):
>   Fix use of singleton in optinfo framework
>
>  gcc/dumpfile.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This sounds like GCC PR87252.

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

brgds, H-P

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Jason Merrill via Gcc-patches]

On 4/10/20 5:47 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Jason Merrill wrote:

On 4/10/20 2:15 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Patrick Palka wrote:


On Fri, 10 Apr 2020, Jason Merrill wrote:


On 4/10/20 1:04 PM, Patrick Palka wrote:

On Thu, 9 Apr 2020, Patrick Palka wrote:

On Thu, 9 Apr 2020, Jason Merrill wrote:


On 4/8/20 7:49 PM, Patrick Palka wrote:

When evaluating the initializer of 'a' in the following example

  struct A { A *p = this; };
  constexpr A foo() { return {}; }
  constexpr A a = foo();

the PLACEHOLDER_EXPR for 'this' in the aggregate initializer
returned
by foo
gets resolved to the RESULT_DECL of foo.  But due to guaranteed
RVO,
the
'this'
should really be resolved to '&a'.



It seems to me that the right approach would be to immediately
resolve
the
PLACEHOLDER_EXPR to the correct target object during evaluation
of
'foo()',
so
that we could use 'this' to access objects adjacent to the
current
object in
the
ultimate storage location.  (I think #c2 of PR c++/94537 is an
example
of
such
usage of 'this', which currently doesn't work.  But as #c1 shows
we
don't
seem
to handle this case correctly in non-constexpr initialization
either.)


As I commented in the PR, the standard doesn't require this to
work
because A
is trivially copyable, and our ABI makes it impossible.  But
there's
still a
constexpr bug when we add

A() = default; A(const A&);

clang doesn't require the constructors to make this work for
constant
initialization, but similarly can't make it work for non-constant
initialization.


That makes a lot of sense, thanks for the detailed explanation.




I haven't yet been able to make a solution using the above
approach
work --
making sure we use the ultimate object instead of the
RESULT_DECL
whenever
we
access ctx->global->values is proving to be tricky and subtle.


Do we need to go through ctx->global->values?  Would it work for
the
RESULT_DECL case in cxx_eval_constant_expression to go to straight
to
ctx->object or ctx->ctor instead?


I attempted that at some point, but IIRC we still end up not
resolving
some RESULT_DECLs because not all of them get processed through
cxx_eval_constant_expression before we manipulate
ctx->global->values
with them.  I'll try this approach more carefully and report back
with
more specifics.


It turns out that immediately resolving RESULT_DECLs/'this' to the
ultimate ctx->object would not interact well with constexpr_call
caching:

 struct A { A() = default; A(const A&); A *ap = this; };
 constexpr A foo() { return {}; }
 constexpr A a = foo();
 constexpr A b = foo();
 static_assert(b.ap == &b); // fails

Evaluation of the first call to foo() returns {&a}, since we resolve
'this' to &a due to guaranteed RVO, and we cache this result.
Evaluation of the second call to foo() just returns the cached result
from the constexpr_call cache, and so we get {&a} again.

So it seems we would have to mark the result of a constexpr call as
not
cacheable whenever this RVO applies during its evaluation, even when
doing the RVO has no observable difference in the final result (i.e.
the
constructor does not try to save the 'this' pointer).

Would the performance impact of disabling caching whenever RVO applies
during constexpr call evaluation be worth it, or should we go with
something like my first patch which "almost works," and which marks a
constexpr call as not cacheable only when we replace a RESULT_DECL in
the result of the call?


Could we search through the result of the call for ctx->object and cache
if we
don't find it?


Hmm, I think the result of the call could still depend on ctx->object
without ctx->object explicitly appearing in the result.  Consider the
following testcase:

struct A {
  A() = default; A(const A&);
  constexpr A(const A *q) : d{this - p} { }


Oops sorry, that 'q' should be a 'p'.


  long d = 0;
};

constexpr A baz(const A *q) { return A(p); };


And same here.


constexpr A a = baz(&a);
constexpr A b = baz(&a); // no error

The initialization of 'b' should be ill-formed, but the result of the
first call to baz(&a) would be {0}, so we would cache it and then reuse
the result when initializing 'b'.


Ah, true.  Can we still cache if we're initializing something that isn't
TREE_STATIC?


Hmm, we correctly compile the analogous non-TREE_STATIC testcase

 struct A {
   A() = default; A(const A&);
   constexpr A(const A *p) : d{this == p} { }
   bool d;
 };

 constexpr A baz(const A *p) { return A(p); }

 void foo() {
   constexpr A x = baz(&x);
   constexpr A y = baz(&x);
   static_assert(!y.d);
 }

because the calls 'baz(&x)' are considered to have non-constant arguments.


Unfortunately, we can come up with another trick to fool the constexpr_call
cache in the presence of RVO even in the !TREE_STATIC case:

 struct B {
   B() = default; B(const B&);
   constexpr B(int) : q{!this[-1].q} {

Re: [PATCH] cselib, var-tracking: Improve debug info after the cselib sp tracking changes [PR94495]

[Jakub Jelinek via Gcc-patches]

On Fri, Apr 10, 2020 at 11:54:49AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Apr 09, 2020 at 10:57:46PM +0200, Christophe Lyon via Gcc-patches 
> wrote:
> > This patch makes GCC fail to build newlib when configured for
> > aarch64_be-none-elf:
> > 0x10c488c vt_expand_var_loc_chain
> > 
> > /tmp/9192639_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/var-tracking.c:8355
> 
> Seems it is the cselib_record_sp_cfa_base_equiv part of the patch (reverting
> the add_stores change doesn't make the ICE go away).
> The following fixes it, but don't have cycles to properly test it right now:

Now committed to trunk in order to unbreak
powerpc64le-linux/aarch64_be-linux bootstrap and various other targets
after bootstrapping/regtesting it on {x86_64,powerpc64{,le}}-linux.
Sorry for the breakage.

> 2020-04-10  Jakub Jelinek  
> 
>   PR debug/94495
>   * cselib.c (cselib_record_sp_cfa_base_equiv): Set PRESERVED_VALUE_P on
>   val->val_rtx.
> 
> --- gcc/cselib.c.jj   2020-04-09 21:20:59.457529812 +0200
> +++ gcc/cselib.c  2020-04-10 11:49:45.820124893 +0200
> @@ -2695,7 +2695,10 @@ cselib_record_sp_cfa_base_equiv (HOST_WI
>  = cselib_lookup_from_insn (plus_constant (Pmode, sp_derived_value, 
> offset),
>  Pmode, 1, VOIDmode, insn);
>if (val != NULL)
> -cselib_record_set (stack_pointer_rtx, val, NULL);
> +{
> +  PRESERVED_VALUE_P (val->val_rtx) = 1;
> +  cselib_record_set (stack_pointer_rtx, val, NULL);
> +}
>  }
>  
>  /* Return true if V is SP_DERIVED_VALUE_P (or SP_DERIVED_VALUE_P + CONST_INT)
> 
>   Jakub

Jakub

[committed] testsuite: Fix up pr94482.c testcase [PR94482]

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 08, 2020 at 08:34:08PM +0200, Martin Jambor wrote:
> 2020-04-08  Martin Jambor  
>   Richard Biener  
> 
>   PR tree-optimization/94482
>   * tree-sra.c (create_access_replacement): Dump new replacement with
>   TDF_UID.
>   (sra_modify_expr): Fix handling of cases when the original EXPR writes
>   to only part of the replacement.
>   * tree-ssa-forwprop.c (pass_forwprop::execute): Properly verify
>   the first operand of combinations into REAL/IMAGPART_EXPR and
>   BIT_FIELD_REF.
> 
>   testsuite/
>   * gcc.dg/torture/pr94482.c: New test.

The test FAILs on powerpc64-linux with -m32 due to psabi warnings.
Furthermore, the test needs really -msse2 to reproduce on x86 -m32 at -O2.

Fixed thusly, tested on x86_64-linux and powerpc64-linux -m32/-m64 and on
the former -m32/-mno-sse too, committed to trunk as obvious.

2020-04-11  Jakub Jelinek  

PR tree-optimization/94482
* gcc.dg/torture/pr94482.c: Add -Wno-psabi -w.  Don't add -msse
and sse_runtime effective target on x86, instead only add -msse2
if target is sse2_runtime.

--- gcc/testsuite/gcc.dg/torture/pr94482.c
+++ gcc/testsuite/gcc.dg/torture/pr94482.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
-/* { dg-options "-msse" { target { i?86-*-* x86_64-*-* } } } */
-/* { dg-require-effective-target sse_runtime { target { i?86-*-* x86_64-*-* } 
} } */
+/* { dg-additional-options "-Wno-psabi -w" } */
+/* { dg-additional-options "-msse2" { target sse2_runtime } } */
 
 typedef unsigned V __attribute__ ((__vector_size__ (16)));
 union U


Jakub