Re: Fix canonical types of atomic types

[Martin Liška]

PING^1

On 2/10/19 6:21 PM, Jan Hubicka wrote:
> Hi,
> build_qualified_type adjusts alignment of atomic types to one of minimal
> alignment needed for atomic operations (I think it does so). For packed
> structures this leads to type variant to be created and alignment to be
> updated later.
> 
> If you call again build_qualified_type on packed structures, it won't
> reuse existing type because check_base_type will compare alignment of
> the base type (which is not atomic and has smaller alignment) and will
> end up creating new variant.
> 
> When constructing a canonical types C frontned relies on types being
> shared and this eventually leads to ice in type simplification.
> 
> I think it is easiest to teach check_base_type about minimal alignment.
> 
> Bootstrapped/regtested x86_64-linux.
>   PR lto/88585
>   * tree.c (find_atomic_core_type): Forward declare.
>   (check_base_type): Correctly compare alignments of atomic types.
> Index: tree.c
> ===
> --- tree.c(revision 268742)
> +++ tree.c(working copy)
> @@ -6329,18 +6329,33 @@ check_lang_type (const_tree cand, const_
>return lang_hooks.types.type_hash_eq (cand, base);
>  }
>  
> +static tree find_atomic_core_type (const_tree type);
> +
>  /* Returns true iff unqualified CAND and BASE are equivalent.  */
>  
>  bool
>  check_base_type (const_tree cand, const_tree base)
>  {
> -  return (TYPE_NAME (cand) == TYPE_NAME (base)
> -   /* Apparently this is needed for Objective-C.  */
> -   && TYPE_CONTEXT (cand) == TYPE_CONTEXT (base)
> -   /* Check alignment.  */
> -   && TYPE_ALIGN (cand) == TYPE_ALIGN (base)
> -   && attribute_list_equal (TYPE_ATTRIBUTES (cand),
> -TYPE_ATTRIBUTES (base)));
> +  if (TYPE_NAME (cand) != TYPE_NAME (base)
> +  /* Apparently this is needed for Objective-C.  */
> +  || TYPE_CONTEXT (cand) != TYPE_CONTEXT (base)
> +  || !attribute_list_equal (TYPE_ATTRIBUTES (cand),
> + TYPE_ATTRIBUTES (base)))
> +return false;
> +  /* Check alignment.  */
> +  if (TYPE_ALIGN (cand) == TYPE_ALIGN (base))
> +return true;
> +  /* Atomic types increase minimal alignment.  We must to do so as well
> + or we get duplicated canonical types. See PR88686.  */
> +  if ((TYPE_QUALS (cand) & TYPE_QUAL_ATOMIC))
> +{
> +  /* See if this object can map to a basic atomic type.  */
> +  tree atomic_type = find_atomic_core_type (cand);
> +  if (TYPE_ALIGN (atomic_type) == TYPE_ALIGN (cand)
> +   && TYPE_ALIGN (base) < TYPE_ALIGN (cand))
> +   return true;
> +}
> +  return false;
>  }
>  
>  /* Returns true iff CAND is equivalent to BASE with TYPE_QUALS.  */
> @@ -6373,7 +6388,7 @@ check_aligned_type (const_tree cand, con
> atomic types, and returns that core atomic type.  */
>  
>  static tree
> -find_atomic_core_type (tree type)
> +find_atomic_core_type (const_tree type)
>  {
>tree base_atomic_type;
>  
> 

Go patch committed: Check for duplicate numeric keys in map literals

[Ian Lance Taylor]

This Go frontend patch by Ben Shi checks for duplicate numeric keys in
map literals.  This is for https://golang.org/issue/28104.
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 269241)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-2c74b84184941ebea318f69fe43a81f657790b63
+bc036b3a03e089e78b892067e40dbb0e7ecca9e2
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 269196)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -14454,6 +14454,7 @@ Composite_literal_expression::lower_map(
 {
   Location location = this->location();
   Unordered_map(unsigned int, std::vector) st;
+  Unordered_map(unsigned int, std::vector) nt;
   if (this->vals_ != NULL)
 {
   if (!this->has_keys_)
@@ -14488,8 +14489,8 @@ Composite_literal_expression::lower_map(
  if (!(*p)->is_constant())
continue;
  std::string sval;
- // Check if there are duplicate constant string keys.
- if ((*p)->string_constant_value())
+ Numeric_constant nval;
+ if ((*p)->string_constant_value()) // Check string keys.
{
  unsigned int h = Gogo::hash_string(sval, 0);
  // Search the index h in the hash map.
@@ -14526,6 +14527,42 @@ Composite_literal_expression::lower_map(
  mit->second.push_back(*p);
}
}
+ else if ((*p)->numeric_constant_value()) // Check numeric keys.
+   {
+ unsigned int h = nval.hash(0);
+ Unordered_map(unsigned int, std::vector)::iterator 
mit;
+ mit = nt.find(h);
+ if (mit == nt.end())
+   {
+ // No duplicate since h is a new code.
+ // Create a new vector indexed by h and add it to the hash 
map.
+ std::vector l;
+ l.push_back(*p);
+ std::pair > val(h, l);
+ nt.insert(val);
+   }
+ else
+   {
+ // Do further check since h already exists.
+ for (std::vector::iterator lit =
+  mit->second.begin();
+  lit != mit->second.end();
+  lit++)
+   {
+ Numeric_constant rval;
+ bool ok = (*lit)->numeric_constant_value();
+ go_assert(ok);
+ if (nval.equals(rval))
+   {
+ go_error_at((*p)->location(),
+ "duplicate key in map literal");
+ return Expression::make_error(location);
+   }
+   }
+ // Add this new numeric key to the vector indexed by h.
+ mit->second.push_back(*p);
+   }
+   }
}
 }
 
@@ -16472,6 +16509,36 @@ Numeric_constant::operator=(const Numeri
   return *this;
 }
 
+// Check equality with another numeric constant.
+
+bool
+Numeric_constant::equals(const Numeric_constant& a) const
+{
+  if (this->classification_ != a.classification_)
+return false;
+
+  if (this->type_ != NULL && a.type_ != NULL
+  && !Type::are_identical(this->type_, a.type_,
+ Type::COMPARE_ALIASES, NULL))
+return false;
+
+  switch (a.classification_)
+{
+case NC_INVALID:
+  break;
+case NC_INT:
+case NC_RUNE:
+  return mpz_cmp(this->u_.int_val, a.u_.int_val) == 0;
+case NC_FLOAT:
+  return mpfr_cmp(this->u_.float_val, a.u_.float_val) == 0;
+case NC_COMPLEX:
+  return mpc_cmp(this->u_.complex_val, a.u_.complex_val) == 0;
+default:
+  go_unreachable();
+}
+  return false;
+}
+
 // Clear the contents.
 
 void
@@ -17198,3 +17265,40 @@ Numeric_constant::expression(Location lo
   go_unreachable();
 }
 }
+
+// Calculate a hash code with a given seed.
+
+unsigned int
+Numeric_constant::hash(unsigned int seed) const
+{
+  unsigned long val;
+  const unsigned int PRIME = 97;
+  long e = 0;
+  double f = 1.0;
+  mpfr_t m;
+
+  switch (this->classification_)
+{
+case NC_INVALID:
+  return PRIME;
+case NC_INT:
+case NC_RUNE:
+  val = mpz_get_ui(this->u_.int_val);
+  break;
+case NC_COMPLEX:
+  mpfr_init(m);
+  mpc_abs(m, this->u_.complex_val, MPFR_RNDN);
+  val = mpfr_get_ui(m, MPFR_RNDN);
+  mpfr_clear(m);
+  break;
+case NC_FLOAT:
+  f = mpfr_get_d_2exp(, this->u_.float_val, MPFR_RNDN) * 4294967295.0;
+  val = static_cast(e + static_cast(f));
+  

Re: [committed] [PR rtl-optimization/87761] Don't let trivially dead insns impede regcprop's work

[Jeff Law]

On 2/26/19 5:18 PM, Segher Boessenkool wrote:
> On Tue, Feb 26, 2019 at 04:58:17PM -0700, Jeff Law wrote:
>> On 2/26/19 4:19 PM, Segher Boessenkool wrote:
>>> On Tue, Feb 26, 2019 at 10:07:54AM -0700, Jeff Law wrote:
>> For gcc-10 we should:
>>
>>   1. Avoid really stupid stuff in init-regs.
>>
>>   2. Avoid really stupid stuff in the splitters.
>>
>>   3. Make REE SUBREG-aware
>>
>>   4. Seriously consider a RTL DCE pass after post-reload splitting
>>
>> But none of those would actually fix this BZ :-)
> 
> Since we are talking about pie-in-the-sky stuff...  I'd like to run some
> kind of mini-combine after every split pass (just on the new insns).  As
> it is the (later) splitters often leave non-optimal code unless a lot of
> work is put into those splitters.  We should not have as many late
> splitters as we do, but for those we do need, it would be helpful if the
> compiler could do simple combinations without having to hand-code them.
#1 is downright trivial.  #2 is pretty easy as well.  #3 could be
painful, but is probably worth it.  #4 is trivial, but would probably
have a measurable compile-time cost.

> 
>>> [ I don't see any problems with -O2 btw, only with -O1, so should we care
>>> at all anyway? ]
>> You can get this stuff at -O2 on other platforms.  It's far more common
>> than I ever imagined.
> 
> Yeah, that's because the testcase uses -fno-split-wide-types.  The subreg
> passes do great work :-)
My point is we see this stuff all the time on common platforms with
simple -O2 optimization.  It deleted something like 2k dead insns on an
x86_64 bootstrap before I added goof'd up trap_p test.  What I don't
have a sense of is how often removing that trivially dead code
ultimately helped cprop on x86_64.  But the amount of trivially dead
code on a standard -O2 bootstrap was a huge surprise.

Jeff

[PATCH v2 1/2] RISC-V: Accept version, supervisor ext and more than one NSE for -march.

[Kito Cheng]

From: Kito Cheng 

Kito Cheng  
Monk Chiang  

ChangeLog:
gcc:
* common/config/riscv/riscv-common.c:
Include config/riscv/riscv-protos.h.
(INCLUDE_STRING): Defined.
(RISCV_DONT_CARE_VERSION): Defined.
(riscv_subset_t): Declare.
(riscv_subset_t::riscv_subset_t): New.
(riscv_subset_list): Declare.
(riscv_subset_list::riscv_subset_list): New.
(riscv_subset_list::~riscv_subset_list): Likewise.
(riscv_subset_list::parsing_subset_version): Likewise.
(riscv_subset_list::parse_std_ext): Likewise.
(riscv_subset_list::parse_sv_or_non_std_ext): Likewise.
(riscv_subset_list::add): Likewise.
(riscv_subset_list::lookup): Likewise.
(riscv_subset_list::xlen): Likewise.
(riscv_subset_list::parse): Likewise.
(riscv_supported_std_ext): Likewise.
(current_subset_list): Likewise.
(riscv_parse_arch_string): Using riscv_subset_list::parse to
parse.

gcc/testsuite:
* gcc.target/riscv/arch-1.c: New.
* gcc.target/riscv/arch-2.c: Likewise.
* gcc.target/riscv/arch-3.c: Likewise.
* gcc.target/riscv/arch-4.c: Likewise.
---
 gcc/common/config/riscv/riscv-common.c  | 525 
 gcc/testsuite/gcc.target/riscv/arch-1.c |   6 +
 gcc/testsuite/gcc.target/riscv/arch-2.c |   5 +
 gcc/testsuite/gcc.target/riscv/arch-3.c |   5 +
 gcc/testsuite/gcc.target/riscv/arch-4.c |   5 +
 5 files changed, 488 insertions(+), 58 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-4.c

diff --git a/gcc/common/config/riscv/riscv-common.c 
b/gcc/common/config/riscv/riscv-common.c
index cb5bb7f..3423df9 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -17,6 +17,7 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
+#define INCLUDE_STRING
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -26,99 +27,507 @@ along with GCC; see the file COPYING3.  If not see
 #include "opts.h"
 #include "flags.h"
 #include "diagnostic-core.h"
+#include "config/riscv/riscv-protos.h"
 
-/* Parse a RISC-V ISA string into an option mask.  Must clear or set all arch
-   dependent mask bits, in case more than one -march string is passed.  */
+#define RISCV_DONT_CARE_VERSION -1
 
-static void
-riscv_parse_arch_string (const char *isa, int *flags, location_t loc)
+/* Subset info.  */
+struct riscv_subset_t
 {
-  const char *p = isa;
+  riscv_subset_t ();
 
-  if (strncmp (p, "rv32", 4) == 0)
-*flags &= ~MASK_64BIT, p += 4;
-  else if (strncmp (p, "rv64", 4) == 0)
-*flags |= MASK_64BIT, p += 4;
-  else
+  std::string name;
+  int major_version;
+  int minor_version;
+  struct riscv_subset_t *next;
+};
+
+/* Subset list.  */
+class riscv_subset_list
+{
+private:
+  /* Original arch string.  */
+  const char *m_arch;
+
+  /* Location of arch string, used for report error.  */
+  location_t m_loc;
+
+  /* Head of subset info list.  */
+  riscv_subset_t *m_head;
+
+  /* Tail of subset info list.  */
+  riscv_subset_t *m_tail;
+
+  /* X-len of m_arch. */
+  unsigned m_xlen;
+
+  riscv_subset_list (const char *, location_t);
+
+  const char *parsing_subset_version (const char *, unsigned *, unsigned *,
+ unsigned, unsigned, bool);
+
+  const char *parse_std_ext (const char *);
+
+  const char *parse_sv_or_non_std_ext (const char *, const char *,
+  const char *);
+
+public:
+  ~riscv_subset_list ();
+
+  void add (const char *, int, int);
+
+  riscv_subset_t *lookup (const char *,
+ int major_version = RISCV_DONT_CARE_VERSION,
+ int minor_version = RISCV_DONT_CARE_VERSION) const;
+
+  unsigned xlen() const {return m_xlen;};
+
+  static riscv_subset_list *parse (const char *, location_t);
+
+};
+
+static const char *riscv_supported_std_ext (void);
+
+static riscv_subset_list *current_subset_list = NULL;
+
+riscv_subset_t::riscv_subset_t ()
+  : name (), major_version (0), minor_version (0), next (NULL)
+{
+}
+
+riscv_subset_list::riscv_subset_list (const char *arch, location_t loc)
+  : m_arch (arch), m_loc (loc), m_head (NULL), m_tail (NULL), m_xlen (0)
+{
+}
+
+riscv_subset_list::~riscv_subset_list ()
+{
+  if (!m_head)
+return;
+
+  riscv_subset_t *item = this->m_head;
+  while (item != NULL)
 {
-  error_at (loc, "-march=%s: ISA string must begin with rv32 or rv64", 
isa);
-  return;
+  riscv_subset_t *next = item->next;
+  delete item;
+  item = next;
 }
+}
 
-  if (*p == 'g')
-{
-  p++;
+/* Add new subset to list.  */
 
-  *flags &= 

[PATCH v2 0/2] RISC-V: Support ELF attribute for GCC

[Kito Cheng]

This version 2 of patch series for of RISC-V ELF attribute[1], first version 
can be found in[2-4].
Most changes between last version is typo fixing and coding sytle fix, and a 
missing re-generated
configure file.

[1] https://github.com/riscv/riscv-elf-psabi-doc/pull/71
[2] [PATCH 0/2] RISC-V: Support ELF attribute for GCC. 
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00928.html
[3] [PATCH 1/2] RISC-V: Accept version, supervisor ext and more than one NSE 
for -march. https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00929.html
[4] [PATCH 2/2] RISC-V: Support ELF attribute 
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00930.html
[5] 
https://github.com/riscv/riscv-isa-manual/blob/master/release/riscv-spec-v2.2.pdf

[PATCH v2 2/2] RISC-V: Support ELF attribute

[Kito Cheng]

From: Kito Cheng 

This patch added a configure time option, 
--with-riscv-attribute=[yes|no|default],
run time option, -mriscv-attribute to control the output of ELF attribute.

This feature is only enabled by default for ELF/Bare mental target
configuration.

Kito Cheng  
Monk Chiang  

ChangeLog:
gcc:
* common/config/riscv/riscv-common.c: Include sstream.
(riscv_subset_list::to_string): New.
(riscv_arch_str): Likewise.
* config.gcc (riscv*-*-*): Hanlde --with-riscv-attribute=
* config.in: Regen.
* config/riscv/riscv-protos.h (riscv_arch_str): New.
* config/riscv/riscv.c (INCLUDE_STRING): Defined.
(riscv_emit_attribute): New.
(riscv_file_start): Emit attribute if needed.
(riscv_option_override): Init riscv_emit_attribute_p.
* config/riscv/riscv.opt (mriscv-attribute): New option.
* configure.ac (riscv*-*-*): Check binutils is supporting ELF
* configure: Regen.
* doc/install.texi: Document --with-riscv-attribute.
* doc/invoke.texi: Document -mriscv-attribute.

gcc/testsuite:

* gcc.target/riscv/attribute-1.c: New.
* gcc.target/riscv/attribute-2.c: Likewise.
* gcc.target/riscv/attribute-3.c: Likewise.
* gcc.target/riscv/attribute-4.c: Likewise.
* gcc.target/riscv/attribute-5.c: Likewise.
* gcc.target/riscv/attribute-6.c: Likewise.
* gcc.target/riscv/attribute-7.c: Likewise.
* gcc.target/riscv/attribute-8.c: Likewise.
* gcc.target/riscv/attribute-9.c: Likewise.
---
 gcc/common/config/riscv/riscv-common.c   | 40 
 gcc/config.gcc   | 26 +-
 gcc/config.in|  6 +
 gcc/config/riscv/riscv-protos.h  |  3 +++
 gcc/config/riscv/riscv.c | 29 
 gcc/config/riscv/riscv.opt   |  4 +++
 gcc/configure| 37 +
 gcc/configure.ac |  7 +
 gcc/doc/install.texi |  7 +
 gcc/doc/invoke.texi  |  7 -
 gcc/testsuite/gcc.target/riscv/attribute-1.c |  6 +
 gcc/testsuite/gcc.target/riscv/attribute-2.c |  6 +
 gcc/testsuite/gcc.target/riscv/attribute-3.c |  6 +
 gcc/testsuite/gcc.target/riscv/attribute-4.c |  6 +
 gcc/testsuite/gcc.target/riscv/attribute-5.c |  6 +
 gcc/testsuite/gcc.target/riscv/attribute-6.c |  6 +
 gcc/testsuite/gcc.target/riscv/attribute-7.c |  6 +
 gcc/testsuite/gcc.target/riscv/attribute-8.c |  6 +
 gcc/testsuite/gcc.target/riscv/attribute-9.c |  6 +
 19 files changed, 218 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-8.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-9.c

diff --git a/gcc/common/config/riscv/riscv-common.c 
b/gcc/common/config/riscv/riscv-common.c
index 3423df9..02aee18 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -17,6 +17,8 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
+#include 
+
 #define INCLUDE_STRING
 #include "config.h"
 #include "system.h"
@@ -80,6 +82,8 @@ public:
  int major_version = RISCV_DONT_CARE_VERSION,
  int minor_version = RISCV_DONT_CARE_VERSION) const;
 
+  std::string to_string () const;
+
   unsigned xlen() const {return m_xlen;};
 
   static riscv_subset_list *parse (const char *, location_t);
@@ -136,6 +140,33 @@ riscv_subset_list::add (const char *subset, int 
major_version,
   m_tail = s;
 }
 
+/* Convert subset info to string with explicit version info.  */
+
+std::string
+riscv_subset_list::to_string () const
+{
+  std::ostringstream oss;
+  oss << "rv" << m_xlen;
+
+  bool first = true;
+  riscv_subset_t *subset = m_head;
+
+  while (subset != NULL)
+{
+  if (!first)
+   oss << '_';
+  first = false;
+
+  oss << subset->name
+ << subset->major_version
+ << 'p'
+ << subset->minor_version;
+  subset = subset->next;
+}
+
+  return oss.str ();
+}
+
 /* Find subset in list with version checking, return NULL if not found.
major/minor version checking can be ignored if major_version/minor_version
is RISCV_DONT_CARE_VERSION.  */
@@ -489,6 +520,15 @@ fail:
   

Go patch committed: Checkfor recursive inhereited interface aliases

[Ian Lance Taylor]

This patch by Ben Shi fixes the Go frontend to check for recursive
inherited interface aliases.  This avoids a compiler crash as
described at https://golang.org/issue/25302.  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 269240)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-9c1859b8e97242b0e697a3aaa39a4da5e6172e74
+2c74b84184941ebea318f69fe43a81f657790b63
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 269196)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -10329,6 +10329,23 @@ Find_alias::type(Type* type)
return TRAVERSE_SKIP_COMPONENTS;
 }
 
+  // Check if there are recursive inherited interface aliases.
+  Interface_type* ift = type->interface_type();
+  if (ift != NULL)
+{
+  const Typed_identifier_list* methods = ift->local_methods();
+  if (methods == NULL)
+   return TRAVERSE_CONTINUE;
+  for (Typed_identifier_list::const_iterator p = methods->begin();
+  p != methods->end();
+  ++p)
+   if (p->name().empty() && p->type()->named_type() == this->find_type_)
+ {
+   this->found_ = true;
+   return TRAVERSE_EXIT;
+ }
+}
+
   return TRAVERSE_CONTINUE;
 }
 

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

[Martin Sebor]

Please disregard the original patch and consider the attached
version instead.

On 2/26/19 5:03 PM, Martin Sebor wrote:

The false positive in PR89350 is due to -Wstringop-overflow
trusting that the sizetype offset in POINTER_PLUS_EXPR means
the offset is, in fact, unsigned.  Avoiding the false positive
in the cases when this isn't so is trivial but comes at a cost
of false negatives.  Avoiding those will, I expect, require
enhancing the compute_builtin_object_size() function and that
seems risky at this stage so I would like to defer that until
stage 1.  Except in the instance of memset, the false positives
also aren't too serious because the same problem is also
diagnosed by the -Warray-bounds warning in the wrestrict pass.
Unfortunately, the wrestrict pass only handles copy functions
and not memset.

With that as background, the attached patch avoids
the -Wstringop-overflow false positive by disabling the warning
for offsets whose lower bound is positive and upper bound negative.
To avoid the false negatives for memset the patch lets the wrestrict
pass handle the function (for the bounds checking only).  While
testing this I noticed that the wrestrict pass makes the same
assumption about offsets, so it too is susceptible to similar
false positives.  The rest of the patch corrects this problem
n the wrestrict pass.  Because the pass doesn't depend on
the compute_builtin_object_size() function as much as
-Wstringop-overflow, the fix does not cause false positives (at
least none that I came across).

Tested on x86_64-linux.

Martin


PR tree-optimization/89350 - Wrong -Wstringop-overflow= warning since r261518

gcc/ChangeLog:

	PR tree-optimization/89350
	* builtins.c (compute_objsize): Also ignore offsets whose upper
	bound is negative.
	* gimple-ssa-warn-restrict.c (builtin_memref): Add new member.
	(builtin_memref::builtin_memref): Initialize new member.
	Allow EXPR to be null.
	(builtin_memref::extend_offset_range): Replace local with a member.
	Avoid assuming pointer offsets are unsigned.
	(builtin_memref::set_base_and_offset): Determine base object
	before computing offset range.
	(builtin_access::builtin_access): Handle memset.
	(builtin_access::generic_overlap): Replace local with a member.
	(builtin_access::strcat_overlap): Same.
	(builtin_access::overlap): Same.
	(maybe_diag_overlap): Same.
	(maybe_diag_access_bounds): Same.
	(wrestrict_dom_walker::check_call): Handle memset.
	(check_bounds_or_overlap): Same.

gcc/testsuite/ChangeLog:

	PR tree-optimization/89350
	* gcc.dg/Wstringop-overflow.c: Xfail overly ambitious tests.
	* gcc.dg/Wstringop-overflow-10.c: New test.
	* gcc.dg/Wstringop-overflow-11.c: New test.
	* gcc.dg/pr89350.c: New test.
	* gcc.dg/pr40340-1.c: Adjust expected warning.
	* gcc.dg/pr40340-2.c: Same.
	* gcc.dg/pr40340-4.c: Same.
	* gcc.dg/pr40340-5.c: Same.

Index: gcc/builtins.c
===
--- gcc/builtins.c	(revision 269190)
+++ gcc/builtins.c	(working copy)
@@ -3652,7 +3652,8 @@ compute_objsize (tree dest, int ostype)
 		  /* Ignore negative offsets for now.  For others,
 			 use the lower bound as the most optimistic
 			 estimate of the (remaining)size.  */
-		  if (wi::sign_mask (min))
+		  if (wi::sign_mask (min)
+			  || wi::sign_mask (max))
 			;
 		  else if (wi::ltu_p (min, wisiz))
 			return wide_int_to_tree (TREE_TYPE (size),
Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c	(revision 269190)
+++ gcc/gimple-ssa-warn-restrict.c	(working copy)
@@ -147,6 +147,9 @@ struct builtin_memref
   /* The size range of the access to this reference.  */
   offset_int sizrange[2];
 
+  /* Cached result of get_max_objsize().  */
+  const offset_int maxobjsize;
+
   /* True for "bounded" string functions like strncat, and strncpy
  and their variants that specify either an exact or upper bound
  on the size of the accesses they perform.  For strncat both
@@ -233,6 +236,7 @@ builtin_memref::builtin_memref (tree expr, tree si
   refoff (HOST_WIDE_INT_MIN),
   offrange (),
   sizrange (),
+  maxobjsize (tree_to_shwi (max_object_size ())),
   strbounded_p ()
 {
   /* Unfortunately, wide_int default ctor is a no-op so array members
@@ -240,7 +244,8 @@ builtin_memref::builtin_memref (tree expr, tree si
   offrange[0] = offrange[1] = 0;
   sizrange[0] = sizrange[1] = 0;
 
-  const offset_int maxobjsize = tree_to_shwi (max_object_size ());
+  if (!expr)
+return;
 
   /* Find the BASE object or pointer referenced by EXPR and set
  the offset range OFFRANGE in the process.  */
@@ -292,13 +297,13 @@ builtin_memref::builtin_memref (tree expr, tree si
 }
 }
 
-/* Ctor helper to set or extend OFFRANGE based on the OFFSET argument.  */
+/* Ctor helper to set or extend OFFRANGE based on the OFFSET argument.
+   Pointer offsets are represented as unsigned sizetype but must be
+   treated as signed.  */
 
 void
 

libgo patch committed: Preserve CC for TestScript child processes

[Ian Lance Taylor]

This libgo patch fixes the cmd/g TestScript test to preserve the CC
environment variable for TestScript child processes, so that tests
that use cgo will act as expected.  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 269216)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-558fcb7bf2a6b78bdba87f20a8a4a95d27125d74
+9c1859b8e97242b0e697a3aaa39a4da5e6172e74
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/cmd/go/script_test.go
===
--- libgo/go/cmd/go/script_test.go  (revision 269196)
+++ libgo/go/cmd/go/script_test.go  (working copy)
@@ -83,13 +83,12 @@ type backgroundCmd struct {
 }
 
 var extraEnvKeys = []string{
-   "SYSTEMROOT",  // must be preserved on Windows to find DLLs; 
golang.org/issue/25210
-   "LD_LIBRARY_PATH", // must be preserved on Unix systems to find shared 
libraries
-
-   // For gccgo testing.
-   "GO_TESTING_GOTOOLS",
-   "GCCGO",
-   "GCCGOTOOLDIR",
+   "SYSTEMROOT", // must be preserved on Windows to find DLLs; 
golang.org/issue/25210
+   "LD_LIBRARY_PATH",// must be preserved on Unix systems to find 
shared libraries
+   "CC", // don't lose user settings when invoking cgo
+   "GO_TESTING_GOTOOLS", // for gccgo testing
+   "GCCGO",  // for gccgo testing
+   "GCCGOTOOLDIR",   // for gccgo testing
 }
 
 // setup sets up the test execution temporary directory and environment.

Re: [PATCH] improve performance of std::allocator::deallocate

[Pádraig Brady]

On 02/26/2019 05:50 AM, Jonathan Wakely wrote:
> On 23/02/19 02:04 +, Pádraig Brady wrote:
>> Attached is a simple patch which has been extensively tested within
>> Facebook,
>> and is enabled by default in our code base.
>>
>> Passing the size to the allocator allows it to optimize deallocation,
>> and this was seen to significantly reduce the work required in jemalloc,
>> with about 40% reduction in CPU cycles in the free path.
>
> Thanks, the patch looks good.
>
> I would prefer to only change the function body, as otherwise LTO
> sometimes produces link-time warnings about ODR violations, because
> the same function is defined on two different lines. The ODR detection
> heuristics aren't smart enough to complain when the function
> declarator is always defined on the same line, but with two different
> function bodies.

We've not noticed issues here with LTO, though that could be
due to global enablement of -fsized-deallocation.
Anyway your suggestion is neater. Updated patch attached.
> Note jemalloc >= 5.1 is required to fix a bug with 0 sizes.
>
> How serious is the bug? What are the symptoms?
>
I've updated the commit summary to say it's a crash.
Arguably that's better than mem corruption.

> It looks like 5.1.0 is less than a year old, so older versions are
> presumably still in wide use.
>
> We could potentially workaround it by making
> new_allocator::allocate(0) call ::operator new(1) when
> __cpp_sized_deallocation is defined, and deallocate(p, 0) call
> ::operator delete(p, 1). Obviously I'd prefer not to do that, because
> the default operator new already has an equivalent check, and only
> programs linking to jemalloc require the workaround.
>
Right the jemalloc fix was released May 2018.
It would be great to avoid the extra workarounds.
Given this would be released about a year after the jemalloc fix was
released,
and that this would only manifest upon program rebuild,
I would be inclined to not add any workarounds.
For reference tcmalloc and glibc malloc were seen to work fine with this.

thanks!
Pádraig.
From 54b69ee9ac7a188fa938108b4eac46a66416d0ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Fri, 22 Feb 2019 17:21:57 -0800
Subject: [PATCH] std::allocator::deallocate support sized-deallocation

Pass the size to the allocator so that it may optimize deallocation.
This was seen to significantly reduce the work required in jemalloc,
with about 40% reduction in CPU cycles in the free path.
Note jemalloc >= 5.1 is required to fix a crash with 0 sizes.

* libstdc++-v3/include/ext/new_allocator.h (deallocate): Pass the size
to the deallocator with -fsized-deallocation.
---
 libstdc++-v3/include/ext/new_allocator.h | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/include/ext/new_allocator.h b/libstdc++-v3/include/ext/new_allocator.h
index e245391..f1ff7da 100644
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -116,16 +116,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // __p is not permitted to be a null pointer.
   void
-  deallocate(pointer __p, size_type)
+  deallocate(pointer __p, size_type __t)
   {
 #if __cpp_aligned_new
 	if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
 	  {
-	::operator delete(__p, std::align_val_t(alignof(_Tp)));
+	::operator delete(__p,
+# if __cpp_sized_deallocation
+			  __t * sizeof(_Tp),
+# endif
+			  std::align_val_t(alignof(_Tp)));
 	return;
 	  }
 #endif
-	::operator delete(__p);
+	::operator delete(__p
+#if __cpp_sized_deallocation
+			  , __t * sizeof(_Tp)
+#endif
+			 );
   }
 
   size_type
-- 
2.5.5

Re: [committed] [PR rtl-optimization/87761] Don't let trivially dead insns impede regcprop's work

[Segher Boessenkool]

On Tue, Feb 26, 2019 at 04:58:17PM -0700, Jeff Law wrote:
> On 2/26/19 4:19 PM, Segher Boessenkool wrote:
> > On Tue, Feb 26, 2019 at 10:07:54AM -0700, Jeff Law wrote:
> For gcc-10 we should:
> 
>   1. Avoid really stupid stuff in init-regs.
> 
>   2. Avoid really stupid stuff in the splitters.
> 
>   3. Make REE SUBREG-aware
> 
>   4. Seriously consider a RTL DCE pass after post-reload splitting
> 
> But none of those would actually fix this BZ :-)

Since we are talking about pie-in-the-sky stuff...  I'd like to run some
kind of mini-combine after every split pass (just on the new insns).  As
it is the (later) splitters often leave non-optimal code unless a lot of
work is put into those splitters.  We should not have as many late
splitters as we do, but for those we do need, it would be helpful if the
compiler could do simple combinations without having to hand-code them.

> > [ I don't see any problems with -O2 btw, only with -O1, so should we care
> > at all anyway? ]
> You can get this stuff at -O2 on other platforms.  It's far more common
> than I ever imagined.

Yeah, that's because the testcase uses -fno-split-wide-types.  The subreg
passes do great work :-)


Segher

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

[Martin Sebor]

The false positive in PR89350 is due to -Wstringop-overflow
trusting that the sizetype offset in POINTER_PLUS_EXPR means
the offset is, in fact, unsigned.  Avoiding the false positive
in the cases when this isn't so is trivial but comes at a cost
of false negatives.  Avoiding those will, I expect, require
enhancing the compute_builtin_object_size() function and that
seems risky at this stage so I would like to defer that until
stage 1.  Except in the instance of memset, the false positives
also aren't too serious because the same problem is also
diagnosed by the -Warray-bounds warning in the wrestrict pass.
Unfortunately, the wrestrict pass only handles copy functions
and not memset.

With that as background, the attached patch avoids
the -Wstringop-overflow false positive by disabling the warning
for offsets whose lower bound is positive and upper bound negative.
To avoid the false negatives for memset the patch lets the wrestrict
pass handle the function (for the bounds checking only).  While
testing this I noticed that the wrestrict pass makes the same
assumption about offsets, so it too is susceptible to similar
false positives.  The rest of the patch corrects this problem
n the wrestrict pass.  Because the pass doesn't depend on
the compute_builtin_object_size() function as much as
-Wstringop-overflow, the fix does not cause false positives (at
least none that I came across).

Tested on x86_64-linux.

Martin
PR tree-optimization/89350 - Wrong -Wstringop-overflow= warning since r261518

gcc/ChangeLog:

	PR tree-optimization/89350
	* builtins.c (compute_objsize): Also ignore offsets whose upper
	bound is negative.
	* gimple-ssa-warn-restrict.c (builtin_memref): Add new member.
	(builtin_memref::builtin_memref): Initialize new member.
	Allow EXPR to be null.
	(builtin_memref::extend_offset_range): Replace local with a member.
	Avoid assuming pointer offsets are unsigned.
	(builtin_memref::set_base_and_offset): Determine base object
	before computing offset range.
	(builtin_access::builtin_access): Handle memset.
	(builtin_access::generic_overlap): Replace local with a member.
	(builtin_access::strcat_overlap): Same.
	(builtin_access::overlap): Same.
	(maybe_diag_overlap): Same.
	(maybe_diag_access_bounds): Same.
	(wrestrict_dom_walker::check_call): Handle memset.
	(check_bounds_or_overlap): Same.

gcc/testsuite/ChangeLog:

	PR tree-optimization/89350
	* gcc.dg/Wstringop-overflow.c: Xfail overly ambitious tests.
	* gcc.dg/Wstringop-overflow-10.c: New test.
	* gcc.dg/Wstringop-overflow-11.c: New test.
	* gcc.dg/pr40340-1.c: Adjust expected warning.
	* gcc.dg/pr40340-2.c: Same.
	* gcc.dg/pr40340-4.c: Same.
	* gcc.dg/pr40340-5.c: Same.

Index: gcc/builtins.c
===
--- gcc/builtins.c	(revision 269190)
+++ gcc/builtins.c	(working copy)
@@ -3652,7 +3652,8 @@ compute_objsize (tree dest, int ostype)
 		  /* Ignore negative offsets for now.  For others,
 			 use the lower bound as the most optimistic
 			 estimate of the (remaining)size.  */
-		  if (wi::sign_mask (min))
+		  if (wi::sign_mask (min)
+			  || wi::sign_mask (max))
 			;
 		  else if (wi::ltu_p (min, wisiz))
 			return wide_int_to_tree (TREE_TYPE (size),
Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c	(revision 269190)
+++ gcc/gimple-ssa-warn-restrict.c	(working copy)
@@ -147,6 +147,9 @@ struct builtin_memref
   /* The size range of the access to this reference.  */
   offset_int sizrange[2];
 
+  /* Cached result of get_max_objsize().  */
+  const offset_int maxobjsize;
+
   /* True for "bounded" string functions like strncat, and strncpy
  and their variants that specify either an exact or upper bound
  on the size of the accesses they perform.  For strncat both
@@ -233,6 +236,7 @@ builtin_memref::builtin_memref (tree expr, tree si
   refoff (HOST_WIDE_INT_MIN),
   offrange (),
   sizrange (),
+  maxobjsize (tree_to_shwi (max_object_size ())),
   strbounded_p ()
 {
   /* Unfortunately, wide_int default ctor is a no-op so array members
@@ -240,7 +244,8 @@ builtin_memref::builtin_memref (tree expr, tree si
   offrange[0] = offrange[1] = 0;
   sizrange[0] = sizrange[1] = 0;
 
-  const offset_int maxobjsize = tree_to_shwi (max_object_size ());
+  if (!expr)
+return;
 
   /* Find the BASE object or pointer referenced by EXPR and set
  the offset range OFFRANGE in the process.  */
@@ -292,13 +297,13 @@ builtin_memref::builtin_memref (tree expr, tree si
 }
 }
 
-/* Ctor helper to set or extend OFFRANGE based on the OFFSET argument.  */
+/* Ctor helper to set or extend OFFRANGE based on the OFFSET argument.
+   Pointer offsets are represented as unsigned sizetype but must be
+   treated as signed.  */
 
 void
 builtin_memref::extend_offset_range (tree offset)
 {
-  const offset_int maxobjsize = tree_to_shwi (max_object_size ());
-
   if (TREE_CODE (offset) == 

Re: [PR fortran/89492, patch] - [9 Regression] Endless compilation of an invalid TRANSFER after r269177

[Segher Boessenkool]

Hi Harald,

On Tue, Feb 26, 2019 at 09:09:53PM +0100, Harald Anlauf wrote:
> @Dominique: I am unable to close PRs in bugzilla that I do not own
> due to insufficient privileges.

You need to log in to bugzilla as anl...@gcc.gnu.org, then everything
should work.


Segher

Re: [committed] [PR rtl-optimization/87761] Don't let trivially dead insns impede regcprop's work

[Jeff Law]

On 2/26/19 4:19 PM, Segher Boessenkool wrote:
> On Tue, Feb 26, 2019 at 10:07:54AM -0700, Jeff Law wrote:
>> As we enter regcprop we have the following horrific RTL:
 (insn 35 7 36 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
 (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
  (nil))
 (insn 36 35 10 2 (set (reg:DI 3 $3 [ x+8 ])
 (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
  (nil))
 (insn 10 36 11 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
 (reg:DI 4 $4 [206])) "j.c":8:49 313 {*movdi_64bit}
  (nil))
 (insn 11 10 37 2 (set (reg:DI 3 $3 [ x+8 ])
 (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
  (nil))
> 
> where 35+36 used to be a single set in TImode:
> insn_cost 4 for29: r200:TI=0
> insn_cost 4 for10: r200:TI#0=r197:DI
>   REG_DEAD r197:DI
> insn_cost 4 for11: r200:TI#8=0
> 
> I would hope combine could clean this up, and it tried, but
That was one of my early thoughts...  But

> 
> Trying 29, 10 -> 11:
>29: r200:TI=0
>10: r200:TI#0=r206:DI
>   REG_DEAD r206:DI
>11: r200:TI#8=0
> Can't combine i2 into i3
> 
> This is because i2 (that's insn 10) has a subreg on the LHS.
Right.  Already went down that rathole and several others :-)

> 
>> You'll note there's a fair amount of obviously dead code.  The dead code
>> really hampers regcprop's ability to propagate values.
> 
> And prevents all of the RTL optimisers before it from doing any useful
> work.  Ideally this should be fixed much earlier.  Not that your patch
> isn't pretty obviously correct :-)
For gcc-10 we should:

  1. Avoid really stupid stuff in init-regs.

  2. Avoid really stupid stuff in the splitters.

  3. Make REE SUBREG-aware

  4. Seriously consider a RTL DCE pass after post-reload splitting

But none of those would actually fix this BZ :-)

> 
> [ I don't see any problems with -O2 btw, only with -O1, so should we care
> at all anyway? ]
You can get this stuff at -O2 on other platforms.  It's far more common
than I ever imagined.

Jeff

ps.  THe patch isn't actually correct.  I committed the wrong version.
We should be looking at notrap_p on SRC, not INSN.  WHen you call it on
the insn, the EXPR_LIST for the notes is considered trapping.  Ugh.  I
didn't notice it until I started trying to clean up the 2nd patch and
was seeing dead code much later than I expected :(   I'll fix that goof
tomorrow.

Re: [committed] [PR rtl-optimization/87761] Don't let trivially dead insns impede regcprop's work

[Segher Boessenkool]

On Tue, Feb 26, 2019 at 10:07:54AM -0700, Jeff Law wrote:
> As we enter regcprop we have the following horrific RTL:
> >> (insn 35 7 36 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
> >> (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
> >>  (nil))
> >> (insn 36 35 10 2 (set (reg:DI 3 $3 [ x+8 ])
> >> (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
> >>  (nil))
> >> (insn 10 36 11 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
> >> (reg:DI 4 $4 [206])) "j.c":8:49 313 {*movdi_64bit}
> >>  (nil))
> >> (insn 11 10 37 2 (set (reg:DI 3 $3 [ x+8 ])
> >> (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
> >>  (nil))

where 35+36 used to be a single set in TImode:
insn_cost 4 for29: r200:TI=0
insn_cost 4 for10: r200:TI#0=r197:DI
  REG_DEAD r197:DI
insn_cost 4 for11: r200:TI#8=0

I would hope combine could clean this up, and it tried, but

Trying 29, 10 -> 11:
   29: r200:TI=0
   10: r200:TI#0=r206:DI
  REG_DEAD r206:DI
   11: r200:TI#8=0
Can't combine i2 into i3

This is because i2 (that's insn 10) has a subreg on the LHS.

> You'll note there's a fair amount of obviously dead code.  The dead code
> really hampers regcprop's ability to propagate values.

And prevents all of the RTL optimisers before it from doing any useful
work.  Ideally this should be fixed much earlier.  Not that your patch
isn't pretty obviously correct :-)

[ I don't see any problems with -O2 btw, only with -O1, so should we care
at all anyway? ]


Segher

[PATCH] PR libstdc++/89477 constrain deduction guides for maps and sets

[Jonathan Wakely]

The Compare, Hash, and Pred template parameters should be constrained in
the C++17 deduction guides for associative and unordered containers.

The deduction guides for stack, queue and priority_queue are already
constrained, but this patch makes them use the _RequireNotAllocator
helper instead of reproducing the logic each time.

PR libstdc++/89477
* include/bits/alloc_traits.h (_RequireNotAllocator): New helper for
container deduction guides.
* include/bits/hashtable.h (_RequireNotAllocatorOrIntegral): Likewise.
* include/bits/stl_map.h (map): Use _RequireNotAllocator to constrain
parameters in deduction guides.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_queue.h (queue, priority_queue): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_stack.h (stack): Likewise.
* include/bits/unordered_map.h (unordered_map, unordered_multimap):
use _RequireNotAllocator and _RequireNotAllocatorOrIntegral to
constrain parameters in deduction guides.
* include/bits/unordered_set.h (unordered_set, unordered_multiset):
Likewise.
* testsuite/23_containers/map/cons/deduction.cc: Test additional
deduction cases.
* testsuite/23_containers/multiset/cons/deduction.cc: Likewise.
* testsuite/23_containers/set/cons/deduction.cc: Likewise.
* testsuite/23_containers/unordered_map/cons/deduction.cc: Likewise.
* testsuite/23_containers/unordered_multimap/cons/deduction.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/cons/deduction.cc:
Likewise.
* testsuite/23_containers/unordered_set/cons/deduction.cc: Likewise.

Tested powerpc64le-linux, committed to trunk.

commit 9adc43fde784ffd47a2dc875f4a4203d104f3bb3
Author: Jonathan Wakely 
Date:   Tue Feb 26 22:20:52 2019 +

PR libstdc++/89477 constrain deduction guides for maps and sets

The Compare, Hash, and Pred template parameters should be constrained in
the C++17 deduction guides for associative and unordered containers.

The deduction guides for stack, queue and priority_queue are already
constrained, but this patch makes them use the _RequireNotAllocator
helper instead of reproducing the logic each time.

PR libstdc++/89477
* include/bits/alloc_traits.h (_RequireNotAllocator): New helper for
container deduction guides.
* include/bits/hashtable.h (_RequireNotAllocatorOrIntegral): 
Likewise.
* include/bits/stl_map.h (map): Use _RequireNotAllocator to 
constrain
parameters in deduction guides.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_queue.h (queue, priority_queue): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_stack.h (stack): Likewise.
* include/bits/unordered_map.h (unordered_map, unordered_multimap):
use _RequireNotAllocator and _RequireNotAllocatorOrIntegral to
constrain parameters in deduction guides.
* include/bits/unordered_set.h (unordered_set, unordered_multiset):
Likewise.
* testsuite/23_containers/map/cons/deduction.cc: Test additional
deduction cases.
* testsuite/23_containers/multiset/cons/deduction.cc: Likewise.
* testsuite/23_containers/set/cons/deduction.cc: Likewise.
* testsuite/23_containers/unordered_map/cons/deduction.cc: Likewise.
* testsuite/23_containers/unordered_multimap/cons/deduction.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/cons/deduction.cc:
Likewise.
* testsuite/23_containers/unordered_set/cons/deduction.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h 
b/libstdc++-v3/include/bits/alloc_traits.h
index b8689daf74b..cda768bf391 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -634,6 +634,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 using _RequireAllocator
   = typename enable_if<__is_allocator<_Alloc>::value, _Alloc>::type;
 
+  template
+using _RequireNotAllocator
+  = typename enable_if::value, _Alloc>::type;
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 #endif // C++11
diff --git a/libstdc++-v3/include/bits/hashtable.h 
b/libstdc++-v3/include/bits/hashtable.h
index 31794fb12c2..4737247994a 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -2214,6 +2214,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template class _Hash_merge_helper { };
 #endif // C++17
 
+#if __cpp_deduction_guides >= 201606
+  // Used to constrain deduction guides
+  

C++ PATCH for c++/89511 - ICE with using-declarations and unscoped enumerator

[Marek Polacek]

Here we ICE because the unscoped enum's context is a FUNCTION_DECL, which
push_using_decl can't handle.

http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742
says this is well-formed (but the scoped enum case is ill-formed).
Nevertheless, the DR hasn't been resolved either way yet, and trying
to accept a FUNCTION_DECL as a USING_DECL_SCOPE seems like a lot of
work, and ultimately maybe both cases will be deemed ill-formed.

This patch fixes the ICE by giving the pre-r211479 error while
simultaneously keeping using-enum-[12].C working.

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

2019-02-26  Marek Polacek  

PR c++/89511 - ICE with using-declarations and unscoped enumerator.
* parser.c (cp_parser_using_declaration): For an unscoped enum
only use its context if it's a namespace declaration.

* g++.dg/cpp0x/using-enum-3.C: New test.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index e976008e94d..361dc9d065e 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -19412,7 +19412,8 @@ cp_parser_using_declaration (cp_parser* parser,
  /*is_declaration=*/true);
   if (!qscope)
 qscope = global_namespace;
-  else if (UNSCOPED_ENUM_P (qscope))
+  else if (UNSCOPED_ENUM_P (qscope)
+  && TREE_CODE (CP_TYPE_CONTEXT (qscope)) == NAMESPACE_DECL)
 qscope = CP_TYPE_CONTEXT (qscope);
 
   if (access_declaration_p && cp_parser_error_occurred (parser))
diff --git gcc/testsuite/g++.dg/cpp0x/using-enum-3.C 
gcc/testsuite/g++.dg/cpp0x/using-enum-3.C
new file mode 100644
index 000..1fb4f95304c
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/using-enum-3.C
@@ -0,0 +1,8 @@
+// PR c++/89511
+// { dg-do compile { target c++11 } }
+
+void f ()
+{
+  enum e { a };
+  using e::a; // { dg-error "not a namespace or unscoped enum" }
+}

Re: [PATCH] Fix array size verification (PR c++/89507)

[Jason Merrill]

On 2/26/19 3:44 PM, Jakub Jelinek wrote:

Hi!

Seems valid_constant_size_p has been written with the expectation that only
sizetype/ssizetype constants will be passed to it, otherwise it couldn't
ever just blindly test tree_int_cst_sign_bit (size) for unsigned
INTEGER_CSTs and complain cst_size_too_big.
Unfortunately a recent patch started using this function even on other
types, and the comment explicitly talk about it being done on
pre-conversion to sizetype:
   /* The expression in a noptr-new-declarator is erroneous if it's of
  non-class type and its value before converting to std::size_t is
  less than zero. ... If the expression is a constant expression,
  the program is ill-fomed.  */
   if (TREE_CODE (cst_nelts) == INTEGER_CST
   && !valid_array_size_p (input_location, cst_nelts, NULL_TREE,
   complain & tf_error))
 return error_mark_node;
E.g. __int128 negative value could fit just fine after cast to sizetype,
etc.

So, instead of changing the C++ FE to only complain about negative cst_elts
normally and fold_convert everything to sizetype before checking, this patch
attempts to deal with non-{,s}sizetype constants.  Negative (signed)
constants are always rejected as before, newly constants that don't fit into
uhwi are rejected after that check regardless of signedness and anything
larger or equal than SIZE_MAX / 2 is also rejected as too big.

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

2019-02-26  Jakub Jelinek  

PR c++/89507
* tree.c (valid_constant_size_p): Deal with size INTEGER_CSTs
with types other than sizetype/ssizetype.


Looks good to me.

Jason

Re: [C++ Patch] PR 89488 ("[9 Regression] ICE in merge_exception_specifiers, at cp/typeck2.c:2395")

[Jason Merrill]

On 2/26/19 11:02 AM, Paolo Carlini wrote:

Hi,

On 26/02/19 15:28, Jason Merrill wrote:

On 2/25/19 10:27 AM, Paolo Carlini wrote:

Hi,

this error recovery regression has to do with the recent changes 
committed by Jason for c++/88368. What happens is that 
maybe_instantiate_noexcept fails the hard way, thus, toward the end 
of the function, doesn't update TREE_TYPE (fn) and just returns 
false. process_subob_fn doesn't notice and proceeds to call 
merge_exception_specifiers anyway where of course the gcc_assert 
(!DEFERRED_NOEXCEPT_SPEC_P (add)) triggers, because 
maybe_instantiate_noexcept has not done its normal job. To improve 
error-recovery I think we can simply leave *spec_p alone in such 
cases, because we would merge the *spec_p with a 
TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn)) where TREE_TYPE (fn) has not 
been normally computed. I tried a few other things which prima facie 
looked sensible but nothing else worked - eg, returning false from 
maybe_instantiate_noexcept and also updating TREE_TYPE (fn) to a 
noexcept_false_spec variant causes regressions exactly for the 
testcases of c++/88368.


If maybe_instantiate_noexcept returns false, I think we should set 
*spec_p to error_mark_node.


Sure, that certainly works, I tested it a couple of days ago and I'm 
finishing testing the below now. The only difference is that during 
error-recovery 'zl ()' is seen as seriously broken and we don't give the 
second,  "cannot convert", error message, which we used to give.


OK if it passes.

Jason

Re: [C++ Patch/RFC] PR 88987 ("[9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr")

[Jason Merrill]

On 2/26/19 10:22 AM, Paolo Carlini wrote:

Hi,

On 26/02/19 15:33, Jason Merrill wrote:

On 2/26/19 5:42 AM, Paolo Carlini wrote:

Hi,

the issue is rather easy to explain: after Alexandre' change  in 
r266874, which simplified the condition at the beginning of 
build_noexcept_spec to evaluate early all the expressions which 
aren't deferred or value-dependent, we obviously ICE during 
error-recovery on the new testcase because an expression which isn't 
a potential constant filters through and cxx_constant_value can't 
handle it.  We can avoid this in various ways - for example by adding 
a gate && potential_rvalue_constant_expression_p (expr) in the 
condition at the beginning of build_noexcept_spec and adjust/remove 
the final gcc_assert (which is already a bit obsolete wrt Alexandre' 
change). Or we can handle this earlier, in 
cp_parser_noexcept_specification_opt - in complete analogy, with, 
say, cp_parser_initializer_list - thus don't let through those 
expressions at all (possible variant: set expr = error_mark_node), 
which has the advantage of avoiding a duplicate 
potential_rvalue_constant_expression call (note: in the parser 
build_no_except_spec is called only by 
cp_parser_noexcept_specification_opt)


All those variants pass the testsuite on x86_64-linux.

What happens if 'sm' is constexpr?


Well, if 'sm' is constexpr we accept the snippet, as we should, AFAICS. 
This is true for all my tentative patches, I think, certainly for what I 
posted.


Yes, we should.  Then the patch is OK.

Jason

[SPARC] Make --help=target -Q output the code model

[Eric Botcazou]

--help=target -Q currently outputs the memory model but not the code model, 
because the former is entirely handled by the option machinery while the 
latter is partially handled manually; this patch fixes this discrepancy.

Tested on SPARC/Solaris and SPARC64/Linux, applied on the mainline.


2019-02-26  Eric Botcazou  

* config/sparc/sparc-opts.h (enum processor_type): Rename to...
(enum sparc_processor_type): ...this.
(enum sparc_code_model_type): New enumeration type.
(enum sparc_memory_model_type): Tweak comments.
* config/sparc/sparc.opt (mcpu): Adjust to above renaming.
(mtune): Likewise.
(mcmodel): Use sparc_code_model enumeration and variable.
(sparc_code_model): New enumeration.
(mdebug): Add Undocumented marker.
* config/sparc/sparc.h (enum cmodel): Delete.
(sparc_cmodel): Likewise.
(TARGET_CM_MEDLOW): Adjust to above renaming.
(TARGET_CM_MEDMID): Likewise.
(TARGET_CM_MEDANY): Likewise.
(TARGET_CM_EMBMEDANY): Likewise.
* config/sparc/sparc.c (sparc_cmodel): Delete.
(sparc_option_override): Remove string/value mapping support for the
code model.  Move code and memory model support to after the handling
of target flags.  Do private machine setup last.
(sparc_emit_set_symbolic_const64): Use sparc_code_model.
(sparc_legitimize_reload_address): Likewise.
(sparc_output_mi_thunk): Likewise.
* config/sparc/sparc.md (cpu): Adjust comment to above renaming.

-- 
Eric BotcazouIndex: config/sparc/sparc-opts.h
===
--- config/sparc/sparc-opts.h	(revision 269211)
+++ config/sparc/sparc-opts.h	(working copy)
@@ -20,10 +20,10 @@ along with GCC; see the file COPYING3.
 #ifndef SPARC_OPTS_H
 #define SPARC_OPTS_H
 
-/* Processor type.
+/* SPARC processor type.
These must match the values for the cpu attribute in sparc.md and
the table in sparc_option_override.  */
-enum processor_type {
+enum sparc_processor_type {
   PROCESSOR_V7,
   PROCESSOR_CYPRESS,
   PROCESSOR_V8,
@@ -50,10 +50,19 @@ enum processor_type {
   PROCESSOR_NATIVE
 };
 
-/* Sparc system memory model.  See Appendix D in the Sparc V9 manual
-   for formal specification, and Appendix J for more discussion.  */
+/* SPARC-V9 code model type.  See sparc.h for the full description.  */
+enum sparc_code_model_type {
+  CM_32,	/* 32-bit address space.  */
+  CM_MEDLOW,	/* 32-bit address space.  */
+  CM_MEDMID,	/* 44-bit address space.  */
+  CM_MEDANY,	/* 64-bit address space.  */
+  CM_EMBMEDANY	/* 64-bit address space.  */
+};
+
+/* SPARC memory model type.  See Appendix D in the SPARC-V9 manual
+   for formal specification and Appendix J for more discussion.  */
 enum sparc_memory_model_type {
-  SMM_DEFAULT,	/* Uninitialized.  */
+  SMM_DEFAULT,	/* Processor default.  */
   SMM_RMO,	/* Relaxed Memory Order.  */
   SMM_PSO,	/* Partial Store Order.  */
   SMM_TSO,	/* Total Store Order.  */
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c	(revision 269211)
+++ config/sparc/sparc.c	(working copy)
@@ -724,11 +724,6 @@ static const struct attribute_spec sparc
 };
 #endif
 
-/* Option handling.  */
-
-/* Parsed value.  */
-enum cmodel sparc_cmodel;
-
 char sparc_hard_reg_printed[8];
 
 /* Initialize the GCC target structure.  */
@@ -1636,22 +1631,10 @@ dump_target_flags (const char *prefix, c
 static void
 sparc_option_override (void)
 {
-  static struct code_model {
-const char *const name;
-const enum cmodel value;
-  } const cmodels[] = {
-{ "32", CM_32 },
-{ "medlow", CM_MEDLOW },
-{ "medmid", CM_MEDMID },
-{ "medany", CM_MEDANY },
-{ "embmedany", CM_EMBMEDANY },
-{ NULL, (enum cmodel) 0 }
-  };
-  const struct code_model *cmodel;
   /* Map TARGET_CPU_DEFAULT to value for -m{cpu,tune}=.  */
   static struct cpu_default {
 const int cpu;
-const enum processor_type processor;
+const enum sparc_processor_type processor;
   } const cpu_default[] = {
 /* There must be one entry here for each TARGET_CPU value.  */
 { TARGET_CPU_sparc, PROCESSOR_CYPRESS },
@@ -1795,30 +1778,6 @@ sparc_option_override (void)
   target_flags |= MASK_LONG_DOUBLE_128;
 }
 
-  /* Code model selection.  */
-  sparc_cmodel = SPARC_DEFAULT_CMODEL;
-
-#ifdef SPARC_BI_ARCH
-  if (TARGET_ARCH32)
-sparc_cmodel = CM_32;
-#endif
-
-  if (sparc_cmodel_string != NULL)
-{
-  if (TARGET_ARCH64)
-	{
-	  for (cmodel = [0]; cmodel->name; cmodel++)
-	if (strcmp (sparc_cmodel_string, cmodel->name) == 0)
-	  break;
-	  if (cmodel->name == NULL)
-	error ("bad value (%s) for -mcmodel= switch", sparc_cmodel_string);
-	  else
-	sparc_cmodel = cmodel->value;
-	}
-  else
-	error ("-mcmodel= is not supported on 32-bit systems");
-}
-
   /* Check that -fcall-saved-REG wasn't specified for 

Re: [PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)

[Jakub Jelinek]

On Tue, Feb 26, 2019 at 05:18:17PM +0100, Jakub Jelinek wrote:
> > > Shall I modify the patch for that?
> > 
> > Might it even simplify the patch?  If not the only comment on the
> > original patch is that it would be nice to test it on a SJLJ EH
> > target ...
> 
>  1 file changed, 29 insertions(+), 16 deletions(-)
> so not really simplify it, but not terrible either.
> 
> Here is the incremental (untested) diff of what handles that.
> 
> I don't have access to any standard SJLJ EH targets, but will try
> --enable-sjlj-exceptions on x86_64-linux to see how far I get with that.

Full updated patch that passed normal bootstrap/regtest on x86_64-linux and
i686-linux.

--enable-sjlj-exceptions bootstrap on x86_64-linux failed miserably,
some entry-points are removed from libgcc_s.so in that case and
make: relocation error: /lib64/libgc.so.1: symbol __gcc_personality_v0 version 
GCC_3.3.1 not defined in file libgcc_s.so.1 with link time reference
On the other side, even without SJLJ EH, the testsuite coverage is quite
good, at least during development of the patch I made several mistakes and
each time there were dozens to hundreds of failing tests in the testsuite,
including __builtin_setjmp, non-local goto, etc.

That said, if anybody is able to test this on some SJLJ setup, it would be
greatly appreciated.

2019-02-26  Jakub Jelinek  

PR tree-optimization/89280
* tree-cfgcleanup.c (maybe_dead_abnormal_edge_p,
builtin_setjmp_setup_bb): New functions.
(cleanup_control_flow_pre): Ignore maybe_dead_abnormal_edge_p edges.
When visiting __builtin_setjmp_setup block, queue in special
setjmp_vec vector edges from .ABNORMAL_DISPATCHER to corresponding
__builtin_setjmp_receiver.  Remove .ABNORMAL_DISPATCHER basic blocks
from visited after the loop if they don't have any visited successor
blocks.

* gcc.c-torture/compile/pr89280.c: New test.
* gcc.dg/torture/pr57147-2.c: Don't expect a setjmp after noreturn
function.  Skip the test for -O0.

--- gcc/tree-cfgcleanup.c.jj2019-02-23 01:14:03.032266203 +0100
+++ gcc/tree-cfgcleanup.c   2019-02-23 01:40:03.589681687 +0100
@@ -723,6 +723,97 @@ cleanup_tree_cfg_bb (basic_block bb)
   return false;
 }
 
+/* Return true if E is an EDGE_ABNORMAL edge for returns_twice calls,
+   i.e. one going from .ABNORMAL_DISPATCHER to basic block which doesn't
+   start with a forced or nonlocal label.  Calls which return twice can return
+   the second time only if they are called normally the first time, so basic
+   blocks which can be only entered through these abnormal edges but not
+   normally are effectively unreachable as well.  Additionally ignore
+   __builtin_setjmp_receiver starting blocks, which have one FORCED_LABEL
+   and which are always only reachable through EDGE_ABNORMAL edge.  They are
+   handled in cleanup_control_flow_pre.  */
+
+static bool
+maybe_dead_abnormal_edge_p (edge e)
+{
+  if ((e->flags & (EDGE_ABNORMAL | EDGE_EH)) != EDGE_ABNORMAL)
+return false;
+
+  gimple_stmt_iterator gsi = gsi_start_nondebug_after_labels_bb (e->src);
+  gimple *g = gsi_stmt (gsi);
+  if (!g || !gimple_call_internal_p (g, IFN_ABNORMAL_DISPATCHER))
+return false;
+
+  tree target = NULL_TREE;
+  for (gsi = gsi_start_bb (e->dest); !gsi_end_p (gsi); gsi_next ())
+if (glabel *label_stmt = dyn_cast  (gsi_stmt (gsi)))
+  {
+   tree this_target = gimple_label_label (label_stmt);
+   if (DECL_NONLOCAL (this_target))
+ return false;
+   if (FORCED_LABEL (this_target))
+ {
+   if (target)
+ return false;
+   target = this_target;
+ }
+  }
+else
+  break;
+
+  if (target)
+{
+  /* If there was a single FORCED_LABEL, check for
+__builtin_setjmp_receiver with address of that label.  */
+  if (!gsi_end_p (gsi) && is_gimple_debug (gsi_stmt (gsi)))
+   gsi_next_nondebug ();
+  if (gsi_end_p (gsi))
+   return false;
+  if (!gimple_call_builtin_p (gsi_stmt (gsi), BUILT_IN_SETJMP_RECEIVER))
+   return false;
+
+  tree arg = gimple_call_arg (gsi_stmt (gsi), 0);
+  if (TREE_CODE (arg) != ADDR_EXPR || TREE_OPERAND (arg, 0) != target)
+   return false;
+}
+  return true;
+}
+
+/* If BB is a basic block ending with __builtin_setjmp_setup, return edge
+   from .ABNORMAL_DISPATCHER basic block to corresponding
+   __builtin_setjmp_receiver basic block, otherwise return NULL.  */
+static edge
+builtin_setjmp_setup_bb (basic_block bb)
+{
+  if (EDGE_COUNT (bb->succs) != 2
+  || ((EDGE_SUCC (bb, 0)->flags
+  & (EDGE_ABNORMAL | EDGE_EH)) != EDGE_ABNORMAL
+ && (EDGE_SUCC (bb, 1)->flags
+ & (EDGE_ABNORMAL | EDGE_EH)) != EDGE_ABNORMAL))
+return NULL;
+
+  gimple_stmt_iterator gsi = gsi_last_nondebug_bb (bb);
+  if (gsi_end_p (gsi)
+  || !gimple_call_builtin_p (gsi_stmt (gsi), BUILT_IN_SETJMP_SETUP))
+return NULL;
+
+  tree 

Re: [backtrace] Avoid segfault

[Gerald Pfeifer]

On Tue, 26 Feb 2019, Tom de Vries wrote:
>>> Specifically I am now seeing
>>>
>>>   gmake[4]: *** No rule to make target 'b3test_dwz_buildid', 
>>>   needed by 'b3test_dwz_buildid.log'.
> The only way of reproducing it was to deinstall dwz.
:
> Fixed in patch below, committed as trivial.

Great, thanks for the quick follow-up, Tom!  I did a couple of further 
tests and am happy to report that the testsuite of libbacktrace is now
completely "clean".

I'll keep my eyes open. ;-)

Gerald

[PATCH] Fix array size verification (PR c++/89507)

[Jakub Jelinek]

Hi!

Seems valid_constant_size_p has been written with the expectation that only
sizetype/ssizetype constants will be passed to it, otherwise it couldn't
ever just blindly test tree_int_cst_sign_bit (size) for unsigned
INTEGER_CSTs and complain cst_size_too_big.
Unfortunately a recent patch started using this function even on other
types, and the comment explicitly talk about it being done on
pre-conversion to sizetype:
  /* The expression in a noptr-new-declarator is erroneous if it's of
 non-class type and its value before converting to std::size_t is
 less than zero. ... If the expression is a constant expression,
 the program is ill-fomed.  */
  if (TREE_CODE (cst_nelts) == INTEGER_CST
  && !valid_array_size_p (input_location, cst_nelts, NULL_TREE,
  complain & tf_error))
return error_mark_node;
E.g. __int128 negative value could fit just fine after cast to sizetype,
etc.

So, instead of changing the C++ FE to only complain about negative cst_elts
normally and fold_convert everything to sizetype before checking, this patch
attempts to deal with non-{,s}sizetype constants.  Negative (signed)
constants are always rejected as before, newly constants that don't fit into
uhwi are rejected after that check regardless of signedness and anything
larger or equal than SIZE_MAX / 2 is also rejected as too big.

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

2019-02-26  Jakub Jelinek  

PR c++/89507
* tree.c (valid_constant_size_p): Deal with size INTEGER_CSTs
with types other than sizetype/ssizetype.

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

--- gcc/tree.c.jj   2019-02-18 20:48:35.745681423 +0100
+++ gcc/tree.c  2019-02-26 18:22:23.760753681 +0100
@@ -7533,19 +7533,16 @@ valid_constant_size_p (const_tree size,
   return false;
 }
 
-  tree type = TREE_TYPE (size);
-  if (TYPE_UNSIGNED (type))
+  if (tree_int_cst_sgn (size) < 0)
 {
-  if (!tree_fits_uhwi_p (size)
- || tree_int_cst_sign_bit (size))
-   {
- *perr = cst_size_too_big;
- return false;
-   }
+  *perr = cst_size_negative;
+  return false;
 }
-  else if (tree_int_cst_sign_bit (size))
+  if (!tree_fits_uhwi_p (size)
+  || (wi::to_widest (TYPE_MAX_VALUE (sizetype))
+ < wi::to_widest (size) * 2))
 {
-  *perr = cst_size_negative;
+  *perr = cst_size_too_big;
   return false;
 }
 
--- gcc/testsuite/g++.dg/other/new2.C.jj2019-02-26 18:24:23.792785651 
+0100
+++ gcc/testsuite/g++.dg/other/new2.C   2019-02-26 18:23:26.530724514 +0100
@@ -0,0 +1,5 @@
+// PR c++/89507
+// { dg-do compile }
+
+unsigned char const n = 128;
+int *p = new int[n];   // { dg-bogus "array exceeds maximum object size" }

Jakub

Re: [PATCH] libstdc++/89130 and libstdc++/89090 fixes for vector relocation

[Jonathan Wakely]

On 24/02/19 15:46 +, Jonathan Wakely wrote:

On 21/02/19 20:47 +, Jonathan Wakely wrote:

On 05/02/19 14:45 +, Jonathan Wakely wrote:

This fixes two PRs, one trivial (don't use C++17 features in C++11
mode) and one more serious (don't require MoveInsertable when we
should only need CopyInsertable).

It would be nice to rely on if-constexpr in C++11 mode, but it causes
clang warnings, complicates testcase bisection/reduction, and causes
users to file bogus bug reports. So let's just avoid it.

Tested powerpc64le-linux, committed to trunk.





commit 51908e56bd32b5f89bc909193c3da957de01c3e0
Author: Jonathan Wakely 
Date:   Tue Feb 5 11:50:18 2019 +

 PR libstdc++/89130 restore support for non-MoveConstructible types
 The changes to "relocate" std::vector elements can lead to new errors
 outside the immediate context, because moving the elements to new
 storage no longer makes use of the move-if-noexcept utilities. This
 means that types with deleted moves no longer degenerate to copies, but
 are just ill-formed. The errors happen while instantiating the
 noexcept-specifier for __relocate_object_a, when deciding whether to try
 to relocate.
 This patch introduces indirections to avoid the ill-formed
 instantiations of std::__relocate_object_a. In order to avoid using
 if-constexpr prior to C++17 this is done by tag dispatching. After this
 patch all uses of std::__relocate_a are guarded by checks that will
 support sensible code (i.e. code not using custom allocators that fool
 the new checks).
 PR libstdc++/89130
 * include/bits/alloc_traits.h (__is_copy_insertable_impl): Rename to
 __is_alloc_insertable_impl. Replace single type member with two
 members, one for each of copy and move insertable.
 (__is_move_insertable): New trait for internal use.
 * include/bits/stl_vector.h (vector::_S_nothrow_relocate(true_type))
 (vector::_S_nothrow_relocate(true_type)): New functions to
 conditionally check if __relocate_a can throw.
 (vector::_S_use_relocate()): Dispatch to _S_nothrow_relocate based
 on __is_move_insertable.
 (vector::_S_do_relocate): New overloaded functions to conditionally
 call __relocate_a.
 (vector::_S_relocate): New function that dispatches to _S_do_relocate
 based on _S_use_relocate.
 * include/bits/vector.tcc (vector::reserve, vector::_M_realloc_insert)
 (vector::_M_default_append): Call _S_relocate instead of __relocate_a.
 * testsuite/23_containers/vector/modifiers/push_back/89130.cc: New.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h 
b/libstdc++-v3/include/bits/alloc_traits.h
index ed61ce845f8..3b0c16fbf64 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -577,14 +577,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  }

template
-class __is_copy_insertable_impl
+class __is_alloc_insertable_impl
  {
-  typedef allocator_traits<_Alloc> _Traits;
+  using _Traits = allocator_traits<_Alloc>;
+  using value_type = typename _Traits::value_type;

-  template,
+  typename
   = decltype(_Traits::construct(std::declval<_Alloc&>(),
-std::declval<_Up*>(),
-std::declval()))>
+std::declval<_Tp*>(),
+std::declval<_Up>()))>
static true_type
_M_select(int);

@@ -593,13 +595,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_select(...);

  public:
-  typedef decltype(_M_select(0)) type;
+  using copy = decltype(_M_select(0));
+  using move = decltype(_M_select(0));


This caused another regression, fixed by the attached patch.


That patch doesn't work with Clang because I made the members
protected and forgot to make them public again (and GCC doesn't cre,
only Clang notices).


Aaaand another patch for Clang, because my test using Clang was flawed
and only tested std::allocator, which is handled by the partial
specialization. These problems are not found using G++ because of the
numerous bugs with access control in templates.

Tested powerpc64le-linux, committed to trunk.


commit f4f6e96aca78d6bfe90dab9b0fd7b94a9e31f241
Author: Jonathan Wakely 
Date:   Tue Feb 26 16:56:36 2019 +

PR libstdc++/89416 fix alloc insertable trait for clang (again)

PR libstdc++/89416
* include/bits/alloc_traits.h (__is_alloc_insertable_impl): Change
to class template and partial specialization using void_t.
(__is_copy_insertable, __is_move_insertable): Adjust base class.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h b/libstdc++-v3/include/bits/alloc_traits.h
index 9a3d816c42c..b8689daf74b 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -576,32 

Re: [PR fortran/89492, patch] - [9 Regression] Endless compilation of an invalid TRANSFER after r269177

[Harald Anlauf]

Committed as rev. 269227 after confirmation by Dominique:

https://gcc.gnu.org/ml/fortran/2019-02/msg00229.html

Thanks for the quick review.

Harald

@Dominique: I am unable to close PRs in bugzilla that I do not own
due to insufficient privileges.

On 02/25/19 22:49, Harald Anlauf wrote:
> Rev. 269177 uncovered a latent issue in TRANSFER when the MOLD argument
> had storage size 0, resulting in an infinite loop.  The attached patch
> rejects illegal cases and handles the case where storage size of both
> SOURCE and MOLD are 0.  It also verifies proper simplification for
> some cases, some of which were not always properly handled before.
> 
> Thanks to Dominique for the heads-up which I initially missed.
> 
> Regtested on x86_64-pc-linux-gnu; the testcase is based on the report
> and slightly extended.
> 
> OK for trunk?
> 
> Thanks, and sorry for any inconvenience caused,
> Harald
> 
> 2019-02-25  Harald Anlauf  
> 
>   PR fortran/89492
>   * check.c (gfc_calculate_transfer_sizes): Handle cases where
>   storage size of elements of MOLD is 0.
> 
> 2019-02-25  Harald Anlauf  
> 
>   PR fortran/89492
>   * gfortran.dg/pr89492.f90: New test.
> 

[WWW] update CXX-status

[Nathan Sidwell]

Gerald,
now modules and coroutines are slated to be in C++20, here's a doc patch 
for them, pointing at their respective wiki pages.


ok?

nathan
--
Nathan Sidwell
? stat.diff
Index: htdocs/projects/cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.81
diff -r1.81 cxx-status.html
306a307,318
> 
>Modules 
>   http://wg21.link/p1103r3;>P1103R3
>   No (Modules wiki) 
>
> 
> 
>Coroutines 
>   http://wg21.link/p0912r5;>P0912R5
>   No (Coroutines Wiki) 
>
> 

Re: [PATCH][stage 1] Fix bitmap registration of overheads.

[Richard Biener]

On February 26, 2019 6:50:13 PM GMT+01:00, "Martin Liška"  
wrote:
>On 2/26/19 4:02 PM, Richard Biener wrote:
>> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška  wrote:
>>>
>>> Hi.
>>>
>>> I've rewritten bitmap memory statistics which abused unsigned
>>> type via register_overhead (map, -((int)sizeof (bitmap_head))).
>>> I come up with a concept that each bitmap has assigned a unique ID
>>> which is used for stats tracking. It's caused by fact that e.g. DF
>is
>>> heavily reallocating bitmaps that then have a different address.
>>>
>>> Survives bootstrap with --enable-gather-detailed-mem-stats.
>>>
>>> Ready for next stage1?
>> 
>> +  /* Get bitmap descriptor UID casted to an unsigned integer
>pointer.  */
>> +  unsigned *get_descriptor ()
>> +  {
>> +return (unsigned *)(ptrdiff_t)alloc_descriptor;
>> +  }
>> 
>> this one is a bit ugly and together with
>
>I know it's not perfect.
>
>> 
>> template 
>> inline hashval_t
>> pointer_hash ::hash (const value_type )
>> {
>>   /* This is a really poor hash function, but it is what the current
>code uses,
>>  so I am reusing it to avoid an additional axis in testing.  */
>>   return (hashval_t) ((intptr_t)candidate >> 3);
>> 
>> will give quite some hash collisions.  So I guess you should shift
>> the descriptor << 3 at least (and then make it at most 29 bits in
>> size?).
>
>That's easily doable.
>
>> Not sure what to do about the descriptor wrapping btw.
>
>Question is whether we want to invest in our internal scaffolding more
>time?
>Or can we live with the ugly casting?

I guess we can live with it if we can avoid the hash collisions. 

Richard. 

>Martin
>
>> 
>> Richard.
>> 
>>> Thanks,
>>> Martin
>>>
>>> gcc/ChangeLog:
>>>
>>> 2019-02-26  Martin Liska  
>>>
>>> * bitmap.c (bitmap_register): Come up with
>>> alloc_descriptor_max_uid and assign it for
>>> a new bitmap.
>>> (register_overhead): Use get_descriptor as
>>> a descriptor.
>>> (release_overhead): New.
>>> (bitmap_elem_to_freelist): Call it.
>>> (bitmap_elt_clear_from): Likewise.
>>> (bitmap_obstack_free): Likewise.
>>> (bitmap_move): Sensitively release memory.
>>> * bitmap.h (struct GTY): Add alloc_descriptor.
>>> (bitmap_initialize): Initialize alloc_descriptor to zero.
>>> * tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
>>> ---
>>>  gcc/bitmap.c   | 39 ---
>>>  gcc/bitmap.h   | 17 ++---
>>>  gcc/tree-ssa-pre.c |  2 +-
>>>  3 files changed, 43 insertions(+), 15 deletions(-)
>>>
>>>

Re: [PATCH, fortran]: Do not cast charlen to index type in transfer_array_inner

[Steve Kargl]

On Tue, Feb 26, 2019 at 07:16:21PM +0100, Uros Bizjak wrote:
> Attached patch removes following warning:
> 
> libgfortran/io/transfer.c: In function ‘transfer_array_inner’:
> libgfortran/io/transfer.c:2499:35: warning: operand of ?: changes
> signedness from ‘long int’ to ‘size_t’ {aka ‘long unsigned int’} due
> to unsignedness of other operand [-Wsign-compare]
> 
> There is actually no need to cast "charlen" to (unsigned) index_type,
> as it is already declared as size_t:
> 
> typedef size_t gfc_charlen_type;
> 
> the same type as are "elem_len" and "size" variables.
> 
> 2019-02-26  Uroš Bizjak  
> 
> * io/transfer.c (transfer_array_inner): Do not
> cast charlen to index type.
> 
> Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> 
> OK for mainline?
> 

Yes.

-- 
Steve

[PATCH, fortran]: Do not cast charlen to index type in transfer_array_inner

[Uros Bizjak]

Attached patch removes following warning:

libgfortran/io/transfer.c: In function ‘transfer_array_inner’:
libgfortran/io/transfer.c:2499:35: warning: operand of ?: changes
signedness from ‘long int’ to ‘size_t’ {aka ‘long unsigned int’} due
to unsignedness of other operand [-Wsign-compare]

There is actually no need to cast "charlen" to (unsigned) index_type,
as it is already declared as size_t:

typedef size_t gfc_charlen_type;

the same type as are "elem_len" and "size" variables.

2019-02-26  Uroš Bizjak  

* io/transfer.c (transfer_array_inner): Do not
cast charlen to index type.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

OK for mainline?

Uros.
Index: io/transfer.c
===
--- io/transfer.c   (revision 269217)
+++ io/transfer.c   (working copy)
@@ -2496,7 +2496,7 @@ transfer_array_inner (st_parameter_dt *dtp, gfc_ar
 return;
 
   iotype = (bt) GFC_DESCRIPTOR_TYPE (desc);
-  size = iotype == BT_CHARACTER ? (index_type) charlen : GFC_DESCRIPTOR_SIZE 
(desc);
+  size = iotype == BT_CHARACTER ? charlen : GFC_DESCRIPTOR_SIZE (desc);
 
   rank = GFC_DESCRIPTOR_RANK (desc);
 

Re: [PATCH][stage 1] Fix bitmap registration of overheads.

[Martin Liška]

On 2/26/19 4:02 PM, Richard Biener wrote:
> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška  wrote:
>>
>> Hi.
>>
>> I've rewritten bitmap memory statistics which abused unsigned
>> type via register_overhead (map, -((int)sizeof (bitmap_head))).
>> I come up with a concept that each bitmap has assigned a unique ID
>> which is used for stats tracking. It's caused by fact that e.g. DF is
>> heavily reallocating bitmaps that then have a different address.
>>
>> Survives bootstrap with --enable-gather-detailed-mem-stats.
>>
>> Ready for next stage1?
> 
> +  /* Get bitmap descriptor UID casted to an unsigned integer pointer.  */
> +  unsigned *get_descriptor ()
> +  {
> +return (unsigned *)(ptrdiff_t)alloc_descriptor;
> +  }
> 
> this one is a bit ugly and together with

I know it's not perfect.

> 
> template 
> inline hashval_t
> pointer_hash ::hash (const value_type )
> {
>   /* This is a really poor hash function, but it is what the current code 
> uses,
>  so I am reusing it to avoid an additional axis in testing.  */
>   return (hashval_t) ((intptr_t)candidate >> 3);
> 
> will give quite some hash collisions.  So I guess you should shift
> the descriptor << 3 at least (and then make it at most 29 bits in
> size?).

That's easily doable.

> Not sure what to do about the descriptor wrapping btw.

Question is whether we want to invest in our internal scaffolding more time?
Or can we live with the ugly casting?

Martin

> 
> Richard.
> 
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2019-02-26  Martin Liska  
>>
>> * bitmap.c (bitmap_register): Come up with
>> alloc_descriptor_max_uid and assign it for
>> a new bitmap.
>> (register_overhead): Use get_descriptor as
>> a descriptor.
>> (release_overhead): New.
>> (bitmap_elem_to_freelist): Call it.
>> (bitmap_elt_clear_from): Likewise.
>> (bitmap_obstack_free): Likewise.
>> (bitmap_move): Sensitively release memory.
>> * bitmap.h (struct GTY): Add alloc_descriptor.
>> (bitmap_initialize): Initialize alloc_descriptor to zero.
>> * tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
>> ---
>>  gcc/bitmap.c   | 39 ---
>>  gcc/bitmap.h   | 17 ++---
>>  gcc/tree-ssa-pre.c |  2 +-
>>  3 files changed, 43 insertions(+), 15 deletions(-)
>>
>>

[PATCH, doc]: Fix some texinfo warnings

[Uros Bizjak]

2019-02-26  Uroš Bizjak  

* doc/extend.texi (__builtin_object_size):
Use @pxref instead of @xref inside parenthesis.
(__builtin_has_attribute): Add missing comma after @xref.
(__builtin_object_size): Ditto.
* doc/md.texi (cond_*{mode}): Use @samp instead of @var around op1[i].
* fortran/invoke.texi (-ffpe-trap): Use @var for every item
in the list.

Bootstrapped on x86-64-linux-gnu, committed to mainline SVN as obvious.

Uros.
Index: doc/extend.texi
===
--- doc/extend.texi (revision 269217)
+++ doc/extend.texi (working copy)
@@ -11775,7 +11775,7 @@
 @var{ptr} to the end of the object @var{ptr} pointer points to
 (if known at compile time).  To determine the sizes of dynamically allocated
 objects the function relies on the allocation functions called to obtain
-the storage to be declared with the @code{alloc_size} attribute (@xref{Common
+the storage to be declared with the @code{alloc_size} attribute (@pxref{Common
 Function Attributes}).  @code{__builtin_object_size} never evaluates
 its arguments for side effects.  If there are any side effects in them, it
 returns @code{(size_t) -1} for @var{type} 0 or 1 and @code{(size_t) 0}
@@ -12560,7 +12560,7 @@
 @var{attribute} argument is an attribute name optionally followed by
 a comma-separated list of arguments enclosed in parentheses.  Both forms
 of attribute names---with and without double leading and trailing
-underscores---are recognized.  @xref{Attribute Syntax} for details.
+underscores---are recognized.  @xref{Attribute Syntax}, for details.
 When no attribute arguments are specified for an attribute that expects
 one or more arguments the function returns @code{true} if
 @var{type-or-expression} has been declared with the attribute regardless
@@ -13163,7 +13163,8 @@
 @end deftypefn
 
 @deftypefn {Built-in Function}{size_t} __builtin_object_size (const void * 
@var{ptr}, int @var{type})
-Returns the size of an object pointed to by @var{ptr}.  @xref{Object Size 
Checking} for a detailed description of the function.
+Returns the size of an object pointed to by @var{ptr}.  @xref{Object Size
+Checking}, for a detailed description of the function.
 @end deftypefn
 
 @deftypefn {Built-in Function} double __builtin_huge_val (void)
Index: doc/md.texi
===
--- doc/md.texi (revision 269217)
+++ doc/md.texi (working copy)
@@ -6628,7 +6628,7 @@
 where, for example, @var{op} is @code{+} for @samp{cond_add@var{mode}}.
 
 When defined for floating-point modes, the contents of @samp{op3[i]}
-are not interpreted if @var{op1[i]} is false, just like they would not
+are not interpreted if @samp{op1[i]} is false, just like they would not
 be in a normal C @samp{?:} condition.
 
 Operands 0, 2, 3 and 4 all have mode @var{m}.  Operand 1 is a scalar
Index: fortran/invoke.texi
===
--- fortran/invoke.texi (revision 269217)
+++ fortran/invoke.texi (working copy)
@@ -1205,7 +1205,7 @@
 
 If the option is used more than once in the command line, the lists will
 be joined: '@code{ffpe-trap=}@var{list1} @code{ffpe-trap=}@var{list2}'
-is equivalent to @code{ffpe-trap=}@var{list1,list2}.
+is equivalent to @code{ffpe-trap=}@var{list1},@var{list2}.
 
 Note that once enabled an exception cannot be disabled (no negative form).
 

[committed] [PR rtl-optimization/87761] Don't let trivially dead insns impede regcprop's work

[Jeff Law]

This is the first of either 2 (possibly 3) patches to address the
fix-r4000-10 regression in BZ87761.

There's a bit of winding path to get to the code quality regression and
some things we can and should do for gcc-10 (smarter splitters, avoid
stupid code from init-regs).

Even if those issues earlier in the pipeline were fixed we actually
wouldn't get any code improvement for fix-r1000-10.  We actually need to
dig into regcprop.

As we enter regcprop we have the following horrific RTL:

>> (insn 33 5 6 2 (set (reg:DI 6 $6 [207])
>> (reg:DI 5 $5 [ y ])) "j.c":8:40 313 {*movdi_64bit}
>>  (nil))
>> (note 6 33 7 2 NOTE_INSN_DELETED)
>> (note 7 6 35 2 NOTE_INSN_FUNCTION_BEG)
>> (insn 35 7 36 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
>> (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
>>  (nil))
>> (insn 36 35 10 2 (set (reg:DI 3 $3 [ x+8 ])
>> (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
>>  (nil))
>> (insn 10 36 11 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
>> (reg:DI 4 $4 [206])) "j.c":8:49 313 {*movdi_64bit}
>>  (nil))
>> (insn 11 10 37 2 (set (reg:DI 3 $3 [ x+8 ])
>> (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
>>  (nil))
>> (insn 37 11 38 2 (set (reg:DI 4 $4 [orig:201 y ] [201])
>> (const_int 0 [0])) "j.c":8:63 313 {*movdi_64bit}
>>  (nil))
>> (insn 38 37 12 2 (set (reg:DI 5 $5 [ y+8 ])
>> (const_int 0 [0])) "j.c":8:63 313 {*movdi_64bit}
>>  (nil))
>> (insn 12 38 13 2 (set (reg:DI 4 $4 [orig:201 y ] [201])
>> (reg:DI 6 $6 [207])) "j.c":8:63 313 {*movdi_64bit}
>>  (nil))
>> (insn 13 12 17 2 (set (reg:DI 5 $5 [ y+8 ])
>> (const_int 0 [0])) "j.c":8:63 313 {*movdi_64bit}
>>  (nil))
>> (insn 17 13 26 2 (parallel [
>> (set (reg:TI 2 $2 [199])
>> (mult:TI (zero_extend:TI (reg:DI 2 $2 [orig:200 x ] [200]))
>> (zero_extend:TI (reg:DI 4 $4 [orig:201 y ] [201]
>> (clobber (reg:TI 64 lo [208]))
>> ]) "j.c":8:63 80 {umulditi3_r4000}
>>  (nil))


You'll note there's a fair amount of obviously dead code.  The dead code
really hampers regcprop's ability to propagate values.  Ultimately what
we want to be able to do is cprop reg4 and reg5 (incoming argument
registers) into insn 17.  The fact that we shuffle through reg4 and have
unused sets of reg4 and reg5 get in the way.

This patch addresses one particular subissue -- namely the sets of
unused registers.  insns 35, 36, 11, 37, 38 & 13.  By identifying &
removing them as regcprop processes the current block (triggering on
REG_UNUSED which will be set up by regcprop) we essentially present the
core of regcprop with:

>> (insn 33 5 6 2 (set (reg:DI 6 $6 [207])
>> (reg:DI 5 $5 [ y ])) "j.c":8:40 312 {*movdi_64bit}
>>  (nil))
>> 
>> (note 6 33 7 2 NOTE_INSN_DELETED)
>> 
>> (note 7 6 10 2 NOTE_INSN_FUNCTION_BEG)
>> 
>> (insn 10 7 12 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
>> (reg:DI 4 $4 [206])) "j.c":8:49 312 {*movdi_64bit}
>>  (nil))
>> 
>> (insn 12 10 17 2 (set (reg:DI 4 $4 [orig:201 y ] [201])
>> (reg:DI 6 $6 [207])) "j.c":8:63 312 {*movdi_64bit}
>>  (nil))
>> 
>> (insn 17 12 26 2 (parallel [
>> (set (reg:TI 2 $2 [199])
>> (mult:TI (zero_extend:TI (reg:DI 2 $2 [orig:200 x ] [200]))
>> (zero_extend:TI (reg:DI 4 $4 [orig:201 y ] [201]
>> (clobber (reg:TI 64 lo [208]))
>> ]) "j.c":8:63 80 {umulditi3_r4000}
>>  (nil))


regcprop will be able to cprop reg5 for the use of reg6 in insn 12 and
again for the use of reg4 in insn 17 resulting in something like this:

>> (insn 33 5 6 2 (set (reg:DI 6 $6 [207])
>> (reg:DI 5 $5 [ y ])) "j.c":8:40 312 {*movdi_64bit}
>>  (expr_list:REG_DEAD (reg:DI 5 $5 [ y ])
>> (nil)))
>> (note 6 33 7 2 NOTE_INSN_DELETED)
>> (note 7 6 10 2 NOTE_INSN_FUNCTION_BEG)
>> (insn 10 7 12 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
>> (reg:DI 4 $4 [206])) "j.c":8:49 312 {*movdi_64bit}
>>  (expr_list:REG_DEAD (reg:DI 4 $4 [206])
>> (nil)))
>> (insn 12 10 17 2 (set (reg:DI 4 $4 [orig:201 y ] [201])
>> (reg:DI 5 $5 [207])) "j.c":8:63 312 {*movdi_64bit}
>>  (expr_list:REG_DEAD (reg:DI 6 $6 [207])
>> (nil)))
>> (insn 17 12 26 2 (parallel [
>> (set (reg:TI 2 $2 [199])
>> (mult:TI (zero_extend:TI (reg:DI 2 $2 [orig:200 x ] [200]))
>> (zero_extend:TI (reg:DI 5 $5 [orig:201 y ] [201]
>> (clobber (reg:TI 64 lo [208]))
>> ]) "j.c":8:63 80 {umulditi3_r4000}
>>  (expr_list:REG_DEAD (reg:DI 4 $4 [orig:201 y ] [201])
>> (expr_list:REG_UNUSED (reg:TI 64 lo [208])
>> (nil

Which is halfway to our goal (we've cprop'd the incoming reg5 into insn
17).  DCE will later delete insns 33 and insn 12.


This triggers often on x86 and other targets as well.  I suspect most of
the time it's not enabling regcprop to do a better job, but 

Re: [EXT] Re: [Patch, Aarch64] Implement TARGET_GET_MULTILIB_ABI_NAME for aarch64 (for use in Fortran vector header file)

[Richard Sandiford]

Steve Ellcey  writes:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 91e79d3..b8125d5 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -18722,6 +18722,17 @@ aarch64_comp_type_attributes (const_tree type1, 
> const_tree type2)
>return 1;
>  }
>  
> +/* Implement TARGET_GET_MULTILIB_ABI_NAME */
> +
> +static const char *
> +aarch64_get_multilib_abi_name (void)
> +{
> +  if (TARGET_BIG_END)
> +return TARGET_ILP32 ? "aarch64_be_ilp32" : "aarch64_be";
> +  return TARGET_ILP32 ? "aarch64_ilp32" : "aarch64";
> +}
> +
> +

Nit: too many blank lines.

OK otherwise, thanks.

Richard

Re: [PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)

[Richard Biener]

On Tue, 26 Feb 2019, Jakub Jelinek wrote:

> On Tue, Feb 26, 2019 at 04:08:21PM +0100, Richard Biener wrote:
> > I think we can have multiple .ABNORMAL_DISPATCHERs - at least in theory
> > via inlining, though I see code in the inliner avoiding multiple ones
> > at least for nonlocal goto, not sure if that covers all cases.
> 
> Ok.
> 
> > > Shall I modify the patch for that?
> > 
> > Might it even simplify the patch?  If not the only comment on the
> > original patch is that it would be nice to test it on a SJLJ EH
> > target ...
> 
>  1 file changed, 29 insertions(+), 16 deletions(-)
> so not really simplify it, but not terrible either.
> 
> Here is the incremental (untested) diff of what handles that.
> 
> I don't have access to any standard SJLJ EH targets, but will try
> --enable-sjlj-exceptions on x86_64-linux to see how far I get with that.

Indeed not terrible.  Maybe Eric can help with testing on a SJLJ
target (though IIRC Ada uses its own EH scheme on such targets?)

Richard.

> --- gcc/tree-cfgcleanup.c.jj  2019-02-26 16:52:33.828719803 +0100
> +++ gcc/tree-cfgcleanup.c 2019-02-26 17:11:07.735576027 +0100
> @@ -731,12 +731,7 @@ cleanup_tree_cfg_bb (basic_block bb)
> normally are effectively unreachable as well.  Additionally ignore
> __builtin_setjmp_receiver starting blocks, which have one FORCED_LABEL
> and which are always only reachable through EDGE_ABNORMAL edge.  They are
> -   handled in cleanup_control_flow_pre.
> -   Similarly, return true for EDGE_ABNORMAL edge from any basic block to
> -   .ABNORMAL_DISPATCHER basic block if the latter block has no successors.
> -   .ABNORMAL_DISPATCHER basic blocks that don't dispatch to anything are 
> dead,
> -   don't really need any EDGE_ABNORMAL edges to them and can be safely
> -   removed.  */
> +   handled in cleanup_control_flow_pre.  */
>  
>  static bool
>  maybe_dead_abnormal_edge_p (edge e)
> @@ -747,16 +742,7 @@ maybe_dead_abnormal_edge_p (edge e)
>gimple_stmt_iterator gsi = gsi_start_nondebug_after_labels_bb (e->src);
>gimple *g = gsi_stmt (gsi);
>if (!g || !gimple_call_internal_p (g, IFN_ABNORMAL_DISPATCHER))
> -{
> -  if (EDGE_COUNT (e->dest->succs) == 0)
> - {
> -   gsi = gsi_start_nondebug_after_labels_bb (e->dest);
> -   g = gsi_stmt (gsi);
> -   if (g && gimple_call_internal_p (g, IFN_ABNORMAL_DISPATCHER))
> - return true;
> - }
> -  return false;
> -}
> +return false;
>  
>tree target = NULL_TREE;
>for (gsi = gsi_start_bb (e->dest); !gsi_end_p (gsi); gsi_next ())
> @@ -846,6 +832,7 @@ cleanup_control_flow_pre ()
>bitmap_clear (visited);
>  
>vec *setjmp_vec = NULL;
> +  auto_vec abnormal_dispatchers;
>  
>stack.quick_push (ei_start (ENTRY_BLOCK_PTR_FOR_FN (cfun)->succs));
>  
> @@ -877,6 +864,16 @@ cleanup_control_flow_pre ()
>   stack.quick_push (ei_start (setjmp_vec));
>   }
>  
> +   if ((ei_edge (ei)->flags
> +& (EDGE_ABNORMAL | EDGE_EH)) == EDGE_ABNORMAL)
> + {
> +   gimple_stmt_iterator gsi
> + = gsi_start_nondebug_after_labels_bb (dest);
> +   gimple *g = gsi_stmt (gsi);
> +   if (g && gimple_call_internal_p (g, IFN_ABNORMAL_DISPATCHER))
> + abnormal_dispatchers.safe_push (dest);
> + }
> +
> if (EDGE_COUNT (dest->succs) > 0)
>   stack.quick_push (ei_start (dest->succs));
>   }
> @@ -895,6 +892,22 @@ cleanup_control_flow_pre ()
>  
>vec_free (setjmp_vec);
>  
> +  /* If we've marked .ABNORMAL_DISPATCHER basic block(s) as visited
> + above, but haven't marked any of their successors as visited,
> + unmark them now, so that they can be removed as useless.  */
> +  basic_block dispatcher_bb;
> +  unsigned int k;
> +  FOR_EACH_VEC_ELT (abnormal_dispatchers, k, dispatcher_bb)
> +{
> +  edge e;
> +  edge_iterator ei;
> +  FOR_EACH_EDGE (e, ei, dispatcher_bb->succs)
> + if (bitmap_bit_p (visited, e->dest->index))
> +   break;
> +  if (e == NULL)
> + bitmap_clear_bit (visited, dispatcher_bb->index);
> +}
> +
>set_dom_info_availability (CDI_DOMINATORS, saved_state);
>  
>/* We are deleting BBs in non-reverse dominator order, make sure
> 
> 
>   Jakub
> 
> 

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

Re: [AArch64, SVE] Fix vectorized FP converts

[Richard Sandiford]

Alejandro Martinez Vicente  writes:
> Hi,
>
> Some of the narrowing/widening FP converts were missing from SVE. I fixed most
> of them, so they can be vectorized. The ones missing are int64->fp16 and
> fp16->int64.
>
> I extended the tests to cover the cases that were missing.
>
> I validated the patch with self-checking and running the new SVE tests on an
> SVE emulator.
>
> Alejandro

OK, thanks.

Think you've posted enough patches now to apply for svn write access.
Will follow up off-list.

Richard

Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64

[Steve Ellcey]

Ping.

Steve Ellcey
sell...@marvell.com


On Mon, 2019-02-11 at 10:46 -0800, Steve Ellcey wrote:
> On Thu, 2019-02-07 at 18:13 +, Wilco Dijkstra wrote
> > 
> > Hi Steve,
> > 
> > > > After special cases you could do something like t = mask2 +
> > > > (HWI_1U << shift);
> > > > return t == (t & -t) to check for a valid bfi.
> > > 
> > > I am not sure I follow this logic and my attempts to use this did
> > > not
> > > work so I kept my original code.
> > 
> > It's similar to the initial code in aarch64_bitmask_imm, but rather
> > than adding
> > the lowest bit to the value to verify it is a mask (val + (val &
> > -val)), we use the
> > shift instead. If the shift is exactly right, it reaches the first
> > set bit of the mask.
> > Adding the low bit to a valid mask always results in zero or a
> > single set bit.
> > The standard idiom to check that is t == (t & -t).
> > 
> > > > +  "bfi\t%0, %1, 0, %P2"
> > > > 
> > > > This could emit a width that may be 32 too large in SImode if
> > > > bit 31 is set
> > > > (there is another use of %P in aarch64.md which may have the
> > > > same
> > > > issue).
> > > 
> > > I am not sure why having bit 31 set would be a problem.  Sign
> > > extension?
> > 
> > Yes, if bit 31 is set, %P will emit 33 for a 32-bit constant which
> > is obviously wrong.
> > Your patch avoids this for bfi by explicitly computing the correct
> > value.
> > 
> > This looks good to me (and creates useful bfi's as expected), but I
> > can't approve.
> > 
> > Wilco
> 
> Thanks for looking this over.  I have updated the mask check to use
> your method and retested to make sure it still works.  Can one of the
> aarch64 maintainers approve this patch?
> 
> 2018-02-11  Steve Ellcey  
> 
>   PR rtl-optimization/87763
>   * config/aarch64/aarch64-protos.h
> (aarch64_masks_and_shift_for_bfi_p):
>   New prototype.
>   * config/aarch64/aarch64.c (aarch64_masks_and_shift_for_bfi_p):
>   New function.
>   * config/aarch64/aarch64.md (*aarch64_bfi5_shift):
>   New instruction.
>   (*aarch64_bfi4_noand): Ditto.
>   (*aarch64_bfi4_noshift): Ditto.
>   (*aarch64_bfi4_noshift_alt): Ditto.
> 
> 2018-02-11  Steve Ellcey  
> 
>   PR rtl-optimization/87763
>   * gcc.target/aarch64/combine_bfxil.c: Change some bfxil checks
>   to bfi.
>   * gcc.target/aarch64/combine_bfi_2.c: New test.
> 
> 

Re: [EXT] Re: [Patch, Aarch64] Implement TARGET_GET_MULTILIB_ABI_NAME for aarch64 (for use in Fortran vector header file)

[Steve Ellcey]

On Tue, 2019-02-26 at 10:17 +, Richard Sandiford wrote:
> 
> I'm torn about about whether we should proactively add the ILP32 and
> big-endian conditions now or wait until there's a specific need.
> Unless anyone strongly objects, let's keep them for now.
> 
> Thanks,
> Richard

OK, here is a new patch with the ILP32 and big-endian conditions still
in place but the sve stuff removed.  Retested on aarch64 with no
regressions.  OK for checkin?

Steve Ellcey
sell...@marvell.com



2018-02-26  Steve Ellcey  

* config/aarch64/aarch64.c (aarch64_get_multilib_abi_name):
New function.
(TARGET_GET_MULTILIB_ABI_NAME): New macro.


2018-02-26  Steve Ellcey  

* gfortran.dg/simd-builtins-1.f90: Update for aarch64*-*-*.
* gfortran.dg/simd-builtins-2.f90: Ditto.
* gfortran.dg/simd-builtins-6.f90: Ditto.
* gfortran.dg/simd-builtins-8.f90: New test.
* gfortran.dg/simd-builtins-8.h: New header file.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 91e79d3..b8125d5 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -18722,6 +18722,17 @@ aarch64_comp_type_attributes (const_tree type1, const_tree type2)
   return 1;
 }
 
+/* Implement TARGET_GET_MULTILIB_ABI_NAME */
+
+static const char *
+aarch64_get_multilib_abi_name (void)
+{
+  if (TARGET_BIG_END)
+return TARGET_ILP32 ? "aarch64_be_ilp32" : "aarch64_be";
+  return TARGET_ILP32 ? "aarch64_ilp32" : "aarch64";
+}
+
+
 /* Implement TARGET_STACK_PROTECT_GUARD. In case of a
global variable based guard use the default else
return a null tree.  */
@@ -19244,6 +19255,9 @@ aarch64_libgcc_floating_mode_supported_p
 #undef TARGET_COMP_TYPE_ATTRIBUTES
 #define TARGET_COMP_TYPE_ATTRIBUTES aarch64_comp_type_attributes
 
+#undef TARGET_GET_MULTILIB_ABI_NAME
+#define TARGET_GET_MULTILIB_ABI_NAME aarch64_get_multilib_abi_name
+
 #if CHECKING_P
 #undef TARGET_RUN_TARGET_SELFTESTS
 #define TARGET_RUN_TARGET_SELFTESTS selftest::aarch64_run_selftests
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90
index 6d79ef8..5cb3eb5 100644
--- a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90
+++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90
@@ -1,5 +1,6 @@
-! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } }
-! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" }
+! { dg-do compile { target i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } }
+! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" }
+! { dg-additional-options "-msse2 -mno-avx" { target i?86-*-linux* x86_64-*-linux* } }
 
 program test_overloaded_intrinsic
   real(4) :: x4(3200), y4(3200)
@@ -14,6 +15,7 @@ program test_overloaded_intrinsic
   print *, y8
 end
 
-! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */
-! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */
-! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } }
+! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } }
+! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } }
+! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" { target i?86-*-linux* x86_64-*-* } } }
+! { dg-final { scan-assembler "bl.*_ZGVnN4v_sinf" { target aarch64*-*-* } } }
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90
index f0e6bc1..2e5bc22 100644
--- a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90
+++ b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90
@@ -1,11 +1,12 @@
-! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } }
-! { dg-additional-options "-msse2 -nostdinc -Ofast -fdump-tree-optimized" }
+! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } }
+! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" }
+! { dg-additional-options "-msse2" { target i?86-*-linux* x86_64-*-linux* } }
 
 program test_overloaded_intrinsic
   real(4) :: x4(3200), y4(3200)
   real(8) :: x8(3200), y8(3200)
 
-  ! this should be using simd clone
+  ! this should not be using simd clone
   y4 = sin(x4)
   print *, y4
 
@@ -18,3 +19,4 @@ end
 ! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */
 ! { dg-final { scan-tree-dump-not "simdclone" "optimized" } } */
 ! { dg-final { scan-assembler-not "call.*_ZGVbN4v_sinf" } }
+! { dg-final { scan-assembler-not "bl.*_ZGVnN4v_sinf" } }
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90
index 2ffa807..60bcac7 100644
--- a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90
+++ b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90
@@ -1,5 +1,6 @@
-! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } }
-! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fdump-tree-optimized" }
+! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } }

Re: [PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)

[Jakub Jelinek]

On Tue, Feb 26, 2019 at 04:08:21PM +0100, Richard Biener wrote:
> I think we can have multiple .ABNORMAL_DISPATCHERs - at least in theory
> via inlining, though I see code in the inliner avoiding multiple ones
> at least for nonlocal goto, not sure if that covers all cases.

Ok.

> > Shall I modify the patch for that?
> 
> Might it even simplify the patch?  If not the only comment on the
> original patch is that it would be nice to test it on a SJLJ EH
> target ...

 1 file changed, 29 insertions(+), 16 deletions(-)
so not really simplify it, but not terrible either.

Here is the incremental (untested) diff of what handles that.

I don't have access to any standard SJLJ EH targets, but will try
--enable-sjlj-exceptions on x86_64-linux to see how far I get with that.

--- gcc/tree-cfgcleanup.c.jj2019-02-26 16:52:33.828719803 +0100
+++ gcc/tree-cfgcleanup.c   2019-02-26 17:11:07.735576027 +0100
@@ -731,12 +731,7 @@ cleanup_tree_cfg_bb (basic_block bb)
normally are effectively unreachable as well.  Additionally ignore
__builtin_setjmp_receiver starting blocks, which have one FORCED_LABEL
and which are always only reachable through EDGE_ABNORMAL edge.  They are
-   handled in cleanup_control_flow_pre.
-   Similarly, return true for EDGE_ABNORMAL edge from any basic block to
-   .ABNORMAL_DISPATCHER basic block if the latter block has no successors.
-   .ABNORMAL_DISPATCHER basic blocks that don't dispatch to anything are dead,
-   don't really need any EDGE_ABNORMAL edges to them and can be safely
-   removed.  */
+   handled in cleanup_control_flow_pre.  */
 
 static bool
 maybe_dead_abnormal_edge_p (edge e)
@@ -747,16 +742,7 @@ maybe_dead_abnormal_edge_p (edge e)
   gimple_stmt_iterator gsi = gsi_start_nondebug_after_labels_bb (e->src);
   gimple *g = gsi_stmt (gsi);
   if (!g || !gimple_call_internal_p (g, IFN_ABNORMAL_DISPATCHER))
-{
-  if (EDGE_COUNT (e->dest->succs) == 0)
-   {
- gsi = gsi_start_nondebug_after_labels_bb (e->dest);
- g = gsi_stmt (gsi);
- if (g && gimple_call_internal_p (g, IFN_ABNORMAL_DISPATCHER))
-   return true;
-   }
-  return false;
-}
+return false;
 
   tree target = NULL_TREE;
   for (gsi = gsi_start_bb (e->dest); !gsi_end_p (gsi); gsi_next ())
@@ -846,6 +832,7 @@ cleanup_control_flow_pre ()
   bitmap_clear (visited);
 
   vec *setjmp_vec = NULL;
+  auto_vec abnormal_dispatchers;
 
   stack.quick_push (ei_start (ENTRY_BLOCK_PTR_FOR_FN (cfun)->succs));
 
@@ -877,6 +864,16 @@ cleanup_control_flow_pre ()
stack.quick_push (ei_start (setjmp_vec));
}
 
+ if ((ei_edge (ei)->flags
+  & (EDGE_ABNORMAL | EDGE_EH)) == EDGE_ABNORMAL)
+   {
+ gimple_stmt_iterator gsi
+   = gsi_start_nondebug_after_labels_bb (dest);
+ gimple *g = gsi_stmt (gsi);
+ if (g && gimple_call_internal_p (g, IFN_ABNORMAL_DISPATCHER))
+   abnormal_dispatchers.safe_push (dest);
+   }
+
  if (EDGE_COUNT (dest->succs) > 0)
stack.quick_push (ei_start (dest->succs));
}
@@ -895,6 +892,22 @@ cleanup_control_flow_pre ()
 
   vec_free (setjmp_vec);
 
+  /* If we've marked .ABNORMAL_DISPATCHER basic block(s) as visited
+ above, but haven't marked any of their successors as visited,
+ unmark them now, so that they can be removed as useless.  */
+  basic_block dispatcher_bb;
+  unsigned int k;
+  FOR_EACH_VEC_ELT (abnormal_dispatchers, k, dispatcher_bb)
+{
+  edge e;
+  edge_iterator ei;
+  FOR_EACH_EDGE (e, ei, dispatcher_bb->succs)
+   if (bitmap_bit_p (visited, e->dest->index))
+ break;
+  if (e == NULL)
+   bitmap_clear_bit (visited, dispatcher_bb->index);
+}
+
   set_dom_info_availability (CDI_DOMINATORS, saved_state);
 
   /* We are deleting BBs in non-reverse dominator order, make sure


Jakub

Re: [C++ Patch] PR 89488 ("[9 Regression] ICE in merge_exception_specifiers, at cp/typeck2.c:2395")

[Paolo Carlini]

Hi,

On 26/02/19 15:28, Jason Merrill wrote:

On 2/25/19 10:27 AM, Paolo Carlini wrote:

Hi,

this error recovery regression has to do with the recent changes 
committed by Jason for c++/88368. What happens is that 
maybe_instantiate_noexcept fails the hard way, thus, toward the end 
of the function, doesn't update TREE_TYPE (fn) and just returns 
false. process_subob_fn doesn't notice and proceeds to call 
merge_exception_specifiers anyway where of course the gcc_assert 
(!DEFERRED_NOEXCEPT_SPEC_P (add)) triggers, because 
maybe_instantiate_noexcept has not done its normal job. To improve 
error-recovery I think we can simply leave *spec_p alone in such 
cases, because we would merge the *spec_p with a 
TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn)) where TREE_TYPE (fn) has not 
been normally computed. I tried a few other things which prima facie 
looked sensible but nothing else worked - eg, returning false from 
maybe_instantiate_noexcept and also updating TREE_TYPE (fn) to a 
noexcept_false_spec variant causes regressions exactly for the 
testcases of c++/88368.


If maybe_instantiate_noexcept returns false, I think we should set 
*spec_p to error_mark_node.


Sure, that certainly works, I tested it a couple of days ago and I'm 
finishing testing the below now. The only difference is that during 
error-recovery 'zl ()' is seen as seriously broken and we don't give the 
second,  "cannot convert", error message, which we used to give.


Thanks, Paolo.

/

Index: cp/method.c
===
--- cp/method.c (revision 269187)
+++ cp/method.c (working copy)
@@ -1256,9 +1256,13 @@ process_subob_fn (tree fn, tree *spec_p, bool *tri
 
   if (spec_p)
 {
-  maybe_instantiate_noexcept (fn);
-  tree raises = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn));
-  *spec_p = merge_exception_specifiers (*spec_p, raises);
+  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);
+   }
 }
 
   if (!trivial_fn_p (fn) && !dtor_from_ctor)
Index: testsuite/g++.dg/cpp0x/nsdmi15.C
===
--- testsuite/g++.dg/cpp0x/nsdmi15.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/nsdmi15.C(working copy)
@@ -0,0 +1,8 @@
+// PR c++/89488
+// { dg-do compile { target c++11 } }
+
+struct zl {
+  struct {
+int x2 = zl ();  // { dg-error "default member" }
+  } fx;
+};

[AArch64, SVE] Fix vectorized FP converts

[Alejandro Martinez Vicente]

Hi,

Some of the narrowing/widening FP converts were missing from SVE. I fixed most
of them, so they can be vectorized. The ones missing are int64->fp16 and
fp16->int64.

I extended the tests to cover the cases that were missing.

I validated the patch with self-checking and running the new SVE tests on an
SVE emulator.

Alejandro


gcc/Changelog:

2019-02-25  Alejandro Martinez  

* config/aarch64/aarch64-sve.md
(aarch64_sve__vnx8hf2,
aarch64_sve__vnx4sf2): Renamed FP to int
patterns.
(vec_unpack_fix_trunc__,
vec_pack_float_): New unpack/pack expanders.
* config/aarch64/iterators.md (SVE_HSDI): Fix cut-&-paste of SVE_BHSI.
(VWIDEINT): New iterator.
(VwideInt): Likewise.


gcc/testsuite/Changelog:
 
2019-02-25  Alejandro Martinez  

* gcc.target/aarch64/sve/fcvt_1.c: New test for fp to fp convert.
* gcc.target/aarch64/sve/fcvt_1_run.c: Likewise.
* gcc.target/aarch64/sve/cvtf_signed_1.c Improved test to cover
widening and narrowing cases.
* gcc.target/aarch64/sve/cvtf_signed_1_run.c: Likewise.
* gcc.target/aarch64/sve/cvtf_unsigned_1.c: Likewise.
* gcc.target/aarch64/sve/cvtf_unsigned_1_run.c: Likewise.
* gcc.target/aarch64/sve/fcvtz_signed_1.c: Likewise.
* gcc.target/aarch64/sve/fcvtz_signed_1_run.c: Likewise.
* gcc.target/aarch64/sve/fcvtz_unsigned_1.c: Likewise.
* gcc.target/aarch64/sve/fcvtz_unsigned_1_run.c: Likewise.



cvt_v4.patch
Description: cvt_v4.patch

libgo patch committed: Update to final Go 1.12 release

[Ian Lance Taylor]

I've committed this patch to update to the final Go 1.12 release.
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 269214)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e330eea4464f1513808ccd95011edb4ccbe946b5
+558fcb7bf2a6b78bdba87f20a8a4a95d27125d74
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/MERGE
===
--- libgo/MERGE (revision 269202)
+++ libgo/MERGE (working copy)
@@ -1,4 +1,4 @@
-1af509d46e31a14e7ff17e23b1fd84250976b405
+05e77d41914d247a1e7caf37d7125ccaa5a53505
 
 The first line of this file holds the git revision number of the
 last merge done from the master library sources.
Index: libgo/VERSION
===
--- libgo/VERSION   (revision 269202)
+++ libgo/VERSION   (working copy)
@@ -1 +1 @@
-go1.12rc1
+go1.12
Index: libgo/go/cmd/go/internal/work/exec.go
===
--- libgo/go/cmd/go/internal/work/exec.go   (revision 269196)
+++ libgo/go/cmd/go/internal/work/exec.go   (working copy)
@@ -657,7 +657,7 @@ func (b *Builder) build(a *Action) (err
if len(out) > 0 {
output := b.processOutput(out)
if p.Module != nil && !allowedVersion(p.Module.GoVersion) {
-   output += "note: module requires Go " + 
p.Module.GoVersion
+   output += "note: module requires Go " + 
p.Module.GoVersion + "\n"
}
b.showOutput(a, a.Package.Dir, a.Package.Desc(), output)
if err != nil {
Index: libgo/go/crypto/rc4/rc4.go
===
--- libgo/go/crypto/rc4/rc4.go  (revision 269196)
+++ libgo/go/crypto/rc4/rc4.go  (working copy)
@@ -45,8 +45,10 @@ func NewCipher(key []byte) (*Cipher, err
return , nil
 }
 
-// Reset zeros the key data so that it will no longer appear in the
-// process's memory.
+// Reset zeros the key data and makes the Cipher unusable.
+//
+// Deprecated: Reset can't guarantee that the key will be entirely removed from
+// the process's memory.
 func (c *Cipher) Reset() {
for i := range c.s {
c.s[i] = 0
Index: libgo/go/crypto/tls/handshake_client.go
===
--- libgo/go/crypto/tls/handshake_client.go (revision 269196)
+++ libgo/go/crypto/tls/handshake_client.go (working copy)
@@ -573,7 +573,7 @@ func (hs *clientHandshakeState) doFullHa
return fmt.Errorf("tls: client certificate private key 
of type %T does not implement crypto.Signer", chainToSend.PrivateKey)
}
 
-   signatureAlgorithm, sigType, hashFunc, err := 
pickSignatureAlgorithm(key.Public(), certReq.supportedSignatureAlgorithms, 
hs.hello.supportedSignatureAlgorithms, c.vers)
+   signatureAlgorithm, sigType, hashFunc, err := 
pickSignatureAlgorithm(key.Public(), certReq.supportedSignatureAlgorithms, 
supportedSignatureAlgorithmsTLS12, c.vers)
if err != nil {
c.sendAlert(alertInternalError)
return err
Index: libgo/go/crypto/tls/handshake_client_test.go
===
--- libgo/go/crypto/tls/handshake_client_test.go(revision 269202)
+++ libgo/go/crypto/tls/handshake_client_test.go(working copy)
@@ -873,10 +873,41 @@ func TestHandshakeClientCertPSSDisabled(
supportedSignatureAlgorithmsTLS12 = 
savedSupportedSignatureAlgorithmsTLS12
 
// Use t.Run to ensure the defer runs after all parallel tests end.
-   t.Run("", func(t *testing.T) {
+   t.Run("1024", func(t *testing.T) {
runClientTestTLS12(t, test)
runClientTestTLS13(t, test)
})
+
+   // Use a 512-bit key to check that the TLS 1.2 handshake is actually 
using
+   // PKCS#1 v1.5. PSS would be failing here.
+   cert, err := X509KeyPair([]byte(`-BEGIN CERTIFICATE-
+MIIBcTCCARugAwIBAgIQGjQnkCFlUqaFlt6ixyz/tDANBgkqhkiG9w0BAQsFADAS
+MRAwDgYDVQQKEwdBY21lIENvMB4XDTE5MDExODIzMjMyOFoXDTIwMDExODIzMjMy
+OFowEjEQMA4GA1UEChMHQWNtZSBDbzBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDd
+ez1rFUDwax2HTxbcnFUP9AhcgEGMHVV2nn4VVEWFJB6I8C/Nkx0XyyQlrmFYBzEQ
+nIPhKls4T0hFoLvjJnXpAgMBAAGjTTBLMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUE
+DDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMBYGA1UdEQQPMA2CC2V4YW1wbGUu
+Y29tMA0GCSqGSIb3DQEBCwUAA0EAxDuUS+BrrS3c+h+k+fQPOmOScy6yTX9mHw0Q
+KbucGamXYEy0URIwOdO0tQ3LHPc1YGvYSPwkDjkjqECs2Vm/AA==
+-END CERTIFICATE-`), []byte(`-BEGIN RSA PRIVATE KEY-

Re: [C++ Patch/RFC] PR 88987 ("[9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr")

[Paolo Carlini]

Hi,

On 26/02/19 15:33, Jason Merrill wrote:

On 2/26/19 5:42 AM, Paolo Carlini wrote:

Hi,

the issue is rather easy to explain: after Alexandre' change  in 
r266874, which simplified the condition at the beginning of 
build_noexcept_spec to evaluate early all the expressions which 
aren't deferred or value-dependent, we obviously ICE during 
error-recovery on the new testcase because an expression which isn't 
a potential constant filters through and cxx_constant_value can't 
handle it.  We can avoid this in various ways - for example by adding 
a gate && potential_rvalue_constant_expression_p (expr) in the 
condition at the beginning of build_noexcept_spec and adjust/remove 
the final gcc_assert (which is already a bit obsolete wrt Alexandre' 
change). Or we can handle this earlier, in 
cp_parser_noexcept_specification_opt - in complete analogy, with, 
say, cp_parser_initializer_list - thus don't let through those 
expressions at all (possible variant: set expr = error_mark_node), 
which has the advantage of avoiding a duplicate 
potential_rvalue_constant_expression call (note: in the parser 
build_no_except_spec is called only by 
cp_parser_noexcept_specification_opt)


All those variants pass the testsuite on x86_64-linux.

What happens if 'sm' is constexpr?


Well, if 'sm' is constexpr we accept the snippet, as we should, AFAICS. 
This is true for all my tentative patches, I think, certainly for what I 
posted.


Note, this is supposed to be only an error-recovery issue.

Paolo.

Re: [PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)

[Richard Biener]

On Tue, 26 Feb 2019, Jakub Jelinek wrote:

> On Sat, Feb 23, 2019 at 10:05:40AM +0100, Jakub Jelinek wrote:
> > And finally, for 1) the patch has a case for a dead .ABNORMAL_DISPATCHER,
> > one that has only incoming edges but no successors.  I didn't want to
> > complicate or slow down the processing too much, so it is actually done
> > only if .ABNORMAL_DISPATCHER has no outgoing edges, rather than if it has
> > some, but all of them are in the end to non-visited basic blocks.
> > This means when we for 5) or 4) above remove all such bbs as dead in one
> > cfg cleanup, we remove .ABNORMAL_DISPATCHER only in the following cfg
> > cleanup.
> 
> Thinking about the above, I think we could handle that cheaply in the same
> cleanup cfg rather than in the next one.  Don't know right now if we can
> have at most one .ABNORMAL_DISPATCHER in a function or more (I vaguely
> remember we disallow inlining in some of the ab cases like setjmp,
> non-local goto etc.), if there can be at most one, we could just make
> the .ABNORMAL_DISPATCHER visited normally, but additionally note it in some
> basic_block pointer, if we can have more than one, we could have auto_vec of
> them, and then after the loop just go through that one or more
> .ABNORMAL_DISPATCHER bbs and if they don't have any successors visited,
> unset the visited bit for them as well.

I think we can have multiple .ABNORMAL_DISPATCHERs - at least in theory
via inlining, though I see code in the inliner avoiding multiple ones
at least for nonlocal goto, not sure if that covers all cases.

> Shall I modify the patch for that?

Might it even simplify the patch?  If not the only comment on the
original patch is that it would be nice to test it on a SJLJ EH
target ...

Richard.

> > 2019-02-23  Jakub Jelinek  
> > 
> > PR tree-optimization/89280
> > * tree-cfgcleanup.c (maybe_dead_abnormal_edge_p,
> > builtin_setjmp_setup_bb): New functions.
> > (cleanup_control_flow_pre): Ignore maybe_dead_abnormal_edge_p edges.
> > When visiting __builtin_setjmp_setup block, queue in special
> > setjmp_vec vector edges from .ABNORMAL_DISPATCHER to corresponding
> > __builtin_setjmp_receiver.
> > 
> > * gcc.c-torture/compile/pr89280.c: New test.
> > * gcc.dg/torture/pr57147-2.c: Don't expect a setjmp after noreturn
> > function.  Skip the test for -O0.
> 
>   Jakub
> 
> 

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

Re: [PATCH][stage 1] Fix bitmap registration of overheads.

[Richard Biener]

On Tue, Feb 26, 2019 at 3:30 PM Martin Liška  wrote:
>
> Hi.
>
> I've rewritten bitmap memory statistics which abused unsigned
> type via register_overhead (map, -((int)sizeof (bitmap_head))).
> I come up with a concept that each bitmap has assigned a unique ID
> which is used for stats tracking. It's caused by fact that e.g. DF is
> heavily reallocating bitmaps that then have a different address.
>
> Survives bootstrap with --enable-gather-detailed-mem-stats.
>
> Ready for next stage1?

+  /* Get bitmap descriptor UID casted to an unsigned integer pointer.  */
+  unsigned *get_descriptor ()
+  {
+return (unsigned *)(ptrdiff_t)alloc_descriptor;
+  }

this one is a bit ugly and together with

template 
inline hashval_t
pointer_hash ::hash (const value_type )
{
  /* This is a really poor hash function, but it is what the current code uses,
 so I am reusing it to avoid an additional axis in testing.  */
  return (hashval_t) ((intptr_t)candidate >> 3);

will give quite some hash collisions.  So I guess you should shift
the descriptor << 3 at least (and then make it at most 29 bits in
size?).  Not sure what to do about the descriptor wrapping btw.

Richard.

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-02-26  Martin Liska  
>
> * bitmap.c (bitmap_register): Come up with
> alloc_descriptor_max_uid and assign it for
> a new bitmap.
> (register_overhead): Use get_descriptor as
> a descriptor.
> (release_overhead): New.
> (bitmap_elem_to_freelist): Call it.
> (bitmap_elt_clear_from): Likewise.
> (bitmap_obstack_free): Likewise.
> (bitmap_move): Sensitively release memory.
> * bitmap.h (struct GTY): Add alloc_descriptor.
> (bitmap_initialize): Initialize alloc_descriptor to zero.
> * tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
> ---
>  gcc/bitmap.c   | 39 ---
>  gcc/bitmap.h   | 17 ++---
>  gcc/tree-ssa-pre.c |  2 +-
>  3 files changed, 43 insertions(+), 15 deletions(-)
>
>

Re: [PATCH] Remove a legacy lto-symtab.c file.

[Jan Hubicka]

> On Tue, Feb 26, 2019 at 3:25 PM Martin Liška  wrote:
> >
> > Hi.
> >
> > It's a legacy file that is out of current build system. I tried
> > to fix compilation errors, but it crashes early after start.
> >
> > May I remove the file?
> 
> yeah, it's probably just left over by accident.

I think it is replaced by nm + plugin :)

Honza

Re: [PATCH][libbacktrace] Add btest_lto

[Ian Lance Taylor via gcc-patches]

On Tue, Feb 26, 2019 at 6:27 AM Tom de Vries  wrote:
>
> On 26-02-19 13:00, Thomas Schwinge wrote:
> > Hi Tom!
> >
> > On Tue, 26 Feb 2019 12:28:34 +0100, Tom de Vries  wrote:
> >> On 26-02-19 10:40, Thomas Schwinge wrote:
> >>> On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries  wrote:
>  On 25-02-19 11:48, Thomas Schwinge wrote:
> > On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries  
> > wrote:
> >> Add libbacktrace test-case using -flto.
> >
> > I'm seeing this one fail is some configurations, but only in the
> > 'build-gcc/libbacktrace/btest_lto.log' variant:
> >>>
>  Meaning, compiling libbacktrace using the host compiler, so it would be
>  useful to known which compiler that is.
> 
>  [ I've tried a gcc-4.8 and gcc-6 and gcc-7 as host compiler, and a
>  couple of CFLAGS settings (-O2, -O3) to reproduce this, but didn't 
>  manage. ]
> >>>
> >>> Years old:
> >>>
> >>> $ gcc --version
> >>> gcc (Sourcery CodeBench 2014.05-45) 4.8.3 20140320 (prerelease)
> >>> [...]
> >>> $ ld --version
> >>> GNU ld (Sourcery CodeBench 2014.05-45) 2.24.51.20140217
> >>> [...]
> >>>
> >>> (It'll be fine for me if you just declare that unsupported.)
> >>
> >> I see. The 4.8 I tried is a 4.8.5.
> >>
> > test5: unexpected syminfo name got global.2537 expected global
> > PASS: backtrace_full noinline
> > PASS: backtrace_full inline
> > PASS: backtrace_simple noinline
> > PASS: backtrace_simple inline
> > FAIL: backtrace_syminfo variable
> > FAIL btest_lto (exit status: 1)
> >
> > I haven't looked yet which details about these GCC build configurations
> > might be different/important; maybe you've got an idea already?
> >>>
> >>> I can reproduce this with '-O0' ("unexpected syminfo name got global.2528
> >>> expected global", in that case).  With '-O0 -fdump-tree-all
> >>> -fdump-ipa-all -save-temps', the 'global.2528' name appears only in
> >>> 'btest_lto.ltrans0.000i.cgraph', and 'btest_lto.ltrans0.s':
> >>>
> >>> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> >>> (addr)state.2526/56 (read)callback_three.2389/64 
> >>> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> >>> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> >>> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> >>> (write)failures.2527/57 (read)
> >>> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> >>> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> >>> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> >>> (addr)state.2526/56 (read)callback_three.2389/64 
> >>> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> >>> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> >>> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> >>> (write)failures.2527/57 (read)
> >>> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> >>> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> >>> (addr)state.2526/56 (read)callback_three.2389/64 
> >>> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> >>> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> >>> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> >>> (write)failures.2527/57 (read)
> >>> ./btest_lto.ltrans0.s:  .type   global.2528, @object
> >>> ./btest_lto.ltrans0.s:  .size   global.2528, 4
> >>> ./btest_lto.ltrans0.s:global.2528:
> >>> ./btest_lto.ltrans0.s:  movq$global.2528, -8(%rbp)  #, addr
> >>> ./btest_lto.ltrans0.s:  movl$global.2528, %eax  #, global.22
> >>> ./btest_lto.ltrans0.s:  movl$global.2528, %ecx  #, global.23
> >>> ./btest_lto.ltrans0.s:  .quad   global.2528
> >
> > With '-fdump-rtl-all' added, I see it appear in
> > 'btest_lto.ltrans0.166r.expand':
> >
> > ./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
> > [flags 0x2]  )) [...]/libbacktrace/btest.c:399 
> > -1
> > ./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
> > [flags 0x2]  )) [...]/libbacktrace/btest.c:433 
> > -1
> > ./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
> > [flags 0x2]  )) [...]/libbacktrace/btest.c:435 
> > -1
> >
> >> How about:
> >> ...
> >> - int global;
> >> + static int global;
> >> ...
> >>
> >> Does that fix the failure?
> >
> > No, that gets us "unexpected syminfo name got global.2479.2528 expected
> > global".  ;-\
> >
>
> Ian,
>
> Is this approach OK?

I would drop the #ifdef and just always accept it.

if (strncmp (symdata.name, "global") == 0
&& (symdata.name[6] == '\0' || symdata.name[6] == '.'))

Ian

Re: [PATCH] Improve memory statistics report readability.

[Richard Biener]

On Tue, Feb 26, 2019 at 3:27 PM Martin Liška  wrote:
>
> Hi.
>
> The patch is fixing an error in vec_safe_grow_cleared function.
> Apart from that I improved readability of the report.
>
> Patch bootstrap with --enable-gather-detailed-mem-stats.
>
> Ready to be installed?

OK.

Richard.

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-02-26  Martin Liska  
>
> * alloc-pool.h (struct pool_usage): Remove extra
> print_dash_line.
> * bitmap.h (struct bitmap_usage): Likewise.
> * ggc-common.c (struct ggc_usage): Likewise.
> * mem-stats.h (struct mem_usage): Likewise.
> (mem_alloc_description::dump): Print dash lines
> here and repeat header at the end of a table report.
> It's then more readable.
> * tree-phinodes.c (phinodes_print_statistics): Make
> horizontal alignment.
> * tree-ssanames.c (ssanames_print_statistics): Likewise.
> * vec.c (struct vec_usage): Remove extra print_dash_line.
> * vec.h (vec_safe_grow_cleared): Pass PASS_MEM_STAT.
>
> libcpp/ChangeLog:
>
> 2019-02-26  Martin Liska  
>
> * symtab.c (ht_dump_statistics): Make
> horizontal alignment for statistics.
> ---
>  gcc/alloc-pool.h|  3 ---
>  gcc/bitmap.h|  1 -
>  gcc/ggc-common.c|  3 ---
>  gcc/mem-stats.h |  9 ++---
>  gcc/tree-phinodes.c |  4 ++--
>  gcc/tree-ssanames.c |  4 ++--
>  gcc/vec.c   |  3 ---
>  gcc/vec.h   |  2 +-
>  libcpp/symtab.c | 24 +---
>  9 files changed, 24 insertions(+), 29 deletions(-)
>
>

Re: [PATCH] Remove a legacy lto-symtab.c file.

[Richard Biener]

On Tue, Feb 26, 2019 at 3:25 PM Martin Liška  wrote:
>
> Hi.
>
> It's a legacy file that is out of current build system. I tried
> to fix compilation errors, but it crashes early after start.
>
> May I remove the file?

yeah, it's probably just left over by accident.

Richard.

> Thanks,
> Martin
>
> lto-plugin/ChangeLog:
>
> 2019-02-26  Martin Liska  
>
> * lto-symtab.c: Remove.
> ---
>  lto-plugin/lto-symtab.c | 359 
>  1 file changed, 359 deletions(-)
>  delete mode 100644 lto-plugin/lto-symtab.c
>
>

[PATCH][wwwdocs] Fix typo in -ftree-switch-conversion improvement

[Kyrill Tkachov]

Hi all,

This fixes a typo and removes the "with cases" from "as a switch 
statement with cases" as that's redundant.

Checked output on Firefox.

Committing as obvious.

Thanks,
Kyrill

Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.44
diff -U 3 -r1.44 changes.html
--- htdocs/gcc-9/changes.html	26 Feb 2019 11:14:42 -	1.44
+++ htdocs/gcc-9/changes.html	26 Feb 2019 12:25:28 -
@@ -75,7 +75,7 @@
   (jump table, bit test, decision tree) for a subset of switch cases.
   
   
-  A linear function expression defined as ia switch statement with cases
+  A linear function expression defined as a switch statement
   can be transformed by https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftree-switch-conversion;>-ftree-switch-conversion.  For example:
 
 int

libgo patch committed: Always declare nanotime in Go

[Ian Lance Taylor]

For the libgo implementation nanotime is always defined in C, so
remove build tags so that it is always declared in Go.  This is for PR
86535.  Bootstrapped and tested on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269202)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-51d2cb40a6475b126ed66cefa2aa6c8dbdc806d0
+e330eea4464f1513808ccd95011edb4ccbe946b5
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/stubs3.go
===
--- libgo/go/runtime/stubs3.go  (revision 269196)
+++ libgo/go/runtime/stubs3.go  (working copy)
@@ -2,13 +2,6 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build !plan9
-// +build !windows
-// +build !nacl
-// +build !freebsd
-// +build !darwin
-// +build !aix
-
 package runtime
 
 func nanotime() int64

Re: [PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)

[Jakub Jelinek]

On Sat, Feb 23, 2019 at 10:05:40AM +0100, Jakub Jelinek wrote:
> And finally, for 1) the patch has a case for a dead .ABNORMAL_DISPATCHER,
> one that has only incoming edges but no successors.  I didn't want to
> complicate or slow down the processing too much, so it is actually done
> only if .ABNORMAL_DISPATCHER has no outgoing edges, rather than if it has
> some, but all of them are in the end to non-visited basic blocks.
> This means when we for 5) or 4) above remove all such bbs as dead in one
> cfg cleanup, we remove .ABNORMAL_DISPATCHER only in the following cfg
> cleanup.

Thinking about the above, I think we could handle that cheaply in the same
cleanup cfg rather than in the next one.  Don't know right now if we can
have at most one .ABNORMAL_DISPATCHER in a function or more (I vaguely
remember we disallow inlining in some of the ab cases like setjmp,
non-local goto etc.), if there can be at most one, we could just make
the .ABNORMAL_DISPATCHER visited normally, but additionally note it in some
basic_block pointer, if we can have more than one, we could have auto_vec of
them, and then after the loop just go through that one or more
.ABNORMAL_DISPATCHER bbs and if they don't have any successors visited,
unset the visited bit for them as well.

Shall I modify the patch for that?

> 2019-02-23  Jakub Jelinek  
> 
>   PR tree-optimization/89280
>   * tree-cfgcleanup.c (maybe_dead_abnormal_edge_p,
>   builtin_setjmp_setup_bb): New functions.
>   (cleanup_control_flow_pre): Ignore maybe_dead_abnormal_edge_p edges.
>   When visiting __builtin_setjmp_setup block, queue in special
>   setjmp_vec vector edges from .ABNORMAL_DISPATCHER to corresponding
>   __builtin_setjmp_receiver.
> 
>   * gcc.c-torture/compile/pr89280.c: New test.
>   * gcc.dg/torture/pr57147-2.c: Don't expect a setjmp after noreturn
>   function.  Skip the test for -O0.

Jakub

Re: [C++ Patch/RFC] PR 88987 ("[9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr")

[Jason Merrill]

On 2/26/19 5:42 AM, Paolo Carlini wrote:

Hi,

the issue is rather easy to explain: after Alexandre' change  in 
r266874, which simplified the condition at the beginning of 
build_noexcept_spec to evaluate early all the expressions which aren't 
deferred or value-dependent, we obviously ICE during error-recovery on 
the new testcase because an expression which isn't a potential constant 
filters through and cxx_constant_value can't handle it.  We can avoid 
this in various ways - for example by adding a gate && 
potential_rvalue_constant_expression_p (expr) in the condition at the 
beginning of build_noexcept_spec and adjust/remove the final gcc_assert 
(which is already a bit obsolete wrt Alexandre' change). Or we can 
handle this earlier, in cp_parser_noexcept_specification_opt - in 
complete analogy, with, say, cp_parser_initializer_list - thus don't let 
through those expressions at all (possible variant: set expr = 
error_mark_node), which has the advantage of avoiding a duplicate 
potential_rvalue_constant_expression call (note: in the parser 
build_no_except_spec is called only by 
cp_parser_noexcept_specification_opt)


All those variants pass the testsuite on x86_64-linux.


What happens if 'sm' is constexpr?

Jason

[PATCH][stage 1] Fix bitmap registration of overheads.

[Martin Liška]

Hi.

I've rewritten bitmap memory statistics which abused unsigned
type via register_overhead (map, -((int)sizeof (bitmap_head))).
I come up with a concept that each bitmap has assigned a unique ID
which is used for stats tracking. It's caused by fact that e.g. DF is
heavily reallocating bitmaps that then have a different address.

Survives bootstrap with --enable-gather-detailed-mem-stats.

Ready for next stage1?
Thanks,
Martin

gcc/ChangeLog:

2019-02-26  Martin Liska  

* bitmap.c (bitmap_register): Come up with
alloc_descriptor_max_uid and assign it for
a new bitmap.
(register_overhead): Use get_descriptor as
a descriptor.
(release_overhead): New.
(bitmap_elem_to_freelist): Call it.
(bitmap_elt_clear_from): Likewise.
(bitmap_obstack_free): Likewise.
(bitmap_move): Sensitively release memory.
* bitmap.h (struct GTY): Add alloc_descriptor.
(bitmap_initialize): Initialize alloc_descriptor to zero.
* tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
---
 gcc/bitmap.c   | 39 ---
 gcc/bitmap.h   | 17 ++---
 gcc/tree-ssa-pre.c |  2 +-
 3 files changed, 43 insertions(+), 15 deletions(-)


diff --git a/gcc/bitmap.c b/gcc/bitmap.c
index 5a8236de750..894aefa13de 100644
--- a/gcc/bitmap.c
+++ b/gcc/bitmap.c
@@ -36,18 +36,33 @@ static bitmap_element *bitmap_tree_listify_from (bitmap, bitmap_element *);
 void
 bitmap_register (bitmap b MEM_STAT_DECL)
 {
-  bitmap_mem_desc.register_descriptor (b, BITMAP_ORIGIN, false
-   FINAL_PASS_MEM_STAT);
+  static unsigned alloc_descriptor_max_uid = 1;
+  gcc_assert (b->alloc_descriptor == 0);
+  b->alloc_descriptor = alloc_descriptor_max_uid++;
+
+  bitmap_mem_desc.register_descriptor (b->get_descriptor (), BITMAP_ORIGIN,
+   false FINAL_PASS_MEM_STAT);
 }
 
 /* Account the overhead.  */
 static void
 register_overhead (bitmap b, size_t amount)
 {
-  if (bitmap_mem_desc.contains_descriptor_for_instance (b))
-bitmap_mem_desc.register_instance_overhead (amount, b);
+  unsigned *d = b->get_descriptor ();
+  if (bitmap_mem_desc.contains_descriptor_for_instance (d))
+bitmap_mem_desc.register_instance_overhead (amount, d);
+}
+
+/* Release the overhead.  */
+static void
+release_overhead (bitmap b, size_t amount, bool remove_from_map)
+{
+  unsigned *d = b->get_descriptor ();
+  if (bitmap_mem_desc.contains_descriptor_for_instance (d))
+bitmap_mem_desc.release_instance_overhead (d, amount, remove_from_map);
 }
 
+
 /* Global data */
 bitmap_element bitmap_zero_bits;  /* An element of all zero bits.  */
 bitmap_obstack bitmap_default_obstack;/* The default bitmap obstack.  */
@@ -65,7 +80,7 @@ bitmap_elem_to_freelist (bitmap head, bitmap_element *elt)
   bitmap_obstack *bit_obstack = head->obstack;
 
   if (GATHER_STATISTICS)
-register_overhead (head, -((int)sizeof (bitmap_element)));
+release_overhead (head, sizeof (bitmap_element), false);
 
   elt->next = NULL;
   elt->indx = -1;
@@ -153,7 +168,7 @@ bitmap_elt_clear_from (bitmap head, bitmap_element *elt)
   int n = 0;
   for (prev = elt; prev; prev = prev->next)
 	n++;
-  register_overhead (head, -sizeof (bitmap_element) * n);
+  release_overhead (head, sizeof (bitmap_element) * n, false);
 }
 
   prev = elt->prev;
@@ -798,7 +813,7 @@ bitmap_obstack_free (bitmap map)
   map->first = (bitmap_element *) map->obstack->heads;
 
   if (GATHER_STATISTICS)
-	register_overhead (map, -((int)sizeof (bitmap_head)));
+	release_overhead (map, sizeof (bitmap_head), true);
 
   map->obstack->heads = map;
 }
@@ -872,16 +887,18 @@ bitmap_move (bitmap to, bitmap from)
 
   bitmap_clear (to);
 
-  *to = *from;
-
+  size_t sz = 0;
   if (GATHER_STATISTICS)
 {
-  size_t sz = 0;
   for (bitmap_element *e = to->first; e; e = e->next)
 	sz += sizeof (bitmap_element);
   register_overhead (to, sz);
-  register_overhead (from, -sz);
 }
+
+  *to = *from;
+
+  if (GATHER_STATISTICS)
+release_overhead (from, sz, false);
 }
 
 /* Clear a single bit in a bitmap.  Return true if the bit changed.  */
diff --git a/gcc/bitmap.h b/gcc/bitmap.h
index ed25c1ee5da..d9368e7f780 100644
--- a/gcc/bitmap.h
+++ b/gcc/bitmap.h
@@ -325,14 +325,16 @@ struct GTY(()) bitmap_head {
   static bitmap_obstack crashme;
   /* Poison obstack to not make it not a valid initialized GC bitmap.  */
   CONSTEXPR bitmap_head()
-: indx(0), tree_form(false), first(NULL), current(NULL),
-  obstack ()
+: indx (0), tree_form (false), alloc_descriptor (0), first (NULL),
+  current (NULL), obstack ()
   {}
   /* Index of last element looked at.  */
   unsigned int indx;
   /* False if the bitmap is in list form; true if the bitmap is in tree form.
  Bitmap iterators only work on bitmaps in list form.  */
-  bool tree_form;
+  unsigned tree_form: 1;
+  /* Bitmap UID used for memory allocation statistics.  */
+  

Re: [C++ PATCH] Fix up constexpr changing of active union member (PR c++/89481)

[Jason Merrill]

On 2/25/19 5:45 PM, Jakub Jelinek wrote:

Hi!

cxx_eval_store_expression has code to propagate no_zero_init from outer
ctors to inner ctors, if the outer ctor is known to be zero initialized, the
inner one should be as well.

As the following patch shows, when changing active union member there needs
to be an exception, even if the whole containing aggregate was zero
initialized before, if we change the union member and just initialize some
portion of the new one, we can't assume the rest is initialized.

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


OK.

Jason

Re: [C++ Patch] PR 89488 ("[9 Regression] ICE in merge_exception_specifiers, at cp/typeck2.c:2395")

[Jason Merrill]

On 2/25/19 10:27 AM, Paolo Carlini wrote:

Hi,

this error recovery regression has to do with the recent changes 
committed by Jason for c++/88368. What happens is that 
maybe_instantiate_noexcept fails the hard way, thus, toward the end of 
the function, doesn't update TREE_TYPE (fn) and just returns false. 
process_subob_fn doesn't notice and proceeds to call 
merge_exception_specifiers anyway where of course the gcc_assert 
(!DEFERRED_NOEXCEPT_SPEC_P (add)) triggers, because 
maybe_instantiate_noexcept has not done its normal job. To improve 
error-recovery I think we can simply leave *spec_p alone in such cases, 
because we would merge the *spec_p with a TYPE_RAISES_EXCEPTIONS 
(TREE_TYPE (fn)) where TREE_TYPE (fn) has not been normally computed. I 
tried a few other things which prima facie looked sensible but nothing 
else worked - eg, returning false from maybe_instantiate_noexcept and 
also updating TREE_TYPE (fn) to a noexcept_false_spec variant causes 
regressions exactly for the testcases of c++/88368.


If maybe_instantiate_noexcept returns false, I think we should set 
*spec_p to error_mark_node.


Jason

Re: [PATCH][libbacktrace] Add btest_lto

[Tom de Vries]

On 26-02-19 13:00, Thomas Schwinge wrote:
> Hi Tom!
> 
> On Tue, 26 Feb 2019 12:28:34 +0100, Tom de Vries  wrote:
>> On 26-02-19 10:40, Thomas Schwinge wrote:
>>> On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries  wrote:
 On 25-02-19 11:48, Thomas Schwinge wrote:
> On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries  wrote:
>> Add libbacktrace test-case using -flto.
>
> I'm seeing this one fail is some configurations, but only in the
> 'build-gcc/libbacktrace/btest_lto.log' variant:
>>>
 Meaning, compiling libbacktrace using the host compiler, so it would be
 useful to known which compiler that is.

 [ I've tried a gcc-4.8 and gcc-6 and gcc-7 as host compiler, and a
 couple of CFLAGS settings (-O2, -O3) to reproduce this, but didn't manage. 
 ]
>>>
>>> Years old:
>>>
>>> $ gcc --version
>>> gcc (Sourcery CodeBench 2014.05-45) 4.8.3 20140320 (prerelease)
>>> [...]
>>> $ ld --version
>>> GNU ld (Sourcery CodeBench 2014.05-45) 2.24.51.20140217
>>> [...]
>>>
>>> (It'll be fine for me if you just declare that unsupported.)
>>
>> I see. The 4.8 I tried is a 4.8.5.
>>
> test5: unexpected syminfo name got global.2537 expected global
> PASS: backtrace_full noinline
> PASS: backtrace_full inline
> PASS: backtrace_simple noinline
> PASS: backtrace_simple inline
> FAIL: backtrace_syminfo variable
> FAIL btest_lto (exit status: 1)
>
> I haven't looked yet which details about these GCC build configurations
> might be different/important; maybe you've got an idea already?
>>>
>>> I can reproduce this with '-O0' ("unexpected syminfo name got global.2528
>>> expected global", in that case).  With '-O0 -fdump-tree-all
>>> -fdump-ipa-all -save-temps', the 'global.2528' name appears only in
>>> 'btest_lto.ltrans0.000i.cgraph', and 'btest_lto.ltrans0.s':
>>>
>>> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
>>> (addr)state.2526/56 (read)callback_three.2389/64 
>>> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
>>> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
>>> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
>>> (write)failures.2527/57 (read)
>>> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
>>> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
>>> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
>>> (addr)state.2526/56 (read)callback_three.2389/64 
>>> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
>>> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
>>> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
>>> (write)failures.2527/57 (read)
>>> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
>>> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
>>> (addr)state.2526/56 (read)callback_three.2389/64 
>>> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
>>> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
>>> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
>>> (write)failures.2527/57 (read)
>>> ./btest_lto.ltrans0.s:  .type   global.2528, @object
>>> ./btest_lto.ltrans0.s:  .size   global.2528, 4
>>> ./btest_lto.ltrans0.s:global.2528:
>>> ./btest_lto.ltrans0.s:  movq$global.2528, -8(%rbp)  #, addr
>>> ./btest_lto.ltrans0.s:  movl$global.2528, %eax  #, global.22
>>> ./btest_lto.ltrans0.s:  movl$global.2528, %ecx  #, global.23
>>> ./btest_lto.ltrans0.s:  .quad   global.2528
> 
> With '-fdump-rtl-all' added, I see it appear in
> 'btest_lto.ltrans0.166r.expand':
> 
> ./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
> [flags 0x2]  )) [...]/libbacktrace/btest.c:399 -1
> ./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
> [flags 0x2]  )) [...]/libbacktrace/btest.c:433 -1
> ./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
> [flags 0x2]  )) [...]/libbacktrace/btest.c:435 -1
> 
>> How about:
>> ...
>> - int global;
>> + static int global;
>> ...
>>
>> Does that fix the failure?
> 
> No, that gets us "unexpected syminfo name got global.2479.2528 expected
> global".  ;-\
> 

Ian,

Is this approach OK?

Thanks,
- Tom
[libbacktrace] Fix btest-lto for older gcc

With gcc 4.8.5, btest_lto ends up with a privatized name for the variable with
name 'global':
...
$ nm btest_lto | grep ' d ' | grep global
00617150 d global.2530
...
which makes test5 fail:
...
test5: unexpected syminfo name got global.2530 expected global
...

Fix this failure by accepting this type of name as a valid name in btest_lto.

2019-02-26  Tom de Vries  

	* Makefile.am (btest_lto_CFLAGS): Add -DHAVE_LTO.
	* Makefile.in: Regenerate.
	* btest.c (test5) [HAVE_LTO]: Allow global.* as minimal symbol name
	

[PATCH] Improve memory statistics report readability.

[Martin Liška]

Hi.

The patch is fixing an error in vec_safe_grow_cleared function.
Apart from that I improved readability of the report.

Patch bootstrap with --enable-gather-detailed-mem-stats.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2019-02-26  Martin Liska  

* alloc-pool.h (struct pool_usage): Remove extra
print_dash_line.
* bitmap.h (struct bitmap_usage): Likewise.
* ggc-common.c (struct ggc_usage): Likewise.
* mem-stats.h (struct mem_usage): Likewise.
(mem_alloc_description::dump): Print dash lines
here and repeat header at the end of a table report.
It's then more readable.
* tree-phinodes.c (phinodes_print_statistics): Make
horizontal alignment.
* tree-ssanames.c (ssanames_print_statistics): Likewise.
* vec.c (struct vec_usage): Remove extra print_dash_line.
* vec.h (vec_safe_grow_cleared): Pass PASS_MEM_STAT.

libcpp/ChangeLog:

2019-02-26  Martin Liska  

* symtab.c (ht_dump_statistics): Make
horizontal alignment for statistics.
---
 gcc/alloc-pool.h|  3 ---
 gcc/bitmap.h|  1 -
 gcc/ggc-common.c|  3 ---
 gcc/mem-stats.h |  9 ++---
 gcc/tree-phinodes.c |  4 ++--
 gcc/tree-ssanames.c |  4 ++--
 gcc/vec.c   |  3 ---
 gcc/vec.h   |  2 +-
 libcpp/symtab.c | 24 +---
 9 files changed, 24 insertions(+), 29 deletions(-)


diff --git a/gcc/alloc-pool.h b/gcc/alloc-pool.h
index 4af926dcff1..d3208100316 100644
--- a/gcc/alloc-pool.h
+++ b/gcc/alloc-pool.h
@@ -83,17 +83,14 @@ struct pool_usage: public mem_usage
   {
 fprintf (stderr, "%-32s%-48s %6s%11s%16s%17s%12s\n", "Pool name", name,
 	 "Pools", "Leak", "Peak", "Times", "Elt size");
-print_dash_line ();
   }
 
   /* Dump footer.  */
   inline void
   dump_footer ()
   {
-print_dash_line ();
 fprintf (stderr, "%s" PRsa(82) PRsa(10) "\n", "Total",
 	 SIZE_AMOUNT (m_instances), SIZE_AMOUNT (m_allocated));
-print_dash_line ();
   }
 
   /* Element size.  */
diff --git a/gcc/bitmap.h b/gcc/bitmap.h
index 11c75e9ef69..ed25c1ee5da 100644
--- a/gcc/bitmap.h
+++ b/gcc/bitmap.h
@@ -258,7 +258,6 @@ struct bitmap_usage: public mem_usage
   {
 fprintf (stderr, "%-48s %11s%16s%17s%12s%12s%10s\n", name, "Leak", "Peak",
 	 "Times", "N searches", "Search iter", "Type");
-print_dash_line ();
   }
 
   /* Number search operations.  */
diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index 9a12fad5838..0d1e5bf2bf5 100644
--- a/gcc/ggc-common.c
+++ b/gcc/ggc-common.c
@@ -910,9 +910,7 @@ struct ggc_usage: public mem_usage
   inline void
   dump_footer ()
   {
-print_dash_line ();
 dump ("Total", *this);
-print_dash_line ();
   }
 
   /* Get balance which is GGC allocation leak.  */
@@ -955,7 +953,6 @@ struct ggc_usage: public mem_usage
   {
 fprintf (stderr, "%-48s %11s%17s%17s%16s%17s\n", name, "Garbage", "Freed",
 	 "Leak", "Overhead", "Times");
-print_dash_line ();
   }
 
   /* Freed memory in bytes.  */
diff --git a/gcc/mem-stats.h b/gcc/mem-stats.h
index cbc328f4b3d..7612e7de3d2 100644
--- a/gcc/mem-stats.h
+++ b/gcc/mem-stats.h
@@ -219,10 +219,8 @@ struct mem_usage
   inline void
   dump_footer () const
   {
-print_dash_line ();
 fprintf (stderr, "%s" PRsa (53) PRsa (26) "\n", "Total",
 	 SIZE_AMOUNT (m_allocated), SIZE_AMOUNT (m_times));
-print_dash_line ();
   }
 
   /* Return fraction of NOMINATOR and DENOMINATOR in percent.  */
@@ -247,7 +245,6 @@ struct mem_usage
   {
 fprintf (stderr, "%-48s %11s%16s%10s%17s\n", name, "Leak", "Peak",
 	 "Times", "Type");
-print_dash_line ();
   }
 
   /* Current number of allocated bytes.  */
@@ -631,11 +628,17 @@ mem_alloc_description::dump (mem_alloc_origin origin,
   mem_list_t *list = get_list (origin, , cmp);
   T total = get_sum (origin);
 
+  T::print_dash_line ();
   T::dump_header (mem_location::get_origin_name (origin));
+  T::print_dash_line ();
   for (int i = length - 1; i >= 0; i--)
 list[i].second->dump (list[i].first, total);
+  T::print_dash_line ();
 
+  T::dump_header (mem_location::get_origin_name (origin));
+  T::print_dash_line ();
   total.dump_footer ();
+  T::print_dash_line ();
 
   XDELETEVEC (list);
 
diff --git a/gcc/tree-phinodes.c b/gcc/tree-phinodes.c
index 54e1452e80c..d062f4e36f6 100644
--- a/gcc/tree-phinodes.c
+++ b/gcc/tree-phinodes.c
@@ -80,9 +80,9 @@ unsigned int phi_nodes_created;
 void
 phinodes_print_statistics (void)
 {
-  fprintf (stderr, "PHI nodes allocated: " PRsa (11) "\n",
+  fprintf (stderr, "%-32s" PRsa (11) "\n", "PHI nodes allocated:",
 	   SIZE_AMOUNT (phi_nodes_created));
-  fprintf (stderr, "PHI nodes reused: " PRsa (11) "\n",
+  fprintf (stderr, "%-32s" PRsa (11) "\n", "PHI nodes reused:",
 	   SIZE_AMOUNT (phi_nodes_reused));
 }
 
diff --git a/gcc/tree-ssanames.c b/gcc/tree-ssanames.c
index 51f52bb5bd3..c457334bb31 100644
--- a/gcc/tree-ssanames.c
+++ b/gcc/tree-ssanames.c
@@ -112,9 +112,9 @@ 

[PATCH] Remove a legacy lto-symtab.c file.

[Martin Liška]

Hi.

It's a legacy file that is out of current build system. I tried
to fix compilation errors, but it crashes early after start.

May I remove the file?
Thanks,
Martin

lto-plugin/ChangeLog:

2019-02-26  Martin Liska  

* lto-symtab.c: Remove.
---
 lto-plugin/lto-symtab.c | 359 
 1 file changed, 359 deletions(-)
 delete mode 100644 lto-plugin/lto-symtab.c


diff --git a/lto-plugin/lto-symtab.c b/lto-plugin/lto-symtab.c
deleted file mode 100644
index 22b3af6027b..000
--- a/lto-plugin/lto-symtab.c
+++ /dev/null
@@ -1,359 +0,0 @@
-/* Program to read the IL symbol table.
-   Copyright (C) 2008-2019 Free Software Foundation, Inc.
-   Contributed by Rafael Avila de Espindola (espind...@google.com).
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.  */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "plugin-api.h"
-#include "../gcc/lto/common.h"
-
-/* The presence of gelf.h is checked by the toplevel configure script.  */
-# include 
-
-static ld_plugin_claim_file_handler claim_file_handler;
-static ld_plugin_all_symbols_read_handler all_symbols_read_handler;
-static ld_plugin_cleanup_handler cleanup_handler;
-static void *plugin_handle;
-
-struct file_handle {
-  unsigned nsyms;
-  struct ld_plugin_symbol *syms;
-};
-
-static struct file_handle **all_file_handles = NULL;
-static unsigned int num_file_handles;
-
-/* Write NSYMS symbols from file HANDLE in SYMS. */
-
-static enum ld_plugin_status
-get_symbols (const void *handle, int nsyms, struct ld_plugin_symbol *syms)
-{
-  unsigned i;
-  struct file_handle *h = (struct file_handle *) handle;
-  assert (h->nsyms == nsyms);
-
-  for (i = 0; i < nsyms; i++)
-syms[i] = h->syms[i];
-
-  return LDPS_OK;
-}
-
-/* Register HANDLER as the callback for notifying the plugin that all symbols
-   have been read. */
-
-static enum ld_plugin_status
-register_all_symbols_read (ld_plugin_all_symbols_read_handler handler)
-{
-  all_symbols_read_handler = handler;
-  return LDPS_OK;
-}
-
-/* Register HANDLER as the callback for claiming a file. */
-
-static enum ld_plugin_status
-register_claim_file(ld_plugin_claim_file_handler handler)
-{
-  claim_file_handler = handler;
-  return LDPS_OK;
-}
-
-/* Register HANDLER as the callback to removing temporary files. */
-
-static enum ld_plugin_status
-register_cleanup (ld_plugin_cleanup_handler handler)
-{
-  cleanup_handler = handler;
-  return LDPS_OK;
-}
-
-/* For a file identified by HANDLE, add NSYMS symbols from SYMS. */
-
-static enum ld_plugin_status
-add_symbols (void *handle, int nsyms,
-	 const struct ld_plugin_symbol *syms)
-{
-  int i;
-  struct file_handle *h = (struct file_handle *) handle;
-  h->nsyms = nsyms;
-  h->syms = calloc (nsyms, sizeof (struct ld_plugin_symbol));
-  assert (h->syms);
-
-  for (i = 0; i < nsyms; i++)
-{
-  h->syms[i] = syms[i];
-  h->syms[i].name = strdup (h->syms[i].name);
-  if (h->syms[i].version)
-	h->syms[i].version = strdup (h->syms[i].version);
-  if (h->syms[i].comdat_key)
-	h->syms[i].comdat_key = strdup (h->syms[i].comdat_key);
-}
-
-  return LDPS_OK;
-}
-
-struct ld_plugin_tv tv[] = {
-  {LDPT_REGISTER_CLAIM_FILE_HOOK,
-   {.tv_register_claim_file = register_claim_file}
-  },
-  {LDPT_ADD_SYMBOLS,
-   {.tv_add_symbols = add_symbols}
-  },
-
-  {LDPT_REGISTER_ALL_SYMBOLS_READ_HOOK,
-   {.tv_register_all_symbols_read = register_all_symbols_read}
-  },
-  {LDPT_GET_SYMBOLS,
-   {.tv_get_symbols = get_symbols}
-  },
-  {LDPT_REGISTER_CLEANUP_HOOK,
-   {.tv_register_cleanup = register_cleanup}
-  },
-  {0, {0}}
-};
-
-/* Load a plugin from a file named NAME. */
-
-static void
-load_plugin (const char *name)
-{
-  ld_plugin_onload onload;
-  plugin_handle = dlopen (name, RTLD_LAZY);
-
-  assert (plugin_handle != NULL);
-  onload = dlsym (plugin_handle, "onload");
-  assert (onload);
-  onload (tv);
-  assert (claim_file_handler);
-}
-
-/* Send object to the plugin. The file (archive or object) name is NAME.
-   FD is an open file descriptor. The object data starts at OFFSET and is
-   FILESIZE bytes long. */
-
-static void
-register_object (const char *name, int fd, off_t offset, off_t filesize)
-{
-  int claimed;
-  struct ld_plugin_input_file file;
-  void *handle;
-
-  num_file_handles++;
-  all_file_handles = realloc 

[PATCH] Fix PR89505

[Richard Biener]

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk 
sofar.

Richard.

2019-02-26  Richard Biener  

PR tree-optimization/89505
* tree-ssa-structalias.c (compute_dependence_clique): Make sure
to handle restrict pointed-to vars with multiple subvars
correctly.

* gcc.dg/torture/pr89505.c: New testcase.

Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c  (revision 269205)
+++ gcc/tree-ssa-structalias.c  (working copy)
@@ -7613,7 +7613,10 @@ compute_dependence_clique (void)
  maybe_set_dependence_info);
  if (used)
{
- bitmap_set_bit (rvars, restrict_var->id);
+ /* Add all subvars to the set of restrict pointed-to set. */
+ for (unsigned sv = restrict_var->head; sv != 0;
+  sv = get_varinfo (sv)->next)
+   bitmap_set_bit (rvars, sv);
  varinfo_t escaped = get_varinfo (find (escaped_id));
  if (bitmap_bit_p (escaped->solution, restrict_var->id))
escaped_p = true;
Index: gcc/testsuite/gcc.dg/torture/pr89505.c
===
--- gcc/testsuite/gcc.dg/torture/pr89505.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr89505.c  (working copy)
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+
+struct S { int i; void *p; int j; };
+int a;
+int __attribute__((noinline))
+foo (struct S * __restrict p, int q)
+{
+  int *x = >j;
+  if (q)
+x = 
+  p->j = 1;
+  *x = 2;
+  return p->j;
+}
+
+int main()
+{
+  struct S s;
+  if (foo (, 0) != 2)
+__builtin_abort ();
+  return 0;
+}

Re: [PATCH] Fix up strnlen handling in tree-ssa-strlen.c (PR tree-optimization/89500, take 2)

[Richard Biener]

On Tue, 26 Feb 2019, Jakub Jelinek wrote:

> On Mon, Feb 25, 2019 at 04:55:56PM -0700, Martin Sebor wrote:
> > Storing the strnlen result is intentional when it equals strlen.
> 
> For the *si update, you never want to do that for strnlen.
> And for the strlen_to_stridx, while I don't think it is that important,
> here is an updated patch that handles it, plus it handles strnlen (x, 0)
> even if we don't know anything about x and handles strnlen (p, cst)
> even if we know the first cst bytes are non-zero, but don't know anything
> about zero termination.
> 
> Ok for trunk if it passes bootstrap/regtest?

OK.

Richard.

> 2019-02-26  Jakub Jelinek  
> 
>   PR tree-optimization/89500
>   * tree-ssa-strlen.c (stridx_strlenloc): Adjust comment.
>   (handle_builtin_strlen): Remove noncst_bound variable.  Always
>   optimize strnlen (x, 0) to 0.  Optimize strnlen (x, cst) to
>   cst if the first cst bytes starting at x are known to be non-zero,
>   even if the string is not zero terminated.  Don't try to modify
>   *si for strnlen.  Update strlen_to_stridx only for strlen or if
>   we can prove strnlen returns the same value as strlen would.
> 
>   * gcc.dg/pr89500.c: New test.
>   * gcc.dg/Wstringop-overflow-10.c: New test.
>   * gcc.dg/strlenopt-60.c: New test.
> 
> --- gcc/tree-ssa-strlen.c.jj  2019-02-25 23:56:55.033106702 +0100
> +++ gcc/tree-ssa-strlen.c 2019-02-26 13:53:35.163161757 +0100
> @@ -156,7 +156,8 @@ struct decl_stridxlist_map
> mappings.  */
>  static hash_map *decl_to_stridxlist_htab;
>  
> -/* Hash table mapping strlen calls to stridx instances describing
> +/* Hash table mapping strlen (or strnlen with constant bound and return
> +   smaller than bound) calls to stridx instances describing
> the calls' arguments.  Non-null only when warn_stringop_truncation
> is non-zero.  */
>  typedef std::pair stridx_strlenloc;
> @@ -1269,19 +1270,33 @@ handle_builtin_strlen (gimple_stmt_itera
>tree bound = (DECL_FUNCTION_CODE (callee) == BUILT_IN_STRNLEN
>   ? gimple_call_arg (stmt, 1) : NULL_TREE);
>int idx = get_stridx (src);
> -  if (idx)
> +  if (idx || (bound && integer_zerop (bound)))
>  {
>strinfo *si = NULL;
>tree rhs;
>  
>if (idx < 0)
>   rhs = build_int_cst (TREE_TYPE (lhs), ~idx);
> +  else if (idx == 0)
> + rhs = bound;
>else
>   {
> rhs = NULL_TREE;
> si = get_strinfo (idx);
> if (si != NULL)
> - rhs = get_string_length (si);
> + {
> +   rhs = get_string_length (si);
> +   /* For strnlen, if bound is constant, even if si is not known
> +  to be zero terminated, if we know at least bound bytes are
> +  not zero, the return value will be bound.  */
> +   if (rhs == NULL_TREE
> +   && bound != NULL_TREE
> +   && TREE_CODE (bound) == INTEGER_CST
> +   && si->nonzero_chars != NULL_TREE
> +   && TREE_CODE (si->nonzero_chars) == INTEGER_CST
> +   && tree_int_cst_le (bound, si->nonzero_chars))
> + rhs = bound;
> + }
>   }
>if (rhs != NULL_TREE)
>   {
> @@ -1294,18 +1309,8 @@ handle_builtin_strlen (gimple_stmt_itera
> if (!useless_type_conversion_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
>   rhs = fold_convert_loc (loc, TREE_TYPE (lhs), rhs);
>  
> -   /* Set for strnlen() calls with a non-constant bound.  */
> -   bool noncst_bound = false;
> if (bound)
> - {
> -   tree new_rhs
> - = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (rhs), rhs, bound);
> -
> -   noncst_bound = (TREE_CODE (new_rhs) != INTEGER_CST
> -   || tree_int_cst_lt (new_rhs, rhs));
> -
> -   rhs = new_rhs;
> - }
> + rhs = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (rhs), rhs, bound);
>  
> if (!update_call_from_tree (gsi, rhs))
>   gimplify_and_update_call_from_tree (gsi, rhs);
> @@ -1317,12 +1322,9 @@ handle_builtin_strlen (gimple_stmt_itera
> print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
>   }
>  
> -   /* Avoid storing the length for calls to strnlen() with
> -  a non-constant bound.  */
> -   if (noncst_bound)
> - return;
> -
> if (si != NULL
> +   /* Don't update anything for strnlen.  */
> +   && bound == NULL_TREE
> && TREE_CODE (si->nonzero_chars) != SSA_NAME
> && TREE_CODE (si->nonzero_chars) != INTEGER_CST
> && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
> @@ -1332,7 +1334,13 @@ handle_builtin_strlen (gimple_stmt_itera
> gcc_assert (si->full_string_p);
>   }
>  
> -   if (strlen_to_stridx)
> +   if (strlen_to_stridx
> +   && (bound == NULL_TREE
> +   /* For strnlen record this only if the call is proven
> +  to return the 

Re: [PATCH, OpenACC, libgomp, v6, stage1] Async-rework update

[Thomas Schwinge]

Hi Chung-Lin!

On Tue, 26 Feb 2019 01:49:09 +0800, Chung-Lin Tang  
wrote:
> I have incorporated all your patches you've included in the last mail (with
> some modifications, though pretty minor I think).

OK, thanks, that's good for next GCC development stage 1 as far as I'm
concerned, and Tom has already approved the libgomp 'nvptx' plugin
changes, and I suppose you've addressed Jakub's requests -- so you're
good to go!  :-)


> The default_async, GOMP_PLUGIN_IF_VERSION, and testsuite changes have all 
> been removed.
> We can work on them later as we clarify more things.

ACK, and likewise also for the remaining "TODO" items (either comments in
the source code, or as discussed in email), once we reach clarification
about these.


As I mentioned before, the 'GOMP_PLUGIN_IF_VERSION' changes could go into
trunk right now, given they boil down to just a documentation update.
(And the value then incremented as part of the "async re-work" commit;
pre-approved.)


Grüße
 Thomas


> Index: libgomp/oacc-async.c
> ===
> --- libgomp/oacc-async.c  (revision 269183)
> +++ libgomp/oacc-async.c  (working copy)
> @@ -27,49 +27,162 @@
> .  */
>  
>  #include 
> +#include 
>  #include "openacc.h"
>  #include "libgomp.h"
>  #include "oacc-int.h"
>  
> -int
> -acc_async_test (int async)
> +static struct goacc_thread *
> +get_goacc_thread (void)
>  {
> -  if (!async_valid_p (async))
> -gomp_fatal ("invalid async argument: %d", async);
> -
>struct goacc_thread *thr = goacc_thread ();
>  
>if (!thr || !thr->dev)
>  gomp_fatal ("no device active");
>  
> -  return thr->dev->openacc.async_test_func (async);
> +  return thr;
>  }
>  
> -int
> -acc_async_test_all (void)
> +static struct gomp_device_descr *
> +get_goacc_thread_device (void)
>  {
>struct goacc_thread *thr = goacc_thread ();
>  
>if (!thr || !thr->dev)
>  gomp_fatal ("no device active");
>  
> -  return thr->dev->openacc.async_test_all_func ();
> +  return thr->dev;
>  }
>  
> -void
> -acc_wait (int async)
> +static int
> +validate_async_val (int async)
>  {
>if (!async_valid_p (async))
> -gomp_fatal ("invalid async argument: %d", async);
> +gomp_fatal ("invalid async-argument: %d", async);
>  
> +  if (async == acc_async_sync)
> +return -1;
> +
> +  if (async == acc_async_noval)
> +return 0;
> +
> +  if (async >= 0)
> +/* TODO: we reserve 0 for acc_async_noval before we can clarify the
> +   semantics of "default_async".  */
> +return 1 + async;
> +  else
> +__builtin_unreachable ();
> +}
> +
> +/* Return the asyncqueue to be used for OpenACC async-argument ASYNC.  This
> +   might return NULL if no asyncqueue is to be used.  Otherwise, if CREATE,
> +   create the asyncqueue if it doesn't exist yet.  */
> +
> +attribute_hidden struct goacc_asyncqueue *
> +lookup_goacc_asyncqueue (struct goacc_thread *thr, bool create, int async)
> +{
> +  async = validate_async_val (async);
> +  if (async < 0)
> +return NULL;
> +
> +  struct goacc_asyncqueue *ret_aq = NULL;
> +  struct gomp_device_descr *dev = thr->dev;
> +
> +  gomp_mutex_lock (>openacc.async.lock);
> +
> +  if (!create
> +  && (async >= dev->openacc.async.nasyncqueue
> +   || !dev->openacc.async.asyncqueue[async]))
> +goto end;
> +
> +  if (async >= dev->openacc.async.nasyncqueue)
> +{
> +  int diff = async + 1 - dev->openacc.async.nasyncqueue;
> +  dev->openacc.async.asyncqueue
> + = gomp_realloc (dev->openacc.async.asyncqueue,
> + sizeof (goacc_aq) * (async + 1));
> +  memset (dev->openacc.async.asyncqueue + dev->openacc.async.nasyncqueue,
> +   0, sizeof (goacc_aq) * diff);
> +  dev->openacc.async.nasyncqueue = async + 1;
> +}
> +
> +  if (!dev->openacc.async.asyncqueue[async])
> +{
> +  dev->openacc.async.asyncqueue[async] = 
> dev->openacc.async.construct_func ();
> +
> +  if (!dev->openacc.async.asyncqueue[async])
> + {
> +   gomp_mutex_unlock (>openacc.async.lock);
> +   gomp_fatal ("async %d creation failed", async);
> + }
> +  
> +  /* Link new async queue into active list.  */
> +  goacc_aq_list n = gomp_malloc (sizeof (struct goacc_asyncqueue_list));
> +  n->aq = dev->openacc.async.asyncqueue[async];
> +  n->next = dev->openacc.async.active;
> +  dev->openacc.async.active = n;
> +}
> +
> +  ret_aq = dev->openacc.async.asyncqueue[async];
> +
> + end:
> +  gomp_mutex_unlock (>openacc.async.lock);
> +  return ret_aq;
> +}
> +
> +/* Return the asyncqueue to be used for OpenACC async-argument ASYNC.  This
> +   might return NULL if no asyncqueue is to be used.  Otherwise, create the
> +   asyncqueue if it doesn't exist yet.  */
> +
> +attribute_hidden struct goacc_asyncqueue *
> +get_goacc_asyncqueue (int async)
> +{
> +  struct goacc_thread *thr = get_goacc_thread ();
> +  return lookup_goacc_asyncqueue (thr, 

Re: [PATCH] improve performance of std::allocator::deallocate

[Jonathan Wakely]

On 23/02/19 02:04 +, Pádraig Brady wrote:

Attached is a simple patch which has been extensively tested within
Facebook,
and is enabled by default in our code base.

Passing the size to the allocator allows it to optimize deallocation,
and this was seen to significantly reduce the work required in jemalloc,
with about 40% reduction in CPU cycles in the free path.


Thanks, the patch looks good.

I would prefer to only change the function body, as otherwise LTO
sometimes produces link-time warnings about ODR violations, because
the same function is defined on two different lines. The ODR detection
heuristics aren't smart enough to complain when the function
declarator is always defined on the same line, but with two different
function bodies.

i.e. define it as:

 // __p is not permitted to be a null pointer.
 void
 deallocate(pointer __p,
size_type __t __attribute__((__unused__)))
 {
#if __cpp_sized_deallocation
   // ...
#else
   // ..
#endif
 }

Or to reduce the duplication, maybe:

 // __p is not permitted to be a null pointer.
 void
 deallocate(pointer __p, size_type __t)
 {
#if __cpp_aligned_new
if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
  {
::operator delete(__p,
#if __cpp_sized_deallocation
  __t * sizeof(_Tp),
#endif
  std::align_val_t(alignof(_Tp)));
return;
  }
#endif
::operator delete(__p
#if __cpp_sized_deallocation
  , __t * sizeof(_Tp)
#endif
   );
 }



Note jemalloc >= 5.1 is required to fix a bug with 0 sizes.


How serious is the bug? What are the symptoms?

It looks like 5.1.0 is less than a year old, so older versions are
presumably still in wide use.

We could potentially workaround it by making
new_allocator::allocate(0) call ::operator new(1) when
__cpp_sized_deallocation is defined, and deallocate(p, 0) call
::operator delete(p, 1). Obviously I'd prefer not to do that, because
the default operator new already has an equivalent check, and only
programs linking to jemalloc require the workaround.

Re: [wwwdocs, doc] List -Wabsolute-value in gcc-9/changes.html

[Martin Jambor]

Hi,

On Wed, Feb 13 2019, Martin Jambor wrote:
> Hi Gerald and Martin,
>
> On Mon, Jan 28 2019, Gerald Pfeifer wrote:
>> Hi Martin,
>>
>> On Sat, 26 Jan 2019, Martin Jambor wrote:
 What is a "wrong absolute value function"?  That might be good to
 show by means of an example?  (Also in invoke.texi, which I checked
 before writing this.)
>>> I'm not sure how to change the wording, perhaps "...when a used absolute
>>> value function seems wrong for the type of its argument" ...?
>>
>> yes, that definitely would have helped me as a user.  (I guessed
>> it might be that, but seeing it in writing helps.)
>>
>> On Mon, 28 Jan 2019, Martin Sebor wrote:
>>>   -Wabsolute-value warns for calls to standard functions that compute
>>>   the absolute value of an argument when a more appropriate standard
>>>   function is available.  For example, calling abs(3.14) triggers
>>>   the warning because the appropriate function to call to compute
>>>   the absolute value of a double argument is fabs.  The option also
>>>   triggers warnings when the argument in a call to such a function
>>>   has an unsigned type.
>>
>> Lovely.  
>>
>> (I'd say "This option...", but that's probably a matter of taste.)
>>
>> Are you going to enhance both invoke.texi and apply a patch to the
>> release notes (changes.html)?  That would be ideal.
>>
>
> I have incorporated Martin's extended description to both invoke.texi
> and changes.html, the result is in the two patches below.  OK to commit
> to trunk and to wwwdocs CVS repo respectively?

Since it is documentation only and because the change was basically
pre-approved by Gerald, I plan to commit both later today (unless
someone stops me).  I hope I'm not stretching the rules too much.

Martin

>
>
> diff -u -r1.38 changes.html
> --- htdocs/gcc-9/changes.html   7 Feb 2019 11:49:26 -   1.38
> +++ htdocs/gcc-9/changes.html   13 Feb 2019 17:38:57 -
> @@ -89,6 +89,23 @@
>
>  
>  
> +C
> +
> +  New warnings:
> +  
> +-Wabsolute-value warns for calls to standard
> +  functions that compute the absolute value of an argument when a
> +  more appropriate standard function is available.  For example,
> +  calling abs(3.14) triggers the warning because the
> +  appropriate function to call to compute the absolute value of a
> +  double argument is fabs.  The option also triggers
> +  warnings when the argument in a call to such a function has an
> +  unsigned type.  This warning can be suppressed with an explicit
> +  type cast and it is also enabled by -Wextra.
> +
> +  
> +
> +
>  C++
>  
>New warnings:
>
>
>
> 2019-02-13  Martin Jambor  
>   Martin Sebor  
>
>   * doc/invoke.texi (Warning Options): Reword description of
>   -Wno-absolute-value.
> ---
>  gcc/doc/invoke.texi | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index c625350d04d..a8bafbebce8 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -6633,9 +6633,13 @@ example, warn if an unsigned variable is compared 
> against zero with
>  @item -Wabsolute-value @r{(C and Objective-C only)}
>  @opindex Wabsolute-value
>  @opindex Wno-absolute-value
> -Warn when a wrong absolute value function seems to be used or when it
> -does not have any effect because its argument is an unsigned type.
> -This warning be suppressed with an explicit type cast and it is also
> +Warn for calls to standard functions that compute the absolute value
> +of an argument when a more appropriate standard function is available.
> +For example, calling @code{abs(3.14)} triggers the warning because the
> +appropriate function to call to compute the absolute value of a double
> +argument is @code{fabs}.  The option also triggers warnings when the
> +argument in a call to such a function has an unsigned type.  This
> +warning can be suppressed with an explicit type cast and it is also
>  enabled by @option{-Wextra}.
>  
>  @include cppwarnopts.texi
> -- 
> 2.20.1

[PATCH] Fix up strnlen handling in tree-ssa-strlen.c (PR tree-optimization/89500, take 2)

[Jakub Jelinek]

On Mon, Feb 25, 2019 at 04:55:56PM -0700, Martin Sebor wrote:
> Storing the strnlen result is intentional when it equals strlen.

For the *si update, you never want to do that for strnlen.
And for the strlen_to_stridx, while I don't think it is that important,
here is an updated patch that handles it, plus it handles strnlen (x, 0)
even if we don't know anything about x and handles strnlen (p, cst)
even if we know the first cst bytes are non-zero, but don't know anything
about zero termination.

Ok for trunk if it passes bootstrap/regtest?

2019-02-26  Jakub Jelinek  

PR tree-optimization/89500
* tree-ssa-strlen.c (stridx_strlenloc): Adjust comment.
(handle_builtin_strlen): Remove noncst_bound variable.  Always
optimize strnlen (x, 0) to 0.  Optimize strnlen (x, cst) to
cst if the first cst bytes starting at x are known to be non-zero,
even if the string is not zero terminated.  Don't try to modify
*si for strnlen.  Update strlen_to_stridx only for strlen or if
we can prove strnlen returns the same value as strlen would.

* gcc.dg/pr89500.c: New test.
* gcc.dg/Wstringop-overflow-10.c: New test.
* gcc.dg/strlenopt-60.c: New test.

--- gcc/tree-ssa-strlen.c.jj2019-02-25 23:56:55.033106702 +0100
+++ gcc/tree-ssa-strlen.c   2019-02-26 13:53:35.163161757 +0100
@@ -156,7 +156,8 @@ struct decl_stridxlist_map
mappings.  */
 static hash_map *decl_to_stridxlist_htab;
 
-/* Hash table mapping strlen calls to stridx instances describing
+/* Hash table mapping strlen (or strnlen with constant bound and return
+   smaller than bound) calls to stridx instances describing
the calls' arguments.  Non-null only when warn_stringop_truncation
is non-zero.  */
 typedef std::pair stridx_strlenloc;
@@ -1269,19 +1270,33 @@ handle_builtin_strlen (gimple_stmt_itera
   tree bound = (DECL_FUNCTION_CODE (callee) == BUILT_IN_STRNLEN
? gimple_call_arg (stmt, 1) : NULL_TREE);
   int idx = get_stridx (src);
-  if (idx)
+  if (idx || (bound && integer_zerop (bound)))
 {
   strinfo *si = NULL;
   tree rhs;
 
   if (idx < 0)
rhs = build_int_cst (TREE_TYPE (lhs), ~idx);
+  else if (idx == 0)
+   rhs = bound;
   else
{
  rhs = NULL_TREE;
  si = get_strinfo (idx);
  if (si != NULL)
-   rhs = get_string_length (si);
+   {
+ rhs = get_string_length (si);
+ /* For strnlen, if bound is constant, even if si is not known
+to be zero terminated, if we know at least bound bytes are
+not zero, the return value will be bound.  */
+ if (rhs == NULL_TREE
+ && bound != NULL_TREE
+ && TREE_CODE (bound) == INTEGER_CST
+ && si->nonzero_chars != NULL_TREE
+ && TREE_CODE (si->nonzero_chars) == INTEGER_CST
+ && tree_int_cst_le (bound, si->nonzero_chars))
+   rhs = bound;
+   }
}
   if (rhs != NULL_TREE)
{
@@ -1294,18 +1309,8 @@ handle_builtin_strlen (gimple_stmt_itera
  if (!useless_type_conversion_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
rhs = fold_convert_loc (loc, TREE_TYPE (lhs), rhs);
 
- /* Set for strnlen() calls with a non-constant bound.  */
- bool noncst_bound = false;
  if (bound)
-   {
- tree new_rhs
-   = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (rhs), rhs, bound);
-
- noncst_bound = (TREE_CODE (new_rhs) != INTEGER_CST
- || tree_int_cst_lt (new_rhs, rhs));
-
- rhs = new_rhs;
-   }
+   rhs = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (rhs), rhs, bound);
 
  if (!update_call_from_tree (gsi, rhs))
gimplify_and_update_call_from_tree (gsi, rhs);
@@ -1317,12 +1322,9 @@ handle_builtin_strlen (gimple_stmt_itera
  print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
}
 
- /* Avoid storing the length for calls to strnlen() with
-a non-constant bound.  */
- if (noncst_bound)
-   return;
-
  if (si != NULL
+ /* Don't update anything for strnlen.  */
+ && bound == NULL_TREE
  && TREE_CODE (si->nonzero_chars) != SSA_NAME
  && TREE_CODE (si->nonzero_chars) != INTEGER_CST
  && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
@@ -1332,7 +1334,13 @@ handle_builtin_strlen (gimple_stmt_itera
  gcc_assert (si->full_string_p);
}
 
- if (strlen_to_stridx)
+ if (strlen_to_stridx
+ && (bound == NULL_TREE
+ /* For strnlen record this only if the call is proven
+to return the same value as strlen would.  */
+ || (TREE_CODE (bound) == INTEGER_CST
+ && TREE_CODE (rhs) == INTEGER_CST
+ 

Re: [PATCH][libbacktrace] Add btest_lto

[Thomas Schwinge]

Hi Tom!

On Tue, 26 Feb 2019 12:28:34 +0100, Tom de Vries  wrote:
> On 26-02-19 10:40, Thomas Schwinge wrote:
> > On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries  wrote:
> >> On 25-02-19 11:48, Thomas Schwinge wrote:
> >>> On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries  wrote:
>  Add libbacktrace test-case using -flto.
> >>>
> >>> I'm seeing this one fail is some configurations, but only in the
> >>> 'build-gcc/libbacktrace/btest_lto.log' variant:
> > 
> >> Meaning, compiling libbacktrace using the host compiler, so it would be
> >> useful to known which compiler that is.
> >>
> >> [ I've tried a gcc-4.8 and gcc-6 and gcc-7 as host compiler, and a
> >> couple of CFLAGS settings (-O2, -O3) to reproduce this, but didn't manage. 
> >> ]
> > 
> > Years old:
> > 
> > $ gcc --version
> > gcc (Sourcery CodeBench 2014.05-45) 4.8.3 20140320 (prerelease)
> > [...]
> > $ ld --version
> > GNU ld (Sourcery CodeBench 2014.05-45) 2.24.51.20140217
> > [...]
> > 
> > (It'll be fine for me if you just declare that unsupported.)
> 
> I see. The 4.8 I tried is a 4.8.5.
> 
> >>> test5: unexpected syminfo name got global.2537 expected global
> >>> PASS: backtrace_full noinline
> >>> PASS: backtrace_full inline
> >>> PASS: backtrace_simple noinline
> >>> PASS: backtrace_simple inline
> >>> FAIL: backtrace_syminfo variable
> >>> FAIL btest_lto (exit status: 1)
> >>>
> >>> I haven't looked yet which details about these GCC build configurations
> >>> might be different/important; maybe you've got an idea already?
> > 
> > I can reproduce this with '-O0' ("unexpected syminfo name got global.2528
> > expected global", in that case).  With '-O0 -fdump-tree-all
> > -fdump-ipa-all -save-temps', the 'global.2528' name appears only in
> > 'btest_lto.ltrans0.000i.cgraph', and 'btest_lto.ltrans0.s':
> > 
> > ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> > (addr)state.2526/56 (read)callback_three.2389/64 
> > (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> > (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> > (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> > (write)failures.2527/57 (read)
> > ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> > ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> > ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> > (addr)state.2526/56 (read)callback_three.2389/64 
> > (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> > (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> > (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> > (write)failures.2527/57 (read)
> > ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> > ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> > (addr)state.2526/56 (read)callback_three.2389/64 
> > (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> > (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> > (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> > (write)failures.2527/57 (read)
> > ./btest_lto.ltrans0.s:  .type   global.2528, @object
> > ./btest_lto.ltrans0.s:  .size   global.2528, 4
> > ./btest_lto.ltrans0.s:global.2528:
> > ./btest_lto.ltrans0.s:  movq$global.2528, -8(%rbp)  #, addr
> > ./btest_lto.ltrans0.s:  movl$global.2528, %eax  #, global.22
> > ./btest_lto.ltrans0.s:  movl$global.2528, %ecx  #, global.23
> > ./btest_lto.ltrans0.s:  .quad   global.2528

With '-fdump-rtl-all' added, I see it appear in
'btest_lto.ltrans0.166r.expand':

./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
[flags 0x2]  )) [...]/libbacktrace/btest.c:399 -1
./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
[flags 0x2]  )) [...]/libbacktrace/btest.c:433 -1
./btest_lto.ltrans0.166r.expand:(symbol_ref:DI ("global.2528") 
[flags 0x2]  )) [...]/libbacktrace/btest.c:435 -1

> How about:
> ...
> - int global;
> + static int global;
> ...
> 
> Does that fix the failure?

No, that gets us "unexpected syminfo name got global.2479.2528 expected
global".  ;-\


Grüße
 Thomas

Re: [PATCH][libbacktrace] Add btest_lto

[Tom de Vries]

On 26-02-19 10:40, Thomas Schwinge wrote:
> Hi Tom!
> 
> On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries  wrote:
>> On 25-02-19 11:48, Thomas Schwinge wrote:
>>> On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries  wrote:
 Add libbacktrace test-case using -flto.
>>>
>>> I'm seeing this one fail is some configurations, but only in the
>>> 'build-gcc/libbacktrace/btest_lto.log' variant:
> 
>> Meaning, compiling libbacktrace using the host compiler, so it would be
>> useful to known which compiler that is.
>>
>> [ I've tried a gcc-4.8 and gcc-6 and gcc-7 as host compiler, and a
>> couple of CFLAGS settings (-O2, -O3) to reproduce this, but didn't manage. ]
> 
> Years old:
> 
> $ gcc --version
> gcc (Sourcery CodeBench 2014.05-45) 4.8.3 20140320 (prerelease)
> [...]
> $ ld --version
> GNU ld (Sourcery CodeBench 2014.05-45) 2.24.51.20140217
> [...]
> 
> (It'll be fine for me if you just declare that unsupported.)
> 

I see. The 4.8 I tried is a 4.8.5.

>>> test5: unexpected syminfo name got global.2537 expected global
>>> PASS: backtrace_full noinline
>>> PASS: backtrace_full inline
>>> PASS: backtrace_simple noinline
>>> PASS: backtrace_simple inline
>>> FAIL: backtrace_syminfo variable
>>> FAIL btest_lto (exit status: 1)
>>>
>>> I haven't looked yet which details about these GCC build configurations
>>> might be different/important; maybe you've got an idea already?
> 
> I can reproduce this with '-O0' ("unexpected syminfo name got global.2528
> expected global", in that case).  With '-O0 -fdump-tree-all
> -fdump-ipa-all -save-temps', the 'global.2528' name appears only in
> 'btest_lto.ltrans0.000i.cgraph', and 'btest_lto.ltrans0.s':
> 
> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> (addr)state.2526/56 (read)callback_three.2389/64 
> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> (write)failures.2527/57 (read)
> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> (addr)state.2526/56 (read)callback_three.2389/64 
> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> (write)failures.2527/57 (read)
> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> ./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
> (addr)state.2526/56 (read)callback_three.2389/64 
> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
> (write)failures.2527/57 (read)
> ./btest_lto.ltrans0.s:  .type   global.2528, @object
> ./btest_lto.ltrans0.s:  .size   global.2528, 4
> ./btest_lto.ltrans0.s:global.2528:
> ./btest_lto.ltrans0.s:  movq$global.2528, -8(%rbp)  #, addr
> ./btest_lto.ltrans0.s:  movl$global.2528, %eax  #, global.22
> ./btest_lto.ltrans0.s:  movl$global.2528, %ecx  #, global.23
> ./btest_lto.ltrans0.s:  .quad   global.2528
> 

How about:
...
- int global;
+ static int global;
...

Does that fix the failure?

Thanks,
- Tom

Re: [patch] Fix LRA/reload issue with -fnon-call-exceptions

[Eric Botcazou]

>   * rtlanal.c (get_initial_register_offset): Fall back to the raw estimate
>   as long as the epilogue isn't completed.

I have backported it onto the 8 branch, where it fixes the failure (timeout) 
of gnat.dg/opt73.adb for PowerPC/Linux, after testing it on this platform.

-- 
Eric Botcazou

[PATCH] Fix PR89489

[Richard Biener]

Boostrapped / tested on x86_64-unknown-linux-gnu, applied.

Richard.

2019-02-26  Richard Biener  

PR tree-optimization/89489
* tree-parloops.c (create_loop_fn): Copy over last_clique.

Index: gcc/tree-parloops.c
===
--- gcc/tree-parloops.c (revision 269205)
+++ gcc/tree-parloops.c (working copy)
@@ -1498,6 +1498,7 @@ create_loop_fn (location_t loc)
   DECL_ARGUMENTS (decl) = t;
 
   allocate_struct_function (decl, false);
+  DECL_STRUCT_FUNCTION (decl)->last_clique = act_cfun->last_clique;
 
   /* The call to allocate_struct_function clobbers CFUN, so we need to restore
  it.  */

Re: [PATCH][wwwdocs][AArch64/arm] Mention Neoverse N1 and Neoverse E1 support for GCC 9

[Gerald Pfeifer]

On Mon, 25 Feb 2019, Kyrill Tkachov wrote:
> Here's a wwwdocs patch mentioning the recently-added support for the Arm 
> Neoverse N1 and Neoverse E1 processors. Checked the output on Firefox.
> 
> Ok to commit (from an aarch64 perspective)?

Looks good to me, just...

> +Support has been added for the Arm Neoverse E1 processor 
> (-mcpu=neoverse-e1)

...break this long line and add a full stop at the end.

Thanks,
Gerald

[C++ Patch/RFC] PR 88987 ("[9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr")

[Paolo Carlini]

Hi,

the issue is rather easy to explain: after Alexandre' change  in 
r266874, which simplified the condition at the beginning of 
build_noexcept_spec to evaluate early all the expressions which aren't 
deferred or value-dependent, we obviously ICE during error-recovery on 
the new testcase because an expression which isn't a potential constant 
filters through and cxx_constant_value can't handle it.  We can avoid 
this in various ways - for example by adding a gate && 
potential_rvalue_constant_expression_p (expr) in the condition at the 
beginning of build_noexcept_spec and adjust/remove the final gcc_assert 
(which is already a bit obsolete wrt Alexandre' change). Or we can 
handle this earlier, in cp_parser_noexcept_specification_opt - in 
complete analogy, with, say, cp_parser_initializer_list - thus don't let 
through those expressions at all (possible variant: set expr = 
error_mark_node), which has the advantage of avoiding a duplicate 
potential_rvalue_constant_expression call (note: in the parser 
build_no_except_spec is called only by cp_parser_noexcept_specification_opt)


All those variants pass the testsuite on x86_64-linux.

Thanks, Paolo.



Index: cp/parser.c
===
--- cp/parser.c (revision 269187)
+++ cp/parser.c (working copy)
@@ -25143,7 +25143,17 @@ cp_parser_noexcept_specification_opt (cp_parser* p
  parser->type_definition_forbidden_message
  = G_("types may not be defined in an exception-specification");
 
- expr = cp_parser_constant_expression (parser);
+ bool non_constant_p;
+ expr
+   = cp_parser_constant_expression (parser,
+/*allow_non_constant=*/true,
+_constant_p);
+ if (non_constant_p
+ && !require_potential_rvalue_constant_expression (expr))
+   {
+ expr = NULL_TREE;
+ return_cond = true;
+   }
 
  /* Restore the saved message.  */
  parser->type_definition_forbidden_message = saved_message;
Index: testsuite/g++.dg/cpp0x/pr88987.C
===
--- testsuite/g++.dg/cpp0x/pr88987.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/pr88987.C(working copy)
@@ -0,0 +1,9 @@
+// { dg-do compile { target c++11 } }
+
+int sm;
+
+template  T
+pk () noexcept (sm)  // { dg-error "constant expression" }
+{
+  return 0;
+}

Re: [PATCH] Use RANGE_EXPR in Fortran array initializers some more (PR fortran/43210)

[Jakub Jelinek]

On Tue, Feb 26, 2019 at 08:37:28AM +, Paul Richard Thomas wrote:
> Your timing is astonishing. This was next on my list of TODOs - not
> for this particular PR but to deal with the rodata bloat eg. 84487. I
> presume that this patch will make the latter go away?
> 
> Yes, this is good for trunk and, if it fixes 84487, 8-branch as well.

The patch doesn't change anything on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487#c4
It is really mostly about compile time memory.  If a data section
variable is initialized with such initializer, it makes no difference in
what is emitted.  The only difference is that it is more efficient
in the compiler to handle such initializer if it is large, and if an
automatic variable is ininitialized from such CONSTRUCTOR, the gimplifier
can decide to initialize at runtime using a loop or loops rather than
using memcpy from a large .rodata initializer.

Jakub

Re: [EXT] Re: [Patch, Aarch64] Implement TARGET_GET_MULTILIB_ABI_NAME for aarch64 (for use in Fortran vector header file)

[Richard Sandiford]

Steve Ellcey  writes:
> On Wed, 2019-02-20 at 10:04 +, Richard Sandiford wrote:
>> (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector,
>> even with -msve-vector-bits=N, but it can create an ABI-level Advanced
>> SIMD vector.)
>> 
>> I think we should leave the SVE stuff out for now though.  ISTM that:
>> 
>> !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64')
>> !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve')
>> 
>> is trying to say that there's both an Advanced SIMD implementation of sin
>> and an SVE implementation of sin.  But AFAICT the patch would just treat
>> the two the same way when SVE is enabled, which I think in practice means
>> that both would declare an Advanced SIMD function.
>
> It looks like you are right.  I did not know that GCC would essentially
> use the non-SVE vector functions to handle SVE vectors. So right now,
> GCC doesn't seem to need to differentiate between SVE and non-SVE.
>
>> Once we support SVE vector functions, how would the header file declare
>> the Advanced SIMD function when SVE is enabled on the command line?
>
> I guess this is what I was thinking the aarch64_sve if would be for,
> but there is a difference between supporting SVE (using non-SVE vector
> functions) and supporting SVE with functions that can take and return
> an SVE vector.  I think that we should use 'if('aarch64_sve')' to mean
> SVE is enabled and we want GCC to call SVE vector functions.  So right
> now this would always return false, until such time as GCC is changed
> to do calls with SVE vectors as arguments.

That isn't a global decision though.  Whether we use SVE or not when
it's available depends on the context.  The ideal would be to try
both SVE and Advanced SIMD and pick whichever gives the lowest cost.
(We're hoping to do that for GCC 10.)

The header file should just declare the functions that are available.
That includes declaring SVE versions even if SVE is currently disabled,
because SVE could be enabled later using target pragmas or target_clones
attributes (one we support those).

We might want a new syntax for this.

> Given that it would always return false I guess we could just drop it
> out for now.

Yeah, agreed.  

> FYI: If anyone is interested here is a test program I was compiling to
> see what GCC does with SVE, I compiled with -march=armv8.5-a,
> -march=armv8.5-a+sve and -msve-vector-bits=[256,2048,scalable] to see
> what sort of code got generated.  I was a little surprised that using
> -march=armv8.5-a (without the +sve) and -msve-vector-bits= did not give
> a warning.  Why set sve-vector-bits if SVE is not enabled.

The idea was that -msve-vector-bits= would still affect any SVE-specific
code in a TU that contains both SVE and non-SVE code.  E.g. if you use
target_clones (again once it's supported) to provide SVE and non-SVE
versions of a function, the -msve-vector-bits= would affect the SVE
version.

I'm torn about about whether we should proactively add the ILP32 and
big-endian conditions now or wait until there's a specific need.
Unless anyone strongly objects, let's keep them for now.

Thanks,
Richard

Re: [PATCH] Fix up remove_partial_avx_dependency (PR target/89474)

[Richard Biener]

On Mon, Feb 25, 2019 at 11:53 PM Jakub Jelinek  wrote:
>
> Hi!
>
> The following patch fixes two issues in the new rpad pass.
> One is that the insertion at the start of a basic block didn't work properly
> if the basic block didn't contain any non-NOTE/non-DEBUG_INSN instructions.
> next_nonnote_nondebug_insn hapilly turns through into another basic block
> and the insertion can insert an instruction in between basic blocks or into
> a different basic block from where we wanted to emit it.
> I believe we want to emit it after CODE_LABEL, after NOTE_INSN_BASIC_BLOCK
> and if possible, after debug insns in there, the patch emits it before the
> first normal insn in the bb if any, or after the BB_END (thus extending
> BB_END).
>
> Another issue is that it is quite weird/dangerous to add the v4sf_const0
> pseudo uses in lots of places in the IL, register those changes with df,
> then do df_analyze with different flags and finally emit the setter.
> I understand the goal was not to do df_analyze etc. in the usual case where
> there are no instructions that need this treatment.  This patch does the
> df_analyze at the spot we find the first insn, but before we actually change
> that instruction, so the changes are after the df_analyze.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2019-02-25  Jakub Jelinek  
>
> PR target/89474
> * config/i386/i386.c (remove_partial_avx_dependency): Call
> df_analyze etc. before creation of the v4sf_const0 pseudo, rather than
> after changing possibly many instructions to use that pseudo.  Fix up
> insertion of v4sf_const0 setter at the start of bb.
>
> * gcc.target/i386/pr89474.c: New test.
>
> --- gcc/config/i386/i386.c.jj   2019-02-22 23:02:47.805117610 +0100
> +++ gcc/config/i386/i386.c  2019-02-25 14:20:05.793608879 +0100
> @@ -2835,7 +2835,14 @@ remove_partial_avx_dependency (void)
> continue;
>
>   if (!v4sf_const0)
> -   v4sf_const0 = gen_reg_rtx (V4SFmode);
> +   {
> + calculate_dominance_info (CDI_DOMINATORS);
> + df_set_flags (DF_DEFER_INSN_RESCAN);
> + df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
> + df_md_add_problem ();
> + df_analyze ();
> + v4sf_const0 = gen_reg_rtx (V4SFmode);
> +   }
>
>   /* Convert PARTIAL_XMM_UPDATE_TRUE insns, DF -> SF, SF -> DF,
>  SI -> SF, SI -> DF, DI -> SF, DI -> DF, to vec_dup and
> @@ -2883,12 +2890,6 @@ remove_partial_avx_dependency (void)
>
>if (v4sf_const0)
>  {
> -  calculate_dominance_info (CDI_DOMINATORS);
> -  df_set_flags (DF_DEFER_INSN_RESCAN);
> -  df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
> -  df_md_add_problem ();
> -  df_analyze ();
> -
>/* (Re-)discover loops so that bb->loop_father can be used in the
>  analysis below.  */
>loop_optimizer_init (AVOID_CFG_MODIFICATIONS);
> @@ -2904,11 +2905,23 @@ remove_partial_avx_dependency (void)
> bb = get_immediate_dominator (CDI_DOMINATORS,
>   bb->loop_father->header);
>
> -  insn = BB_HEAD (bb);
> -  if (!NONDEBUG_INSN_P (insn))
> -   insn = next_nonnote_nondebug_insn (insn);
>set = gen_rtx_SET (v4sf_const0, CONST0_RTX (V4SFmode));
> -  set_insn = emit_insn_before (set, insn);
> +
> +  insn = BB_HEAD (bb);
> +  while (insn && !NONDEBUG_INSN_P (insn))
> +   {
> + if (insn == BB_END (bb))
> +   {
> + insn = NULL;
> + break;
> +   }
> + insn = NEXT_INSN (insn);
> +   }
> +  if (insn == BB_HEAD (bb))
> +set_insn = emit_insn_before (set, insn);
> +  else
> +   set_insn = emit_insn_after (set,
> +   insn ? PREV_INSN (insn) : BB_END (bb));
>df_insn_rescan (set_insn);
>df_process_deferred_rescans ();
>loop_optimizer_finalize ();
> --- gcc/testsuite/gcc.target/i386/pr89474.c.jj  2019-02-25 14:21:51.651867104 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr89474.c 2019-02-25 14:21:34.373151405 
> +0100
> @@ -0,0 +1,14 @@
> +/* PR target/89474 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mavx" } */
> +
> +int a;
> +void foo (double);
> +int baz (void);
> +
> +void
> +bar (void)
> +{
> +  while (baz ())
> +foo (a);
> +}
>
> Jakub

Re: [patch] Fix wrong code for boolean negation in condition at -O

[Richard Biener]

On Mon, Feb 25, 2019 at 10:09 AM Eric Botcazou  wrote:
>
> Hi,
>
> this is a regression present on the mainline and 8 branch, introduced by the
> new code in edge_info::derive_equivalences dealing with BIT_AND_EXPR for SSA
> names with boolean range:
>
>   /* If either operand has a boolean range, then we
>  know its value must be one, otherwise we just know it
>  is nonzero.  The former is clearly useful, I haven't
>  seen cases where the latter is helpful yet.  */
>   if (TREE_CODE (rhs1) == SSA_NAME)
> {
>   if (ssa_name_has_boolean_range (rhs1))
> {
>   value = build_one_cst (TREE_TYPE (rhs1));
>   derive_equivalences (rhs1, value, recursion_limit - 1);
> }
> }
>   if (TREE_CODE (rhs2) == SSA_NAME)
> {
>   if (ssa_name_has_boolean_range (rhs2))
> {
>   value = build_one_cst (TREE_TYPE (rhs2));
>   derive_equivalences (rhs2, value, recursion_limit - 1);
> }
> }
>
> and visible on the attached Ada testcase at -O1 or above.
>
> The sequence of events is as follows: for boolean types with precision > 1
> (the normal boolean types in Ada), the gimplifier turns a TRUTH_NOT_EXPR into
> a BIT_XOR_EXPR with 1 in order to preserve the 0-or-1-value invariant:
>
> /* The parsers are careful to generate TRUTH_NOT_EXPR
>only with operands that are always zero or one.
>We do not fold here but handle the only interesting case
>manually, as fold may re-introduce the TRUTH_NOT_EXPR.  */
> *expr_p = gimple_boolify (*expr_p);
> if (TYPE_PRECISION (TREE_TYPE (*expr_p)) == 1)
>   *expr_p = build1_loc (input_location, BIT_NOT_EXPR,
> TREE_TYPE (*expr_p),
> TREE_OPERAND (*expr_p, 0));
> else
>   *expr_p = build2_loc (input_location, BIT_XOR_EXPR,
> TREE_TYPE (*expr_p),
> TREE_OPERAND (*expr_p, 0),
> build_int_cst (TREE_TYPE (*expr_p), 1));
>
> Now this TRUTH_NOT_EXPR is part of a conjunction which has been turned into a
> BIT_AND_EXPR by the folder, so this gives BIT_AND_EXPR >.
>
> After some optimization passes, the second operand of the BIT_AND_EXPR is also
> folded into 1 and, consequently, the following match.pd pattern kicks in:
>
> /* Fold (X & Y) ^ Y and (X ^ Y) & Y as ~X & Y.  */
> (for opo (bit_and bit_xor)
>  opi (bit_xor bit_and)
>  (simplify
>   (opo:c (opi:c @0 @1) @1)
>   (bit_and (bit_not @0) @1)))
>
> and yields BIT_AND_EXPR .  This is still correct, in the
> sense that the 0-or-1-value invariant is preserved.
>
> Then the new code in edge_info::derive_equivalences above deduces from this
> that the BIT_NOT_EXPR has value 1 on one of the edges.  But the same function
> also handles the BIT_NOT_EXPR itself and further deduces that its operand has
> value ~1 or 254 (the precision of boolean types is 8) on this edge, which
> breaks the 0-or-1-value invariant and leads to wrong code downstream.
>
> Given the new code for BIT_AND_EXPR in edge_info::derive_equivalences for
> boolean types, I think that the same special treatment must be added for
> boolean types in the BIT_NOT_EXPR case to preserve the 0-or-1-value invariant.
>
> Bootstrapped/regtested on x86_64-suse-linux, OK for mainline and 8 branch?

OK.

Richard.

>
> 2019-02-25  Eric Botcazou  
>
> * tree-ssa-dom.c (edge_info::derive_equivalences) : Fix
> and move around comment.
> : Likewise.
> : Add specific handling for boolean types.
>
>
> 2019-02-25  Eric Botcazou  
>
> * gnat.dg/opt77.adb: New test.
> * gnat.dg/opt77_pkg.ad[sb]: Likewise.
>
> --
> Eric Botcazou

Re: [PATCH] Fix a test (PR testsuite/89441).

[Martin Liška]

On 2/22/19 3:40 PM, John David Anglin wrote:
> Hi Martin,
> 
> On 2019-02-22 5:21 a.m., Martin Liška wrote:
>> Hi.
>>
>> This patch makes main not hidden (as reported in the PR).
>> John: Can you verify it fixes your problem on hppa64-hp-hpux11.11 target?
> Your patch fixed the problem on the hppa64-hp-hpux11.11 target but we also 
> need to
> require visibility support on 32-bit hppa-hpux.  See attached.

I see, thanks. Feel free to install the patch.

Martin

> 
> Dave
> 

Re: [PATCH][libbacktrace] Add btest_lto

[Thomas Schwinge]

Hi Tom!

On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries  wrote:
> On 25-02-19 11:48, Thomas Schwinge wrote:
> > On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries  wrote:
> >> Add libbacktrace test-case using -flto.
> > 
> > I'm seeing this one fail is some configurations, but only in the
> > 'build-gcc/libbacktrace/btest_lto.log' variant:

> Meaning, compiling libbacktrace using the host compiler, so it would be
> useful to known which compiler that is.
> 
> [ I've tried a gcc-4.8 and gcc-6 and gcc-7 as host compiler, and a
> couple of CFLAGS settings (-O2, -O3) to reproduce this, but didn't manage. ]

Years old:

$ gcc --version
gcc (Sourcery CodeBench 2014.05-45) 4.8.3 20140320 (prerelease)
[...]
$ ld --version
GNU ld (Sourcery CodeBench 2014.05-45) 2.24.51.20140217
[...]

(It'll be fine for me if you just declare that unsupported.)

> > test5: unexpected syminfo name got global.2537 expected global
> > PASS: backtrace_full noinline
> > PASS: backtrace_full inline
> > PASS: backtrace_simple noinline
> > PASS: backtrace_simple inline
> > FAIL: backtrace_syminfo variable
> > FAIL btest_lto (exit status: 1)
> > 
> > I haven't looked yet which details about these GCC build configurations
> > might be different/important; maybe you've got an idea already?

I can reproduce this with '-O0' ("unexpected syminfo name got global.2528
expected global", in that case).  With '-O0 -fdump-tree-all
-fdump-ipa-all -save-temps', the 'global.2528' name appears only in
'btest_lto.ltrans0.000i.cgraph', and 'btest_lto.ltrans0.s':

./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
(addr)state.2526/56 (read)callback_three.2389/64 
(addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
(read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
(read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
(write)failures.2527/57 (read)
./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
(addr)state.2526/56 (read)callback_three.2389/64 
(addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
(read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
(read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
(write)failures.2527/57 (read)
./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
./btest_lto.ltrans0.000i.cgraph:  References: global.2528/12 
(addr)state.2526/56 (read)callback_three.2389/64 
(addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20 
(read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20 
(read)stderr/20 (read)failures.2527/57 (read)failures.2527/57 
(write)failures.2527/57 (read)
./btest_lto.ltrans0.s:  .type   global.2528, @object
./btest_lto.ltrans0.s:  .size   global.2528, 4
./btest_lto.ltrans0.s:global.2528:
./btest_lto.ltrans0.s:  movq$global.2528, -8(%rbp)  #, addr
./btest_lto.ltrans0.s:  movl$global.2528, %eax  #, global.22
./btest_lto.ltrans0.s:  movl$global.2528, %ecx  #, global.23
./btest_lto.ltrans0.s:  .quad   global.2528

> Well, the backtrace_syminfo function looks at the minimal symbol info
> (so, not the dwarf info) and it seems lto has done an optimization that
> has changed the name of the variable in the minimal symbol info.
> 
> There's probably a standard way to annotate the 'global' variable to
> prevent the optimization from happening, which would fix the failure
> (but, we need to know which optimization renamed it).
> 
> OTOH, we could just limit this test to target libbacktrace only, given
> the fact that host compilers may not even support flto.


Grüße
 Thomas

Re: [PR fortran/89492, patch] - [9 Regression] Endless compilation of an invalid TRANSFER after r269177

[Dominique d'Humières]

Hi Harald,

> Rev. 269177 uncovered a latent issue in TRANSFER when the MOLD argument
> had storage size 0, resulting in an infinite loop.  The attached patch
> rejects illegal cases and handles the case where storage size of both
> SOURCE and MOLD are 0.  It also verifies proper simplification for
> some cases, some of which were not always properly handled before.

LGTM. Thanks for the quick fix.

Dominique

PS: Don’t forget to close the PRs you have fixed.

Re: [PATCH] Fix up remove_partial_avx_dependency (PR target/89474)

[Jakub Jelinek]

Hi!

Honza, you've reviewed H.J.'s patch, could you please review this follow-up
as well?  Thanks.

On Mon, Feb 25, 2019 at 02:57:39PM -0800, H.J. Lu wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > 2019-02-25  Jakub Jelinek  
> >
> > PR target/89474
> > * config/i386/i386.c (remove_partial_avx_dependency): Call
> > df_analyze etc. before creation of the v4sf_const0 pseudo, rather 
> > than
> > after changing possibly many instructions to use that pseudo.  Fix 
> > up
> > insertion of v4sf_const0 setter at the start of bb.
> >
> > * gcc.target/i386/pr89474.c: New test.

Jakub

Re: [PATCH] Use RANGE_EXPR in Fortran array initializers some more (PR fortran/43210)

[Paul Richard Thomas]

Hi Jakub,

Your timing is astonishing. This was next on my list of TODOs - not
for this particular PR but to deal with the rodata bloat eg. 84487. I
presume that this patch will make the latter go away?

Yes, this is good for trunk and, if it fixes 84487, 8-branch as well.

Thanks

Paul

On Mon, 25 Feb 2019 at 23:02, Jakub Jelinek  wrote:
>
> Hi!
>
> When initializing whole array with a const, we can save quite some compile
> time memory (and time in some cases) by using RANGE_EXPRs, instead of
> duplicating the same initializer thousands of times in the CONSTRUCTOR.
> In some cases the gimplifier even can optimize those better.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2019-02-25  Jakub Jelinek  
>
> PR fortran/43210
> * trans-array.c (gfc_conv_array_initializer): Use RANGE_EXPR instead
> of duplicating the initializer possibly many times.
>
> --- gcc/fortran/trans-array.c.jj2019-02-10 12:05:42.753718023 +0100
> +++ gcc/fortran/trans-array.c   2019-02-25 18:11:44.948166509 +0100
> @@ -5986,7 +5986,6 @@ gfc_conv_array_initializer (tree type, g
>  {
>gfc_constructor *c;
>tree tmp;
> -  offset_int wtmp;
>gfc_se se;
>tree index, range;
>vec *v = NULL;
> @@ -6009,13 +6008,10 @@ gfc_conv_array_initializer (tree type, g
>else
> gfc_conv_structure (, expr, 1);
>
> -  wtmp = wi::to_offset (TYPE_MAX_VALUE (TYPE_DOMAIN (type))) + 1;
> -  /* This will probably eat buckets of memory for large arrays.  */
> -  while (wtmp != 0)
> -{
> - CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, se.expr);
> - wtmp -= 1;
> -}
> +  CONSTRUCTOR_APPEND_ELT (v, build2 (RANGE_EXPR, gfc_array_index_type,
> +TYPE_MIN_VALUE (TYPE_DOMAIN (type)),
> +TYPE_MAX_VALUE (TYPE_DOMAIN (type))),
> + se.expr);
>break;
>
>  case EXPR_ARRAY:
>
> Jakub



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [patch, fortran] Fix PR 89496, error with alternate return

[Janne Blomqvist]

On Tue, Feb 26, 2019 at 9:19 AM Thomas Koenig  wrote:
>
> Hi Dominique,
>
>
> > AFAICT there is no patch attached.
>
> I guess that would have helped :-)
>
> Here it is.

Ok, thanks.


-- 
Janne Blomqvist

Re: [backtrace] Avoid segfault

[Tom de Vries]

On 25-02-19 21:03, Tom de Vries wrote:
> On 25-02-19 15:12, Gerald Pfeifer wrote:
>> Specifically I am now seeing
>>
>>   gmake[4]: *** No rule to make target 'b3test_dwz_buildid', 
>>   needed by 'b3test_dwz_buildid.log'.
>>
>> in my build/test logs.  (Note, this is GNU make 4.2.1, so might reproduce 
>> on your SUSE systems as well?)
> 
> Hi Gerald,
> 
> I managed to reproduce this by adding:
> ...
> mkdir bin
> (
> cd bin
> ln -s $(which false) dwz
> )
> export PATH=$(pwd -P)/bin:$PATH
> ...
> to my libbacktrace test script.
> 

Hmm, I realized that linking dwz to /bin/false set HAVE_DWZ to 1, so I
did in fact not reproduce the failure this way.

The only way of reproducing it was to deinstall dwz.

> The problem is that:
> ...
> TESTS += b3test_dwz_buildid
> ...
> is guarded by HAVE_ELF and HAVE_OBJCOPY_DEBUGLINK, but not by HAVE_DWZ.
> 

Fixed in patch below, committed as trivial.

Thanks,
- Tom


[libbacktrace] Require dwz for b3test_dwz_buildid

If dwz is not available, then the libbacktrace test b3test_dwz_buildid fails
like this:
...
gmake[4]: *** No rule to make target 'b3test_dwz_buildid'
...

Fix this by guarding the test with HAVE_DWZ.

Tested on x86_64 with and without dwz installed.

2019-02-26  Tom de Vries  

	* Makefile.am (TESTS): Only add b3test_dwz_buildid if HAVE_DWZ.
	* Makefile.in: Regenerate.

---
 libbacktrace/Makefile.am |  4 +++
 libbacktrace/Makefile.in | 72 +---
 2 files changed, 41 insertions(+), 35 deletions(-)

diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 3b5f6e374d8..7ddee4962ec 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -205,6 +205,8 @@ b2test_LDADD = libbacktrace_elf_for_test.la
 check_PROGRAMS += b2test
 TESTS += b2test_buildid
 
+if HAVE_DWZ
+
 b3test_SOURCES = $(btest_SOURCES)
 b3test_CFLAGS = $(btest_CFLAGS)
 b3test_LDFLAGS = -Wl,--build-id
@@ -213,6 +215,8 @@ b3test_LDADD = libbacktrace_elf_for_test.la
 check_PROGRAMS += b3test
 TESTS += b3test_dwz_buildid
 
+endif HAVE_DWZ
+
 endif HAVE_OBJCOPY_DEBUGLINK
 endif HAVE_ELF
 
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index f60aca6463a..a896a26dff8 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -120,29 +120,31 @@ POST_UNINSTALL = :
 build_triplet = @build@
 host_triplet = @host@
 target_triplet = @target@
-check_PROGRAMS = $(am__EXEEXT_1) $(am__EXEEXT_2) $(am__EXEEXT_8)
-TESTS = $(am__append_4) $(am__append_6) $(am__append_9) \
-	$(am__append_10) $(am__append_14) $(am__EXEEXT_8)
+check_PROGRAMS = $(am__EXEEXT_1) $(am__EXEEXT_2) $(am__EXEEXT_3) \
+	$(am__EXEEXT_9)
+TESTS = $(am__append_4) $(am__append_6) $(am__append_8) \
+	$(am__append_11) $(am__append_12) $(am__append_16) \
+	$(am__EXEEXT_9)
 @HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_1 = libbacktrace_elf_for_test.la
 @NATIVE_TRUE@am__append_2 = test_elf test_xcoff_32 test_xcoff_64 \
 @NATIVE_TRUE@	test_pecoff test_unknown unittest unittest_alloc \
 @NATIVE_TRUE@	btest
 @NATIVE_TRUE@am__append_3 = allocfail
 @NATIVE_TRUE@am__append_4 = allocfail.sh
-@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_5 = b2test \
-@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@	b3test
-@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_6 = b2test_buildid \
-@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@	b3test_dwz_buildid
-@HAVE_ELF_TRUE@@NATIVE_TRUE@am__append_7 = btest_lto
-@NATIVE_TRUE@am__append_8 = btest_alloc stest stest_alloc ztest \
+@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_5 = b2test
+@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_6 = b2test_buildid
+@HAVE_DWZ_TRUE@@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_7 = b3test
+@HAVE_DWZ_TRUE@@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_8 = b3test_dwz_buildid
+@HAVE_ELF_TRUE@@NATIVE_TRUE@am__append_9 = btest_lto
+@NATIVE_TRUE@am__append_10 = btest_alloc stest stest_alloc ztest \
 @NATIVE_TRUE@	ztest_alloc edtest edtest_alloc
-@HAVE_DWZ_TRUE@@NATIVE_TRUE@am__append_9 = btest_dwz
-@HAVE_DWZ_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_10 = btest_dwz_gnudebuglink
-@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_11 = -lz
-@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_12 = -lz
-@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@am__append_13 = ttest ttest_alloc
-@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_14 = btest_gnudebuglink
-@HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@am__append_15 = ctestg ctesta \
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@am__append_11 = btest_dwz
+@HAVE_DWZ_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_12 = btest_dwz_gnudebuglink
+@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_13 = -lz
+@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_14 = -lz
+@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@am__append_15 = ttest ttest_alloc
+@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_16 = btest_gnudebuglink