Go patch committed: Compare parse methods when exporting interface types

[Ian Lance Taylor]

This patch by Than McIntosh fixes the Go frontend to compare parse
methods when indexing interface types for export.  This change fixes a
bug in which two interface types were being incorrectly commoned
(considered identical) in the initial stages of writing out types to
export data.  The indexer does a walk to collect candidates for
export, inserting types into a table to eliminate duplicates; as part
of this process a local interface type T1 was being commoned with a
different interface type T2.  This caused a cycle in the exported type
graph due to the way embedded interfaces are handled.

The fix was to add a new flag to the Type::is_identical utility
routine to request that interface type comparison be done by examining
the original parse methods, as opposed to the expanded method set,
then use the new flag when creating the hash map for the exporter.

The test case for this is https://golang.org/cl/166917.

This fixes https://golang.org/issue/30659.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269633)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-565b5cd0f49a00ca20941ea042c07ebe6ddf3553
+946aa5ab2e82d045a2a3b2f18ba2c5b00e957c4b
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/export.cc
===
--- gcc/go/gofrontend/export.cc (revision 269619)
+++ gcc/go/gofrontend/export.cc (working copy)
@@ -60,6 +60,7 @@ class Type_hash_alias_identical
 return type->hash_for_method(NULL,
 (Type::COMPARE_ERRORS
  | Type::COMPARE_TAGS
+ | Type::COMPARE_EMBEDDED_INTERFACES
  | Type::COMPARE_ALIASES));
   }
 };
@@ -73,6 +74,7 @@ class Type_alias_identical
 return Type::are_identical(t1, t2,
   (Type::COMPARE_ERRORS
| Type::COMPARE_TAGS
+| Type::COMPARE_EMBEDDED_INTERFACES
| Type::COMPARE_ALIASES),
   NULL);
   }
@@ -295,6 +297,16 @@ Find_types_to_prepare::type(Type* type)
   if (type->is_abstract())
 return TRAVERSE_SKIP_COMPONENTS;
 
+  // For interfaces make sure that embedded methods are sorted, since the
+  // comparison function we use for indexing types relies on it (this call has
+  // to happen before the set_type_index call below).
+  if (type->classification() == Type::TYPE_INTERFACE)
+{
+  Interface_type* it = type->interface_type();
+  if (it != NULL)
+it->sort_embedded();
+}
+
   if (!this->exp_->set_type_index(type))
 {
   // We've already seen this type.
@@ -408,6 +420,9 @@ Export::prepare_types(const std::vector<
 {
   if (!(*p)->is_type())
continue;
+  Interface_type* it = (*p)->type_value()->interface_type();
+  if (it != NULL)
+it->sort_embedded();
   this->set_type_index((*p)->type_value());
 }
 
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 269633)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -8808,10 +8808,19 @@ Interface_type::is_identical(const Inter
   if (!this->methods_are_finalized_ || !t->methods_are_finalized_)
 return false;
 
+  // Consult a flag to see whether we need to compare based on
+  // parse methods or all methods.
+  Typed_identifier_list* methods = (((flags & COMPARE_EMBEDDED_INTERFACES) != 
0)
+ ? this->parse_methods_
+  : this->all_methods_);
+  Typed_identifier_list* tmethods = (((flags & COMPARE_EMBEDDED_INTERFACES) != 
0)
+  ? t->parse_methods_
+  : t->all_methods_);
+
   // We require the same methods with the same types.  The methods
   // have already been sorted.
-  if (this->all_methods_ == NULL || t->all_methods_ == NULL)
-return this->all_methods_ == t->all_methods_;
+  if (methods == NULL || tmethods == NULL)
+return methods == tmethods;
 
   if (this->assume_identical(this, t) || t->assume_identical(t, this))
 return true;
@@ -8823,11 +8832,11 @@ Interface_type::is_identical(const Inter
   ai.next = hold_ai;
   this->assume_identical_ = &ai;
 
-  Typed_identifier_list::const_iterator p1 = this->all_methods_->begin();
+  Typed_identifier_list::const_iterator p1 = methods->begin();
   Typed_identifier_list::const_iterator p2;
-  for (p2 = t->all_methods_->begin(); p2 != t->all_methods_->end(); ++p1, ++p2)
+  for (p2 = tmethods->begin(); p2 != tmethods->end(); ++p1, ++p2)
 {
-  if (p1 == this->a

Go patch committed: Add debugging helper function debug_go_type

[Ian Lance Taylor]

This patch to the Go frontend by Than McIntosh adds a new debugging
helper function debug_go_type.  This is intended to display the
contents of a Type object in a way useful to debugging a run of the
compiler.  Prior to this the only useful alternative for debugging
types was invoking the mangled_name method, which has problems (for
example, won't work on interface types prior to finalizing of
methods).  This is a "deep" dump, meaning that all types reachable
from the type passed to debug_go_type() will be printed out.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269619)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-3106ec19626d75d8275be16c86421132548fa13e
+565b5cd0f49a00ca20941ea042c07ebe6ddf3553
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/ast-dump.cc
===
--- gcc/go/gofrontend/ast-dump.cc   (revision 269619)
+++ gcc/go/gofrontend/ast-dump.cc   (working copy)
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 
 #include "gogo.h"
 #include "expressions.h"
@@ -580,3 +581,382 @@ debug_go_block_deep(const Block* block)
   Block* ncblock = const_cast(block);
   adc.dump_block(ncblock);
 }
+
+class Type_dumper
+{
+  typedef Unordered_map(const Type*, unsigned) idx_map;
+ public:
+  Type_dumper(const Type* type)
+  : top_(type), ntypes_(0)
+  {
+this->worklist_.push_back(type);
+  }
+
+  void visit();
+
+  std::string stringResult() { return ss_.str(); }
+
+ private:
+  void emitpre(unsigned tag, const Type* addr);
+  void typeref(const char*, const Type*, const char *);
+  void visit_forward_declaration_type(const Forward_declaration_type* fdt);
+  void visit_function_type(const Function_type* ft);
+  void visit_struct_type(const Struct_type* st);
+  void visit_array_type(const Array_type* at);
+  void visit_map_type(const Map_type* mt);
+  void visit_channel_type(const Channel_type* mt);
+  void visit_interface_type(const Interface_type* mt);
+  void visit_methods(const Typed_identifier_list* methods,
+ const char *tag);
+  std::pair lookup(const Type*);
+
+  static constexpr unsigned notag = 0x;
+
+ private:
+  const Type* top_;
+  idx_map types_;
+  unsigned ntypes_;
+  std::list worklist_;
+  std::ostringstream ss_;
+};
+
+// Look up a type, installing it in 'types_'. Return is 
+// where 'found' is true if type had been previously recorded, and N
+// is the index/tag assigned to N.  The input argument is appended to
+// the work list if this is the first time we've seen it.
+
+std::pair Type_dumper::lookup(const Type* t)
+{
+  std::pair entry = std::make_pair(t, this->ntypes_);
+  std::pair ins = this->types_.insert(entry);
+  if (ins.second)
+{
+  this->ntypes_++;
+  if (t != this->top_)
+this->worklist_.push_back(t);
+}
+  return std::make_pair(ins.second, ins.first->second);
+}
+
+// Emit preamble prior to dumping a type, including the type
+// pointer itself and the tag we've assigned it.  If no
+// tag is specified (via special "notag" value) and/or the
+// pointer is null, then just emit an equivalent amount
+// of spaces.
+
+void Type_dumper::emitpre(unsigned tag, const Type* ptr)
+{
+  char tbuf[50], pbuf[50], buf[200];
+
+  tbuf[0] = '\0';
+  if (tag != notag)
+snprintf(tbuf, sizeof tbuf, "T%u", tag);
+
+  pbuf[0] = '\0';
+  if (ptr != NULL)
+snprintf(pbuf, sizeof pbuf, "%p", (const void*) ptr);
+
+  snprintf(buf, sizeof buf, "%8s %16s  ", tbuf, pbuf);
+  this->ss_ << buf;
+}
+
+// Emit a reference to a type into the dump buffer. In most cases this means
+// just the type tag, but for named types we also emit the name, and for
+// simple/primitive types (ex: int64) we emit the type itself. If "pref" is
+// non-NULL, emit the string prior to the reference, and if "suf" is non-NULL,
+// emit it following the reference.
+
+void Type_dumper::typeref(const char* pref, const Type* t, const char* suf)
+{
+  if (pref != NULL)
+this->ss_ << pref;
+  std::pair p = this->lookup(t);
+  unsigned tag = p.second;
+  switch (t->classification())
+{
+  case Type::TYPE_NAMED:
+{
+  const Named_type* nt = t->named_type();
+  const Named_object* no = nt->named_object();
+  this->ss_ << "'" << no->message_name() << "' -> ";
+  const Type* underlying = nt->real_type();
+  this->typeref(NULL, underlying, NULL);
+  break;
+}
+  case Type::TYPE_POINTER:
+this->typeref("*", t->points_to(), NULL);
+break;
+  case Type::TYPE_ERROR:
+this->ss_ << "error_type";
+break;
+  case Type::TYPE_INTEGER:
+{
+  const Integer_type* it = t->integer_type();
+  if (it

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Joseph Myers]

On Tue, 12 Mar 2019, Hans-Peter Nilsson wrote:

> When is it appropriate to make the user add -latomic to link
> their program?  Perhaps different answers for fortran and C++.
> I'm guessing "always when using any atomic construct" for C.

I think we should link with --as-needed -latomic --no-as-needed by default 
when --as-needed is supported (see bug 81358).

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

Re: [PATCH] Loop split upon semi-invariant condition (PR tree-optimization/89134)

[Feng Xue OS]

Richard,

Thanks for your comment. Yes, it is like kind of jump threading with 
knowledge of loop structure. And what is rough time for GCC 10?


Regards,

Feng



From: Richard Biener 
Sent: Tuesday, March 12, 2019 4:31:49 PM
To: Feng Xue OS
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Loop split upon semi-invariant condition (PR 
tree-optimization/89134)

On Tue, Mar 12, 2019 at 7:20 AM Feng Xue OS  wrote:
>
> This patch is composed to implement a loop transformation on one of its 
> conditional statements, which we call it semi-invariant, in that its 
> computation is impacted in only one of its branches.
>
> Suppose a loop as:
>
> void f (std::map m)
> {
> for (auto it = m.begin (); it != m.end (); ++it) {
> /* if (b) is semi-invariant. */
> if (b) {
> b = do_something();/* Has effect on b */
> } else {
> /* No effect on b */
> }
> statements;  /* Also no effect on b */
> }
> }
>
> A transformation, kind of loop split, could be:
>
> void f (std::map m)
> {
> for (auto it = m.begin (); it != m.end (); ++it) {
> if (b) {
> b = do_something();
> } else {
> ++it;
> statements;
> break;
> }
> statements;
> }
>
> for (; it != m.end (); ++it) {
> statements;
> }
> }
>
> If "statements" contains nothing, the second loop becomes an empty one, which 
> can be removed. (This part will be given in another patch). And if 
> "statements" are straight line instructions, we get an opportunity to 
> vectorize the second loop. In practice, this optimization is found to improve 
> some real application by %7.
>
> Since it is just a kind of loop split, the codes are mainly placed in 
> existing tree-ssa-loop-split module, and is controlled by -fsplit-loop, and 
> is enabled with -O3.

Note the transform itself is jump-threading with the threading
duplicating a whole CFG cycle.

I didn't look at the patch details yet since this is suitable for GCC 10 only.

Thanks for implementing this.
Richard.

> Feng
>
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 64bf6017d16..a6c2878d652 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,23 @@
> +2019-03-12  Feng Xue 
> +
> +   PR tree-optimization/89134
> +* doc/invoke.texi (max-cond-loop-split-insns): Document new --params.
> +   (min-cond-loop-split-prob): Likewise.
> +   * params.def: Add max-cond-loop-split-insns, min-cond-loop-split-prob.
> +   * passes.def (pass_cond_loop_split) : New pass.
> +   * timevar.def (TV_COND_LOOP_SPLIT): New time variable.
> +   * tree-pass.h (make_pass_cond_loop_split): New declaration.
> +   * tree-ssa-loop-split.c (split_info): New class.
> +   (find_vdef_in_loop, vuse_semi_invariant_p): New functions.
> +   (ssa_semi_invariant_p, stmt_semi_invariant_p): Likewise.
> +   (can_branch_be_excluded, get_cond_invariant_branch): Likewise.
> +   (is_cond_in_hidden_loop, compute_added_num_insns): Likewise.
> +   (can_split_loop_on_cond, mark_cond_to_split_loop): Likewise.
> +   (split_loop_for_cond, tree_ssa_split_loops_for_cond): Likewise.
> +   (pass_data_cond_loop_split): New variable.
> +   (pass_cond_loop_split): New class.
> +   (make_pass_cond_loop_split): New function.
> +
>  2019-03-11  Jakub Jelinek  
>
> PR middle-end/89655
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index df0883f2fc9..f5e09bd71fd 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -11316,6 +11316,14 @@ The maximum number of branches unswitched in a 
> single loop.
>  @item lim-expensive
>  The minimum cost of an expensive expression in the loop invariant motion.
>
> +@item max-cond-loop-split-insns
> +The maximum number of insns to be increased due to loop split on
> +semi-invariant condition statement.
> +
> +@item min-cond-loop-split-prob
> +The minimum threshold for probability of semi-invaraint condition
> +statement to trigger loop split.
> +
>  @item iv-consider-all-candidates-bound
>  Bound on number of candidates for induction variables, below which
>  all candidates are considered for each use in induction variable
> diff --git a/gcc/params.def b/gcc/params.def
> index 3f1576448be..2e067526958 100644
> --- a/gcc/params.def
> +++ b/gcc/params.def
> @@ -386,6 +386,18 @@ DEFPARAM(PARAM_MAX_UNSWITCH_LEVEL,
> "The maximum number of unswitchings in a single loop.",
> 3, 0, 0)
>
> +/* The maximum number of increased insns due to loop split on semi-invariant
> +   condition statement.  */
> +DEFPARAM(PARAM_MAX_COND_LOOP_SPLIT_INSNS,
> +   "max-cond-loop-split-insns",
> +   "The maximum number of insns to be increased due to loop split on 

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Hans-Peter Nilsson]

Regarding this sometimes-add--latomic(-in-testsuite) that is
revisited:

When is it appropriate to make the user add -latomic to link
their program?  Perhaps different answers for fortran and C++.
I'm guessing "always when using any atomic construct" for C.

I had a grep-look in gcc/doc before asking; I can't see we say
anything.

I don't think "when the target lacks certain atomic features" is
a full valid answer, except pragmatically, to paper over a bug.

brgds, H-P
PS. I'll do the patch if you (someone) does the words.

Re: [PR fortran/87045, patch] - pointer to array of character

[Steve Kargl]

On Sun, Mar 10, 2019 at 10:19:03PM +0100, Harald Anlauf wrote:
> The code in the testcase died due to a run-time bounds-check
> generated slightly too early, leading to a crash for deferred
> character length.  Moving the character length check after the
> assignment solves the issue.
> 
> Regtests cleanly on x86_64-pc-linux-gnu.
> 
> OK for trunk?
> 

OK.

-- 
Steve

Re: [patch, fortran] Fix PR 66695, 77746 and 79485

[Steve Kargl]

On Tue, Mar 12, 2019 at 10:42:21PM +0100, Thomas Koenig wrote:
> 
> the attached patch fixes three very closely related 7/8/9 regressions.
> The common root cause of these PRs was that , if a binding label
> existed, gfc_get_extern_function_decl first looked for that name
> in the global symbol table for that function and used its backend_decl.
> If there was a module procedure with the same name as the BIND(C)
> routine (perfectly legal), the wrong procedure would then be called.
> 
> The approach is straightforward: In the global symbol table, record
> whether we are looking at a "normal" or a BIND(C) name, and if we
> come across the wrong kind of entry in gfc_get_extern_function_decl,
> just ignore it.
> 
> Regressoin-tested. OK for trunk?

Looks good to me.

-- 
Steve

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

[Steve Kargl]

On Tue, Mar 12, 2019 at 11:19:07PM +0100, Thomas Koenig wrote:
> Hi Harald,
> 
> > how about the attached version?  It is quite verbose and produces
> > messages like
> > 
> > Error: Expected list of 'lower-bound-expr:' or list of
> > 'lower-bound-expr:upper-bound-expr' at (1)
> 
> I think this way of specifying error messages
> 
> +#define BOUNDS_SPEC_LIST "list of %"
> 
> ...
> 
> +   gfc_error ("Rank remapping requires a "
> +  BOUNDS_SPEC_LIST " at %L",
>&lvalue->where);
> 
> will cause trouble in translation of the error messages.
> 

I agree with Thomas here.  We should try to make the
translation of error message as painless as possible.

-- 
Steve

[PATCH, d] Committed small tidy up gdc testsuite scripts

[Iain Buclaw]

Hi,

This patch moves the one -fsantize=undefined test to a new ubsan test
directory, guarded by check_effective_target_fsanitize_undefined.

Another recent change to gdc_include_flags left one variable unused,
also noticed that flags was never explicitly returned.  Both have been
fixed up.

Changes tested on x86_64-linux-gnu and committed as obvious to trunk as r269632.

-- 
Iain
---
gcc/testsuite/ChangeLog:

2019-03-13  Iain Buclaw  

* gdc.dg/pr88957.d: Move to gdc.dg/ubsan.
* gdc.dg/ubsan/ubsan.exp: New file.
* lib/gdc.exp (gdc_include_flags): Remove unused target variable.
Explicitly return flags from procedure.
---
diff --git a/gcc/testsuite/gdc.dg/pr88957.d b/gcc/testsuite/gdc.dg/pr88957.d
deleted file mode 100644
index e6366d463b2..000
--- a/gcc/testsuite/gdc.dg/pr88957.d
+++ /dev/null
@@ -1,18 +0,0 @@
-// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957
-// { dg-do compile }
-// { dg-additional-options "-fsanitize=undefined" }
-
-alias int4 = __vector(int[4]);
-
-int fn(const int[4] x)
-{
-int sum = 0;
-foreach (i; x) sum += i;
-return sum;
-}
-
-void pr88957()
-{
-auto x = fn(int4.init.array);
-auto y = fn(int4(2).array);
-}
diff --git a/gcc/testsuite/gdc.dg/ubsan/pr88957.d b/gcc/testsuite/gdc.dg/ubsan/pr88957.d
new file mode 100644
index 000..e6366d463b2
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/ubsan/pr88957.d
@@ -0,0 +1,18 @@
+// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957
+// { dg-do compile }
+// { dg-additional-options "-fsanitize=undefined" }
+
+alias int4 = __vector(int[4]);
+
+int fn(const int[4] x)
+{
+int sum = 0;
+foreach (i; x) sum += i;
+return sum;
+}
+
+void pr88957()
+{
+auto x = fn(int4.init.array);
+auto y = fn(int4(2).array);
+}
diff --git a/gcc/testsuite/gdc.dg/ubsan/ubsan.exp b/gcc/testsuite/gdc.dg/ubsan/ubsan.exp
new file mode 100644
index 000..a2e2da017cc
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/ubsan/ubsan.exp
@@ -0,0 +1,32 @@
+#   Copyright (C) 2019 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# Load support procs.
+load_lib gdc-dg.exp
+load_lib ubsan-dg.exp
+
+# Initialize `dg'.
+dg-init
+ubsan_init
+
+# Main loop.
+if [check_effective_target_fsanitize_undefined] {
+  gdc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.d]] "" ""
+}
+
+# All done.
+ubsan_finish
+dg-finish
diff --git a/gcc/testsuite/lib/gdc.exp b/gcc/testsuite/lib/gdc.exp
index f5957c3d2ee..e09f5ee987a 100644
--- a/gcc/testsuite/lib/gdc.exp
+++ b/gcc/testsuite/lib/gdc.exp
@@ -78,7 +78,6 @@ proc gdc_include_flags { paths } {
 }
 
 set gccpath ${paths}
-set target [file tail [file normalize ${paths}]]
 
 if { $gccpath != "" } {
 	if [file exists "${gccpath}/libphobos/libdruntime"] {
@@ -95,6 +94,8 @@ proc gdc_include_flags { paths } {
 	set idx [lsearch $cxxflags "-nostdinc++"]
 	append flags [lreplace $cxxflags $idx $idx]
 }
+
+return "$flags"
 }
 
 #

Re: [PATCH, d/87824]: x86_64-linux multilib issues

[Iain Buclaw]

On Tue, 12 Mar 2019 at 20:57, Rainer Orth  wrote:
>
> Hi Iain,
>
> > On Tue, 12 Mar 2019 at 18:27, Uros Bizjak  wrote:
> >>
> >> Attached patch fixes libstdc++ includes for multilib d testsuite and
> >> fixes runnable/cppa.d testsuite failure with 32bit multilib on
> >> x86_64-linux-gnu.
> >>
> >>
> >> 2019-03-12  Uroš Bizjak  
> >>
> >> PR d/87824
> >> * lib/gdc.exp (gdc_include_flags): Find C++ headers by calling
> >> libstdc++v3/scripts/testsuite_flags.  Filter out unsupported
> >> -nostdinc++ flag.
> >>
> >> Tested on x86_64-linux-gnu {,-m32}.
> >>
> >> OK for mainline?
> >>
> >
> > OK, thanks.
>
> I just noticed that the `set target' in gdc_include_flags is now unused
> and can be removed.
>

And now that you point it out, I see that gdc_include_flags doesn't
return anything either, and yet the testsuite passes.

I'll ignore whatever chicanery is going on in tcl here, and have fixed up both.

-- 
Iain

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

[Jakub Jelinek]

On Tue, Mar 12, 2019 at 11:21:26PM +, Steve Ellcey wrote:
> I like this idea.  I have prototyped something, I created 'vector_asm'
> as an aarch64 attribute because I couldn't find where to put global
> attributes like __simd__.  Does anyone know where these are listed?

gcc/c-family/c-attribs.c

Note, vector_asm seems like a bad name when the attribute is simd
or directive #pragma omp declare simd, it should be simd_asm instead.

If we go this route, glibc headers would need to use it conditional on gcc
version though, because older gccs wouldn't support that attribute.

Jakub

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[John David Anglin]

On 2019-03-12 7:05 p.m., Jonathan Wakely wrote:
> On 12/03/19 23:01 +, Joseph Myers wrote:
>> On Mon, 11 Mar 2019, Jonathan Wakely wrote:
>>
>>> +proc add_options_for_libatomic { flags } {
>>> +    if { [istarget hppa*-*-hpux*] } {
>>> +   return "$flags -L../../libatomic/.libs -latomic"
>>> +    } option.
>>
>> It's generally inappropriate to hardcode such ../../libatomic/.libs paths
>> without making sure it's for build-tree rather than installed testing (for
>> installed testing, -latomic can be found without any -L option and it's
>> the board file's responsibility to set LD_LIBRARY_PATH if necessary).
>
> I was going to say something about that, but then saw we already do it
> for libgomp/.libs as well. Two wrongs now though ..
I just installed the change before I saw Joseph's comment.  I don't believe 
-latomic can be
found without a -L option in the libstdc++ testsuite.  That's why it's done for 
libgomp.

However, it's not needed for c, c++, fortran testsuites.  They also setup 
LD_LIBRARY_PATH
for testing in build tree.  I've never had to use a board file to get this 
right.

-- 
John David Anglin  dave.ang...@bell.net

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

[Steve Ellcey]

On Tue, 2019-03-12 at 14:17 +, Joseph Myers wrote:
> 
> On Tue, 12 Mar 2019, Richard Biener wrote:
> 
> > It shouldn't be difficult to provide an alias from the glibc side, no?  
> > How does x86 avoid this issue?
> 
> There are static-only wrappers in libmvec_nonshared.a to work around the 
> GCC limitation (not included in the shared library, so less efficient than 
> direct calls to the vectorized functions, because it ought not be 
> necessary to have multiple symbols for the same function exported from the 
> shared library for this purpose).
> 
> The issue is as I said in 
>  - vector and scalar 
> versions of functions should not need to be in one-to-one correspondence.  
> For example, you could add __attribute__ ((__vector_asm__ ("name"))) to 
> set the version of a function's name to be used as the basis for forming 
> vector function names, overriding the use of a name specified with asm 
> ("name") for that purpose.

I like this idea.  I have prototyped something, I created 'vector_asm'
as an aarch64 attribute because I couldn't find where to put global
attributes like __simd__.  Does anyone know where these are listed?
I left off the leading/trailing underscores because GCC didn't like
them in a target attribute.

I then updated my sysdeps/aarch64/fpu/bits/math-vector.h file in glibc
and things seemed to work fine.  Here are my changes, what do people
think about changing GCC to do this?

The GCC changes I made are:


diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index b38505b..45fde16 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1180,8 +1180,9 @@ static const struct attribute_spec 
aarch64_attribute_table[] =
 {
   /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
affects_type_identity, handler, exclude } */
-  { "aarch64_vector_pcs", 0, 0, false, true,  true,  true,  NULL, NULL },
-  { NULL, 0, 0, false, false, false, false, NULL, NULL }
+  { "aarch64_vector_pcs", 0,  0, false, true,  true,  true,  NULL, NULL },
+  { "vector_asm", 1,  1, true,  false, false, false, NULL, NULL },
+  { NULL, 0,  0, false, false, false, false, NULL, NULL }
 };
 
 #define AARCH64_CPU_DEFAULT_FLAGS ((selected_cpu) ? selected_cpu->flags : 0)
diff --git a/gcc/omp-simd-clone.c b/gcc/omp-simd-clone.c
index 388198b..59183f0 100644
--- a/gcc/omp-simd-clone.c
+++ b/gcc/omp-simd-clone.c
@@ -342,6 +342,8 @@ simd_clone_mangle (struct cgraph_node *node,
   unsigned int simdlen = clone_info->simdlen;
   unsigned int n;
   pretty_printer pp;
+  tree attr;
+  const char *str;
 
   gcc_assert (vecsize_mangle && simdlen);
 
@@ -409,7 +411,12 @@ simd_clone_mangle (struct cgraph_node *node,
 }
 
   pp_underscore (&pp);
-  const char *str = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (node->decl));
+  attr = lookup_attribute ("vector_asm", DECL_ATTRIBUTES (node->decl));
+  if (attr)
+str = TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr)));
+  else
+str = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (node->decl));
+
   if (*str == '*')
 ++str;
   pp_string (&pp, str);



The new sysdeps/aarch64/fpu/bits/math-vector.h was modified to include:

# ifdef __DECL_SIMD_AARCH64
#  undef __DECL_SIMD_exp
#  define __DECL_SIMD_exp __DECL_SIMD_AARCH64 __attribute__ ((vector_asm 
("exp")))
#  undef __DECL_SIMD_expf
#  define __DECL_SIMD_expf __DECL_SIMD_AARCH64 __attribute__ ((vector_asm 
("expf")))

# endif

[PATCH, PR d/88957] Committed fix for ICE in tree_could_trap_p with -fsanitize=undefined

[Iain Buclaw]

Hi,

This patch merges the D front-end implementation with dmd upstream 19b1454b5.

Backports fixes for many ICEs that occurred when using the vector
.array property in both CTFE and code generation passes.

Bootstrapped and regression tested on x86_64-linux-gnu.

Committed to trunk as r269627.

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

2019-03-13  Iain Buclaw  

PR d/88957
* expr.cc (ExprVisitor::visit(VectorArrayExp)): New override.

gcc/testsuite/ChangeLog:

2019-03-13  Iain Buclaw  

PR d/88957
* gdc.dg/pr88957.d: New test.
* gdc.dg/simd.d: Add new vector tests.
---
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index f58b620d844..5e4abe6f33f 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-7423993c996ed9f73d6ba6d58f625ad3c778ca1d
+19b1454b5ca7b1036ea5fde197d91d4a7d05c0a5
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/ctfeexpr.c b/gcc/d/dmd/ctfeexpr.c
index 1050e93699e..1b382232dab 100644
--- a/gcc/d/dmd/ctfeexpr.c
+++ b/gcc/d/dmd/ctfeexpr.c
@@ -517,7 +517,7 @@ Expression *resolveSlice(Expression *e, UnionExp *pue)
 uinteger_t resolveArrayLength(Expression *e)
 {
 if (e->op == TOKvector)
-e = ((VectorExp *)e)->e1;
+return ((VectorExp *)e)->dim;
 
 if (e->op == TOKnull)
 return 0;
diff --git a/gcc/d/dmd/dinterpret.c b/gcc/d/dmd/dinterpret.c
index 140abfdd7e9..777f89cf186 100644
--- a/gcc/d/dmd/dinterpret.c
+++ b/gcc/d/dmd/dinterpret.c
@@ -2920,7 +2920,6 @@ public:
 case TOKneg:*pue = Neg(e->type, e1);  break;
 case TOKtilde:  *pue = Com(e->type, e1);  break;
 case TOKnot:*pue = Not(e->type, e1);  break;
-case TOKvector: result = e; return; // do nothing
 default:assert(0);
 }
 result = (*pue).exp();
@@ -3839,8 +3838,6 @@ public:
 Expression *aggregate;
 dinteger_t firstIndex;
 
-if (e1->op == TOKvector)
-e1 = ((VectorExp *)e1)->e1;
 if (e1->op == TOKslice)
 {
 // --
@@ -4893,6 +4890,87 @@ public:
 result = pue->exp();
 }
 
+/**
+ * Interpret the vector expression as an array literal.
+ * Params:
+ *pue = non-null pointer to temporary storage that can be used to store the return value
+ *e = Expression to interpret
+ * Returns:
+ *resulting array literal or 'e' if unable to interpret
+ */
+static Expression *interpretVectorToArray(UnionExp *pue, VectorExp *e)
+{
+if (e->e1->op == TOKarrayliteral)
+return (ArrayLiteralExp *)e->e1;
+if (e->e1->op == TOKint64 || e->e1->op == TOKfloat64)
+{
+// Convert literal __vector(int) -> __vector([array])
+Expressions *elements = new Expressions();
+elements->setDim(e->dim);
+for (size_t i = 0; i < elements->dim; i++)
+(*elements)[i] = copyLiteral(e->e1).copy();
+TypeSArray *type = NULL;
+if (e->type->ty == Tvector)
+{
+TypeVector *tv = (TypeVector *)e->type;
+if (tv->basetype->ty == Tsarray)
+type = (TypeSArray *)tv->basetype;
+}
+else if (e->type->ty == Tsarray)
+type = (TypeSArray *)e->type;
+assert(type);
+new(pue) ArrayLiteralExp(e->loc, type, elements);
+ArrayLiteralExp *ale = (ArrayLiteralExp *)pue->exp();
+ale->ownedByCtfe = OWNEDctfe;
+return ale;
+}
+return e;
+}
+
+void visit(VectorExp *e)
+{
+if (e->ownedByCtfe >= OWNEDctfe) // We've already interpreted all the elements
+{
+result = e;
+return;
+}
+Expression *e1 = interpret(pue, e->e1, istate);
+assert(e1);
+if (exceptionOrCant(e1))
+return;
+if (e1->op != TOKarrayliteral && e1->op != TOKint64 && e1->op != TOKfloat64)
+{
+e->error("`%s` cannot be evaluated at compile time", e->toChars());
+result = CTFEExp::cantexp;
+return;
+}
+if (e1 == pue->exp())
+e1 = pue->copy();
+new(pue) VectorExp(e->loc, e1, e->to);
+VectorExp *ve = (VectorExp *)pue->exp();
+ve->type = e->type;
+ve->dim = e->dim;
+ve->ownedByCtfe = OWNEDctfe;
+result = ve;
+}
+
+void visit(VectorArrayExp *e)
+{
+Expression *e1 = interpret(pue, e->e1, istate);
+assert(e1);
+if (exceptionOrCant(e1))
+return;
+if (e1->op == TOKvector)
+{
+VectorExp *ve = (VectorExp *)e1;
+result = interpretVectorToArray(pue, ve);
+if (result->op != TOKvector)
+return;
+}
+e->error("`%s` cannot be

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Jonathan Wakely]

On 12/03/19 23:01 +, Joseph Myers wrote:

On Mon, 11 Mar 2019, Jonathan Wakely wrote:


+proc add_options_for_libatomic { flags } {
+if { [istarget hppa*-*-hpux*] } {
+   return "$flags -L../../libatomic/.libs -latomic"
+}


It's generally inappropriate to hardcode such ../../libatomic/.libs paths
without making sure it's for build-tree rather than installed testing (for
installed testing, -latomic can be found without any -L option and it's
the board file's responsibility to set LD_LIBRARY_PATH if necessary).


I was going to say something about that, but then saw we already do it
for libgomp/.libs as well. Two wrongs now though ...

Re: [PATCH] Define midpoint and lerp functions for C++20 (P0811R3)

[Jonathan Wakely]

On 12/03/19 22:49 +, Joseph Myers wrote:

On Tue, 5 Mar 2019, Jonathan Wakely wrote:


The midpoint and lerp functions for floating point types come straight
from the P0811R3 proposal, with no attempt at optimization.


I don't know whether P0811R3 states different requirements from the public
P0811R2, but the implementation of midpoint using isnormal does *not*
satisfy "at most one inexact operation occurs" and is *not* correctly
rounded, contrary to the claims made in P0811R2.


I did wonder how the implementation in the paper was meant to meet the
stated requirements, but I didn't wonder too hard.


Consider e.g. midpoint(DBL_MIN + DBL_TRUE_MIN, DBL_MIN + DBL_TRUE_MIN).
The value DBL_MIN + DBL_TRUE_MIN is normal, but dividing it by 2 is
inexact (and so that midpoint implementation would produce DBL_MIN as
result, so failing to satisfy midpoint(x, x) == x).

Replacing isnormal(x) by something like isgreaterequal(fabs(x), MIN*2)
would avoid those inexact divisions, but there would still be spurious
overflows in non-default rounding modes for e.g. midpoint(DBL_MAX,
DBL_TRUE_MIN) in FE_UPWARD mode, so failing "No overflow occurs" if that's
meant to apply in all rounding modes.


Thanks for this review, and the useful cases to test. Ed is working on
adding some more tests, so maybe he can also look at improving the
code :-)

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Joseph Myers]

On Mon, 11 Mar 2019, Jonathan Wakely wrote:

> +proc add_options_for_libatomic { flags } {
> +if { [istarget hppa*-*-hpux*] } {
> +   return "$flags -L../../libatomic/.libs -latomic"
> +}

It's generally inappropriate to hardcode such ../../libatomic/.libs paths 
without making sure it's for build-tree rather than installed testing (for 
installed testing, -latomic can be found without any -L option and it's 
the board file's responsibility to set LD_LIBRARY_PATH if necessary).

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

Re: [PATCH] Define midpoint and lerp functions for C++20 (P0811R3)

[Joseph Myers]

On Tue, 5 Mar 2019, Jonathan Wakely wrote:

> The midpoint and lerp functions for floating point types come straight
> from the P0811R3 proposal, with no attempt at optimization.

I don't know whether P0811R3 states different requirements from the public 
P0811R2, but the implementation of midpoint using isnormal does *not* 
satisfy "at most one inexact operation occurs" and is *not* correctly 
rounded, contrary to the claims made in P0811R2.

Consider e.g. midpoint(DBL_MIN + DBL_TRUE_MIN, DBL_MIN + DBL_TRUE_MIN).  
The value DBL_MIN + DBL_TRUE_MIN is normal, but dividing it by 2 is 
inexact (and so that midpoint implementation would produce DBL_MIN as 
result, so failing to satisfy midpoint(x, x) == x).

Replacing isnormal(x) by something like isgreaterequal(fabs(x), MIN*2) 
would avoid those inexact divisions, but there would still be spurious 
overflows in non-default rounding modes for e.g. midpoint(DBL_MAX, 
DBL_TRUE_MIN) in FE_UPWARD mode, so failing "No overflow occurs" if that's 
meant to apply in all rounding modes.

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

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

[Thomas Koenig]

Hi Harald,


how about the attached version?  It is quite verbose and produces
messages like

Error: Expected list of 'lower-bound-expr:' or list of
'lower-bound-expr:upper-bound-expr' at (1)


I think this way of specifying error messages

+#define BOUNDS_SPEC_LIST "list of %"

...

+ gfc_error ("Rank remapping requires a "
+BOUNDS_SPEC_LIST " at %L",
 &lvalue->where);

will cause trouble in translation of the error messages.

Could you maybe use something like

+ gfc_error ("Rank remapping requires "
+lower and upper bounds at %L",
 &lvalue->where);

and possibly, instead of

- gfc_error ("Either all or none of the upper bounds"
-" must be specified at %L", &lvalue->where);
+ gfc_error ("Rank remapping requires a "
+BOUNDS_SPEC_LIST " at %L",
+&lvalue->where);
  return false;

use

" Rank remapping requires that all lower and upper bounds be specified"

?

(And I am fairly certain that my versions are not the best possible
ones...)

So, either something like what you propsed (but without the #defines)
or something like what I wrote above would be OK.

Regards

Thomas

[patch, fortran] Fix PR 66695, 77746 and 79485

[Thomas Koenig]

Hello world,

the attached patch fixes three very closely related 7/8/9 regressions.
The common root cause of these PRs was that , if a binding label
existed, gfc_get_extern_function_decl first looked for that name
in the global symbol table for that function and used its backend_decl.
If there was a module procedure with the same name as the BIND(C)
routine (perfectly legal), the wrong procedure would then be called.

The approach is straightforward: In the global symbol table, record
whether we are looking at a "normal" or a BIND(C) name, and if we
come across the wrong kind of entry in gfc_get_extern_function_decl,
just ignore it.

Regressoin-tested. OK for trunk?

Regards

Thomas

2019-03-12  Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
* gfortran.h (gfc_symbol): Add bind_c component.
(gfc_get_gsymbol): Add argument bind_c.
* decl.c (add_global_entry): Add bind_c argument to
gfc_get_symbol.
* parse.c (parse_block_data): Likewise.
(parse_module): Likewise.
(add_global_procedure): Likewise.
(add_global_program): Likewise.
* resolve.c (resolve_common_blocks): Likewise.
(resolve_global_procedure): Likewise.
(gfc_verify_binding_labels): Likewise.
* symbol.c (gfc_get_gsymbol): Add argument bind_c. Set bind_c
in gsym.
* trans-decl.c (gfc_get_module_backend_decl): Add bind_c argument
to gfc_get_symbol.
(gfc_get_extern_function_decl): If the sym has a binding label
and it cannot be found in the global symbol tabel, it is the wrong
one and vice versa.

2019-03-12  Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
* gfortran.dg/binding_label_tests_24.f90: New test.
* gfortran.dg/binding_label_tests_25.f90: New test.
* gfortran.dg/binding_label_tests_26.f90: New test.
* gfortran.dg/binding_label_tests_27.f90: New test.
Index: gfortran.h
===
--- gfortran.h	(Revision 269624)
+++ gfortran.h	(Arbeitskopie)
@@ -1891,6 +1891,7 @@ typedef struct gfc_gsymbol
   enum gfc_symbol_type type;
 
   int defined, used;
+  bool bind_c;
   locus where;
   gfc_namespace *ns;
 }
@@ -3114,7 +3115,7 @@ void gfc_enforce_clean_symbol_state (void);
 void gfc_free_dt_list (void);
 
 
-gfc_gsymbol *gfc_get_gsymbol (const char *);
+gfc_gsymbol *gfc_get_gsymbol (const char *, bool bind_c);
 gfc_gsymbol *gfc_find_gsymbol (gfc_gsymbol *, const char *);
 gfc_gsymbol *gfc_find_case_gsymbol (gfc_gsymbol *, const char *);
 
Index: decl.c
===
--- decl.c	(Revision 269624)
+++ decl.c	(Arbeitskopie)
@@ -7248,7 +7248,7 @@ add_global_entry (const char *name, const char *bi
  name is a global identifier.  */
   if (!binding_label || gfc_notification_std (GFC_STD_F2008))
 {
-  s = gfc_get_gsymbol (name);
+  s = gfc_get_gsymbol (name, false);
 
   if (s->defined || (s->type != GSYM_UNKNOWN && s->type != type))
 	{
@@ -7270,7 +7270,7 @@ add_global_entry (const char *name, const char *bi
   && (!gfc_notification_std (GFC_STD_F2008)
 	  || strcmp (name, binding_label) != 0))
 {
-  s = gfc_get_gsymbol (binding_label);
+  s = gfc_get_gsymbol (binding_label, true);
 
   if (s->defined || (s->type != GSYM_UNKNOWN && s->type != type))
 	{
Index: parse.c
===
--- parse.c	(Revision 269624)
+++ parse.c	(Arbeitskopie)
@@ -5839,7 +5839,7 @@ parse_block_data (void)
 }
   else
 {
-  s = gfc_get_gsymbol (gfc_new_block->name);
+  s = gfc_get_gsymbol (gfc_new_block->name, false);
   if (s->defined
 	  || (s->type != GSYM_UNKNOWN && s->type != GSYM_BLOCK_DATA))
gfc_global_used (s, &gfc_new_block->declared_at);
@@ -5921,7 +5921,7 @@ parse_module (void)
   gfc_gsymbol *s;
   bool error;
 
-  s = gfc_get_gsymbol (gfc_new_block->name);
+  s = gfc_get_gsymbol (gfc_new_block->name, false);
   if (s->defined || (s->type != GSYM_UNKNOWN && s->type != GSYM_MODULE))
 gfc_global_used (s, &gfc_new_block->declared_at);
   else
@@ -5985,7 +5985,7 @@ add_global_procedure (bool sub)
  name is a global identifier.  */
   if (!gfc_new_block->binding_label || gfc_notification_std (GFC_STD_F2008))
 {
-  s = gfc_get_gsymbol (gfc_new_block->name);
+  s = gfc_get_gsymbol (gfc_new_block->name, false);
 
   if (s->defined
 	  || (s->type != GSYM_UNKNOWN
@@ -6010,7 +6010,7 @@ add_global_procedure (bool sub)
   && (!gfc_notification_std (GFC_STD_F2008)
   || strcmp (gfc_new_block->name, gfc_new_block->binding_label) != 0))
 {
-  s = gfc_get_gsymbol (gfc_new_block->binding_label);
+  s = gfc_get_gsymbol (gfc_new_block->binding_label, true);
 
   if (s->defined
 	  || (s->type != GSYM_UNKNOWN
@@ -6042,7 +6042,7 @@ add_global_progr

Re: C++ PATCH for c++/89686 - mixing init-capture and simple-capture in lambda

[Marek Polacek]

On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
> On 3/12/19 3:59 PM, Marek Polacek wrote:
> > As Barry explained in the PR, lambda capture is one of
> > 
> >simple-capture ...[opt]
> >...[opt] init-capture
> > 
> > where init-capture requires an initializer.  Here we have
> > 
> >[...xs...]
> > 
> > which is ill-formed as it's mingling both of these.
> > 
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?  Or should I defer to 
> > GCC
> > 10?
> > 
> > 2019-03-12  Marek Polacek  
> > 
> > PR c++/89686 - mixing init-capture and simple-capture in lambda.
> > * parser.c (cp_parser_lambda_introducer): Give error when combining
> > init-capture and simple-capture.
> > 
> > * g++.dg/cpp2a/lambda-pack-init2.C: New test.
> > 
> > diff --git gcc/cp/parser.c gcc/cp/parser.c
> > index f9569ed..d5d8f364752 100644
> > --- gcc/cp/parser.c
> > +++ gcc/cp/parser.c
> > @@ -10721,6 +10721,15 @@ cp_parser_lambda_introducer (cp_parser* parser, 
> > tree lambda_expr)
> > {
> >   cp_lexer_consume_token (parser->lexer);
> >   capture_init_expr = make_pack_expansion (capture_init_expr);
> > + if (init_pack_expansion)
> > +   {
> > + /* We'd already seen '...' so we were expecting an
> > +init-capture.  But we just saw another '...' which
> > +would imply a simple-capture.  */
> > + error_at (capture_token->location,
> > +   "combining init-capture and simple-capture");
> 
> That diagnostic seems a bit obscure, how about something like "too many
> %<...%> in lambda capture"?

Yup, sounds better.

> Or perhaps check to see if there's an initializer after the ..., and
> complain about the second ... if so, or the first ... if not.

I tried but we already give diagnostic for [...xs=xs...] or [...xs=...xs]
and similar.  But let's at least use a proper location for the '...'.

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

2019-03-12  Marek Polacek  

PR c++/89686 - mixing init-capture and simple-capture in lambda.
* parser.c (cp_parser_lambda_introducer): Give error when combining
init-capture and simple-capture.

* g++.dg/cpp2a/lambda-pack-init2.C: New test.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index f9569ed..69294e20191 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -10719,8 +10719,17 @@ cp_parser_lambda_introducer (cp_parser* parser, tree 
lambda_expr)
 
  if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
{
+ location_t eloc = cp_lexer_peek_token (parser->lexer)->location;
  cp_lexer_consume_token (parser->lexer);
  capture_init_expr = make_pack_expansion (capture_init_expr);
+ if (init_pack_expansion)
+   {
+ /* We'd already seen '...' so we were expecting an
+init-capture.  But we just saw another '...' which
+would imply a simple-capture.  */
+ error_at (eloc, "too many %<...%> in lambda capture");
+ continue;
+   }
}
}
 
diff --git gcc/testsuite/g++.dg/cpp2a/lambda-pack-init2.C 
gcc/testsuite/g++.dg/cpp2a/lambda-pack-init2.C
new file mode 100644
index 000..cd31f3296e1
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/lambda-pack-init2.C
@@ -0,0 +1,19 @@
+// PR c++/89686
+// { dg-do compile { target c++2a } }
+
+template 
+void foo(Ts... xs)
+{
+  int i = 10;
+  [...xs...]{}(); // { dg-error "too many . in lambda capture" }
+  [xs...]{}();
+  [...xs=xs]{}();
+  [i, ...xs...]{}(); // { dg-error "too many . in lambda capture" }
+  [i, xs...]{}();
+  [i, ...xs=xs]{}();
+}
+
+int main()
+{
+ foo(0, 1, 2);
+}

Re: C++ PATCH for c++/89686 - mixing init-capture and simple-capture in lambda

[Jason Merrill]

On 3/12/19 3:59 PM, Marek Polacek wrote:

As Barry explained in the PR, lambda capture is one of

   simple-capture ...[opt]
   ...[opt] init-capture

where init-capture requires an initializer.  Here we have

   [...xs...]

which is ill-formed as it's mingling both of these.

Bootstrapped/regtested on x86_64-linux, ok for trunk?  Or should I defer to GCC
10?

2019-03-12  Marek Polacek  

PR c++/89686 - mixing init-capture and simple-capture in lambda.
* parser.c (cp_parser_lambda_introducer): Give error when combining
init-capture and simple-capture.

* g++.dg/cpp2a/lambda-pack-init2.C: New test.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index f9569ed..d5d8f364752 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -10721,6 +10721,15 @@ cp_parser_lambda_introducer (cp_parser* parser, tree 
lambda_expr)
{
  cp_lexer_consume_token (parser->lexer);
  capture_init_expr = make_pack_expansion (capture_init_expr);
+ if (init_pack_expansion)
+   {
+ /* We'd already seen '...' so we were expecting an
+init-capture.  But we just saw another '...' which
+would imply a simple-capture.  */
+ error_at (capture_token->location,
+   "combining init-capture and simple-capture");


That diagnostic seems a bit obscure, how about something like "too many 
%<...%> in lambda capture"?


Or perhaps check to see if there's an initializer after the ..., and 
complain about the second ... if so, or the first ... if not.


Jason

C++ PATCH for c++/89686 - mixing init-capture and simple-capture in lambda

[Marek Polacek]

As Barry explained in the PR, lambda capture is one of

  simple-capture ...[opt]
  ...[opt] init-capture

where init-capture requires an initializer.  Here we have

  [...xs...]

which is ill-formed as it's mingling both of these.

Bootstrapped/regtested on x86_64-linux, ok for trunk?  Or should I defer to GCC
10?

2019-03-12  Marek Polacek  

PR c++/89686 - mixing init-capture and simple-capture in lambda.
* parser.c (cp_parser_lambda_introducer): Give error when combining
init-capture and simple-capture.

* g++.dg/cpp2a/lambda-pack-init2.C: New test.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index f9569ed..d5d8f364752 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -10721,6 +10721,15 @@ cp_parser_lambda_introducer (cp_parser* parser, tree 
lambda_expr)
{
  cp_lexer_consume_token (parser->lexer);
  capture_init_expr = make_pack_expansion (capture_init_expr);
+ if (init_pack_expansion)
+   {
+ /* We'd already seen '...' so we were expecting an
+init-capture.  But we just saw another '...' which
+would imply a simple-capture.  */
+ error_at (capture_token->location,
+   "combining init-capture and simple-capture");
+ continue;
+   }
}
}
 
diff --git gcc/testsuite/g++.dg/cpp2a/lambda-pack-init2.C 
gcc/testsuite/g++.dg/cpp2a/lambda-pack-init2.C
new file mode 100644
index 000..a6172076400
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/lambda-pack-init2.C
@@ -0,0 +1,19 @@
+// PR c++/89686
+// { dg-do compile { target c++2a } }
+
+template 
+void foo(Ts... xs)
+{
+  int i = 10;
+  [...xs...]{}(); // { dg-error "combining init-capture and simple-capture" }
+  [xs...]{}();
+  [...xs=xs]{}();
+  [i, ...xs...]{}(); // { dg-error "combining init-capture and simple-capture" 
}
+  [i, xs...]{}();
+  [i, ...xs=xs]{}();
+}
+
+int main()
+{
+ foo(0, 1, 2);
+}

[PATCH][RFC] Teach GIMPLE FE to build proper CFG + SSA (+ loops)

[Richard Biener]

This makes an attempt at fixing the most annoying parts of the GIMPLE
FE unit testing - the lack of proper CFG preservation and hoops you
need to jump through to make the CFG and SSA builders happy.

Due to this the __GIMPLE specifiers takes two new flags, "cfg"
for GIMPLE-with-a-CFG and "ssa" for GIMPLE-with-a-CFG-and-SSA.
When there is a CFG you need to start basic-block boundaries with

__BB(index):

where 'index' is the basic-block index.  That implicitely defines
a label __BBindex for use in goto stmts and friends (but doesn't
actually add a GIMPLE_LABEL).

The parsing code isn't defensive right now so you need to watch
out to not use index 0 or 1 (entry and exit block) which are
only implicitely present.

As a proof of concept I added one BB annotation - loop_header(num)
where "num" is the loop number.  This means you can now also
have loop structures preserved (to some extent - the loop tree is
not explicitely represented nor are loop fathers, both are re-built
via fixup).

I've not yet adjusted -gimple dumping.

I've adjusted all testcases I could find.

The CFG build inside the frontend is a bit awkward (spread out...),
likewise some functionality is asking for split-out.

This is mainly a RFC for whether you think this is forward looking
enough.  Future enhancements would include EH and abnormal edges
via stmt annotations:

__BB(2):
  foo () goto __BB3 __EDGE_EH; // EH edge to BB3

__BB(3):
  setjmp () goto __BB4 __EDGE_AB; // abnormal edge to BB4

__BB(4):
  _1 = _5 / 0. __NOTHROW; // gimple_nothrow_p is true
  _3 = _2 / _4 goto __BB5 __EDGE_EH; // EH edge to BB5

etc.  extra edge flags:

  goto __BB5 __EDGE_EXECUTABLE;

I guess now is the time for bike-shedding.

Richard.

2019-03-12  Richard Biener  

c/
* c-tree.h (enum c_declspec_il): New.
(struct c_declspecs): Merge gimple_p and rtl_p into declspec_il
enum bitfield.
* c-parser.c (c_parser_declaration_or_fndef): Adjust accordingly.
Pass start pass and declspec_il to c_parser_parse_gimple_body.
(c_parser_declspecs): Adjust.
* gimple-parser.c: Include cfg.h, cfghooks.h, cfganal.h, tree-cfg.h,
gimple-iterator.h, cfgloop.h, tree-phinodes.h, tree-into-ssa.h
and bitmap.h.
(struct gimple_parser_edge): New.
(edges, current_bb): New globals.
(c_parser_gimple_parse_bb_spec): New helper.
(c_parser_parse_gimple_body): Get start pass and IL specification.
Initialize SSA and CFG.
(c_parser_gimple_compound_statement): Handle CFG build.
(c_parser_gimple_statement): Change intermittend __PHI internal
function arg.
(c_parser_gimple_or_rtl_pass_list): Handle ssa, cfg flags.
(c_parser_gimple_goto_stmt): Record edges to build.
(c_parser_gimple_if_stmt): Likewise.
* gimple-parser.h (c_parser_parse_gimple_body): Adjust.
(c_parser_gimple_or_rtl_pass_list): Likewise.

* gcc.dg/gimplefe-13.c: Adjust.
...

Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c(revision 269604)
+++ gcc/c/c-parser.c(working copy)
@@ -2324,19 +2324,9 @@ c_parser_declaration_or_fndef (c_parser
   DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
= c_parser_peek_token (parser)->location;
 
-  /* If the definition was marked with __GIMPLE then parse the
- function body as GIMPLE.  */
-  if (specs->gimple_p)
-   {
- cfun->pass_startwith = specs->gimple_or_rtl_pass;
- bool saved = in_late_binary_op;
- in_late_binary_op = true;
- c_parser_parse_gimple_body (parser);
- in_late_binary_op = saved;
-   }
-  /* Similarly, if it was marked with __RTL, use the RTL parser now,
+  /* If the definition was marked with __RTL, use the RTL parser now,
 consuming the function body.  */
-  else if (specs->rtl_p)
+  if (specs->declspec_il == cdil_rtl)
{
  c_parser_parse_rtl_body (parser, specs->gimple_or_rtl_pass);
 
@@ -2350,6 +2340,16 @@ c_parser_declaration_or_fndef (c_parser
  finish_function ();
  return;
}
+  /* If the definition was marked with __GIMPLE then parse the
+ function body as GIMPLE.  */
+  else if (specs->declspec_il != cdil_none)
+   {
+ bool saved = in_late_binary_op;
+ in_late_binary_op = true;
+ c_parser_parse_gimple_body (parser, specs->gimple_or_rtl_pass,
+ specs->declspec_il);
+ in_late_binary_op = saved;
+   }
   else
fnbody = c_parser_compound_statement (parser);
   tree fndecl = current_function_decl;
@@ -2372,8 +2372,8 @@ c_parser_declaration_or_fndef (c_parser
add_stmt (fnbody);
  finish_function ();
}
-  /* Get rid of the empty stmt list for GIMPLE.  */
-  if (specs->gimple_p)
+  /* Get rid of the empty stmt list fo

Re: [PATCH, d/87824]: x86_64-linux multilib issues

[Rainer Orth]

Hi Iain,

> On Tue, 12 Mar 2019 at 18:27, Uros Bizjak  wrote:
>>
>> Attached patch fixes libstdc++ includes for multilib d testsuite and
>> fixes runnable/cppa.d testsuite failure with 32bit multilib on
>> x86_64-linux-gnu.
>>
>>
>> 2019-03-12  Uroš Bizjak  
>>
>> PR d/87824
>> * lib/gdc.exp (gdc_include_flags): Find C++ headers by calling
>> libstdc++v3/scripts/testsuite_flags.  Filter out unsupported
>> -nostdinc++ flag.
>>
>> Tested on x86_64-linux-gnu {,-m32}.
>>
>> OK for mainline?
>>
>
> OK, thanks.

I just noticed that the `set target' in gdc_include_flags is now unused
and can be removed.

Rainer

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

Re: [PATCH, d/87824]: x86_64-linux multilib issues

[Iain Buclaw]

On Tue, 12 Mar 2019 at 18:27, Uros Bizjak  wrote:
>
> Attached patch fixes libstdc++ includes for multilib d testsuite and
> fixes runnable/cppa.d testsuite failure with 32bit multilib on
> x86_64-linux-gnu.
>
>
> 2019-03-12  Uroš Bizjak  
>
> PR d/87824
> * lib/gdc.exp (gdc_include_flags): Find C++ headers by calling
> libstdc++v3/scripts/testsuite_flags.  Filter out unsupported
> -nostdinc++ flag.
>
> Tested on x86_64-linux-gnu {,-m32}.
>
> OK for mainline?
>

OK, thanks.

-- 
Iain

[PATCH, d/87824]: x86_64-linux multilib issues

[Uros Bizjak]

Attached patch fixes libstdc++ includes for multilib d testsuite and
fixes runnable/cppa.d testsuite failure with 32bit multilib on
x86_64-linux-gnu.


2019-03-12  Uroš Bizjak  

PR d/87824
* lib/gdc.exp (gdc_include_flags): Find C++ headers by calling
libstdc++v3/scripts/testsuite_flags.  Filter out unsupported
-nostdinc++ flag.

Tested on x86_64-linux-gnu {,-m32}.

OK for mainline?

Uros.
Index: lib/gdc.exp
===
--- lib/gdc.exp (revision 269617)
+++ lib/gdc.exp (working copy)
@@ -88,14 +88,13 @@
 append flags "-I${srcdir}/../../libphobos/libdruntime "
 append flags "-I${srcdir}/../../libphobos/src "
 
-# For the tests that mix C++ and D, we should try and handle this better.
-if { $gccpath != "" } {
-   if [file exists "${gccpath}/libstdc++-v3/include"] {
-   append flags "-I${gccpath}/libstdc++-v3/include "
-   append flags "-I${gccpath}/libstdc++-v3/include/$target "
-   }
+# For the tests that mix C++ and D, need to know where headers are located.
+set odir [lookfor_file ${gccpath} libstdc++-v3]
+if { ${odir} != "" } {
+   set cxxflags [exec sh ${odir}/scripts/testsuite_flags --build-includes]
+   set idx [lsearch $cxxflags "-nostdinc++"]
+   append flags [lreplace $cxxflags $idx $idx]
 }
-append flags "-I${srcdir}/../../libstdc++-v3/libsupc++"
 }
 
 #

Re: [PATCH] avoid assuming every type has a size (PR 89662)

[Martin Sebor]

On 3/12/19 2:20 AM, Richard Biener wrote:

On Mon, Mar 11, 2019 at 9:16 PM Martin Sebor  wrote:


A -Warray-bounds enhancement committed last year into GCC 9
introduced an assumption that the MEM_REF type argument has
a size.  The test case submitted in PR89662 does pointer
addition on void*, in which the MEM_REF type is void*, which
breaks the assumption.

The attached change removes this assumption and considers such
types to have the size of 1.  (The result is used to scale
the offset in diagnostics after it has been determined to be
out of bounds.)


Why's this not catched here:

   if (POINTER_TYPE_P (reftype)
   || !COMPLETE_TYPE_P (reftype)
^^^

   || TREE_CODE (TYPE_SIZE_UNIT (reftype)) != INTEGER_CST
   || RECORD_OR_UNION_TYPE_P (reftype))
 return;


Reftype is the type of the argument referenced by the MEM_REF,
not the type of the MEM_REF itself.  The type examined in
the patch is the latter.  In the test case in PR 89662, reftype
is unsigned char but the MEM_REF type is void*.

  void *f (void *c) { return c; }
  void g () {
// unsigned char D.1930[1];
int n = 1;
char c[n];
h (f(c) - 1);   // h (&MEM[(void *)&D.1930 + -1B]);
  }



and what avoids the bad situation for

   char (*a)[n];
   sink (a - 1);

?  That is, the code assumes TYPE_SIZE_UNIT is an INTEGER_CST
but the above should get you a non-constant type?  It's probably
easier to generate a gimple testcase with this.


I think it will depend on what a points to.  The only kind of VLA
the code works with is one whose size is known (for others, like
in some range, I haven't seen a MEM_REF) .  In the following for
instance we get:

  void f (void)
  {
int n = 4;
char a[n];  // unsigned char D.1935[4];
int (*p)[n] = &a;
sink (p - 1);   // &MEM[(void *)&D.1935 - 16B]
// warning: array subscript -4 is outside array bounds of ‘unsigned 
char[4]’

sink (*p - 1); // &MEM[(void *)&D.1935 - 4B]
// warning: array subscript -1 is outside array bounds of ‘unsigned 
char[4]’

  }

I'm not sure what a GIMPLE test case might look like that would
make the code misbehave.  I tried a few variations but most of
them ICE somewhere else.

Martin

[PATCH, PR d/87866] Committed redefine realpath as lrealpath in dmd front-end

[Iain Buclaw]

Hi,

This patch is a second fix for PR d/87866, as dmd front-end function
FileName::canonicalName could be called during the semantic pass of
import("file") expressions, so still requires that realpath() be
redefined.

Bootstrapped and ran D2 testsuite on x86_64-linux-gnu.

Committed to trunk as r269619.

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

2019-03-12  Iain Buclaw  

PR d/87866
* d-system.h (realpath): Redefine as lrealpath.

---
diff --git a/gcc/d/d-system.h b/gcc/d/d-system.h
index c32825d4ad1..efece15f3bc 100644
--- a/gcc/d/d-system.h
+++ b/gcc/d/d-system.h
@@ -31,6 +31,10 @@
 #undef assert
 #define assert(EXPR) gcc_assert(EXPR)
 
+/* Use libiberty's lrealpath to avoid portability problems.  */
+#undef realpath
+#define realpath(a, b) lrealpath((a))
+
 /* Forward ctype.h macros used by the dmd front-end to safe-ctype.h.  */
 #undef isalpha
 #define isalpha(c) ISALPHA(c)

Re: [PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

[Kewen.Lin]

on 2019/3/12 下午11:22, Bill Schmidt wrote:
> On 3/12/19 9:29 AM, Bill Schmidt wrote:
>> On 3/12/19 7:57 AM, Kewen.Lin wrote:
>>> Hi,
>>>
>>> As the comments from Richard and Segher (Thanks!), I've made some 
>>> changes by adding some checks and extensions. 
>>>   *) Check whether vector type available on target machine,
>>>   *) Check whether vector operation available on target machine, 
>>>   *) Extend the vector operation support to MULT/BIT_AND/BIT_IOR/BIT_XOR.
>>>   *) Add more test cases for coverage.
>>>
>>> Re-bootstrapped/re-regtested successfully on powerpc64le-linux-gnu, 
>>> is it ok for GCC10?
>>>
>>> gcc/ChangeLog
>>>
>>> 2019-03-12  Kewen Lin  
>>>
>>> PR target/88497
>>> * tree-ssa-reassoc.c (reassociate_bb): Swap the positions of 
>>> GIMPLE_BINARY_RHS check and gimple_visited_p check, call new 
>>> function undistribute_bitref_for_vector.
>>> (undistribute_bitref_for_vector): New function.
>>> (cleanup_vinfo_map): Likewise.
>>> (unsigned_cmp): Likewise.
>>>
>>> gcc/testsuite/ChangeLog
>>>
>>> 2019-03-12  Kewen Lin  
>>>
>>> * gcc.dg/tree-ssa/pr88497-1.c: New test.
>>> * gcc.dg/tree-ssa/pr88497-2.c: Likewise.
>>> * gcc.dg/tree-ssa/pr88497-3.c: Likewise.
>>> * gcc.dg/tree-ssa/pr88497-4.c: Likewise.
>>> * gcc.dg/tree-ssa/pr88497-5.c: Likewise.
>>> ---
>>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c |  42 
>>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c |  31 +++
>>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c |  31 +++
>>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c |  31 +++
>>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c |  31 +++
>>>  gcc/tree-ssa-reassoc.c| 309 
>>> +-
>>>  6 files changed, 470 insertions(+), 5 deletions(-)
>>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
>>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
>>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c
>>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c
>>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c
>>>
>>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c 
>>> b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
>>> new file mode 100644
>>> index 000..c87caff
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
>>> @@ -0,0 +1,42 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-require-effective-target vect_double } */
>>> +/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
>>> +
>>> +/* To test reassoc can undistribute vector bit_field_ref summation.
>>> +
>>> +   arg1 and arg2 are two arrays whose elements of type vector double.
>>> +   Assuming:
>>> + A0 = arg1[0], A1 = arg1[1], A2 = arg1[2], A3 = arg1[3],
>>> + B0 = arg2[0], B1 = arg2[1], B2 = arg2[2], B3 = arg2[3],
>>> +
>>> +   Then:
>>> + V0 = A0 * B0, V1 = A1 * B1, V2 = A2 * B2, V3 = A3 * B3,
>>> +
>>> +   reassoc transforms
>>> +
>>> + accumulator += V0[0] + V0[1] + V1[0] + V1[1] + V2[0] + V2[1]
>>> + + V3[0] + V3[1];
>>> +
>>> +   into:
>>> +
>>> + T = V0 + V1 + V2 + V3
>>> + accumulator += T[0] + T[1];
>>> +
>>> +   Fewer bit_field_refs, only two for 128 or more bits vector.  */
>>> +
>>> +typedef double v2df __attribute__ ((vector_size (16)));
>>> +double
>>> +test (double accumulator, v2df arg1[], v2df arg2[])
>>> +{
>>> +  v2df temp;
>>> +  temp = arg1[0] * arg2[0];
>>> +  accumulator += temp[0] + temp[1];
>>> +  temp = arg1[1] * arg2[1];
>>> +  accumulator += temp[0] + temp[1];
>>> +  temp = arg1[2] * arg2[2];
>>> +  accumulator += temp[0] + temp[1];
>>> +  temp = arg1[3] * arg2[3];
>>> +  accumulator += temp[0] + temp[1];
>>> +  return accumulator;
>>> +}
>>> +/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 2 "reassoc1" { target 
>>> { powerpc*-*-* } } } } */
>>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c 
>>> b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
>>> new file mode 100644
>>> index 000..d1851ff
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
>>> @@ -0,0 +1,31 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-require-effective-target vect_float } */
>>> +/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
>>> +
>>> +/* To test reassoc can undistribute vector bit_field_ref on multiplication.
>>> +
>>> +   v1, v2, v3, v4 of type vector float.
>>> +
>>> +   reassoc transforms
>>> +
>>> + accumulator *= v1[0] * v1[1] * v1[2] * v1[3] *
>>> +v2[0] * v2[1] * v2[2] * v2[3] *
>>> +v3[0] * v3[1] * v3[2] * v3[3] *
>>> +v4[0] * v4[1] * v4[2] * v4[3] ;
>>> +
>>> +   into:
>>> +
>>> + T = v1 * v2 * v3 * v4;
>>> + accumulator *= T[0] * T[1] * T[2] * T[3];
>>> +
>>> +   Fewer bit_field_refs, only four for 128 or more bits vector.  */
>>> +
>>> +typedef float v4si __attribute__((vector_size(16)));
>>> +float test(float accumulator, v4si v1, v4si v2, v4si v3, v4si v4) {
>>> +  accumulator *= v1[0] * v1[1] * v1[2] * v1[3]

Re: [PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

[Bill Schmidt]

On 3/12/19 9:29 AM, Bill Schmidt wrote:
> On 3/12/19 7:57 AM, Kewen.Lin wrote:
>> Hi,
>>
>> As the comments from Richard and Segher (Thanks!), I've made some 
>> changes by adding some checks and extensions. 
>>   *) Check whether vector type available on target machine,
>>   *) Check whether vector operation available on target machine, 
>>   *) Extend the vector operation support to MULT/BIT_AND/BIT_IOR/BIT_XOR.
>>   *) Add more test cases for coverage.
>>
>> Re-bootstrapped/re-regtested successfully on powerpc64le-linux-gnu, 
>> is it ok for GCC10?
>>
>> gcc/ChangeLog
>>
>> 2019-03-12  Kewen Lin  
>>
>>  PR target/88497
>>  * tree-ssa-reassoc.c (reassociate_bb): Swap the positions of 
>>  GIMPLE_BINARY_RHS check and gimple_visited_p check, call new 
>>  function undistribute_bitref_for_vector.
>>  (undistribute_bitref_for_vector): New function.
>>  (cleanup_vinfo_map): Likewise.
>>  (unsigned_cmp): Likewise.
>>
>> gcc/testsuite/ChangeLog
>>
>> 2019-03-12  Kewen Lin  
>>
>>  * gcc.dg/tree-ssa/pr88497-1.c: New test.
>>  * gcc.dg/tree-ssa/pr88497-2.c: Likewise.
>>  * gcc.dg/tree-ssa/pr88497-3.c: Likewise.
>>  * gcc.dg/tree-ssa/pr88497-4.c: Likewise.
>>  * gcc.dg/tree-ssa/pr88497-5.c: Likewise.
>> ---
>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c |  42 
>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c |  31 +++
>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c |  31 +++
>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c |  31 +++
>>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c |  31 +++
>>  gcc/tree-ssa-reassoc.c| 309 
>> +-
>>  6 files changed, 470 insertions(+), 5 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c
>>
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c 
>> b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
>> new file mode 100644
>> index 000..c87caff
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
>> @@ -0,0 +1,42 @@
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target vect_double } */
>> +/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
>> +
>> +/* To test reassoc can undistribute vector bit_field_ref summation.
>> +
>> +   arg1 and arg2 are two arrays whose elements of type vector double.
>> +   Assuming:
>> + A0 = arg1[0], A1 = arg1[1], A2 = arg1[2], A3 = arg1[3],
>> + B0 = arg2[0], B1 = arg2[1], B2 = arg2[2], B3 = arg2[3],
>> +
>> +   Then:
>> + V0 = A0 * B0, V1 = A1 * B1, V2 = A2 * B2, V3 = A3 * B3,
>> +
>> +   reassoc transforms
>> +
>> + accumulator += V0[0] + V0[1] + V1[0] + V1[1] + V2[0] + V2[1]
>> +  + V3[0] + V3[1];
>> +
>> +   into:
>> +
>> + T = V0 + V1 + V2 + V3
>> + accumulator += T[0] + T[1];
>> +
>> +   Fewer bit_field_refs, only two for 128 or more bits vector.  */
>> +
>> +typedef double v2df __attribute__ ((vector_size (16)));
>> +double
>> +test (double accumulator, v2df arg1[], v2df arg2[])
>> +{
>> +  v2df temp;
>> +  temp = arg1[0] * arg2[0];
>> +  accumulator += temp[0] + temp[1];
>> +  temp = arg1[1] * arg2[1];
>> +  accumulator += temp[0] + temp[1];
>> +  temp = arg1[2] * arg2[2];
>> +  accumulator += temp[0] + temp[1];
>> +  temp = arg1[3] * arg2[3];
>> +  accumulator += temp[0] + temp[1];
>> +  return accumulator;
>> +}
>> +/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 2 "reassoc1" { target 
>> { powerpc*-*-* } } } } */
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c 
>> b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
>> new file mode 100644
>> index 000..d1851ff
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
>> @@ -0,0 +1,31 @@
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target vect_float } */
>> +/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
>> +
>> +/* To test reassoc can undistribute vector bit_field_ref on multiplication.
>> +
>> +   v1, v2, v3, v4 of type vector float.
>> +
>> +   reassoc transforms
>> +
>> + accumulator *= v1[0] * v1[1] * v1[2] * v1[3] *
>> +v2[0] * v2[1] * v2[2] * v2[3] *
>> +v3[0] * v3[1] * v3[2] * v3[3] *
>> +v4[0] * v4[1] * v4[2] * v4[3] ;
>> +
>> +   into:
>> +
>> + T = v1 * v2 * v3 * v4;
>> + accumulator *= T[0] * T[1] * T[2] * T[3];
>> +
>> +   Fewer bit_field_refs, only four for 128 or more bits vector.  */
>> +
>> +typedef float v4si __attribute__((vector_size(16)));
>> +float test(float accumulator, v4si v1, v4si v2, v4si v3, v4si v4) {
>> +  accumulator *= v1[0] * v1[1] * v1[2] * v1[3];
>> +  accumulator *= v2[0] * v2[1] * v2[2] * v2[3];
>> +  accumulator *= v3[0] * v3[1] * v3[2] * v3[3];
>> +  accumulator *= v4[0] * v4[1] * v4[2] * v4[3];
>> +

Re: How to add %' into gfc_fatal_error

[Martin Liška]

On 3/12/19 3:17 PM, Steve Kargl wrote:
> On Tue, Mar 12, 2019 at 12:15:01PM +0100, Martin Liška wrote:
>> On 3/11/19 6:23 PM, Steve Kargl wrote:
>>> On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
 On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
> Hi.
>
> I would like to add %' into __gcc_gfc__ in order to handle:
>
> ./xgcc -B. /tmp/module.ii -Wformat -c
> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void
> dump_module(const char*, int)’:
> /home/marxin/Programming/gcc/gcc/fortran/module.c:6205:19: warning:
> unknown conversion type character ‘'’ in format [-Wformat=]
>  6205 |  gfc_fatal_error ("Can%'t delete module file %qs: %s",
> filename,
>   |   ^~~
>
> Can you please help me how to do that?
>>>
>>> Are you inserting "%" in front of "'"?  Why?
>>> There are 18 occurences of "Can't" in gfc_error*
>>> messages in the fortran/*.c code.  If you're going
>>> to touch all 18 locations, then change "Can't" to
>>> "Cannot".
>>
>> I'm addressing that with attached patch. The patch also touches Alexander's
>> note in a next email (i386.c change).
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
> 
> The Fortran parts are OK.  The other parts look ok, but

Good.

> I don't know if I can approve those changes.

I'm going to install the patch as it's just a follow up of already
approved patches.

Martin

[GCC-8, Arm, committed] Fix availability of FP16-FP64 conversion instructions

[Andre Vieira (lists)]

Hi,

Thanks Christophe! I have committed a backport of r269499 including the 
testism fix r269596 to gcc-8 branch in r269613.


gcc/ChangeLog:
2019-03-12  Andre Vieira  

Backport from mainline
2019-03-08  Andre Vieira  

* config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add TARGET_VFP_DOUBLE
requirement.

gcc/testsuite/ChangeLog:
2019-03-12  Andre Vieira  

Backport from mainline
2019-03-08  Andre Vieira  

* gcc.target/arm/f16_f64_conv_no_dp.c: New test.

Backport from mainline
2019-03-11  Christophe Lyon  

* gcc.target/arm/f16_f64_conv_no_dp.c: Add arm_fp16_ok effective
target.

On 11/03/2019 20:50, Ramana Radhakrishnan wrote:

Nope, just do it after testing it and adjust with Christophes follow up

R

On Mon, 11 Mar 2019, 10:36 Andre Vieira (lists), 
mailto:andre.simoesdiasvie...@arm.com>> 
wrote:


Hi,

Any objections to me backporting this to GCC 8 and 7?

Cheers,
Andre

On 08/03/2019 17:30, Andre Vieira (lists) wrote:
 > Hi,
 >
 > vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even
for FPUs
 > that do not support double precision.  This patch fixes that.
 >
 > Regression tested for arm-none-eabi.
 >
 > Committed in r269499.
 >
 > Cheers,
 > Andre
 >
 > gcc/ChangeLog:
 > 2019-03-08  Andre Vieira  mailto:andre.simoesdiasvie...@arm.com>>
 >
 >      * config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add
TARGET_VFP_DOUBLE
 >      requirement.
 >
 > gcc/testsuite/ChangeLog:
 >
 > 2019-03-08  Andre Vieira  mailto:andre.simoesdiasvie...@arm.com>>
 >
 >      * gcc.target/arm/f16_f64_conv_no_dp.c: New test.

Re: [PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

[Bill Schmidt]

On 3/12/19 7:57 AM, Kewen.Lin wrote:
> Hi,
>
> As the comments from Richard and Segher (Thanks!), I've made some 
> changes by adding some checks and extensions. 
>   *) Check whether vector type available on target machine,
>   *) Check whether vector operation available on target machine, 
>   *) Extend the vector operation support to MULT/BIT_AND/BIT_IOR/BIT_XOR.
>   *) Add more test cases for coverage.
>
> Re-bootstrapped/re-regtested successfully on powerpc64le-linux-gnu, 
> is it ok for GCC10?
>
> gcc/ChangeLog
>
> 2019-03-12  Kewen Lin  
>
>   PR target/88497
>   * tree-ssa-reassoc.c (reassociate_bb): Swap the positions of 
>   GIMPLE_BINARY_RHS check and gimple_visited_p check, call new 
>   function undistribute_bitref_for_vector.
>   (undistribute_bitref_for_vector): New function.
>   (cleanup_vinfo_map): Likewise.
>   (unsigned_cmp): Likewise.
>
> gcc/testsuite/ChangeLog
>
> 2019-03-12  Kewen Lin  
>
>   * gcc.dg/tree-ssa/pr88497-1.c: New test.
>   * gcc.dg/tree-ssa/pr88497-2.c: Likewise.
>   * gcc.dg/tree-ssa/pr88497-3.c: Likewise.
>   * gcc.dg/tree-ssa/pr88497-4.c: Likewise.
>   * gcc.dg/tree-ssa/pr88497-5.c: Likewise.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c |  42 
>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c |  31 +++
>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c |  31 +++
>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c |  31 +++
>  gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c |  31 +++
>  gcc/tree-ssa-reassoc.c| 309 
> +-
>  6 files changed, 470 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
> new file mode 100644
> index 000..c87caff
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
> @@ -0,0 +1,42 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target vect_double } */
> +/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
> +
> +/* To test reassoc can undistribute vector bit_field_ref summation.
> +
> +   arg1 and arg2 are two arrays whose elements of type vector double.
> +   Assuming:
> + A0 = arg1[0], A1 = arg1[1], A2 = arg1[2], A3 = arg1[3],
> + B0 = arg2[0], B1 = arg2[1], B2 = arg2[2], B3 = arg2[3],
> +
> +   Then:
> + V0 = A0 * B0, V1 = A1 * B1, V2 = A2 * B2, V3 = A3 * B3,
> +
> +   reassoc transforms
> +
> + accumulator += V0[0] + V0[1] + V1[0] + V1[1] + V2[0] + V2[1]
> +   + V3[0] + V3[1];
> +
> +   into:
> +
> + T = V0 + V1 + V2 + V3
> + accumulator += T[0] + T[1];
> +
> +   Fewer bit_field_refs, only two for 128 or more bits vector.  */
> +
> +typedef double v2df __attribute__ ((vector_size (16)));
> +double
> +test (double accumulator, v2df arg1[], v2df arg2[])
> +{
> +  v2df temp;
> +  temp = arg1[0] * arg2[0];
> +  accumulator += temp[0] + temp[1];
> +  temp = arg1[1] * arg2[1];
> +  accumulator += temp[0] + temp[1];
> +  temp = arg1[2] * arg2[2];
> +  accumulator += temp[0] + temp[1];
> +  temp = arg1[3] * arg2[3];
> +  accumulator += temp[0] + temp[1];
> +  return accumulator;
> +}
> +/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 2 "reassoc1" { target { 
> powerpc*-*-* } } } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
> new file mode 100644
> index 000..d1851ff
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
> @@ -0,0 +1,31 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target vect_float } */
> +/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
> +
> +/* To test reassoc can undistribute vector bit_field_ref on multiplication.
> +
> +   v1, v2, v3, v4 of type vector float.
> +
> +   reassoc transforms
> +
> + accumulator *= v1[0] * v1[1] * v1[2] * v1[3] *
> +v2[0] * v2[1] * v2[2] * v2[3] *
> +v3[0] * v3[1] * v3[2] * v3[3] *
> +v4[0] * v4[1] * v4[2] * v4[3] ;
> +
> +   into:
> +
> + T = v1 * v2 * v3 * v4;
> + accumulator *= T[0] * T[1] * T[2] * T[3];
> +
> +   Fewer bit_field_refs, only four for 128 or more bits vector.  */
> +
> +typedef float v4si __attribute__((vector_size(16)));
> +float test(float accumulator, v4si v1, v4si v2, v4si v3, v4si v4) {
> +  accumulator *= v1[0] * v1[1] * v1[2] * v1[3];
> +  accumulator *= v2[0] * v2[1] * v2[2] * v2[3];
> +  accumulator *= v3[0] * v3[1] * v3[2] * v3[3];
> +  accumulator *= v4[0] * v4[1] * v4[2] * v4[3];
> +  return accumulator;
> +}
> +/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 4 "reassoc1" { target { 
> powerpc*-*-* } } } } */
> diff --git a/gcc/testsuite/

Re: How to add %' into gfc_fatal_error

[Steve Kargl]

On Tue, Mar 12, 2019 at 12:15:01PM +0100, Martin Liška wrote:
> On 3/11/19 6:23 PM, Steve Kargl wrote:
> > On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
> >> On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
> >>> Hi.
> >>>
> >>> I would like to add %' into __gcc_gfc__ in order to handle:
> >>>
> >>> ./xgcc -B. /tmp/module.ii -Wformat -c
> >>> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void
> >>> dump_module(const char*, int)’:
> >>> /home/marxin/Programming/gcc/gcc/fortran/module.c:6205:19: warning:
> >>> unknown conversion type character ‘'’ in format [-Wformat=]
> >>>  6205 |  gfc_fatal_error ("Can%'t delete module file %qs: %s",
> >>> filename,
> >>>   |   ^~~
> >>>
> >>> Can you please help me how to do that?
> > 
> > Are you inserting "%" in front of "'"?  Why?
> > There are 18 occurences of "Can't" in gfc_error*
> > messages in the fortran/*.c code.  If you're going
> > to touch all 18 locations, then change "Can't" to
> > "Cannot".
> 
> I'm addressing that with attached patch. The patch also touches Alexander's
> note in a next email (i386.c change).
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

The Fortran parts are OK.  The other parts look ok, but
I don't know if I can approve those changes.

-- 
steve

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

[Joseph Myers]

On Tue, 12 Mar 2019, Richard Biener wrote:

> It shouldn't be difficult to provide an alias from the glibc side, no?  
> How does x86 avoid this issue?

There are static-only wrappers in libmvec_nonshared.a to work around the 
GCC limitation (not included in the shared library, so less efficient than 
direct calls to the vectorized functions, because it ought not be 
necessary to have multiple symbols for the same function exported from the 
shared library for this purpose).

The issue is as I said in 
 - vector and scalar 
versions of functions should not need to be in one-to-one correspondence.  
For example, you could add __attribute__ ((__vector_asm__ ("name"))) to 
set the version of a function's name to be used as the basis for forming 
vector function names, overriding the use of a name specified with asm 
("name") for that purpose.

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

[PATCH, d] Committed merge with upstream dmd

[Iain Buclaw]

Hi,

This patch merges the D front-end implementation with dmd upstream 7423993c9.

Backports a fix for extern(C++) mangling for substituted basic types
that are target-specific.  Introduces a new method that currently does
nothing, but could in future make use of flag_abi_version as
extern(C++) integration improves in latter versions of the D
front-end.

Bootstrapped and regression tested on x86_64-linux-gnu.

Committed to trunk as r269611.

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

2019-03-12  Iain Buclaw  

* d-lang.cc (d_init_options): Set global.params.cplusplus to C++14.
* d-target.cc (Target::cppFundamentalType): New method.
---
diff --git a/gcc/d/d-lang.cc b/gcc/d/d-lang.cc
index b53e56e65a2..d97525a590e 100644
--- a/gcc/d/d-lang.cc
+++ b/gcc/d/d-lang.cc
@@ -282,6 +282,9 @@ d_init_options (unsigned int, cl_decoded_option *decoded_options)
   global.params.betterC = false;
   global.params.allInst = false;
 
+  /* Default extern(C++) mangling to C++14.  */
+  global.params.cplusplus = CppStdRevisionCpp14;
+
   global.params.linkswitches = new Strings ();
   global.params.libfiles = new Strings ();
   global.params.objfiles = new Strings ();
diff --git a/gcc/d/d-target.cc b/gcc/d/d-target.cc
index de57d9256db..e0cfbafe0b9 100644
--- a/gcc/d/d-target.cc
+++ b/gcc/d/d-target.cc
@@ -385,6 +385,15 @@ Target::cppParameterType (Parameter *arg)
   return t;
 }
 
+/* Checks whether TYPE is a vendor-specific fundamental type.  Stores the result
+   in IS_FUNDAMENTAL and returns true if the parameter was set.  */
+
+bool
+Target::cppFundamentalType (const Type *, bool &)
+{
+  return false;
+}
+
 /* Return the default system linkage for the target.  */
 
 LINK
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index cf5a22f070f..f58b620d844 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-fcc235e8e25f7758266f7874edd5abefb9943e0b
+7423993c996ed9f73d6ba6d58f625ad3c778ca1d
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/cppmangle.c b/gcc/d/dmd/cppmangle.c
index b991417c35e..9b24fd2c2e4 100644
--- a/gcc/d/dmd/cppmangle.c
+++ b/gcc/d/dmd/cppmangle.c
@@ -120,6 +120,40 @@ class CppMangleVisitor : public Visitor
 !getQualifier(s));  // at global level
 }
 
+/
+ * Determine if type is a C++ fundamental type.
+ * Params:
+ *  t = type to check
+ * Returns:
+ *  true if it is a fundamental type
+ */
+static bool isFundamentalType(Type *t)
+{
+// First check the target whether some specific ABI is being followed.
+bool isFundamental;
+if (Target::cppFundamentalType(t, isFundamental))
+return isFundamental;
+if (t->ty == Tenum)
+{
+// Peel off enum type from special types.
+TypeEnum *te = (TypeEnum *)t;
+if (te->sym->isSpecial())
+t = te->sym->getMemtype(Loc());
+}
+
+// Fundamental arithmetic types:
+// 1. integral types: bool, char, int, ...
+// 2. floating point types: float, double, real
+// 3. void
+// 4. null pointer: std::nullptr_t (since C++11)
+if (t->ty == Tvoid || t->ty == Tbool)
+return true;
+else if (t->ty == Tnull && global.params.cplusplus >= CppStdRevisionCpp11)
+return true;
+else
+return t->isTypeBasic() && (t->isintegral() || t->isreal());
+}
+
 /**
  * Write the mangled representation of the template arguments.
  * Params:
@@ -741,7 +775,8 @@ public:
  */
 void writeBasicType(Type *t, char p, char c)
 {
-if (p || t->isConst())
+// Only do substitutions for non-fundamental types.
+if (!isFundamentalType(t) || t->isConst())
 {
 if (substitute(t))
 return;
@@ -767,6 +802,22 @@ public:
 if (t->isImmutable() || t->isShared())
 return error(t);
 
+// Handle any target-specific basic types.
+if (const char *tm = Target::cppTypeMangle(t))
+{
+// Only do substitutions for non-fundamental types.
+if (!isFundamentalType(t) || t->isConst())
+{
+if (substitute(t))
+return;
+else
+append(t);
+}
+CV_qualifiers(t);
+buf->writestring(tm);
+return;
+}
+
 /* :
  * vvoid
  * wwchar_t
@@ -832,17 +883,6 @@ public:
 case Tcomplex80:p = 'C'; c = 'e';   break;
 
 default:
-// Handle any target-specific basic types.
-if (const char *tm = Target::cppTypeMangle(t))
-{
-if (substitute(t))
-return;
-else
-appen

[PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

[Kewen.Lin]

Hi,

As the comments from Richard and Segher (Thanks!), I've made some 
changes by adding some checks and extensions. 
  *) Check whether vector type available on target machine,
  *) Check whether vector operation available on target machine, 
  *) Extend the vector operation support to MULT/BIT_AND/BIT_IOR/BIT_XOR.
  *) Add more test cases for coverage.

Re-bootstrapped/re-regtested successfully on powerpc64le-linux-gnu, 
is it ok for GCC10?

gcc/ChangeLog

2019-03-12  Kewen Lin  

PR target/88497
* tree-ssa-reassoc.c (reassociate_bb): Swap the positions of 
GIMPLE_BINARY_RHS check and gimple_visited_p check, call new 
function undistribute_bitref_for_vector.
(undistribute_bitref_for_vector): New function.
(cleanup_vinfo_map): Likewise.
(unsigned_cmp): Likewise.

gcc/testsuite/ChangeLog

2019-03-12  Kewen Lin  

* gcc.dg/tree-ssa/pr88497-1.c: New test.
* gcc.dg/tree-ssa/pr88497-2.c: Likewise.
* gcc.dg/tree-ssa/pr88497-3.c: Likewise.
* gcc.dg/tree-ssa/pr88497-4.c: Likewise.
* gcc.dg/tree-ssa/pr88497-5.c: Likewise.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c |  42 
 gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c |  31 +++
 gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c |  31 +++
 gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c |  31 +++
 gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c |  31 +++
 gcc/tree-ssa-reassoc.c| 309 +-
 6 files changed, 470 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
new file mode 100644
index 000..c87caff
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c
@@ -0,0 +1,42 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_double } */
+/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
+
+/* To test reassoc can undistribute vector bit_field_ref summation.
+
+   arg1 and arg2 are two arrays whose elements of type vector double.
+   Assuming:
+ A0 = arg1[0], A1 = arg1[1], A2 = arg1[2], A3 = arg1[3],
+ B0 = arg2[0], B1 = arg2[1], B2 = arg2[2], B3 = arg2[3],
+
+   Then:
+ V0 = A0 * B0, V1 = A1 * B1, V2 = A2 * B2, V3 = A3 * B3,
+
+   reassoc transforms
+
+ accumulator += V0[0] + V0[1] + V1[0] + V1[1] + V2[0] + V2[1]
+ + V3[0] + V3[1];
+
+   into:
+
+ T = V0 + V1 + V2 + V3
+ accumulator += T[0] + T[1];
+
+   Fewer bit_field_refs, only two for 128 or more bits vector.  */
+
+typedef double v2df __attribute__ ((vector_size (16)));
+double
+test (double accumulator, v2df arg1[], v2df arg2[])
+{
+  v2df temp;
+  temp = arg1[0] * arg2[0];
+  accumulator += temp[0] + temp[1];
+  temp = arg1[1] * arg2[1];
+  accumulator += temp[0] + temp[1];
+  temp = arg1[2] * arg2[2];
+  accumulator += temp[0] + temp[1];
+  temp = arg1[3] * arg2[3];
+  accumulator += temp[0] + temp[1];
+  return accumulator;
+}
+/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 2 "reassoc1" { target { 
powerpc*-*-* } } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
new file mode 100644
index 000..d1851ff
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_float } */
+/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
+
+/* To test reassoc can undistribute vector bit_field_ref on multiplication.
+
+   v1, v2, v3, v4 of type vector float.
+
+   reassoc transforms
+
+ accumulator *= v1[0] * v1[1] * v1[2] * v1[3] *
+v2[0] * v2[1] * v2[2] * v2[3] *
+v3[0] * v3[1] * v3[2] * v3[3] *
+v4[0] * v4[1] * v4[2] * v4[3] ;
+
+   into:
+
+ T = v1 * v2 * v3 * v4;
+ accumulator *= T[0] * T[1] * T[2] * T[3];
+
+   Fewer bit_field_refs, only four for 128 or more bits vector.  */
+
+typedef float v4si __attribute__((vector_size(16)));
+float test(float accumulator, v4si v1, v4si v2, v4si v3, v4si v4) {
+  accumulator *= v1[0] * v1[1] * v1[2] * v1[3];
+  accumulator *= v2[0] * v2[1] * v2[2] * v2[3];
+  accumulator *= v3[0] * v3[1] * v3[2] * v3[3];
+  accumulator *= v4[0] * v4[1] * v4[2] * v4[3];
+  return accumulator;
+}
+/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 4 "reassoc1" { target { 
powerpc*-*-* } } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c
new file mode 100644
index 000..e774d25
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
+/* { dg

[PATCH] Fix dumping of "former thunk" info in cgraph dump

[Martin Jambor]

Hi,

I have forgot to add a newline in cgraph_node dumping that I added last
week (the patch to partially address PR 88235).  When discussing this,
we agreed with Honza that if we dump that a node is a former thunk, we
should also dump the various info in the thunk sub-structure that
fomrer_thunk_p() looks at.  Therefore I consider the following patch
pre-approved and will commit it in a few moments (it has passed
bootstrap and testing on an x86_64-linux machine).

Thanks,

Martin



2019-03-11  Martin Jambor  

* cgraph.c (cgraph_node::dump): Dump more info for former thunks,
terminate with newline.
---
 gcc/cgraph.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 9f0d603a1cf..49d80ad1e28 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2110,7 +2110,12 @@ cgraph_node::dump (FILE *f)
   (int)thunk.virtual_offset_p);
 }
   else if (former_thunk_p ())
-fprintf (f, "  Former thunk");
+fprintf (f, "  Former thunk fixed offset %i virtual value %i "
+"indirect_offset %i has virtual offset %i\n",
+(int)thunk.fixed_offset,
+(int)thunk.virtual_value,
+(int)thunk.indirect_offset,
+(int)thunk.virtual_offset_p);
   if (alias && thunk.alias
   && DECL_P (thunk.alias))
 {
-- 
2.21.0

Re: [PATCH 8/8] S/390: Change test case to reflect scheduling changes.

[Andreas Krebbel]

On 12.03.19 11:02, Robin Dapp wrote:
> This fixes a newly introduced test failure.
> 
> 
> ---
> 
> 2019-03-12  Robin Dapp  
> 
> * gcc.target/s390/memset-1.c: Do not require stcy.
> 

Ok. Thanks!

Andreas

Re: [PATCH 0/7] S/390: Rework instruction scheduling.

[Andreas Krebbel]

On 12.03.19 11:00, Robin Dapp wrote:
>> Please adjust the year and the author in gcc/config/s390/3906.md. Ok with 
>> that change.
> 
> Changed that and also simplified the longrunning checks.
> 
> gcc/ChangeLog:
> 
> 2019-03-12  Robin Dapp  
> 
> * config/s390/s390.c (LONGRUNNING_THRESHOLD): Remove.
> (s390_is_fpd): Add.
> (s390_is_fxd): Add.
> (s390_is_longrunning): Add.
> (s390_sched_score): Use new functions.
> (s390_sched_variable_issue): Use new functions.
> 

Ok. Thanks!

Andreas

Re: [PATCH] S/390: Perform more aggressive inlining

[Andreas Krebbel]

On 12.03.19 11:22, Robin Dapp wrote:
> Hi,
> 
> this patch sets the inlining parameters for z13 and later to rather
> aggressive values in response to PR85103 that caused performance
> regressions in SPEC2006's sjeng and gobmk benchmarks.
> 
> Regards
>  Robin
> 
> --
> 
> gcc/ChangeLog:
> 
> 2019-03-12  Robin Dapp  
> 
> * config/s390/s390.c (s390_option_override_internal): Use more
> aggressive inlining parameters.
> 

Ok. Thanks!

Andreas

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

[Kyrill Tkachov]

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

+
+  
 
 
 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
+ 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

Re: [Patch, Fortran] PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

[Janus Weil]

Hi Steve,

> > Technically the ICE is a regression, but since it happens on invalid
> > code only, backporting is not essential IMHO (but might still be
> > useful). Ok for trunk? And 8-branch?
>
> Looks good to me with a minor suggestion.  See below.

thanks for the comments. Updated patch attached.


> You may want to wait a bit or ping Paul to give him
> a chance to peek at the patch.

I'm putting Paul in CC and will wait until tomorrow night before committing.


> >if (gfc_match_char (')') == MATCH_YES)
> > -goto ok;
> > +  {
> > +if (typeparam)
> > +  {
> > + gfc_error_now ("A parameter name is required at %C");
>
> Can you insert "type" so the error reads "A type parameter name"?
> Unfortunately, the words parameter has a few too many meanings.

True. I'm using 'type parameter list' now.

Cheers,
Janus
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index a3b47ac4980..834c73fc27e 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,10 @@
+2019-03-12  Janus Weil  
+
+	PR fortran/89601
+	* decl.c (gfc_match_formal_arglist): Reject empty type parameter lists.
+	(gfc_match_derived_decl): Mark as PDT only if type parameter list was
+	matched successfully.
+
 2019-03-11  Jakub Jelinek  
 
 	PR fortran/89651
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index a29e2db0bd6..3ebce880b39 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6275,7 +6275,16 @@ gfc_match_formal_arglist (gfc_symbol *progname, int st_flag,
 }
 
   if (gfc_match_char (')') == MATCH_YES)
-goto ok;
+  {
+if (typeparam)
+  {
+	gfc_error_now ("A type parameter list is required at %C");
+	m = MATCH_ERROR;
+	goto cleanup;
+  }
+else
+  goto ok;
+  }
 
   for (;;)
 {
@@ -10217,13 +10226,14 @@ gfc_match_derived_decl (void)
   m = gfc_match_formal_arglist (sym, 0, 0, true);
   if (m != MATCH_YES)
 	gfc_error_recovery ();
+  else
+	sym->attr.pdt_template = 1;
   m = gfc_match_eos ();
   if (m != MATCH_YES)
 	{
 	  gfc_error_recovery ();
 	  gfc_error_now ("Garbage after PARAMETERIZED TYPE declaration at %C");
 	}
-  sym->attr.pdt_template = 1;
 }
 
   if (extended && !sym->components)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 9b20bdfe787..8c8d282491b 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2019-03-12  Janus Weil  
+
+	PR fortran/89601
+	* gfortran.dg/pdt_16.f03: Modified to avoid follow-up errors.
+	* gfortran.dg/pdt_30.f90: New test case.
+
 2019-03-12  Jakub Jelinek  
 
 	PR middle-end/89663
diff --git a/gcc/testsuite/gfortran.dg/pdt_16.f03 b/gcc/testsuite/gfortran.dg/pdt_16.f03
index 067d87d660d..22c6b83a084 100644
--- a/gcc/testsuite/gfortran.dg/pdt_16.f03
+++ b/gcc/testsuite/gfortran.dg/pdt_16.f03
@@ -12,7 +12,6 @@ end
 program p
type t(a  ! { dg-error "Expected parameter list" }
   integer, kind :: a
-  real(a) :: x
end type
type u(a, a)  ! { dg-error "Duplicate name" }
   integer, kind :: a ! { dg-error "already declared" }
diff --git a/gcc/testsuite/gfortran.dg/pdt_30.f90 b/gcc/testsuite/gfortran.dg/pdt_30.f90
new file mode 100644
index 000..47f7c775465
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pdt_30.f90
@@ -0,0 +1,17 @@
+! { dg-do compile }
+!
+! PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)
+!
+! Contributed by Arseny Solokha 
+
+program vw
+  interface
+ real function ul (ki)
+   real :: ki
+ end function ul
+  end interface
+  type :: q8 ()  ! { dg-error "A type parameter list is required" }
+ procedure (ul), pointer, nopass :: pj
+  end type q8
+  type (q8) :: ki
+end program vw

Patch ping (Re: [PATCH] Fix -gdwarf-5 -gsplit-dwarf ICEs (PR debug/89498))

[Jakub Jelinek]

On Mon, Mar 04, 2019 at 11:35:50PM +0100, Jakub Jelinek wrote:
> 2019-03-04  Jakub Jelinek  
> 
>   PR debug/89498
>   * dwarf2out.c (size_of_die): For dw_val_class_view_list always use
>   DWARF_OFFSET_SIZE.
>   (value_format): For dw_val_class_view_list never use DW_FORM_loclistx.

Given the clarifications Alex has just posted, I believe this patch does
what is documented in there.  Ok for trunk?

Jakub

Re: [PATCH] Fix -gdwarf-5 -gsplit-dwarf ICEs (PR debug/89498)

[Jakub Jelinek]

On Tue, Mar 12, 2019 at 04:32:35AM -0300, Alexandre Oliva wrote:
> When location lists are referenced in DW_AT_location attributes by an
> absolute address in DW_FORM_sec_offset, the corresponding
> DW_AT_GNU_locviews attribute can be a DW_FORM_sec_offset with an
> absolute address as well.

Note, for DWARF before v4, there is no DW_FORM_sec_offset and
DW_FORM_data4 or DW_FORM_data8 depending on whether it is 32-bit or 64-bit
DWARF is used instead.
> 
> When generating split (extension to) DWARF up to v4, DW_AT_location is
> represented with an offset from the base address in the beginning of
> the .debug_loc.dwo section, in DW_FORM_sec_offset.  DW_AT_GNU_locviews
> should then be an offset from the same base address, also in
> DW_FORM_sec_offset.

Likewise here.

Otherwise LGTM.

Jakub

Patch ping (Re: [PATCH] ARM cmpsi2_addneg fix follow-up (PR target/89506))

[Jakub Jelinek]

On Mon, Mar 04, 2019 at 10:04:01AM +0100, Jakub Jelinek wrote:
> The first one uses constraints and no C code in the output, I believe it is
> actually more expensive for compile time, because if one just reads what
> constrain_operands needs to do for another constraint, it is quite a lot.
> I've tried to at least not introduce new constraints for this, there is no
> constraint for number 1 (or for number -1).
> The Pu constraint is thumb2 only for numbers 1..8, and the alternative uses
> I constraint for the negation of it, i.e. -8..-1, only -1 from this is
> valid for I.  If that matches, we emit adds with #1, otherwise just prefer
> subs over adds.
> 
> The other swaps the alternatives similarly to the above, but for the special
> case of desirable adds with #1 uses C code instead of another alternative.
> 
> Ok for trunk (which one)?

I'd like to ping these patches:

> 2019-03-04  Jakub Jelinek  
> 
>   PR target/89506
>   * config/arm/arm.md (cmpsi2_addneg): Swap the alternatives, add
>   another alternative with I constraint for operands[2] and Pu
>   for operands[3] and emit adds in that case, don't use C code to
>   emit the instruction.

or:

> 2019-03-04  Jakub Jelinek  
> 
>   PR target/89506
>   * config/arm/arm.md (cmpsi2_addneg): Swap the alternatives and use
>   subs for the first alternative except when operands[3] is 1.

Jakub

[C++ Patch] PR 89571 ("[9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238")

[Paolo Carlini]

Hi,

this is just an error recovery ICE but maybe we can fix it in time for 
9.1.0, like c++/89488, which is somehow related. Indeed, the problem is 
again a !DEFERRED_NOEXCEPT_SPEC_P gcc_assert triggering where, earlier, 
process_subob_fn had maybe_instantiate_noexcept returning false (in 
c++/89448 the assertion triggered almost immediately, when 
merge_exception_specifiers was called).


Anyway, what we committed for c++/89488 doesn't help here because the 
error_mark_node assigned to *spec_p is propagated back only up to 
build_over_call, where mark_used returns false but isn't acted upon 
because of the additional && !(complain & tf_error). Thus I had the idea 
of simply removing the latter (by itself a bit invasive at this stage) 
but that leads to duplicated diagnostics because then, in 
cp_parser_decltype_expr, when cp_parser_postfix_expression returns 
error_mark_node we go on and try a full expression too, and emit the 
same diagnostics again.


Given the above we can imagine reworking the parser, which seems to me a 
bit tricky at this time, or we can go back to my initial proposal for 
c++/89488, attached below, which doesn't set *spec_p to error_mark_node 
when maybe_instantiate_noexcept returns false. My rationale being that, 
elsewhere, we very often discard completely the return value of 
maybe_instantiate_noexcept, thus it doesn't seem a big deal only using 
it to avoid immediately calling marge_exception_specifiers and ICE. If 
we do this, for c++/89448 we emit the additional "cannot convert" error, 
which may not be a bad thing, given that we used to emit it forever, and 
the same do both clang and edg, thus it looks like considering that 'zl 
()' not completely broken may make sense for error-recovery purposes...


Tested x86_64-linux.

Thanks, Paolo.

///

/cp
2019-03-12  Paolo Carlini  

PR c++/89571
* method.c (process_subob_fn): Do not set *spec_p to error_mark_node
when maybe_instantiate_noexcept returns false.

/testsuite
2019-03-12  Paolo Carlini  

PR c++/89571
* g++.dg/cpp0x/noexcept36.C: New.
* g++.dg/cpp0x/nsdmi15.C: Adjust.
Index: cp/method.c
===
--- cp/method.c (revision 269606)
+++ cp/method.c (working copy)
@@ -1254,15 +1254,10 @@ process_subob_fn (tree fn, tree *spec_p, bool *tri
   return;
 }
 
-  if (spec_p)
+  if (spec_p && maybe_instantiate_noexcept (fn))
 {
-  if (!maybe_instantiate_noexcept (fn))
-   *spec_p = error_mark_node;
-  else
-   {
- tree raises = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn));
- *spec_p = merge_exception_specifiers (*spec_p, raises);
-   }
+  tree raises = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn));
+  *spec_p = merge_exception_specifiers (*spec_p, raises);
 }
 
   if (!trivial_fn_p (fn) && !dtor_from_ctor)
Index: testsuite/g++.dg/cpp0x/noexcept36.C
===
--- testsuite/g++.dg/cpp0x/noexcept36.C (nonexistent)
+++ testsuite/g++.dg/cpp0x/noexcept36.C (working copy)
@@ -0,0 +1,22 @@
+// PR c++/89571
+// { dg-do compile { target c++11 } }
+
+struct z8 {
+  constexpr static int qq /* = 0 */;  // { dg-error "initializer" }
+};
+
+template
+struct kf {
+  kf (const kf &) noexcept (T::qq);  // { dg-error "constant" }
+};
+
+struct lk {
+  kf e1;
+};
+
+template
+T &sc ();
+
+struct b6 {
+  decltype (lk (sc ())) zz;
+};
Index: testsuite/g++.dg/cpp0x/nsdmi15.C
===
--- testsuite/g++.dg/cpp0x/nsdmi15.C(revision 269606)
+++ testsuite/g++.dg/cpp0x/nsdmi15.C(working copy)
@@ -3,6 +3,6 @@
 
 struct zl {
   struct {
-int x2 = zl ();  // { dg-error "default member" }
+int x2 = zl ();  // { dg-error "default member|cannot convert" }
   } fx;
 };

Re: How to add %' into gfc_fatal_error

[Martin Liška]

On 3/11/19 6:23 PM, Steve Kargl wrote:
> On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
>> On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
>>> Hi.
>>>
>>> I would like to add %' into __gcc_gfc__ in order to handle:
>>>
>>> ./xgcc -B. /tmp/module.ii -Wformat -c
>>> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void
>>> dump_module(const char*, int)’:
>>> /home/marxin/Programming/gcc/gcc/fortran/module.c:6205:19: warning:
>>> unknown conversion type character ‘'’ in format [-Wformat=]
>>>  6205 |  gfc_fatal_error ("Can%'t delete module file %qs: %s",
>>> filename,
>>>   |   ^~~
>>>
>>> Can you please help me how to do that?
> 
> Are you inserting "%" in front of "'"?  Why?
> There are 18 occurences of "Can't" in gfc_error*
> messages in the fortran/*.c code.  If you're going
> to touch all 18 locations, then change "Can't" to
> "Cannot".
> 

Hi.

I'm addressing that with attached patch. The patch also touches Alexander's
note in a next email (i386.c change).

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

Ready to be installed?
Thanks,
Martin
From 5903e4750fd5fd8e972cc5c69513ad724e8eb949 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 12 Mar 2019 09:39:07 +0100
Subject: [PATCH] Replace can't in error messages for Fortran.

gcc/c-family/ChangeLog:

2019-03-12  Martin Liska  

	* c-opts.c (c_common_handle_option): Wrap option with %< and %>.

gcc/fortran/ChangeLog:

2019-03-12  Martin Liska  

	* decl.c (add_init_expr_to_sym): Replace usage of 'can't'
	with 'cannot'.
	(variable_decl): Likewise.
	(cray_pointer_decl): Likewise.
	(match_binding_attributes): Likewise.
	* f95-lang.c (gfc_init): Likewise.
	* interface.c (gfc_check_typebound_override): Likewise.
	* intrinsic.c (make_generic): Likewise.
	* module.c (dump_module): Likewise.
	(gfc_use_module): Likewise.
	* primary.c (gfc_convert_to_structure_constructor): Likewise.
	* resolve.c (resolve_entries): Likewise.
	(check_generic_tbp_ambiguity): Likewise.
	(get_checked_tb_operator_target): Likewise.
	* scanner.c (load_file): Likewise.
	* trans-expr.c (gfc_conv_intrinsic_to_class): Likewise.

gcc/ChangeLog:

2019-03-12  Martin Liska  

	* config/i386/i386.c: Reword an error message.

gcc/testsuite/ChangeLog:

2019-03-12  Martin Liska  

	* gfortran.dg/abstract_type_3.f03: Amend test-case scan
	patterns.
	* gfortran.dg/binding_label_tests_4.f03: Likewise.
	* gfortran.dg/c_f_pointer_tests_6.f90: Likewise.
	* gfortran.dg/c_funloc_tests_6.f90: Likewise.
	* gfortran.dg/c_loc_tests_17.f90: Likewise.
	* gfortran.dg/constructor_9.f90: Likewise.
	* gfortran.dg/dec_structure_8.f90: Likewise.
	* gfortran.dg/entry_4.f90: Likewise.
	* gfortran.dg/init_char_with_nonchar_ctr.f90: Likewise.
	* gfortran.dg/initialization_23.f90: Likewise.
	* gfortran.dg/logical_assignment_1.f90: Likewise.
	* gfortran.dg/pr80752.f90: Likewise.
	* gfortran.dg/pr88116_1.f90: Likewise.
	* gfortran.dg/pr88467.f90: Likewise.
	* gfortran.dg/typebound_call_7.f03: Likewise.
	* gfortran.dg/typebound_generic_1.f03: Likewise.
	* gfortran.dg/typebound_operator_2.f03: Likewise.
	* gfortran.dg/typebound_operator_4.f03: Likewise.
	* gfortran.dg/typebound_proc_9.f03: Likewise.
	* gfortran.dg/unlimited_polymorphic_2.f03: Likewise.
---
 gcc/c-family/c-opts.c  |  2 +-
 gcc/config/i386/i386.c |  3 ++-
 gcc/fortran/decl.c | 10 +-
 gcc/fortran/f95-lang.c |  2 +-
 gcc/fortran/interface.c|  2 +-
 gcc/fortran/intrinsic.c|  8 
 gcc/fortran/module.c   | 14 +++---
 gcc/fortran/primary.c  |  2 +-
 gcc/fortran/resolve.c  | 18 +-
 gcc/fortran/scanner.c  |  2 +-
 gcc/fortran/trans-expr.c   |  4 ++--
 gcc/testsuite/gfortran.dg/abstract_type_3.f03  |  2 +-
 .../gfortran.dg/binding_label_tests_4.f03  |  2 +-
 .../gfortran.dg/c_f_pointer_tests_6.f90|  2 +-
 gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90 |  4 ++--
 gcc/testsuite/gfortran.dg/c_loc_tests_17.f90   |  2 +-
 gcc/testsuite/gfortran.dg/constructor_9.f90|  2 +-
 gcc/testsuite/gfortran.dg/dec_structure_8.f90  |  2 +-
 gcc/testsuite/gfortran.dg/entry_4.f90  |  8 
 .../gfortran.dg/init_char_with_nonchar_ctr.f90 |  8 
 .../gfortran.dg/initialization_23.f90  |  2 +-
 .../gfortran.dg/logical_assignment_1.f90   |  2 +-
 gcc/testsuite/gfortran.dg/pr80752.f90  |  2 +-
 gcc/testsuite/gfortran.dg/pr88116_1.f90|  2 +-
 gcc/testsuite/gfortran.dg/pr88467.f90  |  2 +-
 gcc/testsuite/gfortran.dg/typebound_call_7.f03 |  2 +-
 .../gfortran.dg/typebound_generic_1.f03|  4 ++--
 .../gfortran.dg/typebound_operator_2.f03   |  4 ++--
 .../gfortran.dg/typebound_operator_4.f03   |  4 ++--
 gcc

[PATCH] S/390: Perform more aggressive inlining

[Robin Dapp]

Hi,

this patch sets the inlining parameters for z13 and later to rather
aggressive values in response to PR85103 that caused performance
regressions in SPEC2006's sjeng and gobmk benchmarks.

Regards
 Robin

--

gcc/ChangeLog:

2019-03-12  Robin Dapp  

* config/s390/s390.c (s390_option_override_internal): Use more
aggressive inlining parameters.
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index aff271806b7..1e268d97ca3 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -14993,6 +14993,18 @@ s390_option_override_internal (struct gcc_options *opts,
 			 opts->x_param_values,
 			 opts_set->x_param_values);
 
+  /* Use aggressive inlining parameters.  */
+  if (opts->x_s390_tune >= PROCESSOR_2964_Z13)
+{
+  maybe_set_param_value (PARAM_INLINE_MIN_SPEEDUP, 2,
+			 opts->x_param_values,
+			 opts_set->x_param_values);
+
+  maybe_set_param_value (PARAM_MAX_INLINE_INSNS_AUTO, 80,
+			 opts->x_param_values,
+			 opts_set->x_param_values);
+}
+
   /* Set the default alignment.  */
   s390_default_align (opts);
 

Re: [PATCH 8/8] S/390: Change test case to reflect scheduling changes.

[Robin Dapp]

This fixes a newly introduced test failure.


---

2019-03-12  Robin Dapp  

* gcc.target/s390/memset-1.c: Do not require stcy.
diff --git a/gcc/testsuite/gcc.target/s390/memset-1.c b/gcc/testsuite/gcc.target/s390/memset-1.c
index 3e201df1aed..9463a77208b 100644
--- a/gcc/testsuite/gcc.target/s390/memset-1.c
+++ b/gcc/testsuite/gcc.target/s390/memset-1.c
@@ -74,7 +74,7 @@ void
   return __builtin_memset (s, c, 1029);
 }
 
-/* 2 stc 1 stcy 3 mvc - displacement overflow after the first */
+/* 3 stc 3 mvc - displacement overflow after the first */
 void
 *memset10(void *s, int c)
 {
@@ -172,6 +172,6 @@ void
 /* { dg-final { scan-assembler-times "mvi\\s" 1 } } */
 /* { dg-final { scan-assembler-times "mvc\\s" 20 } } */
 /* { dg-final { scan-assembler-times "xc\\s" 28 } } */
-/* { dg-final { scan-assembler-times "stc\\s" 21 } } */
-/* { dg-final { scan-assembler-times "stcy\\s" 1 } } */
+/* { dg-final { scan-assembler-times "stc\\s" 22 } } */
+/* { dg-final { scan-assembler-times "stcy\\s" 0 } } */
 /* { dg-final { scan-assembler-times "pfd\\s" 2 } } */

Re: [PATCH] s390.md and tilepro.c diagnostics bug fix (PR target/52726)

[Andreas Krebbel]

On 12.03.19 10:58, Jakub Jelinek wrote:
> 2019-03-12  Jakub Jelinek  
> 
>   PR target/52726
>   * config/s390/s390.md (tabort): Use %wd instead of
>   HOST_WIDE_INT_PRINT_DEC in error message, reword to avoid two capital
>   letters and periods.
>   * config/tilepro/tilepro.c (tilepro_print_operand): Use %wd in
>   output_operand_lossage instead of HOST_WIDE_INT_PRINT_DEC, replace
>   's with %< and %>.

Ok. Thanks!

Andreas

Re: [PATCH 0/7] S/390: Rework instruction scheduling.

[Robin Dapp]

> Please adjust the year and the author in gcc/config/s390/3906.md. Ok with 
> that change.

Changed that and also simplified the longrunning checks.

gcc/ChangeLog:

2019-03-12  Robin Dapp  

* config/s390/s390.c (LONGRUNNING_THRESHOLD): Remove.
(s390_is_fpd): Add.
(s390_is_fxd): Add.
(s390_is_longrunning): Add.
(s390_sched_score): Use new functions.
(s390_sched_variable_issue): Use new functions.
>From f92c9095f622453baf9607d1669b1f7e7048aae8 Mon Sep 17 00:00:00 2001
From: Robin Dapp 
Date: Wed, 27 Feb 2019 11:16:07 +0100
Subject: [PATCH 3/8] S/390: Change handling of long-running instructions.
This patch makes the detection of long-running instructions
independent of their latency but checks the execution unit.

---
 gcc/config/s390/s390.c | 80 +++---
 1 file changed, 60 insertions(+), 20 deletions(-)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 95a4460dcf5..f93a94550cc 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -349,12 +349,11 @@ static int last_scheduled_unit_distance[MAX_SCHED_UNITS];
 
 #define NUM_SIDES 2
 static int current_side = 1;
-#define LONGRUNNING_THRESHOLD 20
 
 /* Estimate of number of cycles a long-running insn occupies an
execution unit.  */
-static unsigned fxd_longrunning[NUM_SIDES];
-static unsigned fpd_longrunning[NUM_SIDES];
+static int fxd_longrunning[NUM_SIDES];
+static int fpd_longrunning[NUM_SIDES];
 
 /* The maximum score added for an instruction whose unit hasn't been
in use for MAX_SCHED_MIX_DISTANCE steps.  Increase this value to
@@ -14357,6 +14356,35 @@ s390_get_unit_mask (rtx_insn *insn, int *units)
   return mask;
 }
 
+static bool
+s390_is_fpd (rtx_insn *insn)
+{
+  if (insn == NULL_RTX)
+return false;
+
+  return get_attr_z13_unit_fpd (insn) || get_attr_z14_unit_fpd (insn);
+}
+
+static bool
+s390_is_fxd (rtx_insn *insn)
+{
+  if (insn == NULL_RTX)
+return false;
+
+  return get_attr_z13_unit_fxd (insn) || get_attr_z14_unit_fxd (insn);
+}
+
+/* Returns TRUE if INSN is a long-running instruction.  */
+static bool
+s390_is_longrunning (rtx_insn *insn)
+{
+  if (insn == NULL_RTX)
+return false;
+
+  return s390_is_fxd (insn) || s390_is_fpd (insn);
+}
+
+
 /* Return the scheduling score for INSN.  The higher the score the
better.  The score is calculated from the OOO scheduling attributes
of INSN and the scheduling state s390_sched_state.  */
@@ -14432,20 +14460,34 @@ s390_sched_score (rtx_insn *insn)
 	  score += (last_scheduled_unit_distance[i] * MAX_SCHED_MIX_SCORE /
 		MAX_SCHED_MIX_DISTANCE);
 
-  unsigned latency = insn_default_latency (insn);
-
   int other_side = 1 - current_side;
 
   /* Try to delay long-running insns when side is busy.  */
-  if (latency > LONGRUNNING_THRESHOLD)
+  if (s390_is_longrunning (insn))
 	{
-	  if (get_attr_z13_unit_fxu (insn) && fxd_longrunning[current_side]
-	  && fxd_longrunning[other_side] <= fxd_longrunning[current_side])
-	score = MAX (0, score - 10);
+	  if (s390_is_fxd (insn))
+	{
+	  if (fxd_longrunning[sched_state.side]
+		  && fxd_longrunning[other_side]
+		  <= fxd_longrunning[sched_state.side])
+		score = MAX (0, score - 10);
+
+	  else if (fxd_longrunning[other_side]
+		  >= fxd_longrunning[sched_state.side])
+		score += 10;
+	}
 
-	  if (get_attr_z13_unit_vfu (insn) && fpd_longrunning[current_side]
-	  && fpd_longrunning[other_side] <= fpd_longrunning[current_side])
-	score = MAX (0, score - 10);
+	  if (s390_is_fpd (insn))
+	{
+	  if (fpd_longrunning[sched_state.side]
+		  && fpd_longrunning[other_side]
+		  <= fpd_longrunning[sched_state.side])
+		score = MAX (0, score - 10);
+
+	  else if (fpd_longrunning[other_side]
+		  >= fpd_longrunning[sched_state.side])
+		score += 10;
+	}
 	}
 }
 
@@ -14629,19 +14671,17 @@ s390_sched_variable_issue (FILE *file, int verbose, rtx_insn *insn, int more)
 
   for (int i = 0; i < 2; i++)
 	{
-	  if (fxd_longrunning[i] >= 1)
-	fxd_longrunning[i] -= 1;
-	  if (fpd_longrunning[i] >= 1)
-	fpd_longrunning[i] -= 1;
+	  fxd_longrunning[i] = MAX (0, fxd_longrunning[i] - 1);
+	  fpd_longrunning[i] = MAX (0, fpd_longrunning[i] - 1);
 	}
 
   unsigned latency = insn_default_latency (insn);
-  if (latency > LONGRUNNING_THRESHOLD)
+  if (s390_is_longrunning (insn))
 	{
-	  if (get_attr_z13_unit_fxu (insn))
-	fxd_longrunning[current_side] = latency;
+	  if (s390_is_fxd (insn))
+	fxd_longrunning[sched_state.side] = latency;
 	  else
-	fpd_longrunning[current_side] = latency;
+	fpd_longrunning[sched_state.side] = latency;
 	}
 
   if (verbose > 5)
-- 
2.17.0

[PATCH] s390.md and tilepro.c diagnostics bug fix (PR target/52726)

[Jakub Jelinek]

Hi!

These are the only remaining cases of gcc-internal-format diagnostics using
HOST_WIDE_INT_PRINT*.  That is wrong because the string depends on the exact
host, and xgettext doesn't handle it anyway, so in gcc.pot the messages are
truncated at the spot where HOST_WIDE_INT_PRINT* appears.  See also
PR79846 for an earlier change of the same kind.

On the s390 side, I've also tweaked the message slightly, because gcc
diagnostics should not be in full sentences and should not end with period,
otherwise I'd commit this patch as obvious.

Tested on a cross to s390x-linux on the gcc.target/s390/htm-builtins-compile-2.c
testcase.  Ok for trunk?

2019-03-12  Jakub Jelinek  

PR target/52726
* config/s390/s390.md (tabort): Use %wd instead of
HOST_WIDE_INT_PRINT_DEC in error message, reword to avoid two capital
letters and periods.
* config/tilepro/tilepro.c (tilepro_print_operand): Use %wd in
output_operand_lossage instead of HOST_WIDE_INT_PRINT_DEC, replace
's with %< and %>.

--- gcc/config/s390/s390.md.jj  2019-02-18 20:48:32.856728812 +0100
+++ gcc/config/s390/s390.md 2019-03-12 10:44:38.023960583 +0100
@@ -11474,9 +11474,8 @@ (define_expand "tabort"
   if (CONST_INT_P (operands[0])
   && INTVAL (operands[0]) >= 0 && INTVAL (operands[0]) <= 255)
 {
-  error ("invalid transaction abort code: " HOST_WIDE_INT_PRINT_DEC
-".  Values in range 0 through 255 are reserved.",
-INTVAL (operands[0]));
+  error ("invalid transaction abort code: %wd;  values in range 0 "
+"through 255 are reserved", INTVAL (operands[0]));
   FAIL;
 }
 })
--- gcc/config/tilepro/tilepro.c.jj 2019-01-01 12:37:28.540788187 +0100
+++ gcc/config/tilepro/tilepro.c2019-03-12 10:46:40.995960027 +0100
@@ -4771,8 +4771,7 @@ tilepro_print_operand (FILE *file, rtx x
i = exact_log2 (n);
if (i < 0)
  {
-   output_operand_lossage ("invalid %%t operand '"
-   HOST_WIDE_INT_PRINT_DEC "'", n);
+   output_operand_lossage ("invalid %%t operand %<%wd%>", n);
return;
  }
 

Jakub

New target hook for function scratch registers (PR 89628)

[Richard Sandiford]

Steve Ellcey  writes:
> Richard,
>
> I don't necessarily disagree with anything in your comments and long
> term I think that is the right direction, but I wonder if that level of
> change is appropriate for GCC Stage 4 which is where we are now.  Your
> changes would require fixes in shared code, whereas setting
> REG_ALLOC_ORDER only affects Aarch64 and seems like a safer change.

I guess it's weighing invasiveness in terms of lines of code/location of
code vs. invasiveness in terms of the effect the code has.  Changing
REG_ALLOC_ORDER affects all functinos that use significant numbers of
SIMD registers, which could have unexpected knock-on effects like
performance regressions or exposing latent bugs.  It would also make
the RA try V24 before V16 for callers of vector PCS functions,
even though they should prefer V16.

Keeping the change specific to callees that use the new vector PCS
feature seems more conservative from that point of view.

> I am not sure how long it would take me to implement something along
> the lines of what you are suggesting.

OK, in that case, I thought I'd give a go.

This patch adds a new target hook that says which registers a function
can use without saving them in the prologue and restoring them in the
epilogue.  By default this is call_used_reg_set.

The patch only makes IRA use the hook, and in that context it's just
an (important) optimisation.  But I think we need the same thing for
passes like regrename, where it'll be a correctness issue.  I'll follow
on with patches there if this one is OK.

Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu.
OK to install?

Richard


2019-03-12  Richard Sandiford  

gcc/
PR target/89628
* target.def (function_scratch_regs): New hook.
* doc/tm.texi.in (TARGET_FUNCTION_SCRATCH_REGS): New placeholder.
* doc/tm.texi: Regenerate.
* targhooks.h (default_function_scratch_regs): Declare.
* targhooks.c (default_function_scratch_regs): New function.
* emit-rtl.h (rtl_data::scratch_regs): New member variable.
* function.c (init_dummy_function_start): Initialize it.
(init_function_start): Likewise.
* ira-color.c (calculate_saved_nregs): Use it instead of
call_used_reg_set.
* config/aarch64/aarch64.c (aarch64_function_scratch_regs): New
function.
(TARGET_FUNCTION_SCRATCH_REGS): Redefine.

gcc/testsuite/
PR target/89628
* gcc.target/aarch64/pr89628.c: New test.

Index: gcc/target.def
===
--- gcc/target.def  2019-03-08 18:14:26.113008680 +
+++ gcc/target.def  2019-03-12 09:34:25.447913041 +
@@ -5763,6 +5763,18 @@ The default version of this hook always
  default_hard_regno_scratch_ok)
 
 DEFHOOK
+(function_scratch_regs,
+ "This hook sets @var{regs} to the set of registers that function @var{fn}\n\
+can use without having to save them in the prologue and restore them in the\n\
+epilogue.\n\
+\n\
+By default this set is the same as @code{call_used_reg_set}.  Targets only\n\
+need to override the hook if some functions implement alternative ABIs that\n\
+save more registers or fewer registers than normal.",
+ void, (struct function *fn, HARD_REG_SET *regs),
+ default_function_scratch_regs)
+
+DEFHOOK
 (hard_regno_call_part_clobbered,
  "This hook should return true if @var{regno} is partly call-saved and\n\
 partly call-clobbered, and if a value of mode @var{mode} would be partly\n\
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in  2019-03-08 18:14:25.577010718 +
+++ gcc/doc/tm.texi.in  2019-03-12 09:34:25.443913054 +
@@ -1705,6 +1705,11 @@ of @code{CALL_USED_REGISTERS}.
 @cindex call-used register
 @cindex call-clobbered register
 @cindex call-saved register
+@hook TARGET_FUNCTION_SCRATCH_REGS
+
+@cindex call-used register
+@cindex call-clobbered register
+@cindex call-saved register
 @hook TARGET_HARD_REGNO_CALL_PART_CLOBBERED
 
 @hook TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi 2019-03-08 18:14:25.573010734 +
+++ gcc/doc/tm.texi 2019-03-12 09:34:25.443913054 +
@@ -1894,6 +1894,19 @@ of @code{CALL_USED_REGISTERS}.
 @cindex call-used register
 @cindex call-clobbered register
 @cindex call-saved register
+@deftypefn {Target Hook} void TARGET_FUNCTION_SCRATCH_REGS (struct function 
*@var{fn}, HARD_REG_SET *@var{regs})
+This hook sets @var{regs} to the set of registers that function @var{fn}
+can use without having to save them in the prologue and restore them in the
+epilogue.
+
+By default this set is the same as @code{call_used_reg_set}.  Targets only
+need to override the hook if some functions implement alternative ABIs that
+save more registers or fewer registers than normal.
+@end deftypefn
+
+@cindex call-used register
+@cin

[PATCH] GCOV: print {start,end}_column in JSON file and gcov-dump tool.

[Martin Liška]

Hi.

This is one more enhancement of JSON intermediate format export. Apart from
that, I also improved documentation of the format and gcov-dump output.

Patch survives gcov.exp regression tests. I'm going to install the patch
after some time.

Thanks,
Martin

gcc/ChangeLog:

2019-03-11  Martin Liska  

* coverage.c (coverage_begin_function): Stream also
end_column.
* doc/gcov.texi: Document 2 new fields in JSON file.  Improve
documentation about function declaration location.
* gcov-dump.c (tag_function): Print whole range
of function declaration.
* gcov.c (struct function_info): Add end_column field.
(function_info::function_info): Initialize it.
(output_json_intermediate_file): Output {start,end}_column
fields.
(read_graph_file): Read end_column.
---
 gcc/coverage.c|  2 ++
 gcc/doc/gcov.texi | 15 ++-
 gcc/gcov-dump.c   |  4 +++-
 gcc/gcov.c| 10 +-
 4 files changed, 28 insertions(+), 3 deletions(-)


diff --git a/gcc/coverage.c b/gcc/coverage.c
index a34c5da49bf..1ffefd5f482 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -652,8 +652,10 @@ coverage_begin_function (unsigned lineno_checksum, unsigned cfg_checksum)
 
   /* Function can start in a single file and end in another one.  */
   int end_line = endloc.file == xloc.file ? endloc.line : xloc.line;
+  int end_column = endloc.file == xloc.file ? endloc.column: xloc.column;
   gcc_assert (xloc.line <= end_line);
   gcov_write_unsigned (end_line);
+  gcov_write_unsigned (end_column);
   gcov_write_length (offset);
 
   return !gcov_is_error ();
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index 0960e4acb26..ecad5d11847 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -236,9 +236,11 @@ Each @var{function} has the following form:
   "blocks": @var{blocks},
   "blocks_executed": @var{blocks_executed},
   "demangled_name": "@var{demangled_name},
+  "end_column": @var{end_column},
   "end_line": @var{end_line},
   "execution_count": @var{execution_count},
   "name": @var{name},
+  "start_column": @var{start_column}
   "start_line": @var{start_line}
 @}
 @end smallexample
@@ -255,6 +257,9 @@ Fields of the @var{function} element have following semantics:
 @item
 @var{demangled_name}: demangled name of the function
 
+@item
+@var{end_column}: column in the source file where the function ends
+
 @item
 @var{end_line}: line in the source file where the function ends
 
@@ -264,10 +269,18 @@ Fields of the @var{function} element have following semantics:
 @item
 @var{name}: name of the function
 
+@item
+@var{start_column}: column in the source file where the function begins
+
 @item
 @var{start_line}: line in the source file where the function begins
 @end itemize
 
+Note that line numbers and column numbers number from 1.  In the current
+implementation, @var{start_line} and @var{start_column} do not include
+any template parameters and the leading return type but that
+this is likely to be fixed in the future.
+
 Each @var{line} has the following form:
 
 @smallexample
@@ -293,11 +306,11 @@ Fields of the @var{line} element have following semantics:
 @item
 @var{unexecuted_block}: flag whether the line contains an unexecuted block
 (not all statements on the line are executed)
-@end itemize
 
 @item
 @var{function_name}: a name of a function this @var{line} belongs to
 (for a line with an inlined statements can be not set)
+@end itemize
 
 Each @var{branch} has the following form:
 
diff --git a/gcc/gcov-dump.c b/gcc/gcov-dump.c
index 72d94d95165..67b1e88a5bc 100644
--- a/gcc/gcov-dump.c
+++ b/gcc/gcov-dump.c
@@ -315,7 +315,9 @@ tag_function (const char *filename ATTRIBUTE_UNUSED,
 	  unsigned line_start = gcov_read_unsigned ();
 	  unsigned column_start = gcov_read_unsigned ();
 	  unsigned line_end = gcov_read_unsigned ();
-	  printf (":%u:%u:%u", line_start, column_start, line_end);
+	  unsigned column_end = gcov_read_unsigned ();
+	  printf (":%u:%u-%u:%u", line_start, column_start,
+		  line_end, column_end);
 	  if (artificial)
 	printf (", artificial");
 	}
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 37e787a1823..1d576552a45 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -283,6 +283,9 @@ struct function_info
   /* Last line number.  */
   unsigned end_line;
 
+  /* Last line column.  */
+  unsigned end_column;
+
   /* Index of source file where the function is defined.  */
   unsigned src;
 
@@ -631,7 +634,8 @@ function_info::function_info (): m_name (NULL), m_demangled_name (NULL),
   ident (0), lineno_checksum (0), cfg_checksum (0), has_catch (0),
   artificial (0), is_group (0),
   blocks (), blocks_executed (0), counts (),
-  start_line (0), start_column (), end_line (0), src (0), lines (), next (NULL)
+  start_line (0), start_column (0), end_line (0), end_column (0),
+  src (0), lines (), next (NULL)
 {
 }
 
@@ -1131,7 +1135,9 @@ output_json_intermediate_file (json::array *json_files, source_info *src)
   functio

[PATCH][stage1] Refactor gimple_fold_builtin_memory_op function.

[Martin Liška]

Hi.

The patch is about simplification and usage of enum types. ENDP integer
does not make much sense in this usage.

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

Ready to be installed after stage1 opens?
Thanks,
Martin

2019-03-11  Martin Liska  

* gimple-fold.c (gimple_fold_builtin_memory_op): Change endp
into built_in_function enum. Remove code for endp == 2 and
use BUILT_IN_* constants.
(gimple_fold_builtin): Call the function with fcode.
---
 gcc/gimple-fold.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)


diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 62d2e0abc26..e0da5ef6723 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -692,7 +692,7 @@ size_must_be_zero_p (tree size)
 
 static bool
 gimple_fold_builtin_memory_op (gimple_stmt_iterator *gsi,
-			   tree dest, tree src, int endp)
+			   tree dest, tree src, enum built_in_function code)
 {
   gimple *stmt = gsi_stmt (*gsi);
   tree lhs = gimple_call_lhs (stmt);
@@ -839,7 +839,7 @@ gimple_fold_builtin_memory_op (gimple_stmt_iterator *gsi,
 	}
 	}
 
-  if (endp == 3)
+  if (code == BUILT_IN_MEMMOVE)
 	{
 	  /* Both DEST and SRC must be pointer types.
 	 ??? This is what old code did.  Is the testing for pointer types
@@ -1102,17 +1102,16 @@ set_vop_and_replace:
 
 done:
   gimple_seq stmts = NULL;
-  if (endp == 0 || endp == 3)
+  if (code == BUILT_IN_MEMCPY || code == BUILT_IN_MEMMOVE)
 len = NULL_TREE;
-  else if (endp == 2)
-len = gimple_build (&stmts, loc, MINUS_EXPR, TREE_TYPE (len), len,
-			ssize_int (1));
-  if (endp == 2 || endp == 1)
+  else if (code == BUILT_IN_MEMPCPY)
 {
   len = gimple_convert_to_ptrofftype (&stmts, loc, len);
   dest = gimple_build (&stmts, loc, POINTER_PLUS_EXPR,
 			   TREE_TYPE (dest), dest, len);
 }
+  else
+gcc_unreachable ();
 
   gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
   gimple *repl = gimple_build_assign (lhs, dest);
@@ -3848,14 +3847,10 @@ gimple_fold_builtin (gimple_stmt_iterator *gsi)
 	 gimple_call_arg (stmt, 1),
 	 gimple_call_arg (stmt, 2));
 case BUILT_IN_MEMCPY:
-  return gimple_fold_builtin_memory_op (gsi, gimple_call_arg (stmt, 0),
-	gimple_call_arg (stmt, 1), 0);
 case BUILT_IN_MEMPCPY:
-  return gimple_fold_builtin_memory_op (gsi, gimple_call_arg (stmt, 0),
-	gimple_call_arg (stmt, 1), 1);
 case BUILT_IN_MEMMOVE:
   return gimple_fold_builtin_memory_op (gsi, gimple_call_arg (stmt, 0),
-	gimple_call_arg (stmt, 1), 3);
+	gimple_call_arg (stmt, 1), fcode);
 case BUILT_IN_SPRINTF_CHK:
 case BUILT_IN_VSPRINTF_CHK:
   return gimple_fold_builtin_sprintf_chk (gsi, fcode);

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Martin Liška]

On 3/11/19 4:51 PM, Martin Sebor wrote:
> On 3/11/19 2:13 AM, Martin Liška wrote:
>> Hi.
>>
>> The patch adds a lot of option name wrapping in string format messages. I 
>> added a new contrib
>> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot 
>> file and reports
>> errors.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>> Apart from that I built all cross compilers and compared all warnings so that
>> I don't introduce a bootstrap error. It's expected that various 
>> target-specific
>> tests will need wrapping in scanned patterns.

Hi.

> 
> This looks great to me.  One change I would consider is making
> the built-in and option strings arguments to %qs rather than
> parts of the format strings.  That should reduce the overall
> number of format strings that need to be translated, and also
> make it easier to spot inconsistencies between the phrasing
> or opportunities to make the phrasing more uniform.

I welcome that and it would be more work to be done on top of the
wrapping I did. But it would be useful.

Thanks,
Martin

> 
> (I still plan to work on the warning we said we'd add to keep
> the missing quoting from creeping back in.)
> 
> Martin
> 
>>
>> Is it fine for next stage1?
>> Thanks,
>> Martin
>>
> 

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

[Jakub Jelinek]

On Tue, Mar 12, 2019 at 09:33:40AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 12, 2019 at 09:25:35AM +0100, Richard Biener wrote:
> > I think this needs to be fixed on the glibc side - if glibc advertises
> > 
> > float expf (float, float)
> > __attribute__((simd(notinbranch),alias("__expf_finite"))
> > 
> > or so then you of course have to provide an implementation that matches 
> > this.
> > 
> > It shouldn't be difficult to provide an alias from the glibc side, no?  How 
> > does
> > x86 avoid this issue?
> 
> Yeah, the patch looks just wrong, it is completely intentional that we use
> DECL_ASSEMBLER_NAME, it is part of the OpenMP ABI, e.g. for C++ we really
> need to use the C++ mangled names there, can't use foo or __ct instead of
> say _Z3fooii or _ZN1AC2Ev as the base parts of the names.
> 
> Please have a look at how this works on x86_64 on the glibc side and do the
> aarch64 glibc patch similarly.

Trying:
#include 

double a[1024];

void
foo (void)
{
  for (int i = 0; i < 1024; i++)
a[i] = exp (a[i]);
}

void
bar (void)
{
  for (int i = 0; i < 1024; i++)
a[i] = sin (a[i]);
}

int
main ()
{
  return 0;
}

on x86_64 with -Ofast -lmvec this works for sin, but doesn't link for exp.
You've hit a glibc bug then, this needs to be fixed on the glibc side,
probably by adding aliases.

Jakub

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

[Jakub Jelinek]

On Tue, Mar 12, 2019 at 09:25:35AM +0100, Richard Biener wrote:
> I think this needs to be fixed on the glibc side - if glibc advertises
> 
> float expf (float, float)
> __attribute__((simd(notinbranch),alias("__expf_finite"))
> 
> or so then you of course have to provide an implementation that matches this.
> 
> It shouldn't be difficult to provide an alias from the glibc side, no?  How 
> does
> x86 avoid this issue?

Yeah, the patch looks just wrong, it is completely intentional that we use
DECL_ASSEMBLER_NAME, it is part of the OpenMP ABI, e.g. for C++ we really
need to use the C++ mangled names there, can't use foo or __ct instead of
say _Z3fooii or _ZN1AC2Ev as the base parts of the names.

Please have a look at how this works on x86_64 on the glibc side and do the
aarch64 glibc patch similarly.

> > 2018-03-11  Steve Ellcey  
> >
> > * config/aarch64/aarch64.c (aarch64_simd_clone_vec_base_name):
> > New function.
> > (TARGET_SIMD_CLONE_VEC_BASE_NAME): New macro.
> > * doc/tm.texi.in (TARGET_SIMD_CLONE_VEC_BASE_NAME): New hook.
> > * doc/tm.texi: Regenerate.
> > * omp-simd-clone.c (simd_clone_mangle): Call vec_base_name hook.
> > * target.def (vec_base_name): New hook.
> > * targhooks.c (cgraph.h): New include.
> > (default_vec_base_name): New function.
> > * targhooks.h (default_vec_base_name): New function declaration.
> >

Jakub

Re: [PATCH] Loop split upon semi-invariant condition (PR tree-optimization/89134)

[Richard Biener]

On Tue, Mar 12, 2019 at 7:20 AM Feng Xue OS  wrote:
>
> This patch is composed to implement a loop transformation on one of its 
> conditional statements, which we call it semi-invariant, in that its 
> computation is impacted in only one of its branches.
>
> Suppose a loop as:
>
> void f (std::map m)
> {
> for (auto it = m.begin (); it != m.end (); ++it) {
> /* if (b) is semi-invariant. */
> if (b) {
> b = do_something();/* Has effect on b */
> } else {
> /* No effect on b */
> }
> statements;  /* Also no effect on b */
> }
> }
>
> A transformation, kind of loop split, could be:
>
> void f (std::map m)
> {
> for (auto it = m.begin (); it != m.end (); ++it) {
> if (b) {
> b = do_something();
> } else {
> ++it;
> statements;
> break;
> }
> statements;
> }
>
> for (; it != m.end (); ++it) {
> statements;
> }
> }
>
> If "statements" contains nothing, the second loop becomes an empty one, which 
> can be removed. (This part will be given in another patch). And if 
> "statements" are straight line instructions, we get an opportunity to 
> vectorize the second loop. In practice, this optimization is found to improve 
> some real application by %7.
>
> Since it is just a kind of loop split, the codes are mainly placed in 
> existing tree-ssa-loop-split module, and is controlled by -fsplit-loop, and 
> is enabled with -O3.

Note the transform itself is jump-threading with the threading
duplicating a whole CFG cycle.

I didn't look at the patch details yet since this is suitable for GCC 10 only.

Thanks for implementing this.
Richard.

> Feng
>
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 64bf6017d16..a6c2878d652 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,23 @@
> +2019-03-12  Feng Xue 
> +
> +   PR tree-optimization/89134
> +* doc/invoke.texi (max-cond-loop-split-insns): Document new --params.
> +   (min-cond-loop-split-prob): Likewise.
> +   * params.def: Add max-cond-loop-split-insns, min-cond-loop-split-prob.
> +   * passes.def (pass_cond_loop_split) : New pass.
> +   * timevar.def (TV_COND_LOOP_SPLIT): New time variable.
> +   * tree-pass.h (make_pass_cond_loop_split): New declaration.
> +   * tree-ssa-loop-split.c (split_info): New class.
> +   (find_vdef_in_loop, vuse_semi_invariant_p): New functions.
> +   (ssa_semi_invariant_p, stmt_semi_invariant_p): Likewise.
> +   (can_branch_be_excluded, get_cond_invariant_branch): Likewise.
> +   (is_cond_in_hidden_loop, compute_added_num_insns): Likewise.
> +   (can_split_loop_on_cond, mark_cond_to_split_loop): Likewise.
> +   (split_loop_for_cond, tree_ssa_split_loops_for_cond): Likewise.
> +   (pass_data_cond_loop_split): New variable.
> +   (pass_cond_loop_split): New class.
> +   (make_pass_cond_loop_split): New function.
> +
>  2019-03-11  Jakub Jelinek  
>
> PR middle-end/89655
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index df0883f2fc9..f5e09bd71fd 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -11316,6 +11316,14 @@ The maximum number of branches unswitched in a 
> single loop.
>  @item lim-expensive
>  The minimum cost of an expensive expression in the loop invariant motion.
>
> +@item max-cond-loop-split-insns
> +The maximum number of insns to be increased due to loop split on
> +semi-invariant condition statement.
> +
> +@item min-cond-loop-split-prob
> +The minimum threshold for probability of semi-invaraint condition
> +statement to trigger loop split.
> +
>  @item iv-consider-all-candidates-bound
>  Bound on number of candidates for induction variables, below which
>  all candidates are considered for each use in induction variable
> diff --git a/gcc/params.def b/gcc/params.def
> index 3f1576448be..2e067526958 100644
> --- a/gcc/params.def
> +++ b/gcc/params.def
> @@ -386,6 +386,18 @@ DEFPARAM(PARAM_MAX_UNSWITCH_LEVEL,
> "The maximum number of unswitchings in a single loop.",
> 3, 0, 0)
>
> +/* The maximum number of increased insns due to loop split on semi-invariant
> +   condition statement.  */
> +DEFPARAM(PARAM_MAX_COND_LOOP_SPLIT_INSNS,
> +   "max-cond-loop-split-insns",
> +   "The maximum number of insns to be increased due to loop split on 
> semi-invariant condition statement.",
> +   100, 0, 0)
> +
> +DEFPARAM(PARAM_MIN_COND_LOOP_SPLIT_PROB,
> +   "min-cond-loop-split-prob",
> +   "The minimum threshold for probability of semi-invaraint condition 
> statement to trigger loop split.",
> +   30, 0, 100)
> +
>  /* The maximum number of insns in loop header duplicated by the copy loop
> headers pass.  */
>  DEFPARAM

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

[Richard Biener]

On Mon, Mar 11, 2019 at 11:39 PM Steve Ellcey  wrote:
>
> This is a proposed GCC patch that allows targets to modify the names of
> the libmvec routines that get called.  Currently, if you build ToT GCC
> on Aarch64 and include this glibc patch:
>
> https://sourceware.org/ml/libc-alpha/2019-03/msg00106.html
>
> And then compile a call to expf which gets vectorized, GCC will
> generate a libmvec call to '_ZGVnN4v___expf_finite' instead of
> _ZGVnN4v_expf because the limvec name is based on the assembly name
> of the scalar function (__expf_finite) and not the 'real' name (expf).
> This means that libmvec needs to provide both names, even though the
> routines don't differ.
>
> Rather than create both names I would like to make it possible for
> GCC to generate calls to libmvec based on the real name by having
> a target specific function that allows GCC to use the DECL_NAME instead
> of DECL_ASSEMBLER_NAME to create the libmvec name.
>
> The responses to my glibc patch (referenced above) has a pointer
> to where this was discussed in the GCC mailing list a couple of years
> ago:
>
> https://gcc.gnu.org/ml/gcc/2015-06/msg00173.html
>
> and which has a pointer back to an older glibc string as well:
>
> https://sourceware.org/ml/libc-alpha/2015-06/msg00213.html
>
> Any thoughts on this patch as a way of 'fixing' GCC to not use the
> finite alias names?

I think this needs to be fixed on the glibc side - if glibc advertises

float expf (float, float)
__attribute__((simd(notinbranch),alias("__expf_finite"))

or so then you of course have to provide an implementation that matches this.

It shouldn't be difficult to provide an alias from the glibc side, no?  How does
x86 avoid this issue?

Richard.

> Steve Ellcey
> sell...@marvell.com
>
>
> 2018-03-11  Steve Ellcey  
>
> * config/aarch64/aarch64.c (aarch64_simd_clone_vec_base_name):
> New function.
> (TARGET_SIMD_CLONE_VEC_BASE_NAME): New macro.
> * doc/tm.texi.in (TARGET_SIMD_CLONE_VEC_BASE_NAME): New hook.
> * doc/tm.texi: Regenerate.
> * omp-simd-clone.c (simd_clone_mangle): Call vec_base_name hook.
> * target.def (vec_base_name): New hook.
> * targhooks.c (cgraph.h): New include.
> (default_vec_base_name): New function.
> * targhooks.h (default_vec_base_name): New function declaration.
>

Re: [PATCH] avoid assuming every type has a size (PR 89662)

[Richard Biener]

On Mon, Mar 11, 2019 at 9:16 PM Martin Sebor  wrote:
>
> A -Warray-bounds enhancement committed last year into GCC 9
> introduced an assumption that the MEM_REF type argument has
> a size.  The test case submitted in PR89662 does pointer
> addition on void*, in which the MEM_REF type is void*, which
> breaks the assumption.
>
> The attached change removes this assumption and considers such
> types to have the size of 1.  (The result is used to scale
> the offset in diagnostics after it has been determined to be
> out of bounds.)

Why's this not catched here:

  if (POINTER_TYPE_P (reftype)
  || !COMPLETE_TYPE_P (reftype)
^^^

  || TREE_CODE (TYPE_SIZE_UNIT (reftype)) != INTEGER_CST
  || RECORD_OR_UNION_TYPE_P (reftype))
return;

and what avoids the bad situation for

  char (*a)[n];
  sink (a - 1);

?  That is, the code assumes TYPE_SIZE_UNIT is an INTEGER_CST
but the above should get you a non-constant type?  It's probably
easier to generate a gimple testcase with this.

Richard.

> Martin

Re: [PATCH] Fix -gdwarf-5 -gsplit-dwarf ICEs (PR debug/89498)

[Alexandre Oliva]

On Mar  9, 2019, Alexandre Oliva  wrote:

> On Mar  9, 2019, Jakub Jelinek  wrote:
>> If so, then all we need is likely my patch + some documentation change,
>> though not sure where exactly it should be documented, some Wiki we refer
>> in include/dwarf2.def, or what?

> Hmm, I was thinking of placing it next to dwarf6-sfn-lvu.txt in
> https://people.redhat.com/aoliva/papers/sfn/ but there seem to be
> several extensions documented in the GCC wiki, so I guess I could do
> that instead, or as well.  I'll take care of it, and post back when I'm
> done.

Here's a draft description of the representation of locviews in DWARF up
to 5, and, while at that, of DW_AT_GNU_entry_view, to be appended to
dwarf6-sfn-lvu.txt (and possibly massaged into the wiki).

Please let me know if it's sufficiently descriptive and clear, or if you
find anything missing, wrong, unclear or otherwise improvable.  Thanks
in advance,


=
Extensions for DWARF v2 to v5
=

This section documents how location views are implemented as
extensions to earlier versions of DWARF.

View number assignment takes place in the line number table, just as
proposed above.

Attributes and Forms


Location lists are not extensible in DWARF up to v5 in a backward
compatible way.  Thus, augmenting them with view lists relies on a
separate optional attribute:

  DW_AT_GNU_locviews | 0x2137

This attribute should only be present in a DIE that has a
DW_AT_location attribute that references a location list, rather than
a single location.  If this attribute is omitted, the view numbers
associated with any implied or explicit location ranges in the
location are to be taken as zero.

Locviews lists, referenced by DW_AT_GNU_locviews attributes, are to be
placed in the same section as the location lists.

When location lists are referenced in DW_AT_location attributes by an
absolute address in DW_FORM_sec_offset, the corresponding
DW_AT_GNU_locviews attribute can be a DW_FORM_sec_offset with an
absolute address as well.

When generating split (extension to) DWARF up to v4, DW_AT_location is
represented with an offset from the base address in the beginning of
the .debug_loc.dwo section, in DW_FORM_sec_offset.  DW_AT_GNU_locviews
should then be an offset from the same base address, also in
DW_FORM_sec_offset.

When generating split DWARF v5, DW_AT_location is given in
DW_FORM_loclistx, an offset, from the base address after the
.debug_loclists section header, that in turn holds the offset, from
the same base address, of the beginning of the actual location list.
DW_AT_GNU_locviews attributes that augment such location lists shall
use a DW_FORM_sec_offset value, to be interpreted as an offset from
the same base address, rather than from the beginning of the
.debug_loclists section.

For split DWARF v5, it is not recommended for DW_AT_GNU_locviews to
use DW_FORM_loclistx.  Having entries in the loclists index table
referencing locviews rather than loclists might surprise some
consumers, and using out-of-range indirect addresses instead of index
table entries might also surprise them for out-of-range indexing of
the table and for not ultimately referencing a location list.



Separate Locviews lists
---

The locviews list is represented as a sequence of pairs of uleb128
numbers, each pair corresponding to an address range in the location
list, i.e. not including the terminator, in DWARF up to v4, and only
bounded location descriptions in DWARF v5.  The view numbers are
assigned to address ranges in the order they appear.

Where a proposed DWARFv6 combined location+view list could be
represented as:

  DW_LLE_base_address base-address
  DW_LLE_view_pair V1, V2
  DW_LLE_start_end A1, A2, location-expression
  DW_LLE_start_end A3, A4, location-epxression
  DW_LLE_view_pair V5, V6
  DW_LLE_start_length A5, L6, location-expression
  DW_LLE_default location-expression
  DW_LLE_end_of_list

... the locview list output separately for DWARF up to v5 would be:

  V1, V2, 0, 0, V5, V6

for a DWARFv5 location list like the v6 one above, minus the
DW_LLE_view_pair entries.  The view pair for A3 and A4, that could be
omitted in the combined v6 list, has to be explicitly put in up to v5,
because for each bounded location description, there must be a pair of
corresponding view numbers to be matched to the pair of addresses
given by it.

Up to DWARFv4, the location list matching the locview list above would
look as follows:

  -1, base-address
  A1, A2 location-expression
  A3, A4 location-expression
  A5, A5+L6 location-expression
  (the default expression cannot be represented)
  0, 0



Inlined Entry Point View


Optimizing subprograms into which a subroutine was inlined, the entry
point of an inlined subroutine may be at an address associated with
other views, in the enclosing subprogram, in the inlined subroutine,
or even in other inlined subr