Re: [PATCH] [PR c++/80290] recycle tinst garbage sooner

[Alexandre Oliva]

On Apr 18, 2018, Jason Merrill  wrote:

> Ok, thanks.

Thanks, here's the consolidated patch I installed.


tinst_level objects are created during template instantiation, and
they're most often quite short-lived, but since there's no intervening
garbage collection, they accumulate throughout the pass while most by
far could be recycled after a short while.  The original testcase in
PR80290, for example, creates almost 55 million tinst_level objects,
all but 10 thousand of them without intervening GC, but we don't need
more than 284 of them live at a time.

Furthermore, in many cases, TREE_LIST objects are created to stand for
the decl in tinst_level.  In most cases, those can be recycled as soon
as the tinst_level object is recycled; in some relatively common
cases, they are modified and reused in up to 3 tinst_level objects.
In the same testcase, TREE_LISTs are used in all but 3 thousand of the
tinst_level objects, and we don't need more than 89 tinst_level
objects with TREE_LISTs live at a time.  Furthermore, all but 2
thousand of those are created without intervening GC.

This patch arranges for tinst_level objects to be refcounted (I've
seen as many as 20 live references to a single tinst_level object in
my testing), and for pending_template, tinst_level and TREE_LIST
objects that can be recycled to be added to freelists; that's much
faster than ggc_free()ing them and reallocating them shortly
thereafter.  In fact, the introduction of such freelists is what makes
this entire patch lighter-weight, when it comes to memory use, and
faster.  With refcounting alone, the total memory footprint was still
about the same, and we spent more time.

In order to further reduce memory use, I've arranged for us to create
TREE_LISTs lazily, only at points that really need them (when printing
error messages).  This grows tinst_level by an additional pointer, but
since a TREE_LIST holds a lot more than an extra pointer, and
tinst_levels with TREE_LISTs used to be allocated tens of thousands of
times more often than plain decl ones, we still save memory overall.

I was still not quite happy about growing memory use in cases that
used template classes but not template overload resolution, so I
changed the type of the errors field to unsigned short, from int.
With that change, in_system_header_p and refcount move into the same
word or half-word that used to hold errors, releasing a full word,
bringing tinst_level back to its original size, now without any
padding.

The errors field is only used to test whether we've had any errors
since the expansion of some template, to skip the expansion of further
templates.  If we get 2^16 errors or more, it is probably reasonable
to refrain from expanding further templates, even if we would expand
them before this change.

With these changes, compile time for the original testcase at -O0,
with default checking enabled, is cut down by some 3.7%, total GCable
memory allocation is cut down by almost 20%, and total memory use (as
reported by GNU time as maxresident) is cut down by slightly over 15%.


for  gcc/cp/ChangeLog

PR c++/80290
* cp-tree.h (struct tinst_level): Split decl into tldcl and
targs.  Add private split_list_p, tree_list_p, and not_list_p
inline const predicates; to_list private member function
declaration; free public member function declaration; list_p,
get_node and maybe_get_node accessors, and refcount data
member.  Narrow errors to unsigned short.
* error.c (print_instantiation_full_context): Use new
accessors.
(print_instantiation_partial_context_line): Likewise.  Drop
const from tinst_level-typed parameter.
* mangle.c (mangle_decl_string): Likewise.
* pt.c (freelist): New template class.
(tree_list_freelist_head): New var.
(tree_list_freelist): New fn, along with specializations.
(tinst_level_freelist_head): New var.
(pending_template_freelist_head): Likewise.
(tinst_level_freelist, pending_template_freelist): New fns.
(tinst_level::to_list, tinst_level::free): Define.
(inc_refcount_use, dec_refcount_use): New fns for tinst_level.
(set_refcount_ptr): New template fn.
(add_pending_template): Adjust for refcounting, freelists and
new accessors.
(neglectable_inst_p): Take a NULL d as a non-DECL.
(limit_bad_template_recursion): Use new accessors.
(push_tinst_level): New overload to create the list.
(push_tinst_level_loc): Make it static, split decl into two
args, adjust tests and initialization to cope with split
lists, use freelist, adjust for refcounting.
(push_tinst_level_loc): New wrapper with the old interface.
(pop_tinst_level): Adjust for refcounting.
(record_last_problematic_instantiation): Likewise.
(reopen_tinst_level): Likewise.  Use new accessors.
(instantiate_alias_template): Adjust for s

Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Jason Merrill]

I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.

On Tue, Apr 17, 2018, 9:45 PM Alexandre Oliva  wrote:

>
> A static_cast of a pointer to data member used to wrap the PTRMEM_CST
> in a NOP_EXPR, but the NOP_EXPR is taken, in constexpr, as evidence
> that there was a reinterpret_cast in the expression.  While
> reinterpret_casts are to be rejected in constexprs, static_casts are
> ok.
>
> Thus, avoid introducing the NOP_EXPR in static_casts, folding the
> converted-to type into the PTRMEM_CST type.
>
> This requires PTRMEM_CST constant expansion to deal with such up and
> downcasts.
>
> ---
>
> I've tested this sucessfully with check-c++-all, but I'm not entirely
> happy with it, not just because the following testcase still fails
> (though the testcases in the patch pass), but also because the early
> folding and the extra work in cplus_expand_constant don't feel quite
> right.
>
>
> struct A { };
> struct B { int x; };
> struct C : A, B {};
> constexpr int C::*pci = &B::x;
> constexpr int A::*pai = static_cast(pci);
>
>
> I've experimented with an alternative of marking NOP_EXPRs introduced by
> static_casts and const_casts with a flag (static_flag), but that felt
> even more fragile, since we drop and rebuild NOP_EXPRs all the time,
> redundant ones used to be dropped safely, and so both positive and
> negative marks for constexpr compatibility could be lost, leading to
> false positives or missed errors.
>
> Still, it seems like we'd be better off with some reliable means to tell
> constexpr-compatible casts from other conversions.  NOP_EXPRs alone just
> don't cut it.
>
> Anyway, at this point I'd appreciate some guidance as to how to proceed.
> At this stage of GCC8 development, I'm even considering dropping the
> incorrect complaint about reinterpret_cast, even if that would regress
> the rejection of casts that don't belong in constexprs.
>
> Thoughts?  Suggestions?
>
> Thanks in advance,
>
> ---
>
> for  gcc/cp/ChangeLog
>
> PR c++/85437
> * expr.c (cplus_expand_constant): Compute deltas for up and
> downcasts.
> * type.c (convert_ptrmem): Convert ptrmem type for static
> cast.
>
> for  gcc/testsuite/ChangeLog
>
> PR c++/85437
> * g++.dg/cpp0x/pr85437.C: New.
> * g++.dg/cpp0x/pr85437-2.C: New.
> * g++.dg/cpp0x/pr85437-3.C: New.
> ---
>  gcc/cp/expr.c  |   25 +
>  gcc/cp/typeck.c|5 -
>  gcc/testsuite/g++.dg/cpp0x/pr85437-2.C |7 +++
>  gcc/testsuite/g++.dg/cpp0x/pr85437-3.C |7 +++
>  gcc/testsuite/g++.dg/cpp0x/pr85437.C   |   16 
>  5 files changed, 59 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr85437-2.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr85437-3.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr85437.C
>
> diff --git a/gcc/cp/expr.c b/gcc/cp/expr.c
> index 15894fc0b594..28fe2e83398d 100644
> --- a/gcc/cp/expr.c
> +++ b/gcc/cp/expr.c
> @@ -50,11 +50,36 @@ cplus_expand_constant (tree cst)
> while (!same_type_p (DECL_CONTEXT (member),
>  TYPE_PTRMEM_CLASS_TYPE (type)))
>   {
> +   tree t1 = TYPE_MAIN_VARIANT (DECL_CONTEXT (member));
> +   tree t2 = TYPE_MAIN_VARIANT (TYPE_PTRMEM_CLASS_TYPE
> (type));
> +
> +   if (can_convert (t2, t1, 0))
> + {
> +   base_kind kind;
> +   tree binfo = lookup_base (t1, t2, ba_unique, &kind, 0);
> +   if (binfo != error_mark_node
> +   && kind != bk_via_virtual)
> + cst = size_binop (MINUS_EXPR, cst, BINFO_OFFSET
> (binfo));
> +   break;
> + }
> +
> +   if (can_convert (t1, t2, 0))
> + {
> +   base_kind kind;
> +   tree binfo = lookup_base (t2, t1, ba_unique, &kind, 0);
> +   if (binfo != error_mark_node
> +   && kind != bk_via_virtual)
> + cst = size_binop (PLUS_EXPR, cst, BINFO_OFFSET
> (binfo));
> +   break;
> + }
> +
> /* The MEMBER must have been nestled within an
>anonymous aggregate contained in TYPE.  Find the
>anonymous aggregate.  */
> member = lookup_anon_field (TYPE_PTRMEM_CLASS_TYPE (type),
> DECL_CONTEXT (member));
> +   if (!member)
> + break;
> cst = size_binop (PLUS_EXPR, cst, byte_position (member));
>   }
> cst = fold (build_nop (type, cst));
> diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
> index b449b1f7f539..0b88181e9574 100644
> --- a/gcc/cp/typeck.c
> +++ b/gcc/cp/typeck.c
> @@ -6871,7 +6871,10 @@ convert_ptrmem (tree type, tree expr, bool
> 

Re: [PATCH] [PR c++/80290] recycle tinst garbage sooner

[Jason Merrill]

Ok, thanks.

On Tue, Apr 17, 2018, 9:29 PM Alexandre Oliva  wrote:

> On Apr 17, 2018, Jason Merrill  wrote:
>
> >> Any objections to making dec_refcount_use a friend of tinst_level's?
> >> Otherwise, I'd rather add a free() member function (or maybe static
> >> member function) to free both the TREE_LIST and the tinst_level objects.
>
> > Either of those sounds fine.
>
> Here's the additional incremental patch I'm testing.
>
> I've added a number of line breaks before opening braces in function
> definitions, that had escaped my attention in the initial patch
> submission.
>
> ---
>  gcc/cp/cp-tree.h |5 -
>  gcc/cp/mangle.c  |2 +-
>  gcc/cp/pt.c  |   56
> --
>  3 files changed, 42 insertions(+), 21 deletions(-)
>
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 26a50ac136dd..7031c79b35db 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -5903,6 +5903,9 @@ struct GTY((chain_next ("%h.next"))) tinst_level {
>tree to_list ();
>
>   public:
> +  /* Release storage for OBJ and node, if it's a TREE_LIST.  */
> +  static void free(tinst_level *obj);
> +
>/* Return TRUE iff the original node is a list, split or not.  */
>bool list_p () const { return !not_list_p (); }
>
> @@ -5916,7 +5919,7 @@ struct GTY((chain_next ("%h.next"))) tinst_level {
>
>/* Return the original node if it's a DECL or a TREE_LIST, but do
>   NOT convert a split list to a TREE_LIST: return NULL instead.  */
> -  tree get_decl_maybe () const {
> +  tree maybe_get_node () const {
>  if (!split_list_p ()) return tldcl;
>  else return NULL_TREE;
>}
> diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
> index 940f7ed87e20..2f65709d7d8c 100644
> --- a/gcc/cp/mangle.c
> +++ b/gcc/cp/mangle.c
> @@ -3777,7 +3777,7 @@ mangle_decl_string (const tree decl)
>if (DECL_LANG_SPECIFIC (decl) && DECL_USE_TEMPLATE (decl))
>  {
>struct tinst_level *tl = current_instantiation ();
> -  if ((!tl || tl->get_decl_maybe () != decl)
> +  if ((!tl || tl->maybe_get_node () != decl)
>   && push_tinst_level (decl))
> {
>   template_p = true;
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 2442f07095ca..79563dfa5334 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -50,7 +50,8 @@ typedef int (*tree_fn_t) (tree, void*);
>  /* The PENDING_TEMPLATES is a TREE_LIST of templates whose
> instantiations have been deferred, either because their definitions
> were not yet available, or because we were putting off doing the
> work.  */
> -struct GTY ((chain_next ("%h.next"))) pending_template {
> +struct GTY ((chain_next ("%h.next"))) pending_template
> +{
>struct pending_template *next;
>struct tinst_level *tinst;
>  };
> @@ -8839,17 +8840,20 @@ public:
> build_tree_list logic in reinit, so this could go out of sync.  */
>  template <>
>  inline tree &
> -freelist::next (tree obj) {
> +freelist::next (tree obj)
> +{
>return TREE_CHAIN (obj);
>  }
>  template <>
>  inline tree
> -freelist::anew () {
> +freelist::anew ()
> +{
>return build_tree_list (NULL, NULL);
>  }
>  template <>
>  inline void
> -freelist::poison (tree obj ATTRIBUTE_UNUSED) {
> +freelist::poison (tree obj ATTRIBUTE_UNUSED)
> +{
>int size ATTRIBUTE_UNUSED = sizeof (tree_list);
>tree p ATTRIBUTE_UNUSED = obj;
>tree_base *b ATTRIBUTE_UNUSED = &obj->base;
> @@ -8878,7 +8882,8 @@ freelist::poison (tree obj
> ATTRIBUTE_UNUSED) {
>  }
>  template <>
>  inline void
> -freelist::reinit (tree obj ATTRIBUTE_UNUSED) {
> +freelist::reinit (tree obj ATTRIBUTE_UNUSED)
> +{
>tree_base *b ATTRIBUTE_UNUSED = &obj->base;
>
>  #ifdef ENABLE_GC_CHECKING
> @@ -8902,7 +8907,8 @@ freelist::reinit (tree obj
> ATTRIBUTE_UNUSED) {
>  static GTY((deletable)) tree tree_list_freelist_head;
>  /* Return the/an actual TREE_LIST freelist.  */
>  static inline freelist
> -tree_list_freelist () {
> +tree_list_freelist ()
> +{
>return tree_list_freelist_head;
>  }
>
> @@ -8910,7 +8916,8 @@ tree_list_freelist () {
>  static GTY((deletable)) tinst_level *tinst_level_freelist_head;
>  /* Return the/an actual tinst_level freelist.  */
>  static inline freelist
> -tinst_level_freelist () {
> +tinst_level_freelist ()
> +{
>return tinst_level_freelist_head;
>  }
>
> @@ -8918,7 +8925,8 @@ tinst_level_freelist () {
>  static GTY((deletable)) pending_template *pending_template_freelist_head;
>  /* Return the/an actual pending_template freelist.  */
>  static inline freelist
> -pending_template_freelist () {
> +pending_template_freelist ()
> +{
>return pending_template_freelist_head;
>  }
>
> @@ -8939,7 +8947,8 @@ tinst_level::to_list ()
>
>  /* Increment OBJ's refcount.  */
>  static tinst_level *
> -inc_refcount_use (tinst_level *obj) {
> +inc_refcount_use (tinst_level *obj)
> +{
>if (obj)
>  {
>++obj->refcount;
> @@ -8948,18 +8957,26 @@ inc_refcount_use (tinst_level *obj) {
>return obj;
>  }
>
> +/* Release storage

[PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Alexandre Oliva]

A static_cast of a pointer to data member used to wrap the PTRMEM_CST
in a NOP_EXPR, but the NOP_EXPR is taken, in constexpr, as evidence
that there was a reinterpret_cast in the expression.  While
reinterpret_casts are to be rejected in constexprs, static_casts are
ok.

Thus, avoid introducing the NOP_EXPR in static_casts, folding the
converted-to type into the PTRMEM_CST type.

This requires PTRMEM_CST constant expansion to deal with such up and
downcasts.

---

I've tested this sucessfully with check-c++-all, but I'm not entirely
happy with it, not just because the following testcase still fails
(though the testcases in the patch pass), but also because the early
folding and the extra work in cplus_expand_constant don't feel quite
right.


struct A { };
struct B { int x; };
struct C : A, B {};
constexpr int C::*pci = &B::x;
constexpr int A::*pai = static_cast(pci);


I've experimented with an alternative of marking NOP_EXPRs introduced by
static_casts and const_casts with a flag (static_flag), but that felt
even more fragile, since we drop and rebuild NOP_EXPRs all the time,
redundant ones used to be dropped safely, and so both positive and
negative marks for constexpr compatibility could be lost, leading to
false positives or missed errors.

Still, it seems like we'd be better off with some reliable means to tell
constexpr-compatible casts from other conversions.  NOP_EXPRs alone just
don't cut it.

Anyway, at this point I'd appreciate some guidance as to how to proceed.
At this stage of GCC8 development, I'm even considering dropping the
incorrect complaint about reinterpret_cast, even if that would regress
the rejection of casts that don't belong in constexprs.

Thoughts?  Suggestions?

Thanks in advance,

---

for  gcc/cp/ChangeLog

PR c++/85437
* expr.c (cplus_expand_constant): Compute deltas for up and
downcasts.
* type.c (convert_ptrmem): Convert ptrmem type for static
cast.

for  gcc/testsuite/ChangeLog

PR c++/85437
* g++.dg/cpp0x/pr85437.C: New.
* g++.dg/cpp0x/pr85437-2.C: New.
* g++.dg/cpp0x/pr85437-3.C: New.
---
 gcc/cp/expr.c  |   25 +
 gcc/cp/typeck.c|5 -
 gcc/testsuite/g++.dg/cpp0x/pr85437-2.C |7 +++
 gcc/testsuite/g++.dg/cpp0x/pr85437-3.C |7 +++
 gcc/testsuite/g++.dg/cpp0x/pr85437.C   |   16 
 5 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr85437-2.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr85437-3.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr85437.C

diff --git a/gcc/cp/expr.c b/gcc/cp/expr.c
index 15894fc0b594..28fe2e83398d 100644
--- a/gcc/cp/expr.c
+++ b/gcc/cp/expr.c
@@ -50,11 +50,36 @@ cplus_expand_constant (tree cst)
while (!same_type_p (DECL_CONTEXT (member),
 TYPE_PTRMEM_CLASS_TYPE (type)))
  {
+   tree t1 = TYPE_MAIN_VARIANT (DECL_CONTEXT (member));
+   tree t2 = TYPE_MAIN_VARIANT (TYPE_PTRMEM_CLASS_TYPE (type));
+
+   if (can_convert (t2, t1, 0))
+ {
+   base_kind kind;
+   tree binfo = lookup_base (t1, t2, ba_unique, &kind, 0);
+   if (binfo != error_mark_node
+   && kind != bk_via_virtual)
+ cst = size_binop (MINUS_EXPR, cst, BINFO_OFFSET (binfo));
+   break;
+ }
+
+   if (can_convert (t1, t2, 0))
+ {
+   base_kind kind;
+   tree binfo = lookup_base (t2, t1, ba_unique, &kind, 0);
+   if (binfo != error_mark_node
+   && kind != bk_via_virtual)
+ cst = size_binop (PLUS_EXPR, cst, BINFO_OFFSET (binfo));
+   break;
+ }
+
/* The MEMBER must have been nestled within an
   anonymous aggregate contained in TYPE.  Find the
   anonymous aggregate.  */
member = lookup_anon_field (TYPE_PTRMEM_CLASS_TYPE (type),
DECL_CONTEXT (member));
+   if (!member)
+ break;
cst = size_binop (PLUS_EXPR, cst, byte_position (member));
  }
cst = fold (build_nop (type, cst));
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index b449b1f7f539..0b88181e9574 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -6871,7 +6871,10 @@ convert_ptrmem (tree type, tree expr, bool 
allow_inverse_p,
 
}
 
-  return build_nop (type, expr);
+  if (c_cast_p)
+   return build_nop (type, expr);
+  else
+   return cp_fold_convert (type, expr);
 }
   else
 return build_ptrmemfunc (TYPE_PTRMEMFUNC_FN_TYPE (type), expr,
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr85437-2.C 
b/gcc/test

Re: [PATCH] [PR c++/80290] recycle tinst garbage sooner

[Alexandre Oliva]

On Apr 17, 2018, Jason Merrill  wrote:

>> Any objections to making dec_refcount_use a friend of tinst_level's?
>> Otherwise, I'd rather add a free() member function (or maybe static
>> member function) to free both the TREE_LIST and the tinst_level objects.

> Either of those sounds fine.

Here's the additional incremental patch I'm testing.

I've added a number of line breaks before opening braces in function
definitions, that had escaped my attention in the initial patch
submission.

---
 gcc/cp/cp-tree.h |5 -
 gcc/cp/mangle.c  |2 +-
 gcc/cp/pt.c  |   56 --
 3 files changed, 42 insertions(+), 21 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 26a50ac136dd..7031c79b35db 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5903,6 +5903,9 @@ struct GTY((chain_next ("%h.next"))) tinst_level {
   tree to_list ();
 
  public:
+  /* Release storage for OBJ and node, if it's a TREE_LIST.  */
+  static void free(tinst_level *obj);
+
   /* Return TRUE iff the original node is a list, split or not.  */
   bool list_p () const { return !not_list_p (); }
 
@@ -5916,7 +5919,7 @@ struct GTY((chain_next ("%h.next"))) tinst_level {
 
   /* Return the original node if it's a DECL or a TREE_LIST, but do
  NOT convert a split list to a TREE_LIST: return NULL instead.  */
-  tree get_decl_maybe () const {
+  tree maybe_get_node () const {
 if (!split_list_p ()) return tldcl;
 else return NULL_TREE;
   }
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 940f7ed87e20..2f65709d7d8c 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3777,7 +3777,7 @@ mangle_decl_string (const tree decl)
   if (DECL_LANG_SPECIFIC (decl) && DECL_USE_TEMPLATE (decl))
 {
   struct tinst_level *tl = current_instantiation ();
-  if ((!tl || tl->get_decl_maybe () != decl)
+  if ((!tl || tl->maybe_get_node () != decl)
  && push_tinst_level (decl))
{
  template_p = true;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2442f07095ca..79563dfa5334 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -50,7 +50,8 @@ typedef int (*tree_fn_t) (tree, void*);
 /* The PENDING_TEMPLATES is a TREE_LIST of templates whose
instantiations have been deferred, either because their definitions
were not yet available, or because we were putting off doing the work.  */
-struct GTY ((chain_next ("%h.next"))) pending_template {
+struct GTY ((chain_next ("%h.next"))) pending_template
+{
   struct pending_template *next;
   struct tinst_level *tinst;
 };
@@ -8839,17 +8840,20 @@ public:
build_tree_list logic in reinit, so this could go out of sync.  */
 template <>
 inline tree &
-freelist::next (tree obj) {
+freelist::next (tree obj)
+{
   return TREE_CHAIN (obj);
 }
 template <>
 inline tree
-freelist::anew () {
+freelist::anew ()
+{
   return build_tree_list (NULL, NULL);
 }
 template <>
 inline void
-freelist::poison (tree obj ATTRIBUTE_UNUSED) {
+freelist::poison (tree obj ATTRIBUTE_UNUSED)
+{
   int size ATTRIBUTE_UNUSED = sizeof (tree_list);
   tree p ATTRIBUTE_UNUSED = obj;
   tree_base *b ATTRIBUTE_UNUSED = &obj->base;
@@ -8878,7 +8882,8 @@ freelist::poison (tree obj ATTRIBUTE_UNUSED) {
 }
 template <>
 inline void
-freelist::reinit (tree obj ATTRIBUTE_UNUSED) {
+freelist::reinit (tree obj ATTRIBUTE_UNUSED)
+{
   tree_base *b ATTRIBUTE_UNUSED = &obj->base;
 
 #ifdef ENABLE_GC_CHECKING
@@ -8902,7 +8907,8 @@ freelist::reinit (tree obj ATTRIBUTE_UNUSED) {
 static GTY((deletable)) tree tree_list_freelist_head;
 /* Return the/an actual TREE_LIST freelist.  */
 static inline freelist
-tree_list_freelist () {
+tree_list_freelist ()
+{
   return tree_list_freelist_head;
 }
 
@@ -8910,7 +8916,8 @@ tree_list_freelist () {
 static GTY((deletable)) tinst_level *tinst_level_freelist_head;
 /* Return the/an actual tinst_level freelist.  */
 static inline freelist
-tinst_level_freelist () {
+tinst_level_freelist ()
+{
   return tinst_level_freelist_head;
 }
 
@@ -8918,7 +8925,8 @@ tinst_level_freelist () {
 static GTY((deletable)) pending_template *pending_template_freelist_head;
 /* Return the/an actual pending_template freelist.  */
 static inline freelist
-pending_template_freelist () {
+pending_template_freelist ()
+{
   return pending_template_freelist_head;
 }
 
@@ -8939,7 +8947,8 @@ tinst_level::to_list ()
 
 /* Increment OBJ's refcount.  */
 static tinst_level *
-inc_refcount_use (tinst_level *obj) {
+inc_refcount_use (tinst_level *obj)
+{
   if (obj)
 {
   ++obj->refcount;
@@ -8948,18 +8957,26 @@ inc_refcount_use (tinst_level *obj) {
   return obj;
 }
 
+/* Release storage for OBJ and node, if it's a TREE_LIST.  */
+void
+tinst_level::free (tinst_level *obj)
+{
+  if (obj->tree_list_p ())
+tree_list_freelist ().free (obj->get_node ());
+  tinst_level_freelist ().free (obj);
+}
+
 /* Decrement OBJ's refcount.  If it reaches zero, release OBJ's DECL
and OBJ, and start over with the tinst_level object that used

[PATCH, rs6000, committed] Fix undef-bool-* tests for older BE processors

[Bill Schmidt]

Hi,

The new tests g++.dg/ext/undef-bool-1.C and gcc.target/powerpc/undef-bool-2.c
fail on big-endian systems not configured to use VSX instructions by default.
This patch allows them to run correctly on such systems by adding the -mvsx
option.

Tested on a Power7 configured with the default (same as --with-cpu=power4),
target triple powerpc64-linux-gnu.  Committed as obvious.

Thanks,
Bill


[gcc/testsuite]

2018-04-17  Bill Schmidt  

* gcc.target/powerpc/undef-bool-2.c: Add -mvsx.
* gcc.target/g++.dg/ext/undef-bool-1.C: Likewise.


Index: gcc/testsuite/gcc.target/powerpc/undef-bool-2.c
===
--- gcc/testsuite/gcc.target/powerpc/undef-bool-2.c (revision 259455)
+++ gcc/testsuite/gcc.target/powerpc/undef-bool-2.c (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -std=c11 -DNO_WARN_X86_INTRINSICS" } */
+/* { dg-options "-O2 -std=c11 -DNO_WARN_X86_INTRINSICS -mvsx" } */
 
 /* Test to ensure that "bool" gets undef'd in xmmintrin.h when
we require strict ANSI.  Subsequent use of bool needs stdbool.h.
Index: gcc/testsuite/g++.dg/ext/undef-bool-1.C
===
--- gcc/testsuite/g++.dg/ext/undef-bool-1.C (revision 259455)
+++ gcc/testsuite/g++.dg/ext/undef-bool-1.C (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
-/* { dg-options "-O2 -DNO_WARN_X86_INTRINSICS" } */
+/* { dg-options "-O2 -DNO_WARN_X86_INTRINSICS -mvsx" } */
 
 /* Test to ensure that "bool" gets undef'd in xmmintrin.h when
we require strict ANSI.  */

Re: [C++ Patch] PR 84630 ("[6/7/8 Regression] ICE: TYPE_NAME() used on error_mark_node in tsubst_lambda_expr, at cp/pt.c:17141")

[Jason Merrill]

Ok.

On Tue, Apr 17, 2018, 1:59 PM Paolo Carlini 
wrote:

> Hi,
>
> this one seems easy: just check the return value of begin_lambda_type
> for error_mark_node - exactly like we do in the parser - and avoid
> ICEing immediately after for the submitted snippet. Tested x86_64-linux.
>
> Thanks, Paolo.
>
> //
>
>

Re: [C++ PATCH] Fix constexpr handling of &x->y (PR c++/84463, take 2)

[Jason Merrill]

Ok.

On Tue, Apr 17, 2018, 10:28 AM Jakub Jelinek  wrote:

> On Mon, Apr 16, 2018 at 10:55:34PM +, Jason Merrill wrote:
> > On Mon, Apr 16, 2018, 1:31 PM Jakub Jelinek  wrote:
> >
> > > On Mon, Apr 16, 2018 at 09:28:43PM +0200, Jakub Jelinek wrote:
> > > > On the following new testcase we emit 2 different constexpr errors
> > > > because of premature folding, where the PR44100 hack which is
> supposed
> > > > to fold expressions like &((S *)0)->f or
> > > > &((S *)24)->f folds all the &x->y expressions if x is TREE_CONSTANT
> > > > into (some type)(x + cst) where what we were actually trying to
> access
> > > > is lost.
> > > >
> > > > The following patch limits the offsetof-like expression hack to
> > > expressions
> > > > where maybe_constant_value of val's operand is INTEGER_CST, or e.g.
> > > > a cast of INTEGER_CST to some pointer type.  This way we don't
> regress
> > > > e.g. init/struct2.C, but don't mess up with x is e.g. some constexpr
> > > > variable initialized to address of something.  Or should it avoid
> > > > maybe_constant_value and just handle the literal INTEGER_CST and cast
> > > > thereof?  We wouldn't handle &((S *)(24 + 8))->f that way though...
> > >
> > > Or shall we move this folding to cp_fold instead of
> cp_build_addr_expr_1
> > > (while keeping it limited to INTEGER_CST pointers)?
> >
> >
> > Yes, I think that would be better.
>
> Ok, here is a patch that does that.  Compared to previous patch, the -O1
> for
> constexpr-nullptr-1.C is still needed, there is different diagnostics
> (dereference of null) in constexpr-nullptr-2.C on two lines and two lines
> that were commented due to this hack can now be handled.  Similarly,
> array-size2.C XPASSes now, so removed the xfail in there.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-04-17  Jakub Jelinek  
>
> PR c++/84463
> * typeck.c (cp_build_addr_expr_1): Move handling of offsetof-like
> tricks from here to ...
> * cp-gimplify.c (cp_fold) : ... here.  Only use it
> if INDIRECT_REF's operand is INTEGER_CST cast to pointer type.
>
> * g++.dg/cpp0x/constexpr-nullptr-1.C: Add -O1 to dg-options.
> * g++.dg/cpp0x/constexpr-nullptr-2.C: Expect different diagnostics
> in two cases.  Uncomment two other tests and add expected dg-error
> for
> them.
> * g++.dg/init/struct2.C: Cast to int rather than long to avoid
> -Wnarrowing diagnostics on some targets for c++11.
> * g++.dg/parse/array-size2.C: Remove xfail.
> * g++.dg/cpp0x/constexpr-84463.C: New test.
>
> --- gcc/cp/typeck.c.jj  2018-04-17 11:09:13.887127384 +0200
> +++ gcc/cp/typeck.c 2018-04-17 18:00:17.616039746 +0200
> @@ -5893,19 +5893,6 @@ cp_build_addr_expr_1 (tree arg, bool str
>return arg;
>  }
>
> -  /* ??? Cope with user tricks that amount to offsetof.  */
> -  if (TREE_CODE (argtype) != FUNCTION_TYPE
> -  && TREE_CODE (argtype) != METHOD_TYPE
> -  && argtype != unknown_type_node
> -  && (val = get_base_address (arg))
> -  && COMPLETE_TYPE_P (TREE_TYPE (val))
> -  && INDIRECT_REF_P (val)
> -  && TREE_CONSTANT (TREE_OPERAND (val, 0)))
> -{
> -  tree type = build_pointer_type (argtype);
> -  return fold_convert (type, fold_offsetof_1 (arg));
> -}
> -
>/* Handle complex lvalues (when permitted)
>   by reduction to simpler cases.  */
>val = unary_complex_lvalue (ADDR_EXPR, arg);
> --- gcc/cp/cp-gimplify.c.jj 2018-04-17 11:09:13.886127383 +0200
> +++ gcc/cp/cp-gimplify.c2018-04-17 18:00:17.626039748 +0200
> @@ -2215,6 +2215,28 @@ cp_fold (tree x)
>goto unary;
>
>  case ADDR_EXPR:
> +  loc = EXPR_LOCATION (x);
> +  op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), false);
> +
> +  /* Cope with user tricks that amount to offsetof.  */
> +  if (op0 != error_mark_node
> + && TREE_CODE (TREE_TYPE (op0)) != FUNCTION_TYPE
> + && TREE_CODE (TREE_TYPE (op0)) != METHOD_TYPE)
> +   {
> + tree val = get_base_address (op0);
> + if (val
> + && INDIRECT_REF_P (val)
> + && COMPLETE_TYPE_P (TREE_TYPE (val))
> + && TREE_CONSTANT (TREE_OPERAND (val, 0)))
> +   {
> + val = TREE_OPERAND (val, 0);
> + STRIP_NOPS (val);
> + if (TREE_CODE (val) == INTEGER_CST)
> +   return fold_convert (TREE_TYPE (x), fold_offsetof_1 (op0));
> +   }
> +   }
> +  goto finish_unary;
> +
>  case REALPART_EXPR:
>  case IMAGPART_EXPR:
>rval_ops = false;
> @@ -2232,6 +2254,7 @@ cp_fold (tree x)
>loc = EXPR_LOCATION (x);
>op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), rval_ops);
>
> +finish_unary:
>if (op0 != TREE_OPERAND (x, 0))
> {
>   if (op0 == error_mark_node)
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C.jj 2018-04-17
> 11:09:13.697127292 +0200
> +++ gcc/testsuit

Re: [PATCH] [PR c++/80290] recycle tinst garbage sooner

[Jason Merrill]

On Tue, Apr 17, 2018, 10:25 AM Alexandre Oliva  wrote:

> On Apr 17, 2018, Jason Merrill  wrote:
>
> > I was thinking maybe_get_node
>
> 'k
>
> > I suppose better would be for
>
> > +  if (obj->list_p () && obj->get_decl_maybe ())
> > +   tree_list_freelist ().free (obj->get_node ());
>
> > to be e.g.
>
> > obj-> maybe_free_list();
>
> Any objections to making dec_refcount_use a friend of tinst_level's?
> Otherwise, I'd rather add a free() member function (or maybe static
> member function) to free both the TREE_LIST and the tinst_level objects.
>

Either of those sounds fine.

Otherwise, maybe_free_list would leave the object in an inconsistent
> state, pointing to a freed TREE_LIST, or it could undo to_list, though
> it's not supposed to be reversible in the lifetime of the object.
> free()ing the entire object along with the TREE_LIST addresses that
> concern.  But then, dec_refcount_use does that and then some...
>
> > Or put the list handling in a destructor for tinst_level, and have
> > freelist use placement new and explicit destruction.
>
> A destructor would enable finalization in GGC, I don't think we want to
> do that.
>
> --
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
>

Re: [PATCH] libgo: Avoid clobbering shell history file in signal_cgo_test.go

[Ian Lance Taylor]

On Wed, Apr 4, 2018 at 6:03 AM, Andreas Schwab  wrote:
>
> For some reason signal_cgo_test.go needs to run an interactive shell,
> but suppresses reading the startup files.  This causes the shell history
> file to be clobbered, by using different history settings than usual.
> Avoid that by setting HOME to / so that the shell cannot write a history
> file.

Thanks.  This has already been fixed in a different way in the master
libgo sources, so I've just copied that change into gccgo.
Bootstrapped and ran os/signal test on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 259445)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-2c7093358e5f5ebeb102d44d1036ca0a807d46a5
+b367349d85f315e94e10ee2d76a7c6a46b993dcb
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/os/signal/signal_cgo_test.go
===
--- libgo/go/os/signal/signal_cgo_test.go   (revision 259359)
+++ libgo/go/os/signal/signal_cgo_test.go   (working copy)
@@ -89,6 +89,8 @@ func TestTerminalSignal(t *testing.T) {
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
cmd := exec.CommandContext(ctx, bash, "--norc", "--noprofile", "-i")
+   // Clear HISTFILE so that we don't read or clobber the user's bash 
history.
+   cmd.Env = append(os.Environ(), "HISTFILE=")
cmd.Stdin = slave
cmd.Stdout = slave
cmd.Stderr = slave

Re: [PATCH, rs6000] Fix address sanitizer for powerpc64.

[Segher Boessenkool]

Hi!

On Wed, Apr 18, 2018 at 12:20:50AM +0200, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 05:15:06PM -0500, Bill Seurer wrote:
> > This patch fixes problems that asan has on powerpc64 running on some old
> > kernels and also very new kernels.
> > 
> > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394 and
> > https://github.com/google/sanitizers/issues/933 for more information.
> > 
> > Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
> > powerpc64be-unknown-linux-gnu with no regressions.  Is this ok for trunk?
> > 
> > 
> > 2018-04-17  Bill Seurer  
> > 
> > PR sanitizer/85389
> > * asan/asan_allocator.h: Switch to use dynamic base for the allocator
> > region.
> 
> I'd write
>   * asan/asan_allocator.h (kAllocatorSpace): For __powerpc64__ change
>   from 0xa00ULL to ~(uptr)0.
> 
> Ok with that change and thanks for all the testing.

Same here: thanks!


Segher

Re: [PATCH, rs6000] Fix address sanitizer for powerpc64.

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 05:15:06PM -0500, Bill Seurer wrote:
> [PATCH, rs6000] Fix address sanitizer for powerpc64.
> 
> This patch fixes problems that asan has on powerpc64 running on some old
> kernels and also very new kernels.
> 
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394 and
> https://github.com/google/sanitizers/issues/933 for more information.
> 
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
> powerpc64be-unknown-linux-gnu with no regressions.  Is this ok for trunk?
> 
> 
> 2018-04-17  Bill Seurer  
> 
>   PR sanitizer/85389
>   * asan/asan_allocator.h: Switch to use dynamic base for the allocator
>   region.

I'd write
* asan/asan_allocator.h (kAllocatorSpace): For __powerpc64__ change
from 0xa00ULL to ~(uptr)0.

Ok with that change and thanks for all the testing.

> Index: libsanitizer/asan/asan_allocator.h
> ===
> --- libsanitizer/asan/asan_allocator.h(revision 259447)
> +++ libsanitizer/asan/asan_allocator.h(working copy)
> @@ -122,7 +122,7 @@ const uptr kAllocatorSpace = ~(uptr)0;
>  const uptr kAllocatorSize  =  0x400ULL;  // 4T.
>  typedef DefaultSizeClassMap SizeClassMap;
>  # elif defined(__powerpc64__)
> -const uptr kAllocatorSpace =  0xa00ULL;
> +const uptr kAllocatorSpace = ~(uptr)0;
>  const uptr kAllocatorSize  =  0x200ULL;  // 2T.
>  typedef DefaultSizeClassMap SizeClassMap;
>  # elif defined(__aarch64__) && SANITIZER_ANDROID
> 

Jakub

[PATCH, rs6000] Fix address sanitizer for powerpc64.

[Bill Seurer]

[PATCH, rs6000] Fix address sanitizer for powerpc64.

This patch fixes problems that asan has on powerpc64 running on some old
kernels and also very new kernels.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394 and
https://github.com/google/sanitizers/issues/933 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64be-unknown-linux-gnu with no regressions.  Is this ok for trunk?


2018-04-17  Bill Seurer  

PR sanitizer/85389
* asan/asan_allocator.h: Switch to use dynamic base for the allocator
region.

Index: libsanitizer/asan/asan_allocator.h
===
--- libsanitizer/asan/asan_allocator.h  (revision 259447)
+++ libsanitizer/asan/asan_allocator.h  (working copy)
@@ -122,7 +122,7 @@ const uptr kAllocatorSpace = ~(uptr)0;
 const uptr kAllocatorSize  =  0x400ULL;  // 4T.
 typedef DefaultSizeClassMap SizeClassMap;
 # elif defined(__powerpc64__)
-const uptr kAllocatorSpace =  0xa00ULL;
+const uptr kAllocatorSpace = ~(uptr)0;
 const uptr kAllocatorSize  =  0x200ULL;  // 2T.
 typedef DefaultSizeClassMap SizeClassMap;
 # elif defined(__aarch64__) && SANITIZER_ANDROID

-- 

-Bill Seurer

Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

[Joshua Watt]

On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
> On 04/17/2018 06:24 PM, Joshua Watt wrote:
> > Ping? I'd really like to get this in binutils, which apparently
> > requires getting it here first.
> 
> I think it would help if you mentioned what this is and
> what is the intended use case.

Ah, that would probably be helpful! Yes, this was discussed on the
binutils mailing list, see:
https://sourceware.org/ml/binutils/2018-02/msg00260.html

In short summary: the gold linker doesn't currently build for mingw,
but only because it is attempting to link against libpthread
incorrectly on that platform. Instead of bringing in more specialized
logic to account for that, I opted to include the autotools
ax_pthread.m4 macro (this patch) that automatically handles discovering
pthreads on a wide variety of platforms and compilers, including mingw.

binutils slaves its config/ directory to GCC, so the patch is required
to be committed here first, and then it will be ported over there.

Thanks,
Joshua Watt

> 
> Was this discussed on the binutils or gdb lists?
> 
> Thanks,
> Pedro Alves

Re: [PATCH] Fix UB in dbxout.c (PR debug/84637)

[Jim Wilson]

On Tue, 2018-04-17 at 22:54 +0200, Jakub Jelinek wrote:
>   PR debug/84637
>   * dbxout.c (dbxout_int): Perform negation in unsigned int type.
>   (stabstr_D): Change type of unum from unsigned int to
>   unsigned HOST_WIDE_INT.  Perform negation in unsigned
> HOST_WIDE_INT
>   type.

OK.

Jim

Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

[Pedro Alves]

On 04/17/2018 06:24 PM, Joshua Watt wrote:
> Ping? I'd really like to get this in binutils, which apparently
> requires getting it here first.

I think it would help if you mentioned what this is and
what is the intended use case.

Was this discussed on the binutils or gdb lists?

Thanks,
Pedro Alves

[PATCH] RISC-V: Fix 32-bit stack pointer alignment problem.

[Jim Wilson]

This fixes the problem that Kito Cheng just reported, where the stack doesn't
have ABI required alignment for 32-bit targets.  This was an unintended side
effect of my previous change to fix a gcc bootstrap build failure.

This was tested with riscv{32,64}-{elf,linux} cross compilers and testsuite
runs.  There were no regressions.

Jim

gcc/
PR 84856
* config/riscv/riscv.c (riscv_compute_frame_info): Add calls to
RISCV_STACK_ALIGN when using outgoing_args_size and pretend_args_size.
Set arg_pointer_offset after using pretend_args_size.
---
 gcc/config/riscv/riscv.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index 9e1005e8f10..2870177fa97 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -3307,7 +3307,7 @@ riscv_compute_frame_info (void)
 }
 
   /* At the bottom of the frame are any outgoing stack arguments. */
-  offset = crtl->outgoing_args_size;
+  offset = RISCV_STACK_ALIGN (crtl->outgoing_args_size);
   /* Next are local stack variables. */
   offset += RISCV_STACK_ALIGN (get_frame_size ());
   /* The virtual frame pointer points above the local variables. */
@@ -,9 +,11 @@ riscv_compute_frame_info (void)
   frame->hard_frame_pointer_offset = offset;
   /* Above the hard frame pointer is the callee-allocated varags save area. */
   offset += RISCV_STACK_ALIGN (cfun->machine->varargs_size);
-  frame->arg_pointer_offset = offset;
   /* Next is the callee-allocated area for pretend stack arguments.  */
-  offset += crtl->args.pretend_args_size;
+  offset += RISCV_STACK_ALIGN (crtl->args.pretend_args_size);
+  /* Arg pointer must be below pretend args, but must be above alignment
+ padding.  */
+  frame->arg_pointer_offset = offset - crtl->args.pretend_args_size;
   frame->total_size = offset;
   /* Next points the incoming stack pointer and any incoming arguments. */
 
-- 
2.14.1

Re: [PATCH] Fix UB in dse.c (PR rtl-optimization/85431)

[Eric Botcazou]

> Fixed by just ignoring them.  Bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?
> 
> 2018-04-17  Jakub Jelinek  
> 
>   PR rtl-optimization/85431
>   * dse.c (record_store): Ignore zero width stores.

OK, thanks.

-- 
Eric Botcazou

[PATCH] Fix UB in dse.c (PR rtl-optimization/85431)

[Jakub Jelinek]

Hi!

As mentioned, for BLKmode stores with MEM_SIZE of 0 we invoke UB,
lowpart_bitmask (0) is called and that shifts an UHWI by 64.
Zero size MEMs should only appear in inline asm and shouldn't be interesting
to DSE at all, they can't make other stores dead, nor can be removed as dead
themselves.

Fixed by just ignoring them.  Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

2018-04-17  Jakub Jelinek  

PR rtl-optimization/85431
* dse.c (record_store): Ignore zero width stores.

--- gcc/dse.c.jj2018-01-27 07:26:11.826913649 +0100
+++ gcc/dse.c   2018-04-17 17:53:55.019932700 +0200
@@ -1417,6 +1417,9 @@ record_store (rtx body, bb_info_t bb_inf
   return 0;
 }
 
+  if (known_eq (width, 0))
+return 0;
+
   if (group_id >= 0)
 {
   /* In the restrictive case where the base is a constant or the

Jakub

[PATCH] Fix UB in dbxout.c (PR debug/84637)

[Jakub Jelinek]

Hi!

The first hunk is I think rather obvious, -2147483648 should be printed
as -2147483648 and doesn't need to introduce UB in the compiler while doing
so.  The changes to stabstr_D are analogous, but in addition to that I don't
see why we should just strip away the upper bits, it is again just a string
containing decimal digits.  What that function implemented is that
values from -4294967295 to 4294967295 were printed as expected and the rest
had some bits lost and HOST_WIDE_INT signed minimum invoked UB.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-04-17  Jakub Jelinek  

PR debug/84637
* dbxout.c (dbxout_int): Perform negation in unsigned int type.
(stabstr_D): Change type of unum from unsigned int to
unsigned HOST_WIDE_INT.  Perform negation in unsigned HOST_WIDE_INT
type.

--- gcc/dbxout.c.jj 2018-01-18 21:11:58.613207125 +0100
+++ gcc/dbxout.c2018-04-17 16:23:59.456993115 +0200
@@ -464,7 +464,7 @@ dbxout_int (int num)
   if (num < 0)
 {
   putc ('-', asm_out_file);
-  unum = -num;
+  unum = -(unsigned int) num;
 }
   else
 unum = num;
@@ -671,7 +671,7 @@ stabstr_D (HOST_WIDE_INT num)
 {
   char buf[64];
   char *p = buf + sizeof buf;
-  unsigned int unum;
+  unsigned HOST_WIDE_INT unum;
 
   if (num == 0)
 {
@@ -681,7 +681,7 @@ stabstr_D (HOST_WIDE_INT num)
   if (num < 0)
 {
   stabstr_C ('-');
-  unum = -num;
+  unum = -(unsigned HOST_WIDE_INT) num;
 }
   else
 unum = num;

Jakub

Re: [PATCH][AArch64/arm] PR testsuite/85326 Avoid C++ tests when C++ compiler not present

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 04:36:54PM +0100, Kyrill Tkachov wrote:
> This patch makes the arm and aarch64 testsuite safe for when a C++ compiler 
> is not present.
> This involves moving .C files into g++.dg/other/ and guarding them with the 
> appropriate target check.
> 
> For others it just means renaming them from .C to .c.
> 
> For gcc.target/aarch64/simd/pr67896.C this means adjusting the error messages 
> to look
> for the errors that the C frontend gives for conflicting types rather than 
> what C++ gives.
> 
> This fixes the errors seen when testing a non-bootstrapped C-only GCC and the 
> tests
> still pass on normal testing setups and the tests that are in g++.dg appear 
> UNSUPPORTED
> on the targets that they don't pertain to.
> 
> Tested this on arm-none-linux-gnueabihf and aarch64-none-linux-gnu.

Sorry for missing it in review.  I've noticed that
+FAIL: g++.dg/other/pr81422.C  -std=gnu++98 (test for excess errors)
on both x86_64-linux and i686-linux, so added the needed c++11 effective
target to the test and then noticed a couple of further things.

Tested on x86_64-linux with -m32/-m64, committed to trunk as obvious:

2018-04-17  Jakub Jelinek  

PR testsuite/85326
* g++.dg/other/pr81422.C: Require effective target tls and c++11.
* g++.dg/other/pr60675.C: Likewise.  Remove -std=c++11 from dg-options.
* g++.dg/other/sve_tls_2.C: Require effective target tls.

--- gcc/testsuite/g++.dg/other/pr81422.C.jj 2018-04-17 19:00:20.635357348 
+0200
+++ gcc/testsuite/g++.dg/other/pr81422.C2018-04-17 22:38:54.391423522 
+0200
@@ -1,4 +1,5 @@
-/* { dg-do compile } */
+/* { dg-do compile { target c++11 } } */
+/* { dg-require-effective-target tls } */
 /* { dg-options "-O0" } */
 
 struct DArray
@@ -12,4 +13,3 @@ void foo35(DArray)
 static __thread int x[5];
 foo35({5, (int*)&x});
 }
-
--- gcc/testsuite/g++.dg/other/pr60675.C.jj 2018-04-17 19:00:20.610357336 
+0200
+++ gcc/testsuite/g++.dg/other/pr60675.C2018-04-17 22:38:23.853407970 
+0200
@@ -1,5 +1,7 @@
-/* { dg-do compile { target fpic } } */
-/* { dg-options "-std=c++11 -w -O2 -fPIC" } */
+/* { dg-do compile { target c++11 } } */
+/* { dg-require-effective-target tls } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-w -O2 -fPIC" } */
 namespace CLHEP {
   static const double meter = 1000.*10;
   static const double meter2 = meter*meter;
--- gcc/testsuite/g++.dg/other/sve_tls_2.C.jj   2018-04-17 19:00:20.610357336 
+0200
+++ gcc/testsuite/g++.dg/other/sve_tls_2.C  2018-04-17 22:39:30.931442140 
+0200
@@ -1,4 +1,5 @@
 /* { dg-do compile { target aarch64*-*-* } } */
+/* { dg-require-effective-target tls } */
 /* { dg-options "-O2 -march=armv8.2-a+sve -fPIC -msve-vector-bits=256" } */
 
 #include 


Jakub

libgo patch committed: suppress "ar rcD" and "-zdefs" on AIX

[Ian Lance Taylor]

This patch by Tony Reix fixes invocations of ar and ld on AIX.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 259359)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-3aa5fc91094c5f24b26747ec176ad44cde784fc7
+2c7093358e5f5ebeb102d44d1036ca0a807d46a5
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/cmd/go/internal/work/gccgo.go
===
--- libgo/go/cmd/go/internal/work/gccgo.go  (revision 259359)
+++ libgo/go/cmd/go/internal/work/gccgo.go  (working copy)
@@ -190,15 +190,15 @@ func (gccgoToolchain) pack(b *Builder, a
}
absAfile := mkAbs(objdir, afile)
// Try with D modifier first, then without if that fails.
-   if b.run(a, p.Dir, p.ImportPath, nil, "ar", "rcD", absAfile, absOfiles) 
!= nil {
+   if cfg.Goos == "aix" || b.run(a, p.Dir, p.ImportPath, nil, "ar", "rcD", 
absAfile, absOfiles) != nil {
+   var arArgs []string
if cfg.Goos == "aix" && cfg.Goarch == "ppc64" {
// AIX puts both 32-bit and 64-bit objects in the same 
archive.
// Tell the AIX "ar" command to only care about 64-bit 
objects.
// AIX "ar" command does not know D option.
-   return b.run(a, p.Dir, p.ImportPath, nil, "ar", "-X64", 
"rc", absAfile, absOfiles)
-   } else {
-   return b.run(a, p.Dir, p.ImportPath, nil, "ar", "rc", 
absAfile, absOfiles)
+   arArgs = append(arArgs, "-X64")
}
+   return b.run(a, p.Dir, p.ImportPath, nil, "ar", "rc", arArgs, 
absAfile, absOfiles)
}
return nil
 }
@@ -466,7 +466,10 @@ func (tools gccgoToolchain) link(b *Buil
ldflags = append(ldflags, goLibBegin...)
ldflags = append(ldflags, "-lgo", "-lgcc_s", "-lgcc", "-lc", 
"-lgcc")
case "shared":
-   ldflags = append(ldflags, "-zdefs", "-shared", "-nostdlib", 
"-lgo", "-lgcc_s", "-lgcc", "-lc")
+   if cfg.Goos != "aix" {
+   ldflags = append(ldflags, "-zdefs")
+   }
+   ldflags = append(ldflags, "-shared", "-nostdlib", "-lgo", 
"-lgcc_s", "-lgcc", "-lc")
 
case "pie":
ldflags = append(ldflags, "-pie")

[C++ Patch] PR 84630 ("[6/7/8 Regression] ICE: TYPE_NAME() used on error_mark_node in tsubst_lambda_expr, at cp/pt.c:17141")

[Paolo Carlini]

Hi,

this one seems easy: just check the return value of begin_lambda_type 
for error_mark_node - exactly like we do in the parser - and avoid 
ICEing immediately after for the submitted snippet. Tested x86_64-linux.


Thanks, Paolo.

//

/cp
2018-04-17  Paolo Carlini  

PR c++/84630
* pt.c (tsubst_lambda_expr): Check begin_lambda_type return value
for error_mark_node.

/testsuite
2018-04-17  Paolo Carlini  

PR c++/84630
* g++.dg/cpp0x/pr84630.C: New.
Index: cp/pt.c
===
--- cp/pt.c (revision 259444)
+++ cp/pt.c (working copy)
@@ -17281,6 +17281,8 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flag
 }
 
   tree type = begin_lambda_type (r);
+  if (type == error_mark_node)
+return error_mark_node;
 
   /* Do this again now that LAMBDA_EXPR_EXTRA_SCOPE is set.  */
   determine_visibility (TYPE_NAME (type));
Index: testsuite/g++.dg/cpp0x/pr84630.C
===
--- testsuite/g++.dg/cpp0x/pr84630.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/pr84630.C(working copy)
@@ -0,0 +1,7 @@
+// PR c++/84630
+// { dg-do compile { target c++11 } }
+
+template  struct c {
+  template  __attribute__((noinline([] {}))) int b();  // { dg-error 
"wrong number of arguments" }
+};
+c<> a;

[PATCH] Fix memory and type attributes on vec_extract_??_

[Jakub Jelinek]

Hi!

With the PR85430 fix, I used some scripting to look for insns with
n_operands 2 and types like alu, sselog etc. (those that have 1 suffixed
variants).

The vec_extract_* patterns are one big category that have been detected by
this; some of the patterns used sselog1 type, but others used sselog, which
is IMHO incorrect for n_operands 2 insns.  Furthermore, the
define_insn_and_split I've changed recently that originally had "#"
unconditionally lacked any attrs, which are IMHO needed now that they can
emit in some cases insn directly rather than being split first.

The vec_extract_hi_* patterns usually allow memory in the output operand and
never allow it in the input operand; for sselog1 the default memory attr
implementation returns:
 (and (eq_attr "type" "alu1,negnot,ishift1,rotate1,sselog1,sseshuf1")
  (match_operand 1 "memory_operand"))
   (const_string "both")
 (and (match_operand 0 "memory_operand")
  (match_operand 1 "memory_operand"))
   (const_string "both")
 (match_operand 0 "memory_operand")
   (const_string "store")
  (const_string "none")
The 2 MEMs never happen for any vec_extract_*_, and for vec_extract_hi_*
op1 is never mem either, so it is always none or store, exactly what we
want.  So, we can even simplify some patterns that used separate
alternatives for the explicit memory attribute; the implicit one can handle
it fine.
On the other side, vec_extract_lo_* patterns allow (=v,v), (=v,m) and (=m,v)
alternatives in some cases, and the memory attr used to be wrong for the
(=v,m) cases, for which IMHO we want load rather than both.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-04-17  Jakub Jelinek  

* config/i386/sse.md (vec_extract_lo_): Add
(=v, v) alternative and explicit "memory" attribute.
(vec_extract_lo_): Likewise.  Also add
"type", "prefix", "prefix_extra", "length_immediate" and "mode"
attributes.
(vec_extract_lo_): Add (=v, v) alternative and use
"sselog1" type instead of "sselog".
(vec_extract_hi_): Use "sselog1" type instead of
"sselog".  Remove explicit "memory" attribute.
(vec_extract_lo_v32hi): Add (=v, v) alternative and explicit "memory",
"type", "prefix", "prefix_extra", "length_immediate" and "mode"
attributes.
(vec_extract_hi_v32hi): Merge all alternatives into one, use
"sselog1" type instead of "sselog".  Remove explicit "memory"
attribute.
(vec_extract_hi_v16hi): Merge each pair of alternatives into one,
use "sselog1" type instead of "sselog".  Remove explicit "memory"
attribute.
(vec_extract_lo_v64qi): Add (=v, v) alternative and explicit "memory",
"type", "prefix", "prefix_extra", "length_immediate" and "mode"
attributes.
(vec_extract_hi_v64qi): Merge all alternatives into one, use
"sselog1" type instead of "sselog".  Remove explicit "memory"
attribute.
(vec_extract_hi_v32qi): Merge each pair of alternatives into one,
use "sselog1" type instead of "sselog".  Remove explicit "memory"
attribute.

--- gcc/config/i386/sse.md.jj   2018-04-17 09:07:32.974146472 +0200
+++ gcc/config/i386/sse.md  2018-04-17 14:40:15.571698749 +0200
@@ -7495,9 +7495,9 @@ (define_insn "vec_extract_lo__mask
(set_attr "mode" "")])
 
 (define_insn "vec_extract_lo_"
-  [(set (match_operand: 0 "" 
"=,v")
+  [(set (match_operand: 0 "" 
"=v,,v")
(vec_select:
- (match_operand:V8FI 1 "" 
"v,")
+ (match_operand:V8FI 1 "" 
"v,v,")
  (parallel [(const_int 0) (const_int 1)
 (const_int 2) (const_int 3)])))]
   "TARGET_AVX512F
@@ -7511,6 +7511,7 @@ (define_insn "vec_extract_lo_")])
 
@@ -7651,10 +7652,10 @@ (define_expand "avx_vextractf128"
 })
 
 (define_insn "vec_extract_lo_"
-  [(set (match_operand: 0 "nonimmediate_operand" "=v,m")
+  [(set (match_operand: 0 "nonimmediate_operand" "=v,v,m")
(vec_select:
  (match_operand:V16FI 1 ""
-",v")
+"v,,v")
  (parallel [(const_int 0) (const_int 1)
  (const_int 2) (const_int 3)
  (const_int 4) (const_int 5)
@@ -7670,7 +7671,13 @@ (define_insn "vec_extract_lo_32x8\t{$0x0, %1, 
%0|%0, %1, 0x0}";
   else
 return "#";
-})
+}
+  [(set_attr "type" "sselog1")
+   (set_attr "prefix_extra" "1")
+   (set_attr "length_immediate" "1")
+   (set_attr "memory" "none,load,store")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
 
 (define_split
   [(set (match_operand: 0 "nonimmediate_operand")
@@ -7697,10 +7704,10 @@ (define_split
 })
 
 (define_insn "vec_extract_lo_"
-  [(set (match_operand: 0 "" "=v,m")
+  [(set (match_operand: 0 "" "=v,v,m")
(vec_select:
  (match_operand:VI8F_256 1 ""
-   ",v")
+  

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu  wrote:
> On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak  wrote:
>> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu  wrote:
>>> -fcf-protection -mcet can't be used with IFUNC features, like symbol
>>> multiversioning or target clone, since IBT/SHSTK are applied to the whole
>>> program and they may be disabled in some functions.  But -fcf-protection
>>> is implemented with multi-byte NOPs on all 64-bit processors as well as
>>> 32-bit processors starting with Pentium Pro.  If -fcf-protection requires
>>> -mcet, IFUNC features can't be used on Linux when -fcf-protection is
>>> enabled by default.
>>>
>>> This patch changes -fcf-protection to to enable the NOP portion of CET
>>> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of CET
>>> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
>>>
>>> OK for trunk?
>>
>> As said in the PR, NOP sequences have non-zero cost in the executable
>> (they enlarge the executable), so I don't think this feature should be
>> enabled by default.
>>
>> There is always a configure option if someone wants their compiler to
>> always emit relevant multi-byte nops.
>
> What we need is an option to enable -fcf-function with multi-byte NOPs
> without -mcet which enables the full CET ISAs.  A configure option
> without the corresponding the command-line option makes test and
> debug difficult.   I can add
>
> --enable-cf-function-nop or --with-cf-function-nop
>
> with
>
> -fct-function-nop
>

How about adding -mno-cet, which enables the NOP portion of CET
ISAs?

-- 
H.J.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu  wrote:
> On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu  wrote:
>> On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak  wrote:
>>> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu  wrote:
 -fcf-protection -mcet can't be used with IFUNC features, like symbol
 multiversioning or target clone, since IBT/SHSTK are applied to the whole
 program and they may be disabled in some functions.  But -fcf-protection
 is implemented with multi-byte NOPs on all 64-bit processors as well as
 32-bit processors starting with Pentium Pro.  If -fcf-protection requires
 -mcet, IFUNC features can't be used on Linux when -fcf-protection is
 enabled by default.

 This patch changes -fcf-protection to to enable the NOP portion of CET
 ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of CET
 ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.

 OK for trunk?
>>>
>>> As said in the PR, NOP sequences have non-zero cost in the executable
>>> (they enlarge the executable), so I don't think this feature should be
>>> enabled by default.
>>>
>>> There is always a configure option if someone wants their compiler to
>>> always emit relevant multi-byte nops.
>>
>> What we need is an option to enable -fcf-function with multi-byte NOPs
>> without -mcet which enables the full CET ISAs.  A configure option
>> without the corresponding the command-line option makes test and
>> debug difficult.   I can add
>>
>> --enable-cf-function-nop or --with-cf-function-nop
>>
>> with
>>
>> -fct-function-nop
>>
>
> How about adding -mno-cet, which enables the NOP portion of CET

I meant -mnop-cet, not -mno-cet.

> ISAs?
>
> --
> H.J.



-- 
H.J.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak  wrote:
> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu  wrote:
>> -fcf-protection -mcet can't be used with IFUNC features, like symbol
>> multiversioning or target clone, since IBT/SHSTK are applied to the whole
>> program and they may be disabled in some functions.  But -fcf-protection
>> is implemented with multi-byte NOPs on all 64-bit processors as well as
>> 32-bit processors starting with Pentium Pro.  If -fcf-protection requires
>> -mcet, IFUNC features can't be used on Linux when -fcf-protection is
>> enabled by default.
>>
>> This patch changes -fcf-protection to to enable the NOP portion of CET
>> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of CET
>> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
>>
>> OK for trunk?
>
> As said in the PR, NOP sequences have non-zero cost in the executable
> (they enlarge the executable), so I don't think this feature should be
> enabled by default.
>
> There is always a configure option if someone wants their compiler to
> always emit relevant multi-byte nops.

What we need is an option to enable -fcf-function with multi-byte NOPs
without -mcet which enables the full CET ISAs.  A configure option
without the corresponding the command-line option makes test and
debug difficult.   I can add

--enable-cf-function-nop or --with-cf-function-nop

with

-fct-function-nop

-- 
H.J.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Uros Bizjak]

On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu  wrote:
> -fcf-protection -mcet can't be used with IFUNC features, like symbol
> multiversioning or target clone, since IBT/SHSTK are applied to the whole
> program and they may be disabled in some functions.  But -fcf-protection
> is implemented with multi-byte NOPs on all 64-bit processors as well as
> 32-bit processors starting with Pentium Pro.  If -fcf-protection requires
> -mcet, IFUNC features can't be used on Linux when -fcf-protection is
> enabled by default.
>
> This patch changes -fcf-protection to to enable the NOP portion of CET
> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of CET
> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
>
> OK for trunk?

As said in the PR, NOP sequences have non-zero cost in the executable
(they enlarge the executable), so I don't think this feature should be
enabled by default.

There is always a configure option if someone wants their compiler to
always emit relevant multi-byte nops.

Uros.

[PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

-fcf-protection -mcet can't be used with IFUNC features, like symbol
multiversioning or target clone, since IBT/SHSTK are applied to the whole
program and they may be disabled in some functions.  But -fcf-protection
is implemented with multi-byte NOPs on all 64-bit processors as well as
32-bit processors starting with Pentium Pro.  If -fcf-protection requires
-mcet, IFUNC features can't be used on Linux when -fcf-protection is
enabled by default.

This patch changes -fcf-protection to to enable the NOP portion of CET
ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of CET
ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.

OK for trunk?

H.J.
---
gcc/

PR target/85417
* config/i386/cet.c (file_end_indicate_exec_stack_and_cet):
Check flag_cf_protection instead of TARGET_IBT and TARGET_SHSTK.
* config/i386/i386.c (pass_insert_endbranch::gate): Don't check
TARGET_IBT.
(ix86_option_override_internal): For -fcf-protection, set
x_flag_cet to 1 if not set and also check x_flag_cet.
(ix86_trampoline_init): Don't check TARGET_IBT.
(x86_output_mi_thunk): Likewise.
(ix86_notrack_prefixed_insn_p): Likewise.
* config/i386/i386.md (rdssp): Also enable for flag_cet.
(incssp): Likewise.
(nop_endbr): Also enable for flag_cet.
* config/i386/i386.opt (flag_cet): Initialized to -1.

gcc/testsuite/

PR target/85417
* c-c++-common/attr-nocf-check-1.c: Compile with
-fcf-protection=none.
* c-c++-common/attr-nocf-check-3.c: Likewise.
* gcc.dg/march-generic.c: Likewise.
* gcc.target/i386/align-limit.c: Likewise.
* c-c++-common/fcf-protection-1.c: Remove dg-error for x86
targets.
* c-c++-common/fcf-protection-2.c: Likewise.
* c-c++-common/fcf-protection-3.c: Likewise.
* c-c++-common/fcf-protection-5.c: Likewise.
* c-c++-common/fcf-protection-6.c: Remove dg-additional-options
and dg-error for x86 targets.
* c-c++-common/fcf-protection-7.c: Likewise.
* gcc.target/i386/cet-notrack-icf-1.c: Compile with
-fcf-protection=none -mno-cet.
* gcc.target/i386/cet-notrack-icf-3.c: Likewise.
* gcc.target/i386/cet-property-2.c: Compile with
-fcf-protection=none.
* gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
* gcc.target/i386/ret-thunk-26.c: Likewise.
* gcc.target/i386/cet-label-3.c: New test.
* gcc.target/i386/cet-property-3.c: Likewise.
* gcc.target/i386/cet-sjlj-7.c: Likewise.
* gcc.target/i386/pr85417-1.c: Likewise.
* gcc.target/i386/pr85417-2.c: Likewise.
---
 gcc/config/i386/cet.c  |  4 +-
 gcc/config/i386/i386.c | 23 +++
 gcc/config/i386/i386.md|  6 +--
 gcc/config/i386/i386.opt   |  2 +-
 gcc/testsuite/c-c++-common/attr-nocf-check-1.c |  1 +
 gcc/testsuite/c-c++-common/attr-nocf-check-3.c |  1 +
 gcc/testsuite/c-c++-common/fcf-protection-1.c  |  1 -
 gcc/testsuite/c-c++-common/fcf-protection-2.c  |  1 -
 gcc/testsuite/c-c++-common/fcf-protection-3.c  |  1 -
 gcc/testsuite/c-c++-common/fcf-protection-5.c  |  1 -
 gcc/testsuite/c-c++-common/fcf-protection-6.c  |  3 +-
 gcc/testsuite/c-c++-common/fcf-protection-7.c  |  3 +-
 gcc/testsuite/gcc.dg/march-generic.c   |  2 +-
 gcc/testsuite/gcc.target/i386/align-limit.c|  2 +-
 gcc/testsuite/gcc.target/i386/cet-label-3.c| 16 
 gcc/testsuite/gcc.target/i386/cet-notrack-icf-1.c  |  2 +-
 gcc/testsuite/gcc.target/i386/cet-notrack-icf-3.c  |  2 +-
 gcc/testsuite/gcc.target/i386/cet-property-2.c |  2 +-
 gcc/testsuite/gcc.target/i386/cet-property-3.c | 11 +
 gcc/testsuite/gcc.target/i386/cet-sjlj-7.c | 48 ++
 .../gcc.target/i386/indirect-thunk-attr-7.c|  2 +-
 .../gcc.target/i386/indirect-thunk-extern-7.c  |  2 +-
 gcc/testsuite/gcc.target/i386/pr85417-1.c  |  4 ++
 gcc/testsuite/gcc.target/i386/pr85417-2.c  | 17 
 gcc/testsuite/gcc.target/i386/ret-thunk-26.c   |  2 +-
 25 files changed, 129 insertions(+), 30 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/cet-label-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/cet-property-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/cet-sjlj-7.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr85417-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr85417-2.c

diff --git a/gcc/config/i386/cet.c b/gcc/config/i386/cet.c
index 4a1e013fdde..eb3be171471 100644
--- a/gcc/config/i386/cet.c
+++ b/gcc/config/i386/cet.c
@@ -34,11 +34,11 @@ file_end_indicate_exec_stack_and_cet (void)
 
   unsigned int feature_1 = 0;
 
-  if (TARGET_IBT)
+  if (flag_cf_protection & CF

[Early Bird Ending] Advance the Cannabinoid Therapeutics Movement

[CannaTherapeutics]

CANNABINOID THERAPEUTICS SYMPOSIUM
June 6 - 7, 2018 | Crowne Plaza Redondo Beach & Marina Hotel | Redondo Beach, CA

---
SIGN UP TODAY:
 
http://links.infocastevents.mkt8115.com/ctt?kn=5&ms=MzM5MjIyMDkS1&r=NjkyMTk1NzM3MTk0S0&b=2&j=MTI2MjA1ODQyNAS2&mt=1&rt=0
 
---
Don't miss your last chance to get the latest research into cannabinoid 
therapeutics and the human endocannabinoid system from world class researchers 
at the early bird pricing.

Join the evolving conversation around how cannabis can be better integrated 
into mainstream medical treatments and standards of care at the Cannabinoid 
Therapeutics Symposium.
Featured Speakers Include:

Ziva Cooper, PhD: COLUMBIA UNIVERSITY MEDICAL CENTER
Ziva Cooper, PhD
Associate Professor of Clinical Neurobiology (in Psychology)
COLUMBIA UNIVERSITY MEDICAL CENTER

Chris Evans, PhD: UCLA
Chris Evans, PhD
Investigator, Center for Translational Technologies; Director, Brain Research 
Institute
UCLA
 

Barbara A. Brett, PhD: CORADO STATE UNIVERSITY - PUEBLO
Barbara A. Brett, PhD
Associate Professor, Dept. of Psychology
COLORADO STATE UNIVERSITY - PUEBLO
 

Bonni Goldstein, MD: CANNA-CENTERS
Sue Sisley, MD
PI, Cannabis for Veterans PTSD Study; PI, Cannabis and Pain Study; President
UNIVERSITY OF MICHIGAN IRB; SCOTTSDALE RESEARCH INSTITUTE

---

SIGN UP TODAY:
 
http://links.infocastevents.mkt8115.com/ctt?kn=9&ms=MzM5MjIyMDkS1&r=NjkyMTk1NzM3MTk0S0&b=2&j=MTI2MjA1ODQyNAS2&mt=1&rt=0
 




























-
Unsubscribe
 
http://www.pages03.net/informationforecastinc/SubscriptionPreferences/SubPreferences?spMailingID=33922209&spUserID=NjkyMTk1NzM3MTk0S0&spJobID=MTI2MjA1ODQyNAS2&spReportId=MTI2MjA1ODQyNAS2
 

Re: libbacktrace patch committed: Call munmap after memory test

[Ian Lance Taylor]

On Tue, Apr 17, 2018 at 10:29 AM, Ian Lance Taylor  wrote:
> On Tue, Apr 17, 2018 at 10:21 AM, Tom de Vries  wrote:
>> On 04/17/2018 03:59 PM, Ian Lance Taylor wrote:
>>>
>>> The bug report https://github.com/ianlancetaylor/libbacktrace/issues/13
>>> points out that when backtrace_full checks whether memory is
>>> available, it doesn't necessarily release that memory.  It will stay
>>> on the free list, so libbacktrace will use more and more memory over
>>> time.  This patch fixes that problem by explicitly calling munmap.
>>> Bootstrapped and ran libbacktrace and Go tests on x86_64-pc-linux-gnu.
>>> Committed to mainline.
>>>
>>> Ian
>>>
>>>
>>> 2018-04-17  Ian Lance Taylor  
>>>
>>> * backtrace.c (backtrace_full): When testing whether we can
>>> allocate memory, call mmap directly, and munmap the memory.
>>>
>>>
>>> patch.txt
>>>
>>>
>>> Index: backtrace.c
>>> ===
>>> --- backtrace.c (revision 259359)
>>> +++ backtrace.c (working copy)
>>> @@ -32,12 +32,26 @@ POSSIBILITY OF SUCH DAMAGE.  */
>>> #include "config.h"
>>>   +#include 
>>>   #include 
>>>   +#if !BACKTRACE_USES_MALLOC
>>> +#include 
>>> +#endif
>>> +
>>
>>
>> Hi,
>>
>> this breaks the nvptx build:
>> ...
>> libbacktrace/backtrace.c:39:10: fatal error: sys/mman.h: No such file or
>> directory
>>  #include 
>>   ^~~~
>> compilation terminated.
>
> Sorry about that.  Committed this patch, which should fix that problem.

Actually, never mind.  Looks like this didn't fix the problem.  I'm
just reverting back to the state as of earlier today.

Ian

2018-04-17  Ian Lance Taylor  

* backtrace.c: Revert last two changes.  Don't call mmap
directly.
Index: backtrace.c
===
--- backtrace.c (revision 259439)
+++ backtrace.c (working copy)
@@ -32,27 +32,12 @@ POSSIBILITY OF SUCH DAMAGE.  */
 
 #include "config.h"
 
-#include 
 #include 
 
-#include "backtrace-supported.h"
-
-#if !BACKTRACE_USES_MALLOC
-#include 
-#endif
-
 #include "unwind.h"
 #include "backtrace.h"
 #include "internal.h"
 
-#ifndef MAP_ANONYMOUS
-#define MAP_ANONYMOUS MAP_ANON
-#endif
-
-#ifndef MAP_FAILED
-#define MAP_FAILED ((void *)-1)
-#endif
-
 /* The main backtrace_full routine.  */
 
 /* Data passed through _Unwind_Backtrace.  */
@@ -119,6 +104,7 @@ backtrace_full (struct backtrace_state *
backtrace_error_callback error_callback, void *data)
 {
   struct backtrace_data bdata;
+  void *p;
 
   bdata.skip = skip + 1;
   bdata.state = state;
@@ -127,25 +113,16 @@ backtrace_full (struct backtrace_state *
   bdata.data = data;
   bdata.ret = 0;
 
-#if !BACKTRACE_USES_MALLOC
-  {
-size_t pagesize;
-void *page;
-
-/* If we can't allocate any memory at all, don't try to produce
-   file/line information.  */
-pagesize = getpagesize ();
-page = mmap (NULL, pagesize, PROT_READ | PROT_WRITE, 
-MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
-if (page == MAP_FAILED)
-  bdata.can_alloc = 0;
-else
-  {
-   munmap (page, pagesize);
-   bdata.can_alloc = 1;
-  }
-  }
-#endif
+  /* If we can't allocate any memory at all, don't try to produce
+ file/line information.  */
+  p = backtrace_alloc (state, 4096, NULL, NULL);
+  if (p == NULL)
+bdata.can_alloc = 0;
+  else
+{
+  backtrace_free (state, p, 4096, NULL, NULL);
+  bdata.can_alloc = 1;
+}
 
   _Unwind_Backtrace (unwind, &bdata);
   return bdata.ret;

Re: [PATCH] Fix -fsanitize=address VLA instrumentation (PR sanitizer/85230)

[Jeff Law]

On 04/12/2018 04:16 PM, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, we need to unpoison the red zones when leaving a
> scope with VLA variable(s); this is done through __asan_allocas_unpoison
> call, unfortunately it is called after the __builtin_stack_restore which
> restores the stack pointer; now, if an interrupt comes in between the stack
> restore and the __asan_allocas_unpoison call, the interrupt handler might
> have some stack bytes marked as red zones in the shadow memory and might
> diagnose sanitizing error even when there is none in the original program.
> 
> The following patch ought to fix this by swapping the two calls, so we first
> unpoison and only after it is unpoisoned in shadow memory release the stack.
> The second argument to the __asan_allocas_unpoison call is meant to
> be virtual_dynamic_stack_rtx after the __builtin_stack_restore, i.e. the new
> stack_pointer_rtx value + STACK_DYNAMIC_OFFSET (current_function_decl).
> As the STACK_DYNAMIC_OFFSET value isn't known until the vregs pass, the code
> used a hack where it ignored the second argument and replaced it by
> virtual_dynamic_stack_rtx.  With the asan.c change below this doesn't work
> anymore, because virtual_dynamic_stack_rtx aka stack_pointer_rtx +
> STACK_DYNAMIC_OFFSET (current_function_decl) before the
> __builtin_stack_restore is a different value.  The patch instead uses the
> argument passed to the __asan_allocas_unpoison at GIMPLE time, which is the
> same as passed to __builtin_stack_restore; this is the new stack_pointer_rtx
> value after __builtin_stack_restore.  And, because we don't want that value,
> but that + STACK_DYNAMIC_OFFSET (current_function_decl), we compute
> arg1 + (virtual_dynamic_stack_rtx - stack_pointer_rtx) and let CSE/combiner
> optimize it into arg1 (on targets like x86_64 where STACK_DYNAMIC_OFFSET can
> be even 0 when not accumulating outgoing args or when that size is 0) or
> arg1 + some_constant.
> 
> Bootstrapped on
> {x86_64,i686,powerpc64,powerpc64le,aarch64,s390x,armv7hl}-linux, regtested
> on {x86_64,i686,powerpc64,powerpc64le}-linux so far, but on the power* ones
> on virtual address space size that isn't really supported (likely
> https://github.com/google/sanitizers/issues/933#issuecomment-380058705
> issue, so while nothing regresses there, pretty much all asan tests fail
> there before and after the patch); also tested successfully with
> asan.exp=alloca* on gcc110 and gcc112 on compile farm where it doesn't
> suffer from the VA issue.  Ok if testing passes also on aarch64, s390x
> and armv7hl?
> 
> 2018-04-12  Jakub Jelinek  
> 
>   PR sanitizer/85230
>   * asan.c (handle_builtin_stack_restore): Adjust comment.  Emit
>   __asan_allocas_unpoison call and last_alloca_addr = new_sp before
>   __builtin_stack_restore rather than after it.
>   * builtins.c (expand_asan_emit_allocas_unpoison): Pass
>   arg1 + (virtual_dynamic_stack_rtx - stack_pointer_rtx) as second
>   argument instead of virtual_dynamic_stack_rtx.
OK.

jeff

Re: [PATCH][AArch64/arm] PR testsuite/85326 Avoid C++ tests when C++ compiler not present

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 04:36:54PM +0100, Kyrill Tkachov wrote:
> This patch makes the arm and aarch64 testsuite safe for when a C++ compiler 
> is not present.
> This involves moving .C files into g++.dg/other/ and guarding them with the 
> appropriate target check.
> 
> For others it just means renaming them from .C to .c.
> 
> For gcc.target/aarch64/simd/pr67896.C this means adjusting the error messages 
> to look
> for the errors that the C frontend gives for conflicting types rather than 
> what C++ gives.
> 
> This fixes the errors seen when testing a non-bootstrapped C-only GCC and the 
> tests
> still pass on normal testing setups and the tests that are in g++.dg appear 
> UNSUPPORTED
> on the targets that they don't pertain to.
> 
> Tested this on arm-none-linux-gnueabihf and aarch64-none-linux-gnu.
> 
> Ok for trunk?

Ok, thanks.

Jakub

Re: libbacktrace patch committed: Call munmap after memory test

[Ian Lance Taylor]

On Tue, Apr 17, 2018 at 10:21 AM, Tom de Vries  wrote:
> On 04/17/2018 03:59 PM, Ian Lance Taylor wrote:
>>
>> The bug report https://github.com/ianlancetaylor/libbacktrace/issues/13
>> points out that when backtrace_full checks whether memory is
>> available, it doesn't necessarily release that memory.  It will stay
>> on the free list, so libbacktrace will use more and more memory over
>> time.  This patch fixes that problem by explicitly calling munmap.
>> Bootstrapped and ran libbacktrace and Go tests on x86_64-pc-linux-gnu.
>> Committed to mainline.
>>
>> Ian
>>
>>
>> 2018-04-17  Ian Lance Taylor  
>>
>> * backtrace.c (backtrace_full): When testing whether we can
>> allocate memory, call mmap directly, and munmap the memory.
>>
>>
>> patch.txt
>>
>>
>> Index: backtrace.c
>> ===
>> --- backtrace.c (revision 259359)
>> +++ backtrace.c (working copy)
>> @@ -32,12 +32,26 @@ POSSIBILITY OF SUCH DAMAGE.  */
>> #include "config.h"
>>   +#include 
>>   #include 
>>   +#if !BACKTRACE_USES_MALLOC
>> +#include 
>> +#endif
>> +
>
>
> Hi,
>
> this breaks the nvptx build:
> ...
> libbacktrace/backtrace.c:39:10: fatal error: sys/mman.h: No such file or
> directory
>  #include 
>   ^~~~
> compilation terminated.

Sorry about that.  Committed this patch, which should fix that problem.

Ian


2018-04-17  Ian Lance Taylor  

* backtrace.c: Include backtrace-supported.h before checking
BACKTRACE_USES_MALLOC.
Index: backtrace.c
===
--- backtrace.c (revision 259434)
+++ backtrace.c (working copy)
@@ -35,13 +35,14 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #include 
 
+#include "backtrace-supported.h"
+
 #if !BACKTRACE_USES_MALLOC
 #include 
 #endif
 
 #include "unwind.h"
 #include "backtrace.h"
-#include "backtrace-supported.h"
 #include "internal.h"
 
 #ifndef MAP_ANONYMOUS

Re: [PATCH] [PR c++/80290] recycle tinst garbage sooner

[Alexandre Oliva]

On Apr 17, 2018, Jason Merrill  wrote:

> I was thinking maybe_get_node

'k

> I suppose better would be for

> +  if (obj->list_p () && obj->get_decl_maybe ())
> +   tree_list_freelist ().free (obj->get_node ());

> to be e.g.

> obj-> maybe_free_list();

Any objections to making dec_refcount_use a friend of tinst_level's?
Otherwise, I'd rather add a free() member function (or maybe static
member function) to free both the TREE_LIST and the tinst_level objects.
Otherwise, maybe_free_list would leave the object in an inconsistent
state, pointing to a freed TREE_LIST, or it could undo to_list, though
it's not supposed to be reversible in the lifetime of the object.
free()ing the entire object along with the TREE_LIST addresses that
concern.  But then, dec_refcount_use does that and then some...

> Or put the list handling in a destructor for tinst_level, and have
> freelist use placement new and explicit destruction.

A destructor would enable finalization in GGC, I don't think we want to
do that.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

[Joshua Watt]

On Thu, 2018-03-22 at 21:45 -0500, Joshua Watt wrote:
> config/
>   * ax_pthread.m4: Add file
> ---
>  config/ax_pthread.m4 | 485
> +++
>  1 file changed, 485 insertions(+)
>  create mode 100644 config/ax_pthread.m4
> 
> diff --git a/config/ax_pthread.m4 b/config/ax_pthread.m4
> new file mode 100644
> index 000..5fbf9fe0d68
> --- /dev/null
> +++ b/config/ax_pthread.m4
> @@ -0,0 +1,485 @@
> +#
> =
> ==
> +#https://www.gnu.org/software/autoconf-archive/ax_pthread.ht
> ml
> +#
> =
> ==
> +#
> +# SYNOPSIS
> +#
> +#   AX_PTHREAD([ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
> +#
> +# DESCRIPTION
> +#
> +#   This macro figures out how to build C programs using POSIX
> threads. It
> +#   sets the PTHREAD_LIBS output variable to the threads library and
> linker
> +#   flags, and the PTHREAD_CFLAGS output variable to any special C
> compiler
> +#   flags that are needed. (The user can also force certain compiler
> +#   flags/libs to be tested by setting these environment variables.)
> +#
> +#   Also sets PTHREAD_CC to any special C compiler that is needed
> for
> +#   multi-threaded programs (defaults to the value of CC otherwise).
> (This
> +#   is necessary on AIX to use the special cc_r compiler alias.)
> +#
> +#   NOTE: You are assumed to not only compile your program with
> these flags,
> +#   but also to link with them as well. For example, you might link
> with
> +#   $PTHREAD_CC $CFLAGS $PTHREAD_CFLAGS $LDFLAGS ... $PTHREAD_LIBS
> $LIBS
> +#
> +#   If you are only building threaded programs, you may wish to use
> these
> +#   variables in your default LIBS, CFLAGS, and CC:
> +#
> +# LIBS="$PTHREAD_LIBS $LIBS"
> +# CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
> +# CC="$PTHREAD_CC"
> +#
> +#   In addition, if the PTHREAD_CREATE_JOINABLE thread-attribute
> constant
> +#   has a nonstandard name, this macro defines
> PTHREAD_CREATE_JOINABLE to
> +#   that name (e.g. PTHREAD_CREATE_UNDETACHED on AIX).
> +#
> +#   Also HAVE_PTHREAD_PRIO_INHERIT is defined if pthread is found
> and the
> +#   PTHREAD_PRIO_INHERIT symbol is defined when compiling with
> +#   PTHREAD_CFLAGS.
> +#
> +#   ACTION-IF-FOUND is a list of shell commands to run if a threads
> library
> +#   is found, and ACTION-IF-NOT-FOUND is a list of commands to run
> it if it
> +#   is not found. If ACTION-IF-FOUND is not specified, the default
> action
> +#   will define HAVE_PTHREAD.
> +#
> +#   Please let the authors know if this macro fails on any platform,
> or if
> +#   you have any other suggestions or comments. This macro was based
> on work
> +#   by SGJ on autoconf scripts for FFTW (http://www.fftw.org/) (with
> help
> +#   from M. Frigo), as well as ac_pthread and hb_pthread macros
> posted by
> +#   Alejandro Forero Cuervo to the autoconf macro repository. We are
> also
> +#   grateful for the helpful feedback of numerous users.
> +#
> +#   Updated for Autoconf 2.68 by Daniel Richard G.
> +#
> +# LICENSE
> +#
> +#   Copyright (c) 2008 Steven G. Johnson 
> +#   Copyright (c) 2011 Daniel Richard G. 
> +#
> +#   This program 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 of the License, or
> (at your
> +#   option) any later version.
> +#
> +#   This program 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 program. If not, see .
> +#
> +#   As a special exception, the respective Autoconf Macro's
> copyright owner
> +#   gives unlimited permission to copy, distribute and modify the
> configure
> +#   scripts that are the output of Autoconf when processing the
> Macro. You
> +#   need not follow the terms of the GNU General Public License when
> using
> +#   or distributing such scripts, even though portions of the text
> of the
> +#   Macro appear in them. The GNU General Public License (GPL) does
> govern
> +#   all other use of the material that constitutes the Autoconf
> Macro.
> +#
> +#   This special exception to the GPL applies to versions of the
> Autoconf
> +#   Macro released by the Autoconf Archive. When you make and
> distribute a
> +#   modified version of the Autoconf Macro, you may extend this
> special
> +#   exception to the GPL to apply to your modified version as well.
> +
> +#serial 24
> +
> +AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
> +AC_DEFUN([AX_PTHREAD], [
> +AC_REQUIRE([AC_CANONICAL_HOST])
> +AC_REQUIRE([AC_PROG_CC])
> +AC_REQUIRE([AC_PROG_SED])
> +AC_LANG_

Re: [PATCH], PR target/85358, Fix __ibm128 being converter to __float128 on PowerPC ISA 3.0 (power9)

[Segher Boessenkool]

On Tue, Apr 17, 2018 at 12:51:17PM -0400, Michael Meissner wrote:
> On Mon, Apr 16, 2018 at 02:53:35PM -0500, Segher Boessenkool wrote:
> > Can't you just set up things such that GET_MODE_WIDER_TYPE does not
> > return ieee128 for ibm128?  With maybe a new hook yes, if that is
> > necessary.
> 
> To me both are semantically the same.  Both involve adding a new hook, and
> whether you change the macro or the calls, is a mattery of syntax.  As I
> recall, when I first started doing __float128, there were one or two places
> that wants to do wider types, but there you want to do it, even if the hook
> says not to do automatic conversions.  You also don't want to outlaw explicit
> conversions.
> 
> I can rewrite it if the global/release maintainers would prefer.

It should be a much smaller patch that way.  And yes, you need some
middle end maintainer's ack.


Segher

Re: libbacktrace patch committed: Call munmap after memory test

[Tom de Vries]

On 04/17/2018 03:59 PM, Ian Lance Taylor wrote:

The bug report https://github.com/ianlancetaylor/libbacktrace/issues/13
points out that when backtrace_full checks whether memory is
available, it doesn't necessarily release that memory.  It will stay
on the free list, so libbacktrace will use more and more memory over
time.  This patch fixes that problem by explicitly calling munmap.
Bootstrapped and ran libbacktrace and Go tests on x86_64-pc-linux-gnu.
Committed to mainline.

Ian


2018-04-17  Ian Lance Taylor  

* backtrace.c (backtrace_full): When testing whether we can
allocate memory, call mmap directly, and munmap the memory.


patch.txt


Index: backtrace.c
===
--- backtrace.c (revision 259359)
+++ backtrace.c (working copy)
@@ -32,12 +32,26 @@ POSSIBILITY OF SUCH DAMAGE.  */
  
  #include "config.h"
  
+#include 

  #include 
  
+#if !BACKTRACE_USES_MALLOC

+#include 
+#endif
+


Hi,

this breaks the nvptx build:
...
libbacktrace/backtrace.c:39:10: fatal error: sys/mman.h: No such file or 
directory

 #include 
  ^~~~
compilation terminated.
...

Thanks,
- Tom


  #include "unwind.h"
  #include "backtrace.h"
+#include "backtrace-supported.h"
  #include "internal.h"
  
+#ifndef MAP_ANONYMOUS

+#define MAP_ANONYMOUS MAP_ANON
+#endif
+
+#ifndef MAP_FAILED
+#define MAP_FAILED ((void *)-1)
+#endif
+
  /* The main backtrace_full routine.  */
  
  /* Data passed through _Unwind_Backtrace.  */

@@ -104,7 +118,6 @@ backtrace_full (struct backtrace_state *
backtrace_error_callback error_callback, void *data)
  {
struct backtrace_data bdata;
-  void *p;
  
bdata.skip = skip + 1;

bdata.state = state;
@@ -113,16 +126,25 @@ backtrace_full (struct backtrace_state *
bdata.data = data;
bdata.ret = 0;
  
-  /* If we can't allocate any memory at all, don't try to produce

- file/line information.  */
-  p = backtrace_alloc (state, 4096, NULL, NULL);
-  if (p == NULL)
-bdata.can_alloc = 0;
-  else
-{
-  backtrace_free (state, p, 4096, NULL, NULL);
-  bdata.can_alloc = 1;
-}
+#if !BACKTRACE_USES_MALLOC
+  {
+size_t pagesize;
+void *page;
+
+/* If we can't allocate any memory at all, don't try to produce
+   file/line information.  */
+pagesize = getpagesize ();
+page = mmap (NULL, pagesize, PROT_READ | PROT_WRITE,
+MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+if (page == MAP_FAILED)
+  bdata.can_alloc = 0;
+else
+  {
+   munmap (page, pagesize);
+   bdata.can_alloc = 1;
+  }
+  }
+#endif
  
_Unwind_Backtrace (unwind, &bdata);

return bdata.ret;

Re: [PATCH] Fix memory and type attributes on vec_extract_??_

[Uros Bizjak]

On Tue, Apr 17, 2018 at 6:53 PM, Jakub Jelinek  wrote:
> Hi!
>
> With the PR85430 fix, I used some scripting to look for insns with
> n_operands 2 and types like alu, sselog etc. (those that have 1 suffixed
> variants).
>
> The vec_extract_* patterns are one big category that have been detected by
> this; some of the patterns used sselog1 type, but others used sselog, which
> is IMHO incorrect for n_operands 2 insns.  Furthermore, the
> define_insn_and_split I've changed recently that originally had "#"
> unconditionally lacked any attrs, which are IMHO needed now that they can
> emit in some cases insn directly rather than being split first.
>
> The vec_extract_hi_* patterns usually allow memory in the output operand and
> never allow it in the input operand; for sselog1 the default memory attr
> implementation returns:
>  (and (eq_attr "type" "alu1,negnot,ishift1,rotate1,sselog1,sseshuf1")
>   (match_operand 1 "memory_operand"))
>(const_string "both")
>  (and (match_operand 0 "memory_operand")
>   (match_operand 1 "memory_operand"))
>(const_string "both")
>  (match_operand 0 "memory_operand")
>(const_string "store")
>   (const_string "none")
> The 2 MEMs never happen for any vec_extract_*_, and for vec_extract_hi_*
> op1 is never mem either, so it is always none or store, exactly what we
> want.  So, we can even simplify some patterns that used separate
> alternatives for the explicit memory attribute; the implicit one can handle
> it fine.
> On the other side, vec_extract_lo_* patterns allow (=v,v), (=v,m) and (=m,v)
> alternatives in some cases, and the memory attr used to be wrong for the
> (=v,m) cases, for which IMHO we want load rather than both.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-04-17  Jakub Jelinek  
>
> * config/i386/sse.md (vec_extract_lo_): Add
> (=v, v) alternative and explicit "memory" attribute.
> (vec_extract_lo_): Likewise.  Also add
> "type", "prefix", "prefix_extra", "length_immediate" and "mode"
> attributes.
> (vec_extract_lo_): Add (=v, v) alternative and use
> "sselog1" type instead of "sselog".
> (vec_extract_hi_): Use "sselog1" type instead of
> "sselog".  Remove explicit "memory" attribute.
> (vec_extract_lo_v32hi): Add (=v, v) alternative and explicit "memory",
> "type", "prefix", "prefix_extra", "length_immediate" and "mode"
> attributes.
> (vec_extract_hi_v32hi): Merge all alternatives into one, use
> "sselog1" type instead of "sselog".  Remove explicit "memory"
> attribute.
> (vec_extract_hi_v16hi): Merge each pair of alternatives into one,
> use "sselog1" type instead of "sselog".  Remove explicit "memory"
> attribute.
> (vec_extract_lo_v64qi): Add (=v, v) alternative and explicit "memory",
> "type", "prefix", "prefix_extra", "length_immediate" and "mode"
> attributes.
> (vec_extract_hi_v64qi): Merge all alternatives into one, use
> "sselog1" type instead of "sselog".  Remove explicit "memory"
> attribute.
> (vec_extract_hi_v32qi): Merge each pair of alternatives into one,
> use "sselog1" type instead of "sselog".  Remove explicit "memory"
> attribute.

OK for mainline and backports.

Thanks,
Uros.

> --- gcc/config/i386/sse.md.jj   2018-04-17 09:07:32.974146472 +0200
> +++ gcc/config/i386/sse.md  2018-04-17 14:40:15.571698749 +0200
> @@ -7495,9 +7495,9 @@ (define_insn "vec_extract_lo__mask
> (set_attr "mode" "")])
>
>  (define_insn "vec_extract_lo_"
> -  [(set (match_operand: 0 "" 
> "=,v")
> +  [(set (match_operand: 0 "" 
> "=v,,v")
> (vec_select:
> - (match_operand:V8FI 1 "" 
> "v,")
> + (match_operand:V8FI 1 "" 
> "v,v,")
>   (parallel [(const_int 0) (const_int 1)
>  (const_int 2) (const_int 3)])))]
>"TARGET_AVX512F
> @@ -7511,6 +7511,7 @@ (define_insn "vec_extract_lo_[(set_attr "type" "sselog1")
> (set_attr "prefix_extra" "1")
> (set_attr "length_immediate" "1")
> +   (set_attr "memory" "none,store,load")
> (set_attr "prefix" "evex")
> (set_attr "mode" "")])
>
> @@ -7651,10 +7652,10 @@ (define_expand "avx_vextractf128"
>  })
>
>  (define_insn "vec_extract_lo_"
> -  [(set (match_operand: 0 "nonimmediate_operand" "=v,m")
> +  [(set (match_operand: 0 "nonimmediate_operand" "=v,v,m")
> (vec_select:
>   (match_operand:V16FI 1 ""
> -",v")
> +"v,,v")
>   (parallel [(const_int 0) (const_int 1)
>   (const_int 2) (const_int 3)
>   (const_int 4) (const_int 5)
> @@ -7670,7 +7671,13 @@ (define_insn "vec_extract_lo_  return "vextract32x8\t{$0x0, %1, 
> %0|%0, %1, 0x0}";
>else
>  return "#";
> -})
> +}
> +  [(set_attr "type" "s

Re: [PATCH] Fix x86 attrs on *x86_movcc_0_m1*

[Uros Bizjak]

On Tue, Apr 17, 2018 at 6:58 PM, Jakub Jelinek  wrote:
> Hi!
>
> The search for patterns with n_operands 2 and TYPE_ALU revealed also these
> 3 patterns, which also have just 2 operands, yet use "alu".
>
> I think "alu1" is the right type for these, but given that they had explicit
> "memory" and "imm_disp" attributes, it probably isn't that big deal.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1?
> Or is this something we want in GCC8 too?
>
> 2018-04-17  Jakub Jelinek  
>
> * config/i386/i386.md (*x86_movcc_0_m1): Use type "alu1" rather
> than "alu", remove explicit "memory" and "imm_disp" attributes.
> (*x86_movcc_0_m1_se, *x86_movcc_0_m1_neg): Likewise.

OK for stage1, to avoid stepping on the mine this late in the development.

Thanks,
Uros.

> --- gcc/config/i386/i386.md.jj  2018-04-17 13:22:08.134050850 +0200
> +++ gcc/config/i386/i386.md 2018-04-17 15:03:32.048628607 +0200
> @@ -17898,14 +17898,10 @@ (define_insn "*x86_movcc_0_m1"
> (clobber (reg:CC FLAGS_REG))]
>""
>"sbb{}\t%0, %0"
> -  ; Since we don't have the proper number of operands for an alu insn,
> -  ; fill in all the blanks.
> -  [(set_attr "type" "alu")
> +  [(set_attr "type" "alu1")
> (set_attr "modrm_class" "op0")
> (set_attr "use_carry" "1")
> (set_attr "pent_pair" "pu")
> -   (set_attr "memory" "none")
> -   (set_attr "imm_disp" "false")
> (set_attr "mode" "")
> (set_attr "length_immediate" "0")])
>
> @@ -17918,12 +17914,10 @@ (define_insn "*x86_movcc_0_m1_se"
> (clobber (reg:CC FLAGS_REG))]
>""
>"sbb{}\t%0, %0"
> -  [(set_attr "type" "alu")
> +  [(set_attr "type" "alu1")
> (set_attr "modrm_class" "op0")
> (set_attr "use_carry" "1")
> (set_attr "pent_pair" "pu")
> -   (set_attr "memory" "none")
> -   (set_attr "imm_disp" "false")
> (set_attr "mode" "")
> (set_attr "length_immediate" "0")])
>
> @@ -17934,12 +17928,10 @@ (define_insn "*x86_movcc_0_m1_neg"
> (clobber (reg:CC FLAGS_REG))]
>""
>"sbb{}\t%0, %0"
> -  [(set_attr "type" "alu")
> +  [(set_attr "type" "alu1")
> (set_attr "modrm_class" "op0")
> (set_attr "use_carry" "1")
> (set_attr "pent_pair" "pu")
> -   (set_attr "memory" "none")
> -   (set_attr "imm_disp" "false")
> (set_attr "mode" "")
> (set_attr "length_immediate" "0")])
>
>
> Jakub

[PATCH] Fix x86 attrs on *x86_movcc_0_m1*

[Jakub Jelinek]

Hi!

The search for patterns with n_operands 2 and TYPE_ALU revealed also these
3 patterns, which also have just 2 operands, yet use "alu".

I think "alu1" is the right type for these, but given that they had explicit
"memory" and "imm_disp" attributes, it probably isn't that big deal.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1?
Or is this something we want in GCC8 too?

2018-04-17  Jakub Jelinek  

* config/i386/i386.md (*x86_movcc_0_m1): Use type "alu1" rather
than "alu", remove explicit "memory" and "imm_disp" attributes.
(*x86_movcc_0_m1_se, *x86_movcc_0_m1_neg): Likewise.

--- gcc/config/i386/i386.md.jj  2018-04-17 13:22:08.134050850 +0200
+++ gcc/config/i386/i386.md 2018-04-17 15:03:32.048628607 +0200
@@ -17898,14 +17898,10 @@ (define_insn "*x86_movcc_0_m1"
(clobber (reg:CC FLAGS_REG))]
   ""
   "sbb{}\t%0, %0"
-  ; Since we don't have the proper number of operands for an alu insn,
-  ; fill in all the blanks.
-  [(set_attr "type" "alu")
+  [(set_attr "type" "alu1")
(set_attr "modrm_class" "op0")
(set_attr "use_carry" "1")
(set_attr "pent_pair" "pu")
-   (set_attr "memory" "none")
-   (set_attr "imm_disp" "false")
(set_attr "mode" "")
(set_attr "length_immediate" "0")])
 
@@ -17918,12 +17914,10 @@ (define_insn "*x86_movcc_0_m1_se"
(clobber (reg:CC FLAGS_REG))]
   ""
   "sbb{}\t%0, %0"
-  [(set_attr "type" "alu")
+  [(set_attr "type" "alu1")
(set_attr "modrm_class" "op0")
(set_attr "use_carry" "1")
(set_attr "pent_pair" "pu")
-   (set_attr "memory" "none")
-   (set_attr "imm_disp" "false")
(set_attr "mode" "")
(set_attr "length_immediate" "0")])
 
@@ -17934,12 +17928,10 @@ (define_insn "*x86_movcc_0_m1_neg"
(clobber (reg:CC FLAGS_REG))]
   ""
   "sbb{}\t%0, %0"
-  [(set_attr "type" "alu")
+  [(set_attr "type" "alu1")
(set_attr "modrm_class" "op0")
(set_attr "use_carry" "1")
(set_attr "pent_pair" "pu")
-   (set_attr "memory" "none")
-   (set_attr "imm_disp" "false")
(set_attr "mode" "")
(set_attr "length_immediate" "0")])
 

Jakub

Re: [PATCH], PR target/85358, Fix __ibm128 being converter to __float128 on PowerPC ISA 3.0 (power9)

[Michael Meissner]

On Mon, Apr 16, 2018 at 02:53:35PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Apr 16, 2018 at 01:41:29PM -0400, Michael Meissner wrote:
> > As I was working on PR target/85075 (to flesh some bugs with IEEE 128-bit
> > support on the PowerPC, particularly with switching the default of long
> > double), I noticed that for explicit IBM extended double, the compiler was
> > converting the __ibm128 type to an IEEE 128-bit type, because those types 
> > had
> > hardware support in ISA 3.0 (power9).
> > 
> > Unfortunately, IBM extended double (a pair of doubles meant to give you more
> > mantissa precision but not more expoenent range), is not completely
> > representable in IEEE 128-bit floating point.  There are likely some exposed
> > corner cases involved, and the bottom bits might not be the same.
> > 
> > While I would prefer IBM extended double to disappear entirely, I do think 
> > we
> > need to deal with it for a few versions still to come.
> 
> There are many subtargets that still need it, and nothing to change
> that has been planned.

Just to be clear, IBM extended double is fine, as long as you don't try to have
both IBM extended double and IEEE 128-bit support in the SAME program (and of
course, you can live with the various problems IBM extended double has).  The
main problem on the last 3 years has been that at its core, GCC believes there
should be only one floating point type for a given size.

> > I tried to come up with machine dependent ways to prevent the automatic
> > widening from occuring, but I couldn't get anything to work reliably.  This
> > patch adds a new target hook that says whether the automatic widening 
> > between
> > two modes should be allowed.  The default hook says to allow all of the 
> > default
> > widenings to occur, while the PowerPC override says IBM extended double does
> > not widen to IEEE 128-bit and vice versa.
> > 
> > Given we are in stage4 right now, it is not the time to add new hooks, but 
> > here
> > is the patch.  If it doesn't go into GCC 8, is it acceptable for being put
> > early into GCC 9 with a backport before 8.2 comes out?
> > 
> > I have tested this patch using bootstrap builds on a power8 little system, a
> > power7 big endian system (both 32-bit and 64-bit), and an x86_64 bit system
> > with no regressions.  
> 
> Can't you just set up things such that GET_MODE_WIDER_TYPE does not
> return ieee128 for ibm128?  With maybe a new hook yes, if that is
> necessary.

To me both are semantically the same.  Both involve adding a new hook, and
whether you change the macro or the calls, is a mattery of syntax.  As I
recall, when I first started doing __float128, there were one or two places
that wants to do wider types, but there you want to do it, even if the hook
says not to do automatic conversions.  You also don't want to outlaw explicit
conversions.

I can rewrite it if the global/release maintainers would prefer.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Fix type attr of x86 *ashlqi3_1_slp insn (PR target/85430)

[Uros Bizjak]

On Tue, Apr 17, 2018 at 6:39 PM, Jakub Jelinek  wrote:
> Hi!
>
> This define_insn has just 2 match_operands, so using alu type for it without
> defining memory attr is incorrect and can result in ICEs.
> My understanding is that alu1 is exactly what we want here.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-04-17  Jakub Jelinek  
>
> PR target/85430
> * config/i386/i386.md (*ashlqi3_1_slp): Use alu1 type instead of alu.
>
> * gcc.dg/pr85430.c: New test.

OK for trunk and backports.

Thanks,
Uros.

> --- gcc/config/i386/i386.md.jj  2018-04-05 20:34:31.989020754 +0200
> +++ gcc/config/i386/i386.md 2018-04-17 13:22:08.134050850 +0200
> @@ -10713,7 +10713,7 @@ (define_insn "*ashlqi3_1_slp"
>  {
>switch (get_attr_type (insn))
>  {
> -case TYPE_ALU:
> +case TYPE_ALU1:
>gcc_assert (operands[1] == const1_rtx);
>return "add{b}\t%0, %0";
>
> @@ -10729,12 +10729,12 @@ (define_insn "*ashlqi3_1_slp"
>   (cond [(and (and (match_test "TARGET_DOUBLE_WITH_ADD")
>   (match_operand 0 "register_operand"))
>  (match_operand 1 "const1_operand"))
> - (const_string "alu")
> + (const_string "alu1")
>]
>(const_string "ishift1")))
> (set (attr "length_immediate")
>   (if_then_else
> -   (ior (eq_attr "type" "alu")
> +   (ior (eq_attr "type" "alu1")
> (and (eq_attr "type" "ishift1")
>  (and (match_operand 1 "const1_operand")
>   (ior (match_test "TARGET_SHIFT1")
> --- gcc/testsuite/gcc.dg/pr85430.c.jj   2018-04-17 13:23:46.336087029 +0200
> +++ gcc/testsuite/gcc.dg/pr85430.c  2018-04-17 13:23:22.653078309 +0200
> @@ -0,0 +1,12 @@
> +/* PR target/85430 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-tree-ccp -fno-tree-fre" } */
> +
> +typedef char V __attribute__((vector_size (4)));
> +
> +V
> +foo (V v)
> +{
> +  v[(V){}[0]] <<= 1;
> +  return v;
> +}
>
> Jakub

[PATCH] Fix type attr of x86 *ashlqi3_1_slp insn (PR target/85430)

[Jakub Jelinek]

Hi!

This define_insn has just 2 match_operands, so using alu type for it without
defining memory attr is incorrect and can result in ICEs.
My understanding is that alu1 is exactly what we want here.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-04-17  Jakub Jelinek  

PR target/85430
* config/i386/i386.md (*ashlqi3_1_slp): Use alu1 type instead of alu.

* gcc.dg/pr85430.c: New test.

--- gcc/config/i386/i386.md.jj  2018-04-05 20:34:31.989020754 +0200
+++ gcc/config/i386/i386.md 2018-04-17 13:22:08.134050850 +0200
@@ -10713,7 +10713,7 @@ (define_insn "*ashlqi3_1_slp"
 {
   switch (get_attr_type (insn))
 {
-case TYPE_ALU:
+case TYPE_ALU1:
   gcc_assert (operands[1] == const1_rtx);
   return "add{b}\t%0, %0";
 
@@ -10729,12 +10729,12 @@ (define_insn "*ashlqi3_1_slp"
  (cond [(and (and (match_test "TARGET_DOUBLE_WITH_ADD")
  (match_operand 0 "register_operand"))
 (match_operand 1 "const1_operand"))
- (const_string "alu")
+ (const_string "alu1")
   ]
   (const_string "ishift1")))
(set (attr "length_immediate")
  (if_then_else
-   (ior (eq_attr "type" "alu")
+   (ior (eq_attr "type" "alu1")
(and (eq_attr "type" "ishift1")
 (and (match_operand 1 "const1_operand")
  (ior (match_test "TARGET_SHIFT1")
--- gcc/testsuite/gcc.dg/pr85430.c.jj   2018-04-17 13:23:46.336087029 +0200
+++ gcc/testsuite/gcc.dg/pr85430.c  2018-04-17 13:23:22.653078309 +0200
@@ -0,0 +1,12 @@
+/* PR target/85430 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-ccp -fno-tree-fre" } */
+
+typedef char V __attribute__((vector_size (4)));
+
+V
+foo (V v)
+{
+  v[(V){}[0]] <<= 1;
+  return v;
+}

Jakub

Re: [PATCH] PR 85075, Fix PowerPC __float182/__ibm128 types and mangling

[Michael Meissner]

On Tue, Apr 17, 2018 at 12:29:31PM -0400, Michael Meissner wrote:
> On Tue, Apr 17, 2018 at 09:57:52AM -0500, Segher Boessenkool wrote:
> > On Mon, Apr 16, 2018 at 03:22:16PM -0400, Michael Meissner wrote:
> > > Here is the PR 85075 patch without the rs6000.md bits:
> > 
> > This fails on powerpc64-linux bootstrap (w/ --with-cpu=power7 if that
> > matters):
> > 
> > /home/segher/src/gcc/libgcc/config/rs6000/ibm-ldouble.c: In function 
> > '__gcc_qadd
> > ':
> > /home/segher/src/gcc/libgcc/config/rs6000/ibm-ldouble.c:157:1: error: insn 
> > does 
> > not satisfy its constraints:
> >  }
> >  ^
> > (insn 144 197 198 15 (set (reg:TF 32 0 [orig:143 _47 ] [143])
> > (unspec:TF [
> > (reg:DF 33 1 [orig:143 _47+8 ] [143])
> > (reg/v:DF 36 4 [orig:139 xl ] [139])
> > ] UNSPEC_PACK_128BIT)) 
> > "/home/segher/src/gcc/libgcc/config/rs6000/ib
> > m-ldouble.c":106 1003 {packtf}
> >  (nil))
> > during RTL pass: reload
> 
> Yes, you need the patch for 85358 applied (which you've approved, but I 
> haven't
> checked in yet).  That in fact is why I needed to patch rs6000.md in the
> original patch.

Whoops, it is 85424, not 85835.

And note, you will get a lot of warnings when building libstc++-v3 with the PR
85075 patch, due to the new warning that __float128 changed the name mangling.
I probably should look to see if there is a way to add -Wno-psabi to the
libstdc++-v3 flags on the PowerPC.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[RFC PATCHES] Obsolete or remove powerpc*-*-*spe* support (PR target/81084)

[Jakub Jelinek]

Hi!

In the http://gcc.gnu.org/ml/gcc/2017-02/msg00041.html
thread it has been proposed that powerpc*-*-*spe* would be obsoleted in
GCC 7, which didn't happen and the rs6000 backend has been split into two,
one actively maintained where the SPE support has been removed, and the
other one which unfortunately had just a few small commits, didn't get rid
of the expected 80% of the new backend which would make it deal with it
for global changes in GCC, nor has the bugfixes added to rs6000 backend in
the last 11 months since the split (many of them apply to powerpcspe too).

So, in order to resolve the P1 PR81084, I think we should at least make the
powerpc*-*-*spe* obsolete for GCC 8 and remove in GCC 9 if it doesn't get
significantly better soon (the first patch), or remove it altogether now,
which would match the deal that either the port is cleaned up, or it is
removed (the second patch).  In addition to this some changes.html
changes will be needed depending on what is chosen.

Preferences on what to do?

Jakub
2018-04-17  Jakub Jelinek  

PR target/81084
* config.gcc: Obsolete powerpc*-*-*spe*.

--- gcc/config.gcc.jj   2018-04-09 20:15:49.172631651 +0200
+++ gcc/config.gcc  2018-04-16 17:50:55.978576645 +0200
@@ -236,7 +236,7 @@ md_file=
 
 # Obsolete configurations.
 case ${target} in
- nothing   \
+  powerpc*-*-*spe* \
  )
 if test "x$enable_obsolete" != xyes; then
   echo "*** Configuration ${target} is obsolete." >&2
2018-04-17  Jakub Jelinek  

PR target/81084
* config.gcc: Add powerpc*-*-*spe* to unsupported targets.  Remove
all other powerpc*-*-*spe* support snippets.
* config.host: Remove powerpc*-*-*spe* support.
* config/powerpcspe: Remove.
* common/config/powerpcspe: Remove.
libgcc/
* config.host: Remove powerpc-*-eabispe* support.
contrib/
* config-list.mk (LIST): Remove powerpc-eabispe and powerpc-linux_spe.

rm -rf gcc/config/powerpcspe gcc/common/config/powerpcspe
--- gcc/config.gcc.jj   2018-04-09 20:15:49.172631651 +0200
+++ gcc/config.gcc  2018-04-16 17:55:22.854747410 +0200
@@ -265,6 +265,7 @@ case ${target} in
  | m68k-*-uclinuxoldabi*   \
  | mips64orion*-*-rtems*   \
  | pdp11-*-bsd \
+ | powerpc*-*-*spe*\
  | sparc-hal-solaris2* \
  | thumb-*-*   \
  | *-*-freebsd[12] | *-*-freebsd[12].* \
@@ -454,16 +455,6 @@ nios2-*-*)
 nvptx-*-*)
cpu_type=nvptx
;;
-powerpc*-*-*spe*)
-   cpu_type=powerpcspe
-   extra_headers="ppc-asm.h altivec.h spe.h ppu_intrinsics.h paired.h 
spu2vmx.h vec_types.h si2vmx.h htmintrin.h htmxlintrin.h"
-   case x$with_cpu in
-   
xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456789]|xpower6x|xrs64a|xcell|xa2|xe500mc64|xe5500|xe6500)
-   cpu_is_64bit=yes
-   ;;
-   esac
-   extra_options="${extra_options} g.opt fused-madd.opt 
powerpcspe/powerpcspe-tables.opt"
-   ;;
 powerpc*-*-*)
cpu_type=rs6000
extra_objs="rs6000-string.o rs6000-p8swap.o"
@@ -2422,12 +2413,6 @@ powerpc-*-netbsd*)
tmake_file="${tmake_file} rs6000/t-netbsd"
extra_options="${extra_options} rs6000/sysv4.opt"
;;
-powerpc-*-eabispe*)
-   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h 
${cpu_type}/sysv4.h ${cpu_type}/eabi.h ${cpu_type}/e500.h ${cpu_type}/eabispe.h"
-   extra_options="${extra_options} ${cpu_type}/sysv4.opt"
-   tmake_file="${cpu_type}/t-spe ${cpu_type}/t-ppccomm"
-   use_gcc_stdint=wrap
-   ;;
 powerpc-*-eabisimaltivec*)
tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h 
rs6000/sysv4.h rs6000/eabi.h rs6000/eabisim.h rs6000/eabialtivec.h"
extra_options="${extra_options} rs6000/sysv4.opt"
@@ -2463,26 +2448,11 @@ powerpc-*-eabi*)
tmake_file="rs6000/t-fprules rs6000/t-ppcgas rs6000/t-ppccomm"
use_gcc_stdint=wrap
;;
-powerpc-*-rtems*spe*)
-   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h 
powerpcspe/sysv4.h powerpcspe/eabi.h powerpcspe/e500.h powerpcspe/rtems.h 
rtems.h"
-   extra_options="${extra_options} powerpcspe/sysv4.opt"
-   tmake_file="${tmake_file} powerpcspe/t-fprules powerpcspe/t-rtems 
powerpcspe/t-ppccomm"
-   ;;
 powerpc-*-rtems*)
tm_file="rs6000/biarch64.h ${tm_file} dbxelf.h elfos.h freebsd-spec.h 
newlib-stdint.h rs6000/sysv4.h rs6000/rtems.h rtems.h"
extra_options="${extra_options} rs6000/sysv4.opt rs6000/linux64.opt"
tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems 
rs6000/t-ppccomm"
;;
-powerpc*-*-linux*spe*)
-   tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h freebsd-spec.h 
powerpcspe/sysv4.h"
-   extra_options="${extra_options} powerpcspe/sysv4.opt"
-   tmake_file="${tmake_file} powerpcspe/t-fprules powerpcspe/t-ppcco

[C++ PATCH] Fix constexpr handling of &x->y (PR c++/84463, take 2)

[Jakub Jelinek]

On Mon, Apr 16, 2018 at 10:55:34PM +, Jason Merrill wrote:
> On Mon, Apr 16, 2018, 1:31 PM Jakub Jelinek  wrote:
> 
> > On Mon, Apr 16, 2018 at 09:28:43PM +0200, Jakub Jelinek wrote:
> > > On the following new testcase we emit 2 different constexpr errors
> > > because of premature folding, where the PR44100 hack which is supposed
> > > to fold expressions like &((S *)0)->f or
> > > &((S *)24)->f folds all the &x->y expressions if x is TREE_CONSTANT
> > > into (some type)(x + cst) where what we were actually trying to access
> > > is lost.
> > >
> > > The following patch limits the offsetof-like expression hack to
> > expressions
> > > where maybe_constant_value of val's operand is INTEGER_CST, or e.g.
> > > a cast of INTEGER_CST to some pointer type.  This way we don't regress
> > > e.g. init/struct2.C, but don't mess up with x is e.g. some constexpr
> > > variable initialized to address of something.  Or should it avoid
> > > maybe_constant_value and just handle the literal INTEGER_CST and cast
> > > thereof?  We wouldn't handle &((S *)(24 + 8))->f that way though...
> >
> > Or shall we move this folding to cp_fold instead of cp_build_addr_expr_1
> > (while keeping it limited to INTEGER_CST pointers)?
> 
> 
> Yes, I think that would be better.

Ok, here is a patch that does that.  Compared to previous patch, the -O1 for
constexpr-nullptr-1.C is still needed, there is different diagnostics
(dereference of null) in constexpr-nullptr-2.C on two lines and two lines
that were commented due to this hack can now be handled.  Similarly,
array-size2.C XPASSes now, so removed the xfail in there.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-04-17  Jakub Jelinek  

PR c++/84463
* typeck.c (cp_build_addr_expr_1): Move handling of offsetof-like
tricks from here to ...
* cp-gimplify.c (cp_fold) : ... here.  Only use it
if INDIRECT_REF's operand is INTEGER_CST cast to pointer type.

* g++.dg/cpp0x/constexpr-nullptr-1.C: Add -O1 to dg-options.
* g++.dg/cpp0x/constexpr-nullptr-2.C: Expect different diagnostics
in two cases.  Uncomment two other tests and add expected dg-error for
them.
* g++.dg/init/struct2.C: Cast to int rather than long to avoid
-Wnarrowing diagnostics on some targets for c++11.
* g++.dg/parse/array-size2.C: Remove xfail.
* g++.dg/cpp0x/constexpr-84463.C: New test.

--- gcc/cp/typeck.c.jj  2018-04-17 11:09:13.887127384 +0200
+++ gcc/cp/typeck.c 2018-04-17 18:00:17.616039746 +0200
@@ -5893,19 +5893,6 @@ cp_build_addr_expr_1 (tree arg, bool str
   return arg;
 }
 
-  /* ??? Cope with user tricks that amount to offsetof.  */
-  if (TREE_CODE (argtype) != FUNCTION_TYPE
-  && TREE_CODE (argtype) != METHOD_TYPE
-  && argtype != unknown_type_node
-  && (val = get_base_address (arg))
-  && COMPLETE_TYPE_P (TREE_TYPE (val))
-  && INDIRECT_REF_P (val)
-  && TREE_CONSTANT (TREE_OPERAND (val, 0)))
-{
-  tree type = build_pointer_type (argtype);
-  return fold_convert (type, fold_offsetof_1 (arg));
-}
-
   /* Handle complex lvalues (when permitted)
  by reduction to simpler cases.  */
   val = unary_complex_lvalue (ADDR_EXPR, arg);
--- gcc/cp/cp-gimplify.c.jj 2018-04-17 11:09:13.886127383 +0200
+++ gcc/cp/cp-gimplify.c2018-04-17 18:00:17.626039748 +0200
@@ -2215,6 +2215,28 @@ cp_fold (tree x)
   goto unary;
 
 case ADDR_EXPR:
+  loc = EXPR_LOCATION (x);
+  op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), false);
+
+  /* Cope with user tricks that amount to offsetof.  */
+  if (op0 != error_mark_node
+ && TREE_CODE (TREE_TYPE (op0)) != FUNCTION_TYPE
+ && TREE_CODE (TREE_TYPE (op0)) != METHOD_TYPE)
+   {
+ tree val = get_base_address (op0);
+ if (val
+ && INDIRECT_REF_P (val)
+ && COMPLETE_TYPE_P (TREE_TYPE (val))
+ && TREE_CONSTANT (TREE_OPERAND (val, 0)))
+   {
+ val = TREE_OPERAND (val, 0);
+ STRIP_NOPS (val);
+ if (TREE_CODE (val) == INTEGER_CST)
+   return fold_convert (TREE_TYPE (x), fold_offsetof_1 (op0));
+   }
+   }
+  goto finish_unary;
+
 case REALPART_EXPR:
 case IMAGPART_EXPR:
   rval_ops = false;
@@ -2232,6 +2254,7 @@ cp_fold (tree x)
   loc = EXPR_LOCATION (x);
   op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), rval_ops);
 
+finish_unary:
   if (op0 != TREE_OPERAND (x, 0))
{
  if (op0 == error_mark_node)
--- gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C.jj 2018-04-17 
11:09:13.697127292 +0200
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C2018-04-17 
18:00:17.705039771 +0200
@@ -6,7 +6,7 @@
 // c++/67376 on gcc-patches for additional background.
 
 // { dg-do compile { target c++11 } }
-// { dg-options "-fdelete-null-pointer-checks -fdump-tree-optimized" }
+// { dg-options "-O1 -

Re: [PATCH] PR 85075, Fix PowerPC __float182/__ibm128 types and mangling

[Michael Meissner]

On Tue, Apr 17, 2018 at 09:57:52AM -0500, Segher Boessenkool wrote:
> On Mon, Apr 16, 2018 at 03:22:16PM -0400, Michael Meissner wrote:
> > Here is the PR 85075 patch without the rs6000.md bits:
> 
> This fails on powerpc64-linux bootstrap (w/ --with-cpu=power7 if that
> matters):
> 
> /home/segher/src/gcc/libgcc/config/rs6000/ibm-ldouble.c: In function 
> '__gcc_qadd
> ':
> /home/segher/src/gcc/libgcc/config/rs6000/ibm-ldouble.c:157:1: error: insn 
> does 
> not satisfy its constraints:
>  }
>  ^
> (insn 144 197 198 15 (set (reg:TF 32 0 [orig:143 _47 ] [143])
> (unspec:TF [
> (reg:DF 33 1 [orig:143 _47+8 ] [143])
> (reg/v:DF 36 4 [orig:139 xl ] [139])
> ] UNSPEC_PACK_128BIT)) 
> "/home/segher/src/gcc/libgcc/config/rs6000/ib
> m-ldouble.c":106 1003 {packtf}
>  (nil))
> during RTL pass: reload

Yes, you need the patch for 85358 applied (which you've approved, but I haven't
checked in yet).  That in fact is why I needed to patch rs6000.md in the
original patch.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Document some arch-specific operand modifiers

[Borislav Petkov]

On Wed, Mar 14, 2018 at 05:35:21PM +0100, Borislav Petkov wrote:
> Hi,
> 
> here's an attempt to document some of the inline asm operand modifiers
> which make sense and which get used so that people can find what they
> mean in the docs.
> 
> This is my first gcc patch so there might be clumsiness ahead. :)
> 
> Thanks,
> Boris.
> 
> gcc/Changelog:
> 
> 2018-03-14  Borislav Petkov  
> 
>* gcc/doc/extend.texi: document some arch-specific asm operand 
> modifiers
>  and sort entries.
>* gcc/config/i386/i386.c: fix typo.

Looks forgotten, lemme ping people...

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH][AArch64/arm] PR testsuite/85326 Avoid C++ tests when C++ compiler not present

[Kyrill Tkachov]

Hi all,

This patch makes the arm and aarch64 testsuite safe for when a C++ compiler is 
not present.
This involves moving .C files into g++.dg/other/ and guarding them with the 
appropriate target check.

For others it just means renaming them from .C to .c.

For gcc.target/aarch64/simd/pr67896.C this means adjusting the error messages 
to look
for the errors that the C frontend gives for conflicting types rather than what 
C++ gives.

This fixes the errors seen when testing a non-bootstrapped C-only GCC and the 
tests
still pass on normal testing setups and the tests that are in g++.dg appear 
UNSUPPORTED
on the targets that they don't pertain to.

Tested this on arm-none-linux-gnueabihf and aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

2018-04-17  Kyrylo Tkachov  

PR testsuite/85326
* gcc.target/arm/pr54300.C: Move to...
* g++.dg/other/pr54300.C: ... Here.  Add target directives.
* gcc.target/arm/pr55073.C: Move to...
* g++.dg/other/pr55073.C: ... Here.  Add target directives.
* gcc.target/arm/pr56184.C: Move to...
* g++.dg/other/pr56184.C: ... Here.  Add target directives.
* gcc.target/arm/pr59985.C: Move to...
* g++.dg/other/pr59985.C: ... Here.  Add target directives.
* gcc.target/aarch64/pr60675.C: Move to...
* g++.dg/other/pr60675.C: ... Here.  Add target directives.
* gcc.target/aarch64/pr81422.C: Move to...
* g++.dg/other/pr81422.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/const_pred_1.C: Move to...
* g++.dg/other/sve_const_pred_1.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/const_pred_2.C: Move to...
* g++.dg/other/sve_const_pred_2.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/const_pred_3.C: Move to...
* g++.dg/other/sve_const_pred_3.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/const_pred_4.C: Move to...
* g++.dg/other/sve_const_pred_4.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/tls_2.C: Move to...
* g++.dg/other/sve_tls_2.C: ... Here.  Add target directives.
* gcc.target/aarch64/pr81414.C: Rename to...
* gcc.target/aarch64/pr81414.c: ... This.
* gcc.target/aarch64/simd/pr67896.C: Rename to...
* gcc.target/aarch64/simd/pr67896.c: ... This.  Update error expected
messages.
* gcc.target/aarch64/sve/vcond_1.C: Rename to...
* gcc.target/aarch64/sve/vcond_1.c: ... This.  Avoid use of stdint.h.
* gcc.target/aarch64/sve/vcond_1_run.C: Rename to...
* gcc.target/aarch64/sve/vcond_1_run.c: ... This.  Update include
file name.
diff --git a/gcc/testsuite/gcc.target/aarch64/pr60675.C b/gcc/testsuite/g++.dg/other/pr60675.C
similarity index 99%
rename from gcc/testsuite/gcc.target/aarch64/pr60675.C
rename to gcc/testsuite/g++.dg/other/pr60675.C
index aa88cdb240358629d2be575297c2acc957364f23..11001559147db822041a8b806a8d30b6e99a785c 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr60675.C
+++ b/gcc/testsuite/g++.dg/other/pr60675.C
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target fpic } } */
 /* { dg-options "-std=c++11 -w -O2 -fPIC" } */
 namespace CLHEP {
   static const double meter = 1000.*10;
diff --git a/gcc/testsuite/gcc.target/aarch64/pr81414.C b/gcc/testsuite/gcc.target/aarch64/pr81414.c
similarity index 100%
rename from gcc/testsuite/gcc.target/aarch64/pr81414.C
rename to gcc/testsuite/gcc.target/aarch64/pr81414.c
diff --git a/gcc/testsuite/gcc.target/aarch64/pr81422.C b/gcc/testsuite/g++.dg/other/pr81422.C
similarity index 100%
rename from gcc/testsuite/gcc.target/aarch64/pr81422.C
rename to gcc/testsuite/g++.dg/other/pr81422.C
diff --git a/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C b/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
deleted file mode 100644
index 1f916e09f4fc6b10f40fb3c84134f3c3f135c68d..
--- a/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
+++ /dev/null
@@ -1,7 +0,0 @@
-typedef __Poly8_t A;
-typedef __Poly16_t A; /* { dg-error "conflicting declaration" } */
-typedef __Poly64_t A; /* { dg-error "conflicting declaration" } */
-typedef __Poly128_t A; /* { dg-error "conflicting declaration" } */
-
-typedef __Poly8x8_t B;
-typedef __Poly16x8_t B; /* { dg-error "conflicting declaration" } */ 
diff --git a/gcc/testsuite/gcc.target/aarch64/simd/pr67896.c b/gcc/testsuite/gcc.target/aarch64/simd/pr67896.c
new file mode 100644
index ..3e27bea0e952368c46afbad760c22811f369db06
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/simd/pr67896.c
@@ -0,0 +1,7 @@
+typedef __Poly8_t A;
+typedef __Poly16_t A; /* { dg-error "conflicting types" } */
+typedef __Poly64_t A; /* { dg-error "conflicting types" } */
+typedef __Poly128_t A; /* { dg-error "conflicting types" } */
+
+typedef __Poly8x8_t B;
+typedef __Poly16x8_t B; /* { dg-error "conflicting types" } */
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/const_pred_1.C b/gcc/testsuite/g++.dg/other/sve_const_pred_1.C

Re: [PATCH] PR 85075, Fix PowerPC __float182/__ibm128 types and mangling

[Segher Boessenkool]

On Mon, Apr 16, 2018 at 03:22:16PM -0400, Michael Meissner wrote:
> Here is the PR 85075 patch without the rs6000.md bits:

This fails on powerpc64-linux bootstrap (w/ --with-cpu=power7 if that
matters):

/home/segher/src/gcc/libgcc/config/rs6000/ibm-ldouble.c: In function '__gcc_qadd
':
/home/segher/src/gcc/libgcc/config/rs6000/ibm-ldouble.c:157:1: error: insn does 
not satisfy its constraints:
 }
 ^
(insn 144 197 198 15 (set (reg:TF 32 0 [orig:143 _47 ] [143])
(unspec:TF [
(reg:DF 33 1 [orig:143 _47+8 ] [143])
(reg/v:DF 36 4 [orig:139 xl ] [139])
] UNSPEC_PACK_128BIT)) "/home/segher/src/gcc/libgcc/config/rs6000/ib
m-ldouble.c":106 1003 {packtf}
 (nil))
during RTL pass: reload


Segher


>   PR target/85075
>   * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): __ibm128 is
>   now a separate type, don't #define __ibm128 as long double.
>   * config/rs6000/rs6000.c (rs6000_init_builtins): Make __ibm128 a
>   separate type on systems that support IEEE 128-bit floating point.
>   (rs6000_mangle_type): Use separate manglings for __ibm128 and
>   __float128.  Change __float128 mangling from U10__float128 to
>   u10__float128.  Issue a warning that the mangling has changed in
>   GCC 8.

libbacktrace patch committed: Call munmap after memory test

[Ian Lance Taylor]

The bug report https://github.com/ianlancetaylor/libbacktrace/issues/13
points out that when backtrace_full checks whether memory is
available, it doesn't necessarily release that memory.  It will stay
on the free list, so libbacktrace will use more and more memory over
time.  This patch fixes that problem by explicitly calling munmap.
Bootstrapped and ran libbacktrace and Go tests on x86_64-pc-linux-gnu.
Committed to mainline.

Ian


2018-04-17  Ian Lance Taylor  

* backtrace.c (backtrace_full): When testing whether we can
allocate memory, call mmap directly, and munmap the memory.
Index: backtrace.c
===
--- backtrace.c (revision 259359)
+++ backtrace.c (working copy)
@@ -32,12 +32,26 @@ POSSIBILITY OF SUCH DAMAGE.  */
 
 #include "config.h"
 
+#include 
 #include 
 
+#if !BACKTRACE_USES_MALLOC
+#include 
+#endif
+
 #include "unwind.h"
 #include "backtrace.h"
+#include "backtrace-supported.h"
 #include "internal.h"
 
+#ifndef MAP_ANONYMOUS
+#define MAP_ANONYMOUS MAP_ANON
+#endif
+
+#ifndef MAP_FAILED
+#define MAP_FAILED ((void *)-1)
+#endif
+
 /* The main backtrace_full routine.  */
 
 /* Data passed through _Unwind_Backtrace.  */
@@ -104,7 +118,6 @@ backtrace_full (struct backtrace_state *
backtrace_error_callback error_callback, void *data)
 {
   struct backtrace_data bdata;
-  void *p;
 
   bdata.skip = skip + 1;
   bdata.state = state;
@@ -113,16 +126,25 @@ backtrace_full (struct backtrace_state *
   bdata.data = data;
   bdata.ret = 0;
 
-  /* If we can't allocate any memory at all, don't try to produce
- file/line information.  */
-  p = backtrace_alloc (state, 4096, NULL, NULL);
-  if (p == NULL)
-bdata.can_alloc = 0;
-  else
-{
-  backtrace_free (state, p, 4096, NULL, NULL);
-  bdata.can_alloc = 1;
-}
+#if !BACKTRACE_USES_MALLOC
+  {
+size_t pagesize;
+void *page;
+
+/* If we can't allocate any memory at all, don't try to produce
+   file/line information.  */
+pagesize = getpagesize ();
+page = mmap (NULL, pagesize, PROT_READ | PROT_WRITE, 
+MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+if (page == MAP_FAILED)
+  bdata.can_alloc = 0;
+else
+  {
+   munmap (page, pagesize);
+   bdata.can_alloc = 1;
+  }
+  }
+#endif
 
   _Unwind_Backtrace (unwind, &bdata);
   return bdata.ret;

Re: [PATCH] Fix gen_lowpart_if_possible (PR middle-end/85414)

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 11:00:35AM +0200, Eric Botcazou wrote:
> Right, they were originally alike, but someone you know very well changed it:
> 
> 2013-12-17  Jakub Jelinek  
> 
>   * expr.c (convert_modes): For SUBREG_PROMOTED_VAR_P use SUBREG_REG (x)
>   instead of x as last gen_lowpart argument.

Heh, https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01455.html

> 
> > 2018-04-17  Jakub Jelinek  
> > 
> > PR middle-end/85414
> > * simplify-rtx.c (simplify_unary_operation_1)  > case ZERO_EXTEND>: Pass SUBREG_REG (op) rather than op to
> > gen_lowpart_no_emit.
> > * rtlhooks.c (gen_lowpart_if_possible): Don't call gen_lowpart_SUBREG
> > on a SUBREG.
> > 
> > * gcc.dg/pr85414.c: New test.
> 
> I'd say, either we change both convert_move and simplify-rtx.c for GCC 8 or 
> we 
> change none of them.  You're the RM so it's more of your call than mine.

Ok, I'll commit the first patch then and change all 3 spots (expr.c and 2x
simplify-rtx.c) for GCC 9 then.

Jakub

Re: RFC: C++ PATCH for c++/69763, making C++ alignof match C _Alignof

[Joseph Myers]

On Wed, 11 Apr 2018, Jason Merrill wrote:

> On Tue, Apr 10, 2018 at 1:12 PM, Jason Merrill  wrote:
> > But really this is beside the point: the x86 ABI says that the
> > alignment of double is 4, so alignof(double) should be 4 regardless of
> > what GCC wants to do internally.  And I think the same is true of
> > __alignof__.
> 
> Particularly since the description of __alignof__ has been clarified:
> 
> "Some machines never actually require alignment; they allow reference
> to any data type even at an odd address.  For these machines,
> '__alignof__' reports the smallest alignment that GCC gives the data
> type, usually as mandated by the target ABI."

That text seems inaccurate in the x86 double / long long case; it should 
reflect the preferred alignment of the type for a standalone object.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: RFC: C++ PATCH for c++/69763, making C++ alignof match C _Alignof

[Joseph Myers]

On Tue, 10 Apr 2018, Jason Merrill wrote:

> But really this is beside the point: the x86 ABI says that the
> alignment of double is 4, so alignof(double) should be 4 regardless of
> what GCC wants to do internally.  And I think the same is true of
> __alignof__.

__alignof__ needs to stay reflecting the preferred, standalone alignment 
of 8 bytes; changing that is ABI-incompatible; code such as that in 
stddef.h uses __attribute__((__aligned__(__alignof__(long long to give 
structure members the same alignment those types would have for standalone 
objects.  (This doesn't affect the alignment of max_align_t *now* on i386, 
but only because that now includes __float128 as well.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Martin Liška]

On 04/17/2018 10:33 AM, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 10:29:35AM +0200, Martin Liška wrote:
>> On 04/17/2018 10:28 AM, Martin Liška wrote:
>>> I'm sending patch candidate.
>>
>> This one is the right one.
> 
> Ok for stage1 with appropriate ChangeLog entries.
> 
>   Jakub
> 

Good, thanks. There's version I'll install once we flip into stage1 again.

Martin
>From 93b53a0f55ebf4df7a96c620408af19546c7fc3a Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 17 Apr 2018 10:47:36 +0200
Subject: [PATCH] Fix GNU coding style for G_.

gcc/ChangeLog:

2018-04-17  Martin Liska  

	* gimple-ssa-sprintf.c (format_directive): Do not use
	space in between 'G_' and '('.

gcc/c-family/ChangeLog:

2018-04-17  Martin Liska  

	* c-warn.c (overflow_warning): Do not use
	space in between 'G_' and '('.

gcc/testsuite/ChangeLog:

2018-04-17  Martin Liska  

	* gcc.dg/plugin/ggcplug.c (plugin_init): Do not use
	space in between 'G_' and '('.
---
 gcc/c-family/c-warn.c |  8 
 gcc/gimple-ssa-sprintf.c  | 12 ++--
 gcc/testsuite/gcc.dg/plugin/ggcplug.c | 16 
 3 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index d0d9c7894a8..2614eb58f14 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -98,10 +98,10 @@ overflow_warning (location_t loc, tree value, tree expr)
 
 case REAL_CST:
   warnfmt = (expr
-		 ? G_ ("floating point overflow in expression %qE "
-		   "of type %qT results in %qE")
-		 : G_ ("floating point overflow in expression of type %qT "
-		   "results in %qE"));
+		 ? G_("floating point overflow in expression %qE "
+		  "of type %qT results in %qE")
+		 : G_("floating point overflow in expression of type %qT "
+		  "results in %qE"));
   break;
 
 case FIXED_CST:
diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 4ec58605ce8..ec5e7046f6e 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -2933,12 +2933,12 @@ format_directive (const sprintf_dom_walker::call_info &info,
   else
 	warned = fmtwarn (dirloc, argloc, NULL, info.warnopt (),
 			  fmtres.range.min > target_int_max ()
-			  ? G_ ("%<%.*s%> directive output between %wu and "
-"%wu bytes causes result to exceed "
-"%")
-			  : G_ ("%<%.*s%> directive output between %wu and "
-"%wu bytes may cause result to exceed "
-"%"), dirlen,
+			  ? G_("%<%.*s%> directive output between %wu and "
+			   "%wu bytes causes result to exceed "
+			   "%")
+			  : G_("%<%.*s%> directive output between %wu and "
+			   "%wu bytes may cause result to exceed "
+			   "%"), dirlen,
 			  target_to_host (hostdir, sizeof hostdir, dir.beg),
 			  fmtres.range.min, fmtres.range.max);
 }
diff --git a/gcc/testsuite/gcc.dg/plugin/ggcplug.c b/gcc/testsuite/gcc.dg/plugin/ggcplug.c
index c4bc334868b..c186d119371 100644
--- a/gcc/testsuite/gcc.dg/plugin/ggcplug.c
+++ b/gcc/testsuite/gcc.dg/plugin/ggcplug.c
@@ -64,8 +64,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   if (!strcmp (argv[i].key, "count-ggc-start"))
 	{
 	  if (argv[i].value)
-	warning (0, G_ ("option '-fplugin-arg-%s-count-ggc-start=%s'"
-			" ignored (superfluous '=%s')"),
+	warning (0, G_("option '-fplugin-arg-%s-count-ggc-start=%s'"
+			   " ignored (superfluous '=%s')"),
 		 plugin_name, argv[i].value, argv[i].value);
 	  else
 	register_callback ("ggcplug",
@@ -76,8 +76,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   else if (!strcmp (argv[i].key, "count-ggc-end"))
 	{
 	  if (argv[i].value)
-	warning (0, G_ ("option '-fplugin-arg-%s-count-ggc-end=%s'"
-			" ignored (superfluous '=%s')"),
+	warning (0, G_("option '-fplugin-arg-%s-count-ggc-end=%s'"
+			   " ignored (superfluous '=%s')"),
 		 plugin_name, argv[i].value, argv[i].value);
 	  else
 	register_callback ("ggcplug",
@@ -88,8 +88,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   else if (!strcmp (argv[i].key, "count-ggc-mark"))
 	{
 	  if (argv[i].value)
-	warning (0, G_ ("option '-fplugin-arg-%s-count-ggc-mark=%s'"
-			" ignored (superfluous '=%s')"),
+	warning (0, G_("option '-fplugin-arg-%s-count-ggc-mark=%s'"
+			   " ignored (superfluous '=%s')"),
 		 plugin_name, argv[i].value, argv[i].value);
 	  else
 	register_callback ("ggcplug",
@@ -100,8 +100,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   else if (!strcmp (argv[i].key, "test-extra-root"))
 	{
 	  if (argv[i].value)
-	warning (0, G_ ("option '-fplugin-arg-%s-test-extra-root=%s'"
-			" ignored (superfluous '=%s')"),
+	warning (0, G_("option '-fplugin-arg-%s-test-extra-root=%s'"
+			   " ignored (superfluous '=%s')"),
 		 plugin_name, argv[i].value, argv[i].value);
 	  else
 	register_callback ("ggcplug",
-- 
2.16.3

Re: [PATCH] Fix gen_lowpart_if_possible (PR middle-end/85414)

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 09:32:31AM +0200, Eric Botcazou wrote:
> > The following testcase FAILs, because cse_local sees
> > (zero_extend:TI (subreg/s/v:DI (reg:TI ...) 0))
> > inside of REG_EQUAL note, and simplify-rtx.c attempts to optimize it.
> > case ZERO_EXTEND:
> >   /* Check for a zero extension of a subreg of a promoted
> >  variable, where the promotion is zero-extended, and the
> >  target mode is the same as the variable's promotion.  */
> >   if (GET_CODE (op) == SUBREG
> >   && SUBREG_PROMOTED_VAR_P (op)
> >   && SUBREG_PROMOTED_UNSIGNED_P (op)
> >   && !paradoxical_subreg_p (mode, GET_MODE (SUBREG_REG (op
> > {
> >   temp = rtl_hooks.gen_lowpart_no_emit (mode, op);
> >   if (temp)
> > return temp;
> > }
> 
> This code is strange though, here's the equivalent one in convert_modes:
> 
>   if (GET_CODE (x) == SUBREG
>   && SUBREG_PROMOTED_VAR_P (x)
>   && is_a  (mode, &int_mode)
>   && (GET_MODE_PRECISION (subreg_promoted_mode (x))
> >= GET_MODE_PRECISION (int_mode))
>   && SUBREG_CHECK_PROMOTED_SIGN (x, unsignedp))
> x = gen_lowpart (int_mode, SUBREG_REG (x));

Yes, convert_modes does this, on the other side e.g. convert_move a few
hundred lines above it doesn't:
  if (GET_CODE (from) == SUBREG
  && SUBREG_PROMOTED_VAR_P (from)
  && is_a  (to_mode, &to_int_mode)
  && (GET_MODE_PRECISION (subreg_promoted_mode (from))
  >= GET_MODE_PRECISION (to_int_mode))
  && SUBREG_CHECK_PROMOTED_SIGN (from, unsignedp))
from = gen_lowpart (to_int_mode, from), from_mode = to_int_mode;

> so can't we just pass SUBREG_REG (op) here?  Same for SIGN_EXTEND above.

The following patch works for the testcase too (even with the rtlhooks.c
hunk removed, but I think we want to keep it anyway, even when we lose the
only known testcase where it matters).  We generate the same assembly,
though it behaves differently.  With the previous patch we have:
(zero_extend:TI (subreg/s/v:DI (reg:TI 94) 0))
in the REG_EQUAL note, then subreg2 makes (zero_extend:TI (reg:DI 146))
out of it and in the end nothing uses the REG_EQUAL note.
With this patch, we have instead (reg:TI 94) in the REG_EQUAL note and
subreg2 pass drops the REG_EQUAL note, so nothing can use it even if it
wanted.

Anyway, if this is what is preferred, ok for trunk if it passes
bootstrap/regtest?

2018-04-17  Jakub Jelinek  

PR middle-end/85414
* simplify-rtx.c (simplify_unary_operation_1) : Pass SUBREG_REG (op) rather than op to
gen_lowpart_no_emit.
* rtlhooks.c (gen_lowpart_if_possible): Don't call gen_lowpart_SUBREG
on a SUBREG.

* gcc.dg/pr85414.c: New test.

--- gcc/simplify-rtx.c.jj   2018-04-13 21:38:39.924432794 +0200
+++ gcc/simplify-rtx.c  2018-04-17 10:37:57.559193098 +0200
@@ -1484,7 +1484,7 @@ simplify_unary_operation_1 (enum rtx_cod
  && SUBREG_PROMOTED_SIGNED_P (op)
  && !paradoxical_subreg_p (mode, GET_MODE (SUBREG_REG (op
{
- temp = rtl_hooks.gen_lowpart_no_emit (mode, op);
+ temp = rtl_hooks.gen_lowpart_no_emit (mode, SUBREG_REG (op));
  if (temp)
return temp;
}
@@ -1567,7 +1567,7 @@ simplify_unary_operation_1 (enum rtx_cod
  && SUBREG_PROMOTED_UNSIGNED_P (op)
  && !paradoxical_subreg_p (mode, GET_MODE (SUBREG_REG (op
{
- temp = rtl_hooks.gen_lowpart_no_emit (mode, op);
+ temp = rtl_hooks.gen_lowpart_no_emit (mode, SUBREG_REG (op));
  if (temp)
return temp;
}
--- gcc/rtlhooks.c.jj   2018-04-16 18:11:54.791378162 +0200
+++ gcc/rtlhooks.c  2018-04-17 10:39:43.263246431 +0200
@@ -123,9 +123,9 @@ gen_lowpart_if_possible (machine_mode mo
 
   return new_rtx;
 }
-  else if (mode != GET_MODE (x) && GET_MODE (x) != VOIDmode
+  else if (mode != GET_MODE (x) && GET_MODE (x) != VOIDmode && !SUBREG_P (x)
   && validate_subreg (mode, GET_MODE (x), x,
-   subreg_lowpart_offset (mode, GET_MODE (x
+  subreg_lowpart_offset (mode, GET_MODE (x
 return gen_lowpart_SUBREG (mode, x);
   else
 return 0;
--- gcc/testsuite/gcc.dg/pr85414.c.jj   2018-04-17 10:21:55.531391008 +0200
+++ gcc/testsuite/gcc.dg/pr85414.c  2018-04-17 10:21:55.531391008 +0200
@@ -0,0 +1,10 @@
+/* PR middle-end/85414 */
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-Og -fgcse -Wno-uninitialized" } */
+
+int
+foo (void)
+{
+  unsigned __int128 c;
+  return __builtin_mul_overflow_p (59, -c, (short) 0);
+}


Jakub

Re: [PATCH] Fix gen_lowpart_if_possible (PR middle-end/85414)

[Eric Botcazou]

> Yes, convert_modes does this, on the other side e.g. convert_move a few
> hundred lines above it doesn't:
>   if (GET_CODE (from) == SUBREG
>   && SUBREG_PROMOTED_VAR_P (from)
>   && is_a  (to_mode, &to_int_mode)
>   && (GET_MODE_PRECISION (subreg_promoted_mode (from))
> 
>   >= GET_MODE_PRECISION (to_int_mode))
> 
>   && SUBREG_CHECK_PROMOTED_SIGN (from, unsignedp))
> from = gen_lowpart (to_int_mode, from), from_mode = to_int_mode;

Right, they were originally alike, but someone you know very well changed it:

2013-12-17  Jakub Jelinek  

* expr.c (convert_modes): For SUBREG_PROMOTED_VAR_P use SUBREG_REG (x)
instead of x as last gen_lowpart argument.

> 2018-04-17  Jakub Jelinek  
> 
>   PR middle-end/85414
>   * simplify-rtx.c (simplify_unary_operation_1)case ZERO_EXTEND>: Pass SUBREG_REG (op) rather than op to
>   gen_lowpart_no_emit.
>   * rtlhooks.c (gen_lowpart_if_possible): Don't call gen_lowpart_SUBREG
>   on a SUBREG.
> 
>   * gcc.dg/pr85414.c: New test.

I'd say, either we change both convert_move and simplify-rtx.c for GCC 8 or we 
change none of them.  You're the RM so it's more of your call than mine.

-- 
Eric Botcazou

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 10:17:15AM +0200, Martin Liška wrote:
> Sure. I see other format violations, should I fix that in follow up patch:
> 
> gcc/c-family/c-warn.c:   ? G_ ("floating point overflow in expression 
> %qE "
> gcc/c-family/c-warn.c:   : G_ ("floating point overflow in expression 
> of type %qT "
> gcc/gimple-ssa-sprintf.c: ? G_ ("%<%.*s%> directive 
> output between %wu and "
> gcc/gimple-ssa-sprintf.c: : G_ ("%<%.*s%> directive 
> output between %wu and "
> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
> '-fplugin-arg-%s-count-ggc-start=%s'"
> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
> '-fplugin-arg-%s-count-ggc-end=%s'"
> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
> '-fplugin-arg-%s-count-ggc-mark=%s'"
> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
> '-fplugin-arg-%s-test-extra-root=%s'"

If you mean the space between G_ and (, sure, if you mean trailing
whitespace, note likely none of the above have trailing whitespace, at least
if they are followed by "something on another line.

> 2018-04-17  Martin Liska  
> 
>   PR lto/85405
>   * ipa-devirt.c (odr_types_equivalent_p):

Please say what you've changed ;)

Jakub

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 10:29:35AM +0200, Martin Liška wrote:
> On 04/17/2018 10:28 AM, Martin Liška wrote:
> > I'm sending patch candidate.
> 
> This one is the right one.

Ok for stage1 with appropriate ChangeLog entries.

Jakub

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Martin Liška]

On 04/17/2018 10:28 AM, Martin Liška wrote:
> I'm sending patch candidate.

This one is the right one.

Martin
diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index d0d9c7894a8..2614eb58f14 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -98,10 +98,10 @@ overflow_warning (location_t loc, tree value, tree expr)
 
 case REAL_CST:
   warnfmt = (expr
-		 ? G_ ("floating point overflow in expression %qE "
-		   "of type %qT results in %qE")
-		 : G_ ("floating point overflow in expression of type %qT "
-		   "results in %qE"));
+		 ? G_("floating point overflow in expression %qE "
+		  "of type %qT results in %qE")
+		 : G_("floating point overflow in expression of type %qT "
+		  "results in %qE"));
   break;
 
 case FIXED_CST:
diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 4ec58605ce8..ec5e7046f6e 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -2933,12 +2933,12 @@ format_directive (const sprintf_dom_walker::call_info &info,
   else
 	warned = fmtwarn (dirloc, argloc, NULL, info.warnopt (),
 			  fmtres.range.min > target_int_max ()
-			  ? G_ ("%<%.*s%> directive output between %wu and "
-"%wu bytes causes result to exceed "
-"%")
-			  : G_ ("%<%.*s%> directive output between %wu and "
-"%wu bytes may cause result to exceed "
-"%"), dirlen,
+			  ? G_("%<%.*s%> directive output between %wu and "
+			   "%wu bytes causes result to exceed "
+			   "%")
+			  : G_("%<%.*s%> directive output between %wu and "
+			   "%wu bytes may cause result to exceed "
+			   "%"), dirlen,
 			  target_to_host (hostdir, sizeof hostdir, dir.beg),
 			  fmtres.range.min, fmtres.range.max);
 }
diff --git a/gcc/testsuite/gcc.dg/plugin/ggcplug.c b/gcc/testsuite/gcc.dg/plugin/ggcplug.c
index c4bc334868b..c186d119371 100644
--- a/gcc/testsuite/gcc.dg/plugin/ggcplug.c
+++ b/gcc/testsuite/gcc.dg/plugin/ggcplug.c
@@ -64,8 +64,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   if (!strcmp (argv[i].key, "count-ggc-start"))
 	{
 	  if (argv[i].value)
-	warning (0, G_ ("option '-fplugin-arg-%s-count-ggc-start=%s'"
-			" ignored (superfluous '=%s')"),
+	warning (0, G_("option '-fplugin-arg-%s-count-ggc-start=%s'"
+			   " ignored (superfluous '=%s')"),
 		 plugin_name, argv[i].value, argv[i].value);
 	  else
 	register_callback ("ggcplug",
@@ -76,8 +76,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   else if (!strcmp (argv[i].key, "count-ggc-end"))
 	{
 	  if (argv[i].value)
-	warning (0, G_ ("option '-fplugin-arg-%s-count-ggc-end=%s'"
-			" ignored (superfluous '=%s')"),
+	warning (0, G_("option '-fplugin-arg-%s-count-ggc-end=%s'"
+			   " ignored (superfluous '=%s')"),
 		 plugin_name, argv[i].value, argv[i].value);
 	  else
 	register_callback ("ggcplug",
@@ -88,8 +88,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   else if (!strcmp (argv[i].key, "count-ggc-mark"))
 	{
 	  if (argv[i].value)
-	warning (0, G_ ("option '-fplugin-arg-%s-count-ggc-mark=%s'"
-			" ignored (superfluous '=%s')"),
+	warning (0, G_("option '-fplugin-arg-%s-count-ggc-mark=%s'"
+			   " ignored (superfluous '=%s')"),
 		 plugin_name, argv[i].value, argv[i].value);
 	  else
 	register_callback ("ggcplug",
@@ -100,8 +100,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   else if (!strcmp (argv[i].key, "test-extra-root"))
 	{
 	  if (argv[i].value)
-	warning (0, G_ ("option '-fplugin-arg-%s-test-extra-root=%s'"
-			" ignored (superfluous '=%s')"),
+	warning (0, G_("option '-fplugin-arg-%s-test-extra-root=%s'"
+			   " ignored (superfluous '=%s')"),
 		 plugin_name, argv[i].value, argv[i].value);
 	  else
 	register_callback ("ggcplug",

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Martin Liška]

On 04/17/2018 10:21 AM, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 10:17:15AM +0200, Martin Liška wrote:
>> Sure. I see other format violations, should I fix that in follow up patch:
>>
>> gcc/c-family/c-warn.c:   ? G_ ("floating point overflow in 
>> expression %qE "
>> gcc/c-family/c-warn.c:   : G_ ("floating point overflow in 
>> expression of type %qT "
>> gcc/gimple-ssa-sprintf.c: ? G_ ("%<%.*s%> directive 
>> output between %wu and "
>> gcc/gimple-ssa-sprintf.c: : G_ ("%<%.*s%> directive 
>> output between %wu and "
>> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
>> '-fplugin-arg-%s-count-ggc-start=%s'"
>> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
>> '-fplugin-arg-%s-count-ggc-end=%s'"
>> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
>> '-fplugin-arg-%s-count-ggc-mark=%s'"
>> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
>> '-fplugin-arg-%s-test-extra-root=%s'"
> 
> If you mean the space between G_ and (, sure, if you mean trailing
> whitespace, note likely none of the above have trailing whitespace, at least
> if they are followed by "something on another line.

I'm sending patch candidate.

> 
>> 2018-04-17  Martin Liska  
>>
>>  PR lto/85405
>>  * ipa-devirt.c (odr_types_equivalent_p):
> 
> Please say what you've changed ;)

Yes, done that in r259431.

M.

> 
>   Jakub
> 

>From 143424c754415a20487e0dc615ac46cd934c8f78 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 17 Apr 2018 10:11:07 +0200
Subject: [PATCH] Fix coding style and add a new test-case (PR lto/85405).

gcc/ChangeLog:

2018-04-17  Martin Liska  

	PR lto/85405
	* ipa-devirt.c (odr_types_equivalent_p): Remove trailing
	in message, remote space in between '_G' and '('.

gcc/testsuite/ChangeLog:

2018-04-17  Martin Liska  

	PR lto/85405
	* g++.dg/lto/pr85405b_0.C: New test.
	* g++.dg/lto/pr85405b_1.C: New test.
---
 gcc/ipa-devirt.c  |  2 +-
 gcc/testsuite/g++.dg/lto/pr85405b_0.C | 18 ++
 gcc/testsuite/g++.dg/lto/pr85405b_1.C |  9 +
 3 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/lto/pr85405b_0.C
 create mode 100644 gcc/testsuite/g++.dg/lto/pr85405b_1.C

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 85b8ef175f3..cc9b5e347e6 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1599,7 +1599,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool *warned,
 		if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
 		  {
 		warn_odr (t1, t2, f1, f2, warn, warned,
-			  G_ ("one field is bitfield while other is not "));
+			  G_("one field is bitfield while other is not"));
 		return false;
 		  }
 		else
diff --git a/gcc/testsuite/g++.dg/lto/pr85405b_0.C b/gcc/testsuite/g++.dg/lto/pr85405b_0.C
new file mode 100644
index 000..a692abb7715
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr85405b_0.C
@@ -0,0 +1,18 @@
+// { dg-lto-do link }
+// { dg-lto-options {{-fPIC -shared -flto}} }
+
+class VclReferenceBase { // { dg-lto-warning "7: type 'struct VclReferenceBase' violates the C\\+\\+ One Definition Rule" }
+  int mnRefCnt;
+  int mbDisposed : 3;
+  virtual ~VclReferenceBase();
+};
+class a;
+class b {
+  a &e;
+  bool c();
+};
+class B {
+  VclReferenceBase d;
+};
+class a : B {};
+bool b::c() { return false; }
diff --git a/gcc/testsuite/g++.dg/lto/pr85405b_1.C b/gcc/testsuite/g++.dg/lto/pr85405b_1.C
new file mode 100644
index 000..fd98e631d56
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr85405b_1.C
@@ -0,0 +1,9 @@
+class VclReferenceBase {
+  int mnRefCnt;
+  int mbDisposed: 7; // { dg-lto-message "19: a field of same name but different type is defined in another translation unit" }
+
+protected:
+  virtual ~VclReferenceBase();
+};
+class : VclReferenceBase {
+} a;
-- 
2.16.3

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Jan Hubicka]

> On 04/17/2018 08:58 AM, Jakub Jelinek wrote:
> > On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
> >> +  if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
> >> +{
> >> +  warn_odr (t1, t2, f1, f2, warn, warned,
> >> +G_ ("one field is bitfield while other is not "));
> > 
> > I think all the G_ uses don't put a space in between G_ and (
> > Also, please avoid the trailing space in the message.
> 
> Sure. I see other format violations, should I fix that in follow up patch:
> 
> gcc/c-family/c-warn.c:   ? G_ ("floating point overflow in expression 
> %qE "
> gcc/c-family/c-warn.c:   : G_ ("floating point overflow in expression 
> of type %qT "
> gcc/gimple-ssa-sprintf.c: ? G_ ("%<%.*s%> directive 
> output between %wu and "
> gcc/gimple-ssa-sprintf.c: : G_ ("%<%.*s%> directive 
> output between %wu and "
> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
> '-fplugin-arg-%s-count-ggc-start=%s'"
> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
> '-fplugin-arg-%s-count-ggc-end=%s'"
> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
> '-fplugin-arg-%s-count-ggc-mark=%s'"
> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
> '-fplugin-arg-%s-test-extra-root=%s'"
> 
> ?
> 
> > 
> > Do you diagnose if both are bit-fields, but with different bitcount, e.g. if
> > in your testcase you replace bool mbDisposed : 1; with int mbDisposed : 3;
> > and bool mbDisposed; with int mbDisposed : 7; ?
> 
> Good point, I add a new test-case, done in patch.
> Is it OK to install the patch?
OK, thanks! (and sorry for the whitespace errors)
Honza
> 
> Martin
> 
> > 
> >> +  return false;
> >> +}
> >> +  else
> >> +gcc_assert (DECL_NONADDRESSABLE_P (f1)
> >> +== DECL_NONADDRESSABLE_P (f2));
> >>  }
> >>  
> >>/* If one aggregate has more fields than the other, they
> >> diff --git a/gcc/testsuite/g++.dg/lto/pr85405_0.C 
> >> b/gcc/testsuite/g++.dg/lto/pr85405_0.C
> >> new file mode 100644
> >> index 000..1a41d81099c
> >> --- /dev/null
> >> +++ b/gcc/testsuite/g++.dg/lto/pr85405_0.C
> >> @@ -0,0 +1,18 @@
> >> +// { dg-lto-do link }
> >> +// { dg-lto-options {{-fPIC -shared -flto}} }
> >> +
> >> +class VclReferenceBase { // { dg-lto-warning "7: type 'struct 
> >> VclReferenceBase' violates the C\\+\\+ One Definition Rule" }
> >> +  int mnRefCnt;
> >> +  bool mbDisposed : 1;
> >> +  virtual ~VclReferenceBase();
> >> +};
> >> +class a;
> >> +class b {
> >> +  a &e;
> >> +  bool c();
> >> +};
> >> +class B {
> >> +  VclReferenceBase d;
> >> +};
> >> +class a : B {};
> >> +bool b::c() { return false; }
> >> diff --git a/gcc/testsuite/g++.dg/lto/pr85405_1.C 
> >> b/gcc/testsuite/g++.dg/lto/pr85405_1.C
> >> new file mode 100644
> >> index 000..78606185624
> >> --- /dev/null
> >> +++ b/gcc/testsuite/g++.dg/lto/pr85405_1.C
> >> @@ -0,0 +1,9 @@
> >> +class VclReferenceBase {
> >> +  int mnRefCnt;
> >> +  bool mbDisposed;
> >> +
> >> +protected:
> >> +  virtual ~VclReferenceBase();
> >> +};
> >> +class : VclReferenceBase {
> >> +} a;
> >>
> > 
> > Jakub
> > 
> 

> From 87380235f9b81bea4cf910e702192586c072ce93 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Tue, 17 Apr 2018 10:11:07 +0200
> Subject: [PATCH] Fix coding style and add a new test-case (PR lto/85405).
> 
> gcc/ChangeLog:
> 
> 2018-04-17  Martin Liska  
> 
>   PR lto/85405
>   * ipa-devirt.c (odr_types_equivalent_p):
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-04-17  Martin Liska  
> 
>   PR lto/85405
>   * g++.dg/lto/pr85405b_0.C: New test.
>   * g++.dg/lto/pr85405b_1.C: New test.
> ---
>  gcc/ipa-devirt.c  |  2 +-
>  gcc/testsuite/g++.dg/lto/pr85405b_0.C | 18 ++
>  gcc/testsuite/g++.dg/lto/pr85405b_1.C |  9 +
>  3 files changed, 28 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/lto/pr85405b_0.C
>  create mode 100644 gcc/testsuite/g++.dg/lto/pr85405b_1.C
> 
> diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
> index 85b8ef175f3..cc9b5e347e6 100644
> --- a/gcc/ipa-devirt.c
> +++ b/gcc/ipa-devirt.c
> @@ -1599,7 +1599,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
> bool *warned,
>   if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
> {
>   warn_odr (t1, t2, f1, f2, warn, warned,
> -   G_ ("one field is bitfield while other is not "));
> +   G_("one field is bitfield while other is not"));
>   return false;
> }
>   else
> diff --git a/gcc/testsuite/g++.dg/lto/pr85405b_0.C 
> b/gcc/testsuite/g++.dg/lto/pr85405b_0.C
> new file mode 100644
> index 000..a692abb7715
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/lto/pr85405b_0.C
> @@ -0,0 +1,18 @@

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Martin Liška]

On 04/17/2018 08:58 AM, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
>> +if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
>> +  {
>> +warn_odr (t1, t2, f1, f2, warn, warned,
>> +  G_ ("one field is bitfield while other is not "));
> 
> I think all the G_ uses don't put a space in between G_ and (
> Also, please avoid the trailing space in the message.

Sure. I see other format violations, should I fix that in follow up patch:

gcc/c-family/c-warn.c:   ? G_ ("floating point overflow in expression 
%qE "
gcc/c-family/c-warn.c:   : G_ ("floating point overflow in expression 
of type %qT "
gcc/gimple-ssa-sprintf.c: ? G_ ("%<%.*s%> directive 
output between %wu and "
gcc/gimple-ssa-sprintf.c: : G_ ("%<%.*s%> directive 
output between %wu and "
gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
'-fplugin-arg-%s-count-ggc-start=%s'"
gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
'-fplugin-arg-%s-count-ggc-end=%s'"
gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
'-fplugin-arg-%s-count-ggc-mark=%s'"
gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
'-fplugin-arg-%s-test-extra-root=%s'"

?

> 
> Do you diagnose if both are bit-fields, but with different bitcount, e.g. if
> in your testcase you replace bool mbDisposed : 1; with int mbDisposed : 3;
> and bool mbDisposed; with int mbDisposed : 7; ?

Good point, I add a new test-case, done in patch.
Is it OK to install the patch?

Martin

> 
>> +return false;
>> +  }
>> +else
>> +  gcc_assert (DECL_NONADDRESSABLE_P (f1)
>> +  == DECL_NONADDRESSABLE_P (f2));
>>}
>>  
>>  /* If one aggregate has more fields than the other, they
>> diff --git a/gcc/testsuite/g++.dg/lto/pr85405_0.C 
>> b/gcc/testsuite/g++.dg/lto/pr85405_0.C
>> new file mode 100644
>> index 000..1a41d81099c
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.dg/lto/pr85405_0.C
>> @@ -0,0 +1,18 @@
>> +// { dg-lto-do link }
>> +// { dg-lto-options {{-fPIC -shared -flto}} }
>> +
>> +class VclReferenceBase { // { dg-lto-warning "7: type 'struct 
>> VclReferenceBase' violates the C\\+\\+ One Definition Rule" }
>> +  int mnRefCnt;
>> +  bool mbDisposed : 1;
>> +  virtual ~VclReferenceBase();
>> +};
>> +class a;
>> +class b {
>> +  a &e;
>> +  bool c();
>> +};
>> +class B {
>> +  VclReferenceBase d;
>> +};
>> +class a : B {};
>> +bool b::c() { return false; }
>> diff --git a/gcc/testsuite/g++.dg/lto/pr85405_1.C 
>> b/gcc/testsuite/g++.dg/lto/pr85405_1.C
>> new file mode 100644
>> index 000..78606185624
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.dg/lto/pr85405_1.C
>> @@ -0,0 +1,9 @@
>> +class VclReferenceBase {
>> +  int mnRefCnt;
>> +  bool mbDisposed;
>> +
>> +protected:
>> +  virtual ~VclReferenceBase();
>> +};
>> +class : VclReferenceBase {
>> +} a;
>>
> 
>   Jakub
> 

>From 87380235f9b81bea4cf910e702192586c072ce93 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 17 Apr 2018 10:11:07 +0200
Subject: [PATCH] Fix coding style and add a new test-case (PR lto/85405).

gcc/ChangeLog:

2018-04-17  Martin Liska  

	PR lto/85405
	* ipa-devirt.c (odr_types_equivalent_p):

gcc/testsuite/ChangeLog:

2018-04-17  Martin Liska  

	PR lto/85405
	* g++.dg/lto/pr85405b_0.C: New test.
	* g++.dg/lto/pr85405b_1.C: New test.
---
 gcc/ipa-devirt.c  |  2 +-
 gcc/testsuite/g++.dg/lto/pr85405b_0.C | 18 ++
 gcc/testsuite/g++.dg/lto/pr85405b_1.C |  9 +
 3 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/lto/pr85405b_0.C
 create mode 100644 gcc/testsuite/g++.dg/lto/pr85405b_1.C

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 85b8ef175f3..cc9b5e347e6 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1599,7 +1599,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool *warned,
 		if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
 		  {
 		warn_odr (t1, t2, f1, f2, warn, warned,
-			  G_ ("one field is bitfield while other is not "));
+			  G_("one field is bitfield while other is not"));
 		return false;
 		  }
 		else
diff --git a/gcc/testsuite/g++.dg/lto/pr85405b_0.C b/gcc/testsuite/g++.dg/lto/pr85405b_0.C
new file mode 100644
index 000..a692abb7715
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr85405b_0.C
@@ -0,0 +1,18 @@
+// { dg-lto-do link }
+// { dg-lto-options {{-fPIC -shared -flto}} }
+
+class VclReferenceBase { // { dg-lto-warning "7: type 'struct VclReferenceBase' violates the C\\+\\+ One Definition Rule" }
+  int mnRefCnt;
+  int mbDisposed : 3;
+  virtual ~VclReferenceBase();
+};
+class a;
+class b {
+  a &e;
+  bool c();
+};
+class B {
+  VclReferenceBase d;
+};
+class a : B {};
+bool b::c() { return false; }
diff --git a/gcc/testsuite/g++.dg/lto/pr85405

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
> + if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
> +   {
> + warn_odr (t1, t2, f1, f2, warn, warned,
> +   G_ ("one field is bitfield while other is not "));

I think all the G_ uses don't put a space in between G_ and (
Also, please avoid the trailing space in the message.

Do you diagnose if both are bit-fields, but with different bitcount, e.g. if
in your testcase you replace bool mbDisposed : 1; with int mbDisposed : 3;
and bool mbDisposed; with int mbDisposed : 7; ?

> + return false;
> +   }
> + else
> +   gcc_assert (DECL_NONADDRESSABLE_P (f1)
> +   == DECL_NONADDRESSABLE_P (f2));
> }
>  
>   /* If one aggregate has more fields than the other, they
> diff --git a/gcc/testsuite/g++.dg/lto/pr85405_0.C 
> b/gcc/testsuite/g++.dg/lto/pr85405_0.C
> new file mode 100644
> index 000..1a41d81099c
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/lto/pr85405_0.C
> @@ -0,0 +1,18 @@
> +// { dg-lto-do link }
> +// { dg-lto-options {{-fPIC -shared -flto}} }
> +
> +class VclReferenceBase { // { dg-lto-warning "7: type 'struct 
> VclReferenceBase' violates the C\\+\\+ One Definition Rule" }
> +  int mnRefCnt;
> +  bool mbDisposed : 1;
> +  virtual ~VclReferenceBase();
> +};
> +class a;
> +class b {
> +  a &e;
> +  bool c();
> +};
> +class B {
> +  VclReferenceBase d;
> +};
> +class a : B {};
> +bool b::c() { return false; }
> diff --git a/gcc/testsuite/g++.dg/lto/pr85405_1.C 
> b/gcc/testsuite/g++.dg/lto/pr85405_1.C
> new file mode 100644
> index 000..78606185624
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/lto/pr85405_1.C
> @@ -0,0 +1,9 @@
> +class VclReferenceBase {
> +  int mnRefCnt;
> +  bool mbDisposed;
> +
> +protected:
> +  virtual ~VclReferenceBase();
> +};
> +class : VclReferenceBase {
> +} a;
> 

Jakub

Re: [PATCH] Fix gen_lowpart_if_possible (PR middle-end/85414)

[Eric Botcazou]

> The following testcase FAILs, because cse_local sees
> (zero_extend:TI (subreg/s/v:DI (reg:TI ...) 0))
> inside of REG_EQUAL note, and simplify-rtx.c attempts to optimize it.
> case ZERO_EXTEND:
>   /* Check for a zero extension of a subreg of a promoted
>  variable, where the promotion is zero-extended, and the
>  target mode is the same as the variable's promotion.  */
>   if (GET_CODE (op) == SUBREG
>   && SUBREG_PROMOTED_VAR_P (op)
>   && SUBREG_PROMOTED_UNSIGNED_P (op)
>   && !paradoxical_subreg_p (mode, GET_MODE (SUBREG_REG (op
> {
>   temp = rtl_hooks.gen_lowpart_no_emit (mode, op);
>   if (temp)
> return temp;
> }

This code is strange though, here's the equivalent one in convert_modes:

  if (GET_CODE (x) == SUBREG
  && SUBREG_PROMOTED_VAR_P (x)
  && is_a  (mode, &int_mode)
  && (GET_MODE_PRECISION (subreg_promoted_mode (x))
  >= GET_MODE_PRECISION (int_mode))
  && SUBREG_CHECK_PROMOTED_SIGN (x, unsignedp))
x = gen_lowpart (int_mode, SUBREG_REG (x));

so can't we just pass SUBREG_REG (op) here?  Same for SIGN_EXTEND above.

-- 
Eric Botcazou

Re: [PR 85421] Call expand_all_artificial_thunks in ipa-cp if necessary

[Jakub Jelinek]

On Tue, Apr 17, 2018 at 08:55:09AM +0200, Martin Jambor wrote:
> Hi,
> 
> my fix from last week caused an ICE described in PR 85421 because I did
> not read my own comment and forgot that after calls to
> redirect_callee_duplicating_thunks, one must finish the work by calling
> expand_all_artificial_thunks, otherwise we end up with unanalyzed thunks
> and hit some assert sooner or later, like we did in this bug.
> 
> Fixed with the patch below, bootstrapped, LTO-bootstrapped and tested on
> x86_64-linux.  OK for trunk?
> 
> I'm sorry for introducing an ICE so late in stage4,
> 
> Martin
> 
> 
> 2018-04-17  Martin Jambor  
> 
>   PR ipa/85421
>   * ipa-cp.c (create_specialized_node): Call
>   expand_all_artificial_thunks if necessary.
>   * testsuite/g++.dg/ipa/pr85421.C: New test.

Ok for trunk.
No testsuite/ prefix for files going into testsuite/ChangeLog.

Jakub