Re: [PATCH][Tree-optimization/PR89772]fold memchr builtins for character not in constant nul-padded string

[JunMa]

在 2019/3/21 下午1:06, Bin.Cheng 写道:

On Thu, Mar 21, 2019 at 12:57 PM JunMa  wrote:

Hi
For now, gcc can not fold code like:

const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)

It tries to avoid folding out of string length although length of a is 5.
This is a bit conservative, it's safe to folding memchr/bcmp/memcmp
builtins when constant string stores in array with some trailing nuls.

This patch folds these cases by exposing additional length of
trailing nuls in c_getstr().
Bootstrapped/regtested on x86_64-linux, ok for trunk?

I suppose that it's for GCC10?

Thanks,
bin

Since it's a P3 normal bug, so the patch is for GCC10.
Sorry for the misleading, and thanks for pointing it out.

Regards Jun

Regards
JunMa


gcc/ChangeLog

2019-03-21  Jun Ma 

  PR Tree-optimization/89772
  * fold-const.c (c_getstr): Add new parameter to get length of
additional
  trailing nuls after constant string.
  * gimple-fold.c (gimple_fold_builtin_memchr): consider trailing nuls in
  out-of-bound accesses checking.
  * fold-const-call.c (fold_const_call): Likewise.


gcc/testsuite/ChangeLog

2019-03-21  Jun Ma 

  PR Tree-optimization/89772
  * gcc.dg/builtin-memchr-4.c: New test.

Re: [PATCH][Tree-optimization/PR89772]fold memchr builtins for character not in constant nul-padded string

[Bin.Cheng]

On Thu, Mar 21, 2019 at 12:57 PM JunMa  wrote:
>
> Hi
> For now, gcc can not fold code like:
>
> const char a[5] = "123"
> __builtin_memchr (a, '7', sizeof a)
>
> It tries to avoid folding out of string length although length of a is 5.
> This is a bit conservative, it's safe to folding memchr/bcmp/memcmp
> builtins when constant string stores in array with some trailing nuls.
>
> This patch folds these cases by exposing additional length of
> trailing nuls in c_getstr().
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
I suppose that it's for GCC10?

Thanks,
bin
>
> Regards
> JunMa
>
>
> gcc/ChangeLog
>
> 2019-03-21  Jun Ma 
>
>  PR Tree-optimization/89772
>  * fold-const.c (c_getstr): Add new parameter to get length of
> additional
>  trailing nuls after constant string.
>  * gimple-fold.c (gimple_fold_builtin_memchr): consider trailing nuls in
>  out-of-bound accesses checking.
>  * fold-const-call.c (fold_const_call): Likewise.
>
>
> gcc/testsuite/ChangeLog
>
> 2019-03-21  Jun Ma 
>
>  PR Tree-optimization/89772
>  * gcc.dg/builtin-memchr-4.c: New test.

[PATCH][Tree-optimization/PR89772]fold memchr builtins for character not in constant nul-padded string

[JunMa]

Hi
For now, gcc can not fold code like:

const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)

It tries to avoid folding out of string length although length of a is 5.
This is a bit conservative, it's safe to folding memchr/bcmp/memcmp
builtins when constant string stores in array with some trailing nuls.

This patch folds these cases by exposing additional length of
trailing nuls in c_getstr().
Bootstrapped/regtested on x86_64-linux, ok for trunk?

Regards
JunMa


gcc/ChangeLog

2019-03-21  Jun Ma 

    PR Tree-optimization/89772
    * fold-const.c (c_getstr): Add new parameter to get length of 
additional

    trailing nuls after constant string.
    * gimple-fold.c (gimple_fold_builtin_memchr): consider trailing nuls in
    out-of-bound accesses checking.
    * fold-const-call.c (fold_const_call): Likewise.


gcc/testsuite/ChangeLog

2019-03-21  Jun Ma 

    PR Tree-optimization/89772
    * gcc.dg/builtin-memchr-4.c: New test.
---
 gcc/fold-const-call.c   | 14 +++---
 gcc/fold-const.c| 14 +++---
 gcc/fold-const.h|  3 ++-
 gcc/gimple-fold.c   |  5 +++--
 gcc/testsuite/gcc.dg/builtin-memchr-4.c | 30 ++
 5 files changed, 49 insertions(+), 17 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/builtin-memchr-4.c

diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 702c8b4..ea81f6a 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -1720,7 +1720,7 @@ fold_const_call (combined_fn fn, tree type, tree arg0, 
tree arg1, tree arg2)
 {
   const char *p0, *p1;
   char c;
-  unsigned HOST_WIDE_INT s0, s1;
+  unsigned HOST_WIDE_INT s0, s1, s3, s4;
   size_t s2 = 0;
   switch (fn)
 {
@@ -1756,10 +1756,10 @@ fold_const_call (combined_fn fn, tree type, tree arg0, 
tree arg1, tree arg2)
  && !TREE_SIDE_EFFECTS (arg0)
  && !TREE_SIDE_EFFECTS (arg1))
return build_int_cst (type, 0);
-  if ((p0 = c_getstr (arg0, &s0))
- && (p1 = c_getstr (arg1, &s1))
- && s2 <= s0
- && s2 <= s1)
+  if ((p0 = c_getstr (arg0, &s0, &s3))
+ && (p1 = c_getstr (arg1, &s1, &s4))
+ && s2 <= s0 + s3
+ && s2 <= s1 + s4)
return build_cmp_result (type, memcmp (p0, p1, s2));
   return NULL_TREE;
 
@@ -1770,8 +1770,8 @@ fold_const_call (combined_fn fn, tree type, tree arg0, 
tree arg1, tree arg2)
  && !TREE_SIDE_EFFECTS (arg0)
  && !TREE_SIDE_EFFECTS (arg1))
return build_int_cst (type, 0);
-  if ((p0 = c_getstr (arg0, &s0))
- && s2 <= s0
+  if ((p0 = c_getstr (arg0, &s0, &s3))
+ && s2 <= s0 + s3
  && target_char_cst_p (arg1, &c))
{
  const char *r = (const char *) memchr (p0, c, s2);
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ec28b43..413f0f0 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -14607,10 +14607,13 @@ fold_build_pointer_plus_hwi_loc (location_t loc, tree 
ptr, HOST_WIDE_INT off)
characters within it if SRC is a reference to a string plus some
constant offset).  If STRLEN is non-null, store the number of bytes
in the string constant including the terminating NUL char.  *STRLEN is
-   typically strlen(P) + 1 in the absence of embedded NUL characters.  */
+   typically strlen(P) + 1 in the absence of embedded NUL characters.
+   If TRAILINGNULSLEN is non-null, store the number of trailing NUL chars
+   after terminating NUL char of pointer P.  */
 
 const char *
-c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* = NULL */)
+c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* = NULL */,
+ unsigned HOST_WIDE_INT *trailingnulslen /* =NULL */)
 {
   tree offset_node;
   tree mem_size;
@@ -14639,16 +14642,13 @@ c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* 
= NULL */)
  literal is stored in.  */
   unsigned HOST_WIDE_INT string_length = TREE_STRING_LENGTH (src);
   unsigned HOST_WIDE_INT string_size = tree_to_uhwi (mem_size);
-
-  /* Ideally this would turn into a gcc_checking_assert over time.  */
-  if (string_length > string_size)
-string_length = string_size;
-
   const char *string = TREE_STRING_POINTER (src);
 
   /* Ideally this would turn into a gcc_checking_assert over time.  */
   if (string_length > string_size)
 string_length = string_size;
+  if (trailingnulslen)
+*trailingnulslen = string_size - string_length;
 
   if (string_length == 0
   || offset >= string_size)
diff --git a/gcc/fold-const.h b/gcc/fold-const.h
index 049fee9..5073138 100644
--- a/gcc/fold-const.h
+++ b/gcc/fold-const.h
@@ -187,7 +187,8 @@ extern bool expr_not_equal_to (tree t, const wide_int &);
 extern tree const_unop (enum tree_code, tree, tree);
 extern tree const_binop (enum tree_code, tree, tree, tree);
 extern bool negate_mathfn_p (combined_fn);
-extern const char *c_getstr (tree, unsigned HOST_WIDE_INT * = NULL);
+extern const char *c_getstr (tree, unsigned HOS

Re: [PATCH] bring netbsd/arm support up to speed. eabi, etc.

[coypu]

More pings!

On Fri, Mar 08, 2019 at 09:56:05AM +, co...@sdf.org wrote:
> Ping.
> 
> Link for possible convenience :-)
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html

[PATCH, PR d/89017] Committed fix for ICE in force_type_die, at dwarf2out.c

[Iain Buclaw]

Hi,

This patch adds a new visit method in the decl walker to handle
functions whose return type is instantiated from a nested template (a
voldemort type), as it needs to be ensured that all members of the
instance are emitted before finishing the outer function, otherwise
they will be removed during the prune_unused_types pass.  Fixing PR
d/89017.

Bootstrapped and regression tested on x86_64-linux-gnu.

Committed to trunk as r269828.

-- 
Iain
---
gcc/d/ChangeLog:

2019-03-21  Iain Buclaw  

PR d/89017
* d-codegen.cc (d_decl_context): Skip over template instances when
finding the context.
* decl.cc (DeclVisitor::visit(TemplateDeclaration)): New override.
(build_type_decl): Include parameters in name of template types.

gcc/testsuite/ChangeLog:

2019-03-21  Iain Buclaw  

PR d/89017
* gdc.dg/pr89017.d: New test.

---
diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index e8233b43c67..26929109b48 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -67,7 +67,7 @@ d_decl_context (Dsymbol *dsym)
   Dsymbol *parent = dsym;
   Declaration *decl = dsym->isDeclaration ();
 
-  while ((parent = parent->toParent ()))
+  while ((parent = parent->toParent2 ()))
 {
   /* We've reached the top-level module namespace.
 	 Set DECL_CONTEXT as the NAMESPACE_DECL of the enclosing module,
@@ -101,11 +101,6 @@ d_decl_context (Dsymbol *dsym)
 
 	  return context;
 	}
-
-  /* Instantiated types are given the context of their template.  */
-  TemplateInstance *ti = parent->isTemplateInstance ();
-  if (ti != NULL && decl == NULL)
-	parent = ti->tempdecl;
 }
 
   return NULL_TREE;
diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 7edfe523d3e..fffed97727f 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -255,6 +255,40 @@ public:
   }
   }
 
+  /* Templates are D's approach to generic programming.  They have no members
+ that can be emitted, however if the template is nested and used as a
+ voldemort type, then it's members must be compiled before the parent
+ function finishes.  */
+
+  void visit (TemplateDeclaration *d)
+  {
+/* Type cannot be directly named outside of the scope it's declared in, so
+   the only way it can be escaped is if the function has auto return.  */
+FuncDeclaration *fd = d_function_chain ? d_function_chain->function : NULL;
+
+if (!fd || !fd->isAuto ())
+  return;
+
+/* Check if the function returns an instantiated type that may contain
+   nested members.  Only applies to classes or structs.  */
+Type *tb = fd->type->nextOf ()->baseElemOf ();
+
+while (tb->ty == Tarray || tb->ty == Tpointer)
+  tb = tb->nextOf ()->baseElemOf ();
+
+TemplateInstance *ti = NULL;
+
+if (tb->ty == Tstruct)
+  ti = ((TypeStruct *) tb)->sym->isInstantiated ();
+else if (tb->ty == Tclass)
+  ti = ((TypeClass *) tb)->sym->isInstantiated ();
+
+/* Return type is instantiated from this template declaration, walk over
+   all members of the instance.  */
+if (ti && ti->tempdecl == d)
+  ti->accept (this);
+  }
+
   /* Walk over all members in the instantiated template.  */
 
   void visit (TemplateInstance *d)
@@ -2228,8 +2262,13 @@ build_type_decl (tree type, Dsymbol *dsym)
 
   gcc_assert (!POINTER_TYPE_P (type));
 
+  /* If a templated type, use the template instance name, as that includes all
+ template parameters.  */
+  const char *name = dsym->parent->isTemplateInstance ()
+? ((TemplateInstance *) dsym->parent)->toChars () : dsym->ident->toChars ();
+
   tree decl = build_decl (make_location_t (dsym->loc), TYPE_DECL,
-			  get_identifier (dsym->ident->toChars ()), type);
+			  get_identifier (name), type);
   SET_DECL_ASSEMBLER_NAME (decl, get_identifier (mangle_decl (dsym)));
   TREE_PUBLIC (decl) = 1;
   DECL_ARTIFICIAL (decl) = 1;
diff --git a/gcc/testsuite/gdc.dg/pr89017.d b/gcc/testsuite/gdc.dg/pr89017.d
new file mode 100644
index 000..b796e6246e8
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr89017.d
@@ -0,0 +1,49 @@
+// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89017
+// { dg-do compile }
+
+enum Type
+{
+Struct,
+Class,
+Pointer,
+Array,
+}
+
+auto f89017(Type type)()
+{
+static if (type == Type.Class)
+{
+class C(S)
+{
+struct S
+{
+void fn(){}
+}
+}
+}
+else
+{
+struct C(S)
+{
+struct S
+{
+void fn(){}
+}
+}
+}
+
+static if (type == Type.Struct)
+return C!Type();
+static if (type == Type.Class || type == Type.Pointer)
+return new C!Type();
+static if (type == Type.Array)
+return new C!Type[2];
+}
+
+void test89017()
+{
+f89017!(Type.Class);
+f89017!(Type.Struct);
+f89017!(Type.Pointer);
+f89017!(Type.Array);
+}

[PATCH] free_lang_data fixes (PR lto/89692)

[Jakub Jelinek]

Hi!

As mentioned in the PR, if e.g. build_aligned_type creates some specially
aligned variant of some TYPE_MAIN_VARIANT, that type doesn't appear in the
IL during free_lang_data and later on we call build_aligned_type with the
same arguments as before, we'll get the previously created aligned variant
which has not been free_lang_data processed and during LTO streaming we ICE
because of that.

The following patch prunes unmarked types from the type variant chain, so
that we don't find them later on and instead create new type variants from
the free_lang_data processed types.

Another change is just to be sure, marking TYPE_CANONICAL if it is not
already marked, so that we don't get weird behavior if we'd remove it.
In the usual case TYPE_CANONICAL will be the TYPE_MAIN_VARIANT type we mark
already anyway.

The rest of the changes is to make sure the new types we create during
free_lang_data get marked in the pset, so that we will not try to purge
them.

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

2019-03-20  Jan Hubicka  
Jakub Jelinek  

PR lto/89692
* tree.c (fld_type_variant): Call fld->pset.add.
(fld_incomplete_type_of): Likewise and don't call add_tree_to_fld_list
if it returns true.
(fld_process_array_type): Likewise.
(free_lang_data_in_type): Purge non-marked types from TYPE_NEXT_VARIANT
list.
(find_decls_types_r): Call fld_worklist_push for TYPE_CANONICAL (t).

* g++.dg/other/pr89692.C: New test.

--- gcc/tree.c.jj   2019-03-20 12:24:56.44338 +0100
+++ gcc/tree.c  2019-03-20 20:16:12.277091827 +0100
@@ -5215,6 +5215,7 @@ fld_type_variant (tree first, tree t, st
   if (inner_type)
 TREE_TYPE (v) = inner_type;
   gcc_checking_assert (fld_type_variant_equal_p (t,v, inner_type));
+  fld->pset.add (v);
   add_tree_to_fld_list (v, fld);
   return v;
 }
@@ -5253,7 +5254,8 @@ fld_process_array_type (tree t, tree t2,
   array = build_array_type_1 (t2, TYPE_DOMAIN (t),
  TYPE_TYPELESS_STORAGE (t), false);
   TYPE_CANONICAL (array) = TYPE_CANONICAL (t);
-  add_tree_to_fld_list (array, fld);
+  if (!fld->pset.add (array))
+   add_tree_to_fld_list (array, fld);
 }
   return array;
 }
@@ -5298,7 +5300,8 @@ fld_incomplete_type_of (tree t, struct f
TYPE_REF_CAN_ALIAS_ALL (t));
  gcc_assert (TYPE_CANONICAL (t2) != t2
  && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t)));
- add_tree_to_fld_list (first, fld);
+ if (!fld->pset.add (first))
+   add_tree_to_fld_list (first, fld);
  return fld_type_variant (first, t, fld);
}
   return t;
@@ -5321,6 +5324,7 @@ fld_incomplete_type_of (tree t, struct f
  copy = build_distinct_type_copy (t);
 
  /* It is possible that type was not seen by free_lang_data yet.  */
+ fld->pset.add (copy);
  add_tree_to_fld_list (copy, fld);
  TYPE_SIZE (copy) = NULL;
  TYPE_USER_ALIGN (copy) = 0;
@@ -5445,6 +5449,18 @@ free_lang_data_in_type (tree type, struc
 
   TYPE_NEEDS_CONSTRUCTING (type) = 0;
 
+  /* Purge non-marked variants from the variants chain, so that they
+ don't reappear in the IL after free_lang_data.  */
+  while (TYPE_NEXT_VARIANT (type)
+&& !fld->pset.contains (TYPE_NEXT_VARIANT (type)))
+{
+  tree t = TYPE_NEXT_VARIANT (type);
+  TYPE_NEXT_VARIANT (type) = TYPE_NEXT_VARIANT (t);
+  /* Turn the removed types into distinct types.  */
+  TYPE_MAIN_VARIANT (t) = t;
+  TYPE_NEXT_VARIANT (t) = NULL_TREE;
+}
+
   if (TREE_CODE (type) == FUNCTION_TYPE)
 {
   TREE_TYPE (type) = fld_simplified_type (TREE_TYPE (type), fld);
@@ -5464,6 +5480,7 @@ free_lang_data_in_type (tree type, struc
  & ~TYPE_QUAL_CONST
  & ~TYPE_QUAL_VOLATILE;
  TREE_VALUE (p) = build_qualified_type (arg_type, quals);
+ fld->pset.add (TREE_VALUE (p));
  free_lang_data_in_type (TREE_VALUE (p), fld);
}
  /* C++ FE uses TREE_PURPOSE to store initial values.  */
@@ -5886,8 +5903,7 @@ find_decls_types_r (tree *tp, int *ws, v
ctx = BLOCK_SUPERCONTEXT (ctx);
  fld_worklist_push (ctx, fld);
}
-  /* Do not walk TYPE_CANONICAL.  We do not stream it and thus do not
-and want not to reach unused types this way.  */
+  fld_worklist_push (TYPE_CANONICAL (t), fld);
 
   if (RECORD_OR_UNION_TYPE_P (t) && TYPE_BINFO (t))
{
--- gcc/testsuite/g++.dg/other/pr89692.C.jj 2019-03-20 20:20:10.233278697 
+0100
+++ gcc/testsuite/g++.dg/other/pr89692.C2019-03-20 20:19:53.193551778 
+0100
@@ -0,0 +1,20 @@
+// PR lto/89692
+// { dg-do compile }
+// { dg-require-effective-target lto }
+// { dg-options "-flto -O2" }
+
+struct S {
+  short int a, b;
+  unsigned char c : 1;
+};
+
+bool

[Patch, fortran] PR83515, PR85797 - ICE in gfc_element_size

[Harald Anlauf]

The PRs originated in gfc_element_size lacking a treatment of
procedure pointers, which has been added.  The testcase is currently
a pure compile test.  When a reduced run-time test for PR83515
becomes available, it will be added to the testsuite.

Regtested on x86_64-pc-linux-gnu.

OK for trunk?

Thanks,
Harald

2019-03-20  Harald Anlauf  

PR fortran/83515
PR fortran/85797
* trans-types.c (gfc_typenode_for_spec): Handle conversion for
procedure pointers.
* target-memory.c (gfc_element_size): Handle size determination
for procedure pointers.

2019-03-20  Harald Anlauf  

PR fortran/83515
PR fortran/85797
* gfortran.dg/pr85797.f90: New test.

Index: gcc/fortran/target-memory.c
===
--- gcc/fortran/target-memory.c (revision 269826)
+++ gcc/fortran/target-memory.c (working copy)
@@ -120,6 +120,7 @@
 case BT_CLASS:
 case BT_VOID:
 case BT_ASSUMED:
+case BT_PROCEDURE:
   {
/* Determine type size without clobbering the typespec for ISO C
   binding types.  */
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c   (revision 269826)
+++ gcc/fortran/trans-types.c   (working copy)
@@ -1194,6 +1194,9 @@
basetype = pfunc_type_node;
}
break;
+case BT_PROCEDURE:
+  basetype = pfunc_type_node;
+  break;
 default:
   gcc_unreachable ();
 }
Index: gcc/testsuite/gfortran.dg/pr85797.f90
===
--- gcc/testsuite/gfortran.dg/pr85797.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr85797.f90   (working copy)
@@ -0,0 +1,33 @@
+! { dg-do compile }
+! { dg-options "-Wall" }
+! PR fortran/83515 - ICE: Invalid expression in gfc_element_size
+! PR fortran/85797 - ICE in gfc_element_size, at fortran/target-memory.c:126
+
+subroutine a
+  c = transfer (a, b)   ! { dg-warning "Non-RECURSIVE procedure" }
+end
+
+recursive subroutine d
+  c = transfer (d, b)
+end
+
+recursive subroutine e
+  k = transfer (transfer (e, e), 1)
+end
+
+subroutine f
+  use, intrinsic :: iso_c_binding
+  integer(c_intptr_t) :: b, c
+  c = transfer (transfer (b, a), b)
+end
+
+module m
+contains
+  function f () result (z)  ! { dg-warning "Return value" }
+class(*), pointer :: z
+  end function f
+  recursive subroutine s (q)
+procedure(f) :: q
+call s (q)
+  end subroutine s
+end

Re: [C++ debug PATCH] [PR88534] accept VAR_DECL in class literal template parms

[Marek Polacek]

On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
> > On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> > > On Mar 20, 2019, Marek Polacek  wrote:
> > > 
> > > > This test fails with
> > > > pr88534.C:58:1: sorry, unimplemented: string literal in function 
> > > > template signature
> > > 
> > > Interesting...  gcc-8 rejected it with an error message rejecting the
> > > template parameter, but my latest trunk build (dated Mar 13, r269641)
> > > compiles it all right.  Was there a subsequent fix, maybe?  I didn't
> > > realize it was supposed to be rejected.
> > 
> > Ah, that problem only started with r269814, namely this hunk:
> 
> Maybe this is done too early and should be postponed to genericization
> (perhaps except for TREE_STATIC vars)?

Or skip when DECL is template_parm_object_p.

> > --- a/gcc/cp/typeck2.c
> > +++ b/gcc/cp/typeck2.c
> > @@ -824,10 +824,9 @@ store_init_value (tree decl, tree init, vec > va_gc>** cleanups, int flags)
> >value = digest_init_flags (type, init, flags, tf_warning_or_error);
> >  }
> >  
> > -  if (TREE_CODE (type) == ARRAY_TYPE
> > -  && TYPE_STRING_FLAG (TREE_TYPE (type))
> > -  && TREE_CODE (value) == CONSTRUCTOR)
> > -value = braced_list_to_string (type, value);
> > +  /* Look for braced array initializers for character arrays and
> > + recursively convert them into STRING_CSTs.  */
> > +  value = braced_lists_to_strings (type, value);
> >  
> >current_ref_temp_count = 0;
> >value = extend_ref_init_temps (decl, value, cleanups);
> > 
> > which now changes
> > 
> >   {.content={116, 101, 115, 116, 0}}
> > 
> > to
> > 
> >   {.content="test"}

Marek

Re: [C++ debug PATCH] [PR88534] accept VAR_DECL in class literal template parms

[Jakub Jelinek]

On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
> On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> > On Mar 20, 2019, Marek Polacek  wrote:
> > 
> > > This test fails with
> > > pr88534.C:58:1: sorry, unimplemented: string literal in function template 
> > > signature
> > 
> > Interesting...  gcc-8 rejected it with an error message rejecting the
> > template parameter, but my latest trunk build (dated Mar 13, r269641)
> > compiles it all right.  Was there a subsequent fix, maybe?  I didn't
> > realize it was supposed to be rejected.
> 
> Ah, that problem only started with r269814, namely this hunk:

Maybe this is done too early and should be postponed to genericization
(perhaps except for TREE_STATIC vars)?

> --- a/gcc/cp/typeck2.c
> +++ b/gcc/cp/typeck2.c
> @@ -824,10 +824,9 @@ store_init_value (tree decl, tree init, vec va_gc>** cleanups, int flags)
>value = digest_init_flags (type, init, flags, tf_warning_or_error);
>  }
>  
> -  if (TREE_CODE (type) == ARRAY_TYPE
> -  && TYPE_STRING_FLAG (TREE_TYPE (type))
> -  && TREE_CODE (value) == CONSTRUCTOR)
> -value = braced_list_to_string (type, value);
> +  /* Look for braced array initializers for character arrays and
> + recursively convert them into STRING_CSTs.  */
> +  value = braced_lists_to_strings (type, value);
>  
>current_ref_temp_count = 0;
>value = extend_ref_init_temps (decl, value, cleanups);
> 
> which now changes
> 
>   {.content={116, 101, 115, 116, 0}}
> 
> to
> 
>   {.content="test"}
> 
> Marek

Jakub

Re: [C++ debug PATCH] [PR88534] accept VAR_DECL in class literal template parms

[Marek Polacek]

On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> On Mar 20, 2019, Marek Polacek  wrote:
> 
> > This test fails with
> > pr88534.C:58:1: sorry, unimplemented: string literal in function template 
> > signature
> 
> Interesting...  gcc-8 rejected it with an error message rejecting the
> template parameter, but my latest trunk build (dated Mar 13, r269641)
> compiles it all right.  Was there a subsequent fix, maybe?  I didn't
> realize it was supposed to be rejected.

Ah, that problem only started with r269814, namely this hunk:

--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -824,10 +824,9 @@ store_init_value (tree decl, tree init, vec** 
cleanups, int flags)
   value = digest_init_flags (type, init, flags, tf_warning_or_error);
 }
 
-  if (TREE_CODE (type) == ARRAY_TYPE
-  && TYPE_STRING_FLAG (TREE_TYPE (type))
-  && TREE_CODE (value) == CONSTRUCTOR)
-value = braced_list_to_string (type, value);
+  /* Look for braced array initializers for character arrays and
+ recursively convert them into STRING_CSTs.  */
+  value = braced_lists_to_strings (type, value);
 
   current_ref_temp_count = 0;
   value = extend_ref_init_temps (decl, value, cleanups);

which now changes

  {.content={116, 101, 115, 116, 0}}

to

  {.content="test"}

Marek

Re: [PATCH] Allow lazy construction of hash_{table,set,map}

[Jakub Jelinek]

On Wed, Mar 20, 2019 at 05:32:16PM -0400, Jason Merrill wrote:
> > Does this look reasonable, or do you have other proposals?
> 
> IMO if you need to guard usage with
> 
> +  if (some_type_hash_table.size () == 0)
> + some_type_hash_table.create ();
> 
> this isn't any better than
> 
>   /* Create the constexpr function table if necessary.  */
>   if (constexpr_fundef_table == NULL)
> constexpr_fundef_table
>   = hash_table::create_ggc (101);

Well, this is surely more costly in that it allocates both the hash_table
structure and the memory pointed by it from GC.

> Better I think would be to make the member functions handle null m_entries
> sensibly.

The goal was not to slow down all current hash_{table,set,map} uses by
adding runtime checks if m_size is 0 or m_entries is NULL or similar
(and also grow code size that way).

I guess another option would be to make the decision whether
the hash_{table,set,map} is constructed with allocation right away (and no
runtime checks for it) or if it is lazy another template argument (bool
Lazy = false before the Allocator template argument), if !Lazy, it would
work exactly as it is now, if Lazy it would not allocate it in the ctor
and where needed would add m_entries checks.

Jakub

Re: [C++ PATCH] PR c++/89571 - ICE with ill-formed noexcept on constructor.

[Jason Merrill]

On 3/20/19 4:50 PM, Paolo Carlini wrote:

Hi Jason ---

On 17/03/19 21:06, Jason Merrill wrote:
Earlier changes to defer instantiating a defaulted noexcept-specifier 
that

depends on yet-unparsed default member initializers broke this testcase,
where instantiation fails for another reason.  In this case there's no
reason to defer and try again later, so let's not.


[snip]

Thanks.

Volker added to the audit trail the below, vaguely related, testcase, 
also a recent error recovery regression. Shall we just avoid passing 
error_mark_node to comp_except_specs and continue? Tested x86_64-linux.


OK.

Jason

Re: [Patch, Fortran, F03] PR 71861: [7/8/9 Regression] ICE in write_symbol(): bad module symbol

[Janus Weil]

Am Mi., 20. März 2019 um 18:26 Uhr schrieb Thomas Koenig
:
>
> Hi Janus,
>
> > the attached one-line patch fixes an ICE-on-invalid regression with
> > abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for
> > trunk and the release branches (7 and 8)?
>
> OK for all.

Thanks, Thomas. Committed to trunk as r269827. Will do the backports
within a week or so.

Cheers,
Janus

Re: [PATCH] Allow lazy construction of hash_{table,set,map}

[Jason Merrill]

On 3/20/19 1:12 PM, Jakub Jelinek wrote:

Already in the PR71446 patch I used ugly and slow code to avoid allocating
memory in a hash_set all the time, even when it will be used only rarely and
in PR89767 I've reached it again.

While e.g. a vec is POD that even doesn't have a constructor and auto_vec
has quite a cheap ctor, hash_set/hash_map/hash_table actually allocate the
elements array right away.  I find that overkill for the cases where the
usual case is that the hash table will not be used and it handles only
something that happens rarely.  My PR71446 patch uses a pointer to hash_set
and performs new/delete if it is needed.

The following (so far untested) patch allows to construct
hash_{table,set,map} with no memory allocation, with the limitation that
only destruction, or size/elements methods can be used safely on that.
In order to switch such hash_* into normal use, there is a create method
(with optional number of initial elements), which is then called once and
afterwards it acts as any other hash_*.

Does this look reasonable, or do you have other proposals?


IMO if you need to guard usage with

+  if (some_type_hash_table.size () == 0)
+   some_type_hash_table.create ();

this isn't any better than

  /* Create the constexpr function table if necessary.  */
  if (constexpr_fundef_table == NULL)
constexpr_fundef_table
  = hash_table::create_ggc (101);

Better I think would be to make the member functions handle null 
m_entries sensibly.


Jason

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Thomas Rodgers]

20190320-2-pstl-integration.patch.bz2
Description: Revised pstl integration patch

Fixed a failing test.

Thomas Rodgers writes:

> This time with the changelog reflecting the updated files in include/std
>
> Thomas Rodgers writes:
>
>> See attached.
>>
>> Jonathan Wakely writes:
>>
>>> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>>>Let's try this patch -
>>>>
>>>
>>>
>>> The feature test macro should be 201603L (in  and
>>> ):
>>>
>>> +// Feature test macro for parallel algorithms
>>> +# define __cpp_lib_parallel_algorithm 201703L
>>>
>>> ***
>>>
>>> The new files have copyright dates of 2018, but it's taken so long to
>>> get the licensing changes done and for me to review it that they need
>>> to say "2018-2019" now:
>>>
>>> +++ b/libstdc++-v3/include/std/execution
>>> @@ -0,0 +1,58 @@
>>> +//  -*- C++ -*-
>>> +
>>> +// Copyright (C) 2018 Free Software Foundation, Inc.
>>>
>>> ***
>>>
>>> The  header warns if included pre-C++17 but it should just
>>> not define anything:
>>>
>>> +#if __cplusplus < 201703L
>>> +# include 
>>> +#else
>>>
>>> We only give that warning for C++11 headers, but for anything newer it
>>> should be just:
>>>
>>> +#if __cplusplus >= 201703L
>>>
>>> ***
>>>
>>> There are still a couple of un-uglified names I noticed:
>>> parallel_set_union_op, is_heap_until_local
>>>
>>> ***
>>>
>>> The copyright notices at the top of each file seem a bit out of place
>>> in the GCC tree:
>>>
>>> +//===-- execution_defs.h 
>>> --===//
>>> +//
>>> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
>>> Exceptions.
>>> +// See https://llvm.org/LICENSE.txt for license information.
>>> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
>>> +//
>>> +//===--===//
>>>
>>> I wonder if we should put another comment before that, saying GCC uses
>>> the PSTL code from the LLVM upstream, or something like that. That can
>>> wait though.

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Thomas Rodgers]

20190320-1-pstl-integration.patch.bz2
Description: Revised pstl integration patch

This time with the changelog reflecting the updated files in include/std

Thomas Rodgers writes:

> See attached.
>
> Jonathan Wakely writes:
>
>> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>>Let's try this patch -
>>>
>>
>>
>> The feature test macro should be 201603L (in  and
>> ):
>>
>> +// Feature test macro for parallel algorithms
>> +# define __cpp_lib_parallel_algorithm 201703L
>>
>> ***
>>
>> The new files have copyright dates of 2018, but it's taken so long to
>> get the licensing changes done and for me to review it that they need
>> to say "2018-2019" now:
>>
>> +++ b/libstdc++-v3/include/std/execution
>> @@ -0,0 +1,58 @@
>> +//  -*- C++ -*-
>> +
>> +// Copyright (C) 2018 Free Software Foundation, Inc.
>>
>> ***
>>
>> The  header warns if included pre-C++17 but it should just
>> not define anything:
>>
>> +#if __cplusplus < 201703L
>> +# include 
>> +#else
>>
>> We only give that warning for C++11 headers, but for anything newer it
>> should be just:
>>
>> +#if __cplusplus >= 201703L
>>
>> ***
>>
>> There are still a couple of un-uglified names I noticed:
>> parallel_set_union_op, is_heap_until_local
>>
>> ***
>>
>> The copyright notices at the top of each file seem a bit out of place
>> in the GCC tree:
>>
>> +//===-- execution_defs.h 
>> --===//
>> +//
>> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
>> Exceptions.
>> +// See https://llvm.org/LICENSE.txt for license information.
>> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
>> +//
>> +//===--===//
>>
>> I wonder if we should put another comment before that, saying GCC uses
>> the PSTL code from the LLVM upstream, or something like that. That can
>> wait though.

Re: [C++ PATCH] PR c++/89571 - ICE with ill-formed noexcept on constructor.

[Paolo Carlini]

Hi Jason ---

On 17/03/19 21:06, Jason Merrill wrote:

Earlier changes to defer instantiating a defaulted noexcept-specifier that
depends on yet-unparsed default member initializers broke this testcase,
where instantiation fails for another reason.  In this case there's no
reason to defer and try again later, so let's not.


[snip]

Thanks.

Volker added to the audit trail the below, vaguely related, testcase, 
also a recent error recovery regression. Shall we just avoid passing 
error_mark_node to comp_except_specs and continue? Tested x86_64-linux.


Thanks again, Paolo.



/cp
2019-03-20  Paolo Carlini  

PR c++/89571
* method.c (after_nsdmi_defaulted_late_checks): Avoid passing
error_mark_node to comp_except_specs.

/testsuite
2019-03-20  Paolo Carlini  

PR c++/89571
* g++.dg/cpp0x/noexcept37.C: New.
Index: cp/method.c
===
--- cp/method.c (revision 269825)
+++ cp/method.c (working copy)
@@ -2274,6 +2274,9 @@ after_nsdmi_defaulted_late_checks (tree t)
  continue;
 
tree eh_spec = get_defaulted_eh_spec (fn);
+   if (eh_spec == error_mark_node)
+ continue;
+
if (!comp_except_specs (TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn)),
eh_spec, ce_normal))
  DECL_DELETED_FN (fn) = true;
Index: testsuite/g++.dg/cpp0x/noexcept37.C
===
--- testsuite/g++.dg/cpp0x/noexcept37.C (nonexistent)
+++ testsuite/g++.dg/cpp0x/noexcept37.C (working copy)
@@ -0,0 +1,8 @@
+// PR c++/89571
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+  int i = ;  // { dg-error "expected" }
+  A() noexcept = default;
+};

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Thomas Rodgers]

See attached.


20190320-pstl-integration.patch.bz2
Description: revised pstl integration patch

Jonathan Wakely writes:

> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>Let's try this patch -
>>
>
>
> The feature test macro should be 201603L (in  and
> ):
>
> +// Feature test macro for parallel algorithms
> +# define __cpp_lib_parallel_algorithm 201703L
>
> ***
>
> The new files have copyright dates of 2018, but it's taken so long to
> get the licensing changes done and for me to review it that they need
> to say "2018-2019" now:
>
> +++ b/libstdc++-v3/include/std/execution
> @@ -0,0 +1,58 @@
> +//  -*- C++ -*-
> +
> +// Copyright (C) 2018 Free Software Foundation, Inc.
>
> ***
>
> The  header warns if included pre-C++17 but it should just
> not define anything:
>
> +#if __cplusplus < 201703L
> +# include 
> +#else
>
> We only give that warning for C++11 headers, but for anything newer it
> should be just:
>
> +#if __cplusplus >= 201703L
>
> ***
>
> There are still a couple of un-uglified names I noticed:
> parallel_set_union_op, is_heap_until_local
>
> ***
>
> The copyright notices at the top of each file seem a bit out of place
> in the GCC tree:
>
> +//===-- execution_defs.h 
> --===//
> +//
> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
> Exceptions.
> +// See https://llvm.org/LICENSE.txt for license information.
> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> +//
> +//===--===//
>
> I wonder if we should put another comment before that, saying GCC uses
> the PSTL code from the LLVM upstream, or something like that. That can
> wait though.

Re: [RFC] D support for S/390

[Rainer Orth]

Iain Buclaw  writes:

> On Fri, 15 Mar 2019 at 16:50, Robin Dapp  wrote:
>>
>> Hi,
>>
>> during the last few days I tried to get D running on s390x (apparently
>> the first Big Endian platform to try it?).  I did not yet go through the
>> code systematically and add a version(SystemZ) in every place where it
>> might be needed but rather tried to fix test failures as they arose.
>
> HPPA has been somewhat ported, which is BigEndian as well.  But I've
> not done any testing beyond just the druntime unittests.

there's also SPARC, but unlike S/390 and HP-PA it's a strict alignment
target, so all execution tests fail due to PR d/88462...

Rainer

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

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Thomas Rodgers]

Ignore

Thomas Rodgers writes:

> Jonathan Wakely writes:
>
>> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>>Let's try this patch -
>>>
>>
>>
>> The feature test macro should be 201603L (in  and
>> ):
>>
>> +// Feature test macro for parallel algorithms
>> +# define __cpp_lib_parallel_algorithm 201703L
>>
>> ***
>>
>> The new files have copyright dates of 2018, but it's taken so long to
>> get the licensing changes done and for me to review it that they need
>> to say "2018-2019" now:
>>
>> +++ b/libstdc++-v3/include/std/execution
>> @@ -0,0 +1,58 @@
>> +//  -*- C++ -*-
>> +
>> +// Copyright (C) 2018 Free Software Foundation, Inc.
>>
>> ***
>>
>> The  header warns if included pre-C++17 but it should just
>> not define anything:
>>
>> +#if __cplusplus < 201703L
>> +# include 
>> +#else
>>
>> We only give that warning for C++11 headers, but for anything newer it
>> should be just:
>>
>> +#if __cplusplus >= 201703L
>
> Did you mean
>
> +#if __cplusplus >= 201603L
>
> ?
>
>>
>> ***
>>
>> There are still a couple of un-uglified names I noticed:
>> parallel_set_union_op, is_heap_until_local
>>
>> ***
>>
>> The copyright notices at the top of each file seem a bit out of place
>> in the GCC tree:
>>
>> +//===-- execution_defs.h 
>> --===//
>> +//
>> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
>> Exceptions.
>> +// See https://llvm.org/LICENSE.txt for license information.
>> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
>> +//
>> +//===--===//
>>
>> I wonder if we should put another comment before that, saying GCC uses
>> the PSTL code from the LLVM upstream, or something like that. That can
>> wait though.

[C++ PATCH] PR c++/87480 - decltype of member access in default template arg

[Jason Merrill]

The issue here is that declval().d is considered instantiation-dependent
within a template, as the access to 'd' might depend on the particular
specialization.  But when we're deducing template arguments for a call, we
know that the call and the arguments are non-dependent, so we can do the
substitution as though we aren't in a template.  Which strictly speaking we
aren't, since the default argument is considered a separate definition.

Tested x86_64-pc-linux-gnu, applying to trunk.

* pt.c (type_unification_real): Accept a dependent result in
template context.
---
 gcc/cp/pt.c|  9 -
 gcc/testsuite/g++.dg/cpp0x/fntmpdefarg11.C | 15 +++
 gcc/cp/ChangeLog   |  6 ++
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/fntmpdefarg11.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0acc16d1b92..6c15419e9cc 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21005,8 +21005,15 @@ type_unification_real (tree tparms,
}
  else
{
+ /* Even if the call is happening in template context, getting
+here means it's non-dependent, and a default argument is
+considered a separate definition under [temp.decls], so we can
+do this substitution without processing_template_decl.  This
+is important if the default argument contains something that
+might be instantiation-dependent like access (87480).  */
+ processing_template_decl_sentinel s;
  tree substed = NULL_TREE;
- if (saw_undeduced == 1 && processing_template_decl == 0)
+ if (saw_undeduced == 1)
{
  /* First instatiate in template context, in case we still
 depend on undeduced template parameters.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg11.C 
b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg11.C
new file mode 100644
index 000..86c8ea93f4d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg11.C
@@ -0,0 +1,15 @@
+// PR c++/87480
+// { dg-do compile { target c++11 } }
+
+template T&& declval();
+
+template ().d)> void f(T) { }
+
+struct A {
+  double d;
+};
+
+template 
+void j(A& a) {
+  f(a);
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 2157496745e..09fb3f2935c 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2019-03-20  Jason Merrill  
+
+   PR c++/87480 - decltype of member access in default template arg
+   * pt.c (type_unification_real): Accept a dependent result in
+   template context.
+
 2019-03-19  Martin Sebor  
 
PR tree-optimization/89688

base-commit: fcf9e045198f89f01e8a2e57724a8e6cc4d04cda
-- 
2.20.1

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Ville Voutilainen]

On Wed, 20 Mar 2019 at 22:15, Jakub Jelinek  wrote:
>
> On Wed, Mar 20, 2019 at 09:13:42PM +0100, Jakub Jelinek wrote:
> > On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > > > We only give that warning for C++11 headers, but for anything newer it
> > > > should be just:
> > > >
> > > > +#if __cplusplus >= 201703L
> > >
> > > Did you mean
> > >
> > > +#if __cplusplus >= 201603L
> >
> > I guess so:
> > http://eel.is/c++draft/support.limits.general
> > as well as
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r2.html
> > says:
> > __cpp_lib_parallel_algorithm  201603L  
>
> Sorry, ignore my mail.

That's fine - that's the value of that particular feature-testing
macro, not the value of __cplusplus. :)

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Jakub Jelinek]

On Wed, Mar 20, 2019 at 09:13:42PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > > We only give that warning for C++11 headers, but for anything newer it
> > > should be just:
> > >
> > > +#if __cplusplus >= 201703L
> > 
> > Did you mean
> > 
> > +#if __cplusplus >= 201603L
> 
> I guess so:
> http://eel.is/c++draft/support.limits.general
> as well as
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r2.html
> says:
> __cpp_lib_parallel_algorithm  201603L   

Sorry, ignore my mail.

Jakub

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Jakub Jelinek]

On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > We only give that warning for C++11 headers, but for anything newer it
> > should be just:
> >
> > +#if __cplusplus >= 201703L
> 
> Did you mean
> 
> +#if __cplusplus >= 201603L

I guess so:
http://eel.is/c++draft/support.limits.general
as well as
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r2.html
says:
__cpp_lib_parallel_algorithm201603L   

Jakub

C++ PATCH for c++/87145 - bogus error converting class type in template argument list

[Marek Polacek]

The fix for 77656 caused us to call convert_nontype_argument even for
value-dependent arguments, to perform the conversion in order to avoid
a bogus warning.

In this case, the argument is Pod{N}.  The call to build_converted_constant_expr
in convert_nontype_argument produces Pod::operator Enum(&{N}).  It doesn't crash
because we're in a template and build_address no longer crashes on CONSTRUCTORs
in a template.

Then when instantiating the function foo we substitute its argument: &{N}.  So
we're in tsubst_copy_and_build/ADDR_EXPR.  The call to
tsubst_non_call_postfix_expression turns {N} into TARGET_EXPR .
Then build_x_unary_op is supposed to put the ADDR_EXPR back.  It calls
cp_build_addr_expr_strict.  But it's *strict*, so the prvalue of class type
TARGET_EXPR  isn't allowed -> error.

It's _strict since ,
that seem like a desirable change, and we had a warning for taking the address
of a TARGET_EXPR in build_x_unary_op even before that.

So rather than messing with _strict, let's avoid this scenario altogether.
I checked whether we have a case in the testsuite that results in convert_like
getting a value-dependent CONSTRUCTOR, but found none.

With this patch, we avoid it, and only call convert_nontype_argument after
substitution, at which point maybe_constant_value will be able to evaluate
the conversion to a constant.

This problem doesn't occur when passing Pod{N} as an argument to a function,
or using it as an array dimension; seems we avoid converting the argument if
it's value-dependent.

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

2019-03-20  Marek Polacek  

PR c++/87145 - bogus error converting class type in template arg list.
* pt.c (convert_template_argument): Don't call convert_nontype_argument
if it could involve calling a conversion function with a value-dependent
constructor as its argument.

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

diff --git gcc/cp/pt.c gcc/cp/pt.c
index 0acc16d1b92..6878583d99b 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -8056,7 +8056,16 @@ convert_template_argument (tree parm,
t = canonicalize_type_argument (t, complain);
 
   if (!type_dependent_expression_p (orig_arg)
- && !uses_template_parms (t))
+ && !uses_template_parms (t)
+ /* This might trigger calling a conversion function with
+a value-dependent argument, which could invoke taking
+the address of a temporary representing the result of
+the conversion.  */
+ && !(COMPOUND_LITERAL_P (orig_arg)
+  && MAYBE_CLASS_TYPE_P (TREE_TYPE (orig_arg))
+  && TYPE_HAS_CONVERSION (TREE_TYPE (orig_arg))
+  && INTEGRAL_OR_ENUMERATION_TYPE_P (t)
+  && value_dependent_expression_p (orig_arg)))
/* We used to call digest_init here.  However, digest_init
   will report errors, which we don't want when complain
   is zero.  More importantly, digest_init will try too
@@ -8092,7 +8101,7 @@ convert_template_argument (tree parm,
  && TREE_CODE (TREE_TYPE (innertype)) == FUNCTION_TYPE
  && TREE_OPERAND_LENGTH (inner) > 0
   && reject_gcc_builtin (TREE_OPERAND (inner, 0)))
-  return error_mark_node;
+   return error_mark_node;
 }
 
   if (TREE_CODE (val) == SCOPE_REF)
diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-conv3.C 
gcc/testsuite/g++.dg/cpp0x/constexpr-conv3.C
new file mode 100644
index 000..3f47c58cd2a
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-conv3.C
@@ -0,0 +1,25 @@
+// PR c++/87145
+// { dg-do compile { target c++11 } }
+
+template struct integral_constant {
+  static constexpr T value = t;
+};
+
+enum class Enum : unsigned {};
+
+struct Pod {
+  unsigned val;
+
+  constexpr operator Enum() const {
+return static_cast(val);
+  }
+};
+
+template
+constexpr void foo() {
+  using Foo = integral_constant;
+}
+
+int main() {
+  foo<2>();
+}
diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-conv4.C 
gcc/testsuite/g++.dg/cpp0x/constexpr-conv4.C
new file mode 100644
index 000..f4e3f00a585
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-conv4.C
@@ -0,0 +1,25 @@
+// PR c++/87145
+// { dg-do compile { target c++11 } }
+
+struct S {
+  int val;
+
+  constexpr operator int() const {
+return static_cast(val);
+  }
+};
+
+template
+struct F { };
+
+template
+constexpr void foo() {
+  F f;
+  F f2;
+}
+
+int
+main()
+{
+  foo<2>();
+}

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Ville Voutilainen]

On Wed, 20 Mar 2019 at 22:05, Thomas Rodgers  wrote:
> > +#if __cplusplus < 201703L
> > +# include 
> > +#else
> >
> > We only give that warning for C++11 headers, but for anything newer it
> > should be just:
> >
> > +#if __cplusplus >= 201703L
>
> Did you mean
>
> +#if __cplusplus >= 201603L
>
> ?

No. Such a value does not exist. He means what he wrote; these
parallel algos should be available starting with C++17 and in newer
versions as well, and they should just not-exist in earlier versions,
without a header warning.

Re: [PATCH] Integration of parallel standard algorithms for c++17

[Thomas Rodgers]

Jonathan Wakely writes:

> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>Let's try this patch -
>>
>
>
> The feature test macro should be 201603L (in  and
> ):
>
> +// Feature test macro for parallel algorithms
> +# define __cpp_lib_parallel_algorithm 201703L
>
> ***
>
> The new files have copyright dates of 2018, but it's taken so long to
> get the licensing changes done and for me to review it that they need
> to say "2018-2019" now:
>
> +++ b/libstdc++-v3/include/std/execution
> @@ -0,0 +1,58 @@
> +//  -*- C++ -*-
> +
> +// Copyright (C) 2018 Free Software Foundation, Inc.
>
> ***
>
> The  header warns if included pre-C++17 but it should just
> not define anything:
>
> +#if __cplusplus < 201703L
> +# include 
> +#else
>
> We only give that warning for C++11 headers, but for anything newer it
> should be just:
>
> +#if __cplusplus >= 201703L

Did you mean

+#if __cplusplus >= 201603L

?

>
> ***
>
> There are still a couple of un-uglified names I noticed:
> parallel_set_union_op, is_heap_until_local
>
> ***
>
> The copyright notices at the top of each file seem a bit out of place
> in the GCC tree:
>
> +//===-- execution_defs.h 
> --===//
> +//
> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
> Exceptions.
> +// See https://llvm.org/LICENSE.txt for license information.
> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> +//
> +//===--===//
>
> I wonder if we should put another comment before that, saying GCC uses
> the PSTL code from the LLVM upstream, or something like that. That can
> wait though.

Re: [C++ debug PATCH] [PR88534] accept VAR_DECL in class literal template parms

[Alexandre Oliva]

On Mar 20, 2019, Marek Polacek  wrote:

> This test fails with
> pr88534.C:58:1: sorry, unimplemented: string literal in function template 
> signature

Interesting...  gcc-8 rejected it with an error message rejecting the
template parameter, but my latest trunk build (dated Mar 13, r269641)
compiles it all right.  Was there a subsequent fix, maybe?  I didn't
realize it was supposed to be rejected.

-- 
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: [PR fortran/85797, patch] - ICE in gfc_element_size, at fortran/target-memory.c:126

[Harald Anlauf]

Hi Thomas,

based on your comments I'll withdraw the patch, but read on...

On 03/20/19 17:14, Thomas Koenig wrote:
> Hi Harald,
>
>> My reading of the standard suggests that this is not allowed:
>>
>>SOURCE shall be a scalar or array of any type.
>>
>>MOLD shall be a scalar or array of any type. ...
>
> I read the stanard differently.  For comparison, look at UNPACK:
>
> # VECTOR  shall be a rank-one array of any type.
>
> and a function result is fine there.

If PROCEDURE is a type, then my patch is wrong.

I got rejections of several variations of the test cases by
Crayftn and Intel, which seemed to support my interpretation.

> Also, looking at how the paragraph about MOLD continues:
>
> # MOLD  shall be a scalar or array of any type. If it is a variable, it
> # need not be defined.
>
> The sentence starting with "If" would be redundant if MOLD could
> only be a variable.

No.  A constant expression for MOLD is quite useful; I use it every day.
In fact, I consider TRANSFER to be the "Swiss army knife of Fortran 95",
and we have tons on TRANSFER in our code, with MOLD being 1, [1], ["*"],
you name it...

> However, I am ready to be convinced otherwise :-)

Well, your response shows that the review process exists!

I have a slightly different approach in mind that I need to check.

Thanks for the review anyway,

Harald (not the "real" McGyver)

> Regards
>
> Thomas
>

Re: [PATCH] correct handling of offsets in bounds warnings (PR 89350)

[Jeff Law]

On 2/26/19 6:32 PM, Martin Sebor wrote:
> Please disregard the original patch and consider the attached
> version instead.
> 
> On 2/26/19 5:03 PM, Martin Sebor wrote:
>> The false positive in PR89350 is due to -Wstringop-overflow
>> trusting that the sizetype offset in POINTER_PLUS_EXPR means
>> the offset is, in fact, unsigned.  Avoiding the false positive
>> in the cases when this isn't so is trivial but comes at a cost
>> of false negatives.  Avoiding those will, I expect, require
>> enhancing the compute_builtin_object_size() function and that
>> seems risky at this stage so I would like to defer that until
>> stage 1.  Except in the instance of memset, the false positives
>> also aren't too serious because the same problem is also
>> diagnosed by the -Warray-bounds warning in the wrestrict pass.
>> Unfortunately, the wrestrict pass only handles copy functions
>> and not memset.
>>
>> With that as background, the attached patch avoids
>> the -Wstringop-overflow false positive by disabling the warning
>> for offsets whose lower bound is positive and upper bound negative.
>> To avoid the false negatives for memset the patch lets the wrestrict
>> pass handle the function (for the bounds checking only).  While
>> testing this I noticed that the wrestrict pass makes the same
>> assumption about offsets, so it too is susceptible to similar
>> false positives.  The rest of the patch corrects this problem
>> n the wrestrict pass.  Because the pass doesn't depend on
>> the compute_builtin_object_size() function as much as
>> -Wstringop-overflow, the fix does not cause false positives (at
>> least none that I came across).
>>
>> Tested on x86_64-linux.
>>
>> Martin
> 
> 
> gcc-89350.diff
> 
> PR tree-optimization/89350 - Wrong -Wstringop-overflow= warning since r261518
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/89350
>   * builtins.c (compute_objsize): Also ignore offsets whose upper
>   bound is negative.
>   * gimple-ssa-warn-restrict.c (builtin_memref): Add new member.
>   (builtin_memref::builtin_memref): Initialize new member.
>   Allow EXPR to be null.
>   (builtin_memref::extend_offset_range): Replace local with a member.
>   Avoid assuming pointer offsets are unsigned.
>   (builtin_memref::set_base_and_offset): Determine base object
>   before computing offset range.
>   (builtin_access::builtin_access): Handle memset.
>   (builtin_access::generic_overlap): Replace local with a member.
>   (builtin_access::strcat_overlap): Same.
>   (builtin_access::overlap): Same.
>   (maybe_diag_overlap): Same.
>   (maybe_diag_access_bounds): Same.
>   (wrestrict_dom_walker::check_call): Handle memset.
>   (check_bounds_or_overlap): Same.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/89350
>   * gcc.dg/Wstringop-overflow.c: Xfail overly ambitious tests.
>   * gcc.dg/Wstringop-overflow-10.c: New test.
>   * gcc.dg/Wstringop-overflow-11.c: New test.
>   * gcc.dg/pr89350.c: New test.
>   * gcc.dg/pr40340-1.c: Adjust expected warning.
>   * gcc.dg/pr40340-2.c: Same.
>   * gcc.dg/pr40340-4.c: Same.
>   * gcc.dg/pr40340-5.c: Same.
OK.  And just to be clear, totally agree with not trying to change
c_b_o_s to return a range at this point in the release cycle.

jeff

Re: [PATCH] make ggc pick up comp_dir_string() cache value. (dwarf2out.c)

[Otto, Thomas]

> > > > "ggc_collect() discarding/reusing remap_debug_filename() output,
> > > > thus producing invalid objects"
> > >
> > > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd ()
> > > result survives.  I vaguely remember GC being happy with heap
> > > strings (due to identifiers?), but not sure.  Otherwise the patch looks
> > > obvious enough.
> >
> > Good point, remap_filename can return the original filename pointer
> > (which can point to env["PWD"] or to an allocated string) or a ggc string.
> >
> > Since not freeing the string pointed to by a static variable is ok (as
> > getpwd does it), what about checking if remap_filename just returns
> > the input filename ptr again, and if not copy the ggc string into an 
> > allocated
> > buffer.
> 
> I think we always want GC allocated storage here since the whole dwarf2out
> data structures live in GC memory.  That means unconditionally copying there
> as is done inside the DWARF2_DIR_SHOULD_END_WITH_SEPARATOR path.

Explicitly requesting gc storage (A or B below) doesn't seem to work. The 
mapped 
wd string is not modified this time but is placed in a very different part of 
the 
assembly, in .section .debug_str.dwo, and after assembling it does not even 
make it 
into object, not even in a corrupted form as previously.

Placing the static cached_wd on function or file level makes no difference, 
only the 
GTY(()) marker fixes it again. Or of course allocating a buffer myself (C).

And while DWARF2_DIR_SHOULD_END_WITH_SEPARATOR is only true on VMS, if I 
enter this if block and do not specify -fdebug-prefix-map then the final object 
does 
not even contain the working directory, probably because it is stored in 
the ggc_vec_alloc data. Tested with 8.3 built with 4.9 and now also 8.3 itself. 
Maybe 
gc and static storage do not play well together.

That leaves classic allocation of memory and pointing the cached_wd there. It 
really shouldn't matter since it is just a cache of an otherwise side effect 
free 
function return value. It would outlive all of its callers anyhow, gc or not.


  static const char *cached_wd = NULL;
  // [...]
  cached_wd = remap_debug_filename (wd);
  if (cached_wd != wd)
{
  size_t cached_wd_len = strlen (cached_wd);
A:char *buf = ggc_vec_alloc (cached_wd_len);
B:char *buf = (char*)ggc_alloc_atomic (cached_wd_len);
C:char *buf = (char*)xmalloc (cached_wd_len);
  memcpy (buf, cached_wd, cached_wd_len);
  cached_wd = buf;
}

Re: [RFC] D support for S/390

[Iain Buclaw]

On Wed, 20 Mar 2019 at 12:27, Iain Buclaw  wrote:
>
> On Wed, 20 Mar 2019 at 10:57, Robin Dapp  wrote:
> >
> > Hi,
> >
> > the unicode tables in std.internal.unicode_tables are apparently auto
> > generated and loaded at (libphobos) compile time.  They are also in
> > little endian format.  Is the tool to generate them available somewhere?
> >  I wanted to start converting them to little endian before loading but
> > this will prove difficult at compile time again :)
> >
>
> Hi,
>
> I will ask if the author still has the utility available.
>
> My guess would be that the data used for input would have been
> retrieved from here.
>
> http://www.unicode.org/Public/4.1.0/ucd/
>
> Will let you know as soon as I find out more.
>

It comes from this repo: https://github.com/DmitryOlshansky/gsoc-bench-2012

I've tested build them using the following:

mkdir build; cd build
sh ../get-uni.sh
gdc -m64 -frelease ../gen_uni.d randAA.d -o gen_uni_64 &
gdc -m32 -frelease ../gen_uni.d randAA.d -o gen_uni_64 &
wait
mkdir 64
./gen_uni_64
mv unicode_*.d 64
mkdir 32
./gen_uni_32
mv unicode_*.d 32
for name in 64/*.d ; do
name32=`echo $name | sed 's/64/32/'`
sed -n '/^static if(size_t.sizeof == 4) {$/,$p' $name32 >> $name
done
mv 64/*.d .
rm -rf 64/ 32/

Then a final clean-up using dfmt
(https://github.com/dlang-community/dfmt - build with: make gdc)

dfmt --inplace --max_line_length=80 unicode_*.d

However... it looks like upstream phobos has done some extra tweaks
and formatting since the original check-in of the sources, so any new
regeneration would have to re-add those ad-hoc changes back in...

Are the values inside the tables the problem? Or just some of the
helper functions/templates that interact with them to generate the
static data?

If the latter, then a rebuild of the files may not be necessary.

Regards
-- 
Iain

Re: [PATCH] PR ada/89583, GNAT.Sockets.Bind_Socket fails with IPv4 address

[Simon Wright]

Thanks, Pierre-Marie: it'd be a shame if 9.1 couldn't handle IPv4.

--S

> On 20 Mar 2019, at 13:31, Pierre-Marie de Rodat  wrote:
> 
> Hello Simon,
> 
> On 3/19/19 5:02 PM, Simon Wright wrote:
>> Ping?
> 
> Sorry for the delay! Thank you for the notice; I’ll try to get our fix ported 
> as soon as possible (hopefully before the end of the week).
> 
> Cheers,
> 
> -- 
> Pierre-Marie de Rodat

Re: [Patch, Fortran, F03] PR 71861: [7/8/9 Regression] ICE in write_symbol(): bad module symbol

[Thomas Koenig]

Hi Janus,


the attached one-line patch fixes an ICE-on-invalid regression with
abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for
trunk and the release branches (7 and 8)?


OK for all.

Thanks for the patch!

Regards

Thomas

Re: [C++ PATCH] Fix lambda capture duplicate handling (PR c++/89767, take 3 & 4)

[Nathan Sidwell]

On 3/20/19 1:15 PM, Jakub Jelinek wrote:

On Wed, Mar 20, 2019 at 11:10:19AM -0400, Nathan Sidwell wrote:

I was unclear.  I was for the lazy creation of the hash.  I just think it
can be lazily created at either the first or second explicit capture.


On top of the https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00991.html
patch I've just posted here are two different patches to do this, the
first one optimizes just the zero captures case and creates a hash_set
on the first add_capture, the second one optimizes zero and one captures
case and creates a hash_set on the second add_capture.


Thanks.  Looking at the 8 or so lines in the second patch dealing with 
the single case I can't help thinking that's not an optimization.  I 
suppose the initial calloc could be pricy.


But anyway, overthinking this.  Either patch is fine -- you choose!

nathan

--
Nathan Sidwell

[C++ PATCH] Fix lambda capture duplicate handling (PR c++/89767, take 3 & 4)

[Jakub Jelinek]

On Wed, Mar 20, 2019 at 11:10:19AM -0400, Nathan Sidwell wrote:
> I was unclear.  I was for the lazy creation of the hash.  I just think it
> can be lazily created at either the first or second explicit capture.

On top of the https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00991.html
patch I've just posted here are two different patches to do this, the
first one optimizes just the zero captures case and creates a hash_set
on the first add_capture, the second one optimizes zero and one captures
case and creates a hash_set on the second add_capture.

Jakub
2019-03-20  Jakub Jelinek  

PR c++/89767
* cp-tree.h (add_capture): Add ids argument.
* parser.c (cp_parser_lambda_introducer): Add ids variable and pass
its address to add_capture calls.
* lambda.c (add_capture): Add ids argument, don't use
IDENTIFIER_MARKED, instead use ids hash_set for that.
(register_capture_members): Don't clear IDENTIFIER_MARKED here.
(add_default_capture): Adjust add_capture caller.

* g++.dg/cpp1y/lambda-init18.C: New test.
* g++.dg/cpp1y/lambda-init19.C: New test.
* g++.dg/cpp1y/pr89767.C: New test.

--- gcc/cp/parser.c.jj  2019-03-20 17:05:02.072175252 +0100
+++ gcc/cp/parser.c 2019-03-20 17:36:04.360920665 +0100
@@ -10547,6 +10547,7 @@ cp_parser_lambda_introducer (cp_parser*
error ("non-local lambda expression cannot have a capture-default");
 }
 
+  hash_set ids (EMPTY_HASH);
   while (cp_lexer_next_token_is_not (parser->lexer, CPP_CLOSE_SQUARE))
 {
   cp_token* capture_token;
@@ -10586,7 +10587,7 @@ cp_parser_lambda_introducer (cp_parser*
   /*id=*/this_identifier,
   /*initializer=*/finish_this_expr (),
   /*by_reference_p=*/true,
-  explicit_init_p);
+  explicit_init_p, &ids);
  continue;
}
 
@@ -10604,7 +10605,7 @@ cp_parser_lambda_introducer (cp_parser*
   /*id=*/this_identifier,
   /*initializer=*/finish_this_expr (),
   /*by_reference_p=*/false,
-  explicit_init_p);
+  explicit_init_p, &ids);
  continue;
}
 
@@ -10757,7 +10758,7 @@ cp_parser_lambda_introducer (cp_parser*
   capture_id,
   capture_init_expr,
   /*by_reference_p=*/capture_kind == BY_REFERENCE,
-  explicit_init_p);
+  explicit_init_p, &ids);
 
   /* If there is any qualification still in effect, clear it
 now; we will be starting fresh with the next capture.  */
--- gcc/cp/lambda.c.jj  2019-03-20 17:05:02.179173500 +0100
+++ gcc/cp/lambda.c 2019-03-20 17:36:39.034359206 +0100
@@ -500,11 +500,12 @@ vla_capture_type (tree array_type)
 /* From an ID and INITIALIZER, create a capture (by reference if
BY_REFERENCE_P is true), add it to the capture-list for LAMBDA,
and return it.  If ID is `this', BY_REFERENCE_P says whether
-   `*this' is captured by reference.  */
+   `*this' is captured by reference.  IDS is used during introducer
+   parsing to detect duplicate captures if there are many captures.  */
 
 tree
 add_capture (tree lambda, tree id, tree orig_init, bool by_reference_p,
-bool explicit_init_p)
+bool explicit_init_p, hash_set *ids)
 {
   char *buf;
   tree type, member, name;
@@ -605,13 +606,16 @@ add_capture (tree lambda, tree id, tree
  for duplicates.  */
   if (!LAMBDA_EXPR_CLOSURE (lambda))
 {
-  if (IDENTIFIER_MARKED (name))
+  gcc_assert (ids);
+  if (ids->size () == 0)
+   ids->create ();
+  if (ids->contains (name))
{
  pedwarn (input_location, 0,
   "already captured %qD in lambda expression", id);
  return NULL_TREE;
}
-  IDENTIFIER_MARKED (name) = true;
+  ids->add (name);
 }
 
   if (variadic)
@@ -674,8 +678,6 @@ register_capture_members (tree captures)
   if (PACK_EXPANSION_P (field))
 field = PACK_EXPANSION_PATTERN (field);
 
-  /* We set this in add_capture to avoid duplicates.  */
-  IDENTIFIER_MARKED (DECL_NAME (field)) = false;
   finish_member_declaration (field);
 }
 
@@ -706,7 +708,7 @@ add_default_capture (tree lambda_stack,
(this_capture_p
 || (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda)
 == CPLD_REFERENCE)),
-   /*explicit_init_p=*/false);
+   /*explicit_init_p=*/false, NULL);
   initializer = convert_from_reference (var);
 
   /* Warn about deprecated implicit capture of this via [=].  */
--- gcc/cp/cp-tree.h.jj 2019-03-20 17:05:02.133174253 +0100
+++ gcc/cp/cp-tree.h2019-03-20 17:35:25.113556194 +0100
@@ -7150,7 +7150,8 @@ extern tree lambda_return_type(tree);
 extern tree lambda_proxy_type  

[PATCH] Allow lazy construction of hash_{table,set,map}

[Jakub Jelinek]

Hi!

Already in the PR71446 patch I used ugly and slow code to avoid allocating
memory in a hash_set all the time, even when it will be used only rarely and
in PR89767 I've reached it again.

While e.g. a vec is POD that even doesn't have a constructor and auto_vec
has quite a cheap ctor, hash_set/hash_map/hash_table actually allocate the
elements array right away.  I find that overkill for the cases where the
usual case is that the hash table will not be used and it handles only
something that happens rarely.  My PR71446 patch uses a pointer to hash_set
and performs new/delete if it is needed.

The following (so far untested) patch allows to construct
hash_{table,set,map} with no memory allocation, with the limitation that
only destruction, or size/elements methods can be used safely on that.
In order to switch such hash_* into normal use, there is a create method
(with optional number of initial elements), which is then called once and
afterwards it acts as any other hash_*.

Does this look reasonable, or do you have other proposals?
Or is this thing simply not worth bothering with and I should just
unconditionally use hash_set with the default 13 elements construction?

2019-03-20  Jakub Jelinek  

* hash-table.h (empty_hash): New enum.
(hash_table::hash_table): New ctor with empty_hash first argument.
(hash_table::create): New method.
* hash-set.h (hash_set::hash_set): New ctor with empty_hash first
argument.
(hash_set::create_ggc): Formatting fix.
(hash_set::create, hash_set::size): New methods.
* hash-map.h (hash_map::hash_map): New ctor with empty_hash first
argument.
(hash_map::empty): Formatting fix.
(hash_map::create, hash_map::size): New methods.

--- gcc/hash-table.h.jj 2019-03-14 23:46:28.593616750 +0100
+++ gcc/hash-table.h2019-03-20 17:47:16.925027249 +0100
@@ -167,6 +167,24 @@ along with GCC; see the file COPYING3.
See hash_table for details.  The interface is very similar to libiberty's
htab_t.
 
+   If a hash table is used only in some rare cases, it is possible
+   to construct the hash_table lazily before first use.  This is done
+   through:
+
+  hash_table  some_type_hash_table (EMPTY_HASH);
+
+   On such an object, only size () or elements () method can be safely
+   called and in order to make it usable,
+
+  some_type_hash_table.create ();
+
+   needs to be called, possibly guarded like:
+
+  if (some_type_hash_table.size () == 0)
+   some_type_hash_table.create ();
+
+   This way, no memory is allocated during construction.
+
 
EASY DESCRIPTORS FOR POINTERS
 
@@ -340,6 +358,8 @@ hash_table_mod2 (hashval_t hash, unsigne
 
 class mem_usage;
 
+enum empty_hash { EMPTY_HASH };
+
 /* User-facing hash table type.
 
The table stores elements of type Descriptor::value_type and uses
@@ -365,6 +385,10 @@ public:
   bool gather_mem_stats = GATHER_STATISTICS,
   mem_alloc_origin origin = HASH_TABLE_ORIGIN
   CXX_MEM_STAT_INFO);
+  explicit hash_table (empty_hash, bool ggc = false,
+  bool gather_mem_stats = GATHER_STATISTICS,
+  mem_alloc_origin origin = HASH_TABLE_ORIGIN
+  CXX_MEM_STAT_INFO);
   explicit hash_table (const hash_table &, bool ggc = false,
   bool gather_mem_stats = GATHER_STATISTICS,
   mem_alloc_origin origin = HASH_TABLE_ORIGIN
@@ -381,6 +405,10 @@ public:
 return table;
   }
 
+  /* If hash_table has been constructed with EMPTY_HASH, this method
+ needs to be called before using it (except for size method).  */
+  void create (size_t n);
+
   /* Current size (in entries) of the hash table.  */
   size_t size () const { return m_size; }
 
@@ -581,11 +609,38 @@ hash_table::hash_
 
   if (m_gather_mem_stats)
 hash_table_usage ().register_descriptor (this, origin, ggc
- FINAL_PASS_MEM_STAT);
+FINAL_PASS_MEM_STAT);
 
   m_entries = alloc_entries (size PASS_MEM_STAT);
   m_size = size;
   m_size_prime_index = size_prime_index;
+}
+
+template class Allocator>
+hash_table::hash_table (empty_hash, bool ggc, bool
+  gather_mem_stats,
+  mem_alloc_origin origin
+  MEM_STAT_DECL) :
+  m_entries (NULL), m_size (0), m_n_elements (0), m_n_deleted (0),
+  m_searches (0), m_collisions (0), m_size_prime_index (INT_MAX),
+  m_ggc (ggc), m_gather_mem_stats (gather_mem_stats)
+{
+  if (m_gather_mem_stats)
+hash_table_usage ().register_descriptor (this, origin, ggc
+FINAL_PASS_MEM_STAT);
+}
+
+template class Allocator>
+void
+hash_table::create (size_t size)
+{
+  gcc_checking_assert (m_size == 0);
+
+  unsigned int size_prime_index = hash_table

Re: [C++ debug PATCH] [PR88534] accept VAR_DECL in class literal template parms

[Marek Polacek]

On Fri, Mar 15, 2019 at 10:53:35AM -0300, Alexandre Oliva wrote:
> On Mar 14, 2019, Jason Merrill  wrote:
> 
> >> You can use VAR_P for this.
> 
> > OK with that change.
> 
> Thanks, I went ahead and also added a test before dereferencing it,
> since there was evidence shortly thereafter that it could possibly be
> NULL.
> 
> Here's what I'm installing.
> 
> 
> P0732R2 / C++ 2a introduce class literals as template parameters.  The
> front-end uses VAR_DECLs constructed from such literals to bind the
> template PARM_DECLs, but dwarf2out.c used to reject such VAR_DECLs.
> 
> Taking DECL_INITIAL from such VAR_DECLs enables the generation of
> DW_AT_const_value for them, at least when the class literal can
> actually be represented as such.
> 
> 
> for  gcc/ChangeLog
> 
>   PR c++/88534
>   PR c++/88537
>   * dwarf2out.c (generic_parameter_die): Follow DECL_INITIAL of
>   VAR_DECL args.
> 
> for  gcc/ChangeLog
> 
>   PR c++/88534
>   PR c++/88537
>   * g++.dg/cpp2a/pr88534.C: New.

This test fails with
pr88534.C:58:1: sorry, unimplemented: string literal in function template 
signature

Marek

Re: [PR fortran/85797, patch] - ICE in gfc_element_size, at fortran/target-memory.c:126

[Thomas Koenig]

Hi Harald,


My reading of the standard suggests that this is not allowed:

   SOURCE shall be a scalar or array of any type.

   MOLD shall be a scalar or array of any type. ...


I read the stanard differently.  For comparison, look at UNPACK:

# VECTOR  shall be a rank-one array of any type.

and a function result is fine there.

Also, looking at how the paragraph about MOLD continues:

# MOLD  shall be a scalar or array of any type. If it is a variable, it
# need not be defined.

The sentence starting with "If" would be redundant if MOLD could
only be a variable.

However, I am ready to be convinced otherwise :-)

Regards

Thomas

[Committed] S/390: Fix PR89775. Stackpointer save/restore instructions removed

[Andreas Krebbel]

Even if a global register is being clobbered in a function we usually
do not save and restore it. However, we still have to do this if it is
a special register. Most of the places in the backend handle this
correctly but not the prologue/epilogue optimization.

Bootstrapped and regression tested on s390x.

gcc/ChangeLog:

2019-03-20  Andreas Krebbel  

PR target/89775
* config/s390/s390.c (global_not_special_regno_p): Move to make it
available to ...
(s390_optimize_register_info): Use global_not_special_regno_p to
check for global regs.

2019-03-20  Jakub Jelinek  

PR target/89775
* gcc.target/s390/pr89775-1.c: New test.
* gcc.target/s390/pr89775-2.c: New test.
---
 gcc/config/s390/s390.c| 34 ---
 gcc/testsuite/gcc.target/s390/pr89775-1.c | 17 
 gcc/testsuite/gcc.target/s390/pr89775-2.c | 25 +++
 3 files changed, 60 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/pr89775-1.c
 create mode 100644 gcc/testsuite/gcc.target/s390/pr89775-2.c

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 41f2665..5f26437 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -9588,6 +9588,21 @@ s390_register_info ()
   s390_register_info_stdarg_gpr ();
 }
 
+/* Return true if REGNO is a global register, but not one
+   of the special ones that need to be saved/restored in anyway.  */
+
+static inline bool
+global_not_special_regno_p (int regno)
+{
+  return (global_regs[regno]
+ /* These registers are special and need to be
+restored in any case.  */
+ && !(regno == STACK_POINTER_REGNUM
+  || regno == RETURN_REGNUM
+  || regno == BASE_REGNUM
+  || (flag_pic && regno == (int)PIC_OFFSET_TABLE_REGNUM)));
+}
+
 /* This function is called by s390_optimize_prologue in order to get
rid of unnecessary GPR save/restore instructions.  The register info
for the GPRs is re-computed and the ranges are re-calculated.  */
@@ -9602,8 +9617,10 @@ s390_optimize_register_info ()
 
   s390_regs_ever_clobbered (clobbered_regs);
 
+  /* Global registers do not need to be saved and restored unless it
+ is one of our special regs.  (r12, r13, r14, or r15).  */
   for (i = 0; i < 32; i++)
-clobbered_regs[i] = clobbered_regs[i] && !global_regs[i];
+clobbered_regs[i] = clobbered_regs[i] && !global_not_special_regno_p (i);
 
   /* There is still special treatment needed for cases invisible to
  s390_regs_ever_clobbered.  */
@@ -10345,21 +10362,6 @@ restore_fpr (rtx base, int offset, int regnum)
   return emit_move_insn (gen_rtx_REG (DFmode, regnum), addr);
 }
 
-/* Return true if REGNO is a global register, but not one
-   of the special ones that need to be saved/restored in anyway.  */
-
-static inline bool
-global_not_special_regno_p (int regno)
-{
-  return (global_regs[regno]
- /* These registers are special and need to be
-restored in any case.  */
- && !(regno == STACK_POINTER_REGNUM
-  || regno == RETURN_REGNUM
-  || regno == BASE_REGNUM
-  || (flag_pic && regno == (int)PIC_OFFSET_TABLE_REGNUM)));
-}
-
 /* Generate insn to save registers FIRST to LAST into
the register save area located at offset OFFSET
relative to register BASE.  */
diff --git a/gcc/testsuite/gcc.target/s390/pr89775-1.c 
b/gcc/testsuite/gcc.target/s390/pr89775-1.c
new file mode 100644
index 000..2c0f6fd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/pr89775-1.c
@@ -0,0 +1,17 @@
+/* PR target/89775 */
+/* { dg-do run } */
+/* { dg-options "-O0 -fomit-frame-pointer" } */
+/* { dg-additional-sources "pr89775-2.c" } */
+
+register void *sp __asm ("15");
+
+__attribute__((noipa)) int
+foo (const char *a, const char *b)
+{
+  while (1)
+{
+  char c = *a++;
+  if (c != *b++) return 0;
+  if (c == '\0') return 1;
+}
+}
diff --git a/gcc/testsuite/gcc.target/s390/pr89775-2.c 
b/gcc/testsuite/gcc.target/s390/pr89775-2.c
new file mode 100644
index 000..645661e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/pr89775-2.c
@@ -0,0 +1,25 @@
+/* PR target/89775 */
+/* { dg-do compile } */
+
+extern int foo (const char *, const char *);
+
+__attribute__((noipa)) void
+bar (const char *p)
+{
+  static const char *x;
+  if (!x)
+x = p;
+  else if (p != x)
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  char a[8] = "abcdefg";
+  bar (a);
+  if (foo (a, a) != 1)
+__builtin_abort ();
+  bar (a);
+  return 0;
+}
-- 
2.7.4

[PATCH][Tree-optimization/PR89730]grant always_inline when -flive-patching=inline-only-static

[Qing Zhao]

Hi,

there is a bug in the current support for -flive-patching=inline-only-static:

it rejects inlining of external always_inline routine, therefore triggers a 
compilation time error. 

we should always inline “always_inline” routines.

please review the following simple patch, it has been bootstrapped and 
regression tested on aarch64.

Okay for committing? 

thanks.

Qing.

gcc/ChangeLog:

2019-03-20  qing zhao  

PR tree-optimization/89730
   * ipa-inline.c (can_inline_edge_p): Grant always_inline even when
   -flive-patching=inline-only-static.  

gcc/testsuite/ChangeLog:

2019-03-20  qing zhao  

* gcc.dg/live-patching-4.c: New test.



PR89730.patch
Description: Binary data

Re: [C++ PATCH] Fix lambda capture duplicate handling (PR c++/89767)

[Nathan Sidwell]

On 3/20/19 10:48 AM, Jakub Jelinek wrote:

On Wed, Mar 20, 2019 at 10:34:51AM -0400, Nathan Sidwell wrote:

On 3/19/19 2:14 PM, Jakub Jelinek wrote:

add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
bit to detect duplicate captures.
I guess in strict C++11 that could have worked, if the introducer could
contain just identifiers, but in C++14 it has 2 problems:



The following patch stops using IDENTIFIER_MARKED for this and uses a
hash_set instead.  But, as I believe lambdas with 0 (or very few) explicit
captures are extremely common, I've tried not to slow down those with
allocation of a hash_set and deallocating it again, so it uses
a linear search if there are up to 8 captures and starts using a hash_set
only when getting above that count.

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

Or do you think allocation of an hash_set and deallocation would be in a
noise?


I think it'd be in the noise.  The high bit is between zero and more than
zero captures. The next most common after zero would be 1. Besides,
identifiers are trivial to hash.


What I meant is that even just hash_set var; implies a xcalloc (13,
sizeof (void*)) or so and destroying it a free of that.
So, if 90% of all lambdas in the headers have zero captures and 5% have 1,
then simplifying the patch by adding that hash_set var; into the
lambda introducer parsing routine and just always using the hash set would
add those to the parsing of all those 95%+ lambda parsings that don't really
need that.

Here is attached completely untested variant that does that unconditional
xcalloc/free for every lambda introducer parsing.


I was unclear.  I was for the lazy creation of the hash.  I just think 
it can be lazily created at either the first or second explicit capture.


nathan

--
Nathan Sidwell

Re: [PATCH] make ggc pick up comp_dir_string() cache value. (dwarf2out.c)

[Richard Biener]

On Wed, Mar 20, 2019 at 2:44 PM Otto, Thomas  wrote
>
> > > "ggc_collect() discarding/reusing remap_debug_filename() output, thus
> > > producing invalid objects"
> >
> > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd () result
> > survives.  I vaguely remember GC being happy with heap strings (due to
> > identifiers?), but not sure.  Otherwise the patch looks obvious enough.
>
> Good point, remap_filename can return the original filename pointer (which
> can point to env["PWD"] or to an allocated string) or a ggc string.
>
> Since not freeing the string pointed to by a static variable is ok (as getpwd 
> does it),
> what about checking if remap_filename just returns the input filename ptr 
> again,
> and if not copy the ggc string into an allocated buffer.

I think we always want GC allocated storage here since the whole dwarf2out
data structures live in GC memory.  That means unconditionally copying there
as is done inside the DWARF2_DIR_SHOULD_END_WITH_SEPARATOR path.

> > How did you test it?
>
> With a file which compiled with -fdebug-prefix-map=src=OBJ and -O2 contains a
> different string than OBJ, such as "SR.7568". When removing a function from 
> the
> file it changes to e.g. "*.LC609", this is deterministic. These new strings 
> were written
> into a pointer (= *comp_dir_string_cache) returned by ggc_alloc_atomic().
>
> Disabling ggc_collect() solves it, as does this patch. Otherwise this was 
> hard to
> reproduce, the file has to be large enough and not compiling with -O2 or even 
> adding
> additional debug code made it disappear or at least unreproducible.
>
> >  The patch misses a changelog entry.
>
> Will add one.
>

Re: [C++ PATCH] Fix lambda capture duplicate handling (PR c++/89767)

[Jakub Jelinek]

On Wed, Mar 20, 2019 at 10:34:51AM -0400, Nathan Sidwell wrote:
> On 3/19/19 2:14 PM, Jakub Jelinek wrote:
> > add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
> > bit to detect duplicate captures.
> > I guess in strict C++11 that could have worked, if the introducer could
> > contain just identifiers, but in C++14 it has 2 problems:
> 
> > The following patch stops using IDENTIFIER_MARKED for this and uses a
> > hash_set instead.  But, as I believe lambdas with 0 (or very few) explicit
> > captures are extremely common, I've tried not to slow down those with
> > allocation of a hash_set and deallocating it again, so it uses
> > a linear search if there are up to 8 captures and starts using a hash_set
> > only when getting above that count.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > 
> > Or do you think allocation of an hash_set and deallocation would be in a
> > noise?
> 
> I think it'd be in the noise.  The high bit is between zero and more than
> zero captures. The next most common after zero would be 1. Besides,
> identifiers are trivial to hash.

What I meant is that even just hash_set var; implies a xcalloc (13,
sizeof (void*)) or so and destroying it a free of that.
So, if 90% of all lambdas in the headers have zero captures and 5% have 1,
then simplifying the patch by adding that hash_set var; into the
lambda introducer parsing routine and just always using the hash set would
add those to the parsing of all those 95%+ lambda parsings that don't really
need that.

Here is attached completely untested variant that does that unconditional
xcalloc/free for every lambda introducer parsing.
The previously posted patch was:
 cp/cp-tree.h   |3 +
 cp/lambda.c|   54 -
 cp/parser.c|   10 --
this variant is:
 cp/cp-tree.h   |3 ++-
 cp/lambda.c|   14 +++---
 cp/parser.c|7 ---

2019-03-20  Jakub Jelinek  

PR c++/89767
* cp-tree.h (add_capture): Add ids argument.
* parser.c (cp_parser_lambda_introducer): Add ids variable and pass
its address to add_capture calls.
* lambda.c (add_capture): Add ids argument, don't use
IDENTIFIER_MARKED, instead use ids hash_set for that.
(register_capture_members): Don't clear IDENTIFIER_MARKED here.
(add_default_capture): Adjust add_capture caller.

* g++.dg/cpp1y/lambda-init18.C: New test.
* g++.dg/cpp1y/lambda-init19.C: New test.
* g++.dg/cpp1y/pr89767.C: New test.

--- gcc/cp/cp-tree.h.jj 2019-03-19 17:10:03.135143659 +0100
+++ gcc/cp/cp-tree.h2019-03-20 15:41:53.561214488 +0100
@@ -7150,7 +7150,8 @@ extern tree lambda_return_type(tree);
 extern tree lambda_proxy_type  (tree);
 extern tree lambda_function(tree);
 extern void apply_deduced_return_type   (tree, tree);
-extern tree add_capture (tree, tree, tree, bool, bool);
+extern tree add_capture (tree, tree, tree, bool, bool,
+hash_set *);
 extern tree add_default_capture (tree, tree, tree);
 extern void insert_capture_proxy   (tree);
 extern void insert_pending_capture_proxies (void);
--- gcc/cp/parser.c.jj  2019-03-19 17:10:03.074144632 +0100
+++ gcc/cp/parser.c 2019-03-20 15:42:44.165434239 +0100
@@ -10547,6 +10547,7 @@ cp_parser_lambda_introducer (cp_parser*
error ("non-local lambda expression cannot have a capture-default");
 }
 
+  hash_set ids;
   while (cp_lexer_next_token_is_not (parser->lexer, CPP_CLOSE_SQUARE))
 {
   cp_token* capture_token;
@@ -10586,7 +10587,7 @@ cp_parser_lambda_introducer (cp_parser*
   /*id=*/this_identifier,
   /*initializer=*/finish_this_expr (),
   /*by_reference_p=*/true,
-  explicit_init_p);
+  explicit_init_p, &ids);
  continue;
}
 
@@ -10604,7 +10605,7 @@ cp_parser_lambda_introducer (cp_parser*
   /*id=*/this_identifier,
   /*initializer=*/finish_this_expr (),
   /*by_reference_p=*/false,
-  explicit_init_p);
+  explicit_init_p, &ids);
  continue;
}
 
@@ -10757,7 +10758,7 @@ cp_parser_lambda_introducer (cp_parser*
   capture_id,
   capture_init_expr,
   /*by_reference_p=*/capture_kind == BY_REFERENCE,
-  explicit_init_p);
+  explicit_init_p, &ids);
 
   /* If there is any qualification still in effect, clear it
 now; we will be starting fresh with the next capture.  */
--- gcc/cp/lambda.c.j

Re: [C++ PATCH] Fix lambda capture duplicate handling (PR c++/89767)

[Nathan Sidwell]

On 3/19/19 2:14 PM, Jakub Jelinek wrote:

Hi!

add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
bit to detect duplicate captures.
I guess in strict C++11 that could have worked, if the introducer could
contain just identifiers, but in C++14 it has 2 problems:



The following patch stops using IDENTIFIER_MARKED for this and uses a
hash_set instead.  But, as I believe lambdas with 0 (or very few) explicit
captures are extremely common, I've tried not to slow down those with
allocation of a hash_set and deallocating it again, so it uses
a linear search if there are up to 8 captures and starts using a hash_set
only when getting above that count.

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

Or do you think allocation of an hash_set and deallocation would be in a
noise?


I think it'd be in the noise.  The high bit is between zero and more 
than zero captures. The next most common after zero would be 1. 
Besides, identifiers are trivial to hash.


nathan

--
Nathan Sidwell

[C++] compiler incompatibility with lambdas

[Nathan Sidwell]

This patch addresses a compiler incompatibility with non-capturing 
lambdas.  Specifically, when a lambda's functions are comdat, we place 
the static _FUN function in the same comdat group as the operator() 
function.


This breaks link compatibility with clang, where the static function is 
named __invoker and not placed in the same group.  The case we hit was a 
link failure when the clang-generated comdat group was chosen and the 
_FUN symbol dropped.


I'm not sure of the rationale of placing them in the same group.  The 
inliner would still be correct to inline the operator() it can see into 
the _FUN body, as all comdat groups are supposed to be equivalent, so 
even if a clang-generated operator() ends up in the executable, that's 
fine to interoperate with a gcc-generated _FUN.  (we did initially think 
this was an LTO bug when it applied identical code folding to the two 
functions, as they are indeed identical)


inter-compiler interoperation of capturing lambdas is a different issue 
-- not sure if the ABI mandates layout.  But that's not relevant in this 
case as the lambda is an empty object, and that's the only case we can 
generate a static _FUN executor.


Jason, any objections for trunk?

nathan
--
Nathan Sidwell
2019-03-20  Nathan Sidwell  

	* lambda.c (maybe_add_lambda_conv_op): Don't add to comdat group.

	* g++.dg/abi/lambda-static-1.C: New.

Index: cp/lambda.c
===
--- cp/lambda.c	(revision 269818)
+++ cp/lambda.c	(working copy)
@@ -1267,12 +1267,6 @@ maybe_add_lambda_conv_op (tree type)
 
   start_preparsed_function (statfn, NULL_TREE,
 			SF_PRE_PARSED | SF_INCLASS_INLINE);
-  if (DECL_ONE_ONLY (statfn))
-{
-  /* Put the thunk in the same comdat group as the call op.  */
-  cgraph_node::get_create (statfn)->add_to_same_comdat_group
-	(cgraph_node::get_create (callop));
-}
   tree body = begin_function_body ();
   tree compound_stmt = begin_compound_stmt (0);
   if (!generic_lambda_p)
Index: testsuite/g++.dg/abi/lambda-static-1.C
===
--- testsuite/g++.dg/abi/lambda-static-1.C	(revision 0)
+++ testsuite/g++.dg/abi/lambda-static-1.C	(working copy)
@@ -0,0 +1,25 @@
+// { dg-do compile { target { c++14 && comdat_group } } }
+// { dg-additional-options -fno-inline }
+
+inline auto lamby () 
+{
+  return [] {};
+}
+
+void direct ()
+{
+  lamby ()();
+}
+
+void indirect ()
+{
+  void (*invoke) () = lamby ();
+
+  invoke ();
+}
+
+// The call operator and the static invoker should be comdat, but not
+// the same group.  (that would be a compiler incompatibility)
+
+// { dg-final { scan-assembler ".section\[\t ]*.text._ZZ5lambyvENKUlvE_clEv,\[^\n\r]*,_ZZ5lambyvENKUlvE_clEv,comdat" } }
+// { dg-final { scan-assembler ".section\[\t ]*.text._ZZ5lambyvENUlvE_4_FUNEv,\[^\n\r]*,_ZZ5lambyvENUlvE_4_FUNEv,comdat" } }

Re: [PATCH] make ggc pick up comp_dir_string() cache value. (dwarf2out.c)

[Otto, Thomas]

> > "ggc_collect() discarding/reusing remap_debug_filename() output, thus
> > producing invalid objects"
> 
> Hmm, but AFAICS it can end up on the heap if plain get_src_pwd () result
> survives.  I vaguely remember GC being happy with heap strings (due to
> identifiers?), but not sure.  Otherwise the patch looks obvious enough.

Good point, remap_filename can return the original filename pointer (which 
can point to env["PWD"] or to an allocated string) or a ggc string.

Since not freeing the string pointed to by a static variable is ok (as getpwd 
does it), 
what about checking if remap_filename just returns the input filename ptr 
again, 
and if not copy the ggc string into an allocated buffer.

> How did you test it?

With a file which compiled with -fdebug-prefix-map=src=OBJ and -O2 contains a 
different string than OBJ, such as "SR.7568". When removing a function from the 
file it changes to e.g. "*.LC609", this is deterministic. These new strings 
were written 
into a pointer (= *comp_dir_string_cache) returned by ggc_alloc_atomic().

Disabling ggc_collect() solves it, as does this patch. Otherwise this was hard 
to 
reproduce, the file has to be large enough and not compiling with -O2 or even 
adding 
additional debug code made it disappear or at least unreproducible.

>  The patch misses a changelog entry.

Will add one.

Re: [PATCH] PR ada/89583, GNAT.Sockets.Bind_Socket fails with IPv4 address

[Pierre-Marie de Rodat]

Hello Simon,

On 3/19/19 5:02 PM, Simon Wright wrote:

Ping?


Sorry for the delay! Thank you for the notice; I’ll try to get our fix 
ported as soon as possible (hopefully before the end of the week).


Cheers,

--
Pierre-Marie de Rodat

Re: [PATCH] make ggc pick up comp_dir_string() cache value. (dwarf2out.c)

[Richard Biener]

On Wed, Mar 20, 2019 at 10:36 AM Otto, Thomas  wrote:
>
> See the corresponding thread on gcc-help:
>
> "ggc_collect() discarding/reusing remap_debug_filename() output, thus 
> producing invalid objects"

Hmm, but AFAICS it can end up on the heap if plain get_src_pwd ()
result survives.  I vaguely
remember GC being happy with heap strings (due to identifiers?), but
not sure.  Otherwise
the patch looks obvious enough.

How did you test it?  The patch misses a changelog entry.

Richard.

>
> Regards
>
> Thomas
>

Re: [RFC] D support for S/390

[Iain Buclaw]

On Wed, 20 Mar 2019 at 10:57, Robin Dapp  wrote:
>
> Hi,
>
> the unicode tables in std.internal.unicode_tables are apparently auto
> generated and loaded at (libphobos) compile time.  They are also in
> little endian format.  Is the tool to generate them available somewhere?
>  I wanted to start converting them to little endian before loading but
> this will prove difficult at compile time again :)
>

Hi,

I will ask if the author still has the utility available.

My guess would be that the data used for input would have been
retrieved from here.

http://www.unicode.org/Public/4.1.0/ucd/

Will let you know as soon as I find out more.

-- 
Iain

Re: [PATCH, wwwdocs] Mention -march=armv8.5-a and other new command line options for AArch64 and Arm for GCC 9

[Sudakshina Das]

Hi Kyrill

On 12/03/2019 12:03, Kyrill Tkachov wrote:
> Hi Sudi,
> 
> On 2/22/19 10:45 AM, Sudakshina Das wrote:
>> Hi
>>
>> This patch documents the addition of the new Armv8.5-A and corresponding
>> extensions in the gcc-9/changes.html.
>> As per https://gcc.gnu.org/about.html, I have used W3 Validator.
>> Is this ok for cvs?
>>
>> Thanks
>> Sudi
> 
> 
> Index: htdocs/gcc-9/changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
> retrieving revision 1.43
> diff -u -r1.43 changes.html
> --- htdocs/gcc-9/changes.html    21 Feb 2019 10:32:55 -    1.43
> +++ htdocs/gcc-9/changes.html    21 Feb 2019 18:25:09 -
> @@ -283,6 +283,19 @@
>   
>   The intrinsics are defined by the ACLE specification.
>     
> +  
> +    The Armv8.5-A architecture is now supported. This can be used by 
> specifying the
> +   -march=armv8.5-a option.
> 
> 
> I tend to prefer the wording "... is now supported through the 
> -march=armv8.5-a option".
> Otherwise it reads as the compiler "using" the architecture, whereas we 
> usually talk about "targeting" an architecture.
> 
> +  
> +   The Armv8.5-A architecture also adds some security features that 
> are optional to all older
> +    architecture versions. These are also supported now and only effect 
> the assembler.
> +    
> +     Speculation Barrier instruction using 
> -march=armv8-a+sb.
> +     Execution and Data Prediction Restriction instructions using 
> -march=armv8-a+predres.
> +     Speculative Store Bypass Safe instruction using 
> -march=armv8-a+ssbs. This does not
> + require a compiler option for Arm and thus 
> -march=armv8-a+ssbs is a AArch64 specific option.
> 
> "AArch64-specific"
> 
> 
> LGTM otherwise.
> Thanks,
> Kyrill

Thanks for the review and sorry for the delay in response. I had edited 
the language for adding new options in a few other places as well.

Thanks
Sudi

> 
> +    
> +  
>   
> 
>   AArch64 specific
> @@ -298,6 +311,22 @@
>   The default value is 16 (64Kb) and can be changed at configure
>   time using the flag 
> --with-stack-clash-protection-guard-size=12|16.
>     
> +  
> +    The option -msign-return-address= has been deprecated. 
> This has been replaced
> +    by the new -mbranch-protection= option. This new 
> option can now be used to
> +    enable the return address signing as well as the new Branch Target 
> Identification
> +    feature of Armv8.5-A architecture. For more information on the 
> arguments accepted by
> +    this option, please refer to
> +  href="https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options";>
>  
> 
> +    AArch64-Options.
> +  
> +   The following optional extensions to Armv8.5-A architecture are 
> also supported now and
> +   only effect the assembler.
> +    
> +     Random Number Generation instructions using 
> -march=armv8.5-a+rng.
> +     Memory Tagging Extension using 
> -march=armv8.5-a+memtag.
> +    
> +  
>   
> 
>   Arm specific
> 

Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.52
diff -u -r1.52 changes.html
--- htdocs/gcc-9/changes.html	7 Mar 2019 14:40:06 -	1.52
+++ htdocs/gcc-9/changes.html	18 Mar 2019 18:55:24 -
@@ -342,6 +342,24 @@
 
 The intrinsics are defined by the ACLE specification.
   
+  
+The Armv8.5-A architecture is now supported through the
+-march=armv8.5-a option.
+  
+   The Armv8.5-A architecture also adds some security features that are
+optional to all older architecture versions. These are also supported now
+and only effect the assembler.
+
+	 Speculation Barrier instruction through the
+	 -march=armv8-a+sb option.
+	 Execution and Data Prediction Restriction instructions through
+	 the -march=armv8-a+predres option.
+	 Speculative Store Bypass Safe instruction through the
+	 -march=armv8-a+ssbs option. This does not require a
+	 compiler option for Arm and thus -march=armv8-a+ssbs
+	 is an AArch64-specific option.
+
+  
 
 
 AArch64 specific
@@ -362,6 +380,23 @@
 The default value is 16 (64Kb) and can be changed at configure
 time using the flag --with-stack-clash-protection-guard-size=12|16.
   
+  
+The option -msign-return-address= has been deprecated. This
+has been replaced by the new -mbranch-protection= option. This
+new option can now be used to enable the return address signing as well as
+the new Branch Target Identification feature of Armv8.5-A architecture. For
+more information on the arguments accepted by this option, please refer to
+ https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options";>AArch64-Options.
+  
+   The following optional extensions to Armv8.5-A architecture are also
+   supported now and only effect the assembler.
+
+	 Random Number Generation instruct

Re: [PR72741] Encode OpenACC 'routine' directive's level of parallelism inside Fortran module files

[Thomas Schwinge]

Hi!

Are there any further questions, or am I good to commit my patch as
posted?

On Thu, 14 Mar 2019 08:38:30 +0100, I wrote:
> On Wed, 13 Mar 2019 23:13:46 +0100, Thomas Koenig  
> wrote:
> > Am 13.03.19 um 18:50 schrieb Thomas Schwinge:
> > >> There are many ways to deal with it without bumping MOD_VERSION in a
> > >> backwards but not forwards compatible way, so that a newer compiler will 
> > >> be
> > >> able to parse old *.mod files, and newer compiler new ones as long as 
> > >> this
> > >> problematic stuff doesn't appear in.
> > > Like the attached, actually pretty simple now?
> > 
> > Can you explain a) how this works
> 
> I'll be happy to elaborate, but I'm not sure at which level you'd like me
> to explain?
> 
> This is basically the very same thing that's being done for other 'struct
> symbol_attribute' flag fields, by interpreting the 'enum
> oacc_routine_lop' values as individual flags, and with the corollary (to
> maintain MOD_VERSION compatibility as best as we can) that we don't
> stream out its default value (so doing correspondingly to when a "real"
> flag's value is 'false').
> 
> > and b) how you tested it?
> 
> I had mentioned that in the commit message: with the relevant old/new GCC
> combinations, using the included test case.
> 
> Happy to explain further, if necessary.


Grüße
 Thomas

[PATCH] [PR89773] Fortran OpenACC 'routine' directive refuses procedures with implicit EXTERNAL attribute

[Thomas Schwinge]

Hi!

On Fri, 26 Aug 2016 08:16:43 -0700, Cesar Philippidis  
wrote:
> While working on [...], I noticed

If only all such issues would end up in their own PRs, instead of mixing
them with other changes...

> that the fortran FE wasn't permitting
> named functions inside acc routine directives. E.g.
> 
>   integer :: foo
>   !$acc routine(foo) gang
> 
>   ... = foo ()

ACK.  Perhaps not the most pretty style, but gfortran does accept this.

Do I understand right that there exists no equivalent syntax in Fortran
to declare a subroutine (instead of a function) with implicit EXTERNAL
attribute?  (See also the new 'gfortran.dg/goacc/pr89773.f90' test case
I'm adding.)

> This patch also fixes this issue. But to do that, I had to add a
> gfc_resolve_oacc_routines pass in order to identify if a variable is a
> function or variable because that information isn't available during
> matching.

OK to fix this as in the attached patch?  If approving this patch, please
respond with "Reviewed-by: NAME " so that your effort will be
recorded in the commit log, see .


Grüße
 Thomas


>From 38d953f51280e6fc327af6b8e35e10ef5d70d589 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 20 Mar 2019 10:58:58 +0100
Subject: [PATCH] [PR89773] Fortran OpenACC 'routine' directive refuses
 procedures with implicit EXTERNAL attribute

	gcc/fortran/
	PR fortran/89773
	* gfortran.h (gfc_oacc_routine_name): Add loc member.
	(gfc_resolve_oacc_routines): Declare.
	* openmp.c (gfc_match_oacc_routine): Move some error checking
	into...
	(gfc_resolve_oacc_routines): ... this new function.
	* resolve.c (resolve_codes): Call it.
	gcc/testsuite/
	PR fortran/89773
	* gfortran.dg/goacc/pr89773.f90: New file.
	* gfortran.dg/goacc/pr77765.f90: Adjust.
	* gfortran.dg/goacc/routine-6.f90: Adjust, and extend.
---
 gcc/fortran/gfortran.h|  2 ++
 gcc/fortran/openmp.c  | 30 +++-
 gcc/fortran/resolve.c |  1 +
 gcc/testsuite/gfortran.dg/goacc/pr77765.f90   |  2 +-
 gcc/testsuite/gfortran.dg/goacc/pr89773.f90   | 36 +++
 gcc/testsuite/gfortran.dg/goacc/routine-6.f90 | 21 +--
 6 files changed, 80 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/goacc/pr89773.f90

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 2f55b9c387a6..caf5e528c7e0 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1739,6 +1739,7 @@ typedef struct gfc_oacc_routine_name
   struct gfc_symbol *sym;
   struct gfc_omp_clauses *clauses;
   struct gfc_oacc_routine_name *next;
+  locus loc;
 }
 gfc_oacc_routine_name;
 
@@ -3210,6 +3211,7 @@ void gfc_resolve_oacc_directive (gfc_code *, gfc_namespace *);
 void gfc_resolve_oacc_declare (gfc_namespace *);
 void gfc_resolve_oacc_parallel_loop_blocks (gfc_code *, gfc_namespace *);
 void gfc_resolve_oacc_blocks (gfc_code *, gfc_namespace *);
+void gfc_resolve_oacc_routines (gfc_namespace *);
 
 /* expr.c */
 void gfc_free_actual_arglist (gfc_actual_arglist *);
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 7a06eb58f5cf..69b05084dc06 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2319,15 +2319,10 @@ gfc_match_oacc_routine (void)
 	sym = NULL;
 	}
 
-	  if ((isym == NULL && st == NULL)
-	  || (sym
-		  && !sym->attr.external
-		  && !sym->attr.function
-		  && !sym->attr.subroutine))
+	  if (isym == NULL && st == NULL)
 	{
-	  gfc_error ("Syntax error in !$ACC ROUTINE ( NAME ) at %C, "
-			 "invalid function name %s",
-			 (sym) ? sym->name : buffer);
+	  gfc_error ("Invalid NAME %qs in !$ACC ROUTINE ( NAME ) at %C",
+			 buffer);
 	  gfc_current_locus = old_loc;
 	  return MATCH_ERROR;
 	}
@@ -2397,6 +2392,7 @@ gfc_match_oacc_routine (void)
 	  n->sym = sym;
 	  n->clauses = c;
 	  n->next = gfc_current_ns->oacc_routine_names;
+	  n->loc = old_loc;
 	  gfc_current_ns->oacc_routine_names = n;
 	}
 }
@@ -6069,6 +6065,24 @@ gfc_resolve_oacc_declare (gfc_namespace *ns)
 }
 }
 
+
+void
+gfc_resolve_oacc_routines (gfc_namespace *ns)
+{
+  for (gfc_oacc_routine_name *orn = ns->oacc_routine_names;
+   orn;
+   orn = orn->next)
+{
+  gfc_symbol *sym = orn->sym;
+  if (!sym->attr.external
+	  && !sym->attr.function
+	  && !sym->attr.subroutine)
+	gfc_error ("NAME %qs does not refer to a subroutine or function"
+		   " in !$ACC ROUTINE ( NAME ) at %L", sym->name, &orn->loc);
+}
+}
+
+
 void
 gfc_resolve_oacc_directive (gfc_code *code, gfc_namespace *ns ATTRIBUTE_UNUSED)
 {
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 7539aa7038c4..e1cd2007e59a 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -16818,6 +16818,7 @@ resolve_codes (gfc_namespace *ns)
   bitmap_obstack_initialize (&labels_obstack);
 
   gfc_resolve_oacc_declare (ns);
+  gfc_resolve_oacc_routines (ns);
   gfc_resolve_omp_local_vars (ns);
   gfc_resol

Re: [RFC] D support for S/390

[Robin Dapp]

Hi,

the unicode tables in std.internal.unicode_tables are apparently auto
generated and loaded at (libphobos) compile time.  They are also in
little endian format.  Is the tool to generate them available somewhere?
 I wanted to start converting them to little endian before loading but
this will prove difficult at compile time again :)

Regards
 Robin

[PATCH] make ggc pick up comp_dir_string() cache value. (dwarf2out.c)

[Otto, Thomas]

See the corresponding thread on gcc-help:

"ggc_collect() discarding/reusing remap_debug_filename() output, thus producing 
invalid objects"


Regards

Thomas



make-ggc-pick-up-comp_dir_string-cache-value.patch
Description: make-ggc-pick-up-comp_dir_string-cache-value.patch

Re: A bug in vrp_meet?

[Richard Biener]

On Tue, Mar 19, 2019 at 8:53 PM Jeff Law  wrote:
>
> On 3/6/19 3:05 AM, Richard Biener wrote:
> > On Tue, Mar 5, 2019 at 10:36 PM Jeff Law  wrote:
> >>
> >> On 3/5/19 7:44 AM, Richard Biener wrote:
> >>
> >>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> >>> the MAX_EXPR introduced by folding makes it somewhat ugly.
> >>>
> >>> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> >>>
> >>> Any ideas how to make it less so?  I can split out making optimize_stmt
> >>> take a gsi * btw, in case that's a more obvious change and it makes the
> >>> patch a little smaller.
> >>>
> >>> Richard.
> >>>
> >>> 2019-03-05  Richard Biener  
> >>>
> >>> PR tree-optimization/89595
> >>> * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take
> >>> stmt iterator as reference, take boolean output parameter to
> >>> indicate whether the stmt was removed and thus the iterator
> >>> already advanced.
> >>> (dom_opt_dom_walker::before_dom_children): Re-iterate over
> >>> stmts created by folding.
> >>>
> >>> * gcc.dg/torture/pr89595.c: New testcase.
> >>>
> >>
> >> Well, all the real logic changs are in the before_dom_children method.
> >> The bits in optimize_stmt are trivial enough to effectively ignore.
> >>
> >> I don't see a better way to discover and process statements that are
> >> created in the bowels of fold_stmt.
> >
> > I'm not entirely happy so I created the following alternative which
> > is a bit larger and slower due to the pre-pass clearing the visited flag
> > but is IMHO easier to follow.  I guess there's plenty of TLC opportunity
> > here but then I also hope to retire the VN parts of DOM in favor
> > of the non-iterating RPO-VN code...
> >
> > So - I'd lean to this variant even though it has the extra loop over stmts,
> > would you agree?
> >
> > Bootstrap / regtest running on x86_64-unknown-linux-gnu.
> >
> > Richard.
> >
> > 2019-03-06  Richard Biener  
> >
> > PR tree-optimization/89595
> > * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take
> > stmt iterator as reference, take boolean output parameter to
> > indicate whether the stmt was removed and thus the iterator
> > already advanced.
> > (dom_opt_dom_walker::before_dom_children): Re-iterate over
> > stmts created by folding.
> >
> > * gcc.dg/torture/pr89595.c: New testcase.
> This one is easier to follow from a logic standpoint.  I don't think the
> gimple_set_visited bits are going to be terribly expensive in general.
>
> Is that flag in a known state for new statements?  I'm guessing it's
> cleared by some structure-sized memset as we create the raw statement?

Yes, it's of course not documented that way but IMHo the only reasonable
state.

> Might be worth clarifying that in the comments in gimple.h.
>
> jeff
>