Re: [PATCH] c++: Fix ABI issue with alignas on armv7hl [PR94050]

[Jason Merrill]

On 3/6/20 8:12 PM, Marek Polacek wrote:

On Fri, Mar 06, 2020 at 05:49:07PM -0500, Jason Merrill wrote:

On 3/5/20 2:40 PM, Marek Polacek wrote:

The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell.  BaseShape's data
takes up 20B on 32-bit architectures, but we failed to round up its
TYPE_SIZE.  This happens since the

patch: here, in layout_class_type for TenuredCell, we see that the size
of TenuredCell and its CLASSTYPE_AS_BASE match, so we set

CLASSTYPE_AS_BASE (t) = t;

But while TYPE_USER_ALIGN of TenuredCell was 0, TYPE_USER_ALIGN of its
CLASSTYPE_AS_BASE was 1.


Surely the bug is that TYPE_USER_ALIGN isn't set for TenuredCell?


That's my understanding.


So why is that?  Where is setting TYPE_USER_ALIGN on as-base 
TenuredCell, and why isn't it setting it on the main type as well?  Or 
is it getting cleared on the main type for some reason?



I think it's clear that we're losing the alignas
specifier and so the TYPE_SIZE of BaseShape is wrong.  Before the patch from
June patch we'd set it...


   After we replace it, it's no longer 1.  Then

we perform layout_empty_base_or_field for TenuredCell and since
TYPE_USER_ALIGN of its CLASSTYPE_AS_BASE is now 0, we don't do this
adjustment:

if (CLASSTYPE_USER_ALIGN (type))
  {
rli->record_align = MAX (rli->record_align, CLASSTYPE_ALIGN (type));
if (warn_packed)
  rli->unpacked_align = MAX (rli->unpacked_align, CLASSTYPE_ALIGN 
(type));
TYPE_USER_ALIGN (rli->t) = 1;
  }


I would expect it to be set here on TenuredCell prime, and then copied 
to the as-base type with



  TYPE_USER_ALIGN (base_t) = TYPE_USER_ALIGN (t);



...here, but we no longer do.  Is there any other direction I could pursue?
Well, perhaps...


--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -6705,6 +6705,10 @@ layout_class_type (tree t, tree *virtuals_p)
 /* If we didn't end up needing an as-base type, don't use it.  */
 if (CLASSTYPE_AS_BASE (t) != t
+  /* If T's CLASSTYPE_AS_BASE is TYPE_USER_ALIGN, but T is not,
+replacing the as-base type would change CLASSTYPE_USER_ALIGN,
+causing us to lose the user-specified alignment as in PR94050.  */
+  && !CLASSTYPE_USER_ALIGN (t)
 && tree_int_cst_equal (TYPE_SIZE (t),
 TYPE_SIZE (CLASSTYPE_AS_BASE (t
   CLASSTYPE_AS_BASE (t) = t;


...we could copy the TYPE_USER_ALIGN flag to t if its old CLASSTYPE_AS_BASE
had it.  But my fix seems to be safer.


The flag should be set properly regardless of whether we do this 
optimization.


Jason

Re: [C++ Patch] PR 94034 ("[10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr")

[Jason Merrill]

On 3/6/20 8:24 PM, Marek Polacek wrote:

On Fri, Mar 06, 2020 at 07:40:20PM -0500, Jason Merrill wrote:

On 3/6/20 11:02 AM, Marek Polacek wrote:

On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:

... the patch ;)

Paolo.




Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by dump_expr"

A rather simple diagnostic issue where we failed to handle RESULT_DECL in
dump_expr.

Tested x86_64-linux.

 /cp
 PR c++/94034
 * error.c (dump_expr): Handle RESULT_DECL like the other *_DECL.

 /testsuite
 PR c++/94034
 * g++.dg/cpp0x/pr94034.C: New.



LGTM.  In fact, I had the same patch.

I think with this patch we print soemthing like " "
which is still kind of ugly, but improving that is out of scope for GCC 10.


Hmm, is that really so much better?


I would say it's better than
"'result_decl' not supported by dump_expr".  Since dump_expr
already handles a bunch of _DECL codes, we might as well add RESULT_DECL.


Why do we end up trying to print a RESULT_DECL?


The r10-5821 patch changed a ctor from

   { .ap =  }

to

   { .ap = & }


And both are wrong; it should be

 { .ap =  }

because the {} is initializing a.

Jason

Re: [C++ Patch] PR 94034 ("[10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr")

[Marek Polacek]

On Fri, Mar 06, 2020 at 07:40:20PM -0500, Jason Merrill wrote:
> On 3/6/20 11:02 AM, Marek Polacek wrote:
> > On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:
> > > ... the patch ;)
> > > 
> > > Paolo.
> > > 
> > 
> > > Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by 
> > > dump_expr"
> > > 
> > > A rather simple diagnostic issue where we failed to handle RESULT_DECL in
> > > dump_expr.
> > > 
> > > Tested x86_64-linux.
> > > 
> > > /cp
> > > PR c++/94034
> > > * error.c (dump_expr): Handle RESULT_DECL like the other *_DECL.
> > > 
> > > /testsuite
> > > PR c++/94034
> > > * g++.dg/cpp0x/pr94034.C: New.
> > > 
> > 
> > LGTM.  In fact, I had the same patch.
> > 
> > I think with this patch we print soemthing like " "
> > which is still kind of ugly, but improving that is out of scope for GCC 10.
> 
> Hmm, is that really so much better?

I would say it's better than 
"'result_decl' not supported by dump_expr".  Since dump_expr
already handles a bunch of _DECL codes, we might as well add RESULT_DECL.

> Why do we end up trying to print a RESULT_DECL?

The r10-5821 patch changed a ctor from

  { .ap =  }

to

  { .ap = & }

We should probably avoid printing such exprs altogether; I doubt people
are interested in seeing internal stuff like that.

Marek

Re: [PATCH] c++: Fix ABI issue with alignas on armv7hl [PR94050]

[Marek Polacek]

On Fri, Mar 06, 2020 at 05:49:07PM -0500, Jason Merrill wrote:
> On 3/5/20 2:40 PM, Marek Polacek wrote:
> > The static_assert in the following test was failing on armv7hl because
> > we were disregarding the alignas specifier on Cell.  BaseShape's data
> > takes up 20B on 32-bit architectures, but we failed to round up its
> > TYPE_SIZE.  This happens since the
> > 
> > patch: here, in layout_class_type for TenuredCell, we see that the size
> > of TenuredCell and its CLASSTYPE_AS_BASE match, so we set
> > 
> >CLASSTYPE_AS_BASE (t) = t;
> > 
> > But while TYPE_USER_ALIGN of TenuredCell was 0, TYPE_USER_ALIGN of its
> > CLASSTYPE_AS_BASE was 1.
> 
> Surely the bug is that TYPE_USER_ALIGN isn't set for TenuredCell?

That's my understanding.  I think it's clear that we're losing the alignas
specifier and so the TYPE_SIZE of BaseShape is wrong.  Before the patch from
June patch we'd set it...

>   After we replace it, it's no longer 1.  Then
> > we perform layout_empty_base_or_field for TenuredCell and since
> > TYPE_USER_ALIGN of its CLASSTYPE_AS_BASE is now 0, we don't do this
> > adjustment:
> > 
> >if (CLASSTYPE_USER_ALIGN (type))
> >  {
> >rli->record_align = MAX (rli->record_align, CLASSTYPE_ALIGN (type));
> >if (warn_packed)
> >  rli->unpacked_align = MAX (rli->unpacked_align, CLASSTYPE_ALIGN 
> > (type));
> >TYPE_USER_ALIGN (rli->t) = 1;
> >  }

...here, but we no longer do.  Is there any other direction I could pursue?
Well, perhaps...

> > --- a/gcc/cp/class.c
> > +++ b/gcc/cp/class.c
> > @@ -6705,6 +6705,10 @@ layout_class_type (tree t, tree *virtuals_p)
> > /* If we didn't end up needing an as-base type, don't use it.  */
> > if (CLASSTYPE_AS_BASE (t) != t
> > +  /* If T's CLASSTYPE_AS_BASE is TYPE_USER_ALIGN, but T is not,
> > +replacing the as-base type would change CLASSTYPE_USER_ALIGN,
> > +causing us to lose the user-specified alignment as in PR94050.  */
> > +  && !CLASSTYPE_USER_ALIGN (t)
> > && tree_int_cst_equal (TYPE_SIZE (t),
> >  TYPE_SIZE (CLASSTYPE_AS_BASE (t
> >   CLASSTYPE_AS_BASE (t) = t;

...we could copy the TYPE_USER_ALIGN flag to t if its old CLASSTYPE_AS_BASE
had it.  But my fix seems to be safer.

Marek

Re: [PATCH] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

[Jason Merrill]

On 3/6/20 6:54 PM, Marek Polacek wrote:

I got a report that building Chromium fails with the "modifying a const
object" error.  After some poking I realized it's a bug in GCC, not in
their codebase.

Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
nor the field were declared const.  So let's dial down the checking.
Here the COMPONENT_REF was const because of the "const_cast(m)"
thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
TREE_TYPE (t).


What is folding the const into the COMPONENT_REF?  Should that build a 
VIEW_CONVERT_EXPR instead?



While looking into this I noticed that we don't detect modifying a const
object in certain cases like in
.  That's because
we never evaluate an X::X() CALL_EXPR -- there's none.  So there's no
CONSTRUCTOR to set TREE_READONLY on.  No idea how to fix this, but it's
likely something for GCC 11 anyway.

PR c++/94074 - wrong modifying const object error for COMPONENT_REF.
* constexpr.c (modifying_const_object_p): Consider a COMPONENT_REF
const only if its object or field are const.

* g++.dg/cpp1y/constexpr-tracking-const17.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const18.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const19.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const20.C: New test.
---
  gcc/cp/constexpr.c| 30 ++-
  .../g++.dg/cpp1y/constexpr-tracking-const17.C | 23 ++
  .../g++.dg/cpp1y/constexpr-tracking-const18.C | 23 ++
  .../g++.dg/cpp1y/constexpr-tracking-const19.C | 23 ++
  .../g++.dg/cpp1y/constexpr-tracking-const20.C | 28 +
  5 files changed, 126 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const17.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const18.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const19.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const20.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 521c87f6210..936d171b9e4 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4401,7 +4401,35 @@ modifying_const_object_p (tree_code code, tree obj, bool 
mutable_p)
if (mutable_p)
  return false;
  
-  return (TREE_READONLY (obj) || CP_TYPE_CONST_P (TREE_TYPE (obj)));

+  if (TREE_READONLY (obj))
+return true;
+
+  if (CP_TYPE_CONST_P (TREE_TYPE (obj)))
+{
+  /* Although a COMPONENT_REF may have a const type, we should
+only consider it modifying a const object when the field
+or object components is const.  This can happen when using
+constructs such as const_cast(m), making something
+const even though it wasn't declared const.  */
+  if (TREE_CODE (obj) == COMPONENT_REF)
+   {
+ tree op1 = TREE_OPERAND (obj, 1);
+ if (CP_TYPE_CONST_P (TREE_TYPE (op1)))
+   return true;
+ else
+   {
+ tree op0 = TREE_OPERAND (obj, 0);
+ /* The LHS of . or -> might itself be a COMPONENT_REF.  */
+ if (TREE_CODE (op0) == COMPONENT_REF)
+   op0 = TREE_OPERAND (op0, 1);
+ return CP_TYPE_CONST_P (TREE_TYPE (op0));
+   }
+   }
+  else
+   return true;
+}
+
+  return false;
  }
  
  /* Evaluate an INIT_EXPR or MODIFY_EXPR.  */

diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const17.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const17.C
new file mode 100644
index 000..3f215d28175
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const17.C
@@ -0,0 +1,23 @@
+// PR c++/94074 - wrong modifying const object error for COMPONENT_REF.
+// { dg-do compile { target c++14 } }
+
+typedef decltype (sizeof (0)) size_t;
+
+template 
+struct array
+{
+  constexpr const E [](size_t n) const noexcept { return elems[n]; }
+  E elems[N];
+};
+
+template 
+struct S {
+  using U = array;
+  U m;
+  constexpr S(int) : m{}
+  {
+const_cast(const_cast(m)[0]) = 42;
+  }
+};
+
+constexpr S p = { 10 };
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const18.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const18.C
new file mode 100644
index 000..11a680468c2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const18.C
@@ -0,0 +1,23 @@
+// PR c++/94074 - wrong modifying const object error for COMPONENT_REF.
+// { dg-do compile { target c++14 } }
+
+typedef decltype (sizeof (0)) size_t;
+
+template 
+struct array
+{
+  constexpr const E [](size_t n) const noexcept { return elems[n]; }
+  E elems[N];
+};
+
+template 
+struct S {
+  using U = array;
+  const U m;
+  constexpr S(int) : m{}
+  {
+const_cast(const_cast(m)[0]) = 42; // { dg-error "modifying a 
const object" }
+  }

Re: [PATCH] c++: Fix missing SFINAE when binding a bit-field to a reference (PR 93729)

[Jason Merrill]

On 3/6/20 1:41 PM, Patrick Palka wrote:

We are unconditionally emitting an error here, without first checking complain.

This is not a regression, though I guess it could loosely be considered to be a
concepts bug, and the fix seems to be relatively harmless.  Does this maybe look
OK for trunk, or should it wait for stage 1?


This looks obvious enough to be OK for trunk.


gcc/cp/ChangeLog:

PR c++/93729
* call.c (convert_like_real): Check complain before emitting an error
about binding a bit-field to a reference.

gcc/testsuite/ChangeLog:

PR c++/93729
* g++.dg/concepts/pr93729.C: New test.
---
  gcc/cp/call.c   | 21 -
  gcc/testsuite/g++.dg/concepts/pr93729.C | 15 +++
  2 files changed, 27 insertions(+), 9 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/pr93729.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 85bbd043a1d..c0340d96f3c 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7730,15 +7730,18 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
  {
/* If the reference is volatile or non-const, we
   cannot create a temporary.  */
-   if (lvalue & clk_bitfield)
- error_at (loc, "cannot bind bit-field %qE to %qT",
-   expr, ref_type);
-   else if (lvalue & clk_packed)
- error_at (loc, "cannot bind packed field %qE to %qT",
-   expr, ref_type);
-   else
- error_at (loc, "cannot bind rvalue %qE to %qT",
-   expr, ref_type);
+   if (complain & tf_error)
+ {
+   if (lvalue & clk_bitfield)
+ error_at (loc, "cannot bind bit-field %qE to %qT",
+   expr, ref_type);
+   else if (lvalue & clk_packed)
+ error_at (loc, "cannot bind packed field %qE to %qT",
+   expr, ref_type);
+   else
+ error_at (loc, "cannot bind rvalue %qE to %qT",
+   expr, ref_type);
+ }
return error_mark_node;
  }
/* If the source is a packed field, and we must use a copy
diff --git a/gcc/testsuite/g++.dg/concepts/pr93729.C 
b/gcc/testsuite/g++.dg/concepts/pr93729.C
new file mode 100644
index 000..7397edb311d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/pr93729.C
@@ -0,0 +1,15 @@
+// { dg-do compile { target c++2a } }
+
+// PR c++/93729
+
+struct B
+{
+  int a:4;
+  int b:4;
+};
+
+template
+concept c1
+  = requires(T x, void(f)(int &)) { f(x.a); }; // { dg-bogus "cannot bind" }
+
+static_assert(!c1);

Re: [PATCH] c++: Fix pretty printing of TYPENAME_TYPEs

[Jason Merrill]

On 3/6/20 1:41 PM, Patrick Palka wrote:

I noticed that in some concepts diagnostic messages, we were printing typename
types incorrectly, e.g. printing remove_reference_t as

   typename remove_reference::remove_reference_t

instead of

   typename remove_reference::type.

Fixed this by looking at TYPENAME_TYPE_FULLNAME instead of TYPE_NAME, which is
consistent with how dump_typename in error.c does it.

Does this look OK to commit after testing?


OK.


gcc/cp/ChangeLog:

* cxx-pretty-print.c (cxx_pretty_printer::simple_type_specifier)
[TYPENAME_TYPE]: Print the TYPENAME_TYPE_FULLNAME instead of the
TYPE_NAME.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic4.C: New test.
---
  gcc/cp/cxx-pretty-print.c   |  2 +-
  gcc/testsuite/g++.dg/concepts/diagnostic4.C | 18 ++
  2 files changed, 19 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic4.C

diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 397bdbfa234..100154e400f 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -1360,7 +1360,7 @@ cxx_pretty_printer::simple_type_specifier (tree t)
  case TYPENAME_TYPE:
pp_cxx_ws_string (this, "typename");
pp_cxx_nested_name_specifier (this, TYPE_CONTEXT (t));
-  pp_cxx_unqualified_id (this, TYPE_NAME (t));
+  pp_cxx_unqualified_id (this, TYPENAME_TYPE_FULLNAME (t));
break;
  
  default:

diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic4.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic4.C
new file mode 100644
index 000..677bc867634
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic4.C
@@ -0,0 +1,18 @@
+// { dg-do compile { target c++2a } }
+
+template
+  struct remove_reference
+  { using type = T; };
+
+template
+  using remove_reference_t = remove_reference::type;
+
+template
+  inline constexpr bool blah = false;
+
+template
+  requires blah>
+  // { dg-message "typename remove_reference::type" "" { target *-*-* } .-1 
}
+  void foo() { }
+
+void bar() { foo (); } // { dg-error "use of" }

Re: [C++ Patch] PR 94034 ("[10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr")

[Jason Merrill]

On 3/6/20 11:02 AM, Marek Polacek wrote:

On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:

... the patch ;)

Paolo.




Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by dump_expr"

A rather simple diagnostic issue where we failed to handle RESULT_DECL in
dump_expr.

Tested x86_64-linux.

/cp
PR c++/94034
* error.c (dump_expr): Handle RESULT_DECL like the other *_DECL.

/testsuite
PR c++/94034
* g++.dg/cpp0x/pr94034.C: New.



LGTM.  In fact, I had the same patch.

I think with this patch we print soemthing like " "
which is still kind of ugly, but improving that is out of scope for GCC 10.


Hmm, is that really so much better?

Why do we end up trying to print a RESULT_DECL?

Jason

[PATCH] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

[Marek Polacek]

I got a report that building Chromium fails with the "modifying a const
object" error.  After some poking I realized it's a bug in GCC, not in
their codebase.

Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
nor the field were declared const.  So let's dial down the checking.
Here the COMPONENT_REF was const because of the "const_cast(m)"
thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
TREE_TYPE (t).

While looking into this I noticed that we don't detect modifying a const
object in certain cases like in
.  That's because
we never evaluate an X::X() CALL_EXPR -- there's none.  So there's no
CONSTRUCTOR to set TREE_READONLY on.  No idea how to fix this, but it's
likely something for GCC 11 anyway.

PR c++/94074 - wrong modifying const object error for COMPONENT_REF.
* constexpr.c (modifying_const_object_p): Consider a COMPONENT_REF
const only if its object or field are const.

* g++.dg/cpp1y/constexpr-tracking-const17.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const18.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const19.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const20.C: New test.
---
 gcc/cp/constexpr.c| 30 ++-
 .../g++.dg/cpp1y/constexpr-tracking-const17.C | 23 ++
 .../g++.dg/cpp1y/constexpr-tracking-const18.C | 23 ++
 .../g++.dg/cpp1y/constexpr-tracking-const19.C | 23 ++
 .../g++.dg/cpp1y/constexpr-tracking-const20.C | 28 +
 5 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const17.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const18.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const19.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const20.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 521c87f6210..936d171b9e4 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4401,7 +4401,35 @@ modifying_const_object_p (tree_code code, tree obj, bool 
mutable_p)
   if (mutable_p)
 return false;
 
-  return (TREE_READONLY (obj) || CP_TYPE_CONST_P (TREE_TYPE (obj)));
+  if (TREE_READONLY (obj))
+return true;
+
+  if (CP_TYPE_CONST_P (TREE_TYPE (obj)))
+{
+  /* Although a COMPONENT_REF may have a const type, we should
+only consider it modifying a const object when the field
+or object components is const.  This can happen when using
+constructs such as const_cast(m), making something
+const even though it wasn't declared const.  */
+  if (TREE_CODE (obj) == COMPONENT_REF)
+   {
+ tree op1 = TREE_OPERAND (obj, 1);
+ if (CP_TYPE_CONST_P (TREE_TYPE (op1)))
+   return true;
+ else
+   {
+ tree op0 = TREE_OPERAND (obj, 0);
+ /* The LHS of . or -> might itself be a COMPONENT_REF.  */
+ if (TREE_CODE (op0) == COMPONENT_REF)
+   op0 = TREE_OPERAND (op0, 1);
+ return CP_TYPE_CONST_P (TREE_TYPE (op0));
+   }
+   }
+  else
+   return true;
+}
+
+  return false;
 }
 
 /* Evaluate an INIT_EXPR or MODIFY_EXPR.  */
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const17.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const17.C
new file mode 100644
index 000..3f215d28175
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const17.C
@@ -0,0 +1,23 @@
+// PR c++/94074 - wrong modifying const object error for COMPONENT_REF.
+// { dg-do compile { target c++14 } }
+
+typedef decltype (sizeof (0)) size_t;
+
+template 
+struct array
+{
+  constexpr const E [](size_t n) const noexcept { return elems[n]; }
+  E elems[N];
+};
+
+template 
+struct S {
+  using U = array;
+  U m;
+  constexpr S(int) : m{}
+  {
+const_cast(const_cast(m)[0]) = 42;
+  }
+};
+
+constexpr S p = { 10 };
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const18.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const18.C
new file mode 100644
index 000..11a680468c2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const18.C
@@ -0,0 +1,23 @@
+// PR c++/94074 - wrong modifying const object error for COMPONENT_REF.
+// { dg-do compile { target c++14 } }
+
+typedef decltype (sizeof (0)) size_t;
+
+template 
+struct array
+{
+  constexpr const E [](size_t n) const noexcept { return elems[n]; }
+  E elems[N];
+};
+
+template 
+struct S {
+  using U = array;
+  const U m;
+  constexpr S(int) : m{}
+  {
+const_cast(const_cast(m)[0]) = 42; // { dg-error 
"modifying a const object" }
+  }
+};
+
+constexpr S p = { 10 }; // { dg-message "originally declared" }
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const19.C 

PATCH -- Fix degree trignometric functions

[Steve Kargl]

Caveat 1: Patch is against svn 280157.

Caveat 2: I am no longer subscribed to fortran@.  Hit reply-all if you
  want to communicate with me.

Caveat 3: I don't do git.  This is likely my last patch for GCC.

TL;DR version.

  Fix the simplification and handling of the degree trigonometric functions.
  This includes fixing a number of ICEs.  See PR 93871.

  ChangeLog and patch attached.

Long version.

  This patch fixes a number of issues with the degree trigonometric functions.

  1. The option -fdec-math is a now a NOP.  I left the option intact, because
 someone may have it in a Makefile or build script.  This option sets
 the variable flag_dec_math, which is no longer used.  The DEC functions
 SIND, COSD, TAND, ASIND, ACOSD, ATAND, ATAN2D, COTAN, and COTAND
 are now part of the nonstandard intrinsics provided under -std=gnu.

  2. The previous special handling of these functions has been removed.
 All functions are now handled just like any other intrinsic function
 (except for a few special cases with IEEE_ARITHMETIC).

  3. Simplification routines do the following mappings:
 sind(x) = sin((pi/180) * x) asind(x) = (180/pi) * asin(x)
 cosd(x) = cos((pi/180) * x) acosd(x) = (180/pi) * acos(x)
 tand(x) = tan((pi/180) * x) atand(x) = (180/pi) * atan(x)
 atan2d(y,x) = (180/pi) * atan2(y,x)
 cotand(x) = cotan((pi/180) * x)
 All computations are carried out by MPFR or MPC.

  4. For asind, acosd, atand, atan2d, cotan, and cotand are in-lined.
 For example, 

 function foo(x)
real foo, x
foo = asind(x)
 end function foo

 produces

 foo (real(kind=4) & restrict x)
 {
   real(kind=4) __result_foo;

   __result_foo = __builtin_asinf (*x) * 5.72957763671875e+1;
   return __result_foo;
 }

 At the moment, cotand(x) is transformed into -tan((pi/180)*x + pi/2).
 No attempted of doing a range-reduction step (see below) has been done.
 For cotan(x) the argument can be real or complex.  If x is real, the
 function is transformed as cotan(x) = -tan(x + pi/2).  If x is complex,
 gfortran will produce cotan(x) = cos(x)/sin(x) where cos and sin map
 to __builtin_ccos and __builtin_csin, respectively.

  5. New functions have been added to libgfortran to handle sind, cosd,
 and tand.

 For x = +-inf or nan, these functions return nan.

 For small x,
 sind(x) = sin((pi/180) * x) = (pi/180) * x
 tand(x) = tan((pi/180) * x) = (pi/180) * x
 cosd(x) = 1 - tiny (where tiny is volatile and should cause INEXACT).

 For normal x, a few steps are performed.  First, x is replaced by
 fmod(x,360) such that the result is now in [0,360].  The functions
 are cyclic afterall.  Second, [0,360] is folded into the range [0,45]
 and the choice of computing sin((pi/180)*x) or cos((pi/180)*x) is then
 made.  This is required to achieve a small ULP near the zeros of the
 functions.  A final step uses an FMA where (pi/180) is split into high
 and low parts.

-- 
steve

 

-- 
Steve
Fortran Frontend Changes:

* gfortran.h: Add GFC_ISYM_ACOSD, GFC_ISYM_ASIND, GFC_ISYM_ATAN2D,
GFC_ISYM_ATAND, GFC_ISYM_COSD, GFC_ISYM_COTAND, GFC_ISYM_SIND, and
GFC_ISYM_TAND.

* intrinsic.c (add_functions): Remove check for flag_dec_math.
Give degree trig functions simplification and name resolution
functions (e.g., gfc_simplify_atrigd () and gfc_resolve_atrigd ()).
(do_simplify): Remove special casing of degree trig functions.

* intrinsic.h (gfc_simplify_acosd, gfc_simplify_asind, 
gfc_simplify_atand, gfc_simplify_cosd, gfc_simplify_cotand,
gfc_simplify_sind, gfc_simplify_tand, gfc_resolve_trigd2): Add new
prototypes.
(gfc_simplify_atrigd, gfc_simplify_trigd, gfc_resolve_cotan,
resolve_atrigd): Remove prototypes of deleted functions.

* iresolve.c (is_trig_resolved, copy_replace_function_shallow,
gfc_resolve_cotan, get_radians, get_degrees, resolve_trig_call,
gfc_resolve_atrigd, gfc_resolve_atan2d): Delete
functions.
(gfc_resolve_trigd, gfc_resolve_trigd2): Set typ-spec and resolve
funciton names.
 
* simplify.c (rad2deg): Rename degrees_f ().

* simplify.c (rad2deg, gfc_simplify_acosd, gfc_simplify_asind,
gfc_simplify_atand, gfc_simplify_atan2d, gfc_simplify_cosd,
gfc_simplify_sind, gfc_simplify_tand, gfc_simplify_cotand): New
function.

(gfc_simplify_atan2): Fix error message.
 
(simplify_trig_call, gfc_simplify_trigd, gfc_simplify_atrigd,
radians_f): Delete function.

* trans-intrinsic.c: Add LIB_FUNCTION () for sind, cosd, tand.
(rad2deg, gfc_conv_intrinsic_atrigd, gfc_conv_intrinsic_cotan,
gfc_conv_intrinsic_cotand, gfc_conv_intrinsic_atan2d):
New function

Libgfortran Changes:

* Makefile.am: Add 

Re: [PATCH] c++: Fix ABI issue with alignas on armv7hl [PR94050]

[Jason Merrill]

On 3/5/20 2:40 PM, Marek Polacek wrote:

The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell.  BaseShape's data
takes up 20B on 32-bit architectures, but we failed to round up its
TYPE_SIZE.  This happens since the

patch: here, in layout_class_type for TenuredCell, we see that the size
of TenuredCell and its CLASSTYPE_AS_BASE match, so we set

   CLASSTYPE_AS_BASE (t) = t;

But while TYPE_USER_ALIGN of TenuredCell was 0, TYPE_USER_ALIGN of its
CLASSTYPE_AS_BASE was 1.


Surely the bug is that TYPE_USER_ALIGN isn't set for TenuredCell?


  After we replace it, it's no longer 1.  Then

we perform layout_empty_base_or_field for TenuredCell and since
TYPE_USER_ALIGN of its CLASSTYPE_AS_BASE is now 0, we don't do this
adjustment:

   if (CLASSTYPE_USER_ALIGN (type))
 {
   rli->record_align = MAX (rli->record_align, CLASSTYPE_ALIGN (type));
   if (warn_packed)
 rli->unpacked_align = MAX (rli->unpacked_align, CLASSTYPE_ALIGN 
(type));
   TYPE_USER_ALIGN (rli->t) = 1;
 }

where rli->t is BaseShape.  Then finalize_record_size won't use the
correct rli->record_align and therefore
   /* Round the size up to be a multiple of the required alignment.  */
   TYPE_SIZE (rli->t) = round_up (unpadded_size, TYPE_ALIGN (rli->t));
after this we end up with the wrong size.

Since the original fix was to avoid creating extra copies for LTO
purposes, I think the following fix should be acceptable.

Bootstrapped/regtested on x86_64-linux, ok for trunk?  I verified the
fix on the attached testcase using a --target=armv7hl-linux-gnueabi cross,
but haven't actually run the testsuite.

PR c++/94050 - ABI issue with alignas on armv7hl.
* class.c (layout_class_type): Don't replace a class's
CLASSTYPE_AS_BASE if it is CLASSTYPE_USER_ALIGN.

* g++.dg/abi/align3.C: New test.
---
  gcc/cp/class.c|  4 
  gcc/testsuite/g++.dg/abi/align3.C | 12 
  2 files changed, 16 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/abi/align3.C

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index b3787f75d7b..4a17751d70b 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -6705,6 +6705,10 @@ layout_class_type (tree t, tree *virtuals_p)
  
/* If we didn't end up needing an as-base type, don't use it.  */

if (CLASSTYPE_AS_BASE (t) != t
+  /* If T's CLASSTYPE_AS_BASE is TYPE_USER_ALIGN, but T is not,
+replacing the as-base type would change CLASSTYPE_USER_ALIGN,
+causing us to lose the user-specified alignment as in PR94050.  */
+  && !CLASSTYPE_USER_ALIGN (t)
&& tree_int_cst_equal (TYPE_SIZE (t),
 TYPE_SIZE (CLASSTYPE_AS_BASE (t
  CLASSTYPE_AS_BASE (t) = t;
diff --git a/gcc/testsuite/g++.dg/abi/align3.C 
b/gcc/testsuite/g++.dg/abi/align3.C
new file mode 100644
index 000..a56693a34b8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/align3.C
@@ -0,0 +1,12 @@
+// PR c++/94050 - ABI issue with alignas on armv7hl.
+// { dg-do compile { target c++11 } }
+
+struct alignas(8) Cell {};
+struct TenuredCell : public Cell {};
+struct BaseShape : public TenuredCell {
+  void *p;
+  unsigned q, r;
+  void *s;
+  __UINTPTR_TYPE__ t;
+};
+static_assert (sizeof (BaseShape) % 8 == 0, "");

base-commit: 2d22ab64c4774d7d30c7e014652b28a13d744aec

Re: [PATCH,rs6000] Fix -mlong-double documentation

[Segher Boessenkool]

Hi!

On Fri, Mar 06, 2020 at 11:01:50AM -0800, Carl Love wrote:
> The following patch improves the description of the ppc64 -mlong-double 
> option.

Okay for trunk.  Some trivialities:

> RS6000 Fix -mlong-double documentation

rs6000: Fix [etc.]

(It's no more than just the dir name now; and the target name that it is
named after was lower case, as well).

> 2020-03-06  Carl Love  
>   * config/rs6000/rs6000.opt: Update the description of the
>   command line option.

There should be a blank line after the date+name+email line.

>  mlong-double-
>  Target RejectNegative Joined UInteger Var(rs6000_long_double_type_size) Save
> --mlong-double-[64,128]   Specify size of long double.
> +Use -mlong-double-64 for 64-bit IEEE floating point format. Use
> +-mlong-double-128 for 128-bit floating point format (either IEEE or IBM).

Most options (but not all) use two spaces after a dot (just like comments
and documentation do).

Thanks!


Segher

[committed] analyzer: improvements to region_model::get_representative_tree

[David Malcolm]

This patch extends region_model::get_representative_tree so that dumps
are able to refer to string literals, which I've found useful in
investigating a state-bloat issue.

Doing so uncovered a bug in the handling of views I introduced in
r10-7024-ge516294a1acb28d44cfd583cc6a80354044e where the code was
erroneously using TREE_TYPE on the view region's type, rather than just
using its type, which the patch also fixes.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 90f7c3007d58c5cb538d00351c038f3f2cfcaf67.

gcc/analyzer/ChangeLog:
* analyzer.h (class array_region): New forward decl.
* program-state.cc (selftest::test_program_state_dumping_2): New.
(selftest::analyzer_program_state_cc_tests): Call it.
* region-model.cc (array_region::constant_from_key): New.
(region_model::get_representative_tree): Handle region_svalue by
generating an ADDR_EXPR.
(region_model::get_representative_path_var): In view handling,
remove erroneous TREE_TYPE when determining the type of the tree.
Handle array regions and STRING_CST.
(selftest::assert_dump_tree_eq): New.
(ASSERT_DUMP_TREE_EQ): New macro.
(selftest::test_get_representative_tree): New selftest.
(selftest::analyzer_region_model_cc_tests): Call it.
* region-model.h (region::dyn_cast_array_region): New vfunc.
(array_region::dyn_cast_array_region): New vfunc implementation.
(array_region::constant_from_key): New decl.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/malloc-4.c: Update expected output of leak to
reflect fix to region_model::get_representative_path_var, adding
the missing "*" from the cast.
---
 gcc/analyzer/analyzer.h  |   1 +
 gcc/analyzer/program-state.cc|  46 +++
 gcc/analyzer/region-model.cc | 100 ++-
 gcc/analyzer/region-model.h  |   3 +
 gcc/testsuite/gcc.dg/analyzer/malloc-4.c |   2 +-
 5 files changed, 147 insertions(+), 5 deletions(-)

diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
index 78d6009e8a3..8d0d16979b9 100644
--- a/gcc/analyzer/analyzer.h
+++ b/gcc/analyzer/analyzer.h
@@ -43,6 +43,7 @@ class svalue;
   class setjmp_svalue;
 class region;
   class map_region;
+  class array_region;
   class symbolic_region;
 class region_model;
 class region_model_context;
diff --git a/gcc/analyzer/program-state.cc b/gcc/analyzer/program-state.cc
index 804800f65fe..24b6783d92a 100644
--- a/gcc/analyzer/program-state.cc
+++ b/gcc/analyzer/program-state.cc
@@ -1467,6 +1467,51 @@ test_program_state_dumping ()
  "rmodel: p:  malloc: {sv1: unchecked (`p')}");
 }
 
+/* Verify that program_state::dump_to_pp works for string literals.  */
+
+static void
+test_program_state_dumping_2 ()
+{
+/* Create a program_state for a global ptr "p" that points to
+   a string constant.  */
+  tree p = build_global_decl ("p", ptr_type_node);
+
+  tree string_cst_ptr = build_string_literal (4, "foo");
+
+  auto_delete_vec  checkers;
+  extrinsic_state ext_state (checkers);
+
+  program_state s (ext_state);
+  region_model *model = s.m_region_model;
+  region_id p_rid = model->get_lvalue (p, NULL);
+  svalue_id str_sid = model->get_rvalue (string_cst_ptr, NULL);
+  model->set_value (p_rid, str_sid, NULL);
+
+  ASSERT_DUMP_EQ
+(s, ext_state, false,
+ "rmodel: r0: {kind: `root', parent: null, sval: null}\n"
+ "|-globals: r1: {kind: `globals', parent: r0, sval: null, map: {`p': 
r2}}\n"
+ "|  `-`p': r2: {kind: `primitive', parent: r1, sval: sv3, type: `void 
*'}\n"
+ "||: sval: sv3: {type: `void *', }\n"
+ "||: type: `void *'\n"
+ "`-r3: {kind: `array', parent: r0, sval: sv0, type: `const char[4]', 
array: {[0]: r4}}\n"
+ "  |: sval: sv0: {type: `const char[4]', `\"foo\"'}\n"
+ "  |: type: `const char[4]'\n"
+ "  `-[0]: r4: {kind: `primitive', parent: r3, sval: null, type: `const 
char'}\n"
+ "|: type: `const char'\n"
+ "svalues:\n"
+ "  sv0: {type: `const char[4]', `\"foo\"'}\n"
+ "  sv1: {type: `int', `0'}\n"
+ "  sv2: {type: `const char *', }\n"
+ "  sv3: {type: `void *', }\n"
+ "constraint manager:\n"
+ "  equiv classes:\n"
+ "  constraints:\n");
+
+  ASSERT_DUMP_EQ (s, ext_state, true,
+ "rmodel: p: &\"foo\"[0]");
+}
+
 /* Verify that program_states with identical sm-state can be merged,
and that the merged program_state preserves the sm-state.  */
 
@@ -1570,6 +1615,7 @@ analyzer_program_state_cc_tests ()
 {
   test_sm_state_map ();
   test_program_state_dumping ();
+  test_program_state_dumping_2 ();
   test_program_state_merging ();
   test_program_state_merging_2 ();
 }
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index e7e517ade15..87980e7c8cd 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -2494,6 

[committed] analyzer: improvements to state dumping

[David Malcolm]

This patch fixes a bug in which summarized state dumps involving a
non-NULL pointer to a region for which get_representative_path_var
returned NULL were erroneously dumped as "NULL".

It also extends sm-state dumps so that they show representative tree
values, where available.

Finally, it adds some selftest coverage for such dumps.  Doing so
requires replacing some %qE with a dump_quoted_tree, to avoid
C vs C++ differences between "make selftest-c" and "make selftest-c++".

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 41f99ba6c576b84ca0f2de7d66ebc087454e93cf.

gcc/analyzer/ChangeLog:
* analyzer.h (dump_quoted_tree): New decl.
* engine.cc (exploded_node::dump_dot): Pass region model to
sm_state_map::print.
* program-state.cc: Include diagnostic-core.h.
(sm_state_map::print): Add "model" param and use it to print
representative trees.  Only print origin information if non-null.
(sm_state_map::dump): Pass NULL for model to print call.
(program_state::print): Pass region model to sm_state_map::print.
(program_state::dump_to_pp): Use spaces rather than newlines when
summarizing.  Pass region_model to sm_state_map::print.
(ana::selftest::assert_dump_eq): New function.
(ASSERT_DUMP_EQ): New macro.
(ana::selftest::test_program_state_dumping): New function.
(ana::selftest::analyzer_program_state_cc_tests): Call it.
* program-state.h (program_state::print): Add model param.
* region-model.cc (dump_quoted_tree): New function.
(map_region::print_fields): Use dump_quoted_tree rather than
%qE to avoid lang-dependent output.
(map_region::dump_child_label): Likewise.
(region_model::dump_summary_of_map): For SK_REGION, when
get_representative_path_var fails, print the region id rather than
erroneously printing NULL.
* sm.cc (state_machine::get_state_by_name): New function.
* sm.h (state_machine::get_state_by_name): New decl.
---
 gcc/analyzer/analyzer.h   |   8 ++-
 gcc/analyzer/engine.cc|   2 +-
 gcc/analyzer/program-state.cc | 128 ++
 gcc/analyzer/program-state.h  |   3 +-
 gcc/analyzer/region-model.cc  |  29 +---
 gcc/analyzer/sm.cc|  15 
 gcc/analyzer/sm.h |   2 +
 7 files changed, 161 insertions(+), 26 deletions(-)

diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
index 5364edb3d96..78d6009e8a3 100644
--- a/gcc/analyzer/analyzer.h
+++ b/gcc/analyzer/analyzer.h
@@ -21,12 +21,12 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef GCC_ANALYZER_ANALYZER_H
 #define GCC_ANALYZER_ANALYZER_H
 
-/* Forward decls of common types, with indentation to show inheritance.  */
-
 class graphviz_out;
 
 namespace ana {
 
+/* Forward decls of common types, with indentation to show inheritance.  */
+
 class supergraph;
 class supernode;
 class superedge;
@@ -71,6 +71,10 @@ class state_purge_per_ssa_name;
 class state_change;
 class rewind_info_t;
 
+/* Forward decls of functions.  */
+
+extern void dump_quoted_tree (pretty_printer *pp, tree t);
+
 } // namespace ana
 
 extern bool is_special_named_call_p (const gcall *call, const char *funcname,
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index e411d5b40e7..2431ae34474 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -869,7 +869,7 @@ exploded_node::dump_dot (graphviz_out *gv, const 
dump_args_t ) const
if (!smap->is_empty_p ())
  {
pp_printf (pp, "%s: ", ext_state.get_name (i));
-   smap->print (ext_state.get_sm (i), pp);
+   smap->print (ext_state.get_sm (i), state.m_region_model, pp);
pp_newline (pp);
  }
   }
diff --git a/gcc/analyzer/program-state.cc b/gcc/analyzer/program-state.cc
index 971e8e0a7d6..804800f65fe 100644
--- a/gcc/analyzer/program-state.cc
+++ b/gcc/analyzer/program-state.cc
@@ -22,6 +22,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "system.h"
 #include "coretypes.h"
 #include "tree.h"
+#include "diagnostic-core.h"
 #include "diagnostic.h"
 #include "function.h"
 #include "analyzer/analyzer.h"
@@ -147,10 +148,13 @@ sm_state_map::clone_with_remapping (const 
one_way_svalue_id_map _map) const
   return result;
 }
 
-/* Print this sm_state_map (for SM) to PP.  */
+/* Print this sm_state_map (for SM) to PP.
+   If MODEL is non-NULL, print representative tree values where
+   available.  */
 
 void
-sm_state_map::print (const state_machine , pretty_printer *pp) const
+sm_state_map::print (const state_machine , const region_model *model,
+pretty_printer *pp) const
 {
   bool first = true;
   pp_string (pp, "{");
@@ -170,10 +174,27 @@ sm_state_map::print (const state_machine , 
pretty_printer *pp) const
   sid.print (pp);
 
   entry_t e = (*iter).second;
-  pp_printf (pp, ": %s (origin: ",
- 

Re: [committed] Fix STATIC_CHAIN_REGNUM for v850 port

[Jeff Law]

On Tue, 2020-03-03 at 13:38 -0500, Hans-Peter Nilsson wrote:
> On Sat, 29 Feb 2020, Jeff Law wrote:
> > Wow, I think I wrote the v850 port back in circa 1997 and this bug has been
> > latent all this time.  Vlad's IRA changes twiddled register allocation in
> > just
> > the right way to expose this bug.
> > 
> > I'm not sure what I was thinking, but apparently I made a spectacularly bad
> > choice for the STATIC_CHAIN_REGNUM in choosing a call-saved register (r20).
> > 
> > It's simply wrong to use a call-saved register for the static chain.
> 
> Heh.  I did that mistake too, for CRIS. :/
> 
> A comment from RTH below my (incorrect) comment in cris.c above
> cris_asm_trampoline_template alludes to there being an
> ABI-neutral solution: "??? See the i386 regparm=3 implementation
> that pushes the static chain value to the stack in the
> trampoline, and uses a call-saved register when called
> directly." ... but IIRC it either didn't apply for CRIS or I
> didn't look into it thoroughly enough.  Or that's also buggy.
> 
> brgds, H-P
> PS. Perhaps a doc update with a warning is a suitable penance? :)
That was already the plan.  I took care of the gcc-10 changes.html bit today.

jeff

[PATCH,rs6000] Fix -mlong-double documentation

[Carl Love]

GCC maintianers:

The following patch improves the description of the ppc64 -mlong-double 
option.

I compiled it and tested it by hand with the command:

  gcc  --target-help

Please let me know if the patch is OK for mainline.

Thanks. 

Carl Love
 
--

RS6000 Fix -mlong-double documentation

gcc/ChangeLog

2020-03-06  Carl Love  
* config/rs6000/rs6000.opt: Update the description of the
command line option.
---
 gcc/config/rs6000/rs6000.opt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt
index ed3b44a04a6..8e0ae9a0b5f 100644
--- a/gcc/config/rs6000/rs6000.opt
+++ b/gcc/config/rs6000/rs6000.opt
@@ -414,7 +414,8 @@ Warn about deprecated 'vector long ...' AltiVec type usage.
 
 mlong-double-
 Target RejectNegative Joined UInteger Var(rs6000_long_double_type_size) Save
--mlong-double-[64,128] Specify size of long double.
+Use -mlong-double-64 for 64-bit IEEE floating point format. Use
+-mlong-double-128 for 128-bit floating point format (either IEEE or IBM).
 
 ; This option existed in the past, but now is always on.
 mlra
-- 
2.17.1

[PR94027] ICE in mangling

[Nathan Sidwell]

Now same_type_p rejects argument packs, we need to be more careful 
calling it with template argument vector contents.


The mangler needs to do some comparisons to find the special 
substitutions.  While that code looks a little ugly, this seems the 
smallest fix.


nathan

--
Nathan Sidwell
2020-03-06  Nathan Sidwell  

	PR c++/94027
	* mangle.c (find_substitution): Don't call same_type_p on template
	args that cannot match.

diff --git c/gcc/cp/mangle.c w/gcc/cp/mangle.c
index a0e888fde62..1fc78bfa753 100644
--- c/gcc/cp/mangle.c
+++ w/gcc/cp/mangle.c
@@ -628,6 +628,8 @@ find_substitution (tree node)
 	{
 	  tree args = CLASSTYPE_TI_ARGS (type);
 	  if (TREE_VEC_LENGTH (args) == 3
+		  && (TREE_CODE (TREE_VEC_ELT (args, 0))
+		  == TREE_CODE (char_type_node))
 		  && same_type_p (TREE_VEC_ELT (args, 0), char_type_node)
 		  && is_std_substitution_char (TREE_VEC_ELT (args, 1),
 	   SUBID_CHAR_TRAITS)
@@ -652,7 +654,7 @@ find_substitution (tree node)
 	 args  > .  */
   tree args = CLASSTYPE_TI_ARGS (type);
   if (TREE_VEC_LENGTH (args) == 2
-	  && TYPE_P (TREE_VEC_ELT (args, 0))
+	  && TREE_CODE (TREE_VEC_ELT (args, 0)) == TREE_CODE (char_type_node)
 	  && same_type_p (TREE_VEC_ELT (args, 0), char_type_node)
 	  && is_std_substitution_char (TREE_VEC_ELT (args, 1),
    SUBID_CHAR_TRAITS))
diff --git c/gcc/testsuite/g++.dg/pr94027.C w/gcc/testsuite/g++.dg/pr94027.C
new file mode 100644
index 000..03cd68f1b0f
--- /dev/null
+++ w/gcc/testsuite/g++.dg/pr94027.C
@@ -0,0 +1,22 @@
+// { dg-do compile { target c++11 } }
+// PR 94027 ICE mangling
+
+class a {
+public:
+  a (char);
+};
+struct b {
+  b (a);
+};
+template 
+void ax (int)
+{
+  struct c : b {
+c () : b {sizeof...(aw)}
+{}
+  };
+}
+
+void az() {
+  ax ({});
+}

[PATCH] c++: Fix missing SFINAE when binding a bit-field to a reference (PR 93729)

[Patrick Palka]

We are unconditionally emitting an error here, without first checking complain.

This is not a regression, though I guess it could loosely be considered to be a
concepts bug, and the fix seems to be relatively harmless.  Does this maybe look
OK for trunk, or should it wait for stage 1?

gcc/cp/ChangeLog:

PR c++/93729
* call.c (convert_like_real): Check complain before emitting an error
about binding a bit-field to a reference.

gcc/testsuite/ChangeLog:

PR c++/93729
* g++.dg/concepts/pr93729.C: New test.
---
 gcc/cp/call.c   | 21 -
 gcc/testsuite/g++.dg/concepts/pr93729.C | 15 +++
 2 files changed, 27 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/pr93729.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 85bbd043a1d..c0340d96f3c 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7730,15 +7730,18 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
  {
/* If the reference is volatile or non-const, we
   cannot create a temporary.  */
-   if (lvalue & clk_bitfield)
- error_at (loc, "cannot bind bit-field %qE to %qT",
-   expr, ref_type);
-   else if (lvalue & clk_packed)
- error_at (loc, "cannot bind packed field %qE to %qT",
-   expr, ref_type);
-   else
- error_at (loc, "cannot bind rvalue %qE to %qT",
-   expr, ref_type);
+   if (complain & tf_error)
+ {
+   if (lvalue & clk_bitfield)
+ error_at (loc, "cannot bind bit-field %qE to %qT",
+   expr, ref_type);
+   else if (lvalue & clk_packed)
+ error_at (loc, "cannot bind packed field %qE to %qT",
+   expr, ref_type);
+   else
+ error_at (loc, "cannot bind rvalue %qE to %qT",
+   expr, ref_type);
+ }
return error_mark_node;
  }
/* If the source is a packed field, and we must use a copy
diff --git a/gcc/testsuite/g++.dg/concepts/pr93729.C 
b/gcc/testsuite/g++.dg/concepts/pr93729.C
new file mode 100644
index 000..7397edb311d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/pr93729.C
@@ -0,0 +1,15 @@
+// { dg-do compile { target c++2a } }
+
+// PR c++/93729
+
+struct B
+{
+  int a:4;
+  int b:4;
+};
+
+template
+concept c1
+  = requires(T x, void(f)(int &)) { f(x.a); }; // { dg-bogus "cannot bind" }
+
+static_assert(!c1);
-- 
2.25.1.460.g2f268890c2

[PATCH] c++: Fix pretty printing of TYPENAME_TYPEs

[Patrick Palka]

I noticed that in some concepts diagnostic messages, we were printing typename
types incorrectly, e.g. printing remove_reference_t as

  typename remove_reference::remove_reference_t

instead of

  typename remove_reference::type.

Fixed this by looking at TYPENAME_TYPE_FULLNAME instead of TYPE_NAME, which is
consistent with how dump_typename in error.c does it.

Does this look OK to commit after testing?

gcc/cp/ChangeLog:

* cxx-pretty-print.c (cxx_pretty_printer::simple_type_specifier)
[TYPENAME_TYPE]: Print the TYPENAME_TYPE_FULLNAME instead of the
TYPE_NAME.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic4.C: New test.
---
 gcc/cp/cxx-pretty-print.c   |  2 +-
 gcc/testsuite/g++.dg/concepts/diagnostic4.C | 18 ++
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic4.C

diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 397bdbfa234..100154e400f 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -1360,7 +1360,7 @@ cxx_pretty_printer::simple_type_specifier (tree t)
 case TYPENAME_TYPE:
   pp_cxx_ws_string (this, "typename");
   pp_cxx_nested_name_specifier (this, TYPE_CONTEXT (t));
-  pp_cxx_unqualified_id (this, TYPE_NAME (t));
+  pp_cxx_unqualified_id (this, TYPENAME_TYPE_FULLNAME (t));
   break;
 
 default:
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic4.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic4.C
new file mode 100644
index 000..677bc867634
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic4.C
@@ -0,0 +1,18 @@
+// { dg-do compile { target c++2a } }
+
+template
+  struct remove_reference
+  { using type = T; };
+
+template
+  using remove_reference_t = remove_reference::type;
+
+template
+  inline constexpr bool blah = false;
+
+template
+  requires blah>
+  // { dg-message "typename remove_reference::type" "" { target *-*-* } .-1 
}
+  void foo() { }
+
+void bar() { foo (); } // { dg-error "use of" }
-- 
2.25.1.460.g2f268890c2

Re: [PATCH][AArch64] Fix lane specifier syntax

[Richard Sandiford]

Wilco Dijkstra  writes:
> The syntax for lane specifiers uses a vector element rather than a vector:
>
> fmlsv0.2s, v1.2s, v1.s[1]  // rather than v1.2s[2]
>
> Fix all the lane specifiers to use Vetype which uses the correct element type.
>
> Regress pass.

OK, thanks.

Richard

Re: [PATCH][AArch64] Use intrinsics for widening multiplies (PR91598)

[Richard Sandiford]

> +;; vmlal_lane_s16 intrinsics
> +(define_insn "aarch64_vec_mlal_lane"
> +  [(set (match_operand: 0 "register_operand" "=w")
> + (plus: (match_operand: 1 "register_operand" "0")
> +   (mult:
> + (ANY_EXTEND:
> +   (match_operand: 2 "register_operand" "w"))
> + (ANY_EXTEND:
> +   (vec_duplicate:
> + (vec_select:
> +   (match_operand:VDQHS 3 "register_operand" "")
> +   (parallel [(match_operand:SI 4 "immediate_operand" 
> "i")])))]
> +  "TARGET_SIMD"
> +  {
> +operands[4] = aarch64_endian_lane_rtx (mode, INTVAL (operands[4]));
> +return "mlal\\t%0., %2., %3.[%4]";
> +  }
> +  [(set_attr "type" "neon_mla__scalar_long")]
> +)
> +

The canonical order is to have the (mult ...) first and the register
operand second.  (No need to change the operand numbering though,
just swapping them as-is should be fine.)

> diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
> index 
> ec1b92c5379f7c33446d0ac3556f6358fb7433d3..2f4b553a9a433773b222ce9f0bede3630ff0624c
>  100644
> --- a/gcc/config/aarch64/iterators.md
> +++ b/gcc/config/aarch64/iterators.md
> @@ -980,6 +980,13 @@ (define_mode_attr Vtype [(V8QI "8b") (V16QI "16b")
>(V4SF "4s") (V2DF "2d")
>(V4HF "4h") (V8HF "8h")])
> 
> +;; Map mode to type used in widening multiplies.
> +(define_mode_attr Vtype2 [(V4HI "4h") (V8HI "4h") (V2SI "2s") (V4SI "2s")])

How about Vcondtype, to make it clearer that it's the Vtype associated
with VCOND?

OK with those changes, thanks.

Richard

Re: [PATCH] Restore alignment in rs6000 target.

[Segher Boessenkool]

On Fri, Mar 06, 2020 at 02:07:15PM +0100, Martin Liška wrote:
> After r9-1623-gc518c1025b435e1c593a745036fc9b8ed04c5819 the code was 
> changed to:
> 
> - if (align_jumps_max_skip <= 0)
> -   align_jumps_max_skip = 15;
> - if (align_loops_max_skip <= 0)
> -   align_loops_max_skip = 15;
> +
> + if (flag_align_jumps && !str_align_jumps)
> +   str_align_jumps = "16";
> + if (flag_align_loops && !str_align_loops)
> +   str_align_loops = "16";
> 
> which for situation where align_* was 0 caused that max_skip didn't play 
> any role.
> My code wrongly changed that to str_align_jumps, which is now the was which 
> includes
> both alignment (and max skip). The hunk should not be here.

Do you have a testsuite test as well?  Or, how else was this checked?

>   PR target/93800
>   * config/rs6000/rs6000.c (rs6000_option_override_internal):
>   Remove set of str_align_loops and str_align_jumps as these
>   should be set in previous 2 conditions in the function.

Okay for trunk, maybe with an added test.  Thanks!


Segher

[COMMITTED] rs6000: Correct logic to disable NO_SUM_IN_TOC and NO_FP_IN_TOC [PR94065]

[David Edelsohn]

aix61.h, aix71.h and aix72.h intends to prevent SUM_IN_TOC and FP_IN_TOC
when cmodel=large.  This patch defines the variables associated with the
target options to 1 to _enable_ NO_SUM_IN_TOC and enable NO_FP_IN_TOC.

Bootstrapped on powerpc-ibm-aix7.2.0.0

PR target/94065
* config/rs6000/aix61.h (TARGET_NO_SUM_IN_TOC): Set to 1 for
cmodel=large.
(TARGET_NO_FP_IN_TOC): Same.
* config/rs6000/aix71.h: Same.
* config/rs6000/aix72.h: Same.


0001-rs6000-Correct-logic-to-disable-NO_SUM_IN_TOC-and-NO.patch
Description: Binary data

[PATCH][AArch64][SVE] Add missing movprfx attribute to some ternary arithmetic patterns

[Kyrill Tkachov]

Hi all,

The two affected SVE2 patterns in this patch output a movprfx'ed 
instruction in their second alternative
but don't set the "movprfx" attribute, which will result in the wrong 
instruction length being assumed by the midend.


This patch fixes that in the same way as the other SVE patterns in the 
backend.


Bootstrapped and tested on aarch64-none-linux-gnu.
Committing to trunk.

Thanks,
Kyrill

2020-03-06  Kyrylo Tkachov  

    * config/aarch64/aarch64-sve2.md (@aarch64_sve_:
    Specify movprfx attribute.
    (@aarch64_sve__lane_): Likewise.

commit b9694320e1bfbfc92255b30cc108a81a243770c6
Author: Kyrylo Tkachov 
Date:   Fri Mar 6 15:26:20 2020 +

[AArch64] Add movprfx attribute to a couple of SVE2 patterns

diff --git a/gcc/config/aarch64/aarch64-sve2.md b/gcc/config/aarch64/aarch64-sve2.md
index f82e60e25c7..e18b9fef16e 100644
--- a/gcc/config/aarch64/aarch64-sve2.md
+++ b/gcc/config/aarch64/aarch64-sve2.md
@@ -690,6 +690,7 @@
   "@
\t%0., %2., %3.
movprfx\t%0, %1\;\t%0., %2., %3."
+  [(set_attr "movprfx" "*,yes")]
 )
 
 (define_insn "@aarch64_sve__lane_"
@@ -706,6 +707,7 @@
   "@
\t%0., %2., %3.[%4]
movprfx\t%0, %1\;\t%0., %2., %3.[%4]"
+  [(set_attr "movprfx" "*,yes")]
 )
 
 ;; -

Re: [PATCH] generate EH info for volatile asm statements (PR inline-asm/93981)

[J.W. Jagersma]

On 2020-03-06 09:55, Richard Biener wrote:

On Thu, Mar 5, 2020 at 5:49 PM J.W. Jagersma  wrote:

diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 2a409dcaffe..8314db00922 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -2077,6 +2077,9 @@ lower_eh_constructs_2 (struct leh_state *state, 
gimple_stmt_iterator *gsi)
 DECL_GIMPLE_REG_P (tmp) = 1;
   gsi_insert_after (gsi, s, GSI_SAME_STMT);
 }
+  /* FALLTHRU */
+
+case GIMPLE_ASM:
/* Look for things that can throw exceptions, and record them.  */
if (state->cur_region && stmt_could_throw_p (cfun, stmt))
 {


The part you skip here for ASMs means that for ASM outputs we do
not represent their values correctly on EH edges (and we eventually
never will be able to since we don't know exactly at which point the
actual assembly throws).  So I think this "feature" needs to be documented
appropriately and eventually only ASMs without outputs made allowed
to throw?


So the code for assign stmts above would have to be duplicated and
modified so that each output gets assigned to a temporary. I'll see if
I can do that.
Personally I think it's reasonable to assume that if an asm throws, its
operands won't be modified (ie. it contains only a single instruction).
But there is no way to enforce this from the compiler, of course.


diff --git a/gcc/tree-into-ssa.c b/gcc/tree-into-ssa.c
index 6528acac31a..03bc1d52cfa 100644
--- a/gcc/tree-into-ssa.c
+++ b/gcc/tree-into-ssa.c
@@ -1415,7 +1415,43 @@ rewrite_stmt (gimple_stmt_iterator *si)
 if (tracked_var)
   {
 gimple *note = gimple_build_debug_bind (tracked_var, name, stmt);
-   gsi_insert_after (si, note, GSI_SAME_STMT);
+   /* If stmt ends the bb, insert the debug stmt on the single
+  non-EH edge from the stmt.  */
+   if (gsi_one_before_end_p (*si) && stmt_ends_bb_p (stmt))
+ {
+   basic_block bb = gsi_bb (*si);
+   edge_iterator ei;
+   edge e, ef = NULL;
+   FOR_EACH_EDGE (e, ei, bb->succs)
+ if (!(e->flags & EDGE_EH))


I think this needs to check for abnormal edges as well to cover
the case of

   i = setjmp ();

which means doing !(e->flags & EDGE_COMPLEX) and adjusting the
comment.


+   {
+ gcc_checking_assert (!ef);
+ ef = e;
+   }
+   /* If there are other predecessors to ef->dest, then
+  there must be PHI nodes for the modified
+  variable, and therefore there will be debug bind
+  stmts after the PHI nodes.  The debug bind notes
+  we'd insert would force the creation of a new
+  block (diverging codegen) and be redundant with
+  the post-PHI bind stmts, so don't add them.
+
+  As for the exit edge, there wouldn't be redundant
+  bind stmts, but there wouldn't be a PC to bind
+  them to either, so avoid diverging the CFG.  */
+   if (ef && single_pred_p (ef->dest)
+   && ef->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
+ {
+   /* If there were PHI nodes in the node, we'd
+  have to make sure the value we're binding
+  doesn't need rewriting.  But there shouldn't
+  be PHI nodes in a single-predecessor block,
+  so we just add the note.  */
+   gsi_insert_on_edge_immediate (ef, note);
+ }


it would be nice to elide building of the debug bind if we don't
end up inserting it.


Then this and the above would have to be changed in maybe_register_def
too? That is where I copied this code from.


Otherwise the patch looks reasonable.  It lacks a testcase though,
I think a target specific testcase can be constructed easily.


Non-call-exceptions need to be supported by the OS and/or runtime
library though. I rolled my own but I don't know on which platforms (if
any) this is available by default.

Re: [C++ Patch] PR 94034 ("[10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr")

[Marek Polacek]

On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:
> ... the patch ;)
> 
> Paolo.
> 

> Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by dump_expr"
> 
> A rather simple diagnostic issue where we failed to handle RESULT_DECL in
> dump_expr.
> 
> Tested x86_64-linux.
> 
>/cp
>PR c++/94034
>* error.c (dump_expr): Handle RESULT_DECL like the other *_DECL.
> 
>/testsuite
>PR c++/94034
>* g++.dg/cpp0x/pr94034.C: New.
> 

LGTM.  In fact, I had the same patch.

I think with this patch we print soemthing like " "
which is still kind of ugly, but improving that is out of scope for GCC 10.

Marek

[C++ Patch] PR 94034 ("[10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr")

[Paolo Carlini]

Hi,

in this apparently simple regression we end up producing garbled 
diagnostic because dump_expr (called via verify_constant) doesn't handle 
RESULT_DECL. I think it makes sense to add the tree code together with 
all the other *_DECL. Tested x86_64-linux.


Thanks, Paolo.

/

Re: [C++ Patch] PR 94034 ("[10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr")

[Paolo Carlini]

... the patch ;)

Paolo.

Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by dump_expr"

A rather simple diagnostic issue where we failed to handle RESULT_DECL in
dump_expr.

Tested x86_64-linux.

   /cp
   PR c++/94034
   * error.c (dump_expr): Handle RESULT_DECL like the other *_DECL.

   /testsuite
   PR c++/94034
   * g++.dg/cpp0x/pr94034.C: New.

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index cc51b6ffe13..c1392bcbb25 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -2102,6 +2102,7 @@ dump_expr (cxx_pretty_printer *pp, tree t, int flags)
 case OVERLOAD:
 case TYPE_DECL:
 case IDENTIFIER_NODE:
+case RESULT_DECL:
   dump_decl (pp, t, ((flags & ~(TFF_DECL_SPECIFIERS|TFF_RETURN_TYPE
 |TFF_TEMPLATE_HEADER))
 | TFF_NO_TEMPLATE_BINDINGS
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr94034.C 
b/gcc/testsuite/g++.dg/cpp0x/pr94034.C
new file mode 100644
index 000..0a828c1e263
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/pr94034.C
@@ -0,0 +1,10 @@
+// { dg-do compile { target c++11 } }
+
+struct A { A *ap = this; };
+constexpr A foo() {
+  return {};
+}
+void g() {
+  constexpr A a = foo();  // { dg-bogus "not supported by" }
+  // { dg-error "not a constant expression" "" { target c++11 } .-1 }
+}

[committed][rtl-optimization/93996] Avoid adding REG_NOTEs to anything other than INSNs

[Jeff Law]

As noted in PR93996, haifa-sched can try to add REG_NOTEs to a NOTE_INSN.  This
causes memory corruption which typically shows up as a fault in the GC system.

What happens is we have an insn before the EPILOGUE_BEG note.  That insn needs 
to
be split and the split form creates new basic blocks.

As a result we have a NOTE_INSN_BASIC_BLOCK right after the NOTE_EPILOGUE_BEG
while the code in haifa-sched.c assume the next insn after the NOTE_EPILOGUE_BEG
would be a real insn.

The primary patch is Andrews.  All I did was bullet proof it a bit by ensuring
that we don't go past next_tail and asserting that after skippiong the
NOTE_INSN_BASIC_BLOCK that we've got an INSN.

Bootstrapped and regression tested on x86 and a variety of other platforms
overnight in the tester.

Committing to the trunk.

Jeff
commit e6ce69cae5059dfd715edd4e26653c23baf4cb0f
Author: Andrew Pinski 
Date:   Fri Mar 6 08:34:01 2020 -0700

Avoid putting a REG_NOTE on anything other than an INSN in haifa-sched.c

PR rtl-optimization/93996
* haifa-sched.c (remove_notes): Be more careful when adding
REG_SAVE_NOTE.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 843648314ae..e38af8ed620 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2020-03-06  Andrew Pinski  
+   Jeff Law  
+
+   PR rtl-optimization/93996
+   * haifa-sched.c (remove_notes): Be more careful when adding
+   REG_SAVE_NOTE.
+
 2020-03-06  Delia Burduv  
 
* config/arm/arm_neon.h (vld2_bf16): New.
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 1d3de7b6a76..80687fb5359 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -4239,6 +4239,15 @@ remove_notes (rtx_insn *head, rtx_insn *tail)
  if (insn != tail)
{
  remove_insn (insn);
+ /* If an insn was split just before the EPILOGUE_BEG note and
+that split created new basic blocks, we could have a
+BASIC_BLOCK note here.  Safely advance over it in that case
+and assert that we land on a real insn.  */
+ if (NOTE_P (next)
+ && NOTE_KIND (next) == NOTE_INSN_BASIC_BLOCK
+ && next != next_tail)
+   next = NEXT_INSN (next);
+ gcc_assert (INSN_P (next));
  add_reg_note (next, REG_SAVE_NOTE,
GEN_INT (NOTE_INSN_EPILOGUE_BEG));
  break;

Re: [PATCH][committed] arc: Update tumaddsidi4 test.

[Jeff Law]

On Fri, 2020-03-06 at 16:39 +0200, Claudiu Zissulescu wrote:
> The test is using -O1 and, the macu instruction is generated by the
> combiner and not in the expand step. My previous "arc: Improve code
> gen for 64bit add/sub operations." is actually splitting the 64-bit
> add in the expand, leading to the impossibility to match the multiply
> and accumulate on 64 bit datum by the combiner, hence, the error. This
> patch is stepping up the optimization level which will generate the
> macu instruction at the expand time.
> 
> -xx-xx  Claudiu Zissulescu  
> 
>   * gcc.target/arc/tumaddsidi4.c: Step-up optimization level.
THanks.  I've started an off-cycle spin on the ARC toolchain:

http://gcc.gnu.org/jenkins/job/arc-elf/609/

Jeff

Re: [PATCH] [rs6000] Rewrite the declaration of a variable

[Segher Boessenkool]

Hi!

On Fri, Mar 06, 2020 at 10:20:08AM +0800, binbin wrote:
> OK, changed the code.  Bootstrap and regression tests were done on
> powerpc64le-linux-gnu (LE) with no regressions.  Thanks for your suggestion.

Yes, this is fine, approved for trunk (but add a changelog!)

And one triviality:

> --- a/gcc/config/rs6000/rs6000.h
> +++ b/gcc/config/rs6000/rs6000.h
> @@ -2494,6 +2494,9 @@ extern GTY(()) tree 
> builtin_mode_to_type[MAX_MACHINE_MODE][2];
>  extern GTY(()) tree altivec_builtin_mask_for_load;
>  
>  #ifndef USED_FOR_TARGET
> +
> +extern GTY(()) section *toc_section;

No empty line before this please?

Thanks!


Segher

[PATCH][AArch64] Use intrinsics for widening multiplies (PR91598)

[Wilco Dijkstra]

Inline assembler instructions don't have latency info and the scheduler does
not attempt to schedule them at all - it does not even honor latencies of
asm source operands. As a result, SIMD intrinsics which are implemented using
inline assembler perform very poorly, particularly on in-order cores.
Fix this by adding new patterns and intrinsics for widening multiplies, which
results in a 63% speedup for the example in the PR. This fixes the performance
regression.

Passes regress

ChangeLog:
2020-03-06  Wilco Dijkstra  

PR target/91598
* config/aarch64/aarch64-builtins.c (TYPES_TERNOPU_LANE): Add define.
* config/aarch64/aarch64-simd.md
(aarch64_vec_mult_lane): Add new insn for widening lane mul.
(aarch64_vec_mlal_lane): Likewise.
* config/aarch64/aarch64-simd-builtins.def: Add intrinsics.
* config/aarch64/arm_neon.h:
(vmlal_lane_s16): Expand using intrinsics rather than inline asm.
(vmlal_lane_u16): Likewise.
(vmlal_lane_s32): Likewise.
(vmlal_lane_u32): Likewise.
(vmlal_laneq_s16): Likewise.
(vmlal_laneq_u16): Likewise.
(vmlal_laneq_s32): Likewise.
(vmlal_laneq_u32): Likewise.
(vmull_lane_s16): Likewise.
(vmull_lane_u16): Likewise.
(vmull_lane_s32): Likewise.
(vmull_lane_u32): Likewise.
(vmull_laneq_s16): Likewise.
(vmull_laneq_u16): Likewise.
(vmull_laneq_s32): Likewise.
(vmull_laneq_u32): Likewise.
* config/aarch64/iterators.md (Vtype2): Add new iterator for lane mul.
(Qlane): Likewise.

---
diff --git a/gcc/config/aarch64/aarch64-builtins.c 
b/gcc/config/aarch64/aarch64-builtins.c
index 
9c9c6d86ae29fcbcf42e84408c5e94990fed8348..5744e68ea08722dcc387254f44408eb0fd3ffe6e
 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -175,6 +175,11 @@ aarch64_types_ternopu_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   qualifier_unsigned, qualifier_unsigned };
 #define TYPES_TERNOPU (aarch64_types_ternopu_qualifiers)
 static enum aarch64_type_qualifiers
+aarch64_types_ternopu_lane_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_unsigned, qualifier_unsigned,
+  qualifier_unsigned, qualifier_lane_index };
+#define TYPES_TERNOPU_LANE (aarch64_types_ternopu_lane_qualifiers)
+static enum aarch64_type_qualifiers
 aarch64_types_ternopu_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   = { qualifier_unsigned, qualifier_unsigned,
   qualifier_unsigned, qualifier_immediate };
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def 
b/gcc/config/aarch64/aarch64-simd-builtins.def
index 
d8bb96f8ed60648477f952ea6b88eae67cc9c921..e256e9c2086b48dfb1d95ce8391651ec9e86b696
 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -191,6 +191,15 @@
   BUILTIN_VQW (BINOP, vec_widen_smult_hi_, 10)
   BUILTIN_VQW (BINOPU, vec_widen_umult_hi_, 10)
 
+  BUILTIN_VD_HSI (TERNOP_LANE, vec_smult_lane_, 0)
+  BUILTIN_VD_HSI (QUADOP_LANE, vec_smlal_lane_, 0)
+  BUILTIN_VD_HSI (TERNOP_LANE, vec_smult_laneq_, 0)
+  BUILTIN_VD_HSI (QUADOP_LANE, vec_smlal_laneq_, 0)
+  BUILTIN_VD_HSI (TERNOPU_LANE, vec_umult_lane_, 0)
+  BUILTIN_VD_HSI (QUADOPU_LANE, vec_umlal_lane_, 0)
+  BUILTIN_VD_HSI (TERNOPU_LANE, vec_umult_laneq_, 0)
+  BUILTIN_VD_HSI (QUADOPU_LANE, vec_umlal_laneq_, 0)
+
   BUILTIN_VSD_HSI (BINOP, sqdmull, 0)
   BUILTIN_VSD_HSI (TERNOP_LANE, sqdmull_lane, 0)
   BUILTIN_VSD_HSI (TERNOP_LANE, sqdmull_laneq, 0)
diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index 
999d80667b7cf06040515958c747d8bca0728acc..ccf4e394c1f6aa7d0adb23cfcd8da1b6d40d7ebf
 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -1892,6 +1892,45 @@ (define_expand "vec_widen_mult_hi_"
  }
 )
 
+;; vmull_lane_s16 intrinsics
+(define_insn "aarch64_vec_mult_lane"
+  [(set (match_operand: 0 "register_operand" "=w")
+   (mult:
+ (ANY_EXTEND:
+   (match_operand: 1 "register_operand" "w"))
+ (ANY_EXTEND:
+   (vec_duplicate:
+ (vec_select:
+   (match_operand:VDQHS 2 "register_operand" "")
+   (parallel [(match_operand:SI 3 "immediate_operand" "i")]))]
+  "TARGET_SIMD"
+  {
+operands[3] = aarch64_endian_lane_rtx (mode, INTVAL (operands[3]));
+return "mull\\t%0., %1., %2.[%3]";
+  }
+  [(set_attr "type" "neon_mul__scalar_long")]
+)
+
+;; vmlal_lane_s16 intrinsics
+(define_insn "aarch64_vec_mlal_lane"
+  [(set (match_operand: 0 "register_operand" "=w")
+   (plus: (match_operand: 1 "register_operand" "0")
+ (mult:
+   (ANY_EXTEND:
+ (match_operand: 2 "register_operand" "w"))
+   (ANY_EXTEND:
+ (vec_duplicate:
+   (vec_select:
+ (match_operand:VDQHS 3 "register_operand" "")
+ (parallel [(match_operand:SI 4 "immediate_operand" 

[PATCH][AArch64] Fix lane specifier syntax

[Wilco Dijkstra]

The syntax for lane specifiers uses a vector element rather than a vector:

fmlsv0.2s, v1.2s, v1.s[1]  // rather than v1.2s[2]

Fix all the lane specifiers to use Vetype which uses the correct element type.

Regress pass.

ChangeLog:
2020-03-06  Wilco Dijkstra  

* aarch64/aarch64-simd.md (aarch64_mla_elt): Correct lane syntax.
(aarch64_mla_elt_): Likewise.
(aarch64_mls_elt): Likewise.
(aarch64_mls_elt_): Likewise.
(aarch64_fma4_elt): Likewise.
(aarch64_fma4_elt_): Likewise.
(aarch64_fma4_elt_to_64v2df): Likewise.
(aarch64_fnma4_elt): Likewise.
(aarch64_fnma4_elt_): Likewise.
(aarch64_fnma4_elt_to_64v2df): Likewise.

* gcc.target/aarch64/fmla_intrinsic_1.c: Check for correct lane syntax. 
* gcc.target/aarch64/fmls_intrinsic_1.c: Likewise.
* gcc.target/aarch64/mla_intrinsic_1.c: Likewise.
* gcc.target/aarch64/mls_intrinsic_1.c: Likewise.

---
diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index 
89aaf8c018e3340dd2d53fc2a6538d3d1220b103..999d80667b7cf06040515958c747d8bca0728acc
 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -1350,7 +1350,7 @@ (define_insn "*aarch64_mla_elt"
  "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (mode, INTVAL (operands[2]));
-return "mla\t%0., %3., %1.[%2]";
+return "mla\t%0., %3., %1.[%2]";
   }
   [(set_attr "type" "neon_mla__scalar")]
 )
@@ -1368,7 +1368,7 @@ (define_insn "*aarch64_mla_elt_"
  "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (mode, INTVAL 
(operands[2]));
-return "mla\t%0., %3., %1.[%2]";
+return "mla\t%0., %3., %1.[%2]";
   }
   [(set_attr "type" "neon_mla__scalar")]
 )
@@ -1408,7 +1408,7 @@ (define_insn "*aarch64_mls_elt"
  "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (mode, INTVAL (operands[2]));
-return "mls\t%0., %3., %1.[%2]";
+return "mls\t%0., %3., %1.[%2]";
   }
   [(set_attr "type" "neon_mla__scalar")]
 )
@@ -1426,7 +1426,7 @@ (define_insn "*aarch64_mls_elt_"
  "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (mode, INTVAL 
(operands[2]));
-return "mls\t%0., %3., %1.[%2]";
+return "mls\t%0., %3., %1.[%2]";
   }
   [(set_attr "type" "neon_mla__scalar")]
 )
@@ -2003,7 +2003,7 @@ (define_insn "*aarch64_fma4_elt"
   "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (mode, INTVAL (operands[2]));
-return "fmla\\t%0., %3., %1.[%2]";
+return "fmla\\t%0., %3., %1.[%2]";
   }
   [(set_attr "type" "neon_fp_mla__scalar")]
 )
@@ -2020,7 +2020,7 @@ (define_insn "*aarch64_fma4_elt_"
   "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (mode, INTVAL 
(operands[2]));
-return "fmla\\t%0., %3., %1.[%2]";
+return "fmla\\t%0., %3., %1.[%2]";
   }
   [(set_attr "type" "neon_fp_mla__scalar")]
 )
@@ -2048,7 +2048,7 @@ (define_insn "*aarch64_fma4_elt_to_64v2df"
   "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (V2DFmode, INTVAL (operands[2]));
-return "fmla\\t%0.2d, %3.2d, %1.2d[%2]";
+return "fmla\\t%0.2d, %3.2d, %1.d[%2]";
   }
   [(set_attr "type" "neon_fp_mla_d_scalar_q")]
 )
@@ -2077,7 +2077,7 @@ (define_insn "*aarch64_fnma4_elt"
   "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (mode, INTVAL (operands[2]));
-return "fmls\\t%0., %3., %1.[%2]";
+return "fmls\\t%0., %3., %1.[%2]";
   }
   [(set_attr "type" "neon_fp_mla__scalar")]
 )
@@ -2095,7 +2095,7 @@ (define_insn "*aarch64_fnma4_elt_"
   "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (mode, INTVAL 
(operands[2]));
-return "fmls\\t%0., %3., %1.[%2]";
+return "fmls\\t%0., %3., %1.[%2]";
   }
   [(set_attr "type" "neon_fp_mla__scalar")]
 )
@@ -2125,7 +2125,7 @@ (define_insn "*aarch64_fnma4_elt_to_64v2df"
   "TARGET_SIMD"
   {
 operands[2] = aarch64_endian_lane_rtx (V2DFmode, INTVAL (operands[2]));
-return "fmls\\t%0.2d, %3.2d, %1.2d[%2]";
+return "fmls\\t%0.2d, %3.2d, %1.d[%2]";
   }
   [(set_attr "type" "neon_fp_mla_d_scalar_q")]
 )
diff --git a/gcc/testsuite/gcc.target/aarch64/fmla_intrinsic_1.c 
b/gcc/testsuite/gcc.target/aarch64/fmla_intrinsic_1.c
index 
5b348827002dcfef1f589900a4cf5ff7ada26697..59ad41ed0471b17418c395f31fbe666b60ec3623
 100644
--- a/gcc/testsuite/gcc.target/aarch64/fmla_intrinsic_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/fmla_intrinsic_1.c
@@ -98,11 +98,11 @@ main (int argc, char **argv)
 
 /* vfma_laneq_f32.
vfma_lane_f32.  */
-/* { dg-final { scan-assembler-times "fmla\\tv\[0-9\]+\.2s, v\[0-9\]+\.2s, 
v\[0-9\]+\.2s\\\[\[0-9\]+\\\]" 2 } } */
+/* { dg-final { scan-assembler-times "fmla\\tv\[0-9\]+\.2s, v\[0-9\]+\.2s, 
v\[0-9\]+\.s\\\[\[0-9\]+\\\]" 2 } } */
 
 /* vfmaq_lane_f32.
vfmaq_laneq_f32.  */
-/* { dg-final { scan-assembler-times "fmla\\tv\[0-9\]+\.4s, v\[0-9\]+\.4s, 
v\[0-9\]+\.4s\\\[\[0-9\]+\\\]" 2 } } */
+/* { dg-final { scan-assembler-times "fmla\\tv\[0-9\]+\.4s, v\[0-9\]+\.4s, 

Re: [PATCH][gcc] libgccjit: introduce version entry points

[David Malcolm]

On Thu, 2020-03-05 at 21:34 -0500, David Malcolm wrote:
> On Thu, 2020-01-16 at 11:11 +, Andrea Corallo wrote:

Responding to my own ideas about thread-safety.

[...]

> My first thought here was that we should have a way to get all three
> at
> once, but it turns out that parse_basever does its own caching
> internally.
> 
> I don't think the current implementation is thread-safe;
> parse_basever
> has:
> 
>   static int s_major = -1, s_minor, s_patchlevel;
> 
>   if (s_major == -1)
> if (sscanf (BASEVER, "%d.%d.%d", _major, _minor,
> _patchlevel) != 3)
>   {
>   sscanf (BASEVER, "%d.%d", _major, _minor);
>   s_patchlevel = 0;
>   }
> 
> I think there's a race here: if two threads call parse_basever at the
> same time, it looks like:
>  (1) thread A could set s_major
>  (2) thread B could read s_major, find it's set
>  (3) thread B could read the uninitialized s_minor
>  (4) thread A sets s_minor
> and various similar issues.
> 
> One fix might be to add a version mutex to libgccjit.c; maybe
> something
> like the following (caveat: I haven't tried compiling this):
> 
> /* A mutex around the cached state in parse_basever.
>Ideally this would be within parse_basever, but the mutex is only
> needed
>by libgccjit.  */
> 
> static pthread_mutex_t version_mutex = PTHREAD_MUTEX_INITIALIZER;
> 
> struct version_info
> {
>   /* Default constructor.  Populate via parse_basever,
>  guarded by version_mutex.  */
>   version_info ()
>   {
> pthread_mutex_lock (_mutex);
> parse_basever (, , );
> pthread_mutex_unlock (_mutex);
>   }
>   
>   int major;
>   int minor;
>   int patchlevel;
> };
> 
> int
> gcc_jit_version_major (void)
> {
>   version_info vi;
>   return vi.major;
> }
> 
> int
> gcc_jit_version_minor (void)
> {
>   version_info vi;
>   return vi.minor;
> }
> 
> int
> gcc_jit_version_patchlevel (void)
> {
>   version_info vi;
>   return vi.patchlevel;
> }
> 
> Is adding a mutex a performance issue?  How frequently are these
> going
> to be called?  
> 
> Alternatively, maybe make these functions take a gcc_jit_context and
> cache the version information within the context? (since the API
> requires multithreaded programs to use their own locking if threads
> share a context)

In retrospect, I don't think this other approach would work: the state
is within parse_basever, so if two threads both determine they need to
access it at about the same time, then they will race.

> Or some kind of caching in libgccjit.c?  (perhaps simply by making
> the
> version_info instances above static?  my memory of C++ function-
> static
> init rules and what we can rely on on our minimal compiler is a
> little
> hazy)

I'd hoped that we could rely on static init being thread-safe, but in
general it isn't, according to:
https://eli.thegreenplace.net/2011/08/30/construction-of-function-static-variables-in-c-is-not-thread-safe
(apparently GCC 4 onwards makes it so, but other compilers don't)


>From what I can tell parse_basever is only called once for the regular
compiler use-case.  So maybe it makes sense to remove the caching from
it, and move the caching to libgccjit.c where we can have a mutex
(AFAIK none of the rest of the host code uses mutexes).

Or split out the actual parsing logic into a parse_basever_uncached
that libgccjit.c can use, and manage its own caching with a pthread
mutex like in my suggested version_info code above.

Thoughts?
Dave

[PATCH][committed] arc: Update tumaddsidi4 test.

[Claudiu Zissulescu]

The test is using -O1 and, the macu instruction is generated by the
combiner and not in the expand step. My previous "arc: Improve code
gen for 64bit add/sub operations." is actually splitting the 64-bit
add in the expand, leading to the impossibility to match the multiply
and accumulate on 64 bit datum by the combiner, hence, the error. This
patch is stepping up the optimization level which will generate the
macu instruction at the expand time.

-xx-xx  Claudiu Zissulescu  

* gcc.target/arc/tumaddsidi4.c: Step-up optimization level.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/testsuite/ChangeLog| 4 
 gcc/testsuite/gcc.target/arc/tumaddsidi4.c | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 13da5a8581d..ea9bc42ff75 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2020-03-06  Claudiu Zissulescu  
+
+   * gcc.target/arc/tumaddsidi4.c: Step-up optimization level.
+
 2020-03-06  Delia Burduv  
 
* gcc.target/arm/simd/bf16_vldn_1.c: New test.
diff --git a/gcc/testsuite/gcc.target/arc/tumaddsidi4.c 
b/gcc/testsuite/gcc.target/arc/tumaddsidi4.c
index d5dc2944d9b..0298a2456f5 100644
--- a/gcc/testsuite/gcc.target/arc/tumaddsidi4.c
+++ b/gcc/testsuite/gcc.target/arc/tumaddsidi4.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-mcpu=archs -O1 -mmpy-option=plus_dmpy -w" } */
+/* { dg-options "-mcpu=archs -O2 -mmpy-option=plus_dmpy -w" } */
 
 /* Check how we generate umaddsidi4 patterns.  */
 long a;
@@ -11,4 +11,4 @@ void fn1(void)
   b = d * (long long)c + a;
 }
 
-/* { dg-final { scan-assembler "macu 0,r" } } */
+/* { dg-final { scan-assembler "macu" } } */
-- 
2.24.1

Re: GCC 9.3 Status Report (2020-03-05)

[Richard Earnshaw]

On 05/03/2020 20:22, Jakub Jelinek wrote:

Status
==

The GCC 9 branch is now frozen for blocking regressions and documentation
fixes only, all changes to the branch require a RM approval now.


Quality Data


Priority  #   Change from last report
---   ---
P10
P2  226   -  17
P3   37   +   2
P4  168   -   1
P5   23
---   ---
Total P1-P3 263   -  15
Total   454   -  16


Previous Report
===

https://gcc.gnu.org/ml/gcc/2020-02/msg00238.html



I have the backport for PR91913 ready if you want it (fully 
bootstrapped), but it's only a P2, so can probably wait unless you're 
planning another RC.


R.

Re: [PATCH] libstdc++: Give ranges::empty() a concrete return type (PR 93978)

[Patrick Palka]

On Fri, 6 Mar 2020, Jonathan Wakely wrote:

> On 05/03/20 11:02 -0500, Patrick Palka wrote:
> > This works around PR 93978 by avoiding having to instantiate ranges::empty()
> > when checking the constraints of view_interface::operator bool().  When
> > ranges::empty() has an auto return type, then we must instantiate it in
> > order to
> > determine whether the requires expression { ranges::empty(_M_derived()); }
> > is
> > well-formed.  But this means instantiating view_interface::empty() and hence
> > view_interface::_M_derived(), all before we've yet deduced the return type
> > of
> > join_view::end().  (The reason view_interface::operator bool() is needed in
> > join_view::end() in the first place is because in this function we perform
> > direct initialization of join_view::_Sentinel from a join_view, and so we
> > try to
> > find a conversion sequence from the latter to the former that goes through
> > this
> > conversion operator.)
> > 
> > Giving ranges::empty() a concrete return type of bool should be safe
> > according
> > to [ranges.prim.empty]/4 which says "whenever ranges::empty(E) is a valid
> 
> N.B. [range.prim.empty] in the commit log here please, not "ranges."

Fixed.

> 
> > expression, it has type bool."
> 
> Right, I don't know why I didn't make it just return bool anyway.
> Probably because I was copy _Begin for each of those other
> range access CPOs.
> 
> This way we've become aware of the danger of using deduced return
> types, and so can audit the other cases.

It seems that all of the other range access CPOs (since they are each
defined with a deduced return type) have some form of this issue: using
them as an unevaluated operand may cause more templates to get
instantiated than when using the corresponding expression-equivalent
expression.  In this specific case, checking the constraint

requires { ranges::empty(_M_derived()); }

requires instantiating the body of _Derived::empty(), whereas checking
the expression-equivalent constraint

requires { _M_derived().empty(); }

doesn't.  If this discrepancy is important, then it seems we need to
avoid using a deduced return type in the definitions of each of these
CPOs.  Is this worth doing?

> 
> > This fixes the test case in PR 93978 when compiling without -Wall, but with
> > -Wall
> > the test case still fails due to the issue described in PR c++/94038, I
> > think.
> > I still don't quite understand why the test case doesn't fail without -O.
> 
> Still a small improvement.
> 
> OK for master, thanks.

Re: [PATCH] c++: Fix ABI issue with alignas on armv7hl [PR94050]

[Jakub Jelinek]

On Thu, Mar 05, 2020 at 02:40:16PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-linux, ok for trunk?  I verified the
> fix on the attached testcase using a --target=armv7hl-linux-gnueabi cross,
> but haven't actually run the testsuite.

FYI, also successfully bootstrapped/regtested on armv7hl-linux-gnueabi
(--enable-checking=release though).

>   PR c++/94050 - ABI issue with alignas on armv7hl.
>   * class.c (layout_class_type): Don't replace a class's
>   CLASSTYPE_AS_BASE if it is CLASSTYPE_USER_ALIGN.
> 
>   * g++.dg/abi/align3.C: New test.

Jakub

[PATCH] Restore alignment in rs6000 target.

[Martin Liška]

Hi.

After r9-1623-gc518c1025b435e1c593a745036fc9b8ed04c5819 the code was changed to:

- if (align_jumps_max_skip <= 0)
-   align_jumps_max_skip = 15;
- if (align_loops_max_skip <= 0)
-   align_loops_max_skip = 15;
+
+ if (flag_align_jumps && !str_align_jumps)
+   str_align_jumps = "16";
+ if (flag_align_loops && !str_align_loops)
+   str_align_loops = "16";

which for situation where align_* was 0 caused that max_skip didn't play any 
role.
My code wrongly changed that to str_align_jumps, which is now the was which 
includes
both alignment (and max skip). The hunk should not be here.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-03-05  Martin Liska  

PR target/93800
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Remove set of str_align_loops and str_align_jumps as these
should be set in previous 2 conditions in the function.
---
 gcc/config/rs6000/rs6000.c | 5 -
 1 file changed, 5 deletions(-)


diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ecbf7ae0c59..848a4ef451e 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4363,11 +4363,6 @@ rs6000_option_override_internal (bool global_init_p)
 		  str_align_loops = "16";
 		}
 	}
-
-	  if (flag_align_jumps && !str_align_jumps)
-	str_align_jumps = "16";
-	  if (flag_align_loops && !str_align_loops)
-	str_align_loops = "16";
 	}
 
   /* Arrange to save and restore machine status around nested functions.  */

[PATCH] c++: Readd [LR]ROTATE_EXPR support to constexpr.c [PR94067]

[Jakub Jelinek]

Hi!

Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c

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

2020-03-06  Jakub Jelinek  

PR c++/94067
Revert
2019-10-11  Paolo Carlini  

* constexpr.c (cxx_eval_constant_expression): Do not handle
RROTATE_EXPR and LROTATE_EXPR.

* g++.dg/warn/Wconversion-pr94067.C: New test.

--- gcc/cp/constexpr.c.jj   2020-03-05 07:58:02.578137680 +0100
+++ gcc/cp/constexpr.c  2020-03-06 11:55:27.126682726 +0100
@@ -5730,6 +5730,8 @@ cxx_eval_constant_expression (const cons
 case MAX_EXPR:
 case LSHIFT_EXPR:
 case RSHIFT_EXPR:
+case LROTATE_EXPR:
+case RROTATE_EXPR:
 case BIT_IOR_EXPR:
 case BIT_XOR_EXPR:
 case BIT_AND_EXPR:
@@ -7853,6 +7855,8 @@ potential_constant_expression_1 (tree t,
 case MAX_EXPR:
 case LSHIFT_EXPR:
 case RSHIFT_EXPR:
+case LROTATE_EXPR:
+case RROTATE_EXPR:
 case BIT_IOR_EXPR:
 case BIT_XOR_EXPR:
 case BIT_AND_EXPR:
--- gcc/testsuite/g++.dg/warn/Wconversion-pr94067.C.jj  2020-03-06 
11:57:08.335191087 +0100
+++ gcc/testsuite/g++.dg/warn/Wconversion-pr94067.C 2020-03-06 
11:59:55.843722307 +0100
@@ -0,0 +1,9 @@
+// PR c++/94067
+// { dg-do compile }
+// { dg-options "-Wconversion" }
+
+static inline unsigned short
+swap (unsigned short x)
+{
+  return (x >> 8) | static_cast(x << 8);
+}

Jakub

Re: GCC 9.3 Status Report (2020-03-05)

[Jakub Jelinek]

On Fri, Mar 06, 2020 at 12:35:09PM +, Jonathan Wakely wrote:
> > The GCC 9 branch is now frozen for blocking regressions and documentation
> > fixes only, all changes to the branch require a RM approval now.
> 
> I'd also like to backport this one:
> https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00360.html
> 
> It only affects the testsuite (and only for *-*-mingw* targets), but
> ensures we don't get FAILs caused by the tests hitting a different
> bug.
> 
> Fixing that other bug will happen for 9.4, but we can avoid the
> failures with a small tweak to the tests, so they still verify what
> was intended. On the other hand, some failing tests won't actually
> hurt the quality of the 9.3 release, so it's not important.

I think this isn't urgent enough and can wait for 9.4.  We don't guarantee
zero FAILs...

Jakub

Re: GCC 9.3 Status Report (2020-03-05)

[Jonathan Wakely]

On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote:
>
> Status
> ==
>
> The GCC 9 branch is now frozen for blocking regressions and documentation
> fixes only, all changes to the branch require a RM approval now.

I'd also like to backport this one:
https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00360.html

It only affects the testsuite (and only for *-*-mingw* targets), but
ensures we don't get FAILs caused by the tests hitting a different
bug.

Fixing that other bug will happen for 9.4, but we can avoid the
failures with a small tweak to the tests, so they still verify what
was intended. On the other hand, some failing tests won't actually
hurt the quality of the 9.3 release, so it's not important.

Re: GCC 9.3 Status Report (2020-03-05)

[Jonathan Wakely]

On Fri, 6 Mar 2020 at 12:18, Jakub Jelinek wrote:
>
> On Fri, Mar 06, 2020 at 12:12:09PM +, Jonathan Wakely wrote:
> > On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote:
> > >
> > > Status
> > > ==
> > >
> > > The GCC 9 branch is now frozen for blocking regressions and documentation
> > > fixes only, all changes to the branch require a RM approval now.
> >
> > I'd like to backport 
> > https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00361.html

Oops, that commit has the wrong PR number. It's for 94069.

> > The only affected target I'm aware of is darwin8, which is an old
> > release. I could wait for after the 9.3 release, but it seems safe to
> > do now.
>
> Ok.
> Seems to be of the wouldn't compile at all without the fix category, I think

Right.

> we don't need another rc for this.

OK, I'll do the backport today. Thanks.

Re: [committed] libstdc++: Fix call to __glibcxx_rwlock_init (PR 93244)

[Jonathan Wakely]

On 06/03/20 12:04 +, Jonathan Wakely wrote:

When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a
wrapper around pthread_wrlock_init, but the wrapper only takes one
argument and we try to call it with two.

This went unnnoticed on most targets because they do define the
PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on
darwin8.

PR libstdc++/93244
* include/std/shared_mutex [!PTHREAD_RWLOCK_INITIALIZER]
(__shared_mutex_pthread::__shared_mutex_pthread()): Remove incorrect
second argument to __glibcxx_rwlock_init.
* testsuite/30_threads/shared_timed_mutex/94069.cc: New test.

Tested powerpc64le-linux, committed to master.

This also needs to be backported to gcc-9 but I'll let the release
managers decide whether that's before or after the upcoming 9.3
release.





commit b0815713a32c5cc062bd41fa75dac4d4408215fb
Author: Jonathan Wakely 
Date:   Fri Mar 6 12:03:17 2020 +

   libstdc++: Fix call to __glibcxx_rwlock_init (PR 93244)

   When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a
   wrapper around pthread_wrlock_init, but the wrapper only takes one
   argument and we try to call it with two.

   This went unnnoticed on most targets because they do define the
   PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on
   darwin8.

   PR libstdc++/93244


Oops, the correct PR number is 94069. Fixed in the ChangeLog now.

Re: GCC 9.3 Status Report (2020-03-05)

[Jakub Jelinek]

On Fri, Mar 06, 2020 at 12:12:09PM +, Jonathan Wakely wrote:
> On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote:
> >
> > Status
> > ==
> >
> > The GCC 9 branch is now frozen for blocking regressions and documentation
> > fixes only, all changes to the branch require a RM approval now.
> 
> I'd like to backport https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00361.html
> 
> The only affected target I'm aware of is darwin8, which is an old
> release. I could wait for after the 9.3 release, but it seems safe to
> do now.

Ok.
Seems to be of the wouldn't compile at all without the fix category, I think
we don't need another rc for this.

Jakub

Re: GCC 9.3 Status Report (2020-03-05)

[Jonathan Wakely]

On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote:
>
> Status
> ==
>
> The GCC 9 branch is now frozen for blocking regressions and documentation
> fixes only, all changes to the branch require a RM approval now.

I'd like to backport https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00361.html

The only affected target I'm aware of is darwin8, which is an old
release. I could wait for after the 9.3 release, but it seems safe to
do now.

[committed] libstdc++: Fix call to __glibcxx_rwlock_init (PR 93244)

[Jonathan Wakely]

When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a
wrapper around pthread_wrlock_init, but the wrapper only takes one
argument and we try to call it with two.

This went unnnoticed on most targets because they do define the
PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on
darwin8.

PR libstdc++/93244
* include/std/shared_mutex [!PTHREAD_RWLOCK_INITIALIZER]
(__shared_mutex_pthread::__shared_mutex_pthread()): Remove incorrect
second argument to __glibcxx_rwlock_init.
* testsuite/30_threads/shared_timed_mutex/94069.cc: New test.

Tested powerpc64le-linux, committed to master.

This also needs to be backported to gcc-9 but I'll let the release
managers decide whether that's before or after the upcoming 9.3
release.


commit b0815713a32c5cc062bd41fa75dac4d4408215fb
Author: Jonathan Wakely 
Date:   Fri Mar 6 12:03:17 2020 +

libstdc++: Fix call to __glibcxx_rwlock_init (PR 93244)

When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a
wrapper around pthread_wrlock_init, but the wrapper only takes one
argument and we try to call it with two.

This went unnnoticed on most targets because they do define the
PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on
darwin8.

PR libstdc++/93244
* include/std/shared_mutex [!PTHREAD_RWLOCK_INITIALIZER]
(__shared_mutex_pthread::__shared_mutex_pthread()): Remove incorrect
second argument to __glibcxx_rwlock_init.
* testsuite/30_threads/shared_timed_mutex/94069.cc: New test.

diff --git a/libstdc++-v3/include/std/shared_mutex 
b/libstdc++-v3/include/std/shared_mutex
index 1d0ce673a76..9b597e76299 100644
--- a/libstdc++-v3/include/std/shared_mutex
+++ b/libstdc++-v3/include/std/shared_mutex
@@ -160,7 +160,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   public:
 __shared_mutex_pthread()
 {
-  int __ret = __glibcxx_rwlock_init(&_M_rwlock, NULL);
+  int __ret = __glibcxx_rwlock_init(&_M_rwlock);
   if (__ret == ENOMEM)
__throw_bad_alloc();
   else if (__ret == EAGAIN)
diff --git a/libstdc++-v3/testsuite/30_threads/shared_timed_mutex/94069.cc 
b/libstdc++-v3/testsuite/30_threads/shared_timed_mutex/94069.cc
new file mode 100644
index 000..6e5cf5f0c6e
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/shared_timed_mutex/94069.cc
@@ -0,0 +1,28 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do compile }
+// { dg-options "-pthread"  }
+// { dg-require-effective-target c++14 }
+// { dg-require-effective-target pthread }
+// { dg-require-gthreads "" }
+//
+#include 
+// This is probably undefined, but we do it to simulate a Pthreads target
+// that doesn't define the macro:
+#undef PTHREAD_RWLOCK_INITIALIZER
+#include 

[committed] libstdc++: Fix failing filesystem::path tests (PR 93244)

[Jonathan Wakely]

The checks for PR 93244 don't actually pass on Windows (which is the
target where the bug is present) because of a different bug, PR 94063.

This adjusts the tests to not be affected by 94063 so that they verify
that 93244 was fixed.

PR libstdc++/93244
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Adjust
test to not fail due to PR 94063.
* testsuite/27_io/filesystem/path/generic/utf.cc: Likewise.
* testsuite/27_io/filesystem/path/generic/wchar_t.cc: Likewise.

Tested x86_64-w64-mingw, committed to master.


commit 180eeeaeb200a07f7f24e1f203cd026880ff861c
Author: Jonathan Wakely 
Date:   Fri Mar 6 11:27:34 2020 +

libstdc++: Fix failing filesystem::path tests (PR 93244)

The checks for PR 93244 don't actually pass on Windows (which is the
target where the bug is present) because of a different bug, PR 94063.

This adjusts the tests to not be affected by 94063 so that they verify
that 93244 was fixed.

PR libstdc++/93244
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Adjust
test to not fail due to PR 94063.
* testsuite/27_io/filesystem/path/generic/utf.cc: Likewise.
* testsuite/27_io/filesystem/path/generic/wchar_t.cc: Likewise.

diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/generic_string.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/generic_string.cc
index 677f5f5d1c4..5caf079ed9b 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/generic_string.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/generic_string.cc
@@ -49,11 +49,12 @@ test01()
 void
 test02()
 {
-  // PR libstdc++/93244
-  path p("C:");
-  p += path::preferred_separator;
-  p += "foo/bar";
-  VERIFY( p.generic_string() == "C:/foo/bar" );
+  if constexpr (path::preferred_separator == L'\\')
+  {
+// PR libstdc++/93244
+VERIFY( path("C:\\foo\\bar").generic_string() == "C:/foo/bar" );
+VERIFY( path("C://foo//bar").generic_string() == "C:/foo/bar" );
+  }
 }
 
 int
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/utf.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/utf.cc
index 9a2f579ebab..52afdb4497b 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/utf.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/utf.cc
@@ -49,11 +49,12 @@ test01()
 void
 test02()
 {
-  // PR libstdc++/93244
-  path p("C:");
-  p += path::preferred_separator;
-  p += "foo/bar";
-  VERIFY( p.generic_u32string() == U"C:/foo/bar" );
+  if constexpr (path::preferred_separator == L'\\')
+  {
+// PR libstdc++/93244
+VERIFY( path("C:\\foo\\bar").generic_u32string() == U"C:/foo/bar" );
+VERIFY( path("C://foo//bar").generic_u32string() == U"C:/foo/bar" );
+  }
 }
 
 int
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/wchar_t.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/wchar_t.cc
index 5dacedc7de4..7bb2f643043 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/wchar_t.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/wchar_t.cc
@@ -49,11 +49,12 @@ test01()
 void
 test02()
 {
-  // PR libstdc++/93244
-  path p("C:");
-  p += path::preferred_separator;
-  p += "foo/bar";
-  VERIFY( p.generic_wstring() == L"C:/foo/bar" );
+  if constexpr (path::preferred_separator == L'\\')
+  {
+// PR libstdc++/93244
+VERIFY( path("C:\\foo\\bar").generic_wstring() == L"C:/foo/bar" );
+VERIFY( path("C://foo//bar").generic_wstring() == L"C:/foo/bar" );
+  }
 }
 
 int

Re: ACLE intrinsics: BFloat16 load intrinsics for AArch32

[Kyrill Tkachov]

Hi Delia,

On 3/5/20 4:38 PM, Delia Burduv wrote:

Hi,

This is the latest version of the patch. I am forcing -mfloat-abi=hard 
because the code generated is slightly differently depending on the 
float-abi used.



Thanks, I've pushed it with an updated ChangeLog.

2020-03-06  Delia Burduv  

    * config/arm/arm_neon.h (vld2_bf16): New.
    (vld2q_bf16): New.
    (vld3_bf16): New.
    (vld3q_bf16): New.
    (vld4_bf16): New.
    (vld4q_bf16): New.
    (vld2_dup_bf16): New.
    (vld2q_dup_bf16): New.
    (vld3_dup_bf16): New.
    (vld3q_dup_bf16): New.
    (vld4_dup_bf16): New.
    (vld4q_dup_bf16): New.
    * config/arm/arm_neon_builtins.def
    (vld2): Changed to VAR13 and added v4bf, v8bf
    (vld2_dup): Changed to VAR8 and added v4bf, v8bf
    (vld3): Changed to VAR13 and added v4bf, v8bf
    (vld3_dup): Changed to VAR8 and added v4bf, v8bf
    (vld4): Changed to VAR13 and added v4bf, v8bf
    (vld4_dup): Changed to VAR8 and added v4bf, v8bf
    * config/arm/iterators.md (VDXBF2): New iterator.
    *config/arm/neon.md (neon_vld2): Use new iterators.
    (neon_vld2_dup): Likewise.
    (neon_vld3qa): Likewise.
    (neon_vld3qb): Likewise.
    (neon_vld3_dup): Likewise.
    (neon_vld4): Likewise.
    (neon_vld4qa): Likewise.
    (neon_vld4qb): Likewise.
    (neon_vld4_dup): Likewise.
    (neon_vld2_dupv8bf): New.
    (neon_vld3_dupv8bf): Likewise.
    (neon_vld4_dupv8bf): Likewise.

Kyrill




Thanks,
Delia

On 3/4/20 5:20 PM, Kyrill Tkachov wrote:

Hi Delia,

On 3/4/20 2:05 PM, Delia Burduv wrote:

Hi,

The previous version of this patch shared part of its code with the
store intrinsics patch
(https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00145.html) so I removed
any duplicated code. This patch now depends on the previously mentioned
store intrinsics patch.

Here is the latest version and the updated ChangeLog.

gcc/ChangeLog:

2019-03-04  Delia Burduv  

    * config/arm/arm_neon.h (bfloat16_t): New typedef.
 (vld2_bf16): New.
    (vld2q_bf16): New.
    (vld3_bf16): New.
    (vld3q_bf16): New.
    (vld4_bf16): New.
    (vld4q_bf16): New.
    (vld2_dup_bf16): New.
    (vld2q_dup_bf16): New.
 (vld3_dup_bf16): New.
    (vld3q_dup_bf16): New.
    (vld4_dup_bf16): New.
    (vld4q_dup_bf16): New.
 * config/arm/arm_neon_builtins.def
 (vld2): Changed to VAR13 and added v4bf, v8bf
 (vld2_dup): Changed to VAR8 and added v4bf, v8bf
 (vld3): Changed to VAR13 and added v4bf, v8bf
 (vld3_dup): Changed to VAR8 and added v4bf, v8bf
 (vld4): Changed to VAR13 and added v4bf, v8bf
 (vld4_dup): Changed to VAR8 and added v4bf, v8bf
 * config/arm/iterators.md (VDXBF): New iterator.
 (VQ2BF): New iterator.
 *config/arm/neon.md (vld2): Used new iterators.
 (vld2_dup): Used new iterators.
 (vld2_dupv8bf): New.
 (vst3): Used new iterators.
 (vst3qa): Used new iterators.
 (vst3qb): Used new iterators.
 (vld3_dup): Used new iterators.
 (vld3_dupv8bf): New.
 (vst4): Used new iterators.
 (vst4qa): Used new iterators.
 (vst4qb): Used new iterators.
 (vld4_dup): Used new iterators.
 (vld4_dupv8bf): New.


gcc/testsuite/ChangeLog:

2019-03-04  Delia Burduv  

    * gcc.target/arm/simd/bf16_vldn_1.c: New test.

Thanks,
Delia

On 2/19/20 5:25 PM, Delia Burduv wrote:
>
> Hi,
>
> Here is the latest version of the patch. It just has some minor
> formatting changes that were brought up by Richard Sandiford in the
> AArch64 patches
>
> Thanks,
> Delia
>
> On 1/22/20 5:31 PM, Delia Burduv wrote:
>> Ping.
>>
>> I will change the tests to use the exact input and output 
registers as

>> Richard Sandiford suggested for the AArch64 patches.
>>
>> On 12/20/19 6:48 PM, Delia Burduv wrote:
>>> This patch adds the ARMv8.6 ACLE BFloat16 load intrinsics
>>> vld{q}_bf16 as part of the BFloat16 extension.
>>> 
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics) 


>>>
>>> The intrinsics are declared in arm_neon.h .
>>> A new test is added to check assembler output.
>>>
>>> This patch depends on the Arm back-end patche.
>>> (https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html)
>>>
>>> Tested for regression on arm-none-eabi and armeb-none-eabi. I don't
>>> have commit rights, so if this is ok can someone please commit 
it for

>>> me?
>>>
>>> gcc/ChangeLog:
>>>
>>> 2019-11-14  Delia Burduv 
>>>
>>>  * config/arm/arm_neon.h (bfloat16_t): New typedef.
>>>  (bfloat16x4x2_t): New typedef.
>>>  (bfloat16x8x2_t): New typedef.
>>>  (bfloat16x4x3_t): New typedef.
>>>  (bfloat16x8x3_t): New typedef.
>>>  (bfloat16x4x4_t): New typedef.
>>>  (bfloat16x8x4_t): New typedef.
>>>  (vld2_bf16): New.
>>>  (vld2q_bf16): New.
>>>  (vld3_bf16): New.
>>>  (vld3q_bf16): New.
>>>  (vld4_bf16): New.
>>>  (vld4q_bf16): New.
>>> 

Re: ACLE intrinsics: BFloat16 store (vst{q}_bf16) intrinsics for AArch32

[Kyrill Tkachov]

Hi Delia,

On 3/5/20 3:53 PM, Delia Burduv wrote:

Hi,

This is the latest version of the patch. I am forcing -mfloat-abi=hard 
because the register allocator behaves differently depending on the 
float-abi used.


Thanks, I've pushed it to master with an updated ChangeLog reflecting 
the recent changes. In the future, please send an updated ChangeLog 
whenever something changes in the patches.


Thanks again!

Kyrill


2020-03-06  Delia Burduv  

    * config/arm/arm_neon.h (bfloat16x4x2_t): New typedef.
    (bfloat16x8x2_t): New typedef.
    (bfloat16x4x3_t): New typedef.
    (bfloat16x8x3_t): New typedef.
    (bfloat16x4x4_t): New typedef.
    (bfloat16x8x4_t): New typedef.
    (vst2_bf16): New.
    (vst2q_bf16): New.
    (vst3_bf16): New.
    (vst3q_bf16): New.
    (vst4_bf16): New.
    (vst4q_bf16): New.
    * config/arm/arm-builtins.c (v2bf_UP): Define.
    (VAR13): New.
    (arm_init_simd_builtin_types): Init Bfloat16x2_t eltype.
    * config/arm/arm-modes.def (V2BF): New mode.
    * config/arm/arm-simd-builtin-types.def
    (Bfloat16x2_t): New entry.
    * config/arm/arm_neon_builtins.def
    (vst2): Changed to VAR13 and added v4bf, v8bf
    (vst3): Changed to VAR13 and added v4bf, v8bf
    (vst4): Changed to VAR13 and added v4bf, v8bf
    * config/arm/iterators.md (VDXBF): New iterator.
    (VQ2BF): New iterator.
    *config/arm/neon.md (neon_vst2): Used new iterators.
    (neon_vst2): Used new iterators.
    (neon_vst3): Used new iterators.
    (neon_vst3): Used new iterators.
    (neon_vst3qa): Used new iterators.
    (neon_vst3qb): Used new iterators.
    (neon_vst4): Used new iterators.
    (neon_vst4): Used new iterators.
    (neon_vst4qa): Used new iterators.
    (neon_vst4qb): Used new iterators.





Thanks,
Delia

On 3/4/20 5:20 PM, Kyrill Tkachov wrote:

Hi Delia,

On 3/3/20 5:23 PM, Delia Burduv wrote:

Hi,

I noticed that the patch doesn't apply cleanly. I fixed it and this 
is the latest version.


Thanks,
Delia

On 3/3/20 4:23 PM, Delia Burduv wrote:

Sorry, I forgot the attachment.

On 3/3/20 4:20 PM, Delia Burduv wrote:

Hi,

I made a mistake in the previous patch. This is the latest 
version. Please let me know if it is ok.


Thanks,
Delia

On 2/21/20 3:18 PM, Delia Burduv wrote:

Hi Kyrill,

The arm_bf16.h is only used for scalar operations. That is how 
the aarch64 versions are implemented too.


Thanks,
Delia

On 2/21/20 2:06 PM, Kyrill Tkachov wrote:

Hi Delia,

On 2/19/20 5:25 PM, Delia Burduv wrote:

Hi,

Here is the latest version of the patch. It just has some minor
formatting changes that were brought up by Richard Sandiford in 
the

AArch64 patches

Thanks,
Delia

On 1/22/20 5:29 PM, Delia Burduv wrote:
> Ping.
>
> I will change the tests to use the exact input and output 
registers as

> Richard Sandiford suggested for the AArch64 patches.
>
> On 12/20/19 6:46 PM, Delia Burduv wrote:
>> This patch adds the ARMv8.6 ACLE BFloat16 store intrinsics
>> vst{q}_bf16 as part of the BFloat16 extension.
>> 
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics) 


>>
>> The intrinsics are declared in arm_neon.h .
>> A new test is added to check assembler output.
>>
>> This patch depends on the Arm back-end patche.
>> (https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html)
>>
>> Tested for regression on arm-none-eabi and armeb-none-eabi. 
I don't
>> have commit rights, so if this is ok can someone please 
commit it for me?

>>
>> gcc/ChangeLog:
>>
>> 2019-11-14  Delia Burduv 
>>
>>  * config/arm/arm_neon.h (bfloat16_t): New typedef.
>>  (bfloat16x4x2_t): New typedef.
>>  (bfloat16x8x2_t): New typedef.
>>  (bfloat16x4x3_t): New typedef.
>>  (bfloat16x8x3_t): New typedef.
>>  (bfloat16x4x4_t): New typedef.
>>  (bfloat16x8x4_t): New typedef.
>>  (vst2_bf16): New.
>>  (vst2q_bf16): New.
>>  (vst3_bf16): New.
>>  (vst3q_bf16): New.
>>  (vst4_bf16): New.
>>  (vst4q_bf16): New.
>>  * config/arm/arm-builtins.c (E_V2BFmode): New mode.
>>  (VAR13): New.
>>  (arm_simd_types[Bfloat16x2_t]):New type.
>>  * config/arm/arm-modes.def (V2BF): New mode.
>>  * config/arm/arm-simd-builtin-types.def
>>  (Bfloat16x2_t): New entry.
>>  * config/arm/arm_neon_builtins.def
>>  (vst2): Changed to VAR13 and added v4bf, v8bf
>>  (vst3): Changed to VAR13 and added v4bf, v8bf
>>  (vst4): Changed to VAR13 and added v4bf, v8bf
>>  * config/arm/iterators.md (VDXBF): New iterator.
>>  (VQ2BF): New iterator.
>>  (V_elem): Added V4BF, V8BF.
>>  (V_sz_elem): Added V4BF, V8BF.
>>  (V_mode_nunits): Added V4BF, V8BF.
>>  (q): Added V4BF, V8BF.
>>  *config/arm/neon.md (vst2): Used new iterators.
>>  (vst3): Used new iterators.
>>  (vst3qa): Used new iterators.
>>  (vst3qb): Used new iterators.
>>  (vst4): Used new iterators.
>>  

[committed] RISC-V: Fix testsuite regression due to recent IRA changes.

[Kito Cheng]

---
 gcc/testsuite/ChangeLog  | 4 
 gcc/testsuite/gcc.target/riscv/pr93304.c | 7 +++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 09d59730730..6c9206aeb27 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2020-03-06  Kito Cheng  
+
+   * gcc.target/riscv/pr93304.c: Update expected output and comment.
+
 2020-03-06  Delia Burduv  
 
* gcc.target/aarch64/advsimd-intrinsics/bfcvt-compile.c: New test.
diff --git a/gcc/testsuite/gcc.target/riscv/pr93304.c 
b/gcc/testsuite/gcc.target/riscv/pr93304.c
index f771e4859a9..248f205e0d2 100644
--- a/gcc/testsuite/gcc.target/riscv/pr93304.c
+++ b/gcc/testsuite/gcc.target/riscv/pr93304.c
@@ -13,7 +13,6 @@ foo (void)
 
 /* Register rename will try to use registers from the lower register
regradless of the REG_ALLOC_ORDER.
-   In theory, t0-t6 should not used in such small program if regrename
-   not executed incorrectly, because a5-a0 has higher priority in
-   REG_ALLOC_ORDER.  */
-/* { dg-final { scan-assembler-not "t\[0-6\]" } } */
+   In theory, t2 should not used in such small program if regrename
+   not executed incorrectly, because t0-a2 should be enough.  */
+/* { dg-final { scan-assembler-not "t2" } } */
-- 
2.25.1

Re: [PATCH] libstdc++: Give ranges::empty() a concrete return type (PR 93978)

[Jonathan Wakely]

On 05/03/20 11:02 -0500, Patrick Palka wrote:

This works around PR 93978 by avoiding having to instantiate ranges::empty()
when checking the constraints of view_interface::operator bool().  When
ranges::empty() has an auto return type, then we must instantiate it in order to
determine whether the requires expression { ranges::empty(_M_derived()); } is
well-formed.  But this means instantiating view_interface::empty() and hence
view_interface::_M_derived(), all before we've yet deduced the return type of
join_view::end().  (The reason view_interface::operator bool() is needed in
join_view::end() in the first place is because in this function we perform
direct initialization of join_view::_Sentinel from a join_view, and so we try to
find a conversion sequence from the latter to the former that goes through this
conversion operator.)

Giving ranges::empty() a concrete return type of bool should be safe according
to [ranges.prim.empty]/4 which says "whenever ranges::empty(E) is a valid


N.B. [range.prim.empty] in the commit log here please, not "ranges."


expression, it has type bool."


Right, I don't know why I didn't make it just return bool anyway.
Probably because I was copy _Begin for each of those other
range access CPOs.

This way we've become aware of the danger of using deduced return
types, and so can audit the other cases.


This fixes the test case in PR 93978 when compiling without -Wall, but with 
-Wall
the test case still fails due to the issue described in PR c++/94038, I think.
I still don't quite understand why the test case doesn't fail without -O.


Still a small improvement.

OK for master, thanks.

Re: Bind to std::equal plumbing in ranges::equal

[Jonathan Wakely]

On 06/03/20 10:09 +, Jonathan Wakely wrote:

On 06/03/20 07:06 +0100, François Dumont wrote:
I started to work on ranges::equal to find out if what I am trying 
to do is totally silly.


With this patch ranges::equal is in pare with std::equal 
specializations that is to say that it correctly deals with Debug 
mode or std::deque iterators.


Once below patch is in:

https://gcc.gnu.org/ml/libstdc++/2019-12/msg00032.html

We will even be able to call std::__equal_aux1 directly using 
__niter_base to get rid of the Debug safe iterator layer. And even 
in this case get rid of the branch __use_memcmp and leave it to 
__equal_aux1.


I mainly fear the usage of std::iterator_traits in __equal_aux1 to 
be a problem. Is it in this context of sized_sentinel ?


I don't understand the question. No sentinel of type _Sent1 or _Sent2
gets passed to __equal_aux1 with your patch, you only pass iterators.

But I think the patch is wrong:


+ return !std::__memcmp(__first1, __first2, __d1);
+   else
+ return std::__equal_aux(__first1, __first1 + __d1, __first2);


This last line will only compile if _Iter1 is random access, but all
we know at this point is that _Sent1 is a sized sentinel for _Iter1.
That doesn't mean it's necessarily random access.


Please try the example at https://wg21.link/counted.iterator#2 which
uses counted_iterator::iterator> and default_sentinel.
The sized_sentinel_for concept is satisfied, but you can't do first1+d1.

Re: Bind to std::equal plumbing in ranges::equal

[Jonathan Wakely]

On 06/03/20 07:06 +0100, François Dumont wrote:
I started to work on ranges::equal to find out if what I am trying to 
do is totally silly.


With this patch ranges::equal is in pare with std::equal 
specializations that is to say that it correctly deals with Debug mode 
or std::deque iterators.


Once below patch is in:

https://gcc.gnu.org/ml/libstdc++/2019-12/msg00032.html

We will even be able to call std::__equal_aux1 directly using 
__niter_base to get rid of the Debug safe iterator layer. And even in 
this case get rid of the branch __use_memcmp and leave it to 
__equal_aux1.


I mainly fear the usage of std::iterator_traits in __equal_aux1 to be 
a problem. Is it in this context of sized_sentinel ?


I don't understand the question. No sentinel of type _Sent1 or _Sent2
gets passed to __equal_aux1 with your patch, you only pass iterators.

But I think the patch is wrong:


+ return !std::__memcmp(__first1, __first2, __d1);
+   else
+ return std::__equal_aux(__first1, __first1 + __d1, __first2);


This last line will only compile if _Iter1 is random access, but all
we know at this point is that _Sent1 is a sized sentinel for _Iter1.
That doesn't mean it's necessarily random access.

Re: [PATCH 1/1] libstdc++: Deal with ENOSYS == ENOTSUP

[Jonathan Wakely]

On Fri, 6 Mar 2020 at 09:52, Andreas Krebbel  wrote:
>
> On 3/6/20 10:15 AM, Ville Voutilainen wrote:
> > On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel  wrote:
> >>
> >> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
> >>
> >> Ok for mainline?
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> 2020-03-06  Andreas Krebbel  
> >>
> >> * src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
> >> would match ENOSYS.
> >> ---
> >>  libstdc++-v3/src/c++11/system_error.cc | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libstdc++-v3/src/c++11/system_error.cc 
> >> b/libstdc++-v3/src/c++11/system_error.cc
> >> index 7844afe6d2a..1f06e67feea 100644
> >> --- a/libstdc++-v3/src/c++11/system_error.cc
> >> +++ b/libstdc++-v3/src/c++11/system_error.cc
> >> @@ -251,7 +251,8 @@ namespace
> >>  #ifdef ENOTSOCK
> >>case ENOTSOCK:
> >>  #endif
> >> -#ifdef ENOTSUP
> >> +#if defined ENOTSUP && (!defined ENOSYS || ENOTSUP != ENOSYS)
> >
> > Hmm, what system does not have ENOSYS but has ENOTSUP? Meaning the
> > !defined ENOSYS
> > bit?
> >
> None that I know about. It is just to make sure the compare afterwards 
> operates on defined inputs.

Right, it's the same pattern we use for the other cases of possibly
duplicated values.

OK to commit, thanks.

Re: [PATCH 1/1] libstdc++: Deal with ENOSYS == ENOTSUP

[Ville Voutilainen]

On Fri, 6 Mar 2020 at 11:52, Andreas Krebbel  wrote:

> > Hmm, what system does not have ENOSYS but has ENOTSUP? Meaning the
> > !defined ENOSYS
> > bit?
> >
> None that I know about. It is just to make sure the compare afterwards 
> operates on defined inputs.

Ah, I see, indeed. This dance is done also for EOPNOTSUPP, looks good
to me (but Jonathan still needs
to do the approval).

Re: [GCC][PATCH][AArch64] ACLE intrinsics for BFCVTN, BFCVTN2 (AArch64 AdvSIMD) and BFCVT (AArch64 FP)

[Richard Sandiford]

Delia Burduv  writes:
> Hi,
>
> Here is the latest version of the  patch. That test should now work.

Thanks, pushed.

Richard

Re: [PATCH 1/1] libstdc++: Deal with ENOSYS == ENOTSUP

[Andreas Krebbel]

On 3/6/20 10:15 AM, Ville Voutilainen wrote:
> On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel  wrote:
>>
>> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
>>
>> Ok for mainline?
>>
>> libstdc++-v3/ChangeLog:
>>
>> 2020-03-06  Andreas Krebbel  
>>
>> * src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
>> would match ENOSYS.
>> ---
>>  libstdc++-v3/src/c++11/system_error.cc | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libstdc++-v3/src/c++11/system_error.cc 
>> b/libstdc++-v3/src/c++11/system_error.cc
>> index 7844afe6d2a..1f06e67feea 100644
>> --- a/libstdc++-v3/src/c++11/system_error.cc
>> +++ b/libstdc++-v3/src/c++11/system_error.cc
>> @@ -251,7 +251,8 @@ namespace
>>  #ifdef ENOTSOCK
>>case ENOTSOCK:
>>  #endif
>> -#ifdef ENOTSUP
>> +#if defined ENOTSUP && (!defined ENOSYS || ENOTSUP != ENOSYS)
> 
> Hmm, what system does not have ENOSYS but has ENOTSUP? Meaning the
> !defined ENOSYS
> bit?
> 
None that I know about. It is just to make sure the compare afterwards operates 
on defined inputs.

Andreas

Re: [PATCH 1/1] libstdc++: Deal with ENOSYS == ENOTSUP

[Ville Voutilainen]

On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel  wrote:
>
> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
>
> Ok for mainline?
>
> libstdc++-v3/ChangeLog:
>
> 2020-03-06  Andreas Krebbel  
>
> * src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
> would match ENOSYS.
> ---
>  libstdc++-v3/src/c++11/system_error.cc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/c++11/system_error.cc 
> b/libstdc++-v3/src/c++11/system_error.cc
> index 7844afe6d2a..1f06e67feea 100644
> --- a/libstdc++-v3/src/c++11/system_error.cc
> +++ b/libstdc++-v3/src/c++11/system_error.cc
> @@ -251,7 +251,8 @@ namespace
>  #ifdef ENOTSOCK
>case ENOTSOCK:
>  #endif
> -#ifdef ENOTSUP
> +#if defined ENOTSUP && (!defined ENOSYS || ENOTSUP != ENOSYS)

Hmm, what system does not have ENOSYS but has ENOTSUP? Meaning the
!defined ENOSYS
bit?

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

[Richard Biener]

On Fri, Mar 6, 2020 at 2:04 AM Martin Sebor  wrote:
>
> Treating incompatible redeclarations of built-in functions as built-ins
> is a problem not just for the middle-end but even for the C front-end
> itself, when different parts of it make  different assumptions about
> what is and isn't valid.  The test case that is the subject of this
> bug report (a GCC 9 and 10 regression) is one such example: it shows
> that the attribute format validation assumes the function declaration
> the attribute applies to has passed the prerequisite validation.  But
> that's not the case when the function is an incompatibly redeclared
> built-in where a format attribute's positional argument refers to
> parameter of an invalid/nonsensical type.
>
> The attached patch further adjusts the front-end to consider even more
> incompatible redeclarations as built-ins: in particular, redeclarations
> whose pointer arguments point to incompatible variants of unqualified
> types (e.g., char* vs int*, though not char* vs const char*).
>
> Besides avoiding the front-end and some middle-end ICEs, the effect
> of the patch is also to diagnose more incompatible redeclarations
> of built-ins than before, but fewer invalid calls to such functions
> (since they're no longer considered built-ins).  That seems like
> an unavoidable trade-off.
>
> Tested on x86_64-linux.  Is this acceptable for GCC 10?  How about 9?

The actual patch needs reviewing from a FE maintainer but I'd support
putting this in for GCC 10.

It would be nice if we can put in code like the following to catch "bogus"
built-in declarations.  I've put it in call verification because there it's
where it matters most, free-lang-data would be another canonical place
which would then process all "reachable" function declarations but we
don't yet call free-lang-data when not doing LTO.

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index f7b817d94e6..ae695891bd4 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -3356,6 +3356,17 @@ verify_gimple_call (gcall *stmt)
return true;
  }

+  if (fndecl
+  && fndecl_built_in_p (fndecl, BUILT_IN_NORMAL)
+  && !types_compatible_p (TREE_TYPE (fndecl),
+ TREE_TYPE (builtin_decl_explicit
+   (DECL_FUNCTION_CODE (fndecl)
+{
+  error ("function declaration declared built-in but does not "
+"match expected type");
+  return true;
+}
+
   tree lhs = gimple_call_lhs (stmt);
   if (lhs
   && (!is_gimple_lvalue (lhs)


> Martin

[Committed] IBM Z: Fix error format string.

[Andreas Krebbel]

gcc/ChangeLog:

2020-03-06  Andreas Krebbel  

* config/s390/s390.md ("tabort"): Get rid of two consecutive
blanks in format string.
---
 gcc/config/s390/s390.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index e37ba49444a..44b59659e20 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -11931,8 +11931,8 @@
   if (CONST_INT_P (operands[0])
   && INTVAL (operands[0]) >= 0 && INTVAL (operands[0]) <= 255)
 {
-  error ("invalid transaction abort code: %wd;  values in range 0 "
-"through 255 are reserved", INTVAL (operands[0]));
+  error ("invalid transaction abort code: %wd (values in range 0 "
+"through 255 are reserved)", INTVAL (operands[0]));
   FAIL;
 }
 })
-- 
2.24.1

Re: [PATCH] generate EH info for volatile asm statements (PR inline-asm/93981)

[Richard Biener]

On Thu, Mar 5, 2020 at 5:49 PM J.W. Jagersma  wrote:
>
> The following patch extends the generation of exception handling
> information to cover volatile asms too.  This was already mostly
> implemented, and only very minor changes are required in order to make
> it work.
>
> The change in rewrite_stmt is necessary because it inserts debug
> statements after the asm, and this causes the gimple verification pass
> to fail.  This code is copied from maybe_register_def which does the
> same thing.  Alternatively the verification routines could be made to
> ignore debug statements at the end of a block.
>
> gcc/
> 2020-03-05  Jan W. Jagersma  
>
> PR inline-asm/93981
> * tree-cfg.c (make_edges_bb): Call make_eh_edges for case
> GIMPLE_ASM.
> * tree-eh.c (lower_eh_constructs_2): Add case for GIMPLE_ASM.
> * tree-into-ssa.c (rewrite_stmt): For bb-ending stmts, insert
> debug notes on the fallthrough edge.  Code and comments copied
> verbatim from maybe_register_def.
> ---
>  gcc/tree-cfg.c  |  2 ++
>  gcc/tree-eh.c   |  3 +++
>  gcc/tree-into-ssa.c | 38 +-
>  3 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
> index f7b817d94e6..c21a7978493 100644
> --- a/gcc/tree-cfg.c
> +++ b/gcc/tree-cfg.c
> @@ -913,6 +913,8 @@ make_edges_bb (basic_block bb, struct omp_region 
> **pcur_region, int *pomp_index)
>break;
>
>  case GIMPLE_ASM:
> +  if (stmt_can_throw_internal (cfun, last))
> +   make_eh_edges (last);
>make_gimple_asm_edges (bb);
>fallthru = true;
>break;
> diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
> index 2a409dcaffe..8314db00922 100644
> --- a/gcc/tree-eh.c
> +++ b/gcc/tree-eh.c
> @@ -2077,6 +2077,9 @@ lower_eh_constructs_2 (struct leh_state *state, 
> gimple_stmt_iterator *gsi)
> DECL_GIMPLE_REG_P (tmp) = 1;
>   gsi_insert_after (gsi, s, GSI_SAME_STMT);
> }
> +  /* FALLTHRU */
> +
> +case GIMPLE_ASM:
>/* Look for things that can throw exceptions, and record them.  */
>if (state->cur_region && stmt_could_throw_p (cfun, stmt))
> {

The part you skip here for ASMs means that for ASM outputs we do
not represent their values correctly on EH edges (and we eventually
never will be able to since we don't know exactly at which point the
actual assembly throws).  So I think this "feature" needs to be documented
appropriately and eventually only ASMs without outputs made allowed
to throw?

> diff --git a/gcc/tree-into-ssa.c b/gcc/tree-into-ssa.c
> index 6528acac31a..03bc1d52cfa 100644
> --- a/gcc/tree-into-ssa.c
> +++ b/gcc/tree-into-ssa.c
> @@ -1415,7 +1415,43 @@ rewrite_stmt (gimple_stmt_iterator *si)
> if (tracked_var)
>   {
> gimple *note = gimple_build_debug_bind (tracked_var, name, stmt);
> -   gsi_insert_after (si, note, GSI_SAME_STMT);
> +   /* If stmt ends the bb, insert the debug stmt on the single
> +  non-EH edge from the stmt.  */
> +   if (gsi_one_before_end_p (*si) && stmt_ends_bb_p (stmt))
> + {
> +   basic_block bb = gsi_bb (*si);
> +   edge_iterator ei;
> +   edge e, ef = NULL;
> +   FOR_EACH_EDGE (e, ei, bb->succs)
> + if (!(e->flags & EDGE_EH))

I think this needs to check for abnormal edges as well to cover
the case of

  i = setjmp ();

which means doing !(e->flags & EDGE_COMPLEX) and adjusting the
comment.

> +   {
> + gcc_checking_assert (!ef);
> + ef = e;
> +   }
> +   /* If there are other predecessors to ef->dest, then
> +  there must be PHI nodes for the modified
> +  variable, and therefore there will be debug bind
> +  stmts after the PHI nodes.  The debug bind notes
> +  we'd insert would force the creation of a new
> +  block (diverging codegen) and be redundant with
> +  the post-PHI bind stmts, so don't add them.
> +
> +  As for the exit edge, there wouldn't be redundant
> +  bind stmts, but there wouldn't be a PC to bind
> +  them to either, so avoid diverging the CFG.  */
> +   if (ef && single_pred_p (ef->dest)
> +   && ef->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
> + {
> +   /* If there were PHI nodes in the node, we'd
> +  have to make sure the value we're binding
> +  doesn't need rewriting.  But there shouldn't
> +  be PHI nodes in a single-predecessor block,
> +  so we just add the note.  */
> +   gsi_insert_on_edge_immediate (ef, note);
> + }

it would be nice to elide building of the debug bind if we 

[PATCH 1/1] libstdc++: Deal with ENOSYS == ENOTSUP

[Andreas Krebbel]

zTPF uses the same numeric value for ENOSYS and ENOTSUP.

Ok for mainline?

libstdc++-v3/ChangeLog:

2020-03-06  Andreas Krebbel  

* src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
would match ENOSYS.
---
 libstdc++-v3/src/c++11/system_error.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++11/system_error.cc 
b/libstdc++-v3/src/c++11/system_error.cc
index 7844afe6d2a..1f06e67feea 100644
--- a/libstdc++-v3/src/c++11/system_error.cc
+++ b/libstdc++-v3/src/c++11/system_error.cc
@@ -251,7 +251,8 @@ namespace
 #ifdef ENOTSOCK
   case ENOTSOCK:
 #endif
-#ifdef ENOTSUP
+#if defined ENOTSUP && (!defined ENOSYS || ENOTSUP != ENOSYS)
+  // zTPF uses the same value for ENOSYS and ENOTSUP
   case ENOTSUP:
 #endif
 #ifdef ENOTTY
-- 
2.24.1

Re: [PATCH][gcc] libgccjit: introduce version entry points

[Andrea Corallo]

David Malcolm  writes:

> On Thu, 2020-01-16 at 11:11 +, Andrea Corallo wrote:
>> Hi, second version of the patch here cleaning up an unnecessary
>> change.
>>
>> Does not introduce regressions with make check-jit.
>>
>> Andrea
>>
>> gcc/jit/ChangeLog
>> 2020-??-??  Andrea Corallo  
>>
>>  * docs/topics/compatibility.rst (LIBGCCJIT_ABI_13): New ABI tag
>>  plus add version paragraph.
>>  * libgccjit++.h (namespace gccjit::version): Add new namespace.
>>  * libgccjit.c (gcc_jit_version_major, gcc_jit_version_minor)
>>  (gcc_jit_version_patchlevel): New functions.
>>  * libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_version): New macro.
>>  (gcc_jit_version_major, gcc_jit_version_minor)
>>  (gcc_jit_version_patchlevel): New functions.
>>  * libgccjit.map (LIBGCCJIT_ABI_13) New ABI tag.
>>
>> gcc/testsuite/ChangeLog
>> 2020-??-??  Andrea Corallo  
>>
>>  * jit.dg/test-version.c: New testcase.
>
> [...]
>
> Thanks for the patch; sorry for the delay in reviewing this.
>
> Out of interest, do you have a specific use for this, or is it more
> speculative?

Hi Dave,

The use case is where client code wants to check specifically at
run-time for the version.  This to warn for a known to be buggy version
or to take any other decision that depends on the libgccjit version.
One could decide to layout the generated code differently depending on
the compiler version.

For these cases the granularity we have with with macros defining for
the ABI may be not sufficient.

As you say this is speculative now given that will become helpful only
in the future.

Thanks for reviewing both patches.  I'll re-spin them this weekend.

  Andrea

Re: [committed] testsuite: Add testcase for already fixed PR [PR90311]

[Jakub Jelinek]

On Thu, Mar 05, 2020 at 05:03:30PM +0100, Jakub Jelinek wrote:
> This PR has been fixed by r10-3970.  Testcase tested with cross to
> armv7hl-linux-gnueabi (all of r10-3969 (FAIL), r10-3970 and current trunk 
> (PASS))

It was actually fixed by
r10-1963-g24990170d318194b265c2fc76d93965275da462c
aka svn r273572 and that is what I've tested it with.
Sorry for the confusion.

> 2020-03-05  Jakub Jelinek  
> 
>   PR target/90311
>   * gcc.c-torture/execute/pr90311.c: New test.

Jakub

Re: [PATCH][gcc] libgccjit: introduce version entry points

[Florian Weimer]

* David Malcolm:

>
> My first thought here was that we should have a way to get all three at
> once, but it turns out that parse_basever does its own caching
> internally.
>
> I don't think the current implementation is thread-safe; parse_basever
> has:
>
>   static int s_major = -1, s_minor, s_patchlevel;
>
>   if (s_major == -1)
> if (sscanf (BASEVER, "%d.%d.%d", _major, _minor, _patchlevel) != 3)
>   {
>   sscanf (BASEVER, "%d.%d", _major, _minor);
>   s_patchlevel = 0;
>   }
>
> I think there's a race here:

Right, it's not thread-safe.

One possiblity would be to store all three numbers in one unsigned
int, and used relaxed MO loads and stores.  A zero value would
indicate that initialization is needed.

It will break if there are ever more than 1000 or so GCC releases, but
it will be good for a while.