Make claer, when contributions will be ignored

[Дилян Палаузов]

Hello,

on 27th October I sent to gcc-patches a mail with the subject “Don’t
build gdb/readline/libreadline.a, when --with-system-readline is
supplied” and on 14th November I sent a reminder.  I got no answer. 
Before sending the emails I filled a bugzilla ticket.

Can you please make it clear, when contributions will be ignored, or
agree on some procedures, where all contributions are handled in
reasonable time withot reminders, in a way that the processes work
reliably.

If it is unclear, when work made by others will be neglected, and it is
not foreseenable when, then state this clearly this uncertainty.  If
somebody does not feel comfortable with such a statent, then make
something to make the statement superfluous.

Regards
  Дилян

Re: [PATCH 2/9]: C++ P0482R5 char8_t: Core language support

[Tom Honermann]

On 12/3/18 5:01 PM, Jason Merrill wrote:

On 12/3/18 4:51 PM, Jason Merrill wrote:

On 11/5/18 2:39 PM, Tom Honermann wrote:
This patch adds support for the P0482R5 core language changes.  This 
includes:

- The -fchar8_t and -fno_char8_t command line options.
- char8_t as a keyword.
- The char8_t builtin type as a non-aliasing unsigned integral
   character type of size 1.
- Use of char8_t as a simple type specifier.
- u8 character literals with type char8_t.
- u8 string literals with type array of const char8_t.
- User defined literal operators that accept char8_1 and char8_t 
pointer

   types.
- New __cpp_char8_t predefined feature test macro.
- New __CHAR8_TYPE__ and __GCC_ATOMIC_CHAR8_T_LOCK_FREE predefined
   macros .
- Name mangling and demangling for char8_t (using Du).

gcc/ChangeLog:

2018-11-04  Tom Honermann  

  * defaults.h: Define CHAR8_TYPE.

gcc/c-family/ChangeLog:

2018-11-04  Tom Honermann  
  * c-family/c-common.c (c_common_reswords): Add char8_t.
  (fix_string_type): Use char8_t for the type of u8 string 
literals.

  (c_common_get_alias_set): char8_t doesn't alias.
  (c_common_nodes_and_builtins): Define char8_t as a builtin 
type in

  C++.
  (c_stddef_cpp_builtins): Add __CHAR8_TYPE__.
  (keyword_begins_type_specifier): Add RID_CHAR8.
  * gcc/c-family/c-common.h (rid): Add RID_CHAR8.
  (c_tree_index): Add CTI_CHAR8_TYPE and CTI_CHAR8_ARRAY_TYPE.
  Define D_CXX_CHAR8_T and D_CXX_CHAR8_T_FLAGS.
  Define char8_type_node and char8_array_type_node.
  * c-family/c-cppbuiltin.c (cpp_atomic_builtins): Predefine
  __GCC_ATOMIC_CHAR8_T_LOCK_FREE.
  (c_cpp_builtins): Predefine __cpp_char8_t.
  * c-family/c-lex.c (lex_string): Use char8_array_type_node as the
  type of CPP_UTF8STRING.
  (lex_charconst): Use char8_type_node as the type of CPP_UTF8CHAR.
  * c-family/c.opt: Add the -fchar8_t command line option.

gcc/c/ChangeLog:

2018-11-04  Tom Honermann  

  * c/c-typeck.c (char_type_p): Add char8_type_node.
  (digest_init): Handle initialization by a u8 string literal of
  char8_t type.

gcc/cp/ChangeLog:

2018-11-04  Tom Honermann  

  * cp/cvt.c (type_promotes_to): Handle char8_t promotion.
  * cp/decl.c (grokdeclarator): Handle invalid type specifier
  combinations involving char8_t.
  * cp/lex.c (init_reswords): Add char8_t as a reserved word.
  * cp/mangle.c (write_builtin_type): Add name mangling for char8_t
  (Du).
  * cp/parser.c (cp_keyword_starts_decl_specifier_p,
  cp_parser_simple_type_specifier): Recognize char8_t as a simple
  type specifier.
  (cp_parser_string_literal): Use char8_array_type_node for the 
type

  of CPP_UTF8STRING.
  (cp_parser_set_decl_spec_type): Tolerate char8_t typedefs in 
system

  headers.
  * cp/rtti.c (emit_support_tinfos): type_info support for char8_t.
  * cp/tree.c (char_type_p): Recognize char8_t as a character type.
  * cp/typeck.c (string_conv_p): Handle conversions of u8 string
  literals of char8_t type.
  (check_literal_operator_args): Handle UDLs with u8 string 
literals

  of char8_t type.
  * cp/typeck2.c (digest_init_r): Disallow initializing a char 
array

  with a u8 string literal.

libiberty/ChangeLog:

2018-10-31  Tom Honermann  
  * cp-demangle.c (cplus_demangle_builtin_types,
  cplus_demangle_type): Add name demangling for char8_t (Du).
  * cp-demangle.h: Increase D_BUILTIN_TYPE_COUNT to accommodate the
  new char8_t type.



@@ -3543,6 +3556,10 @@ c_common_get_alias_set (tree t)
   if (!TYPE_P (t))
 return -1;



+  /* Unlike char, char8_t doesn't alias. */
+  if (flag_char8_t && t == char8_type_node)
+    return -1;


This seems unnecessary; doesn't the existing code have the same 
effect? I think we could do with just an adjustment to the existing 
comment.
I'm not sure.  I had concerns about unintended matching due to char8_t 
having an underlying type of unsigned char.



+  else if (flag_char8_t && TREE_TYPE (value) == char8_array_type_node)
+  || (flag_char8_t && type == char8_type_node)
+  bool char8_array = (flag_char8_t && !!comptypes (typ1, 
char8_type_node));

+   || (flag_char8_t && type == char8_type_node
In many places you check the flag and then for one of the char8 
types. Since the types won't be used without the flag, checking the 
flag seems redundant?


This was again protection against unintended matching of the underlying 
unsigned char type, particularly when compiling as C. char8_type_node is 
constructed (in c_common_nodes_and_builtins) following the pattern in 
place for char16_t and char32_t with the following code:


+  char8_type_node = get_identifier (CHAR8_TYPE);
+  char8_type_node = TREE_TYPE (identifier_global_value (char8_type_node));
+  char8_type_size = TYPE_PRECISION (char8_type_node);
+  if (c_dialect_cxx ())
+{
+  char8_type_node = make_unsigned_type (char8_type_size);
+
+  if 

Re: [PATCH 1/9]: C++ P0482R5 char8_t: Documentation updates

[Tom Honermann]

On 12/3/18 2:59 PM, Jason Merrill wrote:

On 11/5/18 2:39 PM, Tom Honermann wrote:
This patch adds documentation for new -fchar8_t and -fno-char8_t 
options.


gcc/ChangeLog:

2018-11-04  Tom Honermann  
  * doc/invoke.texi (-fchar8_t): Document new option.



+Enable support for the P0482 proposal including the addition of a
+new @code{char8_t} fundamental type, changes to the types of UTF-8


Now that the proposal has been accepted, I'd refer to C++2a instead.


Agreed.  I also need to make the changes to implicitly enable -fchar8_t 
with -std=c++2a.


The list of impacted standard library features was incomplete and I 
suspect it isn't worth mentioning them specifically.  Perhaps mentioning 
the feature test macros would be helpful as well?


How does the following sound?

Enable support for @code{char8_t} as adopted for C++2a.  This includes 
the addition of a new @code{char8_t} fundamental type, changes to the 
types of UTF-8 string and character literals, new signatures for user 
defined literals, associated standard library updates, and new 
@code{__cpp_char8_t} and @code{__cpp_lib_char8_t} feature test macros.


Tom.



Jason

avoid null ptr deref in cselib_record_sets

[Alexandre Oliva]

Jeff Law tells me h8300-elf fails gcc.c-torture/compile/pr49029.c
with -O2 -g -mint32 -mh.  This patch fixes it.

The problem is that strict low part handling in cselib_record_sets
assumes src_elt is not NULL.  That src_elt is taken from a strict low
part set, but it won't always have a src_elt to begin with.  In this
case, it's because src is a volatile MEM; we don't record values for
those.

Although we could fix the problem by testing for a NULL src_elt before
creating the zero extends corresponding to strict low part sets of
formerly const0_rtx REGs, there's no point in recording the additional
set that we won't be able to use anyway.

We could still record that the whole register has a zero-extend of
the value stored in the narrower-mode strict low part of the register,
but is that of any use?  I guess not, but if we find otherwise, we can
change that later.

Jeff tested this with a cross compiler to h8300-elf, and several other
native and cross toolchains IIUC.  I'm regstrapping it myself on i686-
and x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* cselib.c (cselib_record_sets): Skip strict low part sets
with NULL src_elt.
---
 gcc/cselib.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/cselib.c b/gcc/cselib.c
index 6d3a4078c689..4a68439455fd 100644
--- a/gcc/cselib.c
+++ b/gcc/cselib.c
@@ -2616,6 +2616,7 @@ cselib_record_sets (rtx_insn *insn)
 preserves the upper bits that di:SI=zero_extend(flags:CCNO<=0).  */
   scalar_int_mode mode;
   if (dest != orig
+ && sets[i].src_elt
  && cselib_record_sets_hook
  && REG_P (dest)
  && HARD_REGISTER_P (dest)

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Re: [PATCH] [PR85569] skip constexpr target_expr constructor dummy type conversion

[Alexandre Oliva]

On Nov 27, 2018, Jason Merrill  wrote:

> Let's replace the == comparison rather than supplement it.  OK with
> that change.

Thanks, here's what I (re)tested and will install eventually.


[PR85569] skip constexpr target_expr constructor dummy type conversion

From: Alexandre Oliva 

The testcase is the work-around testcase for the PR; even that had
started failing.  The problem was that, when unqualifying the type of
a TARGET_EXPR, we'd create a variant of the type, then request the
conversion of the TARGET_EXPR_INITIAL to that variant type.  Though
the types are different pointer-wise, they're the same_type_p, so the
resulting modified expr compares cp_tree_equal to the original, which
maybe_constant_value flags as an error.  There's no reason to
construct an alternate TARGET_EXPR or CONSTRUCTOR just because of an
equivalent type, except for another spot that expected pointer
equality that would no longer be satisfied.  Without relaxing the
assert in constexpr_call_hasher::equal, g++.robertl/eb73.C would
trigger an assertion failure.


for  gcc/cp/ChangeLog

PR c++/85569
* constexpr.c (adjust_temp_type): Test for type equality with
same_type_p.
(constexpr_call_hasher::equal): Likewise.

for  gcc/testsuite

PR c++/85569
* g++.dg/cpp1z/pr85569.C: New.
---
 gcc/cp/constexpr.c   |4 +
 gcc/testsuite/g++.dg/cpp1z/pr85569.C |   93 ++
 2 files changed, 95 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/pr85569.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 92fd2b2d9d59..a668d14e8bf5 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1060,7 +1060,7 @@ constexpr_call_hasher::equal (constexpr_call *lhs, 
constexpr_call *rhs)
 {
   tree lhs_arg = TREE_VALUE (lhs_bindings);
   tree rhs_arg = TREE_VALUE (rhs_bindings);
-  gcc_assert (TREE_TYPE (lhs_arg) == TREE_TYPE (rhs_arg));
+  gcc_assert (same_type_p (TREE_TYPE (lhs_arg), TREE_TYPE (rhs_arg)));
   if (!cp_tree_equal (lhs_arg, rhs_arg))
 return false;
   lhs_bindings = TREE_CHAIN (lhs_bindings);
@@ -1276,7 +1276,7 @@ cxx_eval_builtin_function_call (const constexpr_ctx *ctx, 
tree t, tree fun,
 static tree
 adjust_temp_type (tree type, tree temp)
 {
-  if (TREE_TYPE (temp) == type)
+  if (same_type_p (TREE_TYPE (temp), type))
 return temp;
   /* Avoid wrapping an aggregate value in a NOP_EXPR.  */
   if (TREE_CODE (temp) == CONSTRUCTOR)
diff --git a/gcc/testsuite/g++.dg/cpp1z/pr85569.C 
b/gcc/testsuite/g++.dg/cpp1z/pr85569.C
new file mode 100644
index ..aec543041a0f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/pr85569.C
@@ -0,0 +1,93 @@
+// { dg-do compile { target c++17 } }
+
+#include 
+#include 
+
+#define LIFT_FWD(x) std::forward(x)
+
+template 
+inline
+constexpr
+auto
+equal(
+  T &)
+{
+  return [t = std::forward(t)](const auto& obj)
+-> decltype(obj == t)
+{
+  return obj == t;
+};
+}
+
+template 
+struct is_tuple_invocable;
+
+template 
+struct is_tuple_invocable>
+{
+  using type = typename std::is_invocable::type;
+};
+
+template 
+inline
+constexpr
+auto
+compose(
+  F&& f
+)
+  noexcept
+-> F
+{
+  return std::forward(f);
+}
+
+namespace detail {
+  template 
+  inline
+  constexpr
+  auto
+  compose(
+std::true_type,
+F&& f,
+Tail&& tail,
+T&& ... objs)
+  noexcept(noexcept(f(tail(std::forward(objs)...
+  -> decltype(f(tail(std::forward(objs)...)))
+  {
+return f(tail(std::forward(objs)...));
+  }
+}
+template 
+inline
+constexpr
+auto
+compose(
+  F&& f,
+  Fs&&... fs)
+{
+  return [f = std::forward(f), tail = compose(std::forward(fs)...)]
+(auto&& ... objs)
+-> decltype(detail::compose(typename 
std::is_invocable(fs)...)), 
decltype(objs)...>::type{},
+f,
+compose(std::forward(fs)...),
+LIFT_FWD(objs)...))
+  {
+using tail_type = decltype(compose(std::forward(fs)...));
+
+#ifndef NOT_VIA_TUPLE
+using args_type = std::tuple;
+constexpr auto unitail = typename is_tuple_invocable::type{};
+#else
+constexpr auto unitail = typename std::is_invocable::type{};
+#endif
+
+return detail::compose(unitail,  f, tail, LIFT_FWD(objs)...);
+  };
+}
+
+template 
+constexpr auto eq = equal(N);
+
+static_assert(compose(eq<3>,
+ std::plus<>{})(1,2),
+  "compose is constexpr");


-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Re: [PATCH] [PR86397] set p_t_decl while canonicalizing eh specs for mangling

[Alexandre Oliva]

On Nov 29, 2018, Jason Merrill  wrote:

> Let's go with this.  And remove the comment.

> And the !processing_template_decl is also redundant, since that's
> checked at the top of value_dependent_expression_p.

I've tested this on i686- and x86_64-linux-gnu.  Ok to install?


[PR86397] resolve nondependent noexcept specs early in C++1[14]

From: Alexandre Oliva 

build_noexcept_spec refrained from resolving nondependent noexcept
expressions when they were not part of the function types (C++ 11 and
14).  This caused problems during mangling: canonical_eh_spec, when
called on the template function type, would find an unresolved but not
explicitly deferred expression, and nothrow_spec_p would reject it.

We could relax the mangling logic to skip canonical_eh_spec, but since
-Wnoexcept-type warns when mangling function names that change as
noexcept specs become part of types and of mangling in C++17, and the
test at mangling time may give incorrect results if the spec is not
resolved, we might as well keep things simple and resolve nondependent
noexcept specs sooner rather than later.  This is what this patch does.


for  gcc/cp/ChangeLog

PR c++/86397
* except.c (build_noexcept_spec): Resolve nondependent
expressions.

for gcc/testsuite/ChangeLog

PR c++/86397
* g++.dg/cpp0x/pr86397-1.C: New.
* g++.dg/cpp0x/pr86397-2.C: New.
---
 gcc/cp/except.c|5 +
 gcc/testsuite/g++.dg/cpp0x/pr86397-1.C |4 
 gcc/testsuite/g++.dg/cpp0x/pr86397-2.C |4 
 3 files changed, 9 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr86397-1.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr86397-2.C

diff --git a/gcc/cp/except.c b/gcc/cp/except.c
index 3449b59b3cc0..a6951baa35c6 100644
--- a/gcc/cp/except.c
+++ b/gcc/cp/except.c
@@ -1189,11 +1189,8 @@ type_throw_all_p (const_tree type)
 tree
 build_noexcept_spec (tree expr, tsubst_flags_t complain)
 {
-  /* This isn't part of the signature, so don't bother trying to evaluate
- it until instantiation.  */
   if (TREE_CODE (expr) != DEFERRED_NOEXCEPT
-  && (!processing_template_decl
- || (flag_noexcept_type && !value_dependent_expression_p (expr
+  && !value_dependent_expression_p (expr))
 {
   expr = perform_implicit_conversion_flags (boolean_type_node, expr,
complain,
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr86397-1.C 
b/gcc/testsuite/g++.dg/cpp0x/pr86397-1.C
new file mode 100644
index ..4f9f5fa7e4c8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/pr86397-1.C
@@ -0,0 +1,4 @@
+// { dg-do compile { target c++11 } }
+void e();
+template  void f(int() noexcept(e)) {}
+template void f(int()); // { dg-error "does not match" "" { target 
c++17 } }
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr86397-2.C 
b/gcc/testsuite/g++.dg/cpp0x/pr86397-2.C
new file mode 100644
index ..fb43499526e8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/pr86397-2.C
@@ -0,0 +1,4 @@
+// { dg-do compile { target c++11 } }
+void e();
+template  void f(int() noexcept(e)) {}
+template void f(int() noexcept);


-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Fortran patches

[Steve Kargl]

I intend to commit the attached patch on Saturday.

2018-12-02  Steven G. Kargl  

PR fortran/87922
* io.c (gfc_match_open): ASYNCHRONOUS must be scalar.

PR fortran/87945
* decl.c (var_element): Inquiry parameter cannot be a data object.
(match_data_constant): Inquiry parameter can be a data
in a data statement.

PR fortran/88139
* dump-parse-tree.c (write_proc): Alternate return.

PR fortran/88025
* expr.c (gfc_apply_init): Remove asserts and check for valid
ts->u.cl->length.

PR fortran/88048
* resolve.c (check_data_variable): Convert gfc_internal_error to 
an gfc_error.  Add a nearby missing 'return false;'

PR fortran/88116
* simplify.c: Remove internal error and return gfc_bad_expr.

PR fortran/88205
* io.c (gfc_match_open): STATUS must be CHARACTER type.

PR fortran/88206
* match.c (gfc_match_type_spec): REAL can be an intrinsic function.

PR fortran/88228
* expr.c (check_null, check_elemental): Work around -fdec and
initialization with logical operators operating on integers.

PR fortran/88249
* gfortran.h: Update prototype for gfc_resolve_filepos
* io.c (gfc_resolve_filepos): Accept the locus to include in errors.
* resolve.c (gfc_resolve_code): Pass locus.
 
PR fortran/88269
* io.c (io_constraint): Update macro.  Remove incompatible use
of io_constraint and give explicit error.
 
PR fortran/88328
* io.c (resolve_tag_format): Detect zero-sized array.

2018-12-02  Steven G. Kargl  

PR fortran/87922
* gfortran.dg/pr87922.f90: New test.

PR fortran/887945
* gfortran.dg/pr87945_1.f90: New test.
* gfortran.dg/pr87945_2.f90: New test.

PR fortran/87994
* gfortran.dg/pr87994_1.f90: New test.
* gfortran.dg/pr87994_2.f90: New test.
* gfortran.dg/pr87994_3.f90: New test.

PR fortran/88025
* gfortran.dg/pr88025.f90: New test.

PR fortran/88048
* gfortran.dg/pr88048.f90: New test.

PR fortran/88116
* gfortran.dg/pr88116_1.f90: New test.
* gfortran.dg/pr88116_2.f90: New test.

PR fortran/88139
* gfortran.dg/pr88139.f90: New test.

PR fortran/88205
* gfortran.dg/pr88205.f90: New test.

PR fortran/88206
* gfortran.dg/pr88206.f90: New test.

PR fortran/88228
* gfortran.dg/pr88228.f90: New test.

PR fortran/88249
* gfortran.dg/pr88249.f90: New test.

PR fortran/88269
* gfortran.dg/pr88269.f90: New test.

PR fortran/88328
* gfortran.dg/pr88328.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 266718)
+++ gcc/fortran/decl.c	(working copy)
@@ -281,6 +281,14 @@ var_element (gfc_data_variable *new_var)
   if (m != MATCH_YES)
 return m;
 
+  if (new_var->expr->expr_type == EXPR_CONSTANT
+  && new_var->expr->symtree == NULL)
+{
+  gfc_error ("Inquiry parameter cannot appear in a "
+		 "data-stmt-object-list at %C");
+  return MATCH_ERROR;
+}
+
   sym = new_var->expr->symtree->n.sym;
 
   /* Symbol should already have an associated type.  */
@@ -391,6 +399,14 @@ match_data_constant (gfc_expr **result)
 }
   else if (m == MATCH_YES)
 {
+  /* If a parameter inquiry ends up here, symtree is NULL but **result
+	 contains the right constant expression.  Check here.  */
+  if ((*result)->symtree == NULL
+	  && (*result)->expr_type == EXPR_CONSTANT
+	  && ((*result)->ts.type == BT_INTEGER 
+	  || (*result)->ts.type == BT_REAL))
+	return m;
+
   /* F2018:R845 data-stmt-constant is initial-data-target.
 	 A data-stmt-constant shall be ... initial-data-target if and
 	 only if the corresponding data-stmt-object has the POINTER
Index: gcc/fortran/dump-parse-tree.c
===
--- gcc/fortran/dump-parse-tree.c	(revision 266718)
+++ gcc/fortran/dump-parse-tree.c	(working copy)
@@ -3259,6 +3259,14 @@ write_proc (gfc_symbol *sym)
 {
   gfc_symbol *s;
   s = f->sym;
+
+  if (!s)
+	{
+	  gfc_error_now ("Par %L, \"Nous sommes tous nes pour le mal\"",
+			 >declared_at);
+	  return;
+	}
+
   rok = get_c_type_name (&(s->ts), NULL, , _name, ,
 			 , false);
   if (rok == T_ERROR)
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(revision 266718)
+++ gcc/fortran/expr.c	(working copy)
@@ -2688,6 +2688,9 @@ check_transformational (gfc_expr *e)
 static match
 check_null (gfc_expr *e)
 {
+  if (flag_dec && e->expr_type == EXPR_CONSTANT)
+   return MATCH_NO;
+
   if (strcmp ("null", e->symtree->n.sym->name) != 0)
 return MATCH_NO;
 
@@ -2698,6 +2701,9 @@ 

Re: [doc PATCH] update attribute docs for C++

[Sandra Loosemore]

On 12/4/18 8:13 PM, Martin Sebor wrote:

On 12/4/18 2:04 PM, Sandra Loosemore wrote:

On 12/4/18 9:26 AM, Martin Sebor wrote:


[snip]

+The keyword @code{__attribute__} allows you to specify various special
+properties of types.  Some type attributes apply only to structure and
+union types, and in C++, also class types, while others can apply to
+any type defined via a @code{typedef} declaration.  Unless otherwise
+specified, the same restrictions and effects apply to attributes 
regardless
+of whether a type is a trivial structure or a C++ class with 
user-defined

+constructors, destructors, or a copy assignment.


And here I would really prefer to use standard terminology than trying 
to inaccurately summarize what the terminology means.  E.g.


"...whether or not a class is trivial (in the C++11 sense) or POD (in 
C++98)."


This doesn't say what we want to say (nor is it accurate).

Here are the user's questions again:

   The documentation should clarify how it handles structs/
   classes/unions and references.  Does it threat references
   like pointers? Does it only allow PODs/trivial types to be
   returned, or does it invoke the copy constructor, when it
   is used again?

They were about const/pure but the same questions could be asked
about other attributes as well.  The simple answer I'm trying to
give is that it doesn't matter: (unless the manual says otherwise)
references [to pointers] are treated the same as pointers, and
there is no difference between functions that take arguments or
return classes with user-defined ctors and plain old C structs,
or between attributes applied to such types.  It doesn't help
to use C++ standard terms when they are subtly or substantially
different between C++ revisions, and then try to draw
a distinction between those different terms, when they don't
matter.


I'm getting even more confused about what you're trying to communicate 
here.  :-(


What is the "it" referenced in the user's questions you quoted?  The 
const/pure attributes?  Those are function attributes.  The text you are 
adding is in the type attribute section, so it seemed like it was trying 
to address a different problem: stating that you can attach type 
attributes to any struct/class type whether or not it is a "trivial" 
class, by some definition of that term.  If that's not the purpose of 
this paragraph, what is it?


-Sandra

[Patch,Testsuite][MIPS][Committed] Adjusted msa compare instructions clti to clei.

[Paul Hua]

Hi:

Recently gcc optimize msa compare code i<5 from clti_.df $wn,$wn,5
to clei_.df $wn,$wn,4.
This patch adjusted testsuite.

Committed as obviously.


gcc/testsuite/
2018-12-05  Chenghua Xu  

* gcc.target/mips/msa.c: Adjusted clti_.df $wn,$wn,5
to clei_.df $wn,$wn,4 in test31.
diff --git a/gcc/testsuite/gcc.target/mips/msa.c b/gcc/testsuite/gcc.target/mips/msa.c
index cdd5ca28dac..b741f35556f 100644
--- a/gcc/testsuite/gcc.target/mips/msa.c
+++ b/gcc/testsuite/gcc.target/mips/msa.c
@@ -330,14 +330,14 @@
 /* { dg-final { scan-assembler-times "test30_v8u16:.*ceqi.h.*test30_v8u16" 1 } } */
 /* { dg-final { scan-assembler-times "test30_v4u32:.*ceqi.w.*test30_v4u32" 1 } } */
 /* { dg-final { scan-assembler-times "test30_v2u64:.*ceqi.d.*test30_v2u64" 1 } } */
-/* { dg-final { scan-assembler-times "test31_s_v16i8:.*clti_s.b.*test31_s_v16i8" 1 } } */
-/* { dg-final { scan-assembler-times "test31_s_v8i16:.*clti_s.h.*test31_s_v8i16" 1 } } */
-/* { dg-final { scan-assembler-times "test31_s_v4i32:.*clti_s.w.*test31_s_v4i32" 1 } } */
-/* { dg-final { scan-assembler-times "test31_s_v2i64:.*clti_s.d.*test31_s_v2i64" 1 } } */
-/* { dg-final { scan-assembler-times "test31_u_v16u8:.*clti_u.b.*test31_u_v16u8" 1 } } */
-/* { dg-final { scan-assembler-times "test31_u_v8u16:.*clti_u.h.*test31_u_v8u16" 1 } } */
-/* { dg-final { scan-assembler-times "test31_u_v4u32:.*clti_u.w.*test31_u_v4u32" 1 } } */
-/* { dg-final { scan-assembler-times "test31_u_v2u64:.*clti_u.d.*test31_u_v2u64" 1 } } */
+/* { dg-final { scan-assembler-times "test31_s_v16i8:.*clei_s.b.*test31_s_v16i8" 1 } } */
+/* { dg-final { scan-assembler-times "test31_s_v8i16:.*clei_s.h.*test31_s_v8i16" 1 } } */
+/* { dg-final { scan-assembler-times "test31_s_v4i32:.*clei_s.w.*test31_s_v4i32" 1 } } */
+/* { dg-final { scan-assembler-times "test31_s_v2i64:.*clei_s.d.*test31_s_v2i64" 1 } } */
+/* { dg-final { scan-assembler-times "test31_u_v16u8:.*clei_u.b.*test31_u_v16u8" 1 } } */
+/* { dg-final { scan-assembler-times "test31_u_v8u16:.*clei_u.h.*test31_u_v8u16" 1 } } */
+/* { dg-final { scan-assembler-times "test31_u_v4u32:.*clei_u.w.*test31_u_v4u32" 1 } } */
+/* { dg-final { scan-assembler-times "test31_u_v2u64:.*clei_u.d.*test31_u_v2u64" 1 } } */
 /* { dg-final { scan-assembler-times "test32_s_v16i8:.*clei_s.b.*test32_s_v16i8" 1 } } */
 /* { dg-final { scan-assembler-times "test32_s_v8i16:.*clei_s.h.*test32_s_v8i16" 1 } } */
 /* { dg-final { scan-assembler-times "test32_s_v4i32:.*clei_s.w.*test32_s_v4i32" 1 } } */

Re: [PATCH] Fix -fsanitize=address -fstack-protector* (PR sanitizer/88333)

[Jeff Law]

On 12/4/18 4:32 PM, Jakub Jelinek wrote:
> Hi!
> 
> The current asan.c code requires that the whole block of vars starts and
> ends on ASAN_RED_ZONE_SIZE (i.e. 32 byte) boundary, so that it is on 4 byte
> boundary in the shadow memory.  Normally it is, when frame_offset starts at
> 0, but with -fstack-protector there is the guard above it and in that case
> following patch is needed to realign the end of the block.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-12-04  Jakub Jelinek  
> 
>   PR sanitizer/88333
>   * cfgexpand.c (expand_stack_vars): If asan_vec is empty, start with
>   aligning frame offset to ASAN_RED_ZONE_SIZE bytes.
> 
>   * c-c++-common/asan/pr88333.c: New test.
OK
jeff

Re: [doc PATCH] update attribute docs for C++

[Martin Sebor]

On 12/4/18 2:04 PM, Sandra Loosemore wrote:

On 12/4/18 9:26 AM, Martin Sebor wrote:


Thanks for the comments.  Attached is an updated patch with
the typos fixed.  I've left the rest as is.


Well, I still think a number of points I commented on before need to be 
clarified in the text.  If I'm confused, I think other readers will be, 
too, and users shouldn't have to search for discussion on gcc-patches to 
figure out what the manual means.



+Unless specified otherwise, function attributes that apply to function
+parameters of pointer types also apply to the implicit C++ @code{this}
+argument in non-static member functions, and to parameters of reference
+type.  In attributes that refer to function parameters by their position
+in the argument list the first parameter is at position one.  In C++
+non-static member functions position one refers to the implicit 
@code{this}

+pointer.  The same restrictions and effects apply to function attributes
+used with ordinary functions or C++ member functions.


Like this paragraph above.  Users may read that first sentence and think 
they can attach function attributes to parameter declarations.  I'd 
suggest rewriting this as


"function attributes that specify properties of the function's 
parameters, like @code{nonnull}, also apply"


or something like that.


I've adjusted the words to hopefully make this clearer.  I've added
a new term: /positional argument/ and used it to avoid the confusion.
There is unfortunately no good example to use here because the this
pointer is not a valid argument to any such attribute.  All but
nonnull trigger a warning when applied to this.  It's only important
to discuss because position 1 refers to it and the remaining arguments
in a member function start at position 2.

(I also noticed that the text referred to "attribute declarations"
so I changed those to "attribute specifications.")


+Unless specified otherwise, function attributes that apply to variables
+or function parameters of pointer types also apply to the implicit C++
+@code {this} argument in non-static member functions, and to 
arguments of

+reference type.
+


And similarly here, but this is even more confusing.  What function 
attributes apply to variables, and not just parameters?  Given this is 
the variable attribute section, I think it would be more useful to say 
something about how you attach a variable attribute to the "this" 
parameter, rather than talking about function attributes.


This didn't come out quite right.  The intent is to make it clear
that variable attributes that apply to pointers can also be used
with references (to pointers or to other types), and ditto for
structs and classes (see the questions below).  Perhaps adding
the clarification isn't helpful here so I've removed it.


+The keyword @code{__attribute__} allows you to specify various special
+properties of types.  Some type attributes apply only to structure and
+union types, and in C++, also class types, while others can apply to
+any type defined via a @code{typedef} declaration.  Unless otherwise
+specified, the same restrictions and effects apply to attributes 
regardless
+of whether a type is a trivial structure or a C++ class with 
user-defined

+constructors, destructors, or a copy assignment.


And here I would really prefer to use standard terminology than trying 
to inaccurately summarize what the terminology means.  E.g.


"...whether or not a class is trivial (in the C++11 sense) or POD (in 
C++98)."


This doesn't say what we want to say (nor is it accurate).

Here are the user's questions again:

  The documentation should clarify how it handles structs/
  classes/unions and references.  Does it threat references
  like pointers? Does it only allow PODs/trivial types to be
  returned, or does it invoke the copy constructor, when it
  is used again?

They were about const/pure but the same questions could be asked
about other attributes as well.  The simple answer I'm trying to
give is that it doesn't matter: (unless the manual says otherwise)
references [to pointers] are treated the same as pointers, and
there is no difference between functions that take arguments or
return classes with user-defined ctors and plain old C structs,
or between attributes applied to such types.  It doesn't help
to use C++ standard terms when they are subtly or substantially
different between C++ revisions, and then try to draw
a distinction between those different terms, when they don't
matter.

Martin
gcc/ChangeLog:

	* doc/extend.texi (Function Attributes): Clarify C++ aspects.
	(Variable Attributes): Same.
	(Type Attributes): Same.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 266799)
+++ gcc/doc/extend.texi	(working copy)
@@ -2332,12 +2332,13 @@ the enclosing block.
 @cindex @code{volatile} applied to function
 @cindex @code{const} applied to function
 
-In GNU C, you can use function 

[PATCH, csky] Force .init_array suppor for GLIBC

[瞿仙淼]

Hi, 
I have submitted a patch to force .init_array suppor for GLIBC


Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 266812)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2018-12-05  Xianmiao Qu  
+
+   * config.gcc (csky-*-linux-gnu*): Force .init_array support.
+
 2018-12-05  Segher Boessenkool  
 
* config/rs6000/rs6000.c (rs6000_function_arg): Only do the special
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 266812)
+++ gcc/config.gcc  (working copy)
@@ -1356,6 +1356,9 @@ csky-*-*)
case ${target} in
csky-*-linux-gnu*)
tm_defines="$tm_defines DEFAULT_LIBC=LIBC_GLIBC"
+   # Force .init_array support.  The configure script 
cannot always
+   # automatically detect that GAS supports it, yet we 
require it.
+   gcc_cv_initfini_array=yes
;;
csky-*-linux-uclibc*)
tm_defines="$tm_defines DEFAULT_LIBC=LIBC_UCLIBC"

libgo: remove AIX flock emulation

[Ian Lance Taylor]

This patch by Tobias Klauser removes the somewhat incorrect AIX flock
emulation from the syscall package.  This is based on the discussion
at https://golang.org/issue/29084.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 266781)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-7259d9a403db2784c7d03239c6a50e730062fc61
+d3a98b7a9ea8032be22ebb3ea2f389ce22669d53
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/syscall/libcall_aix.go
===
--- libgo/go/syscall/libcall_aix.go (revision 266510)
+++ libgo/go/syscall/libcall_aix.go (working copy)
@@ -111,28 +111,6 @@ func Reboot(how int) (err error) {
 //sys  Fchownat(dirfd int, path string, uid int, gid int, flags int) (err 
error)
 //fchownat(dirfd _C_int, path *byte, owner Uid_t, group Gid_t, flags _C_int) 
_C_int
 
-// On AIX, there is no flock() system call, we emulate it.
-func Flock(fd int, op int) (err error) {
-   lk := _t{}
-   if (op & LOCK_UN) != 0 {
-   lk.Type = F_UNLCK
-   } else if (op & LOCK_EX) != 0 {
-   lk.Type = F_WRLCK
-   } else if (op & LOCK_SH) != 0 {
-   lk.Type = F_RDLCK
-   } else {
-   return nil
-   }
-   if (op & LOCK_NB) != 0 {
-   err = FcntlFlock(uintptr(fd), F_SETLK, lk)
-   if err != nil && (err == EAGAIN || err == EACCES) {
-   return EWOULDBLOCK
-   }
-   return err
-   }
-   return FcntlFlock(uintptr(fd), F_SETLKW, lk)
-}
-
 //sys  Fstatfs(fd int, buf *Statfs_t) (err error)
 //fstatfs64(fd _C_int, buf *Statfs_t) _C_int
 

[PATCH] rs6000: Fix AIX aggregate passing fix

[Segher Boessenkool]

David's fix for the AIX aggregate passing from yesterday unfortunately
also triggers on powerpc64-linux.  This fixes it.

David, looking at this once more, does this not need a "&& type" test
on AIX?  Before the AGGREGATE_TYPE_P test.  I suspect it only didn't
crash on AIX because AIX doesn't mind dereferencing address 0?

(But committing this as is now, it fixes bootstrap).

Tested on powerpc64-linux {-m32,-m64}.


Segher


2018-12-05  Segher Boessenkool  

* config/rs6000/rs6000.c (rs6000_function_arg): Only do the special
aggregate handling on actual AIX, not on somewhat similar systems.

---
 gcc/config/rs6000/rs6000.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 4e35a05..ea7ff82 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -11990,7 +11990,7 @@ rs6000_function_arg (cumulative_args_t cum_v, 
machine_mode mode,
cum->fregno++;
 
   if (USE_FP_FOR_ARG_P (cum, elt_mode)
- && !(TARGET_AIX && AGGREGATE_TYPE_P (type)))
+ && !(TARGET_AIX && !TARGET_ELF && AGGREGATE_TYPE_P (type)))
{
  rtx rvec[GP_ARG_NUM_REG + AGGR_ARG_NUM_REG + 1];
  rtx r, off;
@@ -12127,7 +12127,7 @@ rs6000_arg_partial_bytes (cumulative_args_t cum_v, 
machine_mode mode,
   align_words = rs6000_parm_start (mode, type, cum->words);
 
   if (USE_FP_FOR_ARG_P (cum, elt_mode)
-  && !(TARGET_AIX && AGGREGATE_TYPE_P (type)))
+  && !(TARGET_AIX && !TARGET_ELF && AGGREGATE_TYPE_P (type)))
 {
   unsigned long n_fpreg = (GET_MODE_SIZE (elt_mode) + 7) >> 3;
 
-- 
1.8.3.1

[PATCH] Fix unroll-and-jam (PR tree-optimization/87360)

[Jakub Jelinek]

Hi!

The following testcases ICE, because tree_loop_unroll_and_jam optimizes one
loop and on another one after it fails to analyze data dependencies and
returns.  The end effect of that is that neither the code at the end of the
function to do final cleanups, nor TODO_cleanup_cfg is done, and the latter
means that we don't reset some number of initialization stuff that keeps
referencing already removed stmts.

The following patch fixes that by replacing return false; with continue;,
so that it will just ignore the loop which couldn't be optimized and will
try to optimize other further loops and at the end if at least one loop is
optimized, return TODO_cleanup_cfg.

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

2018-12-04  Jakub Jelinek  

PR tree-optimization/87360
* gimple-loop-jam.c (tree_loop_unroll_and_jam): On failure to analyze
data dependencies, don't return false, just continue.  Formatting
fixes.
(merge_loop_tree, bb_prevents_fusion_p, unroll_jam_possible_p,
fuse_loops): Formatting fixes.

* g++.dg/opt/pr87360.C: New test.
* gfortran.dg/pr87360.f90: New test.

--- gcc/gimple-loop-jam.c.jj2018-09-04 19:48:19.238613844 +0200
+++ gcc/gimple-loop-jam.c   2018-12-04 18:53:45.983850575 +0100
@@ -118,7 +118,7 @@ merge_loop_tree (struct loop *loop, stru
   for (i = 0; i < n; i++)
 {
   /* If the block was direct child of OLD loop it's now part
- of LOOP.  If it was outside OLD, then it moved into LOOP
+of LOOP.  If it was outside OLD, then it moved into LOOP
 as well.  This avoids changing the loop father for BBs
 in inner loops of OLD.  */
   if (bbs[i]->loop_father == old
@@ -167,7 +167,7 @@ bb_prevents_fusion_p (basic_block bb)
* stores or unknown side-effects prevent fusion
* loads don't
* computations into SSA names: these aren't problematic.  Their
- result will be unused on the exit edges of the first N-1 copies
+result will be unused on the exit edges of the first N-1 copies
 (those aren't taken after unrolling).  If they are used on the
 other edge (the one leading to the outer latch block) they are
 loop-carried (on the outer loop) and the Nth copy of BB will
@@ -282,12 +282,12 @@ unroll_jam_possible_p (struct loop *oute
   if (!simple_iv (loop, loop, op, , true))
return false;
   /* The inductions must be regular, loop invariant step and initial
- value.  */
+value.  */
   if (!expr_invariant_in_loop_p (outer, iv.step)
  || !expr_invariant_in_loop_p (outer, iv.base))
return false;
   /* XXX With more effort we could also be able to deal with inductions
- where the initial value is loop variant but a simple IV in the
+where the initial value is loop variant but a simple IV in the
 outer loop.  The initial value for the second body would be
 the original initial value plus iv.base.step.  The next value
 for the fused loop would be the original next value of the first
@@ -322,7 +322,7 @@ fuse_loops (struct loop *loop)
   gcc_assert (EDGE_COUNT (next->header->preds) == 1);
 
   /* The PHI nodes of the second body (single-argument now)
- need adjustments to use the right values: either directly
+need adjustments to use the right values: either directly
 the value of the corresponding PHI in the first copy or
 the one leaving the first body which unrolling did for us.
 
@@ -449,13 +449,13 @@ tree_loop_unroll_and_jam (void)
   dependences.create (10);
   datarefs.create (10);
   if (!compute_data_dependences_for_loop (outer, true, _nest,
-  , ))
+ , ))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Cannot analyze data dependencies\n");
  free_data_refs (datarefs);
  free_dependence_relations (dependences);
- return false;
+ continue;
}
   if (!datarefs.length ())
continue;
@@ -490,7 +490,7 @@ tree_loop_unroll_and_jam (void)
 ))
{
  /* Couldn't get the distance vector.  For two reads that's
-harmless (we assume we should unroll).  For at least
+harmless (we assume we should unroll).  For at least
 one write this means we can't check the dependence direction
 and hence can't determine safety.  */
 
@@ -503,7 +503,7 @@ tree_loop_unroll_and_jam (void)
}
 
   /* We regard a user-specified minimum percentage of zero as a request
- to ignore all profitability concerns and apply the transformation
+to ignore all profitability concerns and apply the transformation
 always.  */
   if (!PARAM_VALUE 

[PATCH] Fix -fsanitize=address -fstack-protector* (PR sanitizer/88333)

[Jakub Jelinek]

Hi!

The current asan.c code requires that the whole block of vars starts and
ends on ASAN_RED_ZONE_SIZE (i.e. 32 byte) boundary, so that it is on 4 byte
boundary in the shadow memory.  Normally it is, when frame_offset starts at
0, but with -fstack-protector there is the guard above it and in that case
following patch is needed to realign the end of the block.

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

2018-12-04  Jakub Jelinek  

PR sanitizer/88333
* cfgexpand.c (expand_stack_vars): If asan_vec is empty, start with
aligning frame offset to ASAN_RED_ZONE_SIZE bytes.

* c-c++-common/asan/pr88333.c: New test.

--- gcc/cfgexpand.c.jj  2018-11-30 19:59:59.676789914 +0100
+++ gcc/cfgexpand.c 2018-12-04 11:25:55.549672029 +0100
@@ -1124,6 +1124,11 @@ expand_stack_vars (bool (*pred) (size_t)
  && frame_offset.is_constant (_offset)
  && stack_vars[i].size.is_constant ())
{
+ if (data->asan_vec.is_empty ())
+   {
+ alloc_stack_frame_space (0, ASAN_RED_ZONE_SIZE);
+ prev_offset = frame_offset.to_constant ();
+   }
  prev_offset = align_base (prev_offset,
MAX (alignb, ASAN_MIN_RED_ZONE_SIZE),
!FRAME_GROWS_DOWNWARD);
--- gcc/testsuite/c-c++-common/asan/pr88333.c.jj2018-12-04 
12:14:44.329877625 +0100
+++ gcc/testsuite/c-c++-common/asan/pr88333.c   2018-12-04 12:14:34.804033303 
+0100
@@ -0,0 +1,12 @@
+/* PR sanitizer/88333 */
+/* { dg-do compile { target fstack_protector } } */
+/* { dg-options "-fstack-protector-strong -fsanitize=address" } */
+
+void bar (int *);
+
+void
+foo (void)
+{
+  int c;
+  bar ();
+}

Jakub

Re: [PING] Re: [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486)

[Jason Merrill]

On 12/3/18 5:10 PM, Jeff Law wrote:

On 11/19/18 9:51 AM, David Malcolm wrote:

Ping, for these patches:

[PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486)
   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00304.html

[PATCH 2/2] C++: improvements to binary operator diagnostics (PR c++/87504)
   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00303.html


Thanks
Dave





[1] I've split them up for ease of review; they could be reworked to
be
fully independent, but there's some churn in the results for
-Wtautological-compare introduced by the 1st patch which the 2nd
patch addresses.

gcc/ChangeLog:
PR c++/43064
PR c++/43486
* convert.c: Include "selftest.h".
(preserve_any_location_wrapper): New function.
(convert_to_pointer_maybe_fold): Update to handle location
wrappers.
(convert_to_real_maybe_fold): Likewise.
(convert_to_integer_1): Handle location wrappers when checking
for
INTEGER_CST.
(convert_to_integer_maybe_fold): Update to handle location
wrappers.
(convert_to_complex_maybe_fold): Likewise.
(selftest::test_convert_to_integer_maybe_fold): New functions.
(selftest::convert_c_tests): New function.
* fold-const.c (operand_equal_p): Strip any location wrappers.
* selftest-run-tests.c (selftest::run_tests): Call
selftest::convert_c_tests.
* selftest.h (selftest::convert_c_tests): New decl.
* tree.c (tree_int_cst_equal): Strip any location wrappers.
(maybe_wrap_with_location): Don't create wrappers if any
auto_suppress_location_wrappers are active.
(suppress_location_wrappers): New variable.
* tree.h (CONSTANT_CLASS_OR_WRAPPER_P): New macro.
(suppress_location_wrappers): New decl.
(class auto_suppress_location_wrappers): New class.

gcc/c-family/ChangeLog:
PR c++/43064
PR c++/43486
* c-common.c (unsafe_conversion_p): Strip any location wrapper.
(verify_tree): Handle location wrappers.
(c_common_truthvalue_conversion): Strip any location wrapper.
Handle CONST_DECL.
(fold_offsetof): Strip any location wrapper.
(complete_array_type): Likewise for initial_value.
(convert_vector_to_array_for_subscript): Call fold_for_warn on
the
index before checking for INTEGER_CST.
* c-pretty-print.c (c_pretty_printer::primary_expression):
Don't
print parentheses around location wrappers.
* c-warn.c (warn_logical_operator): Call fold_for_warn on
op_right
before checking for INTEGER_CST.
(warn_tautological_bitwise_comparison): Call
tree_strip_any_location_wrapper on lhs, rhs, and bitop's
operand
before checking for INTEGER_CST.
(readonly_error): Strip any location wrapper.
(warn_array_subscript_with_type_char): Strip location wrappers
before checking for INTEGER_CST.  Use the location of the index
if
available.

gcc/cp/ChangeLog:
PR c++/43064
PR c++/43486
* call.c (build_conditional_expr_1): Strip location wrappers
when
checking for CONST_DECL.
(conversion_null_warnings): Use location of "expr" if
available.
* class.c (fixed_type_or_null): Handle location wrappers.
* constexpr.c (potential_constant_expression_1): Likewise.
* cvt.c (ignore_overflows): Strip location wrappers when
checking for INTEGER_CST, and re-wrap the result if present.
(ocp_convert): Call fold_for_warn before checking for
INTEGER_CST.
* decl.c (reshape_init_r): Strip any location wrapper.
(undeduced_auto_decl): Likewise.
* decl2.c (grokbitfield): Likewise for width.
* expr.c (mark_discarded_use): Likewise for expr.
* init.c (build_aggr_init): Likewise before checking init for
DECL_P.
(warn_placement_new_too_small): Call fold_for_warn on adj
before
checking for CONSTANT_CLASS_P, and on nelts.  Strip any
location
wrapper from op0 and on oper before checking for VAR_P.
* lambda.c (add_capture): Strip any location from initializer.
* name-lookup.c (handle_namespace_attrs): Strip any location
from
x before checking for STRING_CST.
* parser.c (cp_parser_primary_expression): Call
maybe_add_location_wrapper on numeric and string literals.
(cp_parser_postfix_expression): Strip any location wrapper when
checking for DECL_IS_BUILTIN_CONSTANT_P.
(cp_parser_binary_expression): Strip any location wrapper when
checking for DECL_P on the lhs.
(cp_parser_decltype_expr): Suppress location wrappers in the
id-expression.
(cp_parser_mem_initializer): Add location wrappers to the
parenthesized expression list.
(cp_parser_template_parameter_list): Don't create wrapper nodes
within a template-parameter-list.

[committed] Add testcase for already fixed PR tree-optimization/87320

[Jakub Jelinek]

Hi!

I've committed the following testcase for already fixed PR, which has been
fixed by the PR87288 fix, after testing on x86_64-linux and i686-linux.

2018-12-04  Jakub Jelinek  

PR tree-optimization/87320
* gcc.dg/pr87320.c: New test.

--- gcc/testsuite/gcc.dg/pr87320.c.jj   2018-12-04 19:16:45.370455885 +0100
+++ gcc/testsuite/gcc.dg/pr87320.c  2018-12-04 19:16:38.428568535 +0100
@@ -0,0 +1,28 @@
+/* PR tree-optimization/87320 */
+/* { dg-do run } */
+/* { dg-options "-O3" } */
+/* { dg-additional-options "-mavx" { target avx_runtime } } */
+
+static void __attribute__ ((noinline))
+transpose_vector (unsigned long n)
+{
+  unsigned long data[2 * n];
+  for (unsigned long i = 0; i < 2 * n; i++)
+data[i] = 4 * i + 2;
+
+  unsigned long transposed[n];
+  for (unsigned long i = 0; i < n; i++)
+transposed[i] = data[2 * i];
+
+  for (unsigned long i = 0; i < n; i++)
+if (transposed[i] != 8 * i + 2)
+  __builtin_abort ();
+}
+
+int
+main ()
+{
+  transpose_vector (4);
+  transpose_vector (120);
+  return 0;
+}

Jakub

[committed] Handle targets with 2 byte wchar_t better in strlenopt-58.c

[Jeff Law]

This is another minor testsuite patch.   strlenopt-58.c assumes 4 byte
wchar_t.  On targets with a smaller wchar_t it will get an error/warning.

This patch adds a dg-warning on the appropriate lines for targets that
do not have 4byte wchar_t.

It's been tested on h8 to verify the bogus warnings/errors are gone. We
don't optimize it fully yet, but I'm not really focused on that kind of
error right now.

It's also been tested on x86_64 to verify that it didn't break anything
on targets with a 4 byte wchar_t.


Installing on the trunk.


Jeff
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 18ef9edb7ad..7aad09dae78 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2018-12-04  Jeff Law  
+
+   * gcc.dg/strlenopt-58.c: Handle targets with 2 byte wchar_t.
+
 2018-12-04  Martin Sebor  
 
* gcc.target/i386/attr-aligned-2.c: New test.
diff --git a/gcc/testsuite/gcc.dg/strlenopt-58.c 
b/gcc/testsuite/gcc.dg/strlenopt-58.c
index e0e80680936..034961cd810 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-58.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-58.c
@@ -34,8 +34,8 @@ extern void* memchr (const void*, int, size_t);
 
 static const wchar_t wc = L'1';
 static const wchar_t ws1[] = L"1";
-static const wchar_t wsx[] = L"\x12345678";
-static const wchar_t ws4[] = L"\x00123456\x12005678\x12340078\x12345600";
+static const wchar_t wsx[] = L"\x12345678";/* { dg-warning "hex 
escape" "" { target { ! 4byte_wchar_t } } } */
+static const wchar_t ws4[] = L"\x00123456\x12005678\x12340078\x12345600";  
/* { dg-warning "hex escape" "" { target { ! 4byte_wchar_t } } } */
 
 void test_wide (void)
 {
@@ -47,7 +47,7 @@ void test_wide (void)
 
   ELIM (memchr (L"" + 1, 0, 0) == 0);
   ELIM (memchr ( + 1, 0, 0) == 0);
-  ELIM (memchr (L"\x12345678", 0, sizeof (wchar_t)) == 0);
+  ELIM (memchr (L"\x12345678", 0, sizeof (wchar_t)) == 0); /* { 
dg-warning "hex escape" "" { target { ! 4byte_wchar_t } } } */
 
   const size_t nb = sizeof ws4;
   const size_t nwb = sizeof (wchar_t);

Re: [PATCH 1/3][rs6000] x86-compat vector intrinsics fixes for BE, 32bit

[Segher Boessenkool]

On Tue, Dec 04, 2018 at 02:33:59PM -0600, Paul Clarke wrote:
> On 12/04/2018 02:16 PM, Segher Boessenkool wrote:
> > On Tue, Dec 04, 2018 at 08:59:03AM -0600, Paul Clarke wrote:
> >> @@ -1612,7 +1608,8 @@ _mm_bsrli_si128 (__m128i __A, const int __N)
> >>const __v16qu zeros = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 
> >> };
> >>  
> >>if (__N < 16)
> >> -if (__builtin_constant_p(__N))
> >> +if (__builtin_constant_p(__N) &&
> >> +__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
> > 
> > Please just use __LITTLE_ENDIAN__, as the rest of these files already does.
> > (More times in this patch; also BIG).
> 
> OK.  I was using the ORDER macros based on the GCC documentation at 
> https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html, which 
> mentions them and does not mention the shorter ENDIAN boolean macros.

Those are PowerPC ABI, or at least, GCC has defined them in rs6000.c since
forever and a bit.  The *mm headers already used them, so let's stick to
this one style please.

> > Do you have new testcases, too?  Or is all this caught by existing
> > testcases?
> 
> Same testcases.  They catch a lot more bugs when they actually run.

:-)


Segher

patch to fix PR88317

[Vladimir Makarov]

  The following patch fixes

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

  The patch was successfully bootstrapped and tested on x86/x86-64.

  I think the test is too big to add it to GCC testsuite.  If Richard 
implements bitmap poisoning, it would be possible to find a smaller test.


  Committed as rev. 266803.

Index: ChangeLog
===
--- ChangeLog	(revision 266802)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2018-12-04  Vladimir Makarov  
+
+	PR rtl-optimization/88317
+	* lra-constraints.c (split_reg): Don't set up check_only_regs if
+	we are outside the inheritance pass.
+
 2018-12-04  Jan Hubicka  
 
 	* ipa-prop.c (jump_function_useful_p): New.
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 266682)
+++ lra-constraints.c	(working copy)
@@ -5496,7 +5496,9 @@ lra_copy_reg_equiv (unsigned int new_reg
ORIGINAL_REGNO.  NEXT_USAGE_INSNS specifies which instruction in
the EBB next uses ORIGINAL_REGNO; it has the same form as the
"insns" field of usage_insns.  If TO is not NULL, we don't use
-   usage_insns, we put restore insns after TO insn.
+   usage_insns, we put restore insns after TO insn.  It is a case when
+   we call it from lra_split_hard_reg_for, outside the inheritance
+   pass.
 
The transformations look like:
 
@@ -5652,16 +5654,18 @@ split_reg (bool before_p, int original_r
   && mode == PSEUDO_REGNO_MODE (original_regno))
 lra_copy_reg_equiv (new_regno, original_regno);
   lra_reg_info[new_regno].restore_rtx = regno_reg_rtx[original_regno];
-  bitmap_set_bit (_only_regs, new_regno);
-  bitmap_set_bit (_only_regs, original_regno);
   bitmap_set_bit (_split_regs, new_regno);
   if (to != NULL)
 {
+  lra_assert (next_usage_insns == NULL);
   usage_insn = to;
   after_p = TRUE;
 }
   else
 {
+  /* We need check_only_regs only inside the inheritance pass.  */
+  bitmap_set_bit (_only_regs, new_regno);
+  bitmap_set_bit (_only_regs, original_regno);
   after_p = usage_insns[original_regno].after_p;
   for (;;)
 	{

Re: [PATCH, rs6000] Fix PR87496: ICE in aggregate_value_p at gcc/function.c:2046

[Segher Boessenkool]

On Tue, Dec 04, 2018 at 01:42:52PM -0600, Peter Bergner wrote:
> On 11/28/18 3:27 PM, Peter Bergner wrote:
> > gcc/
> > PR target/87496
> > * config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow
> > -mabi=ieeelongdouble without both -mpopcntd and -mvsx.
> 
> So this "fix" ended up accidentally disallowing -mabi=ibmlongdouble as well,
> which is wrong.  I need to look at not only whether the variable
> global_options_set.x_rs6000_ieeequad is set, which tells us whether we
> used -mabi={ibm,ieee}longdouble, but whether we actually enabled ieee128.
> The patch below fixes that oversight.  As we talked offline, we also should
> not allow either -mabi={ibm,ieee}longdouble with -mlong-double-64, since
> they are conflicting options.  I have added code to test for that as well.
> I have also added extra test cases to test for those.

Okay, so you make -mabi={ibm,ieee}longdouble be valid options only if
there is -mlong-double-128.  Could you add that to the documentation then
please?

> Is this ok for mainline once bootstrap and regtesting come back clean?

Okay with that documentation added and if it tests okay, yes.  Thanks!

> Since I backported the earlier fix to GCC8, I'd like to backport this
> there too.

Okay for there too.


Segher


> gcc/
>   PR target/87496
>   * config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow
>   -mabi=ieeelongdouble and -mabi=ibmlongdouble without -mlong-double-128.
>   Do not error for -mabi=ibmlongdouble and no ISA 2.06 support.
> 
> gcc/testsuite/
>   PR target/87496
>   * gcc.target/powerpc/pr87496.c: Rename from this...
>   * gcc.target/powerpc/pr87496-1.c: ...to this.  Update comment.
>   * gcc.target/powerpc/pr87496-2.c: New test.
>   * gcc.target/powerpc/pr87496-3.c: New test.

Re: [PATCH 3/3][rs6000] Enable x86-compat vector intrinsics testing

[Segher Boessenkool]

On Tue, Dec 04, 2018 at 09:00:18AM -0600, Paul Clarke wrote:
> The testsuite tests for the compatibility implementations of x86 vector
> intrinsics for "powerpc" had been inadvertently made to PASS
> without actually running the test code.
> 
> This patch removes the code which kept the tests from running the actual
> test code.

So everything just works this way?  Or do many tests fail nastily if you
run it on too old hardware?

> 2018-12-03  Paul A. Clarke  
> 
> [gcc/testsuite]
> 
>   PR target/88316
>   * gcc.target/powerpc/bmi-check.h: Remove test for
>   __BUILTIN_CPU_SUPPORTS__, thereby enabling test code to run.
>   * gcc.target/powerpc/bmi2-check.h: Likewise.
>   * gcc.target/powerpc/mmx-check.h: Likewise.
>   * gcc.target/powerpc/sse-check.h: Likewise.
>   * gcc.target/powerpc/sse2-check.h: Likewise.
>   * gcc.target/powerpc/sse3-check.h: Likewise.
>   * gcc.target/powerpc/ssse3-check.h: Likewise.

Okay for trunk if it all Just Works.  Thanks!

(So do test it on at least a p7, maybe a p6?)


Segher

[PATCH 1/2] v2: C++: more location wrapper nodes (PR c++/43064, PR c++/43486)

[David Malcolm]

The v1 patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00304.html 
has bitrotten somewhat, so here's v2 of the patch, updated relative
to r266740.

Blurb from v1 patch follows:

The C++ frontend gained various location wrapper nodes in r256448 (GCC 8).
That patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00799.html
added wrapper nodes around all nodes with !CAN_HAVE_LOCATION_P for:

* arguments at callsites, and for

* typeid, alignof, sizeof, and offsetof.

This is a followup to that patch, adding many more location wrappers
to the C++ frontend.  It adds location wrappers for nodes with
!CAN_HAVE_LOCATION_P to:

* all literal nodes (in cp_parser_primary_expression)

* all id-expression nodes (in finish_id_expression), except within a
  decltype.

* all mem-initializer nodes within a mem-initializer-list
  (in cp_parser_mem_initializer)

However, the patch also adds some suppressions: regions in the parser
for which wrapper nodes will not be created:

* within a template-parameter-list or template-argument-list (in
  cp_parser_template_parameter_list and cp_parser_template_argument_list
  respectively), to avoid encoding the spelling location of the nodes
  in types.  For example, "array<10>" and "array<10>" are the same type,
  despite the fact that the two different "10" tokens are spelled in
  different locations in the source.

* within a gnu-style attribute (none of are handlers are set up to cope
  with location wrappers yet)

* within various OpenMP clauses

The patch enables various improvements to locations for bad
initializations, for -Wchar-subscripts, and enables various other
improvements in the followup patch.

For example, given the followup buggy mem-initializer:

class X {
  X() : bad(42),
good(42)
  { }
  void* bad;
  int good;
};

previously, our diagnostic was on the final close parenthesis of the
mem-initializer-list, leaving it unclear where the problem is:

t.cc: In constructor 'X::X()':
t.cc:3:16: error: invalid conversion from 'int' to 'void*' [-fpermissive]
3 | good(42)
  |^
  ||
  |int

whereas with the patch we highlight which expression is bogus:

t.cc: In constructor 'X::X()':
t.cc:2:13: error: invalid conversion from 'int' to 'void*' [-fpermissive]
2 |   X() : bad(42),
  | ^~
  | |
  | int

Similarly, the diagnostic for this bogus initialization:

i.cc:1:44: error: initializer-string for array of chars is too long 
[-fpermissive]
1 | char test[3][4] = { "ok", "too long", "ok" };
  |^

is improved by the patch so that it indicates which string is too long:

i.cc:1:27: error: initializer-string for array of chars is too long 
[-fpermissive]
1 | char test[3][4] = { "ok", "too long", "ok" };
  |   ^~

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, in
conjunction with the followup patch [1]

I did some light performance testing, comparing release builds with and
without the patch on kdecore.cc (preprocessed all-of-KDE) and a test file
that includes all of the C++ stdlib (but does nothing) with it, in both
cases compiling at -O3 -g.  In both cases there was no significant
difference in the overall wallclock time for all of compilation:

kdecode.c total wallclock time:

http://chart.apis.google.com/chart?cht=lc=700x400=x,y,x,y=1,58.26,61.79=FF,FF=control|experiment=58.26,61.79=t:59.55,60.26,60.53,60.35,60.17,60.27,59.26,60.01,60.21,60.23,60.1,60.2,60.12,60.48,60.32,60.18,60.01,60.01,60.04,59.96,60.1,60.11,60.21,60.36,60.08,60.1,60.16,60.01,60.21,60.15,60.12,60.09,59.96,60.12,60.06,60.12,60.05,60.11,59.93,59.99|59.6,59.3,60.03,60.1,60.49,60.35,60.03,60.1,59.87,60.39,60.1,59.96,60.19,60.45,59.97,59.91,60.0,59.99,60.09,60.15,60.79,59.98,60.16,60.09,60.02,60.05,60.32,60.01,59.95,59.88,60.1,60.07,60.22,59.87,60.04,60.11,60.01,60.09,59.86,59.86=0:|1|8|16|24|32|40|2:||Iteration|3:||Time+(secs)=Compilation+of+kdecore.cc+at+-O3+with+-g+for+x86_64-pc-linux-gnu:+total:+wall

cp-stdlib.cc total wallclock time:

http://chart.apis.google.com/chart?cht=lc=700x400=x,y,x,y=1,1.88,4.59=FF,FF=control|experiment=1.88,4.59=t:3.59,2.94,2.95,2.94,2.94,2.93,2.92,2.94,2.93,2.94,2.94,2.88,2.94,2.9,2.94,2.9,2.94,2.93,2.94,2.93,2.95,2.93,2.9,2.9,2.94,2.99,2.95,3.0,2.94,3.0,2.94,2.99,2.95,2.95,2.9,2.99,2.94,2.99,2.94,2.96|3.54,2.92,2.93,2.88,2.94,2.92,2.93,2.92,2.9,2.93,2.89,2.93,2.9,2.93,2.89,2.91,2.93,2.92,2.89,2.93,2.93,2.92,2.93,2.92,2.93,2.92,2.88,2.92,2.89,2.93,2.94,2.92,2.9,2.92,2.92,2.91,2.94,2.92,2.98,2.88=0:|1|8|16|24|32|40|2:||Iteration|3:||Time+(secs)=Compilation+of+cp-stdlib.cc+at+-O3+with+-g+for+x86_64-pc-linux-gnu:+total:+wall

-ftime-report did show that kdecode.cc's "phase parsing" was 3% slower
by wallclock:

[PATCH 2/2] v2: C++: improvements to binary operator diagnostics (PR c++/87504)

[David Malcolm]

The v1 patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00303.html
has bitrotten somewhat, so here's v2 of the patch, updated relative
to r266740.

Blurb from v1 patch follows:

The C frontend is able (where expression locations are available) to print
problems with binary operators in 3-location form, labelling the types of
the expressions:

  arg_0 op arg_1
  ~ ^~ ~
||
|arg1 type
arg0 type

The C++ frontend currently just shows the combined location:

  arg_0 op arg_1
  ~~^~~~

and fails to highlight where the subexpressions are, or their types.

This patch introduces a op_location_t struct for handling the above
operator-location vs combined-location split, and a new
class binary_op_rich_location for displaying the above, so that the
C++ frontend is able to use the more detailed 3-location form for
type mismatches in binary operators, and for -Wtautological-compare
(where types are not displayed).  Both forms can be seen in this
example:

bad-binary-ops.C:69:20: error: no match for 'operator&&' (operand types are
  's' and 't')
   69 |   return ns_4::foo && ns_4::inner::bar;
  |  ~ ^~ 
  ||   |
  |s   t
bad-binary-ops.C:69:20: note: candidate: 'operator&&(bool, bool)' 
   69 |   return ns_4::foo && ns_4::inner::bar;
  |  ~~^~~

The patch also allows from some uses of macros in
-Wtautological-compare, where both sides of the comparison have
been spelled the same way, e.g.:

Wtautological-compare-ranges.c:23:11: warning: self-comparison always
   evaluates to true [-Wtautological-compare]
   23 |   if (FOO == FOO);
  |   ^~

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, in
conjunction with the previous patch.

OK for trunk?
Dave

gcc/c-family/ChangeLog:
PR c++/87504
* c-common.h (warn_tautological_cmp): Convert 1st param from
location_t to const op_location_t &.
* c-warn.c (find_array_ref_with_const_idx_r): Strip location
wrapper when testing for INTEGER_CST.
(warn_tautological_bitwise_comparison): Convert 1st param from
location_t to const op_location_t &; use it to build a
binary_op_rich_location, and use this.
(spelled_the_same_p): New function.
(warn_tautological_cmp): Convert 1st param from location_t to
const op_location_t &.  Warn for macro expansions if
spelled_the_same_p.  Use binary_op_rich_location.

gcc/c/ChangeLog:
PR c++/87504
* c-typeck.c (class maybe_range_label_for_tree_type_mismatch):
Move from here to gcc-rich-location.h and gcc-rich-location.c.
(build_binary_op): Use struct op_location_t and
class binary_op_rich_location.

gcc/cp/ChangeLog:
PR c++/87504
* call.c (op_error): Convert 1st param from location_t to
const op_location_t &.  Use binary_op_rich_location for binary
ops.
(build_conditional_expr_1): Convert 1st param from location_t to
const op_location_t &.
(build_conditional_expr): Likewise.
(build_new_op_1): Likewise.
(build_new_op): Likewise.
* cp-tree.h (build_conditional_expr): Likewise.
(build_new_op): Likewise.
(build_x_binary_op): Likewise.
(cp_build_binary_op): Likewise.
* parser.c (cp_parser_primary_expression): Build a location
for id-expression nodes.
(cp_parser_binary_expression): Use an op_location_t when
calling build_x_binary_op.
(cp_parser_operator): Build a location for user-defined literals.
* typeck.c (build_x_binary_op): Convert 1st param from location_t
to const op_location_t &.
(cp_build_binary_op): Likewise.  Use binary_op_rich_location.

gcc/ChangeLog:
PR c++/87504
* gcc-rich-location.c
(maybe_range_label_for_tree_type_mismatch::get_text): Move here from
c/c-typeck.c.
(binary_op_rich_location::binary_op_rich_location): New ctor.
(binary_op_rich_location::use_operator_loc_p): New function.
* gcc-rich-location.h
(class maybe_range_label_for_tree_type_mismatch)): Move here from
c/c-typeck.c.
(struct op_location_t): New forward decl.
(class binary_op_rich_location): New class.
* tree.h (struct op_location_t): New struct.

gcc/testsuite/ChangeLog:
* c-c++-common/Wtautological-compare-ranges.c: New test.
* g++.dg/cpp0x/pr51420.C: Add -fdiagnostics-show-caret and update
expected output.
* g++.dg/diagnostic/bad-binary-ops.C: Update expected output from
1-location form to 3-location form, with labelling of ranges with
types.  Add examples of id-expression nodes with namespaces.
* g++.dg/diagnostic/param-type-mismatch-2.C: Likewise.

This is the 2nd commit message:

FIXME: column and multiline 

Re: Fix move_if_noexcept usages in _Hashtable

[François Dumont]

On 12/4/18 3:38 PM, Jonathan Wakely wrote:

On 04/12/18 07:45 +0100, François Dumont wrote:

Hi

  This patch fix a minor problem with usage of std::move_if_noexcept. 
We use it to move node content if move construtor is noexcept but we 
eventually use the allocator_type::construct method which might be 
slightly different. I think it is better to check for this method 
noexcept qualification.


This is likely to pessimize some code, since most allocators do not
have an exception-specification on their construct members.

Perhaps but the Standard mandates to call allocator construct so we 
don't have choice. It is surprising to consider value_type move 
constructor when we don't know what allocator construct does.


Most users do not change from std::allocator or, even if they do, do not 
implement construct so impact should be limited.


  Moreover I have added a special overload for nodes containing a 
std::pair. It is supposed to allow move semantic in associative 
containers where Key is stored as const deleting std::pair move 
constructor. In this case we should still move the Value part.


  It doesn't work for the moment because the std::pair piecewise 
constructor has no noexcept qualification. Is there any plan to add 
it ? I think adding it will force including  in stl_pair.h, is 
it fine ?


No feedback on this point ? Is using std::pair piecewise constructor ok ?



  If this evolution is accepted I'll adapt it for _Rb_tree that has 
the same problem.


  Working on this I also notice that content of initialization_list 
is not moved. Is there a plan to make initialization_list iterator 
type like move_iterator ? Should containers use 
__make_move_iterator_if_noexcept ?


No.

Whether to allow moving from std::initializer_list is an active topic,
see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1249r0.html

Ok, nice, allowing emplace build of values would be even better, I'll 
have a closer look.



  Tested under Linux x86_64 normal mode.

  Ok to commit this first step ?


No, this is not suitable for stage 3. It seems too risky.

We can reconsider it during stage 1, but I'd like to see (at least) a
new test showing a bug with the current code. For example, a type with
a move constructor that is noexcept, but when used with a
scoped_allocator_adaptor (which calls something other than the move
constructor) we incorrectly move elements, and lose data when an
exception happens.



Ok, I'll try.

[PATCH] testsuite: turn down verbosity of "process-message"

[David Malcolm]

When debugging a failing test, I typically invoke DejaGnu at
verbosity level 2 (via RUNTESTFLAGS="-v -v dg.exp=something"),
so that DejaGnu prints the command line used to invoke the
compiler; specifically these two sites:
  target.exp "Invoking the compiler as "
  remote.exp "Executing on $hostname"
which are both verbosity level 2.

Unfortunately I run into an O(n^2) issue with logging from
process-message:

  verbose "process-message:\n${dg-messages}" 2

where, as each message each processed, it emits the state
of dg-messages, containing the new message and all messages so far,
leading to exponentially-increasing output at level 2 as more test
messages are added.

This patch papers over the problem by moving the
problematic message to verbosity level 3.

Successfully regrtested on x86_64-pc-linux-gnu.

OK for trunk?

gcc/testsuite/ChangeLog:
* lib/gcc-dg.exp (process-message): Change verbosity level of
"verbose" from 2 to 3.
(dg-locus): Likewise.
---
 gcc/testsuite/lib/gcc-dg.exp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 305dd3c..054d884 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -1165,7 +1165,7 @@ proc process-message { msgproc msgprefix dgargs } {
 set newentry [lreplace $newentry 2 2 $expmsg]
 
 set dg-messages [lreplace ${dg-messages} end end $newentry]
-verbose "process-message:\n${dg-messages}" 2
+verbose "process-message:\n${dg-messages}" 3
 }
 
 # Look for messages that don't have standard prefixes.
@@ -1199,7 +1199,7 @@ proc dg-locus { args } {
 
 set newentry [lreplace $newentry 2 2 $expmsg]
 set dg-messages [lreplace ${dg-messages} end end $newentry]
-verbose "process-message:\n${dg-messages}" 2
+verbose "process-message:\n${dg-messages}" 3
 }
 
 # Handle output from -fopt-info for MSG_OPTIMIZED_LOCATIONS:
-- 
1.8.5.3

[committed] spellcheck.c: add another selftest for PR c/82967

[David Malcolm]

This adds another testcase for overzealous spellchecker suggestions,
reported on IRC.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

Committed to trunk as r266798, under the "obvious" rule.

gcc/ChangeLog:
PR c/82967
* spellcheck.c (selftest::test_suggestions): Add another
assertion.
---
 gcc/spellcheck.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/spellcheck.c b/gcc/spellcheck.c
index 690e6fa..391a242 100644
--- a/gcc/spellcheck.c
+++ b/gcc/spellcheck.c
@@ -378,6 +378,9 @@ test_suggestions ()
 
   ASSERT_NOT_SUGGESTED_FOR ("__DATE__", "__i386__");
   // dist == 4, max_length == min_length == 8
+
+  ASSERT_NOT_SUGGESTED_FOR ("start_input_device", "InputDevice");
+  // dist == 9, max_length == 18, min_length == 11
 }
 
 /* Verify that find_closest_string is sane.  */
-- 
1.8.5.3

Re: [PATCH 2/3][rs6000] Fix x86-compat vector intrinsics testcases for BE, 32bit

[Segher Boessenkool]

Hi!

On Tue, Dec 04, 2018 at 08:59:40AM -0600, Paul Clarke wrote:
> Fix general endian issues found in the test cases for the compatibility
> implementations of the x86 vector intrinsics.  (The tests had been
> inadvertently made to PASS without actually running the test code.
> A later patch fixes this issue.)
> 
> Additionally, a new  is added, as some of the APIs therein are
> now used by the test cases.  It is _not_ a complete implementation of the
> SSE4 interfaces, only the few "extract" interfaces uses by the tests.

Hrm.  We probably should tell the user this file isn't the real thing,
somehow.  Could you add a comment in (or near) the header of the file?
I don't think we'll need more, but we'll find out no doubt.

>   PR target/88316
>   * config/rs6000/smmintrin.h: New file.
>   * config.gcc: add smmintrin.h to extra_headers for powerpc*-*-*.

(Capital A).

> [gcc/testsuite]
> 
>   PR target/88316
>   * gcc.target/powerpc/mmx-packssdw-1.c: Fixes for big-endian.
>   * gcc.target/powerpc/mmx-packsswb-1.c: Likewise.
>   * gcc.target/powerpc/mmx-packuswb-1.c: Likewise.
>   * gcc.target/powerpc/mmx-pmulhw-1.c: Likewise.
>   * gcc.target/powerpc/sse-cvtpi32x2ps-1.c: Likewise.
>   * gcc.target/powerpc/sse-cvtpu16ps-1.c: Likewise.
>   * gcc.target/powerpc/sse-cvtss2si-1.c: Likewise.
>   * gcc.target/powerpc/sse-cvtss2si-2.c: Likewise.
>   * gcc.target/powerpc/sse2-pshufhw-1.c: Likewise.
>   * gcc.target/powerpc/sse2-pshuflw-1.c: Likewise.

Okay for trunk with that.  Thanks!


Segher

Re: [doc PATCH] update attribute docs for C++

[Sandra Loosemore]

On 12/4/18 9:26 AM, Martin Sebor wrote:


Thanks for the comments.  Attached is an updated patch with
the typos fixed.  I've left the rest as is.


Well, I still think a number of points I commented on before need to be 
clarified in the text.  If I'm confused, I think other readers will be, 
too, and users shouldn't have to search for discussion on gcc-patches to 
figure out what the manual means.



+Unless specified otherwise, function attributes that apply to function
+parameters of pointer types also apply to the implicit C++ @code{this}
+argument in non-static member functions, and to parameters of reference
+type.  In attributes that refer to function parameters by their position
+in the argument list the first parameter is at position one.  In C++
+non-static member functions position one refers to the implicit @code{this}
+pointer.  The same restrictions and effects apply to function attributes
+used with ordinary functions or C++ member functions.


Like this paragraph above.  Users may read that first sentence and think 
they can attach function attributes to parameter declarations.  I'd 
suggest rewriting this as


"function attributes that specify properties of the function's 
parameters, like @code{nonnull}, also apply"


or something like that.


+Unless specified otherwise, function attributes that apply to variables
+or function parameters of pointer types also apply to the implicit C++
+@code {this} argument in non-static member functions, and to arguments of
+reference type.
+


And similarly here, but this is even more confusing.  What function 
attributes apply to variables, and not just parameters?  Given this is 
the variable attribute section, I think it would be more useful to say 
something about how you attach a variable attribute to the "this" 
parameter, rather than talking about function attributes.



+The keyword @code{__attribute__} allows you to specify various special
+properties of types.  Some type attributes apply only to structure and
+union types, and in C++, also class types, while others can apply to
+any type defined via a @code{typedef} declaration.  Unless otherwise
+specified, the same restrictions and effects apply to attributes regardless
+of whether a type is a trivial structure or a C++ class with user-defined
+constructors, destructors, or a copy assignment.


And here I would really prefer to use standard terminology than trying 
to inaccurately summarize what the terminology means.  E.g.


"...whether or not a class is trivial (in the C++11 sense) or POD (in 
C++98)."


-Sandra

Re: [PATCH 1/3][rs6000] x86-compat vector intrinsics fixes for BE, 32bit

[Paul Clarke]

On 12/04/2018 02:16 PM, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Dec 04, 2018 at 08:59:03AM -0600, Paul Clarke wrote:
>> Fix general endian and 32-bit mode issues found in the
>> compatibility implementations of the x86 vector intrinsics when running the
>> associated test suite tests.  (The tests had been inadvertently made to PASS
>> without actually running the test code.  A later patch fixes this issue.)
>>
>> In a few cases, the opportunity was taken to update the vector API used in
>> the implementations to the preferred functions from the
>> OpenPOWER 64-Bit ELF V2 ABI Specification.
>>
>> [gcc]
>>
>> 2018-12-03  Paul A. Clarke  
>>
>>  PR target/88316
>>  * config/rs6000/mmintrin.h (_mm_unpackhi_pi8): Fix for big-endian.
>>  (_mm_unpacklo_pi8): Likewise.
>>  (_mm_mulhi_pi16): Likewise.
>>  (_mm_packs_pi16): Fix for big-endian. Use preferred API.
>>  (_mm_packs_pi32): Likewise.
>>  (_mm_packs_pu16): Likewise.
>>  * config/rs6000/xmmintrin.h (_mm_cvtss_si32): Fix for big-endian.
>>  (_mm_cvtss_si64): Likewise.
>>  (_mm_cvtpi32x2_ps): Likewise.
>>  (_mm_shuffle_ps): Likewise.
>>  (_mm_movemask_pi8): Likewise.
>>  (_mm_mulhi_pu16): Likewise.
>>  (_mm_sad_pu8): Likewise.
>>  (_mm_sad_pu8): Likewise.
>>  (_mm_cvtpu16_ps): Fix for big-endian. Use preferred API.
>>  (_mm_cvtpu8_ps): Likewise.
>>  * config/rs6000/emmintrin.h (_mm_movemask_pd): Fix for big-endian.
>>  (_mm_mul_epu32): Likewise.
>>  (_mm_bsrli_si128): Likewise.
>>  (_mm_movemask_epi8): Likewise.
>>  (_mm_shufflehi_epi16): Likewise.
>>  (_mm_shufflelo_epi16): Likewise.
>>  (_mm_shuffle_epi32): Likewise.
>>  * config/rs6000/pmmintrin.h (_mm_hadd_ps): Fix for big-endian.
>>  (_mm_sub_ps): Likewise.
>>  * config/rs6000/mmintrin.h (_mm_cmpeq_pi8): Fix for 32-bit mode.
> 
> 
>> @@ -1612,7 +1608,8 @@ _mm_bsrli_si128 (__m128i __A, const int __N)
>>const __v16qu zeros = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
>>  
>>if (__N < 16)
>> -if (__builtin_constant_p(__N))
>> +if (__builtin_constant_p(__N) &&
>> +__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
> 
> Please just use __LITTLE_ENDIAN__, as the rest of these files already does.
> (More times in this patch; also BIG).

OK.  I was using the ORDER macros based on the GCC documentation at 
https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html, which 
mentions them and does not mention the shorter ENDIAN boolean macros.

> Okay for trunk with that fixed.  Thanks!

Thanks for the review!

> Do you have new testcases, too?  Or is all this caught by existing
> testcases?

Same testcases.  They catch a lot more bugs when they actually run.

PC

Re: [PATCH 1/3][rs6000] x86-compat vector intrinsics fixes for BE, 32bit

[Segher Boessenkool]

Hi!

On Tue, Dec 04, 2018 at 08:59:03AM -0600, Paul Clarke wrote:
> Fix general endian and 32-bit mode issues found in the
> compatibility implementations of the x86 vector intrinsics when running the
> associated test suite tests.  (The tests had been inadvertently made to PASS
> without actually running the test code.  A later patch fixes this issue.)
> 
> In a few cases, the opportunity was taken to update the vector API used in
> the implementations to the preferred functions from the
> OpenPOWER 64-Bit ELF V2 ABI Specification.
> 
> [gcc]
> 
> 2018-12-03  Paul A. Clarke  
> 
>   PR target/88316
>   * config/rs6000/mmintrin.h (_mm_unpackhi_pi8): Fix for big-endian.
>   (_mm_unpacklo_pi8): Likewise.
>   (_mm_mulhi_pi16): Likewise.
>   (_mm_packs_pi16): Fix for big-endian. Use preferred API.
>   (_mm_packs_pi32): Likewise.
>   (_mm_packs_pu16): Likewise.
>   * config/rs6000/xmmintrin.h (_mm_cvtss_si32): Fix for big-endian.
>   (_mm_cvtss_si64): Likewise.
>   (_mm_cvtpi32x2_ps): Likewise.
>   (_mm_shuffle_ps): Likewise.
>   (_mm_movemask_pi8): Likewise.
>   (_mm_mulhi_pu16): Likewise.
>   (_mm_sad_pu8): Likewise.
>   (_mm_sad_pu8): Likewise.
>   (_mm_cvtpu16_ps): Fix for big-endian. Use preferred API.
>   (_mm_cvtpu8_ps): Likewise.
>   * config/rs6000/emmintrin.h (_mm_movemask_pd): Fix for big-endian.
>   (_mm_mul_epu32): Likewise.
>   (_mm_bsrli_si128): Likewise.
>   (_mm_movemask_epi8): Likewise.
>   (_mm_shufflehi_epi16): Likewise.
>   (_mm_shufflelo_epi16): Likewise.
>   (_mm_shuffle_epi32): Likewise.
>   * config/rs6000/pmmintrin.h (_mm_hadd_ps): Fix for big-endian.
>   (_mm_sub_ps): Likewise.
>   * config/rs6000/mmintrin.h (_mm_cmpeq_pi8): Fix for 32-bit mode.


> @@ -1612,7 +1608,8 @@ _mm_bsrli_si128 (__m128i __A, const int __N)
>const __v16qu zeros = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
>  
>if (__N < 16)
> -if (__builtin_constant_p(__N))
> +if (__builtin_constant_p(__N) &&
> +__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)

Please just use __LITTLE_ENDIAN__, as the rest of these files already does.
(More times in this patch; also BIG).

Okay for trunk with that fixed.  Thanks!

Do you have new testcases, too?  Or is all this caught by existing
testcases?


Segher

Re: [PATCH, rs6000] Fix PR87496: ICE in aggregate_value_p at gcc/function.c:2046

[Peter Bergner]

On 11/28/18 3:27 PM, Peter Bergner wrote:
> gcc/
>   PR target/87496
>   * config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow
>   -mabi=ieeelongdouble without both -mpopcntd and -mvsx.

So this "fix" ended up accidentally disallowing -mabi=ibmlongdouble as well,
which is wrong.  I need to look at not only whether the variable
global_options_set.x_rs6000_ieeequad is set, which tells us whether we
used -mabi={ibm,ieee}longdouble, but whether we actually enabled ieee128.
The patch below fixes that oversight.  As we talked offline, we also should
not allow either -mabi={ibm,ieee}longdouble with -mlong-double-64, since
they are conflicting options.  I have added code to test for that as well.
I have also added extra test cases to test for those.

Is this ok for mainline once bootstrap and regtesting come back clean?
Since I backported the earlier fix to GCC8, I'd like to backport this
there too.

Peter


gcc/
PR target/87496
* config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow
-mabi=ieeelongdouble and -mabi=ibmlongdouble without -mlong-double-128.
Do not error for -mabi=ibmlongdouble and no ISA 2.06 support.

gcc/testsuite/
PR target/87496
* gcc.target/powerpc/pr87496.c: Rename from this...
* gcc.target/powerpc/pr87496-1.c: ...to this.  Update comment.
* gcc.target/powerpc/pr87496-2.c: New test.
* gcc.target/powerpc/pr87496-3.c: New test.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 266792)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -4282,6 +4282,13 @@ rs6000_option_override_internal (bool gl
 }
   else if (rs6000_long_double_type_size == 128)
 rs6000_long_double_type_size = FLOAT_PRECISION_TFmode;
+  else if (global_options_set.x_rs6000_ieeequad)
+{
+  if (global_options.x_rs6000_ieeequad)
+   error ("%qs requires %qs", "-mabi=ieeelongdouble", "-mlong-double-128");
+  else
+   error ("%qs requires %qs", "-mabi=ibmlongdouble", "-mlong-double-128");
+}
 
   /* Set -mabi=ieeelongdouble on some old targets.  In the future, power server
  systems will also set long double to be IEEE 128-bit.  AIX and Darwin
@@ -4293,7 +4300,8 @@ rs6000_option_override_internal (bool gl
 
   else
 {
-  if (!TARGET_POPCNTD || !TARGET_VSX)
+  if (global_options.x_rs6000_ieeequad
+ && (!TARGET_POPCNTD || !TARGET_VSX))
error ("%qs requires full ISA 2.06 support", "-mabi=ieeelongdouble");
 
   if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT && TARGET_LONG_DOUBLE_128)
Index: gcc/testsuite/gcc.target/powerpc/pr87496-1.c
===
--- gcc/testsuite/gcc.target/powerpc/pr87496-1.c(revision 266792)
+++ gcc/testsuite/gcc.target/powerpc/pr87496-1.c(working copy)
@@ -1,4 +1,4 @@
-/* PR target/87496.c */
+/* PR target/87496 */
 /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
Index: gcc/testsuite/gcc.target/powerpc/pr87496-2.c
===
--- gcc/testsuite/gcc.target/powerpc/pr87496-2.c(nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr87496-2.c(working copy)
@@ -0,0 +1,9 @@
+/* PR target/87496 */
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
+/* { dg-options "-O2 -mcpu=power7 -mabi=ieeelongdouble -mlong-double-64 
-Wno-psabi" } */
+
+int i;
+
+/* { dg-error "'-mabi=ieeelongdouble' requires '-mlong-double-128'" "PR87496" 
{ target *-*-* } 0 } */
Index: gcc/testsuite/gcc.target/powerpc/pr87496-3.c
===
--- gcc/testsuite/gcc.target/powerpc/pr87496-3.c(nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr87496-3.c(working copy)
@@ -0,0 +1,8 @@
+/* PR target/87496 */
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-options "-O2 -mabi=ibmlongdouble -mlong-double-64 -Wno-psabi" } */
+
+int i;
+
+/* { dg-error "'-mabi=ibmlongdouble' requires '-mlong-double-128'" "PR87496" { 
target *-*-* } 0 } */
Index: gcc/testsuite/gcc.target/powerpc/pr87496.c
===
--- gcc/testsuite/gcc.target/powerpc/pr87496.c  (revision 266792)
+++ gcc/testsuite/gcc.target/powerpc/pr87496.c  (nonexistent)
@@ -1,10 +0,0 @@
-/* PR target/87496.c */
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
-/* { dg-skip-if "" { powerpc*-*-darwin* } } */
-/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
-/* 

Re: [PATCH, OpenACC] Support Fortran derived type members in "acc update" directives

[Julian Brown]

On Tue, 4 Dec 2018 20:12:58 +0100
Jakub Jelinek  wrote:

> On Tue, Dec 04, 2018 at 07:06:43PM +, Julian Brown wrote:
> > Thanks for the review! As it happened though, I had to rewrite a
> > lot of the code in this patch for the attach/detach patch, and I
> > had meant to withdraw this one. Many apologies about the wasted
> > time! I mentioned the superseding in the first submission of the
> > attach/detach patch:
> > 
> >   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00826.html  
> 
> I haven't looked at the dynamic array series because I haven't heard
> back on https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00946.html

Those patches are independent of the attach/detach ones (though the
latter do depend on Chung-Lin's async support patches).

Thanks,

Julian

Re: [PATCH, OpenACC] Support Fortran derived type members in "acc update" directives

[Jakub Jelinek]

On Tue, Dec 04, 2018 at 07:06:43PM +, Julian Brown wrote:
> Thanks for the review! As it happened though, I had to rewrite a lot of
> the code in this patch for the attach/detach patch, and I had meant to
> withdraw this one. Many apologies about the wasted time! I mentioned
> the superseding in the first submission of the attach/detach patch:
> 
>   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00826.html

I haven't looked at the dynamic array series because I haven't heard
back on https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00946.html

Jakub

Re: C++ PATCH for c++/88184, ICE when treating name as template-name

[Jason Merrill]

OK.
On Tue, Dec 4, 2018 at 12:27 PM Marek Polacek  wrote:
>
> On Thu, Nov 29, 2018 at 04:03:50PM -0500, Jason Merrill wrote:
> > On 11/29/18 1:28 PM, Marek Polacek wrote:
> > > On Wed, Nov 28, 2018 at 10:34:11PM -0500, Jason Merrill wrote:
> > > > On 11/28/18 10:48 AM, Marek Polacek wrote:
> > > > > Since P0846R0 was implemented, a name will be treated as a 
> > > > > template-name when
> > > > > it is an unqualified-id followed by a < and name lookup finds either 
> > > > > one or
> > > > > more functions or finds nothing, in order to potentially cause ADL to 
> > > > > be performed.
> > > > >
> > > > > In this case, we had
> > > > >
> > > > > f ();
> > > > >
> > > > > where we'd found a decl for f (not a TEMPLATE_DECL) and < follows.
> > > >
> > > >  From the backtrace in the PR, it seems as though we're treating f as
> > > > non-dependent, which is wrong.  type_dependent_expression_p only looks 
> > > > at
> > > > the arguments of a TEMPLATE_ID_EXPR if it has unknown_type_node, so we
> > > > probably want to give it that type.
> > >
> > > That was my first attempt but it was crashing everywhere, so I abandoned 
> > > it.
> > > But I was setting unknown_type_node in cp_parser_template_name whereas 
> > > this
> > > patch sets it in cp_parser_postfix_expression, which works and is arguably
> > > better because it reuses the diagnostic in finish_call_expr.
> >
> > Would it work for lookup_template_function to always use unknown_type_node?
>
> Luckily, that seems to work!  I wish I'd thought of that, I like fixing bugs 
> by
> simplifying code.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-12-04  Marek Polacek  
>
> PR c++/88184 - ICE when treating name as template-name.
> * pt.c (lookup_template_function): Always build the TEMPLATE_ID_EXPR
> with unknown_type_node.
>
> * g++.dg/cpp2a/fn-template17.C: New test.
> * g++.dg/cpp2a/fn-template18.C: New test.
>
> diff --git gcc/cp/pt.c gcc/cp/pt.c
> index a0d899f594b..78addc6c1c2 100644
> --- gcc/cp/pt.c
> +++ gcc/cp/pt.c
> @@ -9068,8 +9068,6 @@ add_pending_template (tree d)
>  tree
>  lookup_template_function (tree fns, tree arglist)
>  {
> -  tree type;
> -
>if (fns == error_mark_node || arglist == error_mark_node)
>  return error_mark_node;
>
> @@ -9090,11 +9088,7 @@ lookup_template_function (tree fns, tree arglist)
>return fns;
>  }
>
> -  type = TREE_TYPE (fns);
> -  if (TREE_CODE (fns) == OVERLOAD || !type)
> -type = unknown_type_node;
> -
> -  return build2 (TEMPLATE_ID_EXPR, type, fns, arglist);
> +  return build2 (TEMPLATE_ID_EXPR, unknown_type_node, fns, arglist);
>  }
>
>  /* Within the scope of a template class S, the name S gets bound
> diff --git gcc/testsuite/g++.dg/cpp2a/fn-template17.C 
> gcc/testsuite/g++.dg/cpp2a/fn-template17.C
> new file mode 100644
> index 000..f0d24107682
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp2a/fn-template17.C
> @@ -0,0 +1,21 @@
> +// PR c++/88184
> +// { dg-do compile }
> +// { dg-options "-std=c++2a -fchecking=2" }
> +
> +namespace A
> +{
> +  void f ();
> +}
> +
> +using A::f;
> +
> +template  void g ()
> +{
> +  f (); // { dg-error "no matching function for call" }
> +}
> +
> +void
> +fn ()
> +{
> +  g();
> +}
> diff --git gcc/testsuite/g++.dg/cpp2a/fn-template18.C 
> gcc/testsuite/g++.dg/cpp2a/fn-template18.C
> new file mode 100644
> index 000..7fe5e89ace3
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp2a/fn-template18.C
> @@ -0,0 +1,23 @@
> +// PR c++/88184
> +// { dg-do compile }
> +// { dg-options "-std=c++2a -fchecking=2" }
> +
> +namespace A
> +{
> +  void f ();
> +  void f (int);
> +  void f (int, int);
> +}
> +
> +using A::f;
> +
> +template  void g ()
> +{
> +  f (); // { dg-error "no matching function for call" }
> +}
> +
> +void
> +fn ()
> +{
> +  g();
> +}

Re: [PATCH, OpenACC] Support Fortran derived type members in "acc update" directives

[Julian Brown]

Hi Jakub,

On Tue, 4 Dec 2018 15:17:08 +0100
Jakub Jelinek  wrote:

> On Mon, Sep 03, 2018 at 08:46:54PM -0400, Julian Brown wrote:
> > 2018-09-03  Cesar Philippidis  
> > 
> > gcc/fortran/
> > * openmp.c (gfc_match_omp_variable_list): New allow_derived
> > argument. (gfc_match_omp_map_clause): Update call to
> > gfc_match_omp_variable_list. (gfc_match_omp_clauses): Update
> > calls to gfc_match_omp_map_clause. (gfc_match_oacc_update):
> > Update call to gfc_match_omp_clauses. (resolve_omp_clauses):
> > Permit derived type variables in ACC UPDATE clauses.
> > * trans-openmp.c (gfc_trans_omp_clauses_1): Lower derived
> > type members.
> > 
> > gcc/
> > * gimplify.c (gimplify_scan_omp_clauses): Update handling
> > of ACC UPDATE variables.
> > 
> > gcc/testsuite/
> > * gfortran.dg/goacc/derived-types.f90: New test.
> > 
> > libgomp/
> > * testsuite/libgomp.oacc-fortran/update-2.f90: New test.
> > * testsuite/libgomp.oacc-fortran/derived-type-1.f90: New
> > test.  
> 
> Note, already OpenMP 4.5 allows the %s in map/to/from clauses, I just
> didn't get to that yet.
> And OpenMP 5.0 allows arbitrary expressions there.
> 
> > @@ -4336,9 +4342,12 @@ resolve_omp_clauses (gfc_code *code,
> > gfc_omp_clauses *omp_clauses, || n->expr->ref == NULL
> > || n->expr->ref->next
> > || n->expr->ref->type != REF_ARRAY)
> > - gfc_error ("%qs in %s clause at %L is not a
> > proper "
> > -"array section", n->sym->name,
> > name,
> > ->where);
> > + {
> > +   if (n->sym->ts.type != BT_DERIVED)
> > + gfc_error ("%qs in %s clause at %L is
> > not a proper "
> > +"array section",
> > n->sym->name, name,
> > +>where);
> > + }
> > else if (n->expr->ref->u.ar.codimen)
> >   gfc_error ("Coarrays not supported in %s
> > clause at %L", name, >where);  
> 
> I'm worried about this change a little bit.  It isn't guarded for
> OpenACC only and I wonder if you actually resolve properly the
> derived expressions (look inside of those).
> 
> > diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> > index f038f4c..95b15e5 100644
> > --- a/gcc/fortran/trans-openmp.c
> > +++ b/gcc/fortran/trans-openmp.c
> > @@ -2108,7 +2108,68 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> > gfc_omp_clauses *clauses, tree decl = gfc_get_symbol_decl (n->sym);
> >   if (DECL_P (decl))
> > TREE_ADDRESSABLE (decl) = 1;
> > - if (n->expr == NULL || n->expr->ref->u.ar.type ==
> > AR_FULL)
> > + /* Handle derived-typed members for OpenACC Update.
> > */
> > + if (n->sym->ts.type == BT_DERIVED
> > + && n->expr != NULL && n->expr->ref != NULL
> > + && (n->expr->ref->next == NULL
> > + || (n->expr->ref->next != NULL
> > + && n->expr->ref->next->type == REF_ARRAY
> > + && n->expr->ref->next->u.ar.type ==
> > AR_FULL))
> > + && (n->expr->ref->type == REF_ARRAY
> > + && n->expr->ref->u.ar.type != AR_SECTION))  
> 
> Like here you have all kinds of conditions, but has resolving made
> sure all the needed diagnostics is emitted?
> Perhaps at least for now this also should be guarded on OpenACC only,
> once OpenMP allows %s in map/to/from, part of this will be usable for
> it, but e.g.
> 
> > + if (context != type)
> > +   {
> > + tree f2 = c->norestrict_decl;
> > + if (!f2 || DECL_FIELD_CONTEXT (f2) != type)
> > +   for (f2 = TYPE_FIELDS (TREE_TYPE (decl));
> > f2;
> > +f2 = DECL_CHAIN (f2))
> > + if (TREE_CODE (f2) == FIELD_DECL
> > + && DECL_NAME (f2) == DECL_NAME
> > (field))
> > +   break;
> > + gcc_assert (f2);
> > + c->norestrict_decl = f2;
> > + field = f2;
> > +   }  
> 
> the above stuff looks way too OpenACC specific.

Thanks for the review! As it happened though, I had to rewrite a lot of
the code in this patch for the attach/detach patch, and I had meant to
withdraw this one. Many apologies about the wasted time! I mentioned
the superseding in the first submission of the attach/detach patch:

  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00826.html

but omitted to follow up with a link back from this patch to that one.
A revised version of the attach/detach patch is here:

  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02556.html

OpenACC 2.6 allows derived type member accesses (or structs, etc.) on
more types of directive than just "update", so this patch wasn't
sufficient -- for the new 

Re: [doc PATCH] document when GCC ignores attribute aligned

[Martin Sebor]

On 12/4/18 12:20 AM, Sandra Loosemore wrote:

On 12/3/18 8:23 PM, Martin Sebor wrote:

Last week we agreed to clarify that attribute aligned on a function
can decrease its alignment if it hasn't been previously declared
with one.  Attached is this change.

Besides the above, I also mention that the attribute specifies
the alignment of the first instruction of the function (in case
that wasn't obvious) , and that it has no effect in the absence
of a definition.

I wrote some tests to convince myself this actually works as
I expected.  Where it does I add those tests to the testsuite
via this patch.  Where it doesn't I opened a bug (PR 88345).

Martin



Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi    (revision 266766)
+++ gcc/doc/extend.texi    (working copy)
@@ -2386,16 +2386,20 @@ and may not be available on all targets.
 @itemx aligned (@var{alignment})
 @cindex @code{aligned} function attribute
 The @code{aligned} attribute specifies a minimum alignment for
-the function, measured in bytes.  When specified, @var{alignment} must
-be an integer constant power of 2.  Specifying no @var{alignment} 
argument

-implies the maximum alignment for the target, which is often, but by no
-means always, 8 or 16 bytes.
+the first instruction of the function, measured in bytes.  When 
specified,

+@var{alignment} must be an integer constant power of 2.  Specifying no
+@var{alignment} argument implies the ideal alignment for the target,
+which is often, but by no means always, 8 or 16 bytes.  The attribute


I think you might as well delete the end of the sentence starting with 
"which is often...".  It adds words but no useful information.  (Maybe 
it's 8 bytes, maybe it's 16 bytes, maybe it's something else)


I added those words in r265498.  I was hoping to give people
an idea of roughly what they might expect because I couldn't
think of a good way to find out.  But since then I realized
that the __alignof__ operator can be used to query this
alignment and I agree that the sentence isn't helpful anymore
(maybe it never really was).  I've replaced it with a reference
to __alignof__ instead and checked in r266792.

Martin




+has no effect when a definition for the function is not provided in
+the same translation unit.

-You cannot use this attribute to decrease the alignment of a function,
-only to increase it.  However, when you explicitly specify a function
-alignment this overrides the effect of the
-@option{-falign-functions} (@pxref{Optimize Options}) option for this
-function.
+The attribute cannot be used to decrease the alignment of a function
+previously declared with a more restrictive alignment; only to increase
+it.  Attempts to do otherwise are diagnosed.  Some targets specify
+a minimum default alignment for functions that is greater than 1.  On
+such targets, specifying a less restrictive alignment is silently 
ignored.
+Using the attribute overrides the effect of the 
@option{-falign-functions}

+(@pxref{Optimize Options}) option for this function.

 Note that the effectiveness of @code{aligned} attributes may be
 limited by inherent limitations in the system linker 


This patch is OK with the above nit fixed.

-Sandra

[PATCH PR libstdc++/88341] -

[Ed Smith-Rowland]

Committed as obvious 266788.

Ed


2018-12-03  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/88341 - Complex norm doesn't compile with C++11
* include/std/complex (_S_do_it): Make C++20 constexpr.
* testsuite/26_numerics/complex/value_operations/pr88341.cc: New test.

Index: include/std/complex
===
--- include/std/complex (revision 266769)
+++ include/std/complex (working copy)
@@ -659,7 +659,7 @@
 struct _Norm_helper
 {
   template
-static inline _GLIBCXX_CONSTEXPR _Tp _S_do_it(const complex<_Tp>& __z)
+static inline _GLIBCXX20_CONSTEXPR _Tp _S_do_it(const complex<_Tp>& 
__z)
 {
   const _Tp __x = __z.real();
   const _Tp __y = __z.imag();
@@ -671,7 +671,7 @@
 struct _Norm_helper
 {
   template
-static inline _GLIBCXX_CONSTEXPR _Tp _S_do_it(const complex<_Tp>& __z)
+static inline _GLIBCXX20_CONSTEXPR _Tp _S_do_it(const complex<_Tp>& 
__z)
 {
   //_Tp __res = std::abs(__z);
   //return __res * __res;
Index: testsuite/26_numerics/complex/value_operations/pr88341.cc
===
--- testsuite/26_numerics/complex/value_operations/pr88341.cc   (nonexistent)
+++ testsuite/26_numerics/complex/value_operations/pr88341.cc   (working copy)
@@ -0,0 +1,27 @@
+// { dg-options "-std=gnu++11" }
+// { dg-do compile { target c++11 } }
+
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+
+double
+n(std::complex& c)
+{
+  return std::norm(c);
+}

Re: [PATCH 0/3][rs6000] x86-compat vector intrinsics fixes for BE, 32bit

[Segher Boessenkool]

On Tue, Dec 04, 2018 at 08:58:15AM -0600, Paul Clarke wrote:
> Many of the tests for the x86-compatible vector intrinsics implementations
> were protected by "#ifdef __BUILTIN_CPU_SUPPORTS__", which is only enabled
> with recent enough glibc that in most environments, the test were silently
> passing without actually testing anything.

And that will still be true for years to come.  Right.  Thanks for working
on this.

> Patches which follow:
> 01: Fix the implementations.
> 02: Fix the test cases.
> 03: Enable the tests to actually run the test code.

In the future, please thread the patches, so that all of them have
In-Reply-To: the 0/N patch.


Segher

Re: [Patch, ppc/darwin 2/2] Make Darwin's call handling follow the style of AIX/ELFv2/sysv.

[Segher Boessenkool]

On Mon, Dec 03, 2018 at 07:18:20PM +, Iain Sandoe wrote:
> revised version, on top of the revised patch 1 attached.  I’ve taken the 
> opportunity to reduce the number of TARGET_MACHO conditionals in rs6000.md 
> (handle in rs6000.c instead)

> From 82ac030d49fd2ae78b75a350c5efc59375df42a6 Mon Sep 17 00:00:00 2001
> From: Iain Sandoe 
> Date: Sat, 1 Dec 2018 16:23:20 +
> Subject: [PATCH] [darwin,ppc] Update call expansions to follow the new scheme.
> 
> This also makes it a bit more apparent what we can remove when the
> mlongcall optimisation is removed.

> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -10285,8 +10285,10 @@
>  
>if (DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)
>  rs6000_call_aix (NULL_RTX, operands[0], operands[1], operands[2]);
> -  else
> +  else if (DEFAULT_ABI == ABI_V4)
>  rs6000_call_sysv (NULL_RTX, operands[0], operands[1], operands[2]);
> +  else
> +rs6000_call_darwin (NULL_RTX, operands[0], operands[1], operands[2]);

Maybe

  else if (DEFAULT_ABI == ABI_DARWIN)
...
  else
gcc_unreachable ();

?  Similar elsewhere.

And I think I saw a missing space-before-opening-paren somewhere, but I
cannot find it now.  Okay for trunk, anyhow.


Segher

Re: C++ PATCH for c++/88184, ICE when treating name as template-name

[Marek Polacek]

On Thu, Nov 29, 2018 at 04:03:50PM -0500, Jason Merrill wrote:
> On 11/29/18 1:28 PM, Marek Polacek wrote:
> > On Wed, Nov 28, 2018 at 10:34:11PM -0500, Jason Merrill wrote:
> > > On 11/28/18 10:48 AM, Marek Polacek wrote:
> > > > Since P0846R0 was implemented, a name will be treated as a 
> > > > template-name when
> > > > it is an unqualified-id followed by a < and name lookup finds either 
> > > > one or
> > > > more functions or finds nothing, in order to potentially cause ADL to 
> > > > be performed.
> > > > 
> > > > In this case, we had
> > > > 
> > > > f ();
> > > > 
> > > > where we'd found a decl for f (not a TEMPLATE_DECL) and < follows.
> > > 
> > >  From the backtrace in the PR, it seems as though we're treating f as
> > > non-dependent, which is wrong.  type_dependent_expression_p only looks at
> > > the arguments of a TEMPLATE_ID_EXPR if it has unknown_type_node, so we
> > > probably want to give it that type.
> > 
> > That was my first attempt but it was crashing everywhere, so I abandoned it.
> > But I was setting unknown_type_node in cp_parser_template_name whereas this
> > patch sets it in cp_parser_postfix_expression, which works and is arguably
> > better because it reuses the diagnostic in finish_call_expr.
> 
> Would it work for lookup_template_function to always use unknown_type_node?

Luckily, that seems to work!  I wish I'd thought of that, I like fixing bugs by
simplifying code.

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

2018-12-04  Marek Polacek  

PR c++/88184 - ICE when treating name as template-name.
* pt.c (lookup_template_function): Always build the TEMPLATE_ID_EXPR
with unknown_type_node.

* g++.dg/cpp2a/fn-template17.C: New test.
* g++.dg/cpp2a/fn-template18.C: New test.

diff --git gcc/cp/pt.c gcc/cp/pt.c
index a0d899f594b..78addc6c1c2 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -9068,8 +9068,6 @@ add_pending_template (tree d)
 tree
 lookup_template_function (tree fns, tree arglist)
 {
-  tree type;
-
   if (fns == error_mark_node || arglist == error_mark_node)
 return error_mark_node;
 
@@ -9090,11 +9088,7 @@ lookup_template_function (tree fns, tree arglist)
   return fns;
 }
 
-  type = TREE_TYPE (fns);
-  if (TREE_CODE (fns) == OVERLOAD || !type)
-type = unknown_type_node;
-
-  return build2 (TEMPLATE_ID_EXPR, type, fns, arglist);
+  return build2 (TEMPLATE_ID_EXPR, unknown_type_node, fns, arglist);
 }
 
 /* Within the scope of a template class S, the name S gets bound
diff --git gcc/testsuite/g++.dg/cpp2a/fn-template17.C 
gcc/testsuite/g++.dg/cpp2a/fn-template17.C
new file mode 100644
index 000..f0d24107682
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/fn-template17.C
@@ -0,0 +1,21 @@
+// PR c++/88184
+// { dg-do compile }
+// { dg-options "-std=c++2a -fchecking=2" }
+
+namespace A
+{
+  void f ();
+}
+
+using A::f;
+
+template  void g ()
+{
+  f (); // { dg-error "no matching function for call" }
+}
+
+void
+fn ()
+{
+  g();
+}
diff --git gcc/testsuite/g++.dg/cpp2a/fn-template18.C 
gcc/testsuite/g++.dg/cpp2a/fn-template18.C
new file mode 100644
index 000..7fe5e89ace3
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/fn-template18.C
@@ -0,0 +1,23 @@
+// PR c++/88184
+// { dg-do compile }
+// { dg-options "-std=c++2a -fchecking=2" }
+
+namespace A
+{
+  void f ();
+  void f (int);
+  void f (int, int);
+}
+
+using A::f;
+
+template  void g ()
+{
+  f (); // { dg-error "no matching function for call" }
+}
+
+void
+fn ()
+{
+  g();
+}

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v5]

[Pedro Alves]

On 12/04/2018 04:56 PM, Nick Clifton wrote:
> Hi Pedro,
> 
>> The issue pointed out by
>>
>>  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02592.html
>>
>> is still present in this version.
> 
> Doh!  Yes I meant to fix that one too, but forgot.
> 
>> Also, noticed a typo here:
>>
>>> +/* If DMGL_NO_RECURE_LIMIT is not enabled, then this is the value used as
>>
>> Typo: "RECURE"
> 
> Oops - thanks.
> 
> OK, revised (v5) patch attached.  Is this version acceptable to all ?
> 
This is fine with me.

Thanks,
Pedro Alves

Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

[Fritz Reese]

On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek  wrote:
>
> Just a couple of random comments.
> -fdec-pad-with-spaces option name doesn't look right, because it doesn't say
> what the option affects.  So perhaps have transfer in the option name?
[...]
> Wouldn't it be better to allow specifying whatever character you want to pad
> with, so that users can choose something even different?

I concur with this. In that case some option like -ftransfer-pad-char=
may be a more appriopriate name, where -fdec may enable a default
transfer-pad-char of \x20 rather than \x00.

>
> > --- a/gcc/fortran/simplify.c
> > +++ b/gcc/fortran/simplify.c
> > @@ -7830,7 +7830,7 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr 
> > *mold, gfc_expr *size)
[...]
> This affects just the simplification when the argument is a known constant.
> Shouldn't we handle it also when it is not a constant?

Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
to affect non-constant resolution.

> The tests look too much big-endian vs. little-endian dependent and
> ascii dependent.  We have pdp-endian and doesn't s390x TPF use EBCDIC?
>
> Wouldn't it be better to compare transfer("ABCE", 1_8) with transfer("ABCE
> ", 1_8)

Agreed.

---
Fritz

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v5]

[Nick Clifton]

Hi Pedro,

> The issue pointed out by
> 
>  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02592.html
> 
> is still present in this version.

Doh!  Yes I meant to fix that one too, but forgot.

> Also, noticed a typo here:
> 
>> +/* If DMGL_NO_RECURE_LIMIT is not enabled, then this is the value used as
> 
> Typo: "RECURE"

Oops - thanks.

OK, revised (v5) patch attached.  Is this version acceptable to all ?

Cheers
  Nick

Index: include/demangle.h
===
--- include/demangle.h	(revision 266771)
+++ include/demangle.h	(working copy)
@@ -68,6 +68,17 @@
 /* If none of these are set, use 'current_demangling_style' as the default. */
 #define DMGL_STYLE_MASK (DMGL_AUTO|DMGL_GNU|DMGL_LUCID|DMGL_ARM|DMGL_HP|DMGL_EDG|DMGL_GNU_V3|DMGL_JAVA|DMGL_GNAT|DMGL_DLANG|DMGL_RUST)
 
+/* Disable a limit on the depth of recursion in mangled strings.
+   Note if this limit is disabled then stack exhaustion is possible when
+   demangling pathologically complicated strings.  Bug reports about stack
+   exhaustion when the option is enabled will be rejected.  */  
+#define DMGL_NO_RECURSE_LIMIT (1 << 18)	
+
+/* If DMGL_NO_RECURSE_LIMIT is not enabled, then this is the value used as
+   the maximum depth of recursion allowed.  It should be enough for any
+   real-world mangled name.  */
+#define DEMANGLE_RECURSION_LIMIT 1024
+  
 /* Enumeration of possible demangling styles.
 
Lucid and ARM styles are still kept logically distinct, even though
Index: libiberty/cp-demangle.c
===
--- libiberty/cp-demangle.c	(revision 266771)
+++ libiberty/cp-demangle.c	(working copy)
@@ -2852,21 +2852,35 @@
 static struct demangle_component *
 d_function_type (struct d_info *di)
 {
-  struct demangle_component *ret;
+  struct demangle_component *ret = NULL;
 
-  if (! d_check_char (di, 'F'))
-return NULL;
-  if (d_peek_char (di) == 'Y')
+  if ((di->options & DMGL_NO_RECURSE_LIMIT) == 0)
 {
-  /* Function has C linkage.  We don't print this information.
-	 FIXME: We should print it in verbose mode.  */
-  d_advance (di, 1);
+  if (di->recursion_level > DEMANGLE_RECURSION_LIMIT)
+	/* FIXME: There ought to be a way to report
+	   that the recursion limit has been reached.  */
+	return NULL;
+
+  di->recursion_level ++;
 }
-  ret = d_bare_function_type (di, 1);
-  ret = d_ref_qualifier (di, ret);
 
-  if (! d_check_char (di, 'E'))
-return NULL;
+  if (d_check_char (di, 'F'))
+{
+  if (d_peek_char (di) == 'Y')
+	{
+	  /* Function has C linkage.  We don't print this information.
+	 FIXME: We should print it in verbose mode.  */
+	  d_advance (di, 1);
+	}
+  ret = d_bare_function_type (di, 1);
+  ret = d_ref_qualifier (di, ret);
+  
+  if (! d_check_char (di, 'E'))
+	ret = NULL;
+}
+
+  if ((di->options & DMGL_NO_RECURSE_LIMIT) == 0)
+di->recursion_level --;
   return ret;
 }
 
@@ -6203,6 +6217,7 @@
   di->expansion = 0;
   di->is_expression = 0;
   di->is_conversion = 0;
+  di->recursion_level = 0;
 }
 
 /* Internal implementation for the demangler.  If MANGLED is a g++ v3 ABI
@@ -6242,6 +6257,20 @@
 
   cplus_demangle_init_info (mangled, options, strlen (mangled), );
 
+  /* PR 87675 - Check for a mangled string that is so long
+ that we do not have enough stack space to demangle it.  */
+  if (((options & DMGL_NO_RECURSE_LIMIT) == 0)
+  /* This check is a bit arbitrary, since what we really want to do is to
+	 compare the sizes of the di.comps and di.subs arrays against the
+	 amount of stack space remaining.  But there is no portable way to do
+	 this, so instead we use the recursion limit as a guide to the maximum
+	 size of the arrays.  */
+  && (unsigned long) di.num_comps > DEMANGLE_RECURSION_LIMIT)
+{
+  /* FIXME: We need a way to indicate that a stack limit has been reached.  */
+  return 0;
+}
+
   {
 #ifdef CP_DYNAMIC_ARRAYS
 __extension__ struct demangle_component comps[di.num_comps];
Index: libiberty/cp-demangle.h
===
--- libiberty/cp-demangle.h	(revision 266771)
+++ libiberty/cp-demangle.h	(working copy)
@@ -122,6 +122,9 @@
   /* Non-zero if we are parsing the type operand of a conversion
  operator, but not when in an expression.  */
   int is_conversion;
+  /* If DMGL_NO_RECURSE_LIMIT is not active then this is set to
+ the current recursion level.  */
+  unsigned int recursion_level;
 };
 
 /* To avoid running past the ending '\0', don't:
Index: libiberty/cplus-dem.c
===
--- libiberty/cplus-dem.c	(revision 266771)
+++ libiberty/cplus-dem.c	(working copy)
@@ -146,6 +146,7 @@
   int *proctypevec; /* Indices of currently processed remembered typevecs.  */
   int proctypevec_size;
   int nproctypes;
+  unsigned int recursion_level;
 };
 
 #define PRINT_ANSI_QUALIFIERS (work -> 

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

[Richard Sandiford]

Jeff Law  writes:
> On 11/20/18 7:57 AM, Renlin Li wrote:
>> Hi Richard,
>> 
>> On 11/14/2018 02:59 PM, Richard Biener wrote:
>>> On Fri, Nov 9, 2018 at 4:49 PM Renlin Li  wrote:

 Hi Richard,

 On 11/09/2018 11:48 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 at 5:55 PM Renlin Li  wrote:
>
>>
>> Hi Richard,
>>
>>
>>> I don't see the masked load here on x86_64 btw. (I don't see
>>> if-conversion generating a load).
>>> I guess that's again when store-data-races are allowed that it uses a
>>> RMW cycle and vectorization
>>> generating the masked variants for the loop-mask.  Which means for SVE
>>> if-conversion should
>>> prefer the masked-store variant even when store data races are allowed?
>> 
>> Yes, it looks like, for SVE, masked-store variant is preferred even when 
>> store data races are allowed.

I agree, and I think that would cope with more cases than fixing it up
later.  E.g. the current fixup code requires the load and store to have
the same vuse, so it won't cope with cases in which another store comes
between the mask_load and mask_store.

An easy heuristic would be to test
targetm.vectorize.empty_mask_is_expensive.  If that's false and masked
stores are available, it's probably better to use them than introduce
the data race.

Thanks,
Richard

Re: [doc PATCH] update attribute docs for C++

[Martin Sebor]

On 12/4/18 12:09 AM, Sandra Loosemore wrote:

On 12/3/18 4:23 PM, Martin Sebor wrote:


gcc/ChangeLog:

* doc/extend.texi (attribute const, pure): Clarify.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi    (revision 266766)
+++ gcc/doc/extend.texi    (working copy)
@@ -2276,12 +2276,13 @@ the enclosing block.
 @cindex @code{volatile} applied to function
 @cindex @code{const} applied to function

-In GNU C, you can use function attributes to declare certain things
-about functions called in your program which help the compiler
-optimize calls and check your code more carefully.  For example, you
+In GNU C and C++, you can use function attributes to declare certain
+function properties that may help the compiler optimize calls or
+check code more carefully for correctness.  For example, you
 can use attributes to declare that a function never returns
-(@code{noreturn}), returns a value depending only on its arguments
-(@code{pure}), or has @code{printf}-style arguments (@code{format}).
+(@code{noreturn}), returns a value depending only on the values of
+its arguments (@code{const}), or has @code{printf}-style arguments
+(@code{format}).

 You can also use attributes to control memory placement, code
 generation options or call/return conventions within the function
@@ -2288,12 +2289,15 @@ generation options or call/return conventions 
with

 being annotated.  Many of these attributes are target-specific.  For
 example, many targets support attributes for defining interrupt
 handler functions, which typically must follow special register usage
-and return conventions.
+and return conventions.  Such attributes are described in the subsection
+for each target.  However, a considerable number of attributes are
+supported by most, if not all targets.  Those are described in
+the @ref{Common Function Attributes} section.

 Function attributes are introduced by the @code{__attribute__} keyword
-on a declaration, followed by an attribute specification inside double
-parentheses.  You can specify multiple attributes in a declaration by
-separating them by commas within the double parentheses or by
+on a declaration, followed by an attribute specification enclosed in
+double parentheses.  You can specify multiple attributes in a 
declaration

+by separating them by commas within the double parentheses or by
 immediately following an attribute declaration with another attribute
 declaration.  @xref{Attribute Syntax}, for the exact rules on attribute
 syntax and placement.  Compatible attribute specifications on distinct
@@ -2301,6 +2305,15 @@ declarations of the same function are merged.  An
 that is not compatible with attributes already applied to a declaration
 of the same function is ignored with a warning.

+Unless specified otherwise, function attributes that apply to function
+parameters of pointer types also apply to the implicit C++ @code{this}
+argument in non-constant member functions, and to parameters of 
reference


I'm confused by this.  Function attributes apply to functions, not 
parameters.  Even if they did apply to parameters, why the restriction 
against constant member functions?


The non-constant a typo.  I meant to say non-static.

The part about parameters applies to attributes like nonnull that
attach to a function declaration but describe a property of
a positional parameter.  (Nonnull should make it clear that it's
implicit for the first parameter of non-static member functions,
and GCC should probably issue a warning when it's specified since
it's likely due to a mistake/misunderstanding.)




+type.  In attributes that refer to function parameters by their position
+in the argument list the first pararameter is at position one.  In C++


s/pararameter/parameter

Again, I'm confused.  Is this about the format attribute?  It would be 
far less obscure to just move this explanation to the discussion of that 
attribute, because nobody trying to understand how the format attribute 
works would be able to tie this discussion in another section into it.


Only a couple of attributes cover it: format and format_arg.
Alloc_align, alloc_size, nonnull, and sentinel don't.  (I haven't
done a review of target function attributes to see if there are
any like that.)  I wouldn't mind if the text were also duplicated
for each individual attribute, but because it's a general feature
of all such attributes I do think there needs to be a blanket
statement that stipulates this rule for all of them.

+non-static member functions position one refers to the implicit 
@code{this}

+pointer.  The same restrictions and effects apply to function attributes
+used with ordinary functions or C++ member functions.
+
 GCC also supports attributes on
 variable declarations (@pxref{Variable Attributes}),
 labels (@pxref{Label Attributes}),
@@ -6067,18 +6080,23 @@ when this attribute is present.
 @cindex attribute of variables
 @cindex variable 

Re: patch to fix PR88282

[Richard Sandiford]

Vladimir Makarov  writes:
>    The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88282
>
>    The patch was successfully bootstrapped and tested on 
> x86/x86-64/ppc64/aarch64.
>
>    Committed as rev. 266784.
>
> Index: ChangeLog
> ===
> --- ChangeLog (revision 266783)
> +++ ChangeLog (working copy)
> @@ -1,3 +1,9 @@
> +2018-12-04  Vladimir Makarov  
> +
> + PR target/88282
> + * ira-costs.c (exec): Try bigger class to use smaller register
> + move cost.
> +
>  2018-12-04  Michael Ploujnikov  
>  
>   PR ipa/88297
> Index: ira-costs.c
> ===
> --- ira-costs.c   (revision 266678)
> +++ ira-costs.c   (working copy)
> @@ -1314,28 +1314,50 @@ record_operand_costs (rtx_insn *insn, en
> machine_mode mode = GET_MODE (SET_SRC (set));
> cost_classes_t cost_classes_ptr = regno_cost_classes[regno];
> enum reg_class *cost_classes = cost_classes_ptr->classes;
> -   reg_class_t rclass, hard_reg_class, pref_class;
> +   reg_class_t rclass, hard_reg_class, pref_class, bigger_hard_reg_class;
> int cost, k;
> +   move_table *move_costs;
> bool dead_p = find_regno_note (insn, REG_DEAD, REGNO (src));
>  
> ira_init_register_move_cost_if_necessary (mode);
> +   move_costs = ira_register_move_cost[mode];
> hard_reg_class = REGNO_REG_CLASS (other_regno);
> +   bigger_hard_reg_class = ira_pressure_class_translate[hard_reg_class];
> +   if (bigger_hard_reg_class == NO_REGS
> +   && (other_regno == STACK_POINTER_REGNUM
> +#ifdef STATIC_CHAIN_REGNUM
> +   || other_regno == STATIC_CHAIN_REGNUM
> +#endif
> +   || other_regno == FRAME_POINTER_REGNUM
> +   || other_regno == HARD_FRAME_POINTER_REGNUM))
> + bigger_hard_reg_class = GENERAL_REGS;
> /* Target code may return any cost for mode which does not
>fit the the hard reg class (e.g. DImode for AREG on
>i386).  Check this and use a bigger class to get the
>right cost.  */
> if (! ira_hard_reg_in_set_p (other_regno, mode,
>  reg_class_contents[hard_reg_class]))
> - hard_reg_class = ira_pressure_class_translate[hard_reg_class];
> + hard_reg_class = bigger_hard_reg_class;
> i = regno == (int) REGNO (src) ? 1 : 0;
> for (k = cost_classes_ptr->num - 1; k >= 0; k--)
>   {
> rclass = cost_classes[k];
> -   cost = ((i == 0
> -? ira_register_move_cost[mode][hard_reg_class][rclass]
> -: ira_register_move_cost[mode][rclass][hard_reg_class])
> -   * frequency);
> -   op_costs[i]->cost[k] = cost;
> +   cost = (i == 0
> +   ? move_costs[hard_reg_class][rclass]
> +   : move_costs[rclass][hard_reg_class]);
> +   /* Target code might define wrong big costs for smaller
> +  reg classes or reg classes containing only fixed hard
> +  regs.  Try a bigger class.  */
> +   if (bigger_hard_reg_class != hard_reg_class)
> + {
> +   int cost2 = (i == 0
> +? move_costs[bigger_hard_reg_class][rclass]
> +: move_costs[rclass][bigger_hard_reg_class]);
> +   if (cost2 < cost)
> + cost = cost2;
> + }
> +   
> +   op_costs[i]->cost[k] = cost * frequency;
> /* If we have assigned a class to this allocno in our
>first pass, add a cost to this alternative
>corresponding to what we would add if this allocno

This seems like a hack to me.  I don't see any reason why
FRAME_POINTER_REGNUM etc. have to be in GENERAL_REGS, so picking
that seems arbitrary.  And is there a reason not to include
ARG_POINTER_REGNUM or PIC_OFFSET_TABLE_REGNUM?

It sounds from the comments in the PR that the backend isn't defining
its costs correctly.  If so, what specifically does it get wrong?
I think it would be better to fix the backends than accumulate more
workarounds like this.

Thanks,
Richard

[PATCH, rs6000] Port cleanup patch, use rtl.h convenience macros, etc.

[Peter Bergner]

Hi Segher,

We talked about replacing rs6000'c regno_or_subregno() with the generic
reg_or_subregno() function from jump.c.  I agree the geberic version is
better because it has an assert that ensures we have a REG.  There were
also a couple of places that could use reg_or_subregno() where we weren't.
I made those changes and tested it and ran into no regressions.

Nearby the changes above, there were cases where could could have been using
the rtl convenience macros like REG_P, etc. to simplify the code so I did
that too...and kept going and just ended up converting all the cases I could
find that should have been using them, to use them.  So the patch is large,
but pretty straight forward.

The passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for mainline?

Peter

* config/rs6000/altivec.md (build_vector_mask_for_load): Use MEM_P.
* config/rs6000/constraints.md (Q constraint): Use REG_P.
* config/rs6000/darwin.h (PREFERRED_RELOAD_CLASS): Use SYMBOL_REF_P.
* config/rs6000/freebsd64.h (ASM_OUTPUT_SPECIAL_POOL_ENTRY_P): Use
SYMBOL_REF_P, CONST_INT_P and CONST_DOUBLE_P.
* config/rs6000/linux64.h (ASM_OUTPUT_SPECIAL_POOL_ENTRY_P): Likewise.
* config/rs6000/predicates.md (altivec_register_operand, vint_operand,
vsx_register_operand, vsx_reg_sfsubreg_ok, vfloat_operand,
vlogical_operand, gpc_reg_operand, int_reg_operand,
int_reg_operand_not_pseudo): Use SUBREG_P and HARD_REGISTER_P.
(ca_operand, base_reg_operand, htm_spr_reg_operand, cc_reg_operand,
cc_reg_not_cr0_operand, input_operand): Use SUBREG_P.
(save_world_operation, restore_world_operation, lmw_operation,
stmw_operation): Use MEM_P and REG_P.
(tie_operand): Use MEM_P.
(vrsave_operation, crsave_operation): Use REG_P.
(mfcr_operation, mtcrf_operation): Use REG_P and CONST_INT_P.
(fpr_reg_operand): Use SUBREG_P and HARD_REGISTER_NUM_P.
(quad_int_reg_operand): Use HARD_REGISTER_NUM_P.
(call_operand): Use HARD_REGISTER_P.
(indexed_or_indirect_operand, altivec_indexed_or_indirect_operand):
Use CONST_INT_P.
(lwa_operand): Use SUBREG_P, REG_P and CONST_INT_P.
* config/rs6000/rs6000-p8swap.c (insn_is_load_p, insn_is_store_p,
quad_aligned_load_p, replace_swapped_aligned_store,
recombine_lvx_pattern, replace_swapped_aligned_load,
recombine_stvx_pattern): Use MEM_P.
(const_load_sequence_p, adjust_vperm, replace_swapped_load_constant):
Use MEM_P and SYMBOL_REF_P.
(rtx_is_swappable_p): Use REG_P and CONST_INT_P.
(insn_is_swappable_p): Use REG_P and MEM_P.
(insn_is_swap_p, (alignment_mask): Use CONST_INT_P.
* config/rs6000/rs6000-string.c (expand_block_clear, expand_block_move):
Use CONST_INT_P.
* config/rs6000/rs6000.c (rs6000_secondary_reload, rs6000_emit_cmove,
rs6000_legitimate_constant_p): Use CONST_DOUBLE_P.
(rs6000_output_move_128bit): Use CONST_DOUBLE_P, CONST_INT_P and
CONST_WIDE_INT_P.
(rs6000_legitimize_address): Use CONST_DOUBLE_P, CONST_INT_P,
CONST_WIDE_INT_P, REG_P and SYMBOL_REF_P.
(rs6000_emit_move): Use CONST_DOUBLE_P, CONST_INT_P, HARD_REGISTER_P,
HARD_REGISTER_NUM_P, MEM_P, REG_P, SUBREG_P, SYMBOL_REF_P and
reg_or_subregno:
(output_toc): Use CONST_DOUBLE_P, CONST_INT_P and SYMBOL_REF_P.
(easy_altivec_constant, rs6000_legitimate_offset_address_p,
rs6000_mode_dependent_address, rs6000_expand_mtfsf_builtin,
rs6000_expand_set_fpscr_rn_builtin, rs6000_expand_set_fpscr_drn_builtin,
rs6000_expand_unop_builtin, INT_P, rs6000_generate_compare,
rs6000_machopic_legitimize_pic_address, rs6000_split_logical_inner,
rs6000_split_logical_di): Use CONST_INT_P.
(rs6000_legitimize_reload_address): Use CONST_INT_P, HARD_REGISTER_P,
REG_P and SYMBOL_REF_P.
(setup_incoming_varargs, rs6000_rtx_costs): Use CONST_INT_P and MEM_P.
(print_operand): Use CONST_INT_P, MEM_P and REG_P.
(virtual_stack_registers_memory_p, rs6000_legitimate_address_p,
mems_ok_for_quad_peep): Use CONST_INT_P and REG_P.
(rs6000_secondary_reload_memory): Use CONST_INT_P and SUBREG_P.
(small_data_operand, print_operand_address): Use CONST_INT_P and
SYMBOL_REF_P.
(split_stack_arg_pointer_used_p): Use HARD_REGISTER_P.
(rs6000_init_hard_regno_mode_ok, direct_move_p): Use 
HARD_REGISTER_NUM_P.
(rs6000_secondary_reload_gpr): Use HARD_REGISTER_NUM_P and MEM_P.
(rs6000_secondary_reload_class): Use HARD_REGISTER_NUM_P, REG_P,
SUBREG_P and SYMBOL_REF_P.
(register_to_reg_type, rs6000_secondary_reload_inner): Use SUBREG_P
and HARD_REGISTER_NUM_P.
(rs6000_adjust_vec_address): Use HARD_REGISTER_NUM_P and
reg_or_subregno.
(rs6000_adjust_cost, 

Reduce memory usage of ipa-cp streaming

[Jan Hubicka]

Hi,
this patch reduces memory usage of WPA for current firefox LTO+FDO build
from 10GB to 8.5GB by not allocating vector for jump functions annotating
calls to libgcov runtime.

Comparing -Q report before and after patch I get:

Time variable   usr   sys  wall 
  GGC
 phase opt and generate : 190.66 ( 62%)   1.15 (  1%) 194.94 ( 46%) 
1038947 kB (  9%)
 phase stream in: 100.59 ( 33%)   8.85 ( 10%) 109.87 ( 
26%)10838189 kB ( 91%)
 phase stream out   :   1.44 (  0%)  75.28 ( 87%) 106.10 ( 25%) 
  1 kB (  0%)
 phase finalize :  13.41 (  4%)   1.42 (  2%)  14.95 (  4%) 
  0 kB (  0%)
 garbage collection :  23.40 (  8%)   0.10 (  0%)  23.63 (  6%) 
  0 kB (  0%)
 callgraph optimization :  48.66 ( 16%)   0.09 (  0%)  50.02 ( 12%) 
   1073 kB (  0%)
 ipa function summary   :   3.02 (  1%)   0.82 (  1%)   3.94 (  1%) 
 387933 kB (  3%)
 ipa dead code removal  :  18.12 (  6%)   0.13 (  0%)  18.37 (  4%) 
  0 kB (  0%)
 ipa devirtualization   :   0.52 (  0%)   0.00 (  0%)   0.52 (  0%) 
  0 kB (  0%)
 ipa cp :  23.84 (  8%)   2.21 (  3%)  26.15 (  6%) 
3645794 kB ( 31%)
 ipa inlining heuristics:  60.39 ( 20%)   0.38 (  0%)  61.00 ( 14%) 
 872904 kB (  7%)
 ipa comdats:   0.80 (  0%)   0.00 (  0%)   0.80 (  0%) 
  0 kB (  0%)
 lto stream inflate :  14.09 (  5%)   0.83 (  1%)  14.90 (  3%) 
  0 kB (  0%)
 ipa lto gimple in  :   0.45 (  0%)   0.09 (  0%)   0.51 (  0%) 
  42421 kB (  0%)
 ipa lto gimple out :   0.25 (  0%)   0.24 (  0%)   0.81 (  0%) 
  1 kB (  0%)
 ipa lto decl in:  36.78 ( 12%)   3.01 (  3%)  39.53 (  9%) 
3900047 kB ( 33%)
 ipa lto decl out   :   0.75 (  0%)   0.09 (  0%)   0.88 (  0%) 
  0 kB (  0%)
 ipa lto constructors in:   0.16 (  0%)   0.03 (  0%)   0.14 (  0%) 
   1820 kB (  0%)
 ipa lto constructors out   :   0.29 (  0%)   0.13 (  0%)   0.66 (  0%) 
  0 kB (  0%)
 ipa lto cgraph I/O :   4.80 (  2%)   1.09 (  1%)   6.09 (  1%) 
2739424 kB ( 23%)
 ipa lto decl merge :   7.73 (  3%)   0.03 (  0%)   8.18 (  2%) 
  69395 kB (  1%)
 ipa lto cgraph merge   :   3.91 (  1%)   0.02 (  0%)   3.99 (  1%) 
 129651 kB (  1%)
 whopr wpa  :   0.34 (  0%)   0.00 (  0%)   0.33 (  0%) 
 79 kB (  0%)
 whopr wpa I/O  :   0.15 (  0%)  74.80 ( 86%) 103.71 ( 24%) 
  0 kB (  0%)
 whopr partitioning :  26.75 (  9%)   0.14 (  0%)  28.04 (  7%) 
  73797 kB (  1%)
 ipa reference  :   3.51 (  1%)   0.01 (  0%)   3.64 (  1%) 
  0 kB (  0%)
 ipa profile:   1.86 (  1%)   0.01 (  0%)   1.86 (  0%) 
  0 kB (  0%)
 ipa pure const :   6.89 (  2%)   0.05 (  0%)   7.04 (  2%) 
  0 kB (  0%)
 ipa icf:  16.97 (  6%)   0.50 (  1%)  17.62 (  4%) 
 49 kB (  0%)
 inline parameters  :   0.01 (  0%)   0.01 (  0%)   0.03 (  0%) 
269 kB (  0%)
 tree PTA   :   0.02 (  0%)   0.00 (  0%)   0.00 (  0%) 
  0 kB (  0%)
 tree SSA rewrite   :   0.02 (  0%)   0.00 (  0%)   0.05 (  0%) 
   4479 kB (  0%)
 tree SSA other :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%) 
  0 kB (  0%)
 tree SSA incremental   :   0.08 (  0%)   0.01 (  0%)   0.10 (  0%) 
572 kB (  0%)
 tree operand scan  :   0.03 (  0%)   0.00 (  0%)   0.01 (  0%) 
   6655 kB (  0%)
 dominance frontiers:   0.01 (  0%)   0.00 (  0%)   0.00 (  0%) 
  0 kB (  0%)
 dominance computation  :   0.05 (  0%)   0.00 (  0%)   0.02 (  0%) 
  0 kB (  0%)
 varconst   :   0.66 (  0%)   0.41 (  0%)   1.00 (  0%) 
  0 kB (  0%)
 branch prediction  :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%) 
  0 kB (  0%)
 TOTAL  : 306.10 86.70425.87   
11879212 kB

Time variable   usr   sys  wall 
  GGC
 phase setup:   0.01 (  0%)   0.00 (  0%)   0.01 (  0%) 
   2072 kB (  0%)
 phase opt and generate : 155.97 ( 59%)   1.09 (  2%) 176.62 ( 31%) 
 756872 kB (  7%)
 phase stream in: 105.51 ( 40%)   8.76 ( 15%) 163.22 ( 28%) 
9382008 kB ( 93%)
 phase stream out   :   1.09 (  0%)  48.71 ( 83%) 238.88 ( 41%) 
  0 kB (  0%)
 garbage collection :   9.22 (  4%)   0.00 (  0%)   9.23 (  2%) 
  0 kB (  0%)
 callgraph construction :   0.01 (  0%)   0.00 (  0%)   0.02 (  0%) 
  0 kB (  0%)
 callgraph optimization 

Re: [patch] various OpenACC reduction enhancements - ME and nvptx changes

[Tom de Vries]

On 04-12-18 13:29, Jakub Jelinek wrote:
> On Fri, Jun 29, 2018 at 11:19:53AM -0700, Cesar Philippidis wrote:
>> The attached patch includes the nvptx and GCC ME reductions enhancements.
>>
>> Is this patch OK for trunk? It bootstrapped / regression tested cleanly
>> for x86_64 with nvptx offloading.
> This is all OpenACC specific code not really shareable with OpenMP, if
> Thomas (for middle-end) and Tom (for NVPTX backend) are ok with it, it is ok
> for trunk.
> 

Formatting needs to be fixed:
...
There should be exactly one space between function name and parenthesis.
160:+  unsigned old_shift = DIM_SIZE(VECTOR);
...

Also, the updated patch does not address my comment about probabilities
here ( https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00325.html ):
...
> +  /* Create the loop.  */
> +  post_edge->flags ^= EDGE_TRUE_VALUE | EDGE_FALLTHRU;

Edges need probabilities, as in nvptx_lockless_update,
nvptx_lockfull_update and nvptx_goacc_reduction_init.
...

Thanks,
- Tom

[committed, testsuite] Fix PR88310.

[Iain Sandoe]

Hi,

A new warning was added in 264657 that fires if the profile count data file is 
missing when -fprofile-use is enabled;  this was causing the test for profile + 
reorder support to fail in the target supports.

Applied the following as obvious.

Iain

Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 266784)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2018-12-04  Iain Sandoe  
+
+   PR testsuite/88310
+   * lib/target-supports.exp (check_effective_target_freorder):
+   Suppress warnings for missing profile.
+
 2018-12-04  Jakub Jelinek  
 
* g++.old-deja/g++.oliva/typename1.C: Don't expect any diagnostics
Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 266784)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -1094,7 +1094,7 @@
 } "-freorder-blocks-and-partition"]
 && [check_no_compiler_messages fprofile_use_freorder object {
void foo (void) { }
-} "-fprofile-use -freorder-blocks-and-partition"] } {
+} "-fprofile-use -freorder-blocks-and-partition -Wno-missing-profile"] } {
return 1
 }
 return 0

Re: [PATCH] Further rs6000 asm modifier tweaks (PR target/88188)

[Segher Boessenkool]

Hi Jakub,

On Tue, Dec 04, 2018 at 09:56:45AM +0100, Jakub Jelinek wrote:
> This patch adds further tweaks discussed in the last PR88188 mail.

Thanks for doing this :-)

> ccr_bit now returns -1 instead of failing assertions, so that the caller
> can decide what to do with it (fail assertion or output_operand_lossage
> with some reasonable diagnostics.

(And all callers already test for that).

> For D and t it now requires CR_REGNO_P, so that it doesn't print completely
> meaningless numbers if used with other registers.
> And use REG_P macros a little bit.


> 2018-12-04  Jakub Jelinek  
> 
>   PR target/88188
>   * config/rs6000/rs6000.c (ccr_bit): Return -1 instead of assertion
>   failures.
>   (print_operand): Use REG_P instead of GET_CODE == REG.
>   : Also check CR_REGNO_P (REGNO (x)).
>   * config/rs6000/rs6000.md (scc patterns): Assert ccr_bit didn't
>   return -1.
> 
>   * gcc.target/powerpc/pr88188-2.c: New test.

> @@ -20754,7 +20765,7 @@ print_operand (FILE *file, rtx x, int co
>  
>  case 'D':
>/* Like 'J' but get to the GT bit only.  */
> -  if (!REG_P (x))
> +  if (! REG_P (x) || ! CR_REGNO_P (REGNO (x)))

No space after ! please.  I know surrounding code does it, but how will
we ever get rid of that otherwise :-)

> @@ -21014,7 +21025,7 @@ print_operand (FILE *file, rtx x, int co
>  
>  case 't':
>/* Like 'J' but get to the OVERFLOW/UNORDERED bit.  */
> -  if (!REG_P (x) || GET_MODE (x) != CCmode)
> +  if (! REG_P (x) || GET_MODE (x) != CCmode || ! CR_REGNO_P (REGNO (x)))

Strange that this one uses GET_MODE, all the rest do not.  Since you add
the CR_REGNO test now, the mode test is obviously superfluous, so you
can delete it?

Okay for trunk, with or without those extra tweaks.  Thanks!


Segher

Re: [PATCH 2/2] asm inline

[Richard Sandiford]

Segher Boessenkool  writes:
> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index 81c520a..9b572d7 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -10315,7 +10315,7 @@ build_asm_stmt (tree cv_qualifier, tree args)
> are subtly different.  We use a ASM_EXPR node to represent this.  */
>  tree
>  build_asm_expr (location_t loc, tree string, tree outputs, tree inputs,
> - tree clobbers, tree labels, bool simple)
> + tree clobbers, tree labels, bool simple, bool is_inline)
>  {
>tree tail;
>tree args;

Function comment doesn't document the new parameter.

> diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
> index 733c42f..87d54b1 100644
> --- a/gcc/cp/semantics.c
> +++ b/gcc/cp/semantics.c
> @@ -1486,7 +1486,7 @@ finish_compound_stmt (tree stmt)
>  
>  tree
>  finish_asm_stmt (int volatile_p, tree string, tree output_operands,
> -  tree input_operands, tree clobbers, tree labels)
> +  tree input_operands, tree clobbers, tree labels, bool inline_p)
>  {
>tree r;
>tree t;

Same here.

> @@ -19608,6 +19610,17 @@ cp_parser_asm_definition (cp_parser* parser)
> else
>   done = true;
> break;
> + case RID_INLINE:
> +   if (!inline_p && parser->in_function_body)
> + {
> +   /* Remember that we saw the `inline' keyword.  */
> +   inline_p = true;
> +   /* Consume the token.  */
> +   cp_lexer_consume_token (parser->lexer);
> + }
> +   else
> + done = true;
> +   break;
>   case RID_GOTO:
> if (!goto_p && parser->in_function_body)
>   {

Hmm, so we allow top-level "asm volatile" in C++ but not C?

Probably worth having tests to show that we (intentionally) don't
allow top-level "asm inline".

> @@ -1640,6 +1640,7 @@ finish_asm_stmt (int volatile_p, tree string, tree 
> output_operands,
> output_operands, input_operands,
> clobbers, labels);
>ASM_VOLATILE_P (r) = volatile_p || noutputs == 0;
> +  ASM_INLINE_P (r) = inline_p;
>r = maybe_cleanup_point_expr_void (r);
>return add_stmt (r);
>  }
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 2791f25..cebbfc7 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -8382,6 +8382,10 @@ various @option{-std} options, use @code{__asm__} 
> instead of
>  @item volatile
>  The optional @code{volatile} qualifier has no effect. 
>  All basic @code{asm} blocks are implicitly volatile.
> +
> +@item inline
> +If you use the @code{inline} qualifier, then for inlining purposes the size
> +of the asm is taken as the smallest size possible (@pxref{Size of an asm}).
>  @end table
>  
>  @subsubheading Parameters

You need to update the syntax above too, which currently reads:

@example
asm @r{[} volatile @r{]} ( @var{AssemblerInstructions} )
@end example

Same for the equivalent extended asm docs.

> @@ -3932,6 +3933,27 @@ gimple_asm_set_volatile (gasm *asm_stmt, bool 
> volatile_p)
>  }
>  
>  
> +/* Return true ASM_STMT ASM_STMT is an asm statement marked inline.  */
> +
> +static inline bool
> +gimple_asm_inline_p (const gasm *asm_stmt)
> +{
> +  return (asm_stmt->subcode & GF_ASM_INLINE) != 0;
> +}

Return true if ASM_STMT is ...

(Or "Return true if asm statement ASM_STMT is marked inline", since gasm
forces it to be an asm statement.)

> diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
> index 5aa782b..7e9ed99 100644
> --- a/gcc/tree-inline.c
> +++ b/gcc/tree-inline.c
> @@ -4109,6 +4109,9 @@ estimate_num_insns (gimple *stmt, eni_weights *weights)
>  with very long asm statements.  */
>   if (count > 1000)
> count = 1000;
> + /* If this asm is asm inline, count anything as minimum size.  */
> + if (gimple_asm_inline_p (as_a  (stmt)))
> +   count = !!count;

FWIW, since Marc found it confusing too... I think MIN (count, 1) would
show the intent more clearerly.  But that's just personal preference,
no need to change.

OK with those changes, thanks.

Richard

Re: [PING] Re: [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486)

[David Malcolm]

On Mon, 2018-12-03 at 15:10 -0700, Jeff Law wrote:
> On 11/19/18 9:51 AM, David Malcolm wrote:
> > Ping, for these patches:
> > 
> > [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR
> > c++/43486)
> >   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00304.html
> > 
> > [PATCH 2/2] C++: improvements to binary operator diagnostics (PR
> > c++/87504)
> >   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00303.html
> > 
> > 
> > Thanks
> > Dave
> > 
> > > 
> > > [1] I've split them up for ease of review; they could be reworked
> > > to
> > > be
> > > fully independent, but there's some churn in the results for
> > > -Wtautological-compare introduced by the 1st patch which the 2nd
> > > patch addresses.
> > > 
> > > gcc/ChangeLog:
> > >   PR c++/43064
> > >   PR c++/43486
> > >   * convert.c: Include "selftest.h".
> > >   (preserve_any_location_wrapper): New function.
> > >   (convert_to_pointer_maybe_fold): Update to handle location
> > >   wrappers.
> > >   (convert_to_real_maybe_fold): Likewise.
> > >   (convert_to_integer_1): Handle location wrappers when checking
> > > for
> > >   INTEGER_CST.
> > >   (convert_to_integer_maybe_fold): Update to handle location
> > >   wrappers.
> > >   (convert_to_complex_maybe_fold): Likewise.
> > >   (selftest::test_convert_to_integer_maybe_fold): New functions.
> > >   (selftest::convert_c_tests): New function.
> > >   * fold-const.c (operand_equal_p): Strip any location wrappers.
> > >   * selftest-run-tests.c (selftest::run_tests): Call
> > >   selftest::convert_c_tests.
> > >   * selftest.h (selftest::convert_c_tests): New decl.
> > >   * tree.c (tree_int_cst_equal): Strip any location wrappers.
> > >   (maybe_wrap_with_location): Don't create wrappers if any
> > >   auto_suppress_location_wrappers are active.
> > >   (suppress_location_wrappers): New variable.
> > >   * tree.h (CONSTANT_CLASS_OR_WRAPPER_P): New macro.
> > >   (suppress_location_wrappers): New decl.
> > >   (class auto_suppress_location_wrappers): New class.
> > > 
> > > gcc/c-family/ChangeLog:
> > >   PR c++/43064
> > >   PR c++/43486
> > >   * c-common.c (unsafe_conversion_p): Strip any location wrapper.
> > >   (verify_tree): Handle location wrappers.
> > >   (c_common_truthvalue_conversion): Strip any location wrapper.
> > >   Handle CONST_DECL.
> > >   (fold_offsetof): Strip any location wrapper.
> > >   (complete_array_type): Likewise for initial_value.
> > >   (convert_vector_to_array_for_subscript): Call fold_for_warn on
> > > the
> > >   index before checking for INTEGER_CST.
> > >   * c-pretty-print.c (c_pretty_printer::primary_expression):
> > > Don't
> > >   print parentheses around location wrappers.
> > >   * c-warn.c (warn_logical_operator): Call fold_for_warn on
> > > op_right
> > >   before checking for INTEGER_CST.
> > >   (warn_tautological_bitwise_comparison): Call
> > >   tree_strip_any_location_wrapper on lhs, rhs, and bitop's
> > > operand
> > >   before checking for INTEGER_CST.
> > >   (readonly_error): Strip any location wrapper.
> > >   (warn_array_subscript_with_type_char): Strip location wrappers
> > >   before checking for INTEGER_CST.  Use the location of the index
> > > if
> > >   available.
> > > 
> > > gcc/cp/ChangeLog:
> > >   PR c++/43064
> > >   PR c++/43486
> > >   * call.c (build_conditional_expr_1): Strip location wrappers
> > > when
> > >   checking for CONST_DECL.
> > >   (conversion_null_warnings): Use location of "expr" if
> > > available.
> > >   * class.c (fixed_type_or_null): Handle location wrappers.
> > >   * constexpr.c (potential_constant_expression_1): Likewise.
> > >   * cvt.c (ignore_overflows): Strip location wrappers when
> > >   checking for INTEGER_CST, and re-wrap the result if present.
> > >   (ocp_convert): Call fold_for_warn before checking for
> > > INTEGER_CST.
> > >   * decl.c (reshape_init_r): Strip any location wrapper.
> > >   (undeduced_auto_decl): Likewise.
> > >   * decl2.c (grokbitfield): Likewise for width.
> > >   * expr.c (mark_discarded_use): Likewise for expr.
> > >   * init.c (build_aggr_init): Likewise before checking init for
> > >   DECL_P.
> > >   (warn_placement_new_too_small): Call fold_for_warn on adj
> > > before
> > >   checking for CONSTANT_CLASS_P, and on nelts.  Strip any
> > > location
> > >   wrapper from op0 and on oper before checking for VAR_P.
> > >   * lambda.c (add_capture): Strip any location from initializer.
> > >   * name-lookup.c (handle_namespace_attrs): Strip any location
> > > from
> > >   x before checking for STRING_CST.
> > >   * parser.c (cp_parser_primary_expression): Call
> > >   maybe_add_location_wrapper on numeric and string literals.
> > >   (cp_parser_postfix_expression): Strip any location wrapper when
> > >   checking for DECL_IS_BUILTIN_CONSTANT_P.
> > >   (cp_parser_binary_expression): Strip any location wrapper when
> > >   checking for DECL_P on the lhs.
> > >   (cp_parser_decltype_expr): Suppress location wrappers in the
> > >   id-expression.
> > >   

Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

[Jakub Jelinek]

On Tue, Dec 04, 2018 at 02:47:25PM +, Mark Eggleston wrote:
> Here is a patch to considered for incorporation into gfortran adding to its
> legacy support. It pads character to integer conversions using spaces
> instead of zeros when enabled.
> 
> The pad character is 'undefined' or 'processor dependent' depending on which
> standard you read. This makes it 0x20 which matches the Oracle Fortran
> compiler.

Trying fortran.godbolt.org, I think ifort pads this with spaces too.

> Enabled using -fdec-pad-with-spaces and -fdec.

Just a couple of random comments.
-fdec-pad-with-spaces option name doesn't look right, because it doesn't say
what the option affects.  So perhaps have transfer in the option name?
Wouldn't it be better to allow specifying whatever character you want to pad
with, so that users can choose something even different?

> --- a/gcc/fortran/simplify.c
> +++ b/gcc/fortran/simplify.c
> @@ -7830,7 +7830,7 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr 
> *mold, gfc_expr *size)
>/* Allocate the buffer to store the binary version of the source.  */
>buffer_size = MAX (source_size, result_size);
>buffer = (unsigned char*)alloca (buffer_size);
> -  memset (buffer, 0, buffer_size);
> +  memset (buffer, (flag_dec_pad_with_spaces ? 0x20 : 0x0), buffer_size);

This affects just the simplification when the argument is a known constant.
Shouldn't we handle it also when it is not a constant?  Like I've tried:
program test
  integer(kind=8) :: a, b, c
  character(len=4) :: e
  a = transfer("ABCE", 1_8)
  e = "ABCE"
  b = transfer(e, 1_8)
  c = transfer("ABCE", 1_8)
  print *, a, b, c
end
and for a the result is on little-endian indeed z'45434241', for b
the upper 32 bits are completely random:
D.3854 = 4;
D.3856 = 8;
_1 = MIN_EXPR ;
_2 = MAX_EXPR <_1, 0>;
_3 = (unsigned long) _2;
__builtin_memcpy (, , _3);
transfer.3_4 = transfer.0;
b = transfer.3_4;
and for c it is the padding with zeros I assume you want for -fdec.
So, what does Oracle fortran or ifort do for this b case above?

> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-1.f90
> @@ -0,0 +1,17 @@
> +! { dg-do run }
> +! { dg-options "-fdec-pad-with-spaces" }
> +!
> +! Test case contributed by Mark Eggleston 
> +
> +program test
> +  integer(kind=8) :: a
> +  a = transfer("ABCE", 1_8)
> +  ! If a has not been converted into big endian
> +  ! or little endian integer it has failed.
> +  if ((a.ne.int(z'4142434520202020',kind=8)).and. &
> +  (a.ne.int(z'2020202045434241',kind=8))) then 

The tests look too much big-endian vs. little-endian dependent and
ascii dependent.  We have pdp-endian and doesn't s390x TPF use EBCDIC?

Wouldn't it be better to compare transfer("ABCE", 1_8) with transfer("ABCE
", 1_8)
?

Jakub

patch to fix PR88282

[Vladimir Makarov]

  The following patch fixes

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

  The patch was successfully bootstrapped and tested on 
x86/x86-64/ppc64/aarch64.


  Committed as rev. 266784.

Index: ChangeLog
===
--- ChangeLog	(revision 266783)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2018-12-04  Vladimir Makarov  
+
+	PR target/88282
+	* ira-costs.c (exec): Try bigger class to use smaller register
+	move cost.
+
 2018-12-04  Michael Ploujnikov  
 
 	PR ipa/88297
Index: ira-costs.c
===
--- ira-costs.c	(revision 266678)
+++ ira-costs.c	(working copy)
@@ -1314,28 +1314,50 @@ record_operand_costs (rtx_insn *insn, en
 	  machine_mode mode = GET_MODE (SET_SRC (set));
 	  cost_classes_t cost_classes_ptr = regno_cost_classes[regno];
 	  enum reg_class *cost_classes = cost_classes_ptr->classes;
-	  reg_class_t rclass, hard_reg_class, pref_class;
+	  reg_class_t rclass, hard_reg_class, pref_class, bigger_hard_reg_class;
 	  int cost, k;
+	  move_table *move_costs;
 	  bool dead_p = find_regno_note (insn, REG_DEAD, REGNO (src));
 
 	  ira_init_register_move_cost_if_necessary (mode);
+	  move_costs = ira_register_move_cost[mode];
 	  hard_reg_class = REGNO_REG_CLASS (other_regno);
+	  bigger_hard_reg_class = ira_pressure_class_translate[hard_reg_class];
+	  if (bigger_hard_reg_class == NO_REGS
+	  && (other_regno == STACK_POINTER_REGNUM
+#ifdef STATIC_CHAIN_REGNUM
+		  || other_regno == STATIC_CHAIN_REGNUM
+#endif
+		  || other_regno == FRAME_POINTER_REGNUM
+		  || other_regno == HARD_FRAME_POINTER_REGNUM))
+	bigger_hard_reg_class = GENERAL_REGS;
 	  /* Target code may return any cost for mode which does not
 	 fit the the hard reg class (e.g. DImode for AREG on
 	 i386).  Check this and use a bigger class to get the
 	 right cost.  */
 	  if (! ira_hard_reg_in_set_p (other_regno, mode,
    reg_class_contents[hard_reg_class]))
-	hard_reg_class = ira_pressure_class_translate[hard_reg_class];
+	hard_reg_class = bigger_hard_reg_class;
 	  i = regno == (int) REGNO (src) ? 1 : 0;
 	  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
 	{
 	  rclass = cost_classes[k];
-	  cost = ((i == 0
-		   ? ira_register_move_cost[mode][hard_reg_class][rclass]
-		   : ira_register_move_cost[mode][rclass][hard_reg_class])
-		  * frequency);
-	  op_costs[i]->cost[k] = cost;
+	  cost = (i == 0
+		  ? move_costs[hard_reg_class][rclass]
+		  : move_costs[rclass][hard_reg_class]);
+	  /* Target code might define wrong big costs for smaller
+		 reg classes or reg classes containing only fixed hard
+		 regs.  Try a bigger class.  */
+	  if (bigger_hard_reg_class != hard_reg_class)
+		{
+		  int cost2 = (i == 0
+			   ? move_costs[bigger_hard_reg_class][rclass]
+			   : move_costs[rclass][bigger_hard_reg_class]);
+		  if (cost2 < cost)
+		cost = cost2;
+		}
+	  
+	  op_costs[i]->cost[k] = cost * frequency;
 	  /* If we have assigned a class to this allocno in our
 		 first pass, add a cost to this alternative
 		 corresponding to what we would add if this allocno
@@ -1350,7 +1372,7 @@ record_operand_costs (rtx_insn *insn, en
 		  else if (ira_reg_class_intersect[pref_class][rclass]
 			   == NO_REGS)
 		op_costs[i]->cost[k]
-		  += (ira_register_move_cost[mode][pref_class][rclass]
+		  += (move_costs[pref_class][rclass]
 			  * frequency);
 		}
 	  /* If this insn is a single set copying operand 1 to

Re: [doc, rfc] document __builtin_setjmp and __builtin_longjmp

[Richard Sandiford]

Sandra Loosemore  writes:
> I have written a new patch for PR 59039 to address more of the comments 
> there, as well as my own complaints about the draft patch attached to 
> the issue.  I'd like to get some feedback on this one before I commit it.

It's a long time since I've worked with these builtins and I'd need
to look at the code to remember how they work.  Reading this without
doing that...

> +@node Nonlocal Gotos
> +@section Nonlocal Gotos
> +@cindex nonlocal gotos

This could be confusing, since GCC supports a "true" form of non-local
goto from nested functions to containing functions, using the "goto"
keyword.

> +GCC provides the built-in functions @code{__builtin_setjmp} and
> +@code{__builtin_longjmp} which are similar to, but not interchangeable
> +with, the C library functions @code{setjmp} and @code{longjmp}.  
> +The built-in versions are used internally by GCC's libraries
> +to implement exception handling on some targets.  You should use the 
> +standard C library functions declared in @code{} in user code
> +instead of the builtins.
> +
> +@code{__builtin_setjmp} and @code{__builtin_longjmp} use GCC's normal
> +mechanisms to save and restore registers using the stack on function
> +entry and exit.  The jump buffer argument @var{buf} holds only the
> +information needed to restore the stack frame, rather than the entire 
> +set of saved register values.  

I wasn't sure from this whether __builtin_longjmp did actually restore
the values of registers or not.  Saying that the jump buffer only
stores the frame information implied not, but...

> +An important caveat is that GCC arranges to save and restore only
> +those registers known to the specific architecture variant being
> +compiled for.  This can make @code{__builtin_setjmp} and
> +@code{__builtin_longjmp} more efficient than their library
> +counterparts in some cases, but it can also cause incorrect and
> +mysterious behavior when mixing with code that uses the full register
> +set.

...the combination of these two paragraphs made it less clear.
It sounded like __builtin_longjmp might somehow restore the registers
using save slots in the caller's frame.

Trying it out, AIUI:

- Unlike setjmp and longjmp, __builtin_setjmp and __builtin_longjmp
  only save and restore what's in the jump buffer, which as the
  documentation says is only enough information to return to the
  original stack frame.

- Any function F that calls __builtin_setjmp compensates for this by
  saving extra registers on entry and restoring them on exit, in order
  to present a normal function interface to F's callers.  I.e. it isn't
  __builtin_setjmp itself that does the saving, and __builtin_longjmp
  doesn't do any restoring.  I didn't realise this from reading the above.

Thanks,
Richard

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v4]

[Pedro Alves]

On 12/04/2018 01:59 PM, Nick Clifton wrote:

> OK then, here is a fourth revision of the patch.

The issue pointed out by

 https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02592.html

is still present in this version.

Also, noticed a typo here:

> +/* If DMGL_NO_RECURE_LIMIT is not enabled, then this is the value used as

Typo: "RECURE"

> +   the maximum depth of recursion allowed.  It should be enough for any
> +   real-world mangled name.  */
> +#define DEMANGLE_RECURSION_LIMIT 1024
> +  

Thanks,
Pedro Alves

[PATCH 3/3][rs6000] Enable x86-compat vector intrinsics testing

[Paul Clarke]

The testsuite tests for the compatibility implementations of x86 vector
intrinsics for "powerpc" had been inadvertently made to PASS
without actually running the test code.

This patch removes the code which kept the tests from running the actual
test code.

2018-12-03  Paul A. Clarke  

[gcc/testsuite]

PR target/88316
* gcc.target/powerpc/bmi-check.h: Remove test for
__BUILTIN_CPU_SUPPORTS__, thereby enabling test code to run.
* gcc.target/powerpc/bmi2-check.h: Likewise.
* gcc.target/powerpc/mmx-check.h: Likewise.
* gcc.target/powerpc/sse-check.h: Likewise.
* gcc.target/powerpc/sse2-check.h: Likewise.
* gcc.target/powerpc/sse3-check.h: Likewise.
* gcc.target/powerpc/ssse3-check.h: Likewise.

Index: gcc/testsuite/gcc.target/powerpc/bmi-check.h
===
diff --git a/trunk/gcc/testsuite/gcc.target/powerpc/bmi-check.h 
b/trunk/gcc/testsuite/gcc.target/powerpc/bmi-check.h
--- a/trunk/gcc/testsuite/gcc.target/powerpc/bmi-check.h(revision 
266157)
+++ b/trunk/gcc/testsuite/gcc.target/powerpc/bmi-check.h(working copy)
@@ -13,19 +13,9 @@ do_test (void)
 int
 main ()
 {
-#ifdef __BUILTIN_CPU_SUPPORTS__
-  /* Need 64-bit for 64-bit longs as single instruction.  */
-  if ( __builtin_cpu_supports ("ppc64") )
-{
-  do_test ();
+  do_test ();
 #ifdef DEBUG
-  printf ("PASSED\n");
+  printf ("PASSED\n");
 #endif
-}
-#ifdef DEBUG
-  else
-printf ("SKIPPED\n");
-#endif
-#endif /* __BUILTIN_CPU_SUPPORTS__ */
   return 0;
 }
Index: gcc/testsuite/gcc.target/powerpc/bmi2-check.h
===
diff --git a/trunk/gcc/testsuite/gcc.target/powerpc/bmi2-check.h 
b/trunk/gcc/testsuite/gcc.target/powerpc/bmi2-check.h
--- a/trunk/gcc/testsuite/gcc.target/powerpc/bmi2-check.h   (revision 
266157)
+++ b/trunk/gcc/testsuite/gcc.target/powerpc/bmi2-check.h   (working copy)
@@ -13,22 +13,10 @@ do_test (void)
 int
 main ()
 {
-#ifdef __BUILTIN_CPU_SUPPORTS__
-  /* The BMI2 test for pext test requires the Bit Permute doubleword
- (bpermd) instruction added in PowerISA 2.06 along with the VSX
- facility.  So we can test for arch_2_06.  */
-  if ( __builtin_cpu_supports ("arch_2_06") )
-{
-  do_test ();
+  do_test ();
 #ifdef DEBUG
-  printf ("PASSED\n");
+  printf ("PASSED\n");
 #endif
-}
-#ifdef DEBUG
-  else
-printf ("SKIPPED\n");
-#endif
-#endif /* __BUILTIN_CPU_SUPPORTS__ */
   return 0;
 }
 
Index: gcc/testsuite/gcc.target/powerpc/mmx-check.h
===
diff --git a/trunk/gcc/testsuite/gcc.target/powerpc/mmx-check.h 
b/trunk/gcc/testsuite/gcc.target/powerpc/mmx-check.h
--- a/trunk/gcc/testsuite/gcc.target/powerpc/mmx-check.h(revision 
266157)
+++ b/trunk/gcc/testsuite/gcc.target/powerpc/mmx-check.h(working copy)
@@ -13,23 +13,9 @@ do_test (void)
 int
 main ()
   {
-#ifdef __BUILTIN_CPU_SUPPORTS__
-/* Many MMX intrinsics are simpler / faster to implement by
-   transferring the __m64 (long int) to vector registers for SIMD
-   operations.  To be efficient we also need the direct register
-   transfer instructions from POWER8.  So we can test for
-   arch_2_07.  */
-if ( __builtin_cpu_supports ("arch_2_07") )
-  {
-   do_test ();
+do_test ();
 #ifdef DEBUG
-   printf ("PASSED\n");
+printf ("PASSED\n");
 #endif
-  }
-#ifdef DEBUG
-else
-  printf ("SKIPPED\n");
-#endif
-#endif /* __BUILTIN_CPU_SUPPORTS__ */
 return 0;
   }
Index: gcc/testsuite/gcc.target/powerpc/sse-check.h
===
diff --git a/trunk/gcc/testsuite/gcc.target/powerpc/sse-check.h 
b/trunk/gcc/testsuite/gcc.target/powerpc/sse-check.h
--- a/trunk/gcc/testsuite/gcc.target/powerpc/sse-check.h(revision 
266157)
+++ b/trunk/gcc/testsuite/gcc.target/powerpc/sse-check.h(working copy)
@@ -1,7 +1,7 @@
 #include 
 #include "m128-check.h"
 
-#define DEBUG 1
+// #define DEBUG 1
 
 #define TEST sse_test
 
@@ -17,25 +17,10 @@ do_test (void)
 int
 main ()
   {
-#ifdef __BUILTIN_CPU_SUPPORTS__
-/* Most SSE intrinsic operations can be implemented via VMX
-   instructions, but some operations may be faster / simpler
-   using the POWER8 VSX instructions.  This is especially true
-   when we are transferring / converting to / from __m64 types.
-   The direct register transfer instructions from POWER8 are
-   especially important.  So we test for arch_2_07.  */
-if ( __builtin_cpu_supports ("arch_2_07") )
-  {
-   do_test ();
+do_test ();
 #ifdef DEBUG
-   printf ("PASSED\n");
+printf ("PASSED\n");
 #endif
-  }
-#ifdef DEBUG
-else
-printf ("SKIPPED\n");
-#endif
-#endif /* __BUILTIN_CPU_SUPPORTS__ */
 return 0;
   }
 
Index: gcc/testsuite/gcc.target/powerpc/sse2-check.h

[PATCH 2/3][rs6000] Fix x86-compat vector intrinsics testcases for BE, 32bit

[Paul Clarke]

Fix general endian issues found in the test cases for the compatibility
implementations of the x86 vector intrinsics.  (The tests had been
inadvertently made to PASS without actually running the test code.
A later patch fixes this issue.)

Additionally, a new  is added, as some of the APIs therein are
now used by the test cases.  It is _not_ a complete implementation of the
SSE4 interfaces, only the few "extract" interfaces uses by the tests.

2018-12-03  Paul A. Clarke  

[gcc]

PR target/88316
* config/rs6000/smmintrin.h: New file.
* config.gcc: add smmintrin.h to extra_headers for powerpc*-*-*.

[gcc/testsuite]

PR target/88316
* gcc.target/powerpc/mmx-packssdw-1.c: Fixes for big-endian.
* gcc.target/powerpc/mmx-packsswb-1.c: Likewise.
* gcc.target/powerpc/mmx-packuswb-1.c: Likewise.
* gcc.target/powerpc/mmx-pmulhw-1.c: Likewise.
* gcc.target/powerpc/sse-cvtpi32x2ps-1.c: Likewise.
* gcc.target/powerpc/sse-cvtpu16ps-1.c: Likewise.
* gcc.target/powerpc/sse-cvtss2si-1.c: Likewise.
* gcc.target/powerpc/sse-cvtss2si-2.c: Likewise.
* gcc.target/powerpc/sse2-pshufhw-1.c: Likewise.
* gcc.target/powerpc/sse2-pshuflw-1.c: Likewise.

Index: gcc/config/rs6000/smmintrin.h
===
diff --git a/trunk/gcc/config/rs6000/smmintrin.h 
b/trunk/gcc/config/rs6000/smmintrin.h
new file mode 10644
--- /dev/null   (revision 0)
+++ b/trunk/gcc/config/rs6000/smmintrin.h   (working copy)
@@ -0,0 +1,67 @@
+/* Copyright (C) 2018 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC 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.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+/* Implemented from the specification included in the Intel C++ Compiler
+   User Guide and Reference, version 9.0.  */
+
+#ifndef NO_WARN_X86_INTRINSICS
+/* This header is distributed to simplify porting x86_64 code that
+   makes explicit use of Intel intrinsics to powerpc64le.
+   It is the user's responsibility to determine if the results are
+   acceptable and make additional changes as necessary.
+   Note that much code that uses Intel intrinsics can be rewritten in
+   standard C or GNU C extensions, which are more portable and better
+   optimized across multiple targets.  */
+#endif
+
+#ifndef SMMINTRIN_H_
+#define SMMINTRIN_H_
+
+#include 
+#include 
+
+extern __inline int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
+_mm_extract_epi8 (__m128i __X, const int __N)
+{
+  return (unsigned char) ((__v16qi)__X)[__N & 15];
+}
+
+extern __inline int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
+_mm_extract_epi32 (__m128i __X, const int __N)
+{
+  return ((__v4si)__X)[__N & 3];
+}
+
+extern __inline int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
+_mm_extract_epi64 (__m128i __X, const int __N)
+{
+  return ((__v2di)__X)[__N & 1];
+}
+
+extern __inline int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
+_mm_extract_ps (__m128 __X, const int __N)
+{
+  return ((__v4si)__X)[__N & 3];
+}
+
+#endif
Index: gcc/config.gcc
===
diff --git a/trunk/gcc/config.gcc b/trunk/gcc/config.gcc
--- a/trunk/gcc/config.gcc  (revision 266157)
+++ b/trunk/gcc/config.gcc  (working copy)
@@ -504,7 +504,7 @@ powerpc*-*-*)
extra_headers="${extra_headers} bmi2intrin.h bmiintrin.h"
extra_headers="${extra_headers} xmmintrin.h mm_malloc.h emmintrin.h"
extra_headers="${extra_headers} mmintrin.h x86intrin.h"
-   extra_headers="${extra_headers} pmmintrin.h tmmintrin.h"
+   extra_headers="${extra_headers} pmmintrin.h tmmintrin.h smmintrin.h"
extra_headers="${extra_headers} ppu_intrinsics.h spu2vmx.h vec_types.h 
si2vmx.h"
extra_headers="${extra_headers} amo.h"
case x$with_cpu in
Index: gcc/testsuite/gcc.target/powerpc/mmx-packssdw-1.c
===
diff --git a/trunk/gcc/testsuite/gcc.target/powerpc/mmx-packssdw-1.c 

[PATCH 1/3][rs6000] x86-compat vector intrinsics fixes for BE, 32bit

[Paul Clarke]

Fix general endian and 32-bit mode issues found in the
compatibility implementations of the x86 vector intrinsics when running the
associated test suite tests.  (The tests had been inadvertently made to PASS
without actually running the test code.  A later patch fixes this issue.)

In a few cases, the opportunity was taken to update the vector API used in
the implementations to the preferred functions from the
OpenPOWER 64-Bit ELF V2 ABI Specification.

[gcc]

2018-12-03  Paul A. Clarke  

PR target/88316
* config/rs6000/mmintrin.h (_mm_unpackhi_pi8): Fix for big-endian.
(_mm_unpacklo_pi8): Likewise.
(_mm_mulhi_pi16): Likewise.
(_mm_packs_pi16): Fix for big-endian. Use preferred API.
(_mm_packs_pi32): Likewise.
(_mm_packs_pu16): Likewise.
* config/rs6000/xmmintrin.h (_mm_cvtss_si32): Fix for big-endian.
(_mm_cvtss_si64): Likewise.
(_mm_cvtpi32x2_ps): Likewise.
(_mm_shuffle_ps): Likewise.
(_mm_movemask_pi8): Likewise.
(_mm_mulhi_pu16): Likewise.
(_mm_sad_pu8): Likewise.
(_mm_sad_pu8): Likewise.
(_mm_cvtpu16_ps): Fix for big-endian. Use preferred API.
(_mm_cvtpu8_ps): Likewise.
* config/rs6000/emmintrin.h (_mm_movemask_pd): Fix for big-endian.
(_mm_mul_epu32): Likewise.
(_mm_bsrli_si128): Likewise.
(_mm_movemask_epi8): Likewise.
(_mm_shufflehi_epi16): Likewise.
(_mm_shufflelo_epi16): Likewise.
(_mm_shuffle_epi32): Likewise.
* config/rs6000/pmmintrin.h (_mm_hadd_ps): Fix for big-endian.
(_mm_sub_ps): Likewise.
* config/rs6000/mmintrin.h (_mm_cmpeq_pi8): Fix for 32-bit mode.

Index: gcc/config/rs6000/emmintrin.h
===
diff --git a/trunk/gcc/config/rs6000/emmintrin.h 
b/trunk/gcc/config/rs6000/emmintrin.h
--- a/trunk/gcc/config/rs6000/emmintrin.h   (revision 266157)
+++ b/trunk/gcc/config/rs6000/emmintrin.h   (working copy)
@@ -1237,7 +1237,7 @@ _mm_movemask_pd (__m128d  __A)
 #ifdef __LITTLE_ENDIAN__
0x80800040, 0x80808080, 0x80808080, 0x80808080
 #elif __BIG_ENDIAN__
-  0x80808080, 0x80808080, 0x80808080, 0x80800040
+  0x80808080, 0x80808080, 0x80808080, 0x80804000
 #endif
 };
 
@@ -1483,12 +1483,8 @@ _mm_mul_epu32 (__m128i __A, __m128i __B)
 #endif
   return (__m128i) result;
 #else
-#ifdef __LITTLE_ENDIAN__
   return (__m128i) vec_mule ((__v4su)__A, (__v4su)__B);
-#elif __BIG_ENDIAN__
-  return (__m128i) vec_mulo ((__v4su)__A, (__v4su)__B);
 #endif
-#endif
 }
 
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
@@ -1612,7 +1608,8 @@ _mm_bsrli_si128 (__m128i __A, const int __N)
   const __v16qu zeros = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
 
   if (__N < 16)
-if (__builtin_constant_p(__N))
+if (__builtin_constant_p(__N) &&
+__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
   /* Would like to use Vector Shift Left Double by Octet
 Immediate here to use the immediate form and avoid
 load of __N * 8 value into a separate VR.  */
@@ -1620,7 +1617,11 @@ _mm_bsrli_si128 (__m128i __A, const int __N)
 else
   {
__v16qu shift = vec_splats((unsigned char)(__N*8));
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
result = vec_sro ((__v16qu)__A, shift);
+#else
+   result = vec_slo ((__v16qu)__A, shift);
+#endif
   }
   else
 result = zeros;
@@ -2026,13 +2027,8 @@ _mm_movemask_epi8 (__m128i __A)
   __vector unsigned long long result;
   static const __vector unsigned char perm_mask =
 {
-#ifdef __LITTLE_ENDIAN__
0x78, 0x70, 0x68, 0x60, 0x58, 0x50, 0x48, 0x40,
0x38, 0x30, 0x28, 0x20, 0x18, 0x10, 0x08, 0x00
-#elif __BIG_ENDIAN__
-   0x00, 0x08, 0x10, 0x18, 0x20, 0x28, 0x30, 0x38,
-   0x40, 0x48, 0x50, 0x58, 0x60, 0x68, 0x70, 0x78
-#endif
 };
 
   result = ((__vector unsigned long long)
@@ -2078,34 +2074,23 @@ _mm_shufflehi_epi16 (__m128i __A, const int __mask
 #ifdef __LITTLE_ENDIAN__
  0x0908, 0x0B0A, 0x0D0C, 0x0F0E
 #elif __BIG_ENDIAN__
- 0x0607, 0x0405, 0x0203, 0x0001
+ 0x0809, 0x0A0B, 0x0C0D, 0x0E0F
 #endif
 };
   __v2du pmask =
 #ifdef __LITTLE_ENDIAN__
-  { 0x1716151413121110UL,  0x1f1e1d1c1b1a1918UL};
+  { 0x1716151413121110UL,  0UL};
 #elif __BIG_ENDIAN__
-  { 0x1011121314151617UL,  0x18191a1b1c1d1e1fUL};
+  { 0x1011121314151617UL,  0UL};
 #endif
   __m64_union t;
   __v2du a, r;
 
-#ifdef __LITTLE_ENDIAN__
   t.as_short[0] = permute_selectors[element_selector_98];
   t.as_short[1] = permute_selectors[element_selector_BA];
   t.as_short[2] = permute_selectors[element_selector_DC];
   t.as_short[3] = permute_selectors[element_selector_FE];
-#elif __BIG_ENDIAN__
-  t.as_short[3] = permute_selectors[element_selector_98];
-  t.as_short[2] = permute_selectors[element_selector_BA];
-  t.as_short[1] = 

[PATCH 0/3][rs6000] x86-compat vector intrinsics fixes for BE, 32bit

[Paul Clarke]

Many of the tests for the x86-compatible vector intrinsics implementations
were protected by "#ifdef __BUILTIN_CPU_SUPPORTS__", which is only enabled
with recent enough glibc that in most environments, the test were silently
passing without actually testing anything.

Patches which follow:
01: Fix the implementations.
02: Fix the test cases.
03: Enable the tests to actually run the test code.

Bootstrap and regression tested on POWER8 ppc64le, ppc64(be), ppc(32bit be),
and POWER7 ppc64(be).

OK for trunk?

PC

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping
  PR87506 - https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01758.html

You've acked the patch with the asserts but that FAILs as mentioned
in the above mail.  The following has been bootstrapped/regtested
and works, can it be committed without those asserts and let those
be handled incrementally later (though, I'm afraid I'm not familiar enough
with resolving those).

Thanks.

2018-11-21  Jakub Jelinek  

PR c++/87506
* constexpr.c (adjust_temp_type): Handle EMPTY_CLASS_EXPR.

* g++.dg/cpp0x/constexpr-87506.C: New test.

--- gcc/cp/constexpr.c.jj   2018-11-16 21:35:34.551110868 +0100
+++ gcc/cp/constexpr.c  2018-11-19 09:35:06.880386449 +0100
@@ -1280,6 +1280,8 @@ adjust_temp_type (tree type, tree temp)
   /* Avoid wrapping an aggregate value in a NOP_EXPR.  */
   if (TREE_CODE (temp) == CONSTRUCTOR)
 return build_constructor (type, CONSTRUCTOR_ELTS (temp));
+  if (TREE_CODE (temp) == EMPTY_CLASS_EXPR)
+return build0 (EMPTY_CLASS_EXPR, type);
   gcc_assert (scalarish_type_p (type));
   return cp_fold_convert (type, temp);
 }
--- gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C.jj 2018-11-19 
09:33:07.795341369 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C2018-11-19 
09:33:07.795341369 +0100
@@ -0,0 +1,12 @@
+// PR c++/87506
+// { dg-do compile { target c++11 } }
+
+struct A {};
+struct B { constexpr B (const A) {} };
+struct C : B { using B::B; };
+
+void
+foo ()
+{
+  C c (A{});
+}


Jakub

[PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

[Mark Eggleston]

Here is a patch to considered for incorporation into gfortran adding to 
its legacy support. It pads character to integer conversions using 
spaces instead of zeros when enabled.


The pad character is 'undefined' or 'processor dependent' depending on 
which standard you read. This makes it 0x20 which matches the Oracle 
Fortran compiler.


Enabled using -fdec-pad-with-spaces and -fdec.

Please find attached a patch file and text files containing change log 
entries for gcc/fortran and gcc/testsuite.


Note: I do not have write access so can not commit changes. Someone else 
will have to commit the change if it is acceptable.


There are several more patches to support legacy Fortran which will be 
sent in order.


regards,

Mark Eggleston

--
https://www.codethink.co.uk/privacy.html

>From de02d8bbab91a87c30672d1a9e1c3ecc95b800f7 Mon Sep 17 00:00:00 2001
From: Jim MacArthur 
Date: Mon, 28 Sep 2015 16:06:30 +0100
Subject: [PATCH] Pad character-to-int conversions with spaces instead of
 zeros.

The pad character is 'undefined' or 'processor dependent' depending on which
standard you read. This makes it 0x20 which matches the Oracle Fortran
compiler.

Additions by Mark Eggleston :

This feature is enabled using -fdec-pad-with-spaces. Also enabled using -fdec.
---
 gcc/fortran/lang.opt|  4 
 gcc/fortran/options.c   |  1 +
 gcc/fortran/simplify.c  |  2 +-
 gcc/testsuite/gfortran.dg/dec-pad-with-spaces-1.f90 | 17 +
 gcc/testsuite/gfortran.dg/dec-pad-with-spaces-2.f90 | 17 +
 gcc/testsuite/gfortran.dg/dec-pad-with-spaces-3.f90 | 17 +
 6 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/dec-pad-with-spaces-1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/dec-pad-with-spaces-2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/dec-pad-with-spaces-3.f90

diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index dc9a94c829c..dbdea73ea1f 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -452,6 +452,10 @@ fdec-math
 Fortran Var(flag_dec_math)
 Enable legacy math intrinsics for compatibility.
 
+fdec-pad-with-spaces
+Fortran Var(flag_dec_pad_with_spaces)
+For character to integer conversions, use spaces for the pad rather than NUL.
+
 fdec-structure
 Fortran Var(flag_dec_structure)
 Enable support for DEC STRUCTURE/RECORD.
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 48e35e3524d..7abccd28aaf 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -74,6 +74,7 @@ set_dec_flags (int value)
   SET_BITFLAG (flag_dec_static, value, value);
   SET_BITFLAG (flag_dec_math, value, value);
   SET_BITFLAG (flag_dec_include, value, value);
+  SET_BITFLAG (flag_dec_pad_with_spaces, value, value);
 }
 
 /* Finalize DEC flags.  */
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index cdf748e4990..04c2c6ea13c 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -7830,7 +7830,7 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mold, gfc_expr *size)
   /* Allocate the buffer to store the binary version of the source.  */
   buffer_size = MAX (source_size, result_size);
   buffer = (unsigned char*)alloca (buffer_size);
-  memset (buffer, 0, buffer_size);
+  memset (buffer, (flag_dec_pad_with_spaces ? 0x20 : 0x0), buffer_size);
 
   /* Now write source to the buffer.  */
   gfc_target_encode_expr (source, buffer, buffer_size);
diff --git a/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-1.f90 b/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-1.f90
new file mode 100644
index 000..c6b5302e79d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-1.f90
@@ -0,0 +1,17 @@
+! { dg-do run }
+! { dg-options "-fdec-pad-with-spaces" }
+!
+! Test case contributed by Mark Eggleston 
+
+program test
+  integer(kind=8) :: a
+  a = transfer("ABCE", 1_8)
+  ! If a has not been converted into big endian
+  ! or little endian integer it has failed.
+  if ((a.ne.int(z'4142434520202020',kind=8)).and. &
+  (a.ne.int(z'2020202045434241',kind=8))) then 
+stop 1
+  end if
+end program test
+
+
diff --git a/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-2.f90 b/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-2.f90
new file mode 100644
index 000..dd1d9fb3b32
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-2.f90
@@ -0,0 +1,17 @@
+! { dg-do run }
+! { dg-options "-fdec" }
+!
+! Test case contributed by Mark Eggleston 
+
+program test
+  integer(kind=8) :: a
+  a = transfer("ABCE", 1_8)
+  ! If a has not been converted into big endian
+  ! or little endian integer it has failed.
+  if ((a.ne.int(z'4142434520202020',kind=8)).and. &
+  (a.ne.int(z'2020202045434241',kind=8))) then 
+stop 1
+  end if
+end program test
+
+
diff --git a/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-3.f90 b/gcc/testsuite/gfortran.dg/dec-pad-with-spaces-3.f90
new file mode 

Re: Fix move_if_noexcept usages in _Hashtable

[Jonathan Wakely]

On 04/12/18 07:45 +0100, François Dumont wrote:

Hi

  This patch fix a minor problem with usage of std::move_if_noexcept. 
We use it to move node content if move construtor is noexcept but we 
eventually use the allocator_type::construct method which might be 
slightly different. I think it is better to check for this method 
noexcept qualification.


This is likely to pessimize some code, since most allocators do not
have an exception-specification on their construct members.

  Moreover I have added a special overload for nodes containing a 
std::pair. It is supposed to allow move semantic in associative 
containers where Key is stored as const deleting std::pair move 
constructor. In this case we should still move the Value part.


  It doesn't work for the moment because the std::pair piecewise 
constructor has no noexcept qualification. Is there any plan to add it 
? I think adding it will force including  in stl_pair.h, is it 
fine ?


  If this evolution is accepted I'll adapt it for _Rb_tree that has 
the same problem.


  Working on this I also notice that content of initialization_list is 
not moved. Is there a plan to make initialization_list iterator type 
like move_iterator ? Should containers use 
__make_move_iterator_if_noexcept ?


No.

Whether to allow moving from std::initializer_list is an active topic,
see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1249r0.html


  Tested under Linux x86_64 normal mode.

  Ok to commit this first step ?


No, this is not suitable for stage 3. It seems too risky.

We can reconsider it during stage 1, but I'd like to see (at least) a
new test showing a bug with the current code. For example, a type with
a move constructor that is noexcept, but when used with a
scoped_allocator_adaptor (which calls something other than the move
constructor) we incorrectly move elements, and lose data when an
exception happens.

[PATCH] Make std::match_results::_M_resize more useful

[Jonathan Wakely]

As both callers of match_results::_M_resize(unsigned) immediately follow
it with a loop to update the value of each sub_match, that behaviour can
be moved into _M_resize itself. The first caller fills the container
with unmatched subs, which can be done with vector::assign, and the
second caller clears the container to establish a specific state, which
can be provided by a new member function specific to that purpose.

Tangentially, I also noticed that match_results::max_size() doesn't
account for the three special sub_match objects that are always present
in a fully established result state. This patch also fixes that.

* include/bits/regex.h (match_results::max_size()): Adjust return
value to account for prefix/suffix/unmatched subs.
(match_results::_M_resize(unsigned int)): Use _Base_type::assign to
reset the contained sub matches.
(match_results::_M_establish_failed_match(_Bi_iter)): Add new member
function to set result state following a failed match.
* include/bits/regex.tcc (__regex_algo_impl): Remove loop to set
sub_match states after _M_resize. Use _M_establish_failed_match.

Tested x86_64-linux.

Any objections?


commit 6a96a528102e1062dd2627b7eb8ddf26c43bc1e7
Author: Jonathan Wakely 
Date:   Tue Dec 4 13:21:26 2018 +

Make std::match_results::_M_resize more useful

As both callers of match_results::_M_resize(unsigned) immediately follow
it with a loop to update the value of each sub_match, that behaviour can
be moved into _M_resize itself. The first caller fills the container
with unmatched subs, which can be done with vector::assign, and the
second caller clears the container to establish a specific state, which
can be provided by a new member function specific to that purpose.

Tangentially, I also noticed that match_results::max_size() doesn't
account for the three special sub_match objects that are always present
in a fully established result state. This patch also fixes that.

* include/bits/regex.h (match_results::max_size()): Adjust return
value to account for prefix/suffix/unmatched subs.
(match_results::_M_resize(unsigned int)): Use _Base_type::assign to
reset the contained sub matches.
(match_results::_M_establish_failed_match(_Bi_iter)): Add new member
function to set result state following a failed match.
* include/bits/regex.tcc (__regex_algo_impl): Remove loop to set
sub_match states after _M_resize. Use _M_establish_failed_match.

diff --git a/libstdc++-v3/include/bits/regex.h 
b/libstdc++-v3/include/bits/regex.h
index af6fe3f0d79..d36ee33033d 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -1698,7 +1698,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 
   size_type
   max_size() const noexcept
-  { return _Base_type::max_size(); }
+  { return _Base_type::max_size() - 3; }
 
   /**
* @brief Indicates if the %match_results contains no results.
@@ -1942,9 +1942,20 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
const basic_regex<_Cp, _Rp>&,
regex_constants::match_flag_type);
 
+  // Reset contents to __size unmatched sub_match objects
+  // (plus additional objects for prefix, suffix and unmatched sub).
   void
   _M_resize(unsigned int __size)
-  { _Base_type::resize(__size + 3); }
+  { _Base_type::assign(__size + 3, sub_match<_Bi_iter>{}); }
+
+  // Set state to a failed match for the given past-the-end iterator.
+  void
+  _M_establish_failed_match(_Bi_iter __end)
+  {
+   sub_match<_Bi_iter> __sm;
+   __sm.first = __sm.second = __end;
+   _Base_type::assign(3, __sm);
+  }
 
   const_reference
   _M_unmatched_sub() const
diff --git a/libstdc++-v3/include/bits/regex.tcc 
b/libstdc++-v3/include/bits/regex.tcc
index dcf660902bc..de0ce795b84 100644
--- a/libstdc++-v3/include/bits/regex.tcc
+++ b/libstdc++-v3/include/bits/regex.tcc
@@ -57,8 +57,6 @@ namespace __detail
   typename match_results<_BiIter, _Alloc>::_Base_type& __res = __m;
   __m._M_begin = __s;
   __m._M_resize(__re._M_automaton->_M_sub_count());
-  for (auto& __it : __res)
-   __it.matched = false;
 
   bool __ret;
   if ((__re.flags() & regex_constants::__polynomial)
@@ -109,12 +107,7 @@ namespace __detail
}
   else
{
- __m._M_resize(0);
- for (auto& __it : __res)
-   {
- __it.matched = false;
- __it.first = __it.second = __e;
-   }
+ __m._M_establish_failed_match(__e);
}
   return __ret;
 }

Re: [PATCH, libgo]: Use build.Default.Compiler in go/cmd/vet/types.goq

[Ian Lance Taylor]

On Tue, Dec 4, 2018 at 1:56 AM, Uros Bizjak  wrote:
>
> Without this patch go tool vet segfaults on alpha due to unknown
> architecture for gc compiler:
>
> go tool vet: exit status 2
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=1 addr=24 pc=4832064492]
>
> goroutine 1 [running]:
> panic
> /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/panic.go:588
>
> Attached patch fixes the segfault.

Thanks.  Committed to mainline.

Ian

Re: [PATCH, OpenACC] Enable GOMP_MAP_FIRSTPRIVATE_INT for OpenACC

[Jakub Jelinek]

On Thu, Sep 20, 2018 at 07:38:04PM -0400, Julian Brown wrote:
> 2018-09-20  Cesar Philippidis  
> Julian Brown  
> 
>   gcc/
>   * omp-low.c (maybe_lookup_field_in_outer_ctx): New function.
>   (convert_to_firstprivate_int): New function.
>   (convert_from_firstprivate_int): New function.
>   (lower_omp_target): Enable GOMP_MAP_FIRSTPRIVATE_INT in OpenACC.
> 
>   libgomp/
>   * oacc-parallel.c (GOACC_parallel_keyed): Handle
>   GOMP_MAP_FIRSTPRIVATE_INT host addresses.
>   * plugin/plugin-nvptx.c (nvptx_exec): Handle
>   GOMP_MAP_FIRSTPRIVATE_INT host addresses.
>   * testsuite/libgomp.oacc-c++/firstprivate-int.C: New test.
>   * testsuite/libgomp.oacc-c-c++-common/firstprivate-int.c: New
>   test.
>   * testsuite/libgomp.oacc-fortran/firstprivate-int.f90: New test.

> @@ -8039,7 +8182,7 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
> omp_context *ctx)
>   if (omp_is_reference (ovar))
> type = TREE_TYPE (type);
>   if ((INTEGRAL_TYPE_P (type)
> -  && TYPE_PRECISION (type) <= POINTER_SIZE)
> +  && tree_to_uhwi (TYPE_SIZE (type)) <= POINTER_SIZE)
>   || TREE_CODE (type) == POINTER_TYPE)
> {
>   tkind = GOMP_MAP_FIRSTPRIVATE_INT;
> @@ -8194,7 +8337,7 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
> omp_context *ctx)
>   if (omp_is_reference (var))
> type = TREE_TYPE (type);
>   if ((INTEGRAL_TYPE_P (type)
> -  && TYPE_PRECISION (type) <= POINTER_SIZE)
> +  && tree_to_uhwi (TYPE_SIZE (type)) <= POINTER_SIZE)
>   || TREE_CODE (type) == POINTER_TYPE)
> {
>   x = build_receiver_ref (var, false, ctx);

Why this?

Jakub

Re: [PATCH, OpenACC] Support Fortran derived type members in "acc update" directives

[Jakub Jelinek]

On Mon, Sep 03, 2018 at 08:46:54PM -0400, Julian Brown wrote:
> 2018-09-03  Cesar Philippidis  
> 
> gcc/fortran/
> * openmp.c (gfc_match_omp_variable_list): New allow_derived
> argument. (gfc_match_omp_map_clause): Update call to
> gfc_match_omp_variable_list. (gfc_match_omp_clauses): Update
> calls to gfc_match_omp_map_clause. (gfc_match_oacc_update):
> Update call to gfc_match_omp_clauses. (resolve_omp_clauses):
> Permit derived type variables in ACC UPDATE clauses.
> * trans-openmp.c (gfc_trans_omp_clauses_1): Lower derived type
> members.
> 
> gcc/
> * gimplify.c (gimplify_scan_omp_clauses): Update handling of ACC
> UPDATE variables.
> 
> gcc/testsuite/
> * gfortran.dg/goacc/derived-types.f90: New test.
> 
> libgomp/
> * testsuite/libgomp.oacc-fortran/update-2.f90: New test.
> * testsuite/libgomp.oacc-fortran/derived-type-1.f90: New test.

Note, already OpenMP 4.5 allows the %s in map/to/from clauses, I just didn't
get to that yet.
And OpenMP 5.0 allows arbitrary expressions there.

> @@ -4336,9 +4342,12 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses 
> *omp_clauses,
>   || n->expr->ref == NULL
>   || n->expr->ref->next
>   || n->expr->ref->type != REF_ARRAY)
> -   gfc_error ("%qs in %s clause at %L is not a proper "
> -  "array section", n->sym->name, name,
> -  >where);
> +   {
> + if (n->sym->ts.type != BT_DERIVED)
> +   gfc_error ("%qs in %s clause at %L is not a proper "
> +  "array section", n->sym->name, name,
> +  >where);
> +   }
>   else if (n->expr->ref->u.ar.codimen)
> gfc_error ("Coarrays not supported in %s clause at %L",
>name, >where);

I'm worried about this change a little bit.  It isn't guarded for OpenACC
only and I wonder if you actually resolve properly the derived expressions
(look inside of those).

> diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> index f038f4c..95b15e5 100644
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -2108,7 +2108,68 @@ gfc_trans_omp_clauses (stmtblock_t *block, 
> gfc_omp_clauses *clauses,
> tree decl = gfc_get_symbol_decl (n->sym);
> if (DECL_P (decl))
>   TREE_ADDRESSABLE (decl) = 1;
> -   if (n->expr == NULL || n->expr->ref->u.ar.type == AR_FULL)
> +   /* Handle derived-typed members for OpenACC Update.  */
> +   if (n->sym->ts.type == BT_DERIVED
> +   && n->expr != NULL && n->expr->ref != NULL
> +   && (n->expr->ref->next == NULL
> +   || (n->expr->ref->next != NULL
> +   && n->expr->ref->next->type == REF_ARRAY
> +   && n->expr->ref->next->u.ar.type == AR_FULL))
> +   && (n->expr->ref->type == REF_ARRAY
> +   && n->expr->ref->u.ar.type != AR_SECTION))

Like here you have all kinds of conditions, but has resolving made sure all
the needed diagnostics is emitted?
Perhaps at least for now this also should be guarded on OpenACC only,
once OpenMP allows %s in map/to/from, part of this will be usable for it,
but e.g.

> +   if (context != type)
> + {
> +   tree f2 = c->norestrict_decl;
> +   if (!f2 || DECL_FIELD_CONTEXT (f2) != type)
> + for (f2 = TYPE_FIELDS (TREE_TYPE (decl)); f2;
> +  f2 = DECL_CHAIN (f2))
> +   if (TREE_CODE (f2) == FIELD_DECL
> +   && DECL_NAME (f2) == DECL_NAME (field))
> + break;
> +   gcc_assert (f2);
> +   c->norestrict_decl = f2;
> +   field = f2;
> + }

the above stuff looks way too OpenACC specific.

Jakub

Re: [PATCH v3] Make function clone name numbering independent.

[Jan Hubicka]

> On 2018-12-03 12:00 p.m., Michael Ploujnikov wrote:
> > On 2018-12-01 11:29 a.m., H.J. Lu wrote:
> >> This caused:
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297
> >>
> > 
> > Sorry about that. Looks like I should have been testing with
> > --with-build-config=bootstrap-lto rather than just --enable-bootstrap.
> > 
> > The quick fix would be to undo the patch to create_virtual_clone or to
> > just change clone_num_suffixes to key off of DECL_ASSEMBLER_NAME
> > (node->decl) instead of node pointers. Any preferences?
> > 
> > The harder fix would be to figure out why some nodes share the same
> > names and fix that, but maybe that's just inevitable with LTO?
> > 
> > - Michael
> > 
> 
> Here's a quick fix while the issue is being investigated.
> 
> Bootstrapped (--with-build-config=bootstrap-lto) and regtested on x86_64.
> 
> Ok for trunk?

> From f5e2500f30ad337e85e0b53eaa15c724657966a2 Mon Sep 17 00:00:00 2001
> From: Michael Ploujnikov 
> Date: Mon, 3 Dec 2018 18:19:18 -0500
> Subject: [PATCH] PR ipa/88297
> 
> gcc/ChangeLog:
> 
> 2018-12-03  Michael Ploujnikov  
> 
>   PR ipa/88297
>   * ipa-cp.c (create_specialized_node): Store clone counters by
>   node assembler names.
>   (ipcp_driver): Change type of clone_num_suffixes key type to
>   const char*.

OK,
thanks!
Honza

Re: [PATCH][OpenACC] update gfortran's tile clause error handling

[Jakub Jelinek]

On Tue, Aug 07, 2018 at 02:47:07PM -0700, Cesar Philippidis wrote:
> This patch updates how the OpenACC tile clause is handled in the Fortran
> FE to match it's behavior in C/C++. Specifically, the tile clause now
> errors on negative integer arguments, instead of emitting a warning.
> 
> Is this OK for trunk?

I've reviewed this already in some other patch, this is not ok, if
that is what you want for OpenACC, you need to copy the function to some
other one and adjust callers to use it for OpenACC clauses only.

> >From af39a6d65cfb46397fa62c88521189002fb3d705 Mon Sep 17 00:00:00 2001
> From: Cesar Philippidis 
> Date: Mon, 3 Oct 2016 13:58:59 +
> Subject: [PATCH] [OpenACC] update gfortran's tile clause error handling
> 
> 2018-XX-YY  Cesar Philippidis  
> 
>   gcc/fortran/
>   * openmp.c (resolve_positive_int_expr): Promote the warning to an
>   error.
> 
>   gcc/testsuite/
>   * gfortran.dg/goacc/loop-2.f95: Change expected tile clause
>   warnings to errors.
>   * gfortran.dg/goacc/loop-5.f95: Likewise.
>   * gfortran.dg/goacc/sie.f95: Likewise.
>   * gfortran.dg/goacc/tile-1.f90: New test.
>   * gfortran.dg/goacc/tile-2.f90: New test.

Jakub

Re: [PATCH, OpenACC] (2/2) Fix implicit mapping for array slices on lexically-enclosing data constructs (PR70828)

[Jakub Jelinek]

On Tue, Aug 28, 2018 at 03:19:34PM -0400, Julian Brown wrote:
> 2018-08-28  Julian Brown  
> 
>   gcc/fortran/
>   * trans-openmp.c (gfc_omp_finish_clause): Don't raise error for
>   assumed-size array if present in a lexically-enclosing data construct.
> 
>   libgomp/
>   * testsuite/libgomp.oacc-fortran/pr70828-4.f90: New test.

This is ok for trunk if whatever it depends on is committed.

Jakub

Re: [PATCH, OpenACC] (1/2) Fix implicit mapping for array slices on lexically-enclosing data constructs (PR70828)

[Jakub Jelinek]

On Tue, Aug 28, 2018 at 03:19:19PM -0400, Julian Brown wrote:
> 2018-08-28  Julian Brown  
>   Cesar Philippidis  
> 
>   PR middle-end/70828
> 
>   gcc/
>   * gimplify.c (gimplify_omp_ctx): Add decl_data_clause hash map.
>   (new_omp_context): Initialise above.
>   (delete_omp_context): Delete above.
>   (gimplify_scan_omp_clauses): Scan for array mappings on data constructs,
>   and record in above map.
>   (gomp_needs_data_present): New function.
>   (gimplify_adjust_omp_clauses_1): Handle data mappings (e.g. array
>   slices) declared in lexically-enclosing data constructs.
>   * omp-low.c (lower_omp_target): Allow decl for bias not to be present
>   in omp context.
>   
>   gcc/testsuite/
>   * c-c++-common/goacc/acc-data-chain.c: New test.
>   * gfortran.dg/goacc/pr70828.f90: New test.
>   * gfortran.dg/goacc/pr70828-2.f90: New test.
> 
>   libgomp/
>   * testsuite/libgomp.oacc-c-c++-common/pr70828.c: New test.
>   * testsuite/libgomp.oacc-fortran/implicit_copy.f90: New test.
>   * testsuite/libgomp.oacc-fortran/pr70828.f90: New test.
>   * testsuite/libgomp.oacc-fortran/pr70828-2.f90: New test.
>   * testsuite/libgomp.oacc-fortran/pr70828-3.f90: New test.
>   * testsuite/libgomp.oacc-fortran/pr70828-5.f90: New test.

> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -191,6 +191,7 @@ struct gimplify_omp_ctx
>bool target_map_scalars_firstprivate;
>bool target_map_pointers_as_0len_arrays;
>bool target_firstprivatize_array_bases;
> +  hash_map > *decl_data_clause;
>  };
>  
>  static struct gimplify_ctx *gimplify_ctxp;
> @@ -413,6 +414,7 @@ new_omp_context (enum omp_region_type region_type)
>  c->default_kind = OMP_CLAUSE_DEFAULT_SHARED;
>else
>  c->default_kind = OMP_CLAUSE_DEFAULT_UNSPECIFIED;
> +  c->decl_data_clause = new hash_map >;

Not really happy about creating this unconditionally.  Can you leave it
NULL by default and only initialize for contexts where it will be needed?

> @@ -7793,8 +7796,21 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq 
> *pre_p,
>   case OMP_TARGET:
> break;
>   case OACC_DATA:
> -   if (TREE_CODE (TREE_TYPE (decl)) != ARRAY_TYPE)
> - break;
> +   {
> + tree nextc = OMP_CLAUSE_CHAIN (c);
> + if (nextc
> + && OMP_CLAUSE_CODE (nextc) == OMP_CLAUSE_MAP
> + && (OMP_CLAUSE_MAP_KIND (nextc)
> +   == GOMP_MAP_FIRSTPRIVATE_POINTER
> + || OMP_CLAUSE_MAP_KIND (nextc) == GOMP_MAP_POINTER))
> +   {
> + tree base_addr = OMP_CLAUSE_DECL (nextc);
> + ctx->decl_data_clause->put (base_addr,
> +   std::make_pair (unshare_expr (c), unshare_expr (nextc)));

Don't like the wrapping here, can you just split it up:
std::pair p
  = std::make_pair (unshare_expr (c),
unshare_expr (nextc));
ctx->decl_data_clause->put (base_addr, p);
or similar?

> +
> +static std::pair *
> +gomp_needs_data_present (tree decl)

Would be helpful to have acc/oacc in the function name.
> +{
> +  gimplify_omp_ctx *ctx = NULL;
> +
> +  if (TREE_CODE (TREE_TYPE (decl)) != ARRAY_TYPE
> +  && TREE_CODE (TREE_TYPE (decl)) != POINTER_TYPE
> +  && (TREE_CODE (TREE_TYPE (decl)) != POINTER_TYPE
> +   || TREE_CODE (TREE_TYPE (TREE_TYPE (decl))) != ARRAY_TYPE))
> +return NULL;
> +
> +  if (gimplify_omp_ctxp->region_type != ORT_ACC_PARALLEL
> +  && gimplify_omp_ctxp->region_type != ORT_ACC_KERNELS)
> +return NULL;

And move this test to the top.

> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -8411,9 +8411,10 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
> omp_context *ctx)
>   x = fold_convert_loc (clause_loc, type, x);
>   if (!integer_zerop (OMP_CLAUSE_SIZE (c)))
> {
> - tree bias = OMP_CLAUSE_SIZE (c);
> - if (DECL_P (bias))
> -   bias = lookup_decl (bias, ctx);
> + tree bias = OMP_CLAUSE_SIZE (c), remapped_bias;
> + if (DECL_P (bias)
> + && (remapped_bias = maybe_lookup_decl (bias, ctx)))
> +   bias = remapped_bias;
>   bias = fold_convert_loc (clause_loc, sizetype, bias);
>   bias = fold_build1_loc (clause_loc, NEGATE_EXPR, sizetype,
>   bias);

This is shared with OpenMP and must be conditionalized for OpenACC only.

Jakub

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v4]

[Nick Clifton]

Hi Ian,

>>> Shouldn't we make it fool-proof by instead introducing a 
>>> DMGL_NO_RECURSION_LIMIT

> You don't need my blessing--I wrote that code ages ago--but I agree
> with Richard that in practice it's OK to limit recursion depth by
> default.  Real symbols have very limited recursion requirements.

OK then, here is a fourth revision of the patch.

In this version:

  * The demangler option has been renamed to DMGHL_NO_RECURSE_LIMIT
and if the option is not present then the limit is enforced.

  * I also found another PR that is fixed by the patch, although I had
to make sure that the affected code could handle NULL pointers 
properly afterwards.

  OK to apply ?

Cheers
  Nick


include/ChangeLog
2018-11-29  Nick Clifton  

* demangle.h (DMGL_NO_RECURSE_LIMIT): Define.
(DEMANGLE_RECURSION_LIMIT): Define

libiberty/ChangeLog
2018-11-29  Nick Clifton  

PR 87681
PR 87675
PR 87636
PR 87350
PR 87335
* cp-demangle.h (struct d_info): Add recursion_level field.
* cp-demangle.c (d_function_type): Add recursion counter.
If the recursion limit is reached and the check is not disabled,
then return with a failure result.
(cplus_demangle_init_info): Initialise the recursion_level field.
(d_demangle_callback): If the recursion limit is enabled, check
for a mangled string that is so long that there is not enough
stack space for the local arrays.
* cplus-dem.c (struct work): Add recursion_level field.
(squangle_mop_up): Set the numb and numk fields to zero.
(work_stuff_copy_to_from): Handle the case where a btypevec or 
ktypevec field is NULL.
(demangle_nested_args): Add recursion counter.  If
the recursion limit is not disabled and reached, return with a
failure result.
Index: include/demangle.h
===
--- include/demangle.h	(revision 266771)
+++ include/demangle.h	(working copy)
@@ -68,6 +68,17 @@
 /* If none of these are set, use 'current_demangling_style' as the default. */
 #define DMGL_STYLE_MASK (DMGL_AUTO|DMGL_GNU|DMGL_LUCID|DMGL_ARM|DMGL_HP|DMGL_EDG|DMGL_GNU_V3|DMGL_JAVA|DMGL_GNAT|DMGL_DLANG|DMGL_RUST)
 
+/* Disable a limit on the depth of recursion in mangled strings.
+   Note if this limit is disabled then stack exhaustion is possible when
+   demangling pathologically complicated strings.  Bug reports about stack
+   exhaustion when the option is enabled will be rejected.  */  
+#define DMGL_NO_RECURSE_LIMIT (1 << 18)	
+
+/* If DMGL_NO_RECURE_LIMIT is not enabled, then this is the value used as
+   the maximum depth of recursion allowed.  It should be enough for any
+   real-world mangled name.  */
+#define DEMANGLE_RECURSION_LIMIT 1024
+  
 /* Enumeration of possible demangling styles.
 
Lucid and ARM styles are still kept logically distinct, even though
Index: libiberty/cp-demangle.c
===
--- libiberty/cp-demangle.c	(revision 266771)
+++ libiberty/cp-demangle.c	(working copy)
@@ -2852,21 +2852,35 @@
 static struct demangle_component *
 d_function_type (struct d_info *di)
 {
-  struct demangle_component *ret;
+  struct demangle_component *ret = NULL;
 
-  if (! d_check_char (di, 'F'))
-return NULL;
-  if (d_peek_char (di) == 'Y')
+  if ((di->options & DMGL_NO_RECURSE_LIMIT) == 0)
 {
-  /* Function has C linkage.  We don't print this information.
-	 FIXME: We should print it in verbose mode.  */
-  d_advance (di, 1);
+  if (di->recursion_level > DEMANGLE_RECURSION_LIMIT)
+	/* FIXME: There ought to be a way to report
+	   that the recursion limit has been reached.  */
+	return NULL;
+
+  di->recursion_level ++;
 }
-  ret = d_bare_function_type (di, 1);
-  ret = d_ref_qualifier (di, ret);
 
-  if (! d_check_char (di, 'E'))
-return NULL;
+  if (d_check_char (di, 'F'))
+{
+  if (d_peek_char (di) == 'Y')
+	{
+	  /* Function has C linkage.  We don't print this information.
+	 FIXME: We should print it in verbose mode.  */
+	  d_advance (di, 1);
+	}
+  ret = d_bare_function_type (di, 1);
+  ret = d_ref_qualifier (di, ret);
+  
+  if (! d_check_char (di, 'E'))
+	ret = NULL;
+}
+
+  if ((di->options & DMGL_NO_RECURSE_LIMIT) == 0)
+di->recursion_level --;
   return ret;
 }
 
@@ -6203,6 +6217,7 @@
   di->expansion = 0;
   di->is_expression = 0;
   di->is_conversion = 0;
+  di->recursion_level = 0;
 }
 
 /* Internal implementation for the demangler.  If MANGLED is a g++ v3 ABI
@@ -6242,6 +6257,20 @@
 
   cplus_demangle_init_info (mangled, options, strlen (mangled), );
 
+  /* PR 87675 - Check for a mangled string that is so long
+ that we do not have enough stack space to demangle it.  */
+  if (((options & DMGL_NO_RECURSE_LIMIT) == 0)
+  /* This check is a bit arbitrary, since what we really want to do is to
+	 compare the sizes 

Re: [patch,openacc] Propagate independent clause for OpenACC kernels pass

[Richard Biener]

On Tue, 4 Dec 2018, Jakub Jelinek wrote:

> On Mon, Dec 03, 2018 at 11:40:39PM +, Julian Brown wrote:
> > Jakub asked in the following email at the time of the patch submission
> > for the gomp4 branch what the difference was between the new
> > marked_independent flag and safelen == INT_MAX:
> > 
> >   https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01100.html
> > 
> > If I understand the followup correctly,
> > 
> >   https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01117.html
> > 
> > a setting of safelen > 1 means that up to that number of loop
> > iterations can run together in lockstep (as if each insn in the loop
> > was blindly rewritten to a safelen-width SIMD equivalent) -- but
> > anything that happens in iteration N + 1 cannot happen before something
> > that happens in iteration N. Chung-Lin pointed out that OpenACC's
> > semantics are even less strict (allowing iterations to proceed fully
> > independently in an arbitrary order), so the marked_independent flag
> > does carry non-redundant information -- even with safelen set to
> > INT_MAX.
> 
> OpenMP 5 (not implemented in GCC 9 though) has order(concurrent) clause
> for this (no cross-iteration dependencies at all, iterations can be run in
> any order, in parallel etc.).
> 
> I believe it matches the can_be_parallel flag we now have, but I remember
> there were some issues with that flag for use in DO CONCURRENT.
> 
> Or do we want to have some other flag for really independent iterations?
> What passes could use that?  Would the vectorizer appreciate the stronger
> assertion in some cases?

The vectorizer doesn't really care.  It would be autopar that should.
The issue with using can_be_parallel for DO CONCURRENT was that the
middle-end introduces non-trivial sharing between iterations, introducing
dependences that then make the loop no longer can_be_parallel.  I
believe similar things could happen with ->safelen (consider loop
reversal and existing forward dependences).  I guess we're simply
lucky in that area ;)

Richard.

Re: [patch,openacc] Set safelen to INT_MAX for oacc independent pragma

[Jakub Jelinek]

On Thu, Sep 20, 2018 at 11:21:28AM -0700, Cesar Philippidis wrote:
> This is another old gomp4 OpenACC patch which impacts targets that use
> simd vectorization, such as the host and AMD GCN, rather than nvptx.
> Basically, as the subject states, it sets safelen to INT_MAX for
> independent acc loops, which I believe is already being done for OpenMP
> in certain situations.
> 
> The original discussion for this patch can be found here
> .
> 
> Is this patch OK for trunk? I bootstrapped and regtested it for x86_64
> Linux with nvptx offloading.
> 
> Thanks,
> Cesar

> [OpenACC] Set safelen to INT_MAX for oacc independent pragma
> 
> 2018-XX-YY  Tom de Vries  
>   Cesar Philippidis  
> 
>   gcc/
>   * omp-expand.c (expand_omp_for): Set loop->safelen to INT_MAX if
>   marked_independent.

This change is ok once the marked_independent vs. can_be_parallel etc. is
resolved.

> (cherry picked from gomp-4_0-branch r226079)
> ---
>  gcc/omp-expand.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
> index 427f329d35f..ee147f10826 100644
> --- a/gcc/omp-expand.c
> +++ b/gcc/omp-expand.c
> @@ -5718,6 +5718,7 @@ expand_omp_for (struct omp_region *region, gimple 
> *inner_stmt)
>   {
> struct loop *loop = region->cont->loop_father;
> loop->marked_independent = true;
> +   loop->safelen = INT_MAX;
>   }
>  }
>else if (gimple_omp_for_kind (fd.for_stmt) & GF_OMP_FOR_SIMD)
> -- 
> 2.17.1
> 


Jakub

Re: [patch] Add OpenACC Fortran support for deviceptr and variable in common blocks

[Chung-Lin Tang]

On 2018/12/4 9:30 PM, Jakub Jelinek wrote:

  && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
-  OMP_MAP_TOFROM))
+  OMP_MAP_TOFROM, openacc))

Why?  OpenMP doesn't have a copy clause, so I'd expect true here.


I guess Cesar was just being specific to OpenACC behavior.


continue;
  if (mask & OMP_CLAUSE_COPYIN)
{
@@ -1047,7 +1048,7 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const 
omp_mask mask,
{
  if (gfc_match ("copyin ( ") == MATCH_YES
  && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
-  OMP_MAP_TO))
+  OMP_MAP_TO, true))
continue;

OpenMP does have a copyin clause, but it is handled below, so this one is ok.


@@ -1156,12 +1157,12 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const 
omp_mask mask,
  && openacc
  && gfc_match ("device ( ") == MATCH_YES
  && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
-  OMP_MAP_FORCE_TO))
+  OMP_MAP_FORCE_TO, false))
continue;
  if ((mask & OMP_CLAUSE_DEVICEPTR)
  && gfc_match ("deviceptr ( ") == MATCH_YES
  && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
-  OMP_MAP_FORCE_DEVICEPTR))
+  OMP_MAP_FORCE_DEVICEPTR, false))
continue;

Not sure about these, your call.  deviceptr is OpenACC specific clause,
device is in both, but means something different in OpenMP.  In any case,
haven't looked if OpenACC allows common blocks in these clauses.


Common block support and the deviceptr changes were originally separate patches.

Also, I think above changes probably could be greatly shortened if a C++ default
argument were used for gfc_match_omp_map_clause().


@@ -3718,8 +3719,8 @@ resolve_positive_int_expr (gfc_expr *expr, const char 
*clause)
if (expr->expr_type == EXPR_CONSTANT
&& expr->ts.type == BT_INTEGER
&& mpz_sgn (expr->value.integer) <= 0)
-gfc_warning (0, "INTEGER expression of %s clause at %L must be positive",
-clause, >where);
+gfc_error ("INTEGER expression of %s clause at %L must be positive",
+  clause, >where);
  }

This affects OpenMP too and makes it inconsistent with C/C++.  Why?
If you need it for OpenACC clauses, then we need two routines.


We'll update this.


--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -105,6 +105,9 @@ enum gimplify_omp_var_data
/* Flag for GOVD_MAP: must be present already.  */
GOVD_MAP_FORCE_PRESENT = 524288,
  
+  /* Flag for OpenACC deviceptrs.  */

+  GOVD_DEVICEPTR = (1<<21),

Please use the same style of constants as in the rest (and, you need
to adjust anyway for current trunk).


This will be updated too.

Thanks,
Chung-Lin

Re: [testsuite] Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039)

[Rainer Orth]

Hi Iain,

> On Sat, 1 Dec 2018 at 19:28, Iain Buclaw  wrote:
>>
>> On Thu, 29 Nov 2018 at 15:12, Rainer Orth  
>> wrote:
>> >
>> > Hi Iain,
>> >
>> > > On Tue, 27 Nov 2018 at 20:32, Rainer Orth
>> > >  wrote:
>> > >>
>> > >> Hi Mike,
>> > >>
>> > >> > On Nov 27, 2018, at 2:18 AM, Rainer Orth 
>> > >> > 
>> > >> > wrote:
>> > >> >>
>> > >> >> Some assemblers, including the Solaris one, don't support UTF-8
>> > >> >> identifiers, which breaks the gdc.test/compilable/ddoc12.d testcase 
>> > >> >> as
>> > >> >> reported in the PR.
>> > >> >
>> > >> > So, another style of fix, would be to change the binding from the
>> > >> > language
>> > >> > front-end to encode unsupported symbols using a fixed, documented, abi
>> > >> > defined technique.
>> > >>
>> > >> there's been some discussion on this in the PR.  Joseph's suggestion was
>> > >> to follow the system compilers if this were done, and indeed they do
>> > >> encode UTF-8 identifiers in some way which could either be
>> > >> reverse-engineered or a spec obtained.  However, given Iain's stance
>> > >> towards UTF-8 identifiers in D, I very much doubt this is worth the
>> > >> effort.  Ultimately, it's his call, of course.
>> > >>
>> > >
>> > > Not only my stance, but as a whole just how those maintaining the core
>> > > language generally agree on. Encoding UTF8 characters in symbols is
>> > > not part of the D ABI, so that is something that needs convincing
>> > > upstream.
>> > >
>> > > There is a third way however, all compilable/ddoc* tests don't
>> > > actually require us to compile the module all the way down to object
>> > > code, the only thing that really needs to be tested is the Ddoc
>> > > generator itself.  Which would be setting 'dg-do-what compile' and
>> > > build with the compiler option -fdoc, then dg-final checks for the
>> > > presence of the file ddoc12.html is the minimum that needs to be done
>> > > for these tests to be considered passed.
>> > >
>> > > I'll have a look into doing it that way tomorrow.
>> >
>> > that would be even better of course, also saving some testing time.
>> >
>>
>> Hi Rainer,
>>
>> Attached patch for it, I've checked that and it does the right thing
>> and passes on x86_64.
>>
>> There's a couple more changes than just testsuite files, as compiling
>> with -fdoc unearthed bug fixes not backported from the D version of
>> the compiler.  These I'll apply separately.
>>
>
> D2 front-end and testsuite changes have been upstreamed/downstreamed.
> If there's no complaint, I'll apply the dejagnu fix as well.

not at all: I've checked it on i386-pc-solaris2.11/gas and
sparc-sun-solaris2.12/as and compilable/ddoc12.d now PASSes on both, so
the gdc-test.exp part is ok.  Please mention PR d/88039 in the
ChangeLog.

Thanks.
Rainer

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

Re: [patch,openacc] Propagate independent clause for OpenACC kernels pass

[Jakub Jelinek]

On Thu, Sep 20, 2018 at 11:06:40AM -0700, Cesar Philippidis wrote:
> 2018-XX-YY  Chung-Lin Tang 
>   Cesar Philippidis  
> 
>   gcc/
>   * cfgloop.h (struct loop): Add 'bool marked_independent' field.
>   * omp-expand.c (struct omp_region): Add 'int kind' and
>   'bool independent' fields.
>   (expand_omp_for): Set 'marked_independent' field for loop
>   corresponding to region.
>   (find_omp_for_region_data): New function.
>   (build_omp_regions_1): Set kind field.  Call
>   find_omp_for_region_data for GIMPLE_OMP_FOR statements.

In addition to what I've just mentioned in another mail:

> --- a/gcc/omp-expand.c
> +++ b/gcc/omp-expand.c
> @@ -107,6 +107,12 @@ struct omp_region
>  
>/* True if this is nested inside an OpenACC kernels construct.  */
>bool inside_kernels_p;
> +
> +  /* Records a generic kind field.  */
> +  int kind;
> +
> +  /* For an OpenACC loop directive, true if has the 'independent' clause.  */
> +  bool independent;
>  };

I'm not sure why you need kind cached, you can get from the region at the
stmt and from there at the kind easily.  And even if it would be a good idea
to cache it, you don't want to mix bool and non-bool members in the
structure to avoid padding gaps.

Jakub

Re: [patch,openacc] Propagate independent clause for OpenACC kernels pass

[Jakub Jelinek]

On Mon, Dec 03, 2018 at 11:40:39PM +, Julian Brown wrote:
> Jakub asked in the following email at the time of the patch submission
> for the gomp4 branch what the difference was between the new
> marked_independent flag and safelen == INT_MAX:
> 
>   https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01100.html
> 
> If I understand the followup correctly,
> 
>   https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01117.html
> 
> a setting of safelen > 1 means that up to that number of loop
> iterations can run together in lockstep (as if each insn in the loop
> was blindly rewritten to a safelen-width SIMD equivalent) -- but
> anything that happens in iteration N + 1 cannot happen before something
> that happens in iteration N. Chung-Lin pointed out that OpenACC's
> semantics are even less strict (allowing iterations to proceed fully
> independently in an arbitrary order), so the marked_independent flag
> does carry non-redundant information -- even with safelen set to
> INT_MAX.

OpenMP 5 (not implemented in GCC 9 though) has order(concurrent) clause
for this (no cross-iteration dependencies at all, iterations can be run in
any order, in parallel etc.).

I believe it matches the can_be_parallel flag we now have, but I remember
there were some issues with that flag for use in DO CONCURRENT.

Or do we want to have some other flag for really independent iterations?
What passes could use that?  Would the vectorizer appreciate the stronger
assertion in some cases?

Jakub

Re: [PATCH][OpenACC] Update deviceptr handling during gimplification

[Jakub Jelinek]

On Tue, Aug 07, 2018 at 03:09:38PM -0700, Cesar Philippidis wrote:
> I had previously posted this patch as part of a monster deviceptr patch
> here . This
> patch breaks out the generic gimplifier changes. Essentially, with this
> patch, the gimplifier will now transfer deviceptr data clauses using
> GOMP_MAP_FORCE_DEVICEPTR.
> 
> Is this patch OK for trunk? It bootstrapped / regression tested cleanly
> for x86_64 with nvptx offloading.

See my comments on the monster deviceptr patch.
> 
> 2018-XX-YY  Cesar Philippidis  
> 
>   gcc/fortran/
>   * trans-openmp.c (gfc_omp_finish_clause): Don't create pointer data
>   mappings for deviceptr clauses.
>   (gfc_trans_omp_clauses): Likewise.
>   gcc/
>   * gimplify.c (enum gimplify_omp_var_data): Add GOVD_DEVICETPR.
>   (omp_notice_variable): Add GOVD_DEVICEPTR attribute when appropriate.
>   (gimplify_scan_omp_clauses): Likewise.
>   (gimplify_adjust_omp_clauses_1): Set GOMP_MAP_FORCE_DEVICEPTR for
>   implicit deviceptr mappings.
>   gcc/testsuite/
>   * c-c++-common/goacc/deviceptr-4.c: Update expected data mapping.

Jakub

Re: [PATCH] Fix predict-22.c testcase (PR tree-optimization/88285)

[Jeff Law]

On 12/4/18 5:11 AM, Jakub Jelinek wrote:
> Hi!
> 
> All uses of explicit -freorder-blocks-and-partition needs to be guarded with
> freorder effective targets, e.g. arm doesn't support -fprofile-use.
> 
> That said, until PR88310 is fixed, this effectively means the test is
> UNSUPPORTED anywhere.
> 
> Ok for trunk anyway?
> 
> 2018-12-04  Jakub Jelinek  
> 
>   PR tree-optimization/88285
>   * gcc.dg/predict-22.c: Only compile on freorder targets.
OK
jeff

Re: [patch,openacc] Generate sequential loop for OpenACC loop directive inside kernels

[Jakub Jelinek]

On Thu, Sep 20, 2018 at 11:57:50AM -0700, Cesar Philippidis wrote:
> 2018-XX-YY  Cesar Philippidis  
> 
>   * omp-low.c (install_var_field): New base_pointer_restrict
>   argument.
>   (scan_sharing_clauses): Update call to install_var_field.
>   (omp_target_base_pointers_restrict_p): New function.
>   (scan_omp_target): Update call to install_var_field.
> ---
>  gcc/omp-low.c | 89 +++
>  1 file changed, 83 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
> index 24685fd012c..a59c15ae5fd 100644
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -642,7 +642,8 @@ build_sender_ref (tree var, omp_context *ctx)
> BASE_POINTERS_RESTRICT, declare the field with restrict.  */
>  
>  static void
> -install_var_field (tree var, bool by_ref, int mask, omp_context *ctx)
> +install_var_field (tree var, bool by_ref, int mask, omp_context *ctx,
> +bool base_pointers_restrict = false)

Can this be a bool in omp_context that you just initialize early, so that it
isn't passed all around?

> @@ -987,10 +992,12 @@ fixup_child_record_type (omp_context *ctx)
>  }
>  
>  /* Instantiate decls as necessary in CTX to satisfy the data sharing
> -   specified by CLAUSES.  */
> +   specified by CLAUSES.  If BASE_POINTERS_RESTRICT, install var field with
> +   restrict.  */
>  
>  static void
> -scan_sharing_clauses (tree clauses, omp_context *ctx)
> +scan_sharing_clauses (tree clauses, omp_context *ctx,
> +   bool base_pointers_restrict = false)

And here etc.

Jakub

Re: [patch] Add OpenACC Fortran support for deviceptr and variable in common blocks

[Jakub Jelinek]

On Fri, Jun 29, 2018 at 12:04:58PM -0700, Cesar Philippidis wrote:
> 2018-06-29  Cesar Philippidis  
>   James Norris  
> 
>   gcc/fortran/
>   * openmp.c (gfc_match_omp_map_clause): Re-write handling of the
>   deviceptr clause.  Add new common_blocks argument.  Propagate it to
>   gfc_match_omp_variable_list.
>   (gfc_match_omp_clauses): Update calls to gfc_match_omp_map_clauses.
>   (resolve_positive_int_expr): Promote the warning to an error.
>   (check_array_not_assumed): Remove pointer check.
>   (resolve_oacc_nested_loops): Error on do concurrent loops.
>   * trans-openmp.c (gfc_omp_finish_clause): Don't create pointer data
>   mappings for deviceptr clauses.
>   (gfc_trans_omp_clauses): Likewise.
> 
>   gcc/
>   * gimplify.c (enum gimplify_omp_var_data): Add GOVD_DEVICETPR.
>   (oacc_default_clause): Privatize fortran common blocks.
>   (omp_notice_variable): Add GOVD_DEVICEPTR attribute when appropriate.
>   Defer the expansion of DECL_VALUE_EXPR for common block decls.
>   (gimplify_scan_omp_clauses): Add GOVD_DEVICEPTR attribute when
>   appropriate.
>   (gimplify_adjust_omp_clauses_1): Set GOMP_MAP_FORCE_DEVICEPTR for
>   implicit deviceptr mappings.
> 
>   gcc/testsuite/
>   * c-c++-common/goacc/deviceptr-4.c: Update.
>   * gfortran.dg/goacc/common-block-1.f90: New test.
>   * gfortran.dg/goacc/common-block-2.f90: New test.
>   * gfortran.dg/goacc/loop-2.f95: Update.
>   * gfortran.dg/goacc/loop-3-2.f95: Update.
>   * gfortran.dg/goacc/loop-3.f95: Update.
>   * gfortran.dg/goacc/loop-5.f95: Update.
>   * gfortran.dg/goacc/pr72715.f90: New test.
>   * gfortran.dg/goacc/sie.f95: Update.
>   * gfortran.dg/goacc/tile-1.f90: Update.
>   * gfortran.dg/gomp/pr77516.f90: Update.
> 
>   libgomp/
>   * oacc-parallel.c (GOACC_parallel_keyed): Handle Fortran deviceptr
>   clause.
>   (GOACC_data_start): Likewise.
>   * testsuite/libgomp.oacc-fortran/common-block-1.f90: New test.
>   * testsuite/libgomp.oacc-fortran/common-block-2.f90: New test.
>   * testsuite/libgomp.oacc-fortran/common-block-3.f90: New test.
>   * testsuite/libgomp.oacc-fortran/deviceptr-1.f90: New test.
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -914,10 +914,11 @@ omp_inv_mask::omp_inv_mask (const omp_mask ) : 
> omp_mask (m)
> mapping.  */
>  
>  static bool
> -gfc_match_omp_map_clause (gfc_omp_namelist **list, gfc_omp_map_op map_op)
> +gfc_match_omp_map_clause (gfc_omp_namelist **list, gfc_omp_map_op map_op,
> +   bool common_blocks)
>  {
>gfc_omp_namelist **head = NULL;
> -  if (gfc_match_omp_variable_list ("", list, false, NULL, , true)
> +  if (gfc_match_omp_variable_list ("", list, common_blocks, NULL, , 
> true)
>== MATCH_YES)
>  {
>gfc_omp_namelist *n;
> @@ -1039,7 +1040,7 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const 
> omp_mask mask,
> if ((mask & OMP_CLAUSE_COPY)
> && gfc_match ("copy ( ") == MATCH_YES
> && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
> -OMP_MAP_TOFROM))
> +OMP_MAP_TOFROM, openacc))

Why?  OpenMP doesn't have a copy clause, so I'd expect true here.

>   continue;
> if (mask & OMP_CLAUSE_COPYIN)
>   {
> @@ -1047,7 +1048,7 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const 
> omp_mask mask,
>   {
> if (gfc_match ("copyin ( ") == MATCH_YES
> && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
> -OMP_MAP_TO))
> +OMP_MAP_TO, true))
>   continue;

OpenMP does have a copyin clause, but it is handled below, so this one is ok.

> @@ -1156,12 +1157,12 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const 
> omp_mask mask,
> && openacc
> && gfc_match ("device ( ") == MATCH_YES
> && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
> -OMP_MAP_FORCE_TO))
> +OMP_MAP_FORCE_TO, false))
>   continue;
> if ((mask & OMP_CLAUSE_DEVICEPTR)
> && gfc_match ("deviceptr ( ") == MATCH_YES
> && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
> -OMP_MAP_FORCE_DEVICEPTR))
> +OMP_MAP_FORCE_DEVICEPTR, false))
>   continue;

Not sure about these, your call.  deviceptr is OpenACC specific clause,
device is in both, but means something different in OpenMP.  In any case,
haven't looked if OpenACC allows common blocks in these clauses.

> @@ -3718,8 +3719,8 @@ resolve_positive_int_expr (gfc_expr *expr, const char 
> *clause)
>if (expr->expr_type == EXPR_CONSTANT
>

Re: [PING v2][PATCH] Make function clone name numbering independent.

[Michael Ploujnikov]

On 2018-12-04 7:48 a.m., Martin Jambor wrote:
> Hi,
> 
> On Tue, Sep 04 2018, Michael Ploujnikov wrote:
>>
>> I've tried building with numbered_clone_function_name replaced by
>> suffixed_function_name and with --enable-offload-targets=hsa and
>> didn't see any errors in gomp.exp. I don't have a readily available
>> HSA setup so if you could do a quick test, I would really appreciate
>> it!
> 
> Sorry it took so long, I have run regular tests on trunk today and your
> patch does not appear to have caused any issues.
> 
> Martin
> 

Thank you for checking.

- Michael



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Fix P0634R3 - Down with typename! testsuite fallout

[Marek Polacek]

On Tue, Dec 04, 2018 at 09:42:51AM +0100, Jakub Jelinek wrote:
> Hi!
> 
> I've noticed these two tests now FAIL with -std=c++2a, they don't print
> any diagnostics.  As I believe that was the point of the P0634R3 changes,
> this patch adjusts the testcases.  Tested on x86_64-linux, ok for trunk?
> 
> 2018-12-04  Jakub Jelinek  
> 
>   * g++.old-deja/g++.oliva/typename1.C: Don't expect any diagnostics
>   for C++2a.
>   * g++.old-deja/g++.oliva/typename2.C: Likewise.

The patch is fine, sorry for missing that.  Apparently I only ran c++2a
with dg.exp.

Marek

Re: [PATCH] Fix PR88301

[Richard Biener]

On Tue, 4 Dec 2018, Christophe Lyon wrote:

> Hi Richard,
> On Mon, 3 Dec 2018 at 14:37, Richard Biener  wrote:
> >
> >
> > This fixes a missed optimization in EVRP by teaching the code
> > figuring out conditional asserts about conversions that preserve
> > the converted value.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
> > sofar.
> >
> > Richard.
> >
> > 2018-12-03  Richard Biener  
> >
> > PR tree-optimization/88301
> > * tree-vrp.c (register_edge_assert_for_2): Handle conversions
> > that do not change the value by registering the same assert
> > for the operand.
> >
> > * gcc.dg/tree-ssa/evrp13.c: New testcase.
> >
> 
> I noticed a regression in g++ on aarch64, and git bisect indicates
> this commits is the culprit.
> g++.dg/warn/Wstringop-overflow-1.C  -std=c++14  (test for warnings, line 
> 14)
> g++.dg/warn/Wstringop-overflow-1.C  -std=c++14 (test for excess errors)
> g++.dg/warn/Wstringop-overflow-1.C  -std=c++17  (test for warnings, line 
> 14)
> g++.dg/warn/Wstringop-overflow-1.C  -std=c++17 (test for excess errors)
> g++.dg/warn/Wstringop-overflow-1.C  -std=c++98  (test for warnings, line 
> 14)
> g++.dg/warn/Wstringop-overflow-1.C  -std=c++98 (test for excess errors)
> 
> g++.log says:
> Excess errors:
> /gcc/testsuite/g++.dg/warn/Wstringop-overflow-1.C:14:21: warning:
> 'char* __builtin_strncpy(char*, const char*, long unsigned int)'
> writing between 6 and 2147483647 bytes into a region of size 5
> overflows the destination [-Wstringop-overflow=]

Yes, sorry.  r266773 should have fixed this.

Richard.

[PATCH][RFC] Poison bitmap_head->obstack

[Richard Biener]

This tries to make bugs like that in PR88317 harder to create by
introducing a bitmap_release function that can be used as
pendant to bitmap_initialize for non-allocated bitmap heads.
The function makes sure to poison the bitmaps obstack member
so the obstack the bitmap was initialized with can be safely
released.

The patch also adds a default constructor to bitmap_head
doing the same, but for C++ reason initializes to a
all-zero bitmap_obstack rather than 0xdeadbeef because
the latter isn't possible in constexpr context (it is
by using unions but then things start to look even more ugly).

The stage1 compiler might end up with a few extra runtime
initializers but constexpr makes sure they'll vanish for
later stages.

I had to paper over that you-may-not-use-memset-to-zero classes
with non-trivial constructors warning in two places and I
had to teach gengtype about CONSTEXPR (probably did so in
an awkward way - suggestions and pointers into gengtype
appreciated).

Bootstrapped (with host GCC 4.8) on x86_64-unknown-linux-gnu,
testing in progress.

The LRA issue seems to be rare enough (on x86_64...) that
I didn't trip over it sofar.

Comments?  Do we want this?  Not sure how we can easily
discover all bitmap_clear () users that should really
use bitmap_release (suggestion for a better name appreciated
as well - I thought about bitmap_uninitialize)

Richard.

2018-12-04  Richard Biener  

* bitmap.c (bitmap_head::crashme): Define.
* bitmap.h (bitmap_head): Add constexpr default constructor
poisoning the obstack member.
(bitmap_head::crashme): Declare.
(bitmap_release): New function clearing a bitmap and poisoning
the obstack member.
* gengtype.c (main): Make it recognize CONSTEXPR.

* lra-constraints.c (lra_inheritance): Use bitmap_release
instead of bitmap_clear.

* ira.c (ira): Work around warning.
* regrename.c (create_new_chain): Likewise.

Index: gcc/bitmap.c
===
--- gcc/bitmap.c(revision 266772)
+++ gcc/bitmap.c(working copy)
@@ -26,6 +26,10 @@ along with GCC; see the file COPYING3.
 /* Memory allocation statistics purpose instance.  */
 mem_alloc_description bitmap_mem_desc;
 
+/* Static zero-initialized bitmap obstack used for default initialization
+   of bitmap_head.  */
+bitmap_obstack bitmap_head::crashme;
+
 static bitmap_element *bitmap_tree_listify_from (bitmap, bitmap_element *);
 
 /* Register new bitmap.  */
Index: gcc/bitmap.h
===
--- gcc/bitmap.h(revision 266772)
+++ gcc/bitmap.h(working copy)
@@ -323,6 +323,12 @@ struct GTY((chain_next ("%h.next"), chai
already pointed to by the chain started by first, so GTY((skip)) it.  */
 
 struct GTY(()) bitmap_head {
+  static bitmap_obstack crashme;
+  /* Poison obstack to not make it not a valid initialized GC bitmap.  */
+  CONSTEXPR bitmap_head()
+: indx(0), tree_form(false), first(NULL), current(NULL),
+  obstack ()
+  {}
   /* Index of last element looked at.  */
   unsigned int indx;
   /* False if the bitmap is in list form; true if the bitmap is in tree form.
@@ -441,6 +446,18 @@ bitmap_initialize (bitmap head, bitmap_o
 bitmap_register (head PASS_MEM_STAT);
 }
 
+/* Release a bitmap (but not its head).  This is suitable for pairing with
+   bitmap_initialize.  */
+
+static inline void
+bitmap_release (bitmap head)
+{
+  bitmap_clear (head);
+  /* Poison the obstack pointer so the obstack can be safely released.
+ Do not zero it as the bitmap then becomes initialized GC.  */
+  head->obstack = (bitmap_obstack *)0xdeadbeef;
+}
+
 /* Allocate and free bitmaps from obstack, malloc and gc'd memory.  */
 extern bitmap bitmap_alloc (bitmap_obstack *obstack CXX_MEM_STAT_INFO);
 #define BITMAP_ALLOC bitmap_alloc
Index: gcc/gengtype.c
===
--- gcc/gengtype.c  (revision 266772)
+++ gcc/gengtype.c  (working copy)
@@ -5205,6 +5205,7 @@ main (int argc, char **argv)
   POS_HERE (do_scalar_typedef ("void", ));
   POS_HERE (do_scalar_typedef ("machine_mode", ));
   POS_HERE (do_scalar_typedef ("fixed_size_mode", ));
+  POS_HERE (do_scalar_typedef ("CONSTEXPR", ));
   POS_HERE (do_typedef ("PTR", 
create_pointer (resolve_typedef ("void", )),
));
Index: gcc/ira.c
===
--- gcc/ira.c   (revision 266772)
+++ gcc/ira.c   (working copy)
@@ -5417,7 +5417,7 @@ ira (FILE *f)
= ((struct ira_spilled_reg_stack_slot *)
   ira_allocate (max_regno
 * sizeof (struct ira_spilled_reg_stack_slot)));
- memset (ira_spilled_reg_stack_slots, 0,
+ memset ((void *)ira_spilled_reg_stack_slots, 0,
  max_regno * sizeof (struct 

Re: [PATCH] Fix PR88301

[Christophe Lyon]

Hi Richard,
On Mon, 3 Dec 2018 at 14:37, Richard Biener  wrote:
>
>
> This fixes a missed optimization in EVRP by teaching the code
> figuring out conditional asserts about conversions that preserve
> the converted value.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
> sofar.
>
> Richard.
>
> 2018-12-03  Richard Biener  
>
> PR tree-optimization/88301
> * tree-vrp.c (register_edge_assert_for_2): Handle conversions
> that do not change the value by registering the same assert
> for the operand.
>
> * gcc.dg/tree-ssa/evrp13.c: New testcase.
>

I noticed a regression in g++ on aarch64, and git bisect indicates
this commits is the culprit.
g++.dg/warn/Wstringop-overflow-1.C  -std=c++14  (test for warnings, line 14)
g++.dg/warn/Wstringop-overflow-1.C  -std=c++14 (test for excess errors)
g++.dg/warn/Wstringop-overflow-1.C  -std=c++17  (test for warnings, line 14)
g++.dg/warn/Wstringop-overflow-1.C  -std=c++17 (test for excess errors)
g++.dg/warn/Wstringop-overflow-1.C  -std=c++98  (test for warnings, line 14)
g++.dg/warn/Wstringop-overflow-1.C  -std=c++98 (test for excess errors)

g++.log says:
Excess errors:
/gcc/testsuite/g++.dg/warn/Wstringop-overflow-1.C:14:21: warning:
'char* __builtin_strncpy(char*, const char*, long unsigned int)'
writing between 6 and 2147483647 bytes into a region of size 5
overflows the destination [-Wstringop-overflow=]

Christophe

> Index: gcc/tree-vrp.c
> ===
> --- gcc/tree-vrp.c  (revision 266733)
> +++ gcc/tree-vrp.c  (working copy)
> @@ -2966,6 +2966,23 @@ register_edge_assert_for_2 (tree name, e
> add_assert_info (asserts, name2, tmp, new_comp_code, new_val);
> }
>
> +  /* If we have a conversion that doesn't change the value of the source
> + simply register the same assert for it.  */
> +  if (CONVERT_EXPR_CODE_P (rhs_code))
> +   {
> + wide_int rmin, rmax;
> + tree rhs1 = gimple_assign_rhs1 (def_stmt);
> + if (INTEGRAL_TYPE_P (TREE_TYPE (rhs1))
> + && int_fits_type_p (val, TREE_TYPE (rhs1))
> + && ((TYPE_PRECISION (TREE_TYPE (name))
> +  > TYPE_PRECISION (TREE_TYPE (rhs1)))
> + || (get_range_info (rhs1, , ) == VR_RANGE
> + && wi::fits_to_tree_p (rmin, TREE_TYPE (name))
> + && wi::fits_to_tree_p (rmax, TREE_TYPE (name)
> +   add_assert_info (asserts, rhs1, rhs1,
> +comp_code, fold_convert (TREE_TYPE (rhs1), val));
> +   }
> +
>/* Add asserts for NAME cmp CST and NAME being defined as
>  NAME = NAME2 & CST2.
>
> Index: gcc/testsuite/gcc.dg/tree-ssa/evrp13.c
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/evrp13.c  (revision 0)
> +++ gcc/testsuite/gcc.dg/tree-ssa/evrp13.c  (working copy)
> @@ -0,0 +1,7 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-evrp" } */
> +
> +#define ADD_NW(A,B) (__extension__({ __typeof(A+B) R; 
> if(__builtin_add_overflow(A,B,)) __builtin_unreachable(); R ;}))
> +_Bool a_b2(unsigned A,  unsigned B) { return ADD_NW(A,B) >= B; }
> +
> +/* { dg-final { scan-tree-dump "return 1;" "evrp" } } */

Re: OpenACC 2.5 Profiling Interface

[Jakub Jelinek]

On Sun, Nov 11, 2018 at 10:31:42PM -0600, Thomas Schwinge wrote:
> On Tue, 28 Feb 2017 18:43:36 +0100, I wrote:
> > The 2.5 versions of the OpenACC standard added a new chapter "Profiling
> > Interface".
> 
> I'd like to get that into trunk.  It's not yet complete (that is, doesn't
> provide all the information specified), but it's very useful already, and
> the missing pieces can later be added incrementally.
> 
> Jakub, would you please especially review the non-OpenACC-specific
> changes here, including the libgomp ABI changes?
> 
> (Note that this patch doesn't apply on top of trunk.  I extracted it out
> of openacc-gcc-8-branch, plus additional changes, and it depends on a
> number of other pending patches.  Due to the many regions of code
> touched, there are a lot of "textual" conflicts when porting it to
> current trunk, but the "structure" will be the same.)

Seems rather expensive to me, especially with the dependence on
libbacktrace and the unconditional initialization of the profiling from the
library constructor.  Could e.g. libbacktrace or some libgomp plugin that is
linked against libbacktrace be dlopened only when apps ask for this stuff?

OpenMP 5 has a profiling API too (OMPT), there the rough plan for when it
will be implemented is that libgomp as the library will implement only the
absolute required minimum and perhaps have a variant library that is a
replacement for libgomp if more detailed instrumentation is needed.

Jakub

Re: [PATCH] Fix predict-22.c testcase (PR tree-optimization/88285)

[Richard Biener]

On Tue, 4 Dec 2018, Jakub Jelinek wrote:

> Hi!
> 
> All uses of explicit -freorder-blocks-and-partition needs to be guarded with
> freorder effective targets, e.g. arm doesn't support -fprofile-use.
> 
> That said, until PR88310 is fixed, this effectively means the test is
> UNSUPPORTED anywhere.
> 
> Ok for trunk anyway?

OK.

> 2018-12-04  Jakub Jelinek  
> 
>   PR tree-optimization/88285
>   * gcc.dg/predict-22.c: Only compile on freorder targets.
> 
> --- gcc/testsuite/gcc.dg/predict-22.c.jj  2018-12-02 13:33:16.616161656 
> +0100
> +++ gcc/testsuite/gcc.dg/predict-22.c 2018-12-04 13:05:34.455226623 +0100
> @@ -1,4 +1,4 @@
> -/* { dg-do compile } */
> +/* { dg-do compile { target freorder } } */
>  /* { dg-options "-O2 -fdump-tree-optimized-details-blocks 
> -fdump-rtl-bbpart-details-blocks -freorder-blocks-and-partition" } */
>  volatile int v;
>  void bar (void) __attribute__((leaf, cold));
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [patch] various OpenACC reduction enhancements - test cases

[Jakub Jelinek]

On Fri, Jun 29, 2018 at 11:23:21AM -0700, Cesar Philippidis wrote:
> Attached are the updated reductions tests cases. Again, these have been
> bootstrapped and regression tested cleanly for x86_64 with nvptx
> offloading. Is it OK for trunk?

If Thomas is ok with this, it is ok for trunk.

> 2018-06-29  Cesar Philippidis  
>   Nathan Sidwell  
> 
>   gcc/testsuite/
>   * c-c++-common/goacc/orphan-reductions-1.c: New test.
>   * c-c++-common/goacc/reduction-7.c: New test.
>   * c-c++-common/goacc/routine-4.c: Update.
>   * g++.dg/goacc/reductions-1.C: New test.
>   * gcc.dg/goacc/loop-processing-1.c: Update.
>   * gfortran.dg/goacc/orphan-reductions-1.f90: New test.
> 
>   libgomp/
>   * libgomp.oacc-c-c++-common/par-reduction-3.c: New test.
>   * libgomp.oacc-c-c++-common/reduction-cplx-flt-2.c: New test.
>   * libgomp.oacc-fortran/reduction-9.f90: New test.

Jakub

Re: [RFC][AArch64] Add support for system register based stack protector canary access

[Florian Weimer]

* Wilco Dijkstra:

>> For userland, I would like to eventually copy the OpenBSD approach for
>> architectures which have some form of PC-relative addressing: we can
>> have multiple random canaries in (RELRO) .rodata in sufficiently close
>> to the code that needs them (assuming that we have split .rodata).  At
>> least for x86-64, I expect this to be a small win.  It's also a slight
>> hardening improvement if the reference canary is not stored in writable
>> memory.
>
> On AArch64 hardware pointer signing already provides a free and more robust
> implementation of stack canaries, so we could change -fstack-protector to
> use that when pointer signing is enabled.

I expected to use both because not all AArch64 implementations support
pointer signing, and we'd use the stack protector to get some coverage
for the legacy implementations.

(I'm still waiting for a request to enable pointer signing in Fedora
rawhide, BTW.)

Thanks,
Florian

Re: [patch] various OpenACC reduction enhancements - FE changes

[Jakub Jelinek]

On Fri, Jun 29, 2018 at 11:22:00AM -0700, Cesar Philippidis wrote:
> 2018-06-29  Cesar Philippidis  
>   Nathan Sidwell  
> 
>   gcc/c/
>   * c-parser.c (c_parser_omp_variable_list): New c_omp_region_type
>   argument.  Use it to specialize handling of OMP_CLAUSE_REDUCTION for
>   OpenACC.
>   (c_parser_omp_clause_reduction): Update call to
>   c_parser_omp_variable_list.  Propage OpenACC errors as necessary.
>   (c_parser_oacc_all_clauses): Update call to
>   p_parser_omp_clause_reduction.
>   (c_parser_omp_all_clauses): Likewise.
>   * c-typeck.c (c_finish_omp_clauses): Emit an error on orphan OpenACC
>   gang reductions.
> 
>   gcc/cp/
>   * parser.c (cp_parser_omp_var_list_no_open):  New c_omp_region_type
>   argument.  Use it to specialize handling of OMP_CLAUSE_REDUCTION for
>   OpenACC.
>   (cp_parser_omp_clause_reduction): Update call to
>   cp_parser_omp_variable_list.  Propage OpenACC errors as necessary.
>   (cp_parser_oacc_all_clauses): Update call to
>   cp_parser_omp_clause_reduction.
>   (cp_parser_omp_all_clauses): Likewise.
>   * semantics.c (finish_omp_clauses): Emit an error on orphan OpenACC
>   gang reductions.
> 
>   gcc/fortran/
>   * openmp.c (resolve_oacc_loop_blocks): Emit an error on orphan OpenACC
>   gang reductions.
>   * trans-openmp.c (gfc_omp_clause_copy_ctor): Permit reductions.
> 
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 7a926285f3a..a6f453dae54 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -965,12 +965,13 @@ class token_pair
>  
>/* Like token_pair::require_close, except that tokens will be skipped
>   until the desired token is found.  An error message is still produced
> - if the next token is not as expected.  */
> + if the next token is not as expected, unless QUIET is set.  */
>  
> -  void skip_until_found_close (c_parser *parser) const
> +  void skip_until_found_close (c_parser *parser, bool quiet = false) const
>{
>  c_parser_skip_until_found (parser, traits_t::close_token_type,
> -traits_t::close_gmsgid, m_open_loc);
> +quiet ? NULL : traits_t::close_gmsgid,
> +m_open_loc);
>}

I don't like these changes, why do you need them?  C++ FE doesn't have such
changes either, and it is fine to diagnose missing ) even if there was some
earlier error.  All other spots which require matching parens do it the
same.  Please leave those out.

 static tree
   
-c_parser_omp_clause_reduction (c_parser *parser, tree list)
   
+c_parser_omp_clause_reduction (c_parser *parser, tree list,
   
+  enum c_omp_region_type ort)  
   

Note, the signature is now different, it is ok to replace is_omp argument
with enum c_omp_region_type if you wish.

>  {
>location_t clause_loc = c_parser_peek_token (parser)->location;
> +  bool seen_error = false;
> +
>matching_parens parens;
>if (parens.require_open (parser))
>  {
> @@ -12855,7 +12876,13 @@ c_parser_omp_clause_reduction (c_parser *parser, 
> tree list)
> tree nl, c;
>  
> nl = c_parser_omp_variable_list (parser, clause_loc,
> -OMP_CLAUSE_REDUCTION, list);
> +OMP_CLAUSE_REDUCTION, list, ort);
> +   if (c_parser_peek_token (parser)->type != CPP_CLOSE_PAREN)
> + {
> +   seen_error = true;
> +   goto cleanup;
> + }
> +
> for (c = nl; c != list; c = OMP_CLAUSE_CHAIN (c))
>   {
> tree d = OMP_CLAUSE_DECL (c), type;
> @@ -12891,7 +12918,8 @@ c_parser_omp_clause_reduction (c_parser *parser, tree 
> list)
>  
> list = nl;
>   }
> -  parens.skip_until_found_close (parser);
> +cleanup:
> +  parens.skip_until_found_close (parser, seen_error);
>  }
>return list;
>  }

And the above hunks as well.

> @@ -13998,7 +14026,7 @@ c_parser_oacc_all_clauses (c_parser *parser, 
> omp_clause_mask mask,
> c_name = "private";
> break;
>   case PRAGMA_OACC_CLAUSE_REDUCTION:
> -   clauses = c_parser_omp_clause_reduction (parser, clauses);
> +   clauses = c_parser_omp_clause_reduction (parser, clauses, C_ORT_ACC);
> c_name = "reduction";
> break;
>   case PRAGMA_OACC_CLAUSE_SEQ:
> @@ -14157,7 +14185,7 @@ c_parser_omp_all_clauses (c_parser *parser, 
> omp_clause_mask mask,
> c_name = "private";
> break;
>   case 

Re: [PING v2][PATCH] Make function clone name numbering independent.

[Martin Jambor]

Hi,

On Tue, Sep 04 2018, Michael Ploujnikov wrote:
>
> I've tried building with numbered_clone_function_name replaced by
> suffixed_function_name and with --enable-offload-targets=hsa and
> didn't see any errors in gomp.exp. I don't have a readily available
> HSA setup so if you could do a quick test, I would really appreciate
> it!

Sorry it took so long, I have run regular tests on trunk today and your
patch does not appear to have caused any issues.

Martin

*PING*^3 [C++ Patch] – PR C++/88114 - PATCH for destructor not generated for "virtual ~destructor() = default"

[Tobias Burnus]

On Wed, Nov 28, 2018 at 09:35:53PM +0100, Tobias Burnus wrote:
> On the 25th November 2018, schrieb Tobias Burnus wrote:
> > On 21 November 2018, Tobias Burnus wrote:
> > > Hello all,
> > > 
> > > if a class contains any 'virtual ... = 0', it's an abstract class
> > > and for an
> > > abstract class, the destructor not added to the vtable.
> > > 
> > > For a normal
> > >    virtual ~class() { }
> > > that's not a problem as the class::~class() destructor will be
> > > generated during
> > > the parsing of the function.
> > > 
> > > But for
> > >    virtual ~class() = default;
> > > the destructor will be generated via mark_used via the vtable.
> > > 
> > > 
> > > If one now declares a derived class and uses it, the class::~class()
> > > is generated
> > > in that translation unit.  Unless, #pragma interface/implementation
> > > is used.
> > > 
> > > In that case, the 'default' destructor will never be generated.
> > > 
> > > 
> > > The following code seems to work both for the big code and for the
> > > example;
> > > without '#pragma implementation', the destructor is not generated
> > > for the example,
> > > only with.
> > > 
> > > The patch survived boostrapping GCC with default languages on
> > > x86-64-gnu-linux
> > > and "make check-g++".*
> > > 
> > > [One probably could get rid of some of the conditions for generating
> > > the code,
> > > e.g. TREE_USED and DECL_DEFAULTED_FN are probably not both needed;
> > > one might
> > > want to set some additional DECL to the fn decl.]
> > > 
> > > Does the patch and the test case make sense? Or is something else/in
> > > addition
> > > needed?
> > > 
> > > Tobias
> > > 
> > > 
> > > *I do get the following failures on this CentOS6 system:
> > > 
> > > FAIL: g++.dg/pr83239.C  -std=gnu++98 (test for excess errors)
> > > Excess errors:
> > > cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned
> > > int)' specified size 18446744073709551608 exceeds maximum object
> > > size 9223372036854775807 [-Wstringop-overflow=]
> > > cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned
> > > int)' specified size 18446744073709551600 exceeds maximum object
> > > size 9223372036854775807 [-Wstringop-overflow=]
> > > 
> > > FAIL: g++.dg/tls/thread_local-order2.C  -std=c++14 execution test
> > > FAIL: g++.dg/tls/thread_local-order2.C  -std=c++17 execution test
> > > 
> > > plus each 32 times:
> > > FAIL: guality/guality.h: 0 PASS, 1 FAIL, 0 UNRESOLVED
> > > FAIL: guality/guality.h: varl is -1, not 6

Re: [patch] various OpenACC reduction enhancements - ME and nvptx changes

[Jakub Jelinek]

On Fri, Jun 29, 2018 at 11:19:53AM -0700, Cesar Philippidis wrote:
> The attached patch includes the nvptx and GCC ME reductions enhancements.
> 
> Is this patch OK for trunk? It bootstrapped / regression tested cleanly
> for x86_64 with nvptx offloading.

This is all OpenACC specific code not really shareable with OpenMP, if
Thomas (for middle-end) and Tom (for NVPTX backend) are ok with it, it is ok
for trunk.

> 2018-06-29  Cesar Philippidis  
>   Nathan Sidwell  
> 
>   gcc/
>   * config/nvptx/nvptx.c (nvptx_propagate_unified): New.
>   (nvptx_split_blocks): Call it for cond_uni insn.
>   (nvptx_expand_cond_uni): New.
>   (enum nvptx_builtins): Add NVPTX_BUILTIN_COND_UNI.
>   (nvptx_init_builtins): Initialize it.
>   (nvptx_expand_builtin):
>   (nvptx_generate_vector_shuffle): Change integral SHIFT operand to
>   tree BITS operand.
>   (nvptx_vector_reduction): New.
>   (nvptx_adjust_reduction_type): New.
>   (nvptx_goacc_reduction_setup): Use it to adjust the type of ref_to_res.
>   (nvptx_goacc_reduction_init): Don't update LHS if it doesn't exist.
>   (nvptx_goacc_reduction_fini): Call nvptx_vector_reduction for vector.
>   Use it to adjust the type of ref_to_res.
>   (nvptx_goacc_reduction_teardown):
>   * config/nvptx/nvptx.md (cond_uni): New pattern.
>   * omp-general.h (enum oacc_loop_flags): Add OLF_REDUCTION enum.
>   * omp-low.c (lower_oacc_reductions): Handle reduction decls mapped
>   with GOMP_MAP_FIRSTPRIVATE_POINTER.
>   (lower_oacc_head_mark): Use OLF_REDUCTION to mark OpenACC reductions.
>   * omp-offload.c (oacc_loop_auto_partitions): Don't assign gang
>   level parallelism to orphan reductions.
>   (default_goacc_reduction): Retype ref_to_res as necessary.

Jakub

Re: [OpenACC] Enable firstprivate OpenACC reductions

[Jakub Jelinek]

On Wed, Sep 05, 2018 at 01:08:21PM -0700, Cesar Philippidis wrote:
> 2018-XX-YY  Cesar Philippidis  
>   Chung-Lin Tang  
> 
>   gcc/
>   * gimplify.c (omp_add_variable): Enable firstprivate reduction
>   variables.
> 
>   gcc/testsuite/
>   * c-c++-common/goacc/reduction-8.c: New test.
> 
>   libgomp/
>   * testsuite/libgomp.oacc-c-c++-common/privatize-reduction-1.c: New
>   test.
>   * testsuite/libgomp.oacc-c-c++-common/privatize-reduction-2.c: New
>   test.

This is all in ORT_ACC guarded code and I don't see anything wrong with it,
so if Thomas is ok with it, it is ok for trunk.

> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -6823,20 +6823,27 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree 
> decl, unsigned int flags)
>else
>  splay_tree_insert (ctx->variables, (splay_tree_key)decl, flags);
>  
> -  /* For reductions clauses in OpenACC loop directives, by default create a
> - copy clause on the enclosing parallel construct for carrying back the
> - results.  */
> +  /* For OpenACC loop directives, when a reduction clause is placed on
> + the outermost acc loop within an acc parallel or kernels
> + construct, it must have an implied copy data mapping. E.g.
> +
> +   #pragma acc parallel
> +  {
> +#pragma acc loop reduction (+:sum)
> +
> + a copy clause for sum should be added on the enclosing parallel
> + construct for carrying back the results.  */
>if (ctx->region_type == ORT_ACC && (flags & GOVD_REDUCTION))
>  {
>struct gimplify_omp_ctx *outer_ctx = ctx->outer_context;
> -  while (outer_ctx)
> +  if (outer_ctx)
>   {
> n = splay_tree_lookup (outer_ctx->variables, (splay_tree_key)decl);
> if (n != NULL)
>   {
> /* Ignore local variables and explicitly declared clauses.  */
> if (n->value & (GOVD_LOCAL | GOVD_EXPLICIT))
> - break;
> + ;
> else if (outer_ctx->region_type == ORT_ACC_KERNELS)
>   {
> /* According to the OpenACC spec, such a reduction variable
> @@ -6856,9 +6863,7 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree 
> decl, unsigned int flags)
>   {
> splay_tree_insert (outer_ctx->variables, (splay_tree_key)decl,
>GOVD_MAP | GOVD_SEEN);
> -   break;
>   }
> -   outer_ctx = outer_ctx->outer_context;
>   }
>  }
>  }

Jakub

[PATCH] Fix predict-22.c testcase (PR tree-optimization/88285)

[Jakub Jelinek]

Hi!

All uses of explicit -freorder-blocks-and-partition needs to be guarded with
freorder effective targets, e.g. arm doesn't support -fprofile-use.

That said, until PR88310 is fixed, this effectively means the test is
UNSUPPORTED anywhere.

Ok for trunk anyway?

2018-12-04  Jakub Jelinek  

PR tree-optimization/88285
* gcc.dg/predict-22.c: Only compile on freorder targets.

--- gcc/testsuite/gcc.dg/predict-22.c.jj2018-12-02 13:33:16.616161656 
+0100
+++ gcc/testsuite/gcc.dg/predict-22.c   2018-12-04 13:05:34.455226623 +0100
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target freorder } } */
 /* { dg-options "-O2 -fdump-tree-optimized-details-blocks 
-fdump-rtl-bbpart-details-blocks -freorder-blocks-and-partition" } */
 volatile int v;
 void bar (void) __attribute__((leaf, cold));

Jakub