date:20170112


On 01/12/2017 07:55 AM, Richard Biener wrote:


The following fixes PR77283, path splitting being overly aggressive
and causing loop unrolling not to happen (because how it distorts the
CFG).

It is a aim at creating a cost model (there's none apart from
not duplicating too much stmts) by means of the observation that
we'd have to have PHI nodes in the joiner to have any possibility
of CSE opportunities being exposed by duplicating it or threading
opportunities being exposed across the new latch.  That includes
virtual PHIs for CSE (so any load/store) but not for the threading
(but IMHO threading should figure all this out on its own without
the requirement for somebody else duplicating the joiner).

Bootstrapped and tested on x86_64-unknown-linux-gnu, the s390x
libquantum regression is reportedly fixed by this.  I had to adjust
gcc.dg/tree-ssa/split-path-7.c to not expect any path splitting because
I (and of course the cost model) can't see any reason to do it.

Ok for trunk?

Thanks,
Richard.

2017-01-12  Richard Biener  

PR tree-optimization/77283
* gimple-ssa-split-paths.c: Include gimple-ssa.h, tree-phinodes.h
and ssa-iterators.h.
(is_feasible_trace): Implement a cost model based on joiner
PHI node uses.

* gcc.dg/tree-ssa/split-path-7.c: Adjust.
* gcc.dg/tree-ssa/split-path-8.c: New testcase.
* gcc.dg/tree-ssa/split-path-9.c: Likewise.
So I think the only concern is split-path-7.  My memory is hazy, but I 
suspect split-path-7 shows the case where path splitting's CFG 
manipulations can result in fewer jumps for diamond sub-graphs.  You 
might see assembly code improvements due to path splitting on this test 
for the microblaze port.


Certainly the code in gimple-ssa-split-paths.c that you're adding is an 
improvement and brings gimple path splitting closer to its intended 
purpose.  I don't think regressing split-path-7 should block this 
improvement, but we would want a PR to track the code quality regression.


So I think it's OK for the trunk and if it shows a code quality 
regression for split-path-7 on the microblaze port that we should have a 
distinct PR to track that issue (which is probably best solved in 
bb-reorder).


Thanks,
Jeff

Re: [RFA][PATCH 3/4] Trim mem* calls in DSE



Richi indicated he wants this to be included in gcc-7.  So I've updated 
the mem* trimming patch with his comments.


The unnecessary SSA updates are gone.  Use wide_int_to_tree rather than 
building/folding expressions we know will result in constants.  Simplify 
incrementing the start address by re-folding the MEM_REF.


Again, these were almost verbatim drop-ins, so I'm going to assume the 
"looks ok" to be approval once prereqs are approved.


This has been bootstrapped and regression tested on top of patches 1a, 
1b, 2 and with patch #4 as well (patch #4 is not on the table for gcc-7 
and isn't being reposted at this point).


Jeff
* tree-ssa-dse.c (decrement_count): New function.
(increment_start_addr, maybe_trim_memstar_call): Likewise.
(dse_dom_walker::optimize_stmt): Call maybe_trim_memstar_call directly
when we know the partially dead statement is a mem* function.

* gcc.dg/tree-ssa/ssa-dse-25.c: New test.

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-25.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-25.c
new file mode 100644
index 000..8b7db3a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-25.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dse1-details -w" } */
+
+char z[32];
+
+
+int
+foo(void)
+{
+  memset (z, 0, 16);
+  memset (z+8, 0, 24);
+}
+
+/* { dg-final { scan-tree-dump "memset ., 0, 8." "dse1" } } */
+
+
diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index 83ce29b..20cf3b4 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -332,6 +332,99 @@ maybe_trim_constructor_store (ao_ref *ref, sbitmap live, 
gimple *stmt)
 }
 }
 
+/* STMT is a memcpy, memmove or memset.  Decrement the number of bytes
+   copied/set by DECREMENT.  */
+static void
+decrement_count (gimple *stmt, int decrement)
+{
+  tree *countp = gimple_call_arg_ptr (stmt, 2);
+  gcc_assert (TREE_CODE (*countp) == INTEGER_CST);
+  *countp = wide_int_to_tree (TREE_TYPE (*countp), (TREE_INT_CST_LOW (*countp)
+   - decrement));
+
+}
+
+static void
+increment_start_addr (gimple *stmt, tree *where, int increment)
+{
+  if (TREE_CODE (*where) == SSA_NAME)
+{
+  tree tem = make_ssa_name (TREE_TYPE (*where));
+  gassign *newop
+= gimple_build_assign (tem, POINTER_PLUS_EXPR, *where,
+  build_int_cst (sizetype, increment));
+  gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
+  gsi_insert_before (, newop, GSI_SAME_STMT);
+  *where = tem;
+  update_stmt (gsi_stmt (gsi));
+  return;
+}
+
+  *where = build_fold_addr_expr (fold_build2 (MEM_REF, char_type_node,
+ *where,
+ build_int_cst (ptr_type_node,
+increment)));
+}
+
+/* STMT is builtin call that writes bytes in bitmap ORIG, some bytes are dead
+   (ORIG & ~NEW) and need not be stored.  Try to rewrite STMT to reduce
+   the amount of data it actually writes.
+
+   Right now we only support trimming from the head or the tail of the
+   memory region.  In theory we could split the mem* call, but it's
+   likely of marginal value.  */
+
+static void
+maybe_trim_memstar_call (ao_ref *ref, sbitmap live, gimple *stmt)
+{
+  switch (DECL_FUNCTION_CODE (gimple_call_fndecl (stmt)))
+{
+case BUILT_IN_MEMCPY:
+case BUILT_IN_MEMMOVE:
+  {
+   int head_trim, tail_trim;
+   compute_trims (ref, live, _trim, _trim);
+
+   /* Tail trimming is easy, we can just reduce the count.  */
+if (tail_trim)
+ decrement_count (stmt, tail_trim);
+
+   /* Head trimming requires adjusting all the arguments.  */
+if (head_trim)
+  {
+   tree *dst = gimple_call_arg_ptr (stmt, 0);
+   increment_start_addr (stmt, dst, head_trim);
+   tree *src = gimple_call_arg_ptr (stmt, 1);
+   increment_start_addr (stmt, src, head_trim);
+   decrement_count (stmt, head_trim);
+ }
+break;
+  }
+
+case BUILT_IN_MEMSET:
+  {
+   int head_trim, tail_trim;
+   compute_trims (ref, live, _trim, _trim);
+
+   /* Tail trimming is easy, we can just reduce the count.  */
+if (tail_trim)
+ decrement_count (stmt, tail_trim);
+
+   /* Head trimming requires adjusting all the arguments.  */
+if (head_trim)
+  {
+   tree *dst = gimple_call_arg_ptr (stmt, 0);
+   increment_start_addr (stmt, dst, head_trim);
+   decrement_count (stmt, head_trim);
+ }
+   break;
+  }
+
+  default:
+   break;
+}
+}
+
 /* STMT is a memory write where one or more bytes written are dead
stores.  ORIG is the bitmap of bytes stored by STMT.  LIVE is the
bitmap of stores that are actually live.
@@ -619,7 +712,7 @@ dse_dom_walker::dse_optimize_stmt

[RFA][PATCH 2/4] [PR tree-optimization/61912] Trimming CONSTRUCTOR stores

This is a relatively minor update to the trimming CONSTRUCTOR stores 
patch to address various comments from Richi.


First, simplification of maybe_trim_constructor_store given we only 
handle one case (CONSTRUCTOR_NELTS (ctor) == 0).  Use 
build_array_type_elts and building an appropriate alias type to avoid 
pessimizing code, adding is_gimple_min_invariant check to avoid creating 
invalid gimple.


Bootstrapped and regression tested with patches 1a & 1b on 
x86_64-linux-gnu as well as with subsequent patches.


Given the changes Richi requested were dropped in verbatim I'm going to 
assume his LGTM comment is an approval once prereqs are in.


JHeff

PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c: Include expr.h.
(maybe_trim_constructor_store): New function.
(maybe_trim_partially_dead_store): Call maybe_trim_constructor_store.


* g++.dg/tree-ssa/ssa-dse-1.C: New test.
* gcc.dg/tree-ssa/pr30375: Adjust expected output.
* gcc.dg/tree-ssa/ssa-dse-24.c: New test.

diff --git a/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C 
b/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C
new file mode 100644
index 000..1fd8dec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C
@@ -0,0 +1,101 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c++14 -O -fdump-tree-dse1-details" } */
+
+using uint = unsigned int;
+
+template
+struct FixBuf
+{
+   C buf[S] = {};
+};
+
+template
+struct OutBuf
+{
+   C*  cur;
+   C*  end;
+   C*  beg;
+
+   template
+   constexpr
+   OutBuf(FixBuf& b) : cur{b.buf}, end{b.buf + S}, beg{b.buf} { }
+
+   OutBuf(C* b, C* e) : cur{b}, end{e} { }
+   OutBuf(C* b, uint s) : cur{b}, end{b + s} { }
+
+   constexpr
+   OutBuf& operator<<(C v)
+   {
+   if (cur < end) {
+   *cur = v;
+   }
+   ++cur;
+   return *this;
+   }
+
+   constexpr
+   OutBuf& operator<<(uint v)
+   {
+   uint q = v / 10U;
+   uint r = v % 10U;
+   if (q) {
+   *this << q;
+   }
+   *this << static_cast(r + '0');
+   return *this;
+   }
+};
+
+template
+struct BufOrSize
+{
+   template
+   static constexpr auto Select(FixBuf& fb, OutBuf&)
+   {
+   return fb;
+   }
+};
+
+template<>
+struct BufOrSize
+{
+   template
+   static constexpr auto Select(FixBuf&, OutBuf& ob)
+   {
+   return ob.cur - ob.beg;
+   }
+};
+
+// if BOS=1, it will return the size of the generated data, else the data 
itself
+template
+constexpr
+auto fixbuf()
+{
+   FixBuf fb;
+   OutBuf ob{fb};
+   for (uint i = 0; i <= N; ++i) {
+   ob << i << static_cast(i == N ? 0 : ' ');
+   }
+   return BufOrSize::Select(fb, ob);
+}
+
+auto foo()
+{
+   constexpr auto x = fixbuf<13, 200>();
+   return x;
+}
+
+auto foo_sized()
+{
+   constexpr auto s = fixbuf<13, 0, 1>();
+   constexpr auto x = fixbuf<13, s>();
+   return x;
+}
+
+int main()
+{
+}
+
+
+/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct FixBuf \\*\\)& 
\\+ \[0-9\]+B\\\] = {}" 1 "dse1" } } */
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr30375.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr30375.c
index 0439b1c..4494a2b 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr30375.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr30375.c
@@ -22,4 +22,5 @@ void test_signed_msg_encoding(void)
 f();
 }
 
-/* { dg-final { scan-tree-dump-times "signInfo = {}" 1 "dse1" } } */
+/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct _s \\*\\) \\+ 
\[0-9\]+B\\\] = {}" 1 "dse1" } } */
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-24.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-24.c
new file mode 100644
index 000..282194c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-24.c
@@ -0,0 +1,62 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dse1" } */
+
+
+typedef unsigned int wchar_t;
+struct printf_info
+{
+  int prec;
+  int width;
+  wchar_t spec;
+  unsigned int is_long_double:1;
+  unsigned int is_short:1;
+  unsigned int is_long:1;
+  unsigned int alt:1;
+  unsigned int space:1;
+  unsigned int left:1;
+  unsigned int showsign:1;
+  unsigned int group:1;
+  unsigned int extra:1;
+  unsigned int is_char:1;
+  unsigned int wide:1;
+  unsigned int i18n:1;
+  unsigned int __pad:4;
+  unsigned short int user;
+  wchar_t pad;
+} info;
+
+void bar (struct printf_info *);
+
+void foo(int prec,
+  int width,
+  wchar_t spec,
+  unsigned int is_long_double,
+  unsigned int is_short,
+  unsigned int is_long,
+  unsigned int alt,
+  unsigned int space,
+  unsigned int left,
+  unsigned int showsign,
+  unsigned int group,
+  wchar_t pad)
+{
+struct printf_info info = {
+.prec = prec,
+.width = width,
+.spec = spec,
+

[RFA][PATCH 1b/4] [PR tree-optimization/33562] Improve DSE of complex stores



No major changes in this patch, just addressing the small changes 
requested by Richi.  ie, missing docs, dropped some unnecessary 
prototype movement, improve check in valid_ao_ref_for_dse, minor 
formatting fixes.


I'm going to assume Richi's prior approval still holds as nothing 
significant changed here.  I'll install once the sbitmap changes are 
approved.


Bootstrapped and regression tested on x86_64-linux-gnu on top of the 
sbitmap changes.  Also bootstrapped and regression tested with the 
subsequent DSE patches.




Jeff
PR tree-optimization/33562
* doc/invoke.texi: Document new dse-max-object-size param.
* params.def (PARM_DSE_MAX_OBJECT_SIZE): New PARAM.
* tree-ssa-dse.c: Include params.h.
(dse_store_status): New enum.
(initialize_ao_ref_for_dse): New, partially extracted from
dse_optimize_stmt.
(valid_ao_ref_for_dse, normalize_ref): New.
(setup_live_bytes_from_ref, compute_trims): Likewise.
(clear_bytes_written_by, maybe_trim_complex_store): Likewise.
(maybe_trim_partially_dead_store): Likewise.
(maybe_trim_complex_store): Likewise.
(dse_classify_store): Renamed from dse_possibly_dead_store_p.
Track what bytes live from the original store.  Return tri-state
for dead, partially dead or live.
(dse_dom_walker): Add constructor, destructor and new private members.
(delete_dead_call, delete_dead_assignment): New extracted from
dse_optimize_stmt.
(dse_optimize_stmt): Make a member of dse_dom_walker.
Use initialize_ao_ref_for_dse.


diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8996161..7321ae9 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9880,6 +9880,10 @@ when adding a new one.
 @item avg-loop-niter
 Average number of iterations of a loop.
 
+@item dse-max-object-size
+Maximum size (in bytes) of objects tracked bytewise by dead store elimination.
+Larger values may result in larger compilation times.
+
 @item scev-max-expr-size
 Bound on size of expressions used in the scalar evolutions analyzer.
 Large expressions slow the analyzer.
diff --git a/gcc/params.def b/gcc/params.def
index 38e91d6..ad97c36 100644
--- a/gcc/params.def
+++ b/gcc/params.def
@@ -532,6 +532,11 @@ DEFPARAM(PARAM_AVG_LOOP_NITER,
 "Average number of iterations of a loop.",
 10, 1, 0)
 
+DEFPARAM(PARAM_DSE_MAX_OBJECT_SIZE,
+"dse-max-object-size",
+"Maximum size (in bytes) of objects tracked bytewise by dead store 
elimination.",
+256, 0, 0)
+
 DEFPARAM(PARAM_SCEV_MAX_EXPR_SIZE,
 "scev-max-expr-size",
 "Bound on size of expressions used in the scalar evolutions analyzer.",
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/complex-4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/complex-4.c
index 87a2638..3155741 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/complex-4.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/complex-4.c
@@ -10,4 +10,4 @@ int f(void)
   return g();
 }
 
-/* { dg-final { scan-tree-dump-times "__complex__" 0 "optimized" { xfail *-*-* 
} } } */
+/* { dg-final { scan-tree-dump-times "__complex__" 0 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/complex-5.c 
b/gcc/testsuite/gcc.dg/tree-ssa/complex-5.c
index e2cd403..e6d027f 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/complex-5.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/complex-5.c
@@ -8,4 +8,4 @@ int f(void)
  __imag__ t = 2;
 }
 
-/* { dg-final { scan-tree-dump-times "__complex__" 0 "optimized" { xfail *-*-* 
} } } */
+/* { dg-final { scan-tree-dump-times "__complex__" 0 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-18.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-18.c
new file mode 100644
index 000..92b2df8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-18.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+int g(_Complex int*);
+int f(void)
+{
+  _Complex int t = 0;
+  int i, j;
+ __imag__ t += 2;
+  return g();
+}
+
+
+/* { dg-final { scan-tree-dump-times "__complex__" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "REALPART_EXPR" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "IMAGPART_EXPR" 1 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-19.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-19.c
new file mode 100644
index 000..718b746
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-19.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+int g(_Complex int*);
+int f(void)
+{
+  _Complex int t = 0;
+  int i, j;
+ __real__ t += 2;
+  return g();
+}
+
+
+/* { dg-final { scan-tree-dump-times "__complex__" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "REALPART_EXPR" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "IMAGPART_EXPR" 1 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-20.c

[RFA][PATCH 1a/4] [PR tree-optimization/33562] New sbitmap functions

Per Richi's request, this breaks out the new sbitmap functions into 
their own patch.


This patch should address all the concerns Richi raised in the prior 
review.  Namely the performance of the range set/clear and bootstrapping 
with older or non-GCC C++ compilers and added missing docs.


The range set/clear functions work by first handling any partial changes 
in the first word by building and applying a single bitmask.  Then all 
full word changes are handled by a call to memset, then finally 
residuals in the last word with another bitmask application.


Internally I tested these by having both implementations and verifying 
they gave identical results during a bootstrap and regression test cycle 
(with the subsequent DSE patches that utilize the new functions).


I also tested the old gcc/non-gcc path by forcing it to be used rather 
than the builtin popcount paths.  Again, this was bootstrapped and 
regression tested against the full DSE patches.


After those tests were complete, I ripped out the debugging/verification 
bits and did another bootstrap and regression test of just the sbitmap 
changes as well as a bootstrap and regression test of each stage in the 
patchkit.


OK for the trunk?

Jeff


PR tree-optimization/33562
* sbitmap.h (bitmap_count_bits): Prototype.
(bitmap_clear_range, bitmap_set_range): Likewise.
* sbitmap.c (bitmap_clear_range): New function.
(bitmap_set_range, sbitmap_popcount, bitmap_count_bits): Likewise.

diff --git a/gcc/sbitmap.c b/gcc/sbitmap.c
index c9bcea9..c065d13 100644
--- a/gcc/sbitmap.c
+++ b/gcc/sbitmap.c
@@ -202,6 +202,170 @@ bitmap_empty_p (const_sbitmap bmap)
   return true;
 }
 
+/* Clear COUNT bits from START in BMAP.  */
+
+void
+bitmap_clear_range (sbitmap bmap, unsigned int start, unsigned int count)
+{
+  if (count == 0)
+return;
+
+  unsigned int start_word = start / SBITMAP_ELT_BITS;
+  unsigned int start_bitno = start % SBITMAP_ELT_BITS;
+
+  /* Clearing less than a full word, starting at the beginning of a word.  */
+  if (start_bitno == 0 && count < SBITMAP_ELT_BITS)
+{
+  SBITMAP_ELT_TYPE mask = ((SBITMAP_ELT_TYPE)1 << count) - 1;
+  bmap->elms[start_word] &= ~mask;
+  return;
+}
+
+  unsigned int end_word = (start + count) / SBITMAP_ELT_BITS;
+  unsigned int end_bitno = (start + count) % SBITMAP_ELT_BITS;
+
+  /* Clearing starts somewhere in the middle of the first word.  Clear up to
+ the end of the first word or the end of the requested region, whichever
+ comes first.  */
+  if (start_bitno != 0)
+{
+  unsigned int nbits = ((start_word == end_word)
+   ? end_bitno - start_bitno
+   : SBITMAP_ELT_BITS - start_bitno);
+  SBITMAP_ELT_TYPE mask = ((SBITMAP_ELT_TYPE)1 << nbits) - 1;
+  mask <<= start_bitno;
+  bmap->elms[start_word] &= ~mask;
+  start_word++;
+  count -= nbits;
+}
+
+  if (count == 0)
+return;
+
+  /* Now clear words at a time until we hit a partial word.  */
+  unsigned int nwords = (end_word - start_word);
+  if (nwords)
+{
+  memset (>elms[start_word], 0, nwords * sizeof (SBITMAP_ELT_TYPE));
+  count -= nwords * sizeof (SBITMAP_ELT_TYPE) * BITS_PER_UNIT;
+  start_word += nwords;
+}
+
+  if (count == 0)
+return;
+
+  /* Now handle residuals in the last word.  */
+  SBITMAP_ELT_TYPE mask = ((SBITMAP_ELT_TYPE)1 << count) - 1;
+  bmap->elms[start_word] &= ~mask;
+}
+
+/* Set COUNT bits from START in BMAP.  */
+void
+bitmap_set_range (sbitmap bmap, unsigned int start, unsigned int count)
+{
+  if (count == 0)
+return;
+
+  unsigned int start_word = start / SBITMAP_ELT_BITS;
+  unsigned int start_bitno = start % SBITMAP_ELT_BITS;
+
+  /* Setting less than a full word, starting at the beginning of a word.  */
+  if (start_bitno == 0 && count < SBITMAP_ELT_BITS)
+{
+  SBITMAP_ELT_TYPE mask = ((SBITMAP_ELT_TYPE)1 << count) - 1;
+  bmap->elms[start_word] |= mask;
+  return;
+}
+
+  unsigned int end_word = (start + count) / SBITMAP_ELT_BITS;
+  unsigned int end_bitno = (start + count) % SBITMAP_ELT_BITS;
+
+  /* Setting starts somewhere in the middle of the first word.  Set up to
+ the end of the first word or the end of the requested region, whichever
+ comes first.  */
+  if (start_bitno != 0)
+{
+  unsigned int nbits = ((start_word == end_word)
+   ? end_bitno - start_bitno
+   : SBITMAP_ELT_BITS - start_bitno);
+  SBITMAP_ELT_TYPE mask = ((SBITMAP_ELT_TYPE)1 << nbits) - 1;
+  mask <<= start_bitno;
+  bmap->elms[start_word] |= mask;
+  start_word++;
+  count -= nbits;
+}
+
+  if (count == 0)
+return;
+
+  /* Now set words at a time until we hit a partial word.  */
+  unsigned int nwords = (end_word - start_word);
+  if (nwords)
+{
+  memset (>elms[start_word], 0xff,
+ nwords * sizeof (SBITMAP_ELT_TYPE));
+  count -=

Re: [PATCH 6/6] RISC-V Port: gcc/testsuite

2017-01-12 Thread Andrew Waterman

On Thu, Jan 12, 2017 at 3:42 PM, Joseph Myers  wrote:
> On Wed, 11 Jan 2017, Palmer Dabbelt wrote:
>
> As I understand it, you have -m options that can change the ABI between
> 32-bit and 64-bit.  In such a case you mustn't check for riscv*64*-*-*
> target triplets in the testsuite, since that behave incorrectly when
> testing with an option that changes to the other one of 32-bit and 64-bit
> from the configured default.  Instead, you need to allow for all
> riscv*-*-* triplets and combine as needed with a test such as lp64 or
> ilp32.

Yes, that makes sense.  This will be rectified in v2 of the patch set.  Thanks.

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

[v3 PATCH] PR libstdc++/78389

2017-01-12 Thread Ville Voutilainen

Tested on Linux-x64.

This patch doesn't try to fix the reported sort() issue, because
a) it would require undoing a throwing move operation, which
is impossible.
b) in order to avoid the throwing move, we would need to add a
level of indirection and the scratch space for the indirect data
would need to be allocated.

2017-01-13  Ville Voutilainen  

PR libstdc++/78389
* include/bits/list.tcc (merge(list&&)):
Adjust list sizes if the comparator throws.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/78389.cc: New.
diff --git a/libstdc++-v3/include/bits/list.tcc 
b/libstdc++-v3/include/bits/list.tcc
index c4f397f..fabbe7b 100644
--- a/libstdc++-v3/include/bits/list.tcc
+++ b/libstdc++-v3/include/bits/list.tcc
@@ -386,20 +386,29 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  iterator __last1 = end();
  iterator __first2 = __x.begin();
  iterator __last2 = __x.end();
- while (__first1 != __last1 && __first2 != __last2)
-   if (*__first2 < *__first1)
- {
-   iterator __next = __first2;
-   _M_transfer(__first1, __first2, ++__next);
-   __first2 = __next;
- }
-   else
- ++__first1;
- if (__first2 != __last2)
-   _M_transfer(__last1, __first2, __last2);
+ size_t __orig_size = __x.size();
+ __try {
+   while (__first1 != __last1 && __first2 != __last2)
+ if (*__first2 < *__first1)
+   {
+ iterator __next = __first2;
+ _M_transfer(__first1, __first2, ++__next);
+ __first2 = __next;
+   }
+ else
+   ++__first1;
+   if (__first2 != __last2)
+ _M_transfer(__last1, __first2, __last2);
 
- this->_M_inc_size(__x._M_get_size());
- __x._M_set_size(0);
+   this->_M_inc_size(__x._M_get_size());
+   __x._M_set_size(0);
+ }
+ __catch(...)
+   {
+ size_t __dist = distance(__first2, __last2);
+ this->_M_inc_size(__dist);
+ __x._M_set_size(__orig_size - __dist);
+   }
}
 }
 
@@ -423,20 +432,30 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
iterator __last1 = end();
iterator __first2 = __x.begin();
iterator __last2 = __x.end();
-   while (__first1 != __last1 && __first2 != __last2)
- if (__comp(*__first2, *__first1))
-   {
- iterator __next = __first2;
- _M_transfer(__first1, __first2, ++__next);
- __first2 = __next;
-   }
- else
-   ++__first1;
-   if (__first2 != __last2)
- _M_transfer(__last1, __first2, __last2);
-
-   this->_M_inc_size(__x._M_get_size());
-   __x._M_set_size(0);
+   size_t __orig_size = __x.size();
+   __try
+ {
+   while (__first1 != __last1 && __first2 != __last2)
+ if (__comp(*__first2, *__first1))
+   {
+ iterator __next = __first2;
+ _M_transfer(__first1, __first2, ++__next);
+ __first2 = __next;
+   }
+ else
+   ++__first1;
+   if (__first2 != __last2)
+ _M_transfer(__last1, __first2, __last2);
+
+   this->_M_inc_size(__x._M_get_size());
+   __x._M_set_size(0);
+ }
+   __catch(...)
+ {
+   size_t __dist = distance(__first2, __last2);
+   this->_M_inc_size(__dist);
+   __x._M_set_size(__orig_size - __dist);
+ }
  }
   }
 
diff --git a/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc 
b/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc
new file mode 100644
index 000..3fa9501
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc
@@ -0,0 +1,73 @@
+// { dg-do run { target c++11 } }
+
+// Copyright (C) 2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// 23.2.2.4 list operations

Re: [PATCH 6/6] RISC-V Port: gcc/testsuite

On Wed, 11 Jan 2017, Palmer Dabbelt wrote:

> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
> index 1a4bfe6..665ac23 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
> @@ -25,4 +25,4 @@ foo ()
> but the loop reads only one element at a time, and DOM cannot resolve 
> these.
> The same happens on powerpc depending on the SIMD support available.  */
>  
> -/* { dg-final { scan-tree-dump "return 28;" "optimized" { xfail { { 
> alpha*-*-* hppa*64*-*-* powerpc64*-*-* } || { sparc*-*-* && lp64 } } } } } */
> +/* { dg-final { scan-tree-dump "return 28;" "optimized" { xfail { { 
> alpha*-*-* hppa*64*-*-* powerpc64*-*-* riscv*64*-*-* } || { sparc*-*-* && 
> lp64 } } } } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c
> index a287dad..0aecfed 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c
> @@ -5,7 +5,7 @@
>  
> When the condition is true, we distribute "(int) (a + b)" as
> "(int) a + (int) b", otherwise we keep the original.  */
> -/* { dg-do compile { target { { ! mips64 } && { ! spu-*-* } } } } */
> +/* { dg-do compile { target { { ! mips64 } && { { ! spu-*-* } && { ! 
> riscv*64*-*-* } } } } } */
>  /* { dg-options "-O -fno-tree-forwprop -fno-tree-ccp -fwrapv 
> -fdump-tree-fre1-details" } */
>  
>  /* From PR14844.  */

As I understand it, you have -m options that can change the ABI between 
32-bit and 64-bit.  In such a case you mustn't check for riscv*64*-*-* 
target triplets in the testsuite, since that behave incorrectly when 
testing with an option that changes to the other one of 32-bit and 64-bit 
from the configured default.  Instead, you need to allow for all 
riscv*-*-* triplets and combine as needed with a test such as lp64 or 
ilp32.

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

Re: [PATCH 4/6] RISC-V Port: libsanitizer

Have these changes been sent upstream?  Although at the present 
development stage applying selected changes might be better than a bulk 
merge from upstream libsanitizer, they should still go upstream so they 
aren't a local patch at the time of the next merge.

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

Re: [PATCH 3/6] RISC-V Port: libgcc

On Wed, 11 Jan 2017, Palmer Dabbelt wrote:

> +riscv*-*-linux*)
> + tmake_file="${tmake_file} t-softfp-sfdf riscv/t-softfp${host_address} 
> t-softfp riscv/t-elf riscv/t-elf${host_address}"
> + extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o crtendS.o 
> crtbeginT.o"
> + md_unwind_header=riscv/linux-unwind.h
> + ;;
> +riscv*-*-*)
> + tmake_file="${tmake_file} t-softfp-sfdf riscv/t-softfp${host_address} 
> t-softfp riscv/t-elf riscv/t-elf${host_address}"
> + extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o"
> + ;;

This looks like you're building soft-fp functions into libgcc for all 
types whether or not you have hardware floating point support for them.

If your ABIs are such that hardware and software floating point are ABI 
compatible at the function call level, then both copies of libgcc (the 
shared library, at least) should indeed have the same ABI (so a soft-float 
program can run with a hard-float copy of libgcc) - but for the hardware 
types, it's better to use t-hardfp.  If they are not ABI compatible, it's 
best for libgcc to contain only the functions that are actually needed.  
That is, in general, it only needs to contain functions that are not 
implemented in hardware, or are implemented in hardware but might not be 
implemented in hardware for some configurations using the same ABI (and in 
the latter case, the t-hardfp implementations are preferred).

> +#define _FP_NANFRAC_S((_FP_QNANBIT_S << 1) - 1)
> +#define _FP_NANFRAC_D((_FP_QNANBIT_D << 1) - 1), -1
> +#define _FP_NANFRAC_Q((_FP_QNANBIT_Q << 1) - 1), -1, -1, -1

This is different from the default NaN the specification says is used by 
hardware (all mantissa bits clear except for the MSB used to indicate a 
quiet NaN).  I'd expect the soft-fp configuration to make the same choices 
here as hardware.

> +#define _FP_NANFRAC_S((_FP_QNANBIT_S << 1) - 1)
> +#define _FP_NANFRAC_D((_FP_QNANBIT_D << 1) - 1)
> +#define _FP_NANFRAC_Q((_FP_QNANBIT_Q << 1) - 1), -1

Likewise.

> +#define _FP_KEEPNANFRACP 1

And since the hardware semantics don't propagate payloads I'd expect this 
to be zero, and ...

> +/* From my experiments it seems X is chosen unless one of the
> +   NaNs is sNaN,  in which case the result is NANSIGN/NANFRAC.  */
> +#define _FP_CHOOSENAN(fs, wc, R, X, Y, OP)   \

 ... this to use a canonical NaN unconditionally, so that again you do the 
same as hardware (the comment here is actively misleading in this case as 
it describes something contrary to the hardware specification as being 
what experiments show hardware does).

> +#define FP_ROUNDMODE (_fcw >> 5)

I'm unclear from the specification whether the high 24 bits of fcsr are 
architecturally defined always to read as zero, or whether that's only the 
case in present architecture versions and they are reserved for possible 
future feature additions.  If the latter, it would seem desirable to mask 
the result of shifting so existing binaries using the soft-fp code 
continue to work on future hardware that might set some of the high bits.

> +#define  __LITTLE_ENDIAN 1234
> +#define  __BIG_ENDIAN4321
> +
> +#if defined __big_endian__
> +# define __BYTE_ORDER __BIG_ENDIAN
> +#else
> +# define __BYTE_ORDER __LITTLE_ENDIAN
> +#endif

As far as I can tell the port is always little-endian and there is no 
__big_endian__ macro, so that #if should not be there.

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

Re: [PATCH] Fix PR77283


On 01/12/2017 07:55 AM, Richard Biener wrote:


The following fixes PR77283, path splitting being overly aggressive
and causing loop unrolling not to happen (because how it distorts the
CFG).

It is a aim at creating a cost model (there's none apart from
not duplicating too much stmts) by means of the observation that
we'd have to have PHI nodes in the joiner to have any possibility
of CSE opportunities being exposed by duplicating it or threading
opportunities being exposed across the new latch.  That includes
virtual PHIs for CSE (so any load/store) but not for the threading
(but IMHO threading should figure all this out on its own without
the requirement for somebody else duplicating the joiner).

Bootstrapped and tested on x86_64-unknown-linux-gnu, the s390x
libquantum regression is reportedly fixed by this.  I had to adjust
gcc.dg/tree-ssa/split-path-7.c to not expect any path splitting because
I (and of course the cost model) can't see any reason to do it.
I went back and reviewed the discussion from last year.  The conclusion 
for linit (split-path-7.c) was that there was a path we could split, but 
that there was no real benefit in doing so at the tree level.


The more general conclusion was that path splitting rarely exposes 
CSE/DCE opportunities, contrary to the original motivation (the adpcm 
encoder is the exception).  What path splitting does more often is 
remove an unconditional branch in diamond shaped sub-graphs.


In an ideal world, raw path splitting would move into the RTL pipeline 
since it's primary value is to eliminate jumps and we'd use some kind of 
PHI partitioning to handle cases where constant values from some paths 
of control allow simplification at use sites.  It's just path isolation.


I'll try to get to the rest of the review tomorrow tonight/tomorrow.

jeff

Re: [RFA][PATCH 3/4] Trim mem* calls in DSE


On 01/04/2017 07:04 AM, Richard Biener wrote:




* tree-ssa-dse.c (need_ssa_update): New file scoped boolean.
(decrement_count): New function.
(increment_start_addr, trim_memstar_call): Likewise.
(trim_partially_dead_store): Call trim_memstar_call.
(pass_dse::execute): Initialize need_ssa_update.  If set, then
return TODO_ssa_update.

* gcc.dg/tree-ssa/ssa-dse-25.c: New test.

diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index 1482c7f..b21b9b5 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -79,6 +80,10 @@ static bitmap need_eh_cleanup;
It is always safe to return FALSE.  But typically better optimziation
can be achieved by analyzing more statements.  */

+/* If trimming stores requires insertion of new statements, then we
+   will need an SSA update.  */
+static bool need_ssa_update;
+


huh?  You set this to true after inserting a POINTER_PLUS_EXPR, I don't see
how you need an SSA update for this.

It doesn't seem needed anymore.  I'm ripping that out.


+/* STMT is a memcpy, memmove or memset.  Decrement the number of bytes
+   copied/set by DECREMENT.  */
+static void
+decrement_count (gimple *stmt, int decrement)
+{
+  tree *countp = gimple_call_arg_ptr (stmt, 2);
+  gcc_assert (TREE_CODE (*countp) == INTEGER_CST);
+  tree x = fold_build2 (MINUS_EXPR, TREE_TYPE (*countp), *countp,
+   build_int_cst (TREE_TYPE (*countp), decrement));
+  *countp = x;


thanks to wide-int the following should work

   *countp = wide_int_to_tree (TREE_TYPE (*countp), *countp - decrement);
*countp is still a tree, but we know its an INTEGER_CST, so we can 
extract its value trivially.



+}
+
+static void
+increment_start_addr (gimple *stmt ATTRIBUTE_UNUSED, tree *where, int
increment)
+{
+  /* If the address wasn't initially a MEM_REF, make it a MEM_REF.  */
+  if (TREE_CODE (*where) == ADDR_EXPR
+  && TREE_CODE (TREE_OPERAND (*where, 0)) != MEM_REF)
+{
+  tree t = TREE_OPERAND (*where, 0);
+  t = build_ref_for_offset (EXPR_LOCATION (t), t,
+   increment * BITS_PER_UNIT, false,
+   ptr_type_node, NULL, false);


please don't use build_ref_for_offset for this.  Simply only handle the SSA_NAME
case here and below ...
Done.  I'm pretty sure calling into build_ref_for_offset was to handle 
 kinds of cases and as you note, we can just re-fold the thing 
as a MEM_REF which simplifies everything a little.


Jeff

[testsuite, committed] gcc.dg/pr77862.c requires fpic target

2017-01-12 Thread Sandra Loosemore

gcc.dg/pr77862.c was failing on targets that don't support -fPIC, 
specifically nios2-elf.  I've fixed this with a 
dg-require-effective-target restriction, consistent with what similar 
testcases do (e.g., gcc.dg/pic-2.c).


Committed as obvious.

-Sandra

2017-01-12  Sandra Loosemore  

	gcc/testsuite/
	* gcc.dg/pr77862.c: Require fpic target.
Index: gcc/testsuite/gcc.dg/pr77862.c
===
--- gcc/testsuite/gcc.dg/pr77862.c	(revision 244386)
+++ gcc/testsuite/gcc.dg/pr77862.c	(working copy)
@@ -1,6 +1,7 @@
 
 /* PR tree-optimization/77862 */
 /* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
 /* { dg-options "-O2 -fPIC -w" } */
 
 struct paramed_type

Re: [PATCH] better handling of ranges (PR 78703)


On 01/09/2017 09:18 AM, Martin Sebor wrote:

On 01/08/2017 09:44 PM, Jeff Law wrote:

On 12/23/2016 02:25 PM, Martin Sebor wrote:

Bug 78703 points out that the decimal point character in floating
directives can be longer than just one byte (in locales where the
decimal point is a multibyte character).  The decimal point can
result in anywhere between 1 and MB_LEN_MAX bytes.  This is unlikely
but locales with two-byte decimal point are known to exist, and
the gimple-ssa-sprintf pass must handle them correctly.

In a comment on the bug Jakub suggests that while printf return
value optimization must correctly deal with the worst case (i.e.,
MB_LEN_MAX of 6 for UTF-8), reflecting the worst case in the text
of warnings could be confusing to users most of whom expect
a single byte decimal point.

Finally, a limitation of the gimple-ssa-sprintf pass has been that
it only understands constant width and precision and treats others
as essentially unlimited even if they are constrained to a limited
range of values.  This results in false positives and negatives
that can be avoided.

The attached patch enhances the pass to overcome both of these
limitations.  It does that by first replacing the exact byte counter
with two other counters: 1) a likely counter that tracks the number
of bytes a directive is likely to result in, and 2) an "unlikely"
byte for lack of a better name, that tracks the unlikely maximum
byte count in cases like multibyte decimal point, and second by
adding range handling for width and precision specified by the
asterisk (such as in sprintf("%*.*i", w, p, i)).

The patch resulted in more extensive changes than I initially
intended but the result is a simplified implementation.  A good
amount of the changes is factoring code out into more general
functions that can be shared throughout the pass.

With these enhancements, although the support for ranges in the
pass is complete, it's not as robust as it could be.  I think
having the pass run later could improve things.

The pass does produce a fair number of warnings for calls to
snprintf in the linux kernel.  Some of these I suspect will be
considered false positives.  I think it might be worth splitting
up the snprintf warning from -Wformat-length and adding a separate
option to control it.

Martin

gcc-78703.diff


PR middle-end/78703 -  -fprintf-return-value floating point handling
incorrect in locales with a mulltibyte decimal point

gcc/ChangeLog:

PR middle-end/78703
* gimple-ssa-sprintf.c (get_int_range): New function.
(struct result_range): Add members.
(struct format_result): Replace number_chars, number_chars_min, and
number_chars_max, with struct result_ramge.  Remove constant.
(format_result::operator+=): Update and define out of class.
(struct fmtresult): Add constructors.  Remove constant and bounded
members.
(format_result::type_max_digits): New function.
(format_result::adjust_for_width_and_precision): New function.
(struct conversion_spec): Rename...
(struct directive): ...to this.
(struct directive): Add new data members.
(directive::set_width, directive::set_precison): New functions.
(bytes_remaining, get_int_range, format_character, format_plain):
Same.
(should_warn_p, maybe_warn, parse_directive): Same.
(min_bytes_remaining, add_bytes): Remove.
(format_percent, get_string_length): Simplify.
(format_integer): Handle width and precision ranges.
(format_floating): Same.
(get_mpfr_format_length): Work around MPFR bugs and simplify.
(format_string): Factor single character handling into
format_character.  Handle width and precision ranges.
(format_directive): Factor out most warning code into maybe_warn.
(pass_sprintf_length::compute_format_length): Factor out parsing
into parse_directive.
(try_substitute_return_value): Handle unlikely maximum byte counter.
Simplify for better clarity.

gcc/testsuite/ChangeLog:

PR middle-end/78703
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf.c: Adjust.
* gcc.dg/format/pr78569.c: Same.




+  /* Get the real type format desription for the target.  */

s/desription/description/





@@ -1613,24 +1738,23 @@ get_string_length (tree str)

   if (lenrange [0] || lenrange [1])
 {
-  fmtresult res;
+  fmtresult res (tree_fits_uhwi_p (lenrange[0])
+ ? tree_to_uhwi (lenrange[0]) : 1 < warn_format_length,

Ordering of operands.



+  else if (0 < min && min < 128)
Order of operands.  It would be helpful if you could just do an
iteration over the

Re: [PATCH 2/6] RISC-V Port: gcc

On Wed, 11 Jan 2017, Palmer Dabbelt wrote:

> +static void
> +riscv_parse_arch_string (const char *isa, int *flags)

This should be passed the location from riscv_handle_option...

> +  error ("-march=%s: ISA string must begin with rv32 or rv64", isa);

 ... so you can use error_at with an explicit location (for all errors in 
thsi function).

> +static bool
> +riscv_handle_option (struct gcc_options *opts,
> +  struct gcc_options *opts_set ATTRIBUTE_UNUSED,
> +  const struct cl_decoded_option *decoded,
> +  location_t loc ATTRIBUTE_UNUSED)

The location will no longer then be ATTRIBUTE_UNUSED.

> + supported_defaults="abi arch tune"

So you have three supported defaults here ...

> +/* Support for a compile-time default CPU, et cetera.  The rules are:
> +   --with-arch is ignored if -march is specified.
> +   --with-abi is ignored if -mabi is specified.
> +   --with-tune is ignored if -mtune is specified.  */
> +#define OPTION_DEFAULT_SPECS \
> +  {"march", "%{!march=*:-march=%(VALUE)}" }, \
> +  {"mabi", "%{!mabi=*:-mabi=%(VALUE)}" }, \
> +  {"tune", "%{!mtune=*:-mtune=%(VALUE)}" }, \
> +  {"arch", "%{!march=*:-march=%(VALUE)}" }, \
> +  {"abi", "%{!mabi=*:-mabi=%(VALUE)}" }, \

 ... why do you need the "march" and "mabi" entries here, when I'd expect 
three entries as well?

> +#undef ASM_SPEC
> +#define ASM_SPEC "\
> +%(subtarget_asm_debugging_spec) \
> +%{fPIC|fpic|fPIE|fpie:-fpic} \

I'd expect you to use FPIE_OR_FPIC_SPEC here to enable 
--enable-default-pie.

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

Re: [PATCH] PR target/79004, Fix char/short -> _Float128 on PowerPC -mcpu=power9

2017-01-12 Thread Michael Meissner

On Wed, Jan 11, 2017 at 04:39:19PM -0600, Segher Boessenkool wrote:
> On Mon, Jan 09, 2017 at 07:32:27PM -0500, Michael Meissner wrote:
> > This patch fixes PR target/79004 by eliminating the optimization of avoiding
> > direct move if we are converting an 8/16-bit integer value from memory to 
> > IEEE
> > 128-bit floating point.
> > 
> > I opened a new bug (PR target/79038) to address the underlying issue that 
> > the
> > IEEE 128-bit floating point integer conversions were written before small
> > integers were allowed in the traditional Altivec registers.  This meant 
> > that we
> > had to use UNSPEC and explicit temporaries to get the integers into the
> > appropriate registers.
> > 
> > I have tested this bug by doing a bootstrap build and make check on a little
> > endian power8 system and using an assembler that knows about ISA 3.0
> > instructions.  I added a new test to verify the results.  Can I check this 
> > into
> > the trunk?  This is not an issue on GCC 6.x.
> 
> Okay, thanks!  Two comments:
> 
> > +/* { dg-final { scan-assembler-not " bl __"} } */
> > +/* { dg-final { scan-assembler "xscvdpqp"  } } */
> > +/* { dg-final { scan-assembler "xscvqpdp"  } } */
> 
> This line always matches if ...
> 
> > +/* { dg-final { scan-assembler "xscvqpdpo" } } */
> 
> ... this one does.  I recommend \m \M .

Ok, I rewrote the test to use \m and \M and checked it in.  Thanks.

> > +/* { dg-final { scan-assembler "xscvqpsdz" } } */
> > +/* { dg-final { scan-assembler "xscvqpswz" } } */
> > +/* { dg-final { scan-assembler "xscvsdqp"  } } */
> > +/* { dg-final { scan-assembler "xscvudqp"  } } */
> > +/* { dg-final { scan-assembler "lxsd"  } } */
> > +/* { dg-final { scan-assembler "lxsiwax"   } } */
> > +/* { dg-final { scan-assembler "lxsiwzx"   } } */
> > +/* { dg-final { scan-assembler "lxssp" } } */
> > +/* { dg-final { scan-assembler "stxsd" } } */
> > +/* { dg-final { scan-assembler "stxsiwx"   } } */
> > +/* { dg-final { scan-assembler "stxssp"} } */
> 
> There are many more than 14 instructions generated; maybe you want
> scan-assembler-times?

I had thought about it, but I thought it might impede future optimizations
(i.e. whether short/char are converted to 32-bit word or 64-bit word before
doing the stores).

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

Re: [PATCH] rename -Wformat-length to -Wformat-overflow

2017-01-12 Thread Martin Sebor


On 01/12/2017 02:26 PM, Jeff Law wrote:

On 01/12/2017 01:31 PM, Martin Sebor wrote:

With the move of the snprintf truncation checking from -Wformat-length
to the dedicated -Wformat-truncation option (done in r244210),
-Wformat-length isn't as descriptive as it could and should be for
an option whose sole focus is the detection of sprintf buffer overflow.

The name is also inconsistent with the name of -Wstringop-overflow
option which focuses on detecting buffer overflow by string operations
such as strcpy or memcpy.

To make the purpose of the option clearer and its name consistent with
-Wstringop-overflow the attached patch renames -Wformat-length to
-Wformat-overflow.

Thanks
Martin

gcc-wformat-overflow.diff


gcc/c-family/ChangeLog:

* c.opt (-Wformat-length): Rename...
(-Wformat-overflow): ...to this.

gcc/ChangeLog:

* doc/invoke.texi (Warning Options): Rename -Wformat-length
to -Wformat-overflow.
* gimple-ssa-sprintf.c (pass_sprintf_length::gate): Adjust.
(min_bytes_remaining): Same.
(get_string_length): Same.
(format_string): Same.
(format_directive): Same.
(add_bytes): Same.
(pass_sprintf_length::handle_gimple_call): Same.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/pr78622.c: Adjust.
* gcc.dg/pr78138.c: Adjust.
* gcc.dg/pr78768.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-4.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-8.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: Adjust.
* gcc.dg/tree-ssa/pr78605.c: Adjust.
* gcc.dg/tree-ssa/pr78622.c: Adjust.

OK with just a couple cleanups noted below.


Done in r244385.

Martin

Re: [PATCH] builtin expansion of strncmp for rs6000

2017-01-12 Thread Segher Boessenkool

On Thu, Jan 12, 2017 at 05:53:06PM +, Joseph Myers wrote:
> On Thu, 15 Dec 2016, Aaron Sawdey wrote:
> 
> > +  emit_library_call_value (gen_rtx_SYMBOL_REF (Pmode, "strncmp"),
> > +  target, LCT_NORMAL, GET_MODE (target), 3,
> > +  force_reg (Pmode, XEXP (src1, 0)), Pmode,
> > +  force_reg (Pmode, XEXP (src2, 0)), Pmode,
> > +  len_rtx, GET_MODE (len_rtx));
> 
> Building glibc with GCC mainline for powerpc64le-linux-gnu (from my bot 
> doing such builds and compilation parts of the testsuite for all GNU/Linux 
> glibc ABIs daily), I'm seeing a failure of the elf/check-localplt test, 
> "Extra PLT reference: libc.so: strncmp".
> 
> Without having bisected, I suspect this patch of being a likely cause of 
> that failure.  glibc redirects internal calls to use hidden aliases such 
> as __GI_strncmp to avoid them going through the PLT.  By using 
> gen_rtx_SYMBOL_REF there with a hardcoded function name "strncmp", this 
> code looks like it would render a declaration of strncmp with asm 
> ("__GI_strncmp") ineffective, generating a direct call to strncmp when 
> glibc expects __GI_strncmp to be called instead.
> 
> I don't know how readily this code can be made to respect asm renaming of 
> strncmp.  If it's hard to fix in GCC, I suppose glibc needs a powerpc 
> version of symbol-hacks.h to handle this redirection.

Tulio will look at fixing it in glibc tomorrow.  Thanks for the report,



Segher

Re: [PATCH] better handling of ranges (PR 78703)


On 01/09/2017 09:18 AM, Martin Sebor wrote:

On 01/08/2017 09:44 PM, Jeff Law wrote:



As much as I hate to say it, I think we need to find a way to break this
down into something more manageable.  It's just impossible to see the
structure of what you're doing with the implementation changes mixed in
with what appear to be refactoring changes.

Is there any way we can start to break this down into something more
manageable?


I'm sorry it's too big.  I actually did start out by doing in stages
and and have a smaller initial patch that the rest of it builds on.
I unfortunately forgot that I had done that when I posted the bigger
patch and then left for my trip.

Attached are the two revisions. The description of the major changes
in each of the two is below.  The patches are bigger in part because
of the name change (conversion_spec to directive and spec to dir),
but also because the range work provided an opportunity to factor
out and consolidate a good amount of code.  IMO, the end result is
quite a bit cleaner than before and should be easier to follow.

I'm not sure how difficult or time consuming it would be to split
up the second of the two patches if it's still too big.  I suspect
it would take a few days.

gcc-78703-1.diff

  Extends struct conversion_spec to struct directive so that ordinary
  format characters can be handled uniformly with other directives
  (those that start with a '%') and adds format_plain to format them.

  It also adds parse_directive and moves directive parsing from
  pass_sprintf_length::compute_format_length to it.

  It makes no changes to the warning or optimization logic and so
  the test updates only to reflect the uniform directive handling.

gcc-78703-2.diff

  Contains the bulk of the rest of the changes.  I.e., it replaces
  the superfluous exact byte counter with the likely counter and
  adds the unlikely counter.

  It replaces the get_width_and_precision function with get_int_range
  to get ranges for width and precision ranges and adds
  fmtresult::adjust_for_width_or_precision to handle with and precision
  ranges.

  It adds tge should_warn_p function and moves all logic to determine
  whether or not to issue a warning at a given point in the processing
  of a format string to it.

  It adds the maybe_warn function and ymoves all the format directive
  overflow and truncation warnings into it.

  It removes the add_bytes function (its fully superseded by
  format_directive.

  Finally, this version also enhances the debugging output to include
  width and precision ranges.

Martin

gcc-78703-1.diff


commit 366503058ae7fa8ff689b258f728010d942e0354
Author: Martin Sebor 
Date:   Fri Dec 16 16:13:10 2016 -0700

Rename struct conversion_spec with struct directive.
Add format_plain to format plain format substrings.
Change format_directive to handle plain format substrings
and to print called function name in diagnostics
Add parse_directive.
Simplify pass_sprintf_length::compute_format_length and
call parse_directive.
Adjust tests.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index a91dcb8..22ef86b 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -1838,32 +1848,42 @@ format_string (const conversion_spec , tree arg)
   return res;
 }

+
+static fmtresult
+format_plain (const directive , tree)

Needs a trivial function comment.

  else if (navail < fmtres.range.max

-  && (((spec.specifier == 's'
+  && (((dir.specifier == 's'
 && fmtres.range.max < HOST_WIDE_INT_MAX)
-   /* && (spec.precision || spec.star_precision) */)
+   /* && (dir.precision || dir.star_precision) */)
   || 1 < warn_format_length))
Any good reason to keep the commented out code here?  If not, let's 
remove it.


With an updated changelog the -1 patch is OK.  It was a *lot* easier to 
see what you were doing here.


Jeff

Re: [patch] update zlib to the 1.2.10 release.


On 01/12/2017 02:26 PM, Matthias Klose wrote:

On 12.01.2017 22:17, Jeff Law wrote:

On 01/05/2017 07:45 AM, Matthias Klose wrote:

These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
building without a system zlib.  The new release includes fixes for security
issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.

Checked with a build with disabled system-zlib. Ok for the trunk?

Were there any changes that we needed to carry forward or any changes you needed
to make to the upstream sources?


I backed out the changes to the configure* and Makefile* changes (and only
these), which are completely different to zlib upstream. There are no
additions/deletions to zlib source files, so these build changes still work with
the updated zlib.
One more note.  I think that, in general, backing out local changes 
which don't have a strong need to be carried forward is absolutely the 
right thing to do.  The less hacking we do on these libraries we pull 
from other sources, the better, IMHO.


jeff

Re: [PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c

On Wed, 11 Jan 2017, Palmer Dabbelt wrote:

> +#include 

This is included in system.h, so don't include it here.

> +  error ("unknown cpu `%s' for -mtune", cpu_string);

This is using very-old-style `' quotes.  Diagnostics should use e.g. %qs 
for quoting the output of a single % directive, or %< and %> for quoting 
anything more complicated, so that Unicode quotes can be used when the 
locale permits.

Likewise elsewhere in this patch and in patch 2.

> +#undef TARGET_LRA_P
> +#define TARGET_LRA_P hook_bool_void_true

Using LRA is the default; you shouldn't need this definition.

I don't see a definition of TARGET_ATOMIC_ASSIGN_EXPAND_FENV.  Since you 
have floating-point exceptions, I'd expect lack this to result in 
c11-atomic-exec-5.c failing.

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

Re: [patch] update zlib to the 1.2.10 release.


On 01/12/2017 02:26 PM, Matthias Klose wrote:

On 12.01.2017 22:17, Jeff Law wrote:

On 01/05/2017 07:45 AM, Matthias Klose wrote:

These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
building without a system zlib.  The new release includes fixes for security
issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.

Checked with a build with disabled system-zlib. Ok for the trunk?

Were there any changes that we needed to carry forward or any changes you needed
to make to the upstream sources?


I backed out the changes to the configure* and Makefile* changes (and only
these), which are completely different to zlib upstream. There are no
additions/deletions to zlib source files, so these build changes still work with
the updated zlib.
OK.  I'm a little concerned that we may be losing local changes -- 
though it looks like you've done this process a couple times already, so 
I'll assume you're aware of potential pitfalls.


Go ahead and install on the trunk.  If it causes problems we can't 
address quickly and safely we may have to rethink.


jeff

Re: [patch] update zlib to the 1.2.10 release.

2017-01-12 Thread Matthias Klose

On 12.01.2017 22:17, Jeff Law wrote:
> On 01/05/2017 07:45 AM, Matthias Klose wrote:
>> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used 
>> when
>> building without a system zlib.  The new release includes fixes for security
>> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
>>
>> Checked with a build with disabled system-zlib. Ok for the trunk?
> Were there any changes that we needed to carry forward or any changes you 
> needed
> to make to the upstream sources?

I backed out the changes to the configure* and Makefile* changes (and only
these), which are completely different to zlib upstream. There are no
additions/deletions to zlib source files, so these build changes still work with
the updated zlib.

Matthias

Re: [PATCH] rename -Wformat-length to -Wformat-overflow


On 01/12/2017 01:31 PM, Martin Sebor wrote:

With the move of the snprintf truncation checking from -Wformat-length
to the dedicated -Wformat-truncation option (done in r244210),
-Wformat-length isn't as descriptive as it could and should be for
an option whose sole focus is the detection of sprintf buffer overflow.

The name is also inconsistent with the name of -Wstringop-overflow
option which focuses on detecting buffer overflow by string operations
such as strcpy or memcpy.

To make the purpose of the option clearer and its name consistent with
-Wstringop-overflow the attached patch renames -Wformat-length to
-Wformat-overflow.

Thanks
Martin

gcc-wformat-overflow.diff


gcc/c-family/ChangeLog:

* c.opt (-Wformat-length): Rename...
(-Wformat-overflow): ...to this.

gcc/ChangeLog:

* doc/invoke.texi (Warning Options): Rename -Wformat-length
to -Wformat-overflow.
* gimple-ssa-sprintf.c (pass_sprintf_length::gate): Adjust.
(min_bytes_remaining): Same.
(get_string_length): Same.
(format_string): Same.
(format_directive): Same.
(add_bytes): Same.
(pass_sprintf_length::handle_gimple_call): Same.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/pr78622.c: Adjust.
* gcc.dg/pr78138.c: Adjust.
* gcc.dg/pr78768.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-4.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-8.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: Adjust.
* gcc.dg/tree-ssa/pr78605.c: Adjust.
* gcc.dg/tree-ssa/pr78622.c: Adjust.

OK with just a couple cleanups noted below.



Index: gcc/gimple-ssa-sprintf.c
===
--- gcc/gimple-ssa-sprintf.c(revision 244382)
+++ gcc/gimple-ssa-sprintf.c(working copy)
@@ -141,7 +141,7 @@ pass_sprintf_length::gate (function *)
  not optimizing and the pass is being invoked early, or when
  optimizing and the pass is being invoked during optimization
  (i.e., "late").  */
-  return ((warn_format_length > 0 || flag_printf_return_value)
+  return ((warn_format_overflow > 0 || flag_printf_return_value)
  && (optimize > 0) == fold_return_value);
 }

@@ -651,7 +651,7 @@ min_bytes_remaining (unsigned HOST_WIDE_INT navail
   if (HOST_WIDE_INT_MAX <= navail)
 return navail;

-  if (1 < warn_format_length || res.knownrange)
+  if (1 < warn_format_overflow || res.knownrange)

Go ahead and fix the operand ordering on lines you're changing.  Here.


@@ -1653,7 +1653,7 @@ get_string_length (tree str)
   fmtresult res;

   res.range.min = (tree_fits_uhwi_p (lenrange[0])
-  ? tree_to_uhwi (lenrange[0]) : 1 < warn_format_length);
+  ? tree_to_uhwi (lenrange[0]) : 1 < warn_format_overflow);

And here.


@@ -1693,12 +1693,12 @@ format_string (const conversion_spec , tree a
  to a "%lc" directive adjusted for precision but not field width.
  6 is the longest UTF-8 sequence for a single wide character.  */
   const unsigned HOST_WIDE_INT max_bytes_for_unknown_wc
-= (0 <= prec ? prec : 1 < warn_format_length ? 6 : 1);
+= (0 <= prec ? prec : 1 < warn_format_overflow ? 6 : 1);

Here.



   /* The maximum number of bytes for an unknown string argument to either
  a "%s" or "%ls" directive adjusted for precision but not field width.  */
   const unsigned HOST_WIDE_INT max_bytes_for_unknown_str
-= (0 <= prec ? prec : 1 < warn_format_length);
+= (0 <= prec ? prec : 1 < warn_format_overflow);

Here.



   /* The result is bounded unless overriddden for a non-constant string
  of an unknown length.  */
@@ -1718,7 +1718,7 @@ format_string (const conversion_spec , tree a
 is the smaller of either 0 (at level 1) or 1 (at level 2)
 and WIDTH, and the maximum is MB_CUR_MAX in the selected
 locale, which is unfortunately, unknown.  */
- res.range.min = 1 == warn_format_length ? !nul : nul < 1;
+ res.range.min = 1 == warn_format_overflow ? !nul : nul < 1;

Here.


@@ -2038,7 +2038,7 @@ format_directive (const pass_sprintf_length::call_
|| warn_format_trunc > 1))
   || (!info.bounded
   && (spec.specifier == 's'
-  || 1 < warn_format_length
+  || 1 < warn_format_overflow

Here.


{
  /* The maximum directive output is longer than there is
 room in the destination and the output length is either
@@ -2114,7

Re: [PATCH] Fix bootstrap failure on s390x-linux - ICE with __morestack side-effect jump (PR bootstrap/79069)

On Thu, Jan 12, 2017 at 02:10:39PM -0700, Jeff Law wrote:
> > 2017-01-12  Jakub Jelinek  
> > 
> > PR bootstrap/79069
> > * cfgrtl.c (rtl_tidy_fallthru_edge): For any_uncondjump_p that can't
> > be removed due to side-effects, don't remove following barrier nor
> > turn the successor edge into fallthru edge.
> Presumably it makes more sense to filter these cases out here rather than in
> the callers.

Yes.  Also, rtl_tidy_fallthru_edge filters other cases earlier too, not the
callers.

Jakub

Re: [PATCH] Optimize away useless snprintf calls with -fprintf-return-value (take 2)


On 01/10/2017 12:23 AM, Jakub Jelinek wrote:

On Mon, Jan 02, 2017 at 04:54:57PM -0700, Martin Sebor wrote:

Looks good to me, thanks!  Just a couple of suggestions:


Here is updated patch with those added comments (and adjusted for the
current trunk).  Ok for trunk?

2017-01-10  Jakub Jelinek  

* gimple-ssa-sprintf.c (try_substitute_return_value): Remove
info.nowrite calls with no lhs that can't throw.  Return bool
whether gsi_remove has been called or not.
(pass_sprintf_length::handle_gimple_call): Return bool whether
try_substitute_return_value called gsi_remove.  Formatting fix.
(pass_sprintf_length::execute): Don't use gsi_remove if
handle_gimple_call returned true.

* gcc.dg/tree-ssa/builtin-snprintf-1.c: New test.

OK.
jeff

Re: [patch] update zlib to the 1.2.10 release.


On 01/05/2017 07:45 AM, Matthias Klose wrote:

These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
building without a system zlib.  The new release includes fixes for security
issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.

Checked with a build with disabled system-zlib. Ok for the trunk?
Were there any changes that we needed to carry forward or any changes 
you needed to make to the upstream sources?


Jeff

Re: [PATCH] Fix bootstrap failure on s390x-linux - ICE with __morestack side-effect jump (PR bootstrap/79069)


On 01/12/2017 01:24 PM, Jakub Jelinek wrote:

Hi!

The RTL verification in rtl_verify_edges as well as various other routines
in cfgrtl.c etc. require that any_uncondjump_p jumps never have fallthru
edges - even if their destination is right after them, there still needs to
be barrier in between them and code_label after that.
rtl_tidy_fallthru_edge can violate this.
If
  if (JUMP_P (q)
  && onlyjump_p (q)
  && (any_uncondjump_p (q)
  || single_succ_p (b)))
it will delete also the JUMP_INSN and everything is fine, but if
any_uncondjump_p (q) is true, but onlyjump_p (q) is false, we can't remove
the jump (as is the case of the split_stack_call_ insn), but still
remove the barrier and make the edge EDGE_FALLTHRU, which then violates
the verification, or with --enable-checking=rtl, ICEs later in
fixup_reorder_chain.

The following patch avoids doing that, if it is any_uncondjump_p that can't
have fallthru edges, either we manage to remove the jump, or we don't tidy
anything.

Bootstrapped/regtested on x86_64-linux, i686-linux and bootstrapped on
s390x-linux (regtests there still ongoing).  Ok for trunk if the regtests
pass there?

2017-01-12  Jakub Jelinek  

PR bootstrap/79069
* cfgrtl.c (rtl_tidy_fallthru_edge): For any_uncondjump_p that can't
be removed due to side-effects, don't remove following barrier nor
turn the successor edge into fallthru edge.
Presumably it makes more sense to filter these cases out here rather 
than in the callers.


OK.

jeff

Re: [PATCH][GCC 5] Fix build issue with NO_FUNCTION_CSE

2017-01-12 Thread Nathan Sidwell


On 01/12/2017 12:38 PM, Kyrill Tkachov wrote:

Hi all,

This patch fixes the build issue on x86_64 (and other targets that
define NO_FUNCTION_CSE but not a particular value)
on the GCC 5 branch.


thanks!


--
Nathan Sidwell

Re: New Port for RISC-V

2017-01-12 Thread Andrew Waterman

Thank you for taking the time to give us feedback.

On Thu, Jan 12, 2017 at 9:30 AM, Joseph Myers  wrote:
> General observation: I see no documentation (no changes to .texi files)
> anywhere in this patch series.  I also don't see updates to config-list.mk
> to add RISC-V targets to the set that builds.  (You should make sure the
> port builds cleanly when built with current mainline GCC and configured
> with --enable-werror-always; config-list.mk uses --enable-werror-always
> and it's a rough way of making sure in a cross build that there aren't
> warnings that would make a native bootstrap fail.  It should build cleanly
> for both 32-bit and 64-bit hosts.)
>
> See sourcebuild.texi, "Back End", for a description of various places that
> may need updating for a new port, including lots of things that need
> documenting if your port has them (not all ports will have all those
> target-specific features).  That includes website updates.

Thanks for the pointer.  We'll write documentation, adjust the build
list, and look at sourcebuild.texi for further guidance before
submitting an updated version of the patch set.

>
> Regarding binutils support: to be clear, does 2.28 branch have all the
> features / fixes known to be required at present and will subsequent fixes
> go on there as needed?

Yes, and we will continue to apply fixes to both the trunk and the 2.28 branch.

>
> Regarding Linux kernel support: how confident are you that the signal
> frame ABI, to the extent that this patch embeds it in linux-unwind.h, will
> remain unchanged?  To what extent has that port been reviewed by Linux
> kernel people familiar with the right way to add new Linux kernel ports?

I will consult with the kernel folks on this matter.

>
> Looking at the architecture specification to resolve some questions about
> the port, I see the statement (section 7.4 Subnormal Arithmetic) "In the
> parlance of the IEEE standard, tininess is detected after rounding---that
> is, the underflow exception is raised only if the rounded result is
> subnormal, even if the unrounded result would have been subnormal.".
> That "that is" is *not* an accurate description of what after-rounding
> tininess detection means.  After-rounding tininess detection means the
> result is tiny if the result *rounded to normal precision but with
> infinite exponent range* has an exponent outside the normal range.  This
> means that some results that round to the least normal value (given the
> actual finite exponent range) count as tiny (the exact range of results
> with that property depends on the rounding mode - in round-to-nearest, for
> example, if s is the greatest subnormal and s+u is the least normal, it's
> the half-open interval [s + u/2, s + 3u/4)).  If your processor behaves as
> described in "that is", that does not conform to IEEE 754-2008 and you
> won't get clean glibc test results, for example.

That is an error in the specification; the intent is that RISC-V
implementations conform to IEEE 754-2008.  The next revision of the
spec will simply remove the "that is" clause.  Thank you for pointing
this out.

>
> I also see the architecture has roundTiesToAway support for your hardware
> binary floating point.  Do you intend to support that rounding mode from C
> code?  (I expect a fair number of glibc changes would be needed to do so,
> although the soft-fp part shouldn't be that big.)

Our expectation was that roundTiesToAway would be primarily used in
hand-written library routines, and that application code wouldn't be
interested in using it because most architectures do not provide it
for binary FP.  Perhaps that is not forward-thinking.  We will consult
with the glibc maintainers about the possibility of a RISC-V-specific
extension to the fenv API.

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

[PATCH] Emit DW_AT_data_bit_offset instead of DW_AT_{data_member_location,bit_offset,byte_size} for -gdwarf-5 (PR debug/71669)

Hi!

While DW_AT_data_bit_offset has been introduced already in DWARF4, GDB only
gained support for it last November, so I think it is better to enable this
only for -gdwarf-5 for now and we can reconsider it in a year or two.

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

2017-01-12  Jakub Jelinek  

PR debug/71669
* dwarf2out.c (add_data_member_location_attribute): For constant
offset bitfield emit for -gdwarf-5 DW_AT_data_bit_offset attribute
instead of DW_AT_data_member_location, DW_AT_bit_offset and
DW_AT_byte_size attributes.

--- gcc/dwarf2out.c.jj  2017-01-11 19:05:15.0 +0100
+++ gcc/dwarf2out.c 2017-01-12 15:08:29.842773537 +0100
@@ -18272,6 +18272,23 @@ add_data_member_location_attribute (dw_d
 
   if (! loc_descr)
 {
+  /* While DW_AT_data_bit_offset has been added already in DWARF4,
+e.g. GDB only added support to it in November 2016.  For DWARF5
+we need newer debug info consumers anyway.  We might change this
+to dwarf_version >= 4 once most consumers catched up.  */
+  if (dwarf_version >= 5
+ && TREE_CODE (decl) == FIELD_DECL
+ && DECL_BIT_FIELD_TYPE (decl))
+   {
+ tree off = bit_position (decl);
+ if (tree_fits_uhwi_p (off) && get_AT (die, DW_AT_bit_size))
+   {
+ remove_AT (die, DW_AT_byte_size);
+ remove_AT (die, DW_AT_bit_offset);
+ add_AT_unsigned (die, DW_AT_data_bit_offset, tree_to_uhwi (off));
+ return;
+   }
+   }
   if (dwarf_version > 2)
{
  /* Don't need to output a location expression, just the constant. */

Jakub

[PATCH] rename -Wformat-length to -Wformat-overflow

2017-01-12 Thread Martin Sebor


With the move of the snprintf truncation checking from -Wformat-length
to the dedicated -Wformat-truncation option (done in r244210),
-Wformat-length isn't as descriptive as it could and should be for
an option whose sole focus is the detection of sprintf buffer overflow.

The name is also inconsistent with the name of -Wstringop-overflow
option which focuses on detecting buffer overflow by string operations
such as strcpy or memcpy.

To make the purpose of the option clearer and its name consistent with
-Wstringop-overflow the attached patch renames -Wformat-length to
-Wformat-overflow.

Thanks
Martin
gcc/c-family/ChangeLog:

	* c.opt (-Wformat-length): Rename...
	(-Wformat-overflow): ...to this.

gcc/ChangeLog:

	* doc/invoke.texi (Warning Options): Rename -Wformat-length
	to -Wformat-overflow.
	* gimple-ssa-sprintf.c (pass_sprintf_length::gate): Adjust.
	(min_bytes_remaining): Same.
	(get_string_length): Same.
	(format_string): Same.
	(format_directive): Same.
	(add_bytes): Same.
	(pass_sprintf_length::handle_gimple_call): Same.

gcc/testsuite/ChangeLog:

	* gcc.c-torture/execute/pr78622.c: Adjust.
	* gcc.dg/pr78138.c: Adjust.
	* gcc.dg/pr78768.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-4.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-8.c: Adjust.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: Adjust.
	* gcc.dg/tree-ssa/pr78605.c: Adjust.
	* gcc.dg/tree-ssa/pr78622.c: Adjust.

Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt	(revision 244382)
+++ gcc/c-family/c.opt	(working copy)
@@ -520,15 +520,15 @@ Wformat-extra-args
 C ObjC C++ ObjC++ Var(warn_format_extra_args) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 1, 0)
 Warn if passing too many arguments to a function for its format string.
 
-Wformat-length
-C ObjC C++ LTO ObjC++ Warning Alias(Wformat-length=, 1, 0)
-Warn about function calls with format strings that write past the end
-of the destination region.  Same as -Wformat-length=1.
-
 Wformat-nonliteral
 C ObjC C++ ObjC++ Var(warn_format_nonliteral) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 2, 0)
 Warn about format strings that are not literals.
 
+Wformat-overflow
+C ObjC C++ LTO ObjC++ Warning Alias(Wformat-overflow=, 1, 0)
+Warn about function calls with format strings that write past the end
+of the destination region.  Same as -Wformat-overflow=1.
+
 Wformat-security
 C ObjC C++ ObjC++ Var(warn_format_security) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 2, 0)
 Warn about possible security problems with format functions.
@@ -554,8 +554,8 @@ Wformat=
 C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_format) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall, 1, 0)
 Warn about printf/scanf/strftime/strfmon format string anomalies.
 
-Wformat-length=
-C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_format_length) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 1, 0)
+Wformat-overflow=
+C ObjC C++ LTO ObjC++ Joined RejectNegative UInteger Var(warn_format_overflow) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 1, 0)
 Warn about function calls with format strings that write past the end
 of the destination region.
 
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 244382)
+++ gcc/doc/invoke.texi	(working copy)
@@ -274,8 +274,8 @@ Objective-C and Objective-C++ Dialects}.
 -Wno-div-by-zero  -Wdouble-promotion  -Wduplicated-cond @gol
 -Wempty-body  -Wenum-compare  -Wno-endif-labels  -Wexpansion-to-defined @gol
 -Werror  -Werror=*  -Wfatal-errors  -Wfloat-equal  -Wformat  -Wformat=2 @gol
--Wno-format-contains-nul  -Wno-format-extra-args  -Wformat-length=@var{n} @gol
--Wformat-nonliteral @gol
+-Wno-format-contains-nul  -Wno-format-extra-args  @gol
+-Wformat-nonliteral -Wformat-overflow=@var{n} @gol
 -Wformat-security  -Wformat-signedness  -Wformat-truncation=@var{n} @gol
 -Wformat-y2k  -Wframe-address @gol
 -Wframe-larger-than=@var{len}  -Wno-free-nonheap-object  -Wjump-misses-init @gol
@@ -3957,10 +3957,10 @@ in the case of @code{scanf} formats, this option s
 warning if the unused arguments are all pointers, since the Single
 Unix Specification says that such unused arguments are allowed.
 
-@item -Wformat-length
-@itemx -Wformat-length=@var{level}
-@opindex Wformat-length
-@opindex Wno-format-length
+@item -Wformat-overflow
+@itemx -Wformat-overflow=@var{level}
+@opindex Wformat-overflow
+@opindex Wno-format-overflow
 Warn about calls to formatted input/output functions such as @code{sprintf}
 and @code{vsprintf} that might

[PATCH] Fix bootstrap failure on s390x-linux - ICE with __morestack side-effect jump (PR bootstrap/79069)

Hi!

The RTL verification in rtl_verify_edges as well as various other routines
in cfgrtl.c etc. require that any_uncondjump_p jumps never have fallthru
edges - even if their destination is right after them, there still needs to
be barrier in between them and code_label after that.
rtl_tidy_fallthru_edge can violate this.
If
  if (JUMP_P (q)
  && onlyjump_p (q)
  && (any_uncondjump_p (q)
  || single_succ_p (b)))
it will delete also the JUMP_INSN and everything is fine, but if
any_uncondjump_p (q) is true, but onlyjump_p (q) is false, we can't remove
the jump (as is the case of the split_stack_call_ insn), but still
remove the barrier and make the edge EDGE_FALLTHRU, which then violates
the verification, or with --enable-checking=rtl, ICEs later in
fixup_reorder_chain.

The following patch avoids doing that, if it is any_uncondjump_p that can't
have fallthru edges, either we manage to remove the jump, or we don't tidy
anything.

Bootstrapped/regtested on x86_64-linux, i686-linux and bootstrapped on
s390x-linux (regtests there still ongoing).  Ok for trunk if the regtests
pass there?

2017-01-12  Jakub Jelinek  

PR bootstrap/79069
* cfgrtl.c (rtl_tidy_fallthru_edge): For any_uncondjump_p that can't
be removed due to side-effects, don't remove following barrier nor
turn the successor edge into fallthru edge.

--- gcc/cfgrtl.c.jj 2017-01-01 12:45:35.0 +0100
+++ gcc/cfgrtl.c2017-01-12 13:24:48.414579702 +0100
@@ -1794,6 +1794,10 @@ rtl_tidy_fallthru_edge (edge e)
 
   q = PREV_INSN (q);
 }
+  /* Unconditional jumps with side-effects (i.e. which we can't just delete
+ together with the barrier) should never have a fallthru edge.  */
+  else if (JUMP_P (q) && any_uncondjump_p (q))
+return;
 
   /* Selectively unlink the sequence.  */
   if (q != PREV_INSN (BB_HEAD (c)))

Jakub

[PATCH] Introduce --with-gcc-major-version-only configure option (take 2)

Hi!

On Tue, Jan 10, 2017 at 07:56:36AM +0100, Jakub Jelinek wrote:
> As I said on IRC, I think -dumpversion of 7 in this configuration is the
> right thing to do.  In GCC sources, we have 3 uses of -dumpversion,
> two of them look like:
> gcc_version := $(shell $(GOC) -dumpversion)
> ...
> toolexeclibgodir = 
> $(nover_glibgo_toolexeclibdir)/go/$(gcc_version)/$(target_alias)
> libexecsubdir = $(libexecdir)/gcc/$(target_alias)/$(gcc_version)
> (in libgo and gotools), one in config/tcl.m4 is like:
> if test "`gcc -dumpversion | awk -F. '{print 
> [$]1}'`" -lt "3" ; then
> AC_MSG_WARN([64bit mode not supported with 
> GCC < 3.2 on $system])
> which works well whether it prints 7 or 7.1.1.
> With --with-gcc-major-version-only, the spec_version is different from
> BASEVER, and -dumpversion can print just one of those, when they are not the
> same.  So, we either break users that expect they can do
> `$CC -dumpmachine`-gcc-`$CC -dumpversion`, or find out the C++ includes by
> g++ -dumpversion, etc., or we break users that expect 3 numbers separated
> by dot or 2 numbers separated by dot with optional another one.
> In the past, we have not always pointed 3 numbers, releases printed just
> major.minor, like gcc -dumpversion printed 3.0 (as mentioned in the manual).
> But the former 3.0 in the previous versioning scheme corresponds to just 7
> in the new one.  So, users that expect 3 numbers are already broken,
> and just one number is just adjusting those assumptions to the current
> versioning scheme.  Yes, we can add a new option, but IMNSHO it should
> be -dumpbaseversion or -dumpfullversion that will always print
> major.minor.patchlevel.  From the SUSE bugzilla, it looks like SUSE has
> been shipping compilers that printed just 5 or 6 for almost 2 years now,
> so hopefully some changes if needed somewhere have been already upstreamed.

Here is updated version of the patch that introduces the -dumpfullversion
option and documents better -dumpversion as well as -dumpfullversion.

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

2017-01-12  Jakub Jelinek  

PR other/79046
* configure: Regenerated.
config/
* acx.m4 (GCC_BASE_VER): New m4 function.
(ACX_TOOL_DIRS): Require GCC_BASE_VER, for
--with-gcc-major-version-only use just major number from BASE-VER.
gcc/
* configure.ac: Add GCC_BASE_VER.
* Makefile.in (version): Use @get_gcc_base_ver@ instead of cat to get
version from BASE-VER file.
(CFLAGS-gcc.o): Add -DBASEVER=$(BASEVER_s).
(gcc.o): Depend on $(BASEVER).
* common.opt (dumpfullversion): New option.
* gcc.c (driver_handle_option): Handle OPT_dumpfullversion.
* doc/invoke.texi: Document -dumpfullversion.
* doc/install.texi: Document --with-gcc-major-version-only.
* configure: Regenerated.
libatomic/
* configure.ac: Add GCC_BASE_VER.
* Makefile.am (gcc_version): Use @get_gcc_base_ver@ instead of cat to
get version from BASE-VER file.
* testsuite/Makefile.in: Regenerated.
* configure: Regenerated.
* Makefile.in: Regenerated.
libgomp/
* configure.ac: Add GCC_BASE_VER.
* Makefile.am (gcc_version): Use @get_gcc_base_ver@ instead of cat to
get version from BASE-VER file.
* testsuite/Makefile.in: Regenerated.
* configure: Regenerated.
* Makefile.in: Regenerated.
libgcc/
* configure.ac: Add GCC_BASE_VER.
* Makefile.in (version): Use @get_gcc_base_ver@ instead of cat to get
version from BASE-VER file.
* configure: Regenerated.
libssp/
* configure.ac: Add GCC_BASE_VER.
* Makefile.am (gcc_version): Use @get_gcc_base_ver@ instead of cat to
get version from BASE-VER file.
* configure: Regenerated.
* Makefile.in: Regenerated.
liboffloadmic/
* configure.ac: Add GCC_BASE_VER.
* Makefile.am (gcc_version): Use @get_gcc_base_ver@ instead of cat to
get version from BASE-VER file.
* aclocal.m4: Include ../config/acx.m4.
* configure: Regenerated.
* Makefile.in: Regenerated.
libquadmath/
* configure.ac: Add GCC_BASE_VER.
* Makefile.am (gcc_version): Use @get_gcc_base_ver@ instead of cat to
get version from BASE-VER file.
* configure: Regenerated.
* Makefile.in: Regenerated.
libmpx/
* configure.ac: Add GCC_BASE_VER.
* Makefile.am (gcc_version): Use @get_gcc_base_ver@ instead of cat to
get version from BASE-VER file.
* configure: Regenerated.
* Makefile.in: Regenerated.
libada/
* configure.ac: Add GCC_BASE_VER.
* Makefile.in (version): Use @get_gcc_base_ver@ instead of cat to get
version from BASE-VER file.
* configure: Regenerated.
lto-plugin/
* configure.ac: Add GCC_BASE_VER.

Re: Unreviewed fixincludes patch

2017-01-12 Thread Bruce Korb

*I* would certainly argue that.  I do occasionally shut down the
internet and go on vacation :).  Looks good to me, not being a Solaris
person anymore.

BTW, tiny notational/formatting thing:  the '<<-' "here text" marker says to
strip leading tabs on each line.  In other words, the following can be indented
with tabs to be more eyeball friendly (for future reference):


+fix = {
+hackname  = solaris_gets_cxx14;
+mach  = "*-*-solaris2*";
+files = "iso/stdio_iso.h";
+select= <<- _EOSelect_
+(#if __STDC_VERSION__ < 201112L)
+(extern char \*gets\(char \*\) __ATTR_DEPRECATED;)
+_EOSelect_;
+c_fix = format;
+c_fix_arg = "%1 && __cplusplus < 201402L\n%2";

Re: [patch,avr] PR78883: Implement a dummy scheduler

2017-01-12 Thread Georg-Johann Lay


Richard Sandiford schrieb:

Georg-Johann Lay  writes:

On 12.01.2017 10:00, Richard Sandiford wrote:

Georg-Johann Lay  writes:

On 04.01.2017 20:29, Jeff Law wrote:

On 01/04/2017 12:18 PM, Segher Boessenkool wrote:

On Wed, Jan 04, 2017 at 06:42:23PM +, Richard Sandiford wrote:

1. reload has a bug that no-one really wants to fix (understandable)
2. the bug is triggered by paradoxical subregs of mems
3. those subregs are normally disabled on targets that support insn
   scheduling
4. therefore, define an insn scheduler
5. we don't actually want insn scheduling, so either
   (a) make sure the insn scheduler is never actually used for insn
   scheduling, or
   (b) allow the insn scheduler to run anyway but encourage it to do
nothing
   (other than take compile time)

(4) and (5) feel like too much of a hack to me.  They're going to have
other consequences, e.g. we'll no longer give the warning:

  instruction scheduling not supported on this target machine

if users try to use -fschedule-insns.  And since we don't support
meaningful insn scheduling even after this patch, giving the warning
seems more user-friendly than dropping it.

I think the consensus is that we don't want these subregs for AVR
regardless of whether scheduling is used, and probably wouldn't want
them even without this bug.

Right, and the same is true for most targets.  Subregs of memory are not
something you want.  As rtl.texi says:


@item mem
@code{subreg}s of @code{mem} were common in earlier versions of GCC and
are still supported.  During the reload pass these are replaced by plain
@code{mem}s.  On machines that do not do instruction scheduling, use of
@code{subreg}s of @code{mem} are still used, but this is no longer
recommended.  Such @code{subreg}s are considered to be
@code{register_operand}s rather than @code{memory_operand}s before and
during reload.  Because of this, the scheduling passes cannot properly
schedule instructions with @code{subreg}s of @code{mem}, so for machines
that do scheduling, @code{subreg}s of @code{mem} should never be used.
To support this, the combine and recog passes have explicit code to
inhibit the creation of @code{subreg}s of @code{mem} when
@code{INSN_SCHEDULING} is defined.



So why not instead change the condition
used by general_operand, like we were talking about yesterday?
It seems simpler and more direct.

We should split off a new "SUBREGS_OF_MEM_ALLOWED" from !INSN_SCHEDULING,
and then probably even default it to false.

That would work for me :-)  The question in my mind would be unexpected
fallout at this point in the release process.  Maybe default it to
!INSN_SCHEDULING to minimize such fallout now, then to false for gcc-8?


jeff

Bit if we disable it, what's the point of introducing changes to combine
which come up with even more of such subregs?

For targets with scheduling, which applies to most of the targets, the
"optimization" in combine will be void as rejected by general_operand,
hence a target would have explicit paradoxical subregs in the back end
or use some home brew predicated that allow that stuff and use internal
knowledge of what combine does.

Moreover I have some problems in explaining what the new hook macro is
supposed to do:

"Disable/enable paradoxical SUBREGs of MEM in general_operands before
register allocation.  Use this hook if your back end has trouble with
paradoxical subregs of mem.  Enabled per default iff the target
provides an insn scheduler."

Sounds OK to me, but...


Who would understand this and infer from the docs whether this macro
should be used?
Who would understand this and infer from the docs whether this macro
should be used?

...how about:

---
Define this macro if you do not want predicates such as
@code{general_operand} and @code{register_operand} to accept paradoxical
@code{subreg}s of @code{mem}s before register allocation.  Early versions
of GCC treated such @code{subreg}s as register operands and required
the register allocator to load the inner @code{mem} into a temporary
register.  However, this approach effectively hid the load from
pre-allocation optimizations like CSE and scheduling and is therefore
deprecated.

As avr cannot operate on memory, it will have to load such values,
hence the conclusion would be to enable that stuff?


The point is that the load happens either way.  It's just a question
of whether it happens before register allocation (new behaviour,
selected by the macro) or whether it's left to the register allocator
itself (old behaviour, to be removed).  Doing it before RA should
help optimisation.


The macro exists so that targets can individually move to the new,
preferred, behavior before the deprecated behavior is removed.
The macro is defined by default for targets that support instruction
scheduling.

Also it appears as purely an optimization tweak, not about kicking
out expressions which ICE

Re: [RFC] combine: Handle zero_extend without subreg in change_zero_ext.

2017-01-12 Thread Dominik Vogt

On Thu, Jan 12, 2017 at 11:02:36AM -0600, Segher Boessenkool wrote:
> Hi Dominik,
> 
> Thanks for the example.  ROSBG, what a weird instruction.
> 
> On Thu, Jan 05, 2017 at 05:46:51PM +0100, Dominik Vogt wrote:
> > --- a/gcc/combine.c
> > +++ b/gcc/combine.c
> > @@ -11372,6 +11372,16 @@ change_zero_ext_src (subrtx_ptr_iterator *piter)
> >else if (GET_CODE (x) == ZERO_EXTEND
> >&& SCALAR_INT_MODE_P (mode)
> >&& REG_P (XEXP (x, 0))
> > +  && !HARD_REGISTER_P (XEXP (x, 0))
> > +  && GET_MODE_PRECISION (GET_MODE (XEXP (x, 0)))
> > + < GET_MODE_PRECISION (mode))
> > +{
> > +  /* (zero_extract (reg)) -> (and (subreg (reg) 0) (const_int)) */
> 
> s/zero_extract/zero_extend/
> 
> > * combine.c (change_zero_ext_src): Handle zero_extend without subreg.
> 
> "Handle zero_extend of a pseudo."?

k

> Okay for trunk with that.

It still needs testing.  I'll do that in a while.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH, Fortran, pr70697, v1] [Coarray] ICE on EVENT WAIT with array element UNTIL_COUNT argument

2017-01-12 Thread Jerry DeLisle

On 01/12/2017 05:43 AM, Andre Vehreschild wrote:
> Hi all,
> 
> *** this is no duplicate, but +1 in the PR#! ***
> 
> attached patch fixes the ICE by resolving the expression in UNTIL_COUNT
> correctly. The ICE was caused by the array-specification in UNTIL_COUNT not
> correctly set.
> 
> Bootstraps and regtests ok on x86_64-linux/F25. Ok for trunk and gcc-6?
> 
> - Andre
> 

OK and thanks,

Jerry

Re: [PATCH, Fortran, pr70696, v1] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

2017-01-12 Thread Jerry DeLisle

On 01/12/2017 03:45 AM, Andre Vehreschild wrote:
> Hi all,
> 
> attached patch fixes the ICE when using an event in a subroutine. The reason
> for the ICE was that the backend_decl of the symbol to event on was not set
> when accessed. The patch ensures this. Furthermore did I fix a invalid memory
> access in the caf_single lib, where to less memory was allocated in the
> registration of the event.
> 
> Bootstraps and regtests ok on x86_64-linux/F25. Ok for trunk?
> 
> Regards,
>   Andre
> 

OK and thanks.

Jerry

[Ping~]Re: [5/5][AArch64, libgcc] Runtime support for AArch64 return address signing (also attached target macros version)

2017-01-12 Thread Jiong Wang


On 06/01/17 11:47, Jiong Wang wrote:
This is the update on libgcc unwinder support according to new DWARF 
proposal.


As Joseph commented, duplication of unwind-dw2.c is not encouraged in 
libgcc,
But from this patch, you can see there are a few places we need to 
modify for
AArch64 in unwind-aarch64.c, so the file duplication approach is 
acceptable?



libgcc/

2017-01-06  Jiong Wang  

* config/aarch64/unwind-aarch64.c (DWARF_REGNUM_AARCH64_RA_STATE,
RA_A_SIGNED_BIT): New macros.
(execute_cfa_program): Multiplex DW_CFA_GNU_window_save on 
AArch64.
(uw_frame_state_for): Clear bit[0] of 
DWARF_REGNUM_AARCH64_RA_STATE.

(uw_update_context): Authenticate return address according to
DWARF_REGNUM_AARCH64_RA_STATE.
(uw_init_context_1): Strip signature of seed address.
(uw_install_context): Re-authenticate EH handler's address.


Ping~

For comparision, I have also attached the patch using the target macros.

Four new target macros are introduced:

  MD_POST_EXTRACT_ROOT_ADDR
  MD_POST_EXTRACT_FRAME_ADDR
  MD_POST_FROB_EH_HANDLER_ADDR
  MD_POST_INIT_CONTEXT

MD_POST_EXTRACT_ROOT_ADDR is to do target private post processing on the address
inside _Unwind* functions, they are serving as root address to start the
unwinding.  MD_POST_EXTRACT_FRAME_ADDR is to do target private post processing
on th address inside the real user program which throws the exceptions.

MD_POST_FROB_EH_HANDLER_ADDR is to do target private frob on the EH handler's
address before we install it into current context.

MD_POST_INIT_CONTEXT it to do target private initialization on the context
structure after common initialization.

One "__aarch64__" macro check is needed to multiplex DW_CFA_window_save.

libgcc/ChangeLog:

2017-01-11  Jiong Wang  

* config/aarch64/aarch64-unwind.h: New file.
(DWARF_REGNUM_AARCH64_RA_STATE): Define.
(MD_POST_EXTRACT_ROOT_ADDR): Define.
(MD_POST_EXTRACT_FRAME_ADDR): Define.
(MD_POST_FROB_EH_HANDLER_ADDR): Define.
(MD_POST_INIT_CONTEXT): Define.
* config/aarch64/linux-unwind.h: Include aarch64-unwind.h
* config.host (aarch64*-*-elf, aarch64*-*-rtems*, aarch64*-*-freebsd*):
Initialize md_unwind_header to include aarch64-unwind.h.
* unwind-dw2.c (struct _Unwind_Context): Define "RA_A_SIGNED_BIT".
(execute_cfa_program): Multiplex DW_CFA_GNU_window_save for __aarch64__.
(uw_update_context): Honor MD_POST_EXTRACT_FRAME_ADDR.
(uw_init_context_1): Honor MD_POST_EXTRACT_ROOT_ADDR and
MD_POST_INIT_CONTEXT.
(uw_frob_return_addr): New function.
(_Unwind_DebugHook): Use uw_frob_return_addr.

diff --git a/libgcc/unwind-dw2.c b/libgcc/unwind-dw2.c
index 8085a42ace15d53f4cb0c6681717012d906a6d47..35010a4065bb83f706701cb05392193f0ffa1f11 100644
--- a/libgcc/unwind-dw2.c
+++ b/libgcc/unwind-dw2.c
@@ -136,6 +136,8 @@ struct _Unwind_Context
 #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
   /* Context which has version/args_size/by_value fields.  */
 #define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 >> 2) + 1)
+  /* Bit reserved on AArch64, return address has been signed with A key.  */
+#define RA_A_SIGNED_BIT ((~(_Unwind_Word) 0 >> 3) + 1)
   _Unwind_Word flags;
   /* 0 for now, can be increased when further fields are added to
  struct _Unwind_Context.  */
@@ -1185,6 +1187,11 @@ execute_cfa_program (const unsigned char *insn_ptr,
 	  break;
 
 	case DW_CFA_GNU_window_save:
+#ifdef __aarch64__
+	  /* This CFA is multiplexed with Sparc.  On AArch64 it's used to toggle
+	 return address signing status.  */
+	  fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
+#else
 	  /* ??? Hardcoded for SPARC register window configuration.  */
 	  if (__LIBGCC_DWARF_FRAME_REGISTERS__ >= 32)
 	for (reg = 16; reg < 32; ++reg)
@@ -1192,6 +1199,7 @@ execute_cfa_program (const unsigned char *insn_ptr,
 		fs->regs.reg[reg].how = REG_SAVED_OFFSET;
 		fs->regs.reg[reg].loc.offset = (reg - 16) * sizeof (void *);
 	  }
+#endif
 	  break;
 
 	case DW_CFA_GNU_args_size:
@@ -1513,10 +1521,15 @@ uw_update_context (struct _Unwind_Context *context, _Unwind_FrameState *fs)
stack frame.  */
 context->ra = 0;
   else
-/* Compute the return address now, since the return address column
-   can change from frame to frame.  */
-context->ra = __builtin_extract_return_addr
-  (_Unwind_GetPtr (context, fs->retaddr_column));
+{
+  /* Compute the return address now, since the return address column
+	 can change from frame to frame.  */
+  context->ra = __builtin_extract_return_addr
+	(_Unwind_GetPtr (context, fs->retaddr_column));
+#ifdef MD_POST_EXTRACT_FRAME_ADDR
+  context->ra = MD_POST_EXTRACT_FRAME_ADDR (context, fs, context->ra);
+#endif
+}
 }
 
 static void
@@ -1550,6 +1563,9 @@ uw_init_context_1 (struct _Unwind_Context *context,
 		   void *outer_cfa,

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On Thu, 12 Jan 2017, Jakub Jelinek wrote:

> Well, we need some suffix that will not clash with C++ mandated udlits
> very soon, it is already bad that i and Q suffixes are problematic.
> By sN, did you mean s128 or literally sN?
> I've googled around a little bit and only found comments about
> 1ui64 and 1i64 suffixes, so that would mean accepting instead of l/L
> i128 or I128.

i128 and I128 seem reasonable as a user-visible C extension (they could of 
course be mixed in any order with u, U for unsigned, and with i, I, j, J 
for imaginary numbers).  I don't know what's appropriate for C++.

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

Re: [PATCH] builtin expansion of strncmp for rs6000

On Thu, 15 Dec 2016, Aaron Sawdey wrote:

> +  emit_library_call_value (gen_rtx_SYMBOL_REF (Pmode, "strncmp"),
> +target, LCT_NORMAL, GET_MODE (target), 3,
> +force_reg (Pmode, XEXP (src1, 0)), Pmode,
> +force_reg (Pmode, XEXP (src2, 0)), Pmode,
> +len_rtx, GET_MODE (len_rtx));

Building glibc with GCC mainline for powerpc64le-linux-gnu (from my bot 
doing such builds and compilation parts of the testsuite for all GNU/Linux 
glibc ABIs daily), I'm seeing a failure of the elf/check-localplt test, 
"Extra PLT reference: libc.so: strncmp".

Without having bisected, I suspect this patch of being a likely cause of 
that failure.  glibc redirects internal calls to use hidden aliases such 
as __GI_strncmp to avoid them going through the PLT.  By using 
gen_rtx_SYMBOL_REF there with a hardcoded function name "strncmp", this 
code looks like it would render a declaration of strncmp with asm 
("__GI_strncmp") ineffective, generating a direct call to strncmp when 
glibc expects __GI_strncmp to be called instead.

I don't know how readily this code can be made to respect asm renaming of 
strncmp.  If it's hard to fix in GCC, I suppose glibc needs a powerpc 
version of symbol-hacks.h to handle this redirection.

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

[PATCH][GCC 5] Fix build issue with NO_FUNCTION_CSE

2017-01-12 Thread Kyrill Tkachov


Hi all,

This patch fixes the build issue on x86_64 (and other targets that define 
NO_FUNCTION_CSE but not a particular value)
on the GCC 5 branch.

Tested on x86_64.
Committing to the branch in the interest of fixing the build.

Thanks,
Kyrill

2016-01-12  Kyrylo Tkachov  

* postreload.c (reload_cse_simplify): Check for NO_FUNCTION_CSE
definition instead of using it directly.
diff --git a/gcc/postreload.c b/gcc/postreload.c
index ba6591d..fc0499a 100644
--- a/gcc/postreload.c
+++ b/gcc/postreload.c
@@ -122,8 +122,10 @@ reload_cse_simplify (rtx_insn *insn, rtx testreg)
 
   /* If NO_FUNCTION_CSE has been set by the target, then we should not try
  to cse function calls.  */
-  if (NO_FUNCTION_CSE && CALL_P (insn))
+#ifdef NO_FUNCTION_CSE
+  if (CALL_P (insn))
 return false;
+#endif
 
   if (GET_CODE (body) == SET)
 {

[PATCH, i386 testsuite]: Check all supported __builtin_cpu_supports options

2017-01-12 Thread Uros Bizjak

Hello!

Attached patch checks all supported __builtin_cpu_supports options.
Additionally, it adds a couple of comments and moves some code to
prevent future mistakes.

2017-01-12  Uros Bizjak  

* gcc.target/i386/builtin_target.c (check_features): Check all
supported __builtin_cpu_supports options.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: gcc/config/i386/cpuid.h
===
--- gcc/config/i386/cpuid.h (revision 244369)
+++ gcc/config/i386/cpuid.h (working copy)
@@ -47,7 +47,7 @@
 #define bit_SSE(1 << 25)
 #define bit_SSE2   (1 << 26)
 
-/* Extended Features */
+/* Extended Features (%eax == 0x8001) */
 /* %ecx */
 #define bit_LAHF_LM(1 << 0)
 #define bit_ABM(1 << 5)
@@ -54,7 +54,6 @@
 #define bit_SSE4a  (1 << 6)
 #define bit_PRFCHW (1 << 8)
 #define bit_XOP (1 << 11)
-#define bit_AVX512VPOPCNTDQ(1 << 14)
 #define bit_LWP(1 << 15)
 #define bit_FMA4(1 << 16)
 #define bit_TBM (1 << 21)
@@ -61,14 +60,12 @@
 #define bit_MWAITX  (1 << 29)
 
 /* %edx */
-#define bit_AVX5124VNNIW (1 << 2)
-#define bit_AVX5124FMAPS (1 << 3)
 #define bit_MMXEXT (1 << 22)
 #define bit_LM (1 << 29)
 #define bit_3DNOWP (1 << 30)
 #define bit_3DNOW  (1 << 31)
 
-/* %ebx.  */
+/* %ebx  */
 #define bit_CLZERO (1 << 0)
 
 /* Extended Features (%eax == 7) */
@@ -100,7 +97,12 @@
 #define bit_AVX512VBMI (1 << 1)
 #define bit_PKU(1 << 3)
 #define bit_OSPKE  (1 << 4)
+#define bit_AVX512VPOPCNTDQ(1 << 14)
 
+/* %edx */
+#define bit_AVX5124VNNIW (1 << 2)
+#define bit_AVX5124FMAPS (1 << 3)
+
 /* XFEATURE_ENABLED_MASK register bits (%eax == 13, %ecx == 0) */
 #define bit_BNDREGS (1 << 3)
 #define bit_BNDCSR  (1 << 4)
Index: gcc/testsuite/gcc.target/i386/builtin_target.c
===
--- gcc/testsuite/gcc.target/i386/builtin_target.c  (revision 244369)
+++ gcc/testsuite/gcc.target/i386/builtin_target.c  (working copy)
@@ -163,6 +163,9 @@
 check_features (unsigned int ecx, unsigned int edx,
int max_cpuid_level)
 {
+  unsigned int eax, ebx;
+  unsigned int ext_level;
+
   if (edx & bit_CMOV)
 assert (__builtin_cpu_supports ("cmov"));
   if (edx & bit_MMX)
@@ -187,18 +190,27 @@
 assert (__builtin_cpu_supports ("sse4.2"));
   if (ecx & bit_AVX)
 assert (__builtin_cpu_supports ("avx"));
+  if (ecx & bit_FMA)
+assert (__builtin_cpu_supports ("fma"));
 
   /* Get advanced features at level 7 (eax = 7, ecx = 0).  */
   if (max_cpuid_level >= 7)
 {
-  unsigned int eax, ebx, ecx, edx;
   __cpuid_count (7, 0, eax, ebx, ecx, edx);
+  if (ebx & bit_BMI)
+   assert (__builtin_cpu_supports ("bmi"));
   if (ebx & bit_AVX2)
assert (__builtin_cpu_supports ("avx2"));
+  if (ebx & bit_BMI2)
+   assert (__builtin_cpu_supports ("bmi2"));
   if (ebx & bit_AVX512F)
assert (__builtin_cpu_supports ("avx512f"));
   if (ebx & bit_AVX512VL)
assert (__builtin_cpu_supports ("avx512vl"));
+  if (ebx & bit_AVX512BW)
+   assert (__builtin_cpu_supports ("avx512bw"));
+  if (ebx & bit_AVX512DQ)
+   assert (__builtin_cpu_supports ("avx512dq"));
   if (ebx & bit_AVX512CD)
assert (__builtin_cpu_supports ("avx512cd"));
   if (ebx & bit_AVX512PF)
@@ -205,21 +217,32 @@
assert (__builtin_cpu_supports ("avx512pf"));
   if (ebx & bit_AVX512ER)
assert (__builtin_cpu_supports ("avx512er"));
-  if (ebx & bit_AVX512BW)
-   assert (__builtin_cpu_supports ("avx512bw"));
-  if (ebx & bit_AVX512DQ)
-   assert (__builtin_cpu_supports ("avx512dq"));
-  if (ecx & bit_AVX512IFMA)
+  if (ebx & bit_AVX512IFMA)
assert (__builtin_cpu_supports ("avx512ifma"));
   if (ecx & bit_AVX512VBMI)
assert (__builtin_cpu_supports ("avx512vbmi"));
+  if (ecx & bit_AVX512VPOPCNTDQ)
+   assert (__builtin_cpu_supports ("avx512vpopcntdq"));
   if (edx & bit_AVX5124VNNIW)
assert (__builtin_cpu_supports ("avx5124vnniw"));
   if (edx & bit_AVX5124FMAPS)
assert (__builtin_cpu_supports ("avx5124fmaps"));
-  if (ecx & bit_AVX512VPOPCNTDQ)
-   assert (__builtin_cpu_supports ("avx512vpopcntdq"));
 }
+
+  /* Check cpuid level of extended features.  */
+  __cpuid (0x8000, ext_level, ebx, ecx, edx);
+
+  if (ext_level >= 0x8001)
+{
+  __cpuid (0x8001, eax, ebx, ecx, edx);
+
+  if (ecx & bit_SSE4a)
+   assert (__builtin_cpu_supports ("sse4a"));
+  if (ecx & bit_FMA4)
+   assert (__builtin_cpu_supports ("fma4"));
+  if (ecx & bit_XOP)
+   assert (__builtin_cpu_supports ("xop"));
+}
 }
 
 static int __attribute__ ((noinline))
Index: libgcc/config/i386/cpuinfo.c

Re: New Port for RISC-V

General observation: I see no documentation (no changes to .texi files) 
anywhere in this patch series.  I also don't see updates to config-list.mk 
to add RISC-V targets to the set that builds.  (You should make sure the 
port builds cleanly when built with current mainline GCC and configured 
with --enable-werror-always; config-list.mk uses --enable-werror-always 
and it's a rough way of making sure in a cross build that there aren't 
warnings that would make a native bootstrap fail.  It should build cleanly 
for both 32-bit and 64-bit hosts.)

See sourcebuild.texi, "Back End", for a description of various places that 
may need updating for a new port, including lots of things that need 
documenting if your port has them (not all ports will have all those 
target-specific features).  That includes website updates.

Regarding binutils support: to be clear, does 2.28 branch have all the 
features / fixes known to be required at present and will subsequent fixes 
go on there as needed?

Regarding Linux kernel support: how confident are you that the signal 
frame ABI, to the extent that this patch embeds it in linux-unwind.h, will 
remain unchanged?  To what extent has that port been reviewed by Linux 
kernel people familiar with the right way to add new Linux kernel ports?

Looking at the architecture specification to resolve some questions about 
the port, I see the statement (section 7.4 Subnormal Arithmetic) "In the 
parlance of the IEEE standard, tininess is detected after rounding---that 
is, the underflow exception is raised only if the rounded result is 
subnormal, even if the unrounded result would have been subnormal.".  
That "that is" is *not* an accurate description of what after-rounding 
tininess detection means.  After-rounding tininess detection means the 
result is tiny if the result *rounded to normal precision but with 
infinite exponent range* has an exponent outside the normal range.  This 
means that some results that round to the least normal value (given the 
actual finite exponent range) count as tiny (the exact range of results 
with that property depends on the rounding mode - in round-to-nearest, for 
example, if s is the greatest subnormal and s+u is the least normal, it's 
the half-open interval [s + u/2, s + 3u/4)).  If your processor behaves as 
described in "that is", that does not conform to IEEE 754-2008 and you 
won't get clean glibc test results, for example.

I also see the architecture has roundTiesToAway support for your hardware 
binary floating point.  Do you intend to support that rounding mode from C 
code?  (I expect a fair number of glibc changes would be needed to do so, 
although the soft-fp part shouldn't be that big.)

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

Re: [PATCH] PR77528 add default constructors for container adaptors

2017-01-12 Thread Jonathan Wakely


On 11/01/17 13:25 +, Jonathan Wakely wrote:

On 11/01/17 08:04 -0500, Tim Song wrote:

On Wed, Jan 11, 2017 at 7:21 AM, Jonathan Wakely  wrote:

This patch uses the _Enable_default_constructor mixin to properly
delete the default constructors. It's a bit cumbersome, because we
have to add an initializer for the base class to every
ctor-initializer-list, but I think I prefer this to making the default
constructor a constrained template.



I'm happy with either approach - my primary concern is making sure
that is_constructible and friends work and don't lie, in a world where
increasing numbers of library components depend on it. Though I'm a


Yes, it's important that we give the right answer.


bit curious as to why you found this approach more preferable.


I dislike making functions into templates when they aren't "supposed"
to be. But I'm in two minds for this case. It's certainly a smaller,
more self-contained change to just add a default constructor template
and not mess about with a new base class and DMIs and all those
mem-initializers.


Re the new DMI, my brain compiler says that _Sequence c = _Sequence();
breaks anything with an explicit copy/move constructor pre-C++17, but
I also don't think we care about those, right?


I dislike them, but maybe the fact they won't work here is a strong
enough reason to get over my dislike of the original approach and just
do it that way instead.


I decided to go with the original solution shown in the PR.

Tested powerpc64le-linux, committed to trunk.

commit b4614f1ef1a9c98650f2454332bb1407cddff13c
Author: Jonathan Wakely 
Date:   Thu Jan 12 15:37:27 2017 +

PR77528 partially revert r244278 and define default constructors

	PR libstdc++/77528
	* include/bits/stl_queue.h (queue, priority_queue): Remove default
	member-initializers and define default constructors as templates with
	constraints.
	* include/bits/stl_stack.h (stack): Likewise.
	* testsuite/23_containers/priority_queue/requirements/constructible.cc:
	New.
	* testsuite/23_containers/priority_queue/requirements/
	explicit_instantiation/1.cc: Test more instantiations.
	* testsuite/23_containers/priority_queue/requirements/
	explicit_instantiation/1_c++98.cc: Likewise.
	* testsuite/23_containers/queue/requirements/constructible.cc: New.
	* testsuite/23_containers/stack/requirements/constructible.cc: New.

diff --git a/libstdc++-v3/include/bits/stl_queue.h b/libstdc++-v3/include/bits/stl_queue.h
index 6417b30..3a52367 100644
--- a/libstdc++-v3/include/bits/stl_queue.h
+++ b/libstdc++-v3/include/bits/stl_queue.h
@@ -131,12 +131,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  of private: to allow derivation.  But none of the other
*  containers allow for derivation.  Odd.)
*/
-  /// @c c is the underlying container.
-#if __cplusplus >= 201103L
-  _Sequence c{};
-#else
+   ///  @c c is the underlying container.
   _Sequence c;
-#endif
 
 public:
   /**
@@ -147,7 +143,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   queue(const _Sequence& __c = _Sequence())
   : c(__c) { }
 #else
-  queue() = default;
+  template::value>::type>
+	queue()
+	: c() { }
 
   explicit
   queue(const _Sequence& __c)
@@ -446,13 +445,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 protected:
   //  See queue::c for notes on these names.
-#if __cplusplus >= 201103L
-  _Sequence c{};
-  _Compare   comp{};
-#else
-  _Sequence c;
+  _Sequence  c;
   _Compare   comp;
-#endif
 
 public:
   /**
@@ -465,17 +459,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   : c(__s), comp(__x)
   { std::make_heap(c.begin(), c.end(), comp); }
 #else
-  priority_queue() = default;
+  template,
+is_default_constructible<_Seq>>::value>::type>
+	priority_queue()
+	: c(), comp() { }
 
   explicit
-  priority_queue(const _Compare& __x,
-		 const _Sequence& __s)
+  priority_queue(const _Compare& __x, const _Sequence& __s)
   : c(__s), comp(__x)
   { std::make_heap(c.begin(), c.end(), comp); }
 
   explicit
-  priority_queue(const _Compare& __x,
-		 _Sequence&& __s = _Sequence())
+  priority_queue(const _Compare& __x, _Sequence&& __s = _Sequence())
   : c(std::move(__s)), comp(__x)
   { std::make_heap(c.begin(), c.end(), comp); }
 
diff --git a/libstdc++-v3/include/bits/stl_stack.h b/libstdc++-v3/include/bits/stl_stack.h
index a0f9ee5..094ce65 100644
--- a/libstdc++-v3/include/bits/stl_stack.h
+++ b/libstdc++-v3/include/bits/stl_stack.h
@@ -129,11 +129,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 protected:
   //  See queue::c for notes on this name.
-#if __cplusplus >= 201103L
-  _Sequence c{};
-#else
   _Sequence c;
-#endif
 
 public:
   // XXX removed old def ctor, added def arg to this one to match 14882
@@ -145,7 +141,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

Re: [RFC] combine: Handle zero_extend without subreg in change_zero_ext.

2017-01-12 Thread Segher Boessenkool

Hi Dominik,

Thanks for the example.  ROSBG, what a weird instruction.

On Thu, Jan 05, 2017 at 05:46:51PM +0100, Dominik Vogt wrote:
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -11372,6 +11372,16 @@ change_zero_ext_src (subrtx_ptr_iterator *piter)
>else if (GET_CODE (x) == ZERO_EXTEND
>  && SCALAR_INT_MODE_P (mode)
>  && REG_P (XEXP (x, 0))
> +&& !HARD_REGISTER_P (XEXP (x, 0))
> +&& GET_MODE_PRECISION (GET_MODE (XEXP (x, 0)))
> +   < GET_MODE_PRECISION (mode))
> +{
> +  /* (zero_extract (reg)) -> (and (subreg (reg) 0) (const_int)) */

s/zero_extract/zero_extend/

>   * combine.c (change_zero_ext_src): Handle zero_extend without subreg.

"Handle zero_extend of a pseudo."?

Okay for trunk with that.  Thanks for the patch,


Segher

Re: [PATCH] Add Cortex-A15 tuning to gcc.dg/uninit-pred-8_a.c

On Thu, Jan 12, 2017 at 04:56:11PM +, Kyrill Tkachov wrote:
> Hi all,
> 
> As discussed in the PR it's better to pin down the tuning for arm targets on 
> this test so that the BRANCH_COST remains constant.
> This makes the test more stable across toolchains configured for different 
> default CPUs.
> 
> Ok to apply?
> 
> Thanks,
> Kyrill
> 
> 2017-01-12  Kyrylo Tkachov  
> 
> PR tree-optimization/78319
> * gcc.dg/uninit-pred-8_a.c: Add -mtune=cortex-a15 for arm.
> Remove xfail.

Ok, thanks.

Jakub

[PATCH] Add Cortex-A15 tuning to gcc.dg/uninit-pred-8_a.c

2017-01-12 Thread Kyrill Tkachov


Hi all,

As discussed in the PR it's better to pin down the tuning for arm targets on 
this test so that the BRANCH_COST remains constant.
This makes the test more stable across toolchains configured for different 
default CPUs.

Ok to apply?

Thanks,
Kyrill

2017-01-12  Kyrylo Tkachov  

PR tree-optimization/78319
* gcc.dg/uninit-pred-8_a.c: Add -mtune=cortex-a15 for arm.
Remove xfail.
diff --git a/gcc/testsuite/gcc.dg/uninit-pred-8_a.c b/gcc/testsuite/gcc.dg/uninit-pred-8_a.c
index c45fba0..c4cdf48 100644
--- a/gcc/testsuite/gcc.dg/uninit-pred-8_a.c
+++ b/gcc/testsuite/gcc.dg/uninit-pred-8_a.c
@@ -1,6 +1,8 @@
 
 /* { dg-do compile } */
 /* { dg-options "-Wuninitialized -O2" } */
+/* Pick a particular tuning to pin down BRANCH_COST.  */
+/* { dg-additional-options "-mtune=cortex-a15" { target arm*-*-* } } */
 
 int g;
 void bar();
@@ -16,9 +18,8 @@ int foo (int n, int l, int m, int r)
   if (m) g++;
   else   bar();
 
-  /* marking this test as xfail on arm-none-eabi, see PR78319.  */
   if ( n ||  m || r || l)
-  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail arm-none-eabi } } */
+  blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
 
   if ( n )
   blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On January 12, 2017 4:53:54 PM GMT+01:00, Jakub Jelinek  
wrote:
>On Thu, Jan 12, 2017 at 04:45:41PM +0100, Marc Glisse wrote:
>> > On Thu, 12 Jan 2017, Jakub Jelinek wrote:
>> > 
>> > > On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
>> > > > It also lacks expressiveness when comparing
>> > > > 
>> > > >   short s;
>> > > >   s_1 = (short) 1;
>> > > >   s_2 = short (1);
>> > > > 
>> > > > IMHO having a _Literal somewhere makes it more obvious what is
>meant
>> > > > (I'm still going to dump 1u or 1l instead of _Literal
>(unsigned) 1
>> > > > of course as that's even more easy to recognize).
>> > > 
>> > > So, with the _Literal (type) constant syntax, what are we going
>to emit
>> > > and parse for __int128 constants?
>> > > _Literal (__int128) (0x123456ULL << 64 || 0x123456ULL), something
>else?
>> > 
>> > Yes, unless we teach libcpp about larger than 64bit literals.
>> 
>> Teaching libcpp about 128bit literals sounds like a much nicer idea
>> indeed...
>
>Well, we need some suffix that will not clash with C++ mandated udlits
>very soon, it is already bad that i and Q suffixes are problematic.
>By sN, did you mean s128 or literally sN?
>I've googled around a little bit and only found comments about
>1ui64 and 1i64 suffixes, so that would mean accepting instead of l/L
>i128 or I128.

Indeed i64 and ui64 it was, found referenced on some stack overflow post.  
There was i16 and ui16 as well, can't see i128 mentioned there though.

Richard.

>
>   Jakub

Re: [PATCH] Fix DW_AT_data_member_location/DW_AT_bit_offset handling (PR debug/78839)

On Thu, Jan 12, 2017 at 05:42:55PM +0100, Pierre-Marie de Rodat wrote:
> > +  object_offset_in_bytes
> > +   = wi::lrshift (object_offset_in_bits, LOG2_BITS_PER_UNIT);
> > +  if (ctx->variant_part_offset == NULL_TREE)
> > +   {
> > + *cst_offset = object_offset_in_bytes.to_shwi ();
> > + return NULL;
> > +   }
> > +  tree_result = wide_int_to_tree (sizetype, object_offset_in_bytes);
> 
> I don’t understand this special case: IIUC, if this IF block was missing,
> the flow would make this function return the same result thanks to the
> similar IF block several lines below. Is it to avoid the conversions to
> tree/wide int/HOST_WIDE_INT (i.e. an optimization)?

Yes, the if (ctx->variant_part_offset == NULL_TREE) block is optimization
for the most common case.

Jakub

Re: [PATCH] Fix DW_AT_data_member_location/DW_AT_bit_offset handling (PR debug/78839)

2017-01-12 Thread Pierre-Marie de Rodat


Jakub,

On 01/11/2017 09:19 PM, Jakub Jelinek wrote:

In GCC 5 and earlier, field_byte_offset had code for
PCC_BITFIELD_TYPE_MATTERS target that figured out what
DW_AT_data_member_location value to use vs. DW_AT_bit_offset.

That code is still in there, but due to several bugs added in r231762
it never triggers anymore.


I totally plead guilty for this! When I originally patched this 
function, something like 3 years ago, I had a hard time trying to 
understand it (in retrospect, I probably failed that), tried various 
things, had headaches while thinking about variable bit offsets, and 
then IIRC saw no regression in GCC or GDB’s testsuite, so stopped 
worrying and submitted my patch for review.


… anyway that’s it for the context. So thank you very much for working 
on this!



The following patch fixes all this and restores the GCC 5 behavior.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


FWIW, this patch triggers no regression in my DWARF/Ada testsuite.


+  object_offset_in_bytes
+   = wi::lrshift (object_offset_in_bits, LOG2_BITS_PER_UNIT);
+  if (ctx->variant_part_offset == NULL_TREE)
+   {
+ *cst_offset = object_offset_in_bytes.to_shwi ();
+ return NULL;
+   }
+  tree_result = wide_int_to_tree (sizetype, object_offset_in_bytes);


I don’t understand this special case: IIUC, if this IF block was 
missing, the flow would make this function return the same result thanks 
to the similar IF block several lines below. Is it to avoid the 
conversions to tree/wide int/HOST_WIDE_INT (i.e. an optimization)?


--
Pierre-Marie de Rodat

[Ada] Conformance of quantified expressions

This patch implements AI12-050, which extends the conformance rules to Ada2012
quantified expressions. Previously the conformance of corresponding identifiers
in the two expressions required that they denote the same entity. The loop
parameters of two quantified expressions are conformant if the identifiers are
the same, even though they denote different entities.

The following must compile quietly:

   gcc -c quantified_expressions.adb
   gcc -c -gnatc quantified_expressions.adb

---
with Support; use Support;
package Quantified_Expressions is

   procedure Matrix_Processing
 (M : in out Matrix;
  B :Boolean := (for all I in Ind =>
   (for some J in Ind =>
   Sample_Matrix (I, J) = 0)));
end Quantified_Expressions;
---
package body Quantified_Expressions is


   procedure Matrix_Processing
 (M : in out Matrix;
  B :Boolean := (for all I in Ind =>
   (for some J in Ind =>
   Sample_Matrix (I, J) = 0)))
   is
   begin
  null;
   end Matrix_Processing;

end Quantified_Expressions;

---
with Ada.Containers.Vectors;

package Support is

   subtype Ind is Integer range 1 .. 10;

   type Matrix is array (Ind, Ind) of Integer;

   Sample_Matrix : Matrix;
end Support;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-12  Ed Schonberg  

* sem_ch6.adb (Fully_Conformant_Expressions): Handle properly
quantified expressions, following AI12-050: the loop parameters
of two quantified expressions are conformant if they have the
same identifier.

Index: sem_ch6.adb
===
--- sem_ch6.adb (revision 244352)
+++ sem_ch6.adb (working copy)
@@ -8476,10 +8476,22 @@
   elsif Is_Entity_Name (E1) and then Is_Entity_Name (E2) then
  if Present (Entity (E1)) then
 return Entity (E1) = Entity (E2)
+
+  --  One may be a discriminant that has been replaced by
+  --  the correspondding discriminal
+
   or else (Chars (Entity (E1)) = Chars (Entity (E2))
 and then Ekind (Entity (E1)) = E_Discriminant
-and then Ekind (Entity (E2)) = E_In_Parameter);
+and then Ekind (Entity (E2)) = E_In_Parameter)
 
+ --  AI12-050 : the loop variables of quantified expressions
+ --  match if the have the same identifier, even though they
+ --  are different entities.
+
+  or else (Chars (Entity (E1)) = Chars (Entity (E2))
+   and then Ekind (Entity (E1)) = E_Loop_Parameter
+   and then Ekind (Entity (E2)) = E_Loop_Parameter);
+
  elsif Nkind (E1) = N_Expanded_Name
and then Nkind (E2) = N_Expanded_Name
and then Nkind (Selector_Name (E1)) = N_Character_Literal

[Ada] Adapt detection of errors to gnat2why changes of Warning_Mode

In gnat2why, the executable used in GNATprove, Warning_Mode is changed
between the initial and final work done in frontend (controlled by -gnatws
in particular) and the work in between done in gnat2why (controlled by
GNATprove switch --warnings). This requires storing the detection of an
error related to warnings treated as errors between all phases.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-12  Yannick Moy  

* errout.adb, errout.ads (Initialize): Factor common treatment
in Reset_Warnings.
(Reset_Warnings): New procedure to reset counts related to warnings.
(Record_Compilation_Errors): New variable to store the presence of an
error, used in gnat2why to allow changing the Warning_Mode.
(Compilation_Errors): Use new variable Record_Compilation_Errors to
store the presence of an error.

Index: errout.adb
===
--- errout.adb  (revision 244352)
+++ errout.adb  (working copy)
@@ -60,6 +60,13 @@
Finalize_Called : Boolean := False;
--  Set True if the Finalize routine has been called
 
+   Record_Compilation_Errors : Boolean := False;
+   --  Record that a compilation error was witnessed during a given phase of
+   --  analysis for gnat2why. This is needed as Warning_Mode is modified twice
+   --  in gnat2why, hence Erroutc.Compilation_Errors can only return a suitable
+   --  value for each phase of analysis separately. This is updated at each
+   --  call to Compilation_Errors.
+
Warn_On_Instance : Boolean;
--  Flag set true for warning message to be posted on instance
 
@@ -236,8 +243,17 @@
begin
   if not Finalize_Called then
  raise Program_Error;
+
+  --  Record that a compilation error was witnessed during a given phase of
+  --  analysis for gnat2why. This is needed as Warning_Mode is modified
+  --  twice in gnat2why, hence Erroutc.Compilation_Errors can only return a
+  --  suitable value for each phase of analysis separately.
+
   else
- return Erroutc.Compilation_Errors;
+ Record_Compilation_Errors := Record_Compilation_Errors or else
+   Erroutc.Compilation_Errors;
+
+ return Record_Compilation_Errors;
   end if;
end Compilation_Errors;
 
@@ -1615,13 +1631,13 @@
   Last_Error_Msg := No_Error_Msg;
   Serious_Errors_Detected := 0;
   Total_Errors_Detected := 0;
-  Warnings_Treated_As_Errors := 0;
-  Warnings_Detected := 0;
-  Info_Messages := 0;
-  Warnings_As_Errors_Count := 0;
   Cur_Msg := No_Error_Msg;
   List_Pragmas.Init;
 
+  --  Reset counts for warnings
+
+  Reset_Warnings;
+
   --  Initialize warnings tables
 
   Warnings.Init;
@@ -2357,6 +2373,18 @@
   end if;
end Remove_Warning_Messages;
 
+   
+   -- Reset_Warnings --
+   
+
+   procedure Reset_Warnings is
+   begin
+  Warnings_Treated_As_Errors := 0;
+  Warnings_Detected := 0;
+  Info_Messages := 0;
+  Warnings_As_Errors_Count := 0;
+   end Reset_Warnings;
+
--
-- Adjust_Name_Case --
--
Index: errout.ads
===
--- errout.ads  (revision 244350)
+++ errout.ads  (working copy)
@@ -803,6 +803,11 @@
--  Remove warnings on all elements of a list (Calls Remove_Warning_Messages
--  on each element of the list, see above).
 
+   procedure Reset_Warnings;
+   --  Reset the counts related to warnings. This is used both to initialize
+   --  these counts and to reset them after each phase of analysis for a given
+   --  value of Opt.Warning_Mode in gnat2why.
+
procedure Set_Ignore_Errors (To : Boolean);
--  Following a call to this procedure with To=True, all error calls are
--  ignored. A call with To=False restores the default treatment in which
@@ -852,9 +857,9 @@
function Compilation_Errors return Boolean;
--  Returns True if errors have been detected, or warnings in -gnatwe (treat
--  warnings as errors) mode. Note that it is mandatory to call Finalize
-   --  before calling this routine. Always returns False in formal verification
-   --  mode, because errors issued when analyzing code are not compilation
-   --  errors, and should not result in exiting with an error status.
+   --  before calling this routine. To account for changes to Warning_Mode in
+   --  gnat2why between phases, the past or current presence of an error is
+   --  recorded in a global variable at each call.
 
procedure Error_Msg_CRT (Feature : String; N : Node_Id);
--  Posts a non-fatal message on node N saying that the feature identified

[Ada] Inheritance of predicates in derived scalar types.

This patch fixes an omission in the inheritance of predicate aspects in type
derivations. The parent type may be a subtype declaration or a type declaration
with a dynamic predicate aspect, and the aspect applies to a first subtype, not
to its anonymous parent type.

Eecuting:

   gnatmake -q -gnata test_it
   test_it

must yield:

   2 in Even is TRUE
   3 in Even is FALSE
   2 in New_Even is TRUE
   3 in New_Even is FALSE
   2 in Newer_Even is TRUE
   3 in Newer_Even is FALSE
   OK

---
with Text_IO; use Text_IO;
procedure Test_It is
type Even is new Integer with
  Dynamic_Predicate => Even mod 2 = 0;

subtype Other_Even is Integer with
  Dynamic_Predicate => Other_Even mod 2 = 0;

type New_Even is new Even;
type Newer_Even is new Other_Even;
B : Boolean;

subtype Small is Integer range -5 .. 5;
type New_Small is new Small;

begin
B := 2 in Even;
Put_Line ("2 in Even is " & B'Img);

B := 3 in Even;
Put_Line ("3 in Even is " & B'Img);

B := 2 in New_Even;
Put_Line ("2 in New_Even is " & B'Img);

B := 3 in New_Even;
Put_Line ("3 in New_Even is " & B'Img);

B := 2 in Newer_Even;
Put_Line ("2 in Newer_Even is " & B'Img);

B := 3 in Newer_Even;
Put_Line ("3 in Newer_Even is " & B'Img);

declare
   X : New_Even;
begin
   X := 13;
exception
   when Others => Put_Line ("OK");
end;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-12  Ed Schonberg  

* sem_ch3.adb (Build_Derived_Type): For a scalar derived type,
inherit predicates if any from the first_subtype of the parent,
not from the anonymous parent type.
* sem_eval.adb (Is_Static_Subtype): A type that inherits a dynamic
predicate is not a static subtype.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 244366)
+++ sem_ch3.adb (working copy)
@@ -9127,9 +9127,13 @@
  end if;
   end if;
 
-  --  We similarly inherit predicates
+  --  We similarly inherit predicates. Note that for scalar derived types
+  --  the predicate is inherited from the first subtype, and not from its
+  --  (anonymous) base type.
 
-  if Has_Predicates (Parent_Type) then
+  if Has_Predicates (Parent_Type)
+or else  Has_Predicates (First_Subtype (Parent_Type))
+  then
  Set_Has_Predicates (Derived_Type);
   end if;
 
Index: sem_eval.adb
===
--- sem_eval.adb(revision 244350)
+++ sem_eval.adb(working copy)
@@ -23,6 +23,7 @@
 --  --
 --
 
+with Aspects;  use Aspects;
 with Atree;use Atree;
 with Checks;   use Checks;
 with Debug;use Debug;
@@ -4989,7 +4990,13 @@
   then
  return False;
 
-  elsif Has_Dynamic_Predicate_Aspect (Typ) then
+  --  If there is a dynamic predicate for the type (declared or inherited)
+  --  the expression is not static.
+
+  elsif Has_Dynamic_Predicate_Aspect (Typ)
+or else (Is_Derived_Type (Typ)
+  and then Has_Aspect (Typ, Aspect_Dynamic_Predicate))
+  then
  return False;
 
   --  String types

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On Thu, Jan 12, 2017 at 04:45:41PM +0100, Marc Glisse wrote:
> > On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> > 
> > > On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
> > > > It also lacks expressiveness when comparing
> > > > 
> > > >   short s;
> > > >   s_1 = (short) 1;
> > > >   s_2 = short (1);
> > > > 
> > > > IMHO having a _Literal somewhere makes it more obvious what is meant
> > > > (I'm still going to dump 1u or 1l instead of _Literal (unsigned) 1
> > > > of course as that's even more easy to recognize).
> > > 
> > > So, with the _Literal (type) constant syntax, what are we going to emit
> > > and parse for __int128 constants?
> > > _Literal (__int128) (0x123456ULL << 64 || 0x123456ULL), something else?
> > 
> > Yes, unless we teach libcpp about larger than 64bit literals.
> 
> Teaching libcpp about 128bit literals sounds like a much nicer idea
> indeed...

Well, we need some suffix that will not clash with C++ mandated udlits
very soon, it is already bad that i and Q suffixes are problematic.
By sN, did you mean s128 or literally sN?
I've googled around a little bit and only found comments about
1ui64 and 1i64 suffixes, so that would mean accepting instead of l/L
i128 or I128.

Jakub

Re: [PATCH][ARM]Use different startfile and endfile for elf target when generating shared object.

2017-01-12 Thread Renlin Li

Hi Kugan,

some of the targets do include pie, and use the same crtbegin file as shared
object.
For example, alpha/elf.h

And there are targets which don't do that,
For example, sh/elf.h

Most of the elf target seem only consider the simple case.

The purpose of this patch is to make it possible to correctly check whether current
toolchain supports shared object.

Current dejegnu target selector "shared" tries to compile a simple source code to with
"-shared -fpic" options to check whether "-shared" is supported.

For arm baremetal targets with, this is not sufficient.

arm-none-eabi is built with multilib. When running this testcase, if it's
compiled with "-march=armv7-a".
The crtbegin.o for this architecture version contains relocations which
cannot be used in shared object.
This test will fail.

if no cpu or architecture is specified, the default cpu will be arm7tdmi.
The test will pass as crtbegin.o for this version doesn't contains any
relocations
only allowed in shared object.

To make this "shared" target selector work for arm baremetal toolchain. The correct way is
to use different startup file for shared and non-shared toolchain.

If the toolchain doesn't support "-shared" option, and someone attempts to use
it
to create shared object, it will complaint that "crtbeginS.o" cannot not be
found.

A full history of discussion is here:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00322.html

Regards,
Renlin

On 12/01/17 11:47, kugan wrote:

Hi,

On 16/06/16 21:04, Renlin Li wrote:

/* Now we define the strings used to build the spec file. */
-#define UNKNOWN_ELF_STARTFILE_SPEC" crti%O%s crtbegin%O%s crt0%O%s"
+#define UNKNOWN_ELF_STARTFILE_SPEC\
+ "crti%O%s \
+ %{!shared:crtbegin%O%s} %{shared:crtbeginS%O%s} \
+ crt0%O%s"

Some targets seems to use shared|pie. When you change it, shouldn't it also
include for pie?

Thanks,
Kugan

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

2017-01-12 Thread Marc Glisse


On Thu, 12 Jan 2017, Richard Biener wrote:


On Thu, 12 Jan 2017, Jakub Jelinek wrote:


On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:

It also lacks expressiveness when comparing

  short s;
  s_1 = (short) 1;
  s_2 = short (1);

IMHO having a _Literal somewhere makes it more obvious what is meant
(I'm still going to dump 1u or 1l instead of _Literal (unsigned) 1
of course as that's even more easy to recognize).


So, with the _Literal (type) constant syntax, what are we going to emit
and parse for __int128 constants?
_Literal (__int128) (0x123456ULL << 64 || 0x123456ULL), something else?


Yes, unless we teach libcpp about larger than 64bit literals.


Teaching libcpp about 128bit literals sounds like a much nicer idea 
indeed...


--
Marc Glisse

Re: [patch,avr] PR78883: Implement a dummy scheduler

2017-01-12 Thread Richard Sandiford

Georg-Johann Lay  writes:
> On 12.01.2017 10:00, Richard Sandiford wrote:
>> Georg-Johann Lay  writes:
>>> On 04.01.2017 20:29, Jeff Law wrote:
 On 01/04/2017 12:18 PM, Segher Boessenkool wrote:
> On Wed, Jan 04, 2017 at 06:42:23PM +, Richard Sandiford wrote:
>> 1. reload has a bug that no-one really wants to fix (understandable)
>> 2. the bug is triggered by paradoxical subregs of mems
>> 3. those subregs are normally disabled on targets that support insn
>>scheduling
>> 4. therefore, define an insn scheduler
>> 5. we don't actually want insn scheduling, so either
>>(a) make sure the insn scheduler is never actually used for insn
>>scheduling, or
>>(b) allow the insn scheduler to run anyway but encourage it to do
>> nothing
>>(other than take compile time)
>>
>> (4) and (5) feel like too much of a hack to me.  They're going to have
>> other consequences, e.g. we'll no longer give the warning:
>>
>>   instruction scheduling not supported on this target machine
>>
>> if users try to use -fschedule-insns.  And since we don't support
>> meaningful insn scheduling even after this patch, giving the warning
>> seems more user-friendly than dropping it.
>>
>> I think the consensus is that we don't want these subregs for AVR
>> regardless of whether scheduling is used, and probably wouldn't want
>> them even without this bug.
>
> Right, and the same is true for most targets.  Subregs of memory are not
> something you want.  As rtl.texi says:
>
>
> @item mem
> @code{subreg}s of @code{mem} were common in earlier versions of GCC and
> are still supported.  During the reload pass these are replaced by plain
> @code{mem}s.  On machines that do not do instruction scheduling, use of
> @code{subreg}s of @code{mem} are still used, but this is no longer
> recommended.  Such @code{subreg}s are considered to be
> @code{register_operand}s rather than @code{memory_operand}s before and
> during reload.  Because of this, the scheduling passes cannot properly
> schedule instructions with @code{subreg}s of @code{mem}, so for machines
> that do scheduling, @code{subreg}s of @code{mem} should never be used.
> To support this, the combine and recog passes have explicit code to
> inhibit the creation of @code{subreg}s of @code{mem} when
> @code{INSN_SCHEDULING} is defined.
>
>
>> So why not instead change the condition
>> used by general_operand, like we were talking about yesterday?
>> It seems simpler and more direct.
>
> We should split off a new "SUBREGS_OF_MEM_ALLOWED" from !INSN_SCHEDULING,
> and then probably even default it to false.
 That would work for me :-)  The question in my mind would be unexpected
 fallout at this point in the release process.  Maybe default it to
 !INSN_SCHEDULING to minimize such fallout now, then to false for gcc-8?


 jeff
>>>
>>> Bit if we disable it, what's the point of introducing changes to combine
>>> which come up with even more of such subregs?
>>>
>>> For targets with scheduling, which applies to most of the targets, the
>>> "optimization" in combine will be void as rejected by general_operand,
>>> hence a target would have explicit paradoxical subregs in the back end
>>> or use some home brew predicated that allow that stuff and use internal
>>> knowledge of what combine does.
>>>
>>> Moreover I have some problems in explaining what the new hook macro is
>>> supposed to do:
>>>
>>> "Disable/enable paradoxical SUBREGs of MEM in general_operands before
>>> register allocation.  Use this hook if your back end has trouble with
>>> paradoxical subregs of mem.  Enabled per default iff the target
>>> provides an insn scheduler."
>>
>> Sounds OK to me, but...
>>
>>> Who would understand this and infer from the docs whether this macro
>>> should be used?
>>
>>> Who would understand this and infer from the docs whether this macro
>>> should be used?
>>
>> ...how about:
>>
>> ---
>> Define this macro if you do not want predicates such as
>> @code{general_operand} and @code{register_operand} to accept paradoxical
>> @code{subreg}s of @code{mem}s before register allocation.  Early versions
>> of GCC treated such @code{subreg}s as register operands and required
>> the register allocator to load the inner @code{mem} into a temporary
>> register.  However, this approach effectively hid the load from
>> pre-allocation optimizations like CSE and scheduling and is therefore
>> deprecated.
>
> As avr cannot operate on memory, it will have to load such values,
> hence the conclusion would be to enable that stuff?

The point is that the load happens either way.  It's just a question
of whether it happens before register allocation (new behaviour,
selected

[PATCH] Fix PR77283


The following fixes PR77283, path splitting being overly aggressive
and causing loop unrolling not to happen (because how it distorts the
CFG).

It is a aim at creating a cost model (there's none apart from
not duplicating too much stmts) by means of the observation that
we'd have to have PHI nodes in the joiner to have any possibility
of CSE opportunities being exposed by duplicating it or threading
opportunities being exposed across the new latch.  That includes
virtual PHIs for CSE (so any load/store) but not for the threading
(but IMHO threading should figure all this out on its own without
the requirement for somebody else duplicating the joiner).

Bootstrapped and tested on x86_64-unknown-linux-gnu, the s390x
libquantum regression is reportedly fixed by this.  I had to adjust
gcc.dg/tree-ssa/split-path-7.c to not expect any path splitting because
I (and of course the cost model) can't see any reason to do it.

Ok for trunk?

Thanks,
Richard.

2017-01-12  Richard Biener  

PR tree-optimization/77283
* gimple-ssa-split-paths.c: Include gimple-ssa.h, tree-phinodes.h
and ssa-iterators.h.
(is_feasible_trace): Implement a cost model based on joiner
PHI node uses.

* gcc.dg/tree-ssa/split-path-7.c: Adjust.
* gcc.dg/tree-ssa/split-path-8.c: New testcase.
* gcc.dg/tree-ssa/split-path-9.c: Likewise.

Index: gcc/gimple-ssa-split-paths.c
===
--- gcc/gimple-ssa-split-paths.c(revision 244350)
+++ gcc/gimple-ssa-split-paths.c(working copy)
@@ -32,6 +32,9 @@ along with GCC; see the file COPYING3.
 #include "tracer.h"
 #include "predict.h"
 #include "params.h"
+#include "gimple-ssa.h"
+#include "tree-phinodes.h"
+#include "ssa-iterators.h"
 
 /* Given LATCH, the latch block in a loop, see if the shape of the
path reaching LATCH is suitable for being split by duplication.
@@ -200,6 +203,58 @@ is_feasible_trace (basic_block bb)
}
 }
 
+  /* If the joiner has no PHIs with useful uses there is zero chance
+ of CSE/DCE/jump-threading possibilities exposed by duplicating it.  */
+  bool found_useful_phi = false;
+  for (gphi_iterator si = gsi_start_phis (bb); ! gsi_end_p (si);
+   gsi_next ())
+{
+  gphi *phi = si.phi ();
+  use_operand_p use_p;
+  imm_use_iterator iter;
+  FOR_EACH_IMM_USE_FAST (use_p, iter, gimple_phi_result (phi))
+   {
+ gimple *stmt = USE_STMT (use_p);
+ if (is_gimple_debug (stmt))
+   continue;
+ /* If there's a use in the joiner this might be a CSE/DCE
+opportunity.  */
+ if (gimple_bb (stmt) == bb)
+   {
+ found_useful_phi = true;
+ break;
+   }
+ /* If the use is on a loop header PHI and on one path the
+value is unchanged this might expose a jump threading
+opportunity.  */
+ if (gimple_code (stmt) == GIMPLE_PHI
+ && gimple_bb (stmt) == bb->loop_father->header
+ /* But for memory the PHI alone isn't good enough.  */
+ && ! virtual_operand_p (gimple_phi_result (stmt)))
+   {
+ for (unsigned i = 0; i < gimple_phi_num_args (phi); ++i)
+   if (gimple_phi_arg_def (phi, i) == gimple_phi_result (stmt))
+ {
+   found_useful_phi = true;
+   break;
+ }
+ if (found_useful_phi)
+   break;
+   }
+   }
+  if (found_useful_phi)
+   break;
+}
+  if (! found_useful_phi)
+{
+  if (dump_file && (dump_flags & TDF_DETAILS))
+   fprintf (dump_file,
+"Block %d is a join that does not expose CSE/DCE/jump-thread "
+"opportunities when duplicated.\n",
+bb->index);
+  return false;
+}
+
   /* We may want something here which looks at dataflow and tries
  to guess if duplication of BB is likely to result in simplification
  of instructions in BB in either the original or the duplicate.  */
Index: gcc/testsuite/gcc.dg/tree-ssa/split-path-7.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/split-path-7.c(revision 244350)
+++ gcc/testsuite/gcc.dg/tree-ssa/split-path-7.c(working copy)
@@ -91,4 +91,4 @@ linit ()
}
 }
 }
-/* { dg-final { scan-tree-dump-times "Duplicating join block" 2 "split-paths" 
} } */
+/* { dg-final { scan-tree-dump-times "Duplicating join block" 0 "split-paths" 
} } */
Index: gcc/testsuite/gcc.dg/tree-ssa/split-path-8.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/split-path-8.c(nonexistent)
+++ gcc/testsuite/gcc.dg/tree-ssa/split-path-8.c(working copy)
@@ -0,0 +1,14 @@
+/* PR77283 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-split-paths-details" }

Re: [PATCH] BRIG frontend: request for a global review

2017-01-12 Thread Pekka Jääskeläinen

Hi,

A gentle ping...

On Wed, Dec 14, 2016 at 7:15 PM, Pekka Jääskeläinen  wrote:
> Hi,
>
> I'm calling for a global review for the BRIG frontend for inclusion in 
> upstream.
> The copyright transfer has been taken care of.
>
> The patch set has been approved by Martin Jambor, the upcoming co-maintainer 
> of
> the BRIG frontend, who asked me to send an updated patch set for a
> global reviewer
> to look at.
>
> Please find the patches attached to this email. An introduction and
> a diffstat is below.
>
> Best regards,
> Pekka
>
>
> 
>
> This patch set adds a BRIG (HSAIL) frontend. It can be used as a core
> for an HSAIL finalizer implementation for processors with gcc backends.
>
> It is a bit unusual frontend as the consumed format is a binary
> representation.  The textual HSAIL can be compiled to it with a separate
> assembler tool.
>
> The frontend has been mostly tested with the HSA 1.0 PRM conformance suite
> which it now passes. The accompanied GENERIC-scanning test suite is supposed
> to be only a smoke test.
>
> libhsail-rt implements HSAIL specific builtins and includes a simple runtime
> that implements SPMD execution via setcontext()/getcontext() or loops to
> execute multiple work-item work groups without SPMD/SIMD-default hardware.
>
> We've split it to 4 patches:
>
> 001 - the configuration file changes and misc.
> 002 - the frontend itself
> 003 - libhsail-rt
> 004 - the smoke test suite
>
> The diffstat is as follows:
>
>  .gitignore| 2 +-
>  Makefile.def  | 3 +
>  Makefile.in   |   489 +
>  configure | 1 +
>  configure.ac  | 1 +
>  gcc/brig-builtins.def |   659 +
>  gcc/brig/Make-lang.in |   247 +
>  gcc/brig/brig-builtins.h  |99 +
>  gcc/brig/brig-c.h |66 +
>  gcc/brig/brig-lang.c  |   770 +
>  gcc/brig/brigfrontend/brig-arg-block-handler.cc   |66 +
>  gcc/brig/brigfrontend/brig-atomic-inst-handler.cc |   265 +
>  gcc/brig/brigfrontend/brig-basic-inst-handler.cc  |   865 +
>  gcc/brig/brigfrontend/brig-branch-inst-handler.cc |   221 +
>  gcc/brig/brigfrontend/brig-cmp-inst-handler.cc|   198 +
>  gcc/brig/brigfrontend/brig-code-entry-handler.cc  |  1719 ++
>  gcc/brig/brigfrontend/brig-code-entry-handler.h   |   425 +
>  gcc/brig/brigfrontend/brig-comment-handler.cc |39 +
>  gcc/brig/brigfrontend/brig-control-handler.cc |   108 +
>  .../brigfrontend/brig-copy-move-inst-handler.cc   |73 +
>  gcc/brig/brigfrontend/brig-cvt-inst-handler.cc|   260 +
>  gcc/brig/brigfrontend/brig-fbarrier-handler.cc|44 +
>  gcc/brig/brigfrontend/brig-function-handler.cc|   373 +
>  gcc/brig/brigfrontend/brig-function.cc|   723 +
>  gcc/brig/brigfrontend/brig-function.h |   213 +
>  gcc/brig/brigfrontend/brig-inst-mod-handler.cc|58 +
>  gcc/brig/brigfrontend/brig-label-handler.cc   |37 +
>  gcc/brig/brigfrontend/brig-lane-inst-handler.cc   |84 +
>  gcc/brig/brigfrontend/brig-machine.c  |44 +
>  gcc/brig/brigfrontend/brig-machine.h  |33 +
>  gcc/brig/brigfrontend/brig-mem-inst-handler.cc|   180 +
>  gcc/brig/brigfrontend/brig-module-handler.cc  |41 +
>  gcc/brig/brigfrontend/brig-queue-inst-handler.cc  |93 +
>  gcc/brig/brigfrontend/brig-seg-inst-handler.cc|   146 +
>  gcc/brig/brigfrontend/brig-signal-inst-handler.cc |42 +
>  gcc/brig/brigfrontend/brig-to-generic.cc  |   811 +
>  gcc/brig/brigfrontend/brig-to-generic.h   |   226 +
>  gcc/brig/brigfrontend/brig-util.cc|   447 +
>  gcc/brig/brigfrontend/brig-util.h |53 +
>  gcc/brig/brigfrontend/brig-variable-handler.cc|   264 +
>  gcc/brig/brigfrontend/phsa.h  |69 +
>  gcc/brig/brigspec.c   |   135 +
>  gcc/brig/config-lang.in   |41 +
>  gcc/brig/lang-specs.h |28 +
>  gcc/brig/lang.opt |41 +
>  gcc/builtin-types.def |80 +-
>  gcc/builtins.def  |41 +
>  gcc/config.in | 6 +
>  gcc/configure | 6 +
>  gcc/configure.ac  | 5 +
>  gcc/doc/frontends.texi| 2 +-
>  gcc/doc/invoke.texi   | 8 +
>  gcc/doc/standards.texi| 8 +
>  gcc/testsuite/brig.dg/README  |10 +
>  gcc/testsuite/brig.dg/dg.exp  |27 +
>

[Ada] Crash on missing full view of controlled private type

This patch protects adjustment, finalization, and initialization-related code
from scenarios where a private type may not have been successfully frozen due
to a missing full view.


-- Source --


--  missing_view.ads

with Ada.Finalization; use Ada.Finalization;

package Missing_View is
   type Ctrl is new Controlled with private;
   type Rec  is new Controlled with private;

private
   type Rec is new Controlled with record
  Comp : Ctrl;
   end record;
end Missing_View;


-- Compilation and output --


$ gcc -c missing_view.ads
missing_view.ads:4:09: missing full declaration for private extension
missing_view.ads:8:09: premature usage of incomplete type "Rec" defined at line 
8

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-12  Hristian Kirtchev  

* exp_aggr.adb (Build_Record_Aggr_Code): Guard against a missing
adjustment primitive when the ancestor type was not properly frozen.
(Gen_Assign): Guard against a missing initialization
primitive when the component type was not properly frozen.
(Initialize_Array_Component): Guard against a missing adjustment
primitive when the component type was not properly frozen.
(Initialize_Record_Component): Guard against a missing adjustment
primitive when the component type was not properly frozen.
(Process_Transient_Component_Completion): The transient object may
not be finalized when its associated type was not properly frozen.
* exp_ch3.adb (Build_Assignment): Guard against a missing
adjustment primitive when the component type was not properly frozen.
(Build_Initialization_Call): Guard against a missing
initialization primitive when the associated type was not properly
frozen.
(Expand_N_Object_Declaration): Guard against a missing
adjustment primitive when the base type was not properly frozen.
(Predefined_Primitive_Bodies): Create an empty Deep_Adjust
body when there is no adjustment primitive available. Create an
empty Deep_Finalize body when there is no finalization primitive
available.
* exp_ch4.adb (Apply_Accessibility_Check): Guard against a
missing finalization primitive when the designated type was
not properly frozen.
(Expand_N_Allocator): Guard against a missing initialization primitive
when the designated type was not properly frozen.
* exp_ch5.adb (Make_Tag_Ctrl_Assignment): Add the adjustment call
only when the corresponding adjustment primitive is available.
* exp_ch7.adb (Build_Adjust_Or_Finalize_Statements): Generate the
adjustment/finalization statements only when there is an available
primitive to carry out the action.
(Build_Initialize_Statements): Generate the initialization/finalization
statements only when there is an available primitive to carry out the
action.
(Make_Adjust_Call): Do not generate a call when the underlying
type is not present due to a possible missing full view.
(Make_Final_Call): Do not generate a call when the underlying
type is not present due to a possible missing full view.
(Make_Finalize_Address_Stmts): Generate an empty body when the
designated type lacks a finalization primitive.
(Make_Init_Call): Do not generate a call when the underlying type is
not present due to a possible missing full view.
(Process_Component_For_Adjust): Add the adjustment call only when the
corresponding adjustment primitive is available.
(Process_Component_For_Finalize): Add the finalization call only when
the corresponding finalization primitive is available.
(Process_Object_Declaration): Use a null statement to emulate a
missing call to the finalization primitive of the object type.
* exp_ch7.ads (Make_Adjust_Call): Update the comment on usage.
(Make_Final_Call): Update the comment on usage.
(Make_Init_Call): Update the comment on usage.
* exp_util.adb (Build_Transient_Object_Statements): Code reformatting.

Index: exp_aggr.adb
===
--- exp_aggr.adb(revision 244350)
+++ exp_aggr.adb(working copy)
@@ -1128,6 +1128,7 @@
   and then Needs_Finalization (Comp_Typ);
 
 Full_Typ  : constant Entity_Id := Underlying_Type (Comp_Typ);
+Adj_Call  : Node_Id;
 Blk_Stmts : List_Id;
 Init_Stmt : Node_Id;
 
@@ -1222,10 +1223,17 @@
   and then Is_Controlled (Component_Type (Comp_Typ))
   and then Nkind (Expr) = N_Aggregate)
 then
-   Append_To (Blk_Stmts,
+   Adj_Call :=
  Make_Adjust_Call

[PATCH] PR66284 remove std::function special case for reference_wrapper

2017-01-12 Thread Jonathan Wakely


As the PR says, we follow the Boost.Function semantics w.r.t.
construction of std::function from a std::reference_wrapper, but other
std::lib implementations do something different. I reported a defect
(LWG 2781) and the consensus is to clarify the standard to bless the
other implementations. This modifies our std::function to have the
correct semantics.

Previously passing a std::reference_wrapper to a std::function
constructor would unwrap it and store an F*, but target_type() would
return typeid(F). With the change it stores std::reference_wrapper
and target_type() returns typeid(std::reference_wrapper). This is
more straightforward, as there's no cleverness being done behind the
scenes.

The previous semantics required a special case in the non-const
overload of std::function::target() to ensure it couldn't be used to
drop const-qualification when the std::function was constructed from a
std::reference_wrapper. Now that there's no unwrapping of
reference_wrappers that isn't needed, and the non-const overload of
target() can simply call the const overload and then const_cast the
result.

These are user-visible changes, but I doubt much code will be affected.

PR libstdc++/66284
* doc/xml/manual/intro.xml: Document LWG 2781 change.
* doc/html/*: Regenerate.
* include/std/functional (_Function_base::_Ref_manager): Remove.
(_Function_handler): Remove partial specializations for
reference_wrapper.
(function::target): Remove special case for const qualification.
* testsuite/20_util/function/6.cc: Adjust tests for target type.
* testsuite/20_util/function/7.cc: Likewise.
* testsuite/20_util/function/8.cc: Likewise.

Tested powerpc64le-linux, committed to trunk.

commit 0966b4fdc1d5747f0cd63305546094f80c327d2b
Author: Jonathan Wakely 
Date:   Thu Jan 12 14:22:13 2017 +

PR66284 remove std::function special case for reference_wrapper

	PR libstdc++/66284
	* doc/xml/manual/intro.xml: Document LWG 2781 change.
	* doc/html/*: Regenerate.
	* include/std/functional (_Function_base::_Ref_manager): Remove.
	(_Function_handler): Remove partial specializations for
	reference_wrapper.
	(function::target): Remove special case for const qualification.
	* testsuite/20_util/function/6.cc: Adjust tests for target type.
	* testsuite/20_util/function/7.cc: Likewise.
	* testsuite/20_util/function/8.cc: Likewise.

diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml
index d23008a..db6e09a 100644
--- a/libstdc++-v3/doc/xml/manual/intro.xml
+++ b/libstdc++-v3/doc/xml/manual/intro.xml
@@ -1116,6 +1116,15 @@ requirements of the license of GCC.
   only use it if valid.
 
 
+http://www.w3.org/1999/xlink; xlink:href="../ext/lwg-defects.html#2781">2781:
+   Contradictory requirements for std::function
+ and std::reference_wrapper
+   
+
+Remove special handling for reference_wrapper
+  arguments and store them directly as the target object.
+
+
   
 
  
diff --git a/libstdc++-v3/include/bits/std_function.h b/libstdc++-v3/include/bits/std_function.h
index f7bb22a..7d77e21 100644
--- a/libstdc++-v3/include/bits/std_function.h
+++ b/libstdc++-v3/include/bits/std_function.h
@@ -268,41 +268,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	{ __functor._M_access<_Functor*>() = new _Functor(std::move(__f)); }
   };
 
-template
-  class _Ref_manager : public _Base_manager<_Functor*>
-  {
-	typedef _Function_base::_Base_manager<_Functor*> _Base;
-
-  public:
-	static bool
-	_M_manager(_Any_data& __dest, const _Any_data& __source,
-		   _Manager_operation __op)
-	{
-	  switch (__op)
-	{
-#if __cpp_rtti
-	case __get_type_info:
-	  __dest._M_access() = (_Functor);
-	  break;
-#endif
-	case __get_functor_ptr:
-	  __dest._M_access<_Functor*>() = *_Base::_M_get_pointer(__source);
-	  return is_const<_Functor>::value;
-	  break;
-
-	default:
-	  _Base::_M_manager(__dest, __source, __op);
-	}
-	  return false;
-	}
-
-	static void
-	_M_init_functor(_Any_data& __functor, reference_wrapper<_Functor> __f)
-	{
-	  _Base::_M_init_functor(__functor, std::__addressof(__f.get()));
-	}
-  };
-
 _Function_base() : _M_manager(nullptr) { }
 
 ~_Function_base()
@@ -311,7 +276,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	_M_manager(_M_functor, _M_functor, __destroy_functor);
 }
 
-
 bool _M_empty() const { return !_M_manager; }
 
 typedef bool (*_Manager_type)(_Any_data&, const _Any_data&,
@@ -354,36 +318,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 };
 
-  template
-class _Function_handler<_Res(_ArgTypes...), reference_wrapper<_Functor> >
-: public _Function_base::_Ref_manager<_Functor>
-{
-  typedef _Function_base::_Ref_manager<_Functor> _Base;
-
- public:
-  static _Res
-  _M_invoke(const _Any_data& __functor, _ArgTypes&&...

Re: [PATCH, rs6000] Fix PR79044 (ICE in swap optimization)

2017-01-12 Thread Bill Schmidt


> On Jan 11, 2017, at 5:36 PM, Segher Boessenkool  
> wrote:
> 
> On Tue, Jan 10, 2017 at 02:18:38PM -0600, Bill Schmidt wrote:
>> PR79044 reports a situation where swap optimization ICEs in GCC 6 and in 
>> trunk.  The
>> problem is that swap optimization doesn't properly recognize that 
>> element-reversing
>> loads and stores (e.g., lxvw4x) cannot be treated as "swappable" 
>> instructions.  These
>> arise from the __builtin_vec_xl and __builtin_vec_xst interfaces that were 
>> added in 
>> GCC 6.  The surrounding code is slightly different, so the fix is slightly 
>> different
>> for the two releases.
>> 
>> The fix is obvious, and bootstraps on powerpc64le-unknown-linux-gnu with no 
>> regressions.
>> Are these patches ok for trunk and GCC 6, respectively?
> 
> Okay for both.  Is this needed for GCC 5 as well?

No, the potential for this problem was introduced in 6.  Thanks for the review!

Bill

> 
> Thanks,
> 
> 
> Segher
>

RE: [PATCH] MIPS: Fix generation of DIV.G and MOD.G for Loongson targets.

2017-01-12 Thread Matthew Fortune

Maciej Rozycki  writes:
> On Thu, 12 Jan 2017, Toma Tabacu wrote:
> 
> > > > Unfortunately, this interferes with the generation of DIV.G and
> > > > MOD.G (the div3 and mod3 patterns) for Loongson
> > > > targets,
> > > which
> > > > causes test failures.
> > >
> > >  What test failures?  Details please.
> > >
> >
> > It's
> > gcc.target/mips/loongson-muldiv-1.c
> > gcc.target/mips/loongson-muldiv-2.c
> > gcc.target/mips/loongson3a-muldiv-1.c
> > gcc.target/mips/loongson3a-muldiv-2.c
> > on O2, O3, and Os.
> >
> > They are also checking for the Loongson-specific multiply instruction,
> > but there are no failures for that.
> 
>  So these tests have e.g.:
> 
> NOMIPS16 st sdiv (st x, st y) { return x / y + x % y; }
> 
> and as such it looks to me like this code does legitimately use a single
> DIV instruction rather than a DIV.G and MOD.G pair, at least at -O2/-O3,
> as I'd expect two divisions to take twice as much computing time as one
> does, and the avoidance of the extra accumulator access overhead needed
> with DIV does not compensate for it.  For -Os actual code generated will
> have to be checked; I suspect DIV.G/MOD.G ought to be used rather than
> DIV/MFLO/MFHI as it's two instructions vs three.
> 
>  So as a first step I'd split these tests into individual cases covering
> signed/unsigned function pairs each of which doing a single operation
> only, i.e. smul/umul, sdiv/udiv, smod/umod, which will then be expected
> to always use the extra Loongson instructions.  This ought to provide
> the coverage originally intended (study the discussion around the
> submission of the patch that introduced these tests to double-check).

This sounds like a reasonable fix. The theme of Toma's changes has been to
improve testsuite stability rather than code gen so breaking these tests
up to cover the original goal looks OK.

>  As a further step a test case for sdivmod/udivmod will then be needed,
> to cover the use of DIV vs DIV.G/MOD.G as required for speed vs space
> optimisation.

I see no need to improve code quality currently as it would be new work.
Based on the description I expect -Os will be using DIV and MFLO/MFHI.
Adding a test to record that certain optimisation levels happen to now
get the base arch DIV instruction used could be risky for stability but
I have no objection unless the new test somehow fails when pitted against
the plethora of configurations we have to test.

>  Likewise for GSMULT/GSDIV/GSMOD, etc. (hmm, why are the signed
> MULT.G/GSMULT instruction variants never used?).

Somewhat weird but so is the presence of signed and unsigned mul in R6.
I believe that microarchitecture optimisation is possible where results
could be memoised waiting for the high part multiply to be issued and
then reused.

Since there shouldn't be any compiler change needed to resolve this then
I see no need to test specifically against loongson. Just verify the
code generated looks reasonable as per the original tests.

Thanks,
Matthew

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On Thu, 12 Jan 2017, Jakub Jelinek wrote:

> On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
> > It also lacks expressiveness when comparing
> > 
> >   short s;
> >   s_1 = (short) 1;
> >   s_2 = short (1);
> > 
> > IMHO having a _Literal somewhere makes it more obvious what is meant
> > (I'm still going to dump 1u or 1l instead of _Literal (unsigned) 1
> > of course as that's even more easy to recognize).
> 
> So, with the _Literal (type) constant syntax, what are we going to emit
> and parse for __int128 constants?
> _Literal (__int128) (0x123456ULL << 64 || 0x123456ULL), something else?

Yes, unless we teach libcpp about larger than 64bit literals.

The following patch implements _Literal (but not proper dumping of
> 64bit literals for __int128 nor parsing the above).

I think that's a good start which also covers pointer types nicely.
For integers we might at some point want to adopt sN and uN suffixes
which appearantly MSVC supports to handle native 128bit literals.

For

struct X { int a : 2; };
void __GIMPLE ()
foo (struct X * p)
{
  p->a = _Literal (int : 2) 1;
  return;
}

and thus 2 bit literals c_parser_type_name needs to be extended
or for _Literal we can handle : 2 on our own.  But for loads
from p->a into a temporary we need to handle that in declarations as well.

struct X { int a : 2; };
int __GIMPLE ()
foo (struct X * p)
{
  int : 2 a; // int a : 2;
  a = p->a;
  return a;
}

Richard.

2017-01-12  Richard Biener  

c/
* gimple-parser.c (c_parser_gimple_postfix_expression): Parse
_Literal ( type-name ) number.

* tree-pretty-print.c (dump_generic_node): Dump INTEGER_CSTs
as _Literal ( type ) number in case usual suffixes do not
preserve all information.

* gcc.dg/gimplefe-22.c: New testcase.

Index: gcc/c/gimple-parser.c
===
--- gcc/c/gimple-parser.c   (revision 244350)
+++ gcc/c/gimple-parser.c   (working copy)
@@ -799,6 +799,32 @@ c_parser_gimple_postfix_expression (c_pa
   type, ptr.value, alias_off);
  break;
}
+ else if (strcmp (IDENTIFIER_POINTER (id), "_Literal") == 0)
+   {
+ /* _Literal '(' type-name ')' number  */
+ c_parser_consume_token (parser);
+ tree type = NULL_TREE;
+ if (c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
+   {
+ struct c_type_name *type_name = c_parser_type_name (parser);
+ tree tem;
+ if (type_name)
+   type = groktypename (type_name, , NULL);
+ c_parser_skip_until_found (parser, CPP_CLOSE_PAREN,
+"expected %<)%>");
+   }
+ tree val = c_parser_gimple_postfix_expression (parser).value;
+ if (! type
+ || ! val
+ || val == error_mark_node
+ || TREE_CODE (val) != INTEGER_CST)
+   {
+ c_parser_error (parser, "invalid _Literal");
+ return expr;
+   }
+ expr.value = fold_convert (type, val);
+ return expr;
+   }
  /* SSA name.  */
  unsigned version, ver_offset;
  if (! lookup_name (id)
Index: gcc/tree-pretty-print.c
===
--- gcc/tree-pretty-print.c (revision 244350)
+++ gcc/tree-pretty-print.c (working copy)
@@ -1664,6 +1664,16 @@ dump_generic_node (pretty_printer *pp, t
   break;
 
 case INTEGER_CST:
+  if (flags & TDF_GIMPLE
+ && (POINTER_TYPE_P (TREE_TYPE (node))
+ || (TYPE_PRECISION (TREE_TYPE (node))
+ < TYPE_PRECISION (integer_type_node))
+ || exact_log2 (TYPE_PRECISION (TREE_TYPE (node))) == -1))
+   {
+ pp_string (pp, "_Literal (");
+ dump_generic_node (pp, TREE_TYPE (node), spc, flags, false);
+ pp_string (pp, ") ");
+   }
   if (TREE_CODE (TREE_TYPE (node)) == POINTER_TYPE
  && ! (flags & TDF_GIMPLE))
{
@@ -1693,11 +1703,7 @@ dump_generic_node (pretty_printer *pp, t
   else if (tree_fits_shwi_p (node))
pp_wide_integer (pp, tree_to_shwi (node));
   else if (tree_fits_uhwi_p (node))
-   {
- pp_unsigned_wide_integer (pp, tree_to_uhwi (node));
- if (flags & TDF_GIMPLE)
-   pp_character (pp, 'U');
-   }
+   pp_unsigned_wide_integer (pp, tree_to_uhwi (node));
   else
{
  wide_int val = node;
@@ -1710,6 +1716,24 @@ dump_generic_node (pretty_printer *pp, t
  print_hex (val, pp_buffer (pp)->digit_buffer);
  pp_string (pp, pp_buffer (pp)->digit_buffer);
}
+  if ((flags & TDF_GIMPLE)
+ && (POINTER_TYPE_P (TREE_TYPE (node))
+ || (TYPE_PRECISION

RE: [PATCH] MIPS: Fix generation of DIV.G and MOD.G for Loongson targets.

2017-01-12 Thread Maciej W. Rozycki

On Thu, 12 Jan 2017, Toma Tabacu wrote:

> > > Unfortunately, this interferes with the generation of DIV.G and MOD.G
> > > (the div3 and mod3 patterns) for Loongson targets,
> > which
> > > causes test failures.
> > 
> >  What test failures?  Details please.
> > 
> 
> It's
> gcc.target/mips/loongson-muldiv-1.c
> gcc.target/mips/loongson-muldiv-2.c
> gcc.target/mips/loongson3a-muldiv-1.c
> gcc.target/mips/loongson3a-muldiv-2.c
> on O2, O3, and Os.
> 
> They are also checking for the Loongson-specific multiply instruction,
> but there are no failures for that.

 So these tests have e.g.:

NOMIPS16 st sdiv (st x, st y) { return x / y + x % y; }

and as such it looks to me like this code does legitimately use a single 
DIV instruction rather than a DIV.G and MOD.G pair, at least at -O2/-O3, 
as I'd expect two divisions to take twice as much computing time as one 
does, and the avoidance of the extra accumulator access overhead needed 
with DIV does not compensate for it.  For -Os actual code generated will 
have to be checked; I suspect DIV.G/MOD.G ought to be used rather than 
DIV/MFLO/MFHI as it's two instructions vs three.

 So as a first step I'd split these tests into individual cases covering 
signed/unsigned function pairs each of which doing a single operation 
only, i.e. smul/umul, sdiv/udiv, smod/umod, which will then be expected to 
always use the extra Loongson instructions.  This ought to provide the 
coverage originally intended (study the discussion around the submission 
of the patch that introduced these tests to double-check).

 As a further step a test case for sdivmod/udivmod will then be needed, 
to cover the use of DIV vs DIV.G/MOD.G as required for speed vs space 
optimisation.

 Likewise for GSMULT/GSDIV/GSMOD, etc. (hmm, why are the signed 
MULT.G/GSMULT instruction variants never used?).

> > > This solution might be excessive, however, as it effectively forbids the
> > > generation of the old DIV instruction for Loongson targets, which 
> > > actually do
> > > support it.
> > 
> >  What's the purpose of this change other than "fixing test failures"?
> > Can you please demonstrate a technical justification of this change?  Has
> > there been a code quality regression which this patch addresses for
> > example?  What about source code which did emit `divmod4' and
> > `udivmod4' patterns on Loongson targets before r241660?
> > 
> >  Given that the DIV.G, MOD.G and accumulator DIV instructions (and their
> > unsigned counterparts) are all available the compiler should have freedom
> > to choose whichever hardware operation is the most suitable for the
> > calculations required according to code generation options selected and
> > artificially disabling some hardware instructions does not appear to be a
> > move in that direction to me.
> 
> I'll be honest here: I don't know when the compiler should generate the
> Loongson-specific division and modulo instructions, I don't have access to
> Loongson hardware, and I wasn't even specifically trying to fix 
> Loongson-related
> issues.
> 
> I admit that the patch was submitted in haste, and I now realize that my
> proposal was unfounded and that I don't have the means to find a satisfactory
> solution. Too much wishful thinking on my part.
> 
> However, there is a legitimate underlying issue here and I felt it had to be
> brought up, but this should have been a bug report, not a patch submission.

 This doesn't look to me like a bug even, just a test suite regression 
which has been uncovered by the change recently made, so I think it would 
be enough if you just posted the relevant piece of `gcc.log', so that it 
is immediately known to the reader what the symptoms are.

 Thanks for reporting!

  Maciej

[PATCH, Fortran, pr70697, v1] [Coarray] ICE on EVENT WAIT with array element UNTIL_COUNT argument

2017-01-12 Thread Andre Vehreschild

Hi all,

*** this is no duplicate, but +1 in the PR#! ***

attached patch fixes the ICE by resolving the expression in UNTIL_COUNT
correctly. The ICE was caused by the array-specification in UNTIL_COUNT not
correctly set.

Bootstraps and regtests ok on x86_64-linux/F25. Ok for trunk and gcc-6?

- Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/testsuite/ChangeLog:

2017-01-12  Andre Vehreschild  

PR fortran/70697
* gfortran.dg/coarray/event_4.f08: New test.


gcc/fortran/ChangeLog:

2017-01-12  Andre Vehreschild  

PR fortran/70697
* resolve.c (resolve_lock_unlock_event): Resolve the expression for
event's until_count.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a75d5fe..a5fe231 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9158,10 +9158,13 @@ resolve_lock_unlock_event (gfc_code *code)
 return;
 
   /* Check for EVENT WAIT the UNTIL_COUNT.  */
-  if (code->op == EXEC_EVENT_WAIT && code->expr4
-  && (code->expr4->ts.type != BT_INTEGER || code->expr4->rank != 0))
-gfc_error ("UNTIL_COUNT= argument at %L must be a scalar INTEGER "
-	   "expression", >expr4->where);
+  if (code->op == EXEC_EVENT_WAIT && code->expr4)
+{
+  if (!gfc_resolve_expr (code->expr4) || code->expr4->ts.type != BT_INTEGER
+	  || code->expr4->rank != 0)
+	gfc_error ("UNTIL_COUNT= argument at %L must be a scalar INTEGER "
+		   "expression", >expr4->where);
+}
 }
 
 
diff --git a/gcc/testsuite/gfortran.dg/coarray/event_4.f08 b/gcc/testsuite/gfortran.dg/coarray/event_4.f08
new file mode 100644
index 000..de901c0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/event_4.f08
@@ -0,0 +1,12 @@
+! { dg-do run }
+!
+! Check that pr 70697 is fixed.
+
+program event_4
+  use iso_fortran_env
+  integer :: nc(1)
+  type(event_type) done[*]
+  nc(1) = 1
+  event post(done[1])
+  event wait(done,until_count=nc(1))
+end

[Ada] Allow user-specified elaboration order constraints

This patch adds a new feature that allows the user to specify a particular
elaboration order for some or all library items in the program.

The following test should produce the following output:

Command line:

gprbuild -q -f -gnatE -g p-main.adb -bargs -l -felab-order.txt

elab-order.txt file:

-- This is the elaboration order:
p (spec) -- Spec of p comes first.
-- Then the spec of q, and so on:
q (spec)

r (spec)

p (body)

r (body)

q (body)

p.main (body)

ada.exceptions (spec) -- Predefined unit should be ignored.
no_such_thing (body) -- Nonexistent unit should be ignored.

Test output:

p (spec) <-- q (spec)
q (spec) <-- r (spec)
r (spec) <-- p (body)
p (body) <-- r (body)
r (body) <-- q (body)
q (body) <-- p.main (body)
"ada.exceptions%s": predefined unit ignored
"no_such_thing%b": not present; ignored

ELABORATION ORDER
   ada (spec)
   ada.characters (spec)
   ada.characters.handling (spec)
   ada.characters.latin_1 (spec)
   interfaces (spec)
   system (spec)
   system.address_operations (spec)
   system.address_operations (body)
   system.case_util (spec)
   system.case_util (body)
   system.img_int (spec)
   system.io (spec)
   system.io (body)
   system.parameters (spec)
   system.parameters (body)
   system.crtl (spec)
   interfaces.c_streams (spec)
   interfaces.c_streams (body)
   system.standard_library (spec)
   system.exceptions_debug (spec)
   system.exceptions_debug (body)
   system.storage_elements (spec)
   system.storage_elements (body)
   system.stack_checking (spec)
   system.stack_checking (body)
   system.traceback_entries (spec)
   system.traceback_entries (body)
   ada.exceptions (spec)
   system.soft_links (spec)
   system.unsigned_types (spec)
   system.img_uns (spec)
   system.val_lli (spec)
   system.val_llu (spec)
   system.val_util (spec)
   system.val_llu (body)
   system.val_lli (body)
   system.wch_con (spec)
   system.wch_con (body)
   system.wch_cnv (spec)
   system.wch_jis (spec)
   system.wch_jis (body)
   system.wch_cnv (body)
   system.wch_stw (spec)
   ada.exceptions.last_chance_handler (spec)
   ada.exceptions.last_chance_handler (body)
   ada.exceptions.traceback (spec)
   system.address_image (spec)
   system.bit_ops (spec)
   system.bit_ops (body)
   system.concat_2 (spec)
   system.concat_2 (body)
   system.concat_3 (spec)
   system.val_util (body)
   system.concat_3 (body)
   system.concat_4 (spec)
   system.concat_4 (body)
   system.concat_5 (spec)
   system.concat_5 (body)
   system.exception_table (spec)
   system.exception_table (body)
   ada.strings (spec)
   ada.strings.maps (spec)
   ada.strings.maps.constants (spec)
   interfaces.c (spec)
   system.exceptions (spec)
   system.exceptions (body)
   system.exceptions.machine (spec)
   system.assertions (spec)
   system.wch_stw (body)
   system.img_uns (body)
   system.img_int (body)
   system.assertions (body)
   system.exception_traces (spec)
   system.exception_traces (body)
   system.memory (spec)
   system.memory (body)
   system.standard_library (body)
   system.object_reader (spec)
   system.dwarf_lines (spec)
   system.secondary_stack (spec)
   interfaces.c (body)
   ada.strings.maps (body)
   system.soft_links (body)
   ada.characters.handling (body)
   system.secondary_stack (body)
   system.dwarf_lines (body)
   system.object_reader (body)
   system.address_image (body)
   ada.exceptions.traceback (body)
   system.traceback (spec)
   system.traceback (body)
   system.traceback.symbolic (spec)
   system.traceback.symbolic (body)
   ada.exceptions (body)
   p (spec)
   q (spec)
   r (spec)
   p (body)
   r (body)
   q (body)
   p.main (body)

Ada code:

with Q, R;
package body P is
   procedure P_Proc is
   begin
  null;
   end P_Proc;
end P;
package P is
   procedure P_Proc;
end P;
procedure P.Main is
begin
   null;
end P.Main;
with P;
package body Q is
   procedure Q_Proc is
   begin
  null;
   end Q_Proc;
end Q;
with P;
package Q is
   procedure Q_Proc;
end Q;
with P;
package body R is
   procedure R_Proc is
   begin
  null;
   end R_Proc;
end R;
with P;
package R is
   procedure R_Proc;
end R;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-12  Bob Duff  

* binde.adb (Forced): New reason for a dependence.
(Force_Elab_Order): Implementation of the new switch.
* binde.ads: Minor comment fixes.
* bindusg.adb: Add -f switch. Apparently, there was an -f switch
long ago that is no longer supported; removed comment about that.
* opt.ads (Force_Elab_Order_File): Name of file specified for
-f switch.
* switch-b.adb: Parse -f switch.

Index: bindusg.adb
===
--- bindusg.adb (revision 244350)
+++ bindusg.adb (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --

[Ada] Missing type invariant check on view conversion

This patch corrects an issue with "out" or "in out" arguments producing wrong
code when the argument is view converted. According to RM 7.3.2 (11-14)
invariant checks of intermediate types must be preformed in the order of the
parent to the child (skipping the parent) after the subprogram. With this
patch the appropriate calls to invariant checksare inserted after the
subprogram during expansion.


-- Source --


--  invariants.ads

package Invariants is

   -
   -- Testing --
   -

   type Type_Id is
 (Tag_1_Id,
  Tag_1_FV_Id,
  Tag_2_Id,
  Tag_2_FV_Id,
  Tag_3_Id,
  Tag_4_Id,
  Tag_4_FV_Id,
  Tag_5_Id,
  Tag_5_FV_Id,
  Tag_6_Id,
  Tag_7_Id,
  Iface_1_Id,
  Iface_2_Id,
  Iface_3_Id,
  Iface_4_Id);

   type Results is array (Type_Id) of Boolean;

   function Mark (Typ : Type_Id) return Boolean;
   --  Mark the result for a particular type as verified. The function always
   --  returns True.

   procedure Reset_Results;
   --  Reset the internally kept result state

   procedure Test_Results (Test_Id : String; Exp : Results);
   --  Ensure that the internally kept result state agrees with expected
   --  results Exp. Emit an error if this is not the case.

   
   -- Interfaces --
   

   type Iface_1 is interface
 with Type_Invariant'Class => Mark (Iface_1_Id);

   type Iface_2 is interface
 with Type_Invariant'Class => Mark (Iface_2_Id);

   type Iface_3 is interface and Iface_1 and Iface_2;

   type Iface_4 is interface and Iface_3
 with Type_Invariant'Class => Mark (Iface_4_Id);

   --
   -- Tagged types --
   --

   type Tag_1 is tagged private
 with Type_Invariant'Class => Mark (Tag_1_Id);

   type Tag_2 is new Tag_1 and Iface_1 and Iface_4 with private;

   type Tag_3 is new Tag_2 and Iface_2 and Iface_3 with private
 with Type_Invariant => Mark (Tag_3_Id);

   type Tag_4 is new Tag_3 and Iface_4 with private
 with Type_Invariant'Class => Mark (Tag_4_Id);

   type Tag_5 is tagged private;

   type Tag_6 is new Tag_5 with private
 with Type_Invariant => Mark (Tag_6_Id);

   type Tag_7 is new Tag_6 with private
 with Type_Invariant'Class => Mark (Tag_7_Id);

private

   type Tag_1 is tagged null record
 with Type_Invariant => Mark (Tag_1_FV_Id);
   --  own: Tag_1_Id, Tag_1_FV_Id
   --  inheritable: Tag_1_Id

   type Tag_2 is new Tag_1 and Iface_1 and Iface_4 with null record
 with Type_Invariant => Mark (Tag_2_FV_Id);
   --  own:   Tag_2_FV_Id
   --  inherited: Tag_1_Id, Iface_1_Id, Iface_2_Id, Iface_4_Id

   type Tag_3 is new Tag_2 and Iface_2 and Iface_3 with null record;
   --  own:   Tag_3_Id
   --  inherited: Iface_1_Id, Iface_2_Id, Iface_4_Id, Tag_1_Id

   type Tag_4 is new Tag_3 and Iface_4 with null record
 with Type_Invariant => Mark (Tag_4_FV_Id);
   --  own: Tag_4_Id, Tag_4_FV_Id
   --  inheritable: Tag_4_Id
   --  inherited  : Iface_1_Id, Iface_2_Id, Iface_4_Id, Tag_1_Id

   type Tag_5 is tagged null record
 with Type_Invariant => Mark (Tag_5_FV_Id);
   --  own: Tag_5_FV_Id

   type Tag_6 is new Tag_5 with null record;
   --  own: Tag_6_Id

   type Tag_7 is new Tag_6 with null record;
   --  own: Tag_7_Id

end Invariants;

--  invariants.adb

with Ada.Text_IO; use Ada.Text_IO;

package body Invariants is

   State : Results;

   --
   -- Mark --
   --

   function Mark (Typ : Type_Id) return Boolean is
   begin
  State (Typ) := True;
  Put_Line (" Check: " & Typ'Img);
  return True;
   end Mark;

   ---
   -- Reset_Results --
   ---

   procedure Reset_Results is
   begin
  State := (others => False);
   end Reset_Results;

   --
   -- Test_Results --
   --

   procedure Test_Results (Test_Id : String; Exp : Results) is
  Exp_Val   : Boolean;
  Posted: Boolean := False;
  State_Val : Boolean;

   begin
  for Index in Results'Range loop
 Exp_Val   := Exp (Index);
 State_Val := State (Index);

 if State_Val /= Exp_Val then
if not Posted then
   Posted := True;
   Put_Line (Test_Id & ": ERROR");
end if;

Put_Line ("  Expected: " & Exp_Val'Img & " for " & Index'Img);
Put_Line ("  Got:  " & State_Val'Img);
 end if;
  end loop;

  if not Posted then
 Put_Line (Test_Id & ": OK");
  end if;
   end Test_Results;

end Invariants;

--  fail.adb

procedure Fail is

   package Derived is

  type T is tagged private;
  type D is new T with private;
  type E is new D with private;

  procedure Create (X : out T);

   private

  type T is tagged record
 C : Integer;
  end record;

  type D is new T with null record
with Type_Invariant => D.C /= 0;

  type E is new D with null

RE: [PATCH] MIPS: Fix generation of DIV.G and MOD.G for Loongson targets.

2017-01-12 Thread Toma Tabacu

> Maciej Rozycki writes:
> 
> >
> > Unfortunately, this interferes with the generation of DIV.G and MOD.G
> > (the div3 and mod3 patterns) for Loongson targets,
> which
> > causes test failures.
> 
>  What test failures?  Details please.
> 

It's
gcc.target/mips/loongson-muldiv-1.c
gcc.target/mips/loongson-muldiv-2.c
gcc.target/mips/loongson3a-muldiv-1.c
gcc.target/mips/loongson3a-muldiv-2.c
on O2, O3, and Os.

They are also checking for the Loongson-specific multiply instruction,
but there are no failures for that.

> 
> > This solution might be excessive, however, as it effectively forbids the
> > generation of the old DIV instruction for Loongson targets, which actually 
> > do
> > support it.
> 
>  What's the purpose of this change other than "fixing test failures"?
> Can you please demonstrate a technical justification of this change?  Has
> there been a code quality regression which this patch addresses for
> example?  What about source code which did emit `divmod4' and
> `udivmod4' patterns on Loongson targets before r241660?
> 
>  Given that the DIV.G, MOD.G and accumulator DIV instructions (and their
> unsigned counterparts) are all available the compiler should have freedom
> to choose whichever hardware operation is the most suitable for the
> calculations required according to code generation options selected and
> artificially disabling some hardware instructions does not appear to be a
> move in that direction to me.
> 
>   Maciej

I'll be honest here: I don't know when the compiler should generate the
Loongson-specific division and modulo instructions, I don't have access to
Loongson hardware, and I wasn't even specifically trying to fix Loongson-related
issues.

I admit that the patch was submitted in haste, and I now realize that my
proposal was unfounded and that I don't have the means to find a satisfactory
solution. Too much wishful thinking on my part.

However, there is a legitimate underlying issue here and I felt it had to be
brought up, but this should have been a bug report, not a patch submission.

Anyway, thank you for the feedback.

Regards,
Toma

Re: [Patch 4/5] OpenACC tile clause support, Fortran front-end parts

On Tue, Nov 29, 2016 at 05:47:08PM -0800, Cesar Philippidis wrote:
> On 11/18/2016 03:24 AM, Jakub Jelinek wrote:
> > On Sat, Nov 12, 2016 at 08:51:00AM -0800, Cesar Philippidis wrote:
> >> On 11/11/2016 02:34 AM, Jakub Jelinek wrote:
> >>> On Thu, Nov 10, 2016 at 06:46:46PM +0800, Chung-Lin Tang wrote:
> >>
> >> And here's the patch.
> > 
> > The patch doesn't look like OpenACC tile clause fortran support,
> > but bind/nohost clause C/C++ support.
> 
> I think I got that patch mixed up with the acc routines patch. Here is
> the fortran tile clause patch.
> 
> One notable difference between the trunk and gomp4 implementation of the
> tile clause is that gomp4 errors on negative value tile arguments,
> whereas trunk issues warnings. Is there a reason why the fortran FE
> generally emits a warning, on say num_threads(-5), instead of an error?
> 
> Chung-Lin, I noticed in your source tree that you included a change to
> gfortranspec.c. Is that necessary for trunk? I've included in this patch
> just in case the other tile patches require it.

This is ok for trunk without the gfortranspec.c hunk (please remove it also
from the ChangeLog entry).

> 2016-11-29  Cesar Philippidis  
>   Joseph Myers  
> 
>   gcc/fortran/
>   * gfortranspec.c (lang_specific_pre_link): Update call to do_spec.
>   * openmp.c (resolve_omp_clauses): Error on directives
>   containing both tile and collapse clauses.
>   (resolve_oacc_loop_blocks): Represent '*' tile arguments as zero.
>   * trans-openmp.c (gfc_trans_omp_do): Lower tiled loops like
>   collapsed loops.
> 
>   gcc/testsuite/
>   * gfortran.dg/goacc/combined-directives.f90: Remove xfail.
>   * gfortran.dg/goacc/tile-1.f90: New test.
>   * gfortran.dg/goacc/tile-2.f90: New test.
>   * gfortran.dg/goacc/tile-lowering.f95: New test.

Jakub

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
> It also lacks expressiveness when comparing
> 
>   short s;
>   s_1 = (short) 1;
>   s_2 = short (1);
> 
> IMHO having a _Literal somewhere makes it more obvious what is meant
> (I'm still going to dump 1u or 1l instead of _Literal (unsigned) 1
> of course as that's even more easy to recognize).

So, with the _Literal (type) constant syntax, what are we going to emit
and parse for __int128 constants?
_Literal (__int128) (0x123456ULL << 64 || 0x123456ULL), something else?

Jakub

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On Thu, 12 Jan 2017, Jakub Jelinek wrote:

> On Thu, Jan 12, 2017 at 04:38:27PM +0530, Prathamesh Kulkarni wrote:
> > On 12 January 2017 at 16:15, Richard Biener  wrote:
> > > On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> > >
> > >> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
> > >> > > I'll give the (short) 1 parsing a try though to see how awkward it
> > >> > > really gets.
> > >> >
> > >> > Ok, doesn't look a good way to go.  Apart from making it difficult
> > >> > to handle in the parser you can't distinguish a conversion from an
> > >> > integer literal and a short literal for
> > >> >
> > >> >  short s;
> > >> >  s_1 = (short) 1;
> > >>
> > >> As there are tons of types the integer literals can have, wouldn't it be
> > >> better to just introduce _Literal  where you could supply
> > >> the type if it is not one where C provides a suffix for it or int?
> > >> Then we could avoid adding lots of suffixes for new and newer types.
> > >> Of course for integer literals with int, unsigned int, {,unsigned} long 
> > >> {,long}
> > >> one would still use no suffix, U, {,U}L{,L} suffixes.
> > >
> > > That's an interesting idea.  _Literal (type) value might be alternative
> > > syntax (a cast to be evaulated as literal).  I'll give it a shot.
> > Um, how about just type(value) ?
> > s_1 = short (10);
> > AFAIU this isn't legal C and could be added as an extension ?
> 
> Even C++ doesn't allow this syntax if the type isn't a single token.
> So you can't use unsigned __int128 (5) or unsigned char (7) or signed char 
> (-5).

It also lacks expressiveness when comparing

  short s;
  s_1 = (short) 1;
  s_2 = short (1);

IMHO having a _Literal somewhere makes it more obvious what is meant
(I'm still going to dump 1u or 1l instead of _Literal (unsigned) 1
of course as that's even more easy to recognize).

Richard.

Re: [PATCH v2 C++] Fix PR70182 -- missing "on" in mangling of unresolved operators

2017-01-12 Thread Nathan Sidwell


On 01/12/2017 02:57 AM, Markus Trippelsdorf wrote:


Thanks for the review. Here is a new patch:


Thanks, that does address my comments.  AFAICT your reading of the ABI 
doc is correct, but I'd like Jason to confirm that.


you're missing the testsuite/ChangeLog entry, don't forget.

nathan
--
Nathan Sidwell

Re: [Patch 4/5] OpenACC tile clause support, Fortran front-end parts

2017-01-12 Thread Chung-Lin Tang

[ping]

Hi Jakub,
I don't think we ever got approval for the Fortran parts of the OpenACC tile 
patch?
Is this okay for trunk? I'll be committing all parts of the patch once the 
Fortran
parts are approved.

Thanks,
Chung-Lin


On 2016/12/14 04:37 PM, Chung-Lin Tang wrote:
> On 2016/11/30 10:47 AM, Cesar Philippidis wrote:
>> On 11/18/2016 03:24 AM, Jakub Jelinek wrote:
>>> On Sat, Nov 12, 2016 at 08:51:00AM -0800, Cesar Philippidis wrote:
 On 11/11/2016 02:34 AM, Jakub Jelinek wrote:
> On Thu, Nov 10, 2016 at 06:46:46PM +0800, Chung-Lin Tang wrote:

 And here's the patch.
>>>
>>> The patch doesn't look like OpenACC tile clause fortran support,
>>> but bind/nohost clause C/C++ support.
>>
>> I think I got that patch mixed up with the acc routines patch. Here is
>> the fortran tile clause patch.
>>
>> One notable difference between the trunk and gomp4 implementation of the
>> tile clause is that gomp4 errors on negative value tile arguments,
>> whereas trunk issues warnings. Is there a reason why the fortran FE
>> generally emits a warning, on say num_threads(-5), instead of an error?
>>
>> Chung-Lin, I noticed in your source tree that you included a change to
>> gfortranspec.c. Is that necessary for trunk? I've included in this patch
>> just in case the other tile patches require it.
>>
>> Cesar
>>
> 
> About the gfortranspec.c change, that's just a testing artifact, not part of 
> the Fortran FE patch.
> 
> Chung-Lin
>

Re: [PATCH][ARM]Use different startfile and endfile for elf target when generating shared object.

2017-01-12 Thread kugan


Hi,

On 16/06/16 21:04, Renlin Li wrote:

 /* Now we define the strings used to build the spec file.  */
-#define UNKNOWN_ELF_STARTFILE_SPEC " crti%O%s crtbegin%O%s crt0%O%s"
+#define UNKNOWN_ELF_STARTFILE_SPEC \
+  "crti%O%s \
+  %{!shared:crtbegin%O%s} %{shared:crtbeginS%O%s} \
+  crt0%O%s"


Some targets seems to use shared|pie. When you change it, shouldn't it 
also include for pie?


Thanks,
Kugan

[PATCH, Fortran, pr70696, v1] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

2017-01-12 Thread Andre Vehreschild

Hi all,

attached patch fixes the ICE when using an event in a subroutine. The reason
for the ICE was that the backend_decl of the symbol to event on was not set
when accessed. The patch ensures this. Furthermore did I fix a invalid memory
access in the caf_single lib, where to less memory was allocated in the
registration of the event.

Bootstraps and regtests ok on x86_64-linux/F25. Ok for trunk?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/testsuite/ChangeLog:

2017-01-12  Andre Vehreschild  

PR fortran/70696
* gfortran.dg/coarray/event_3.f08: New test.

gcc/fortran/ChangeLog:

2017-01-12  Andre Vehreschild  

PR fortran/70696
* trans-expr.c (gfc_get_tree_for_caf_expr): Ensure the backend_decl
is valid before accessing it.

libgfortran/ChangeLog:

2017-01-12  Andre Vehreschild  

PR fortran/70696
* caf/single.c (_gfortran_caf_register): Allocate enough memory for
the event counter.


diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index caaee6b..01b7dd2 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1838,6 +1838,10 @@ gfc_get_tree_for_caf_expr (gfc_expr *expr)
 		 "component at %L is not supported", >where);
   }
 
+  /* Make sure the backend_decl is present before accessing it.  */
+  if (expr->symtree->n.sym->backend_decl == NULL_TREE)
+expr->symtree->n.sym->backend_decl
+	= gfc_get_symbol_decl (expr->symtree->n.sym);
   caf_decl = expr->symtree->n.sym->backend_decl;
   gcc_assert (caf_decl);
   if (expr->symtree->n.sym->ts.type == BT_CLASS)
diff --git a/gcc/testsuite/gfortran.dg/coarray/event_3.f08 b/gcc/testsuite/gfortran.dg/coarray/event_3.f08
new file mode 100644
index 000..f6e28b7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/event_3.f08
@@ -0,0 +1,20 @@
+! { dg-do run }
+!
+! Check PR fortran/70696 is fixed.
+
+program global_event
+  use iso_fortran_env , only : event_type
+  implicit none
+  type(event_type) :: x[*]
+  
+  call exchange
+  contains
+subroutine exchange
+  integer :: cnt
+  event post(x[1])
+  event post(x[1])
+  call event_query(x, cnt)
+  if (cnt /= 2) error stop 1
+  event wait(x, until_count=2)
+end subroutine
+end 
diff --git a/libgfortran/caf/single.c b/libgfortran/caf/single.c
index cf78a1a..8d3bcbf 100644
--- a/libgfortran/caf/single.c
+++ b/libgfortran/caf/single.c
@@ -141,9 +141,12 @@ _gfortran_caf_register (size_t size, caf_register_t type, caf_token_t *token,
   caf_single_token_t single_token;
 
   if (type == CAF_REGTYPE_LOCK_STATIC || type == CAF_REGTYPE_LOCK_ALLOC
-  || type == CAF_REGTYPE_CRITICAL || type == CAF_REGTYPE_EVENT_STATIC
-  || type == CAF_REGTYPE_EVENT_ALLOC)
+  || type == CAF_REGTYPE_CRITICAL)
 local = calloc (size, sizeof (bool));
+  else if (type == CAF_REGTYPE_EVENT_STATIC || type == CAF_REGTYPE_EVENT_ALLOC)
+/* In the event_(wait|post) function the counter for events is a uint32,
+   so better allocate enough memory here.  */
+local = calloc (size, sizeof (uint32_t));
   else if (type == CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY)
 local = NULL;
   else

[ping] libobjc patches and zlib update

2017-01-12 Thread Matthias Klose

[CCing some global reviewers]

Please review the two libobjc patches:

  https://gcc.gnu.org/ml/gcc-patches/2016-12/msg02003.html
- not a regression, but a simplification of the new
  configure option.
  https://gcc.gnu.org/ml/gcc-patches/2016-12/msg02004.html
- fix the --disable-shared build with external bdw-gc.
  Fixed the texi typo as mentioned by Andreas.

and the proposed zlib update:

  https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00315.html

Thanks, Matthias

Re: [PING][PATCH][ARM]Use different startfile and endfile for elf target when generating shared object.

2017-01-12 Thread Renlin Li


~ Ping

https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01227.html

Regards,
Renlin

On 14/12/16 15:33, Renlin Li wrote:

Ping~

Regards,
Renlin

On 16/06/16 12:04, Renlin Li wrote:

Hi all,

GCC has startfile and endfile spec string built into it.
startfile is used to specify objects files to include at the start of the link 
process.
While endfile, on the other hand, is used to specify objects files to include 
at the end
of the link process.

crtbegin.o is one of the object files specified by startfile spec string. IIUC,
crtbeginS.o should be used in place of crtbegin.o when generating shared 
objects.
The same applies to crtend.o which is one of the endfile. crtendS.o should be 
used when
generating shared objects.

This patch makes the change to use different crtbegin and crtend files when 
creating
shared and static object for elf toolchain. The linux toolchain already did this
differentiation.

So when the toolchain doesn't support shared object, the following error 
message will be
produced:
ld: cannot find crtbeginS.o: No such file or directory

Still, those specs strings built into GCC can be overridden by using
-specs=command-line switch to specify a spec file.

arm-none-eabi regression test without new issues, OK for trunk?

Regards,
Renlin Li

gcc/ChangeLog:

2016-06-16  Renlin Li  

 * config/arm/unknown-elf.h (UNKNOWN_ELF_STARTFILE_SPEC): Use
 crtbeginS.o for shared object.
 (UNKNOWN_ELF_ENDFILE_SPEC): Use crtendS.o for shared object.

Re: [PATCH] [PR rtl-optimization/65618] Fix MIPS ADA bootstrap failure

2017-01-12 Thread James Cowgill

On 11/01/17 17:22, Maciej W. Rozycki wrote:
> On Wed, 11 Jan 2017, James Cowgill wrote:
> 
>>>  From this consideration I gather you have a program source which can be 
>>> used as a test case to reproduce the issue, so can you please file a 
>>> problem report and include the source and a recipe to reproduce it?  Is 
>>> this a GCC issue with generated assembly or a GAS issue with interpreting
>>> it?
>>
>> Yes I had a testcase which I used to debug this, but it was pretty huge
>> (and written in ADA). When debugging I just diffed it with the debug
>> information toggled to see if the patch fixed it. I'll see if I can find
>> it anyway.
> 
>  A test case being huge is not an issue, we can always try to reduce it if 
> needed.  What is key is reproducibility.  Please make sure it's 
> self-contained, i.e. doesn't depend on system-installed components (for 
> C/C++ I'd ask for a preprocessed source, but I'm not sure offhand what the 
> requirements are for ADA -- it's been a while since I did anything about 
> ADA, and even then not a huge lot -- just a GCC 3.4 MIPS port).

Filed as PR/79071

James

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On Thu, Jan 12, 2017 at 04:38:27PM +0530, Prathamesh Kulkarni wrote:
> On 12 January 2017 at 16:15, Richard Biener  wrote:
> > On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> >
> >> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
> >> > > I'll give the (short) 1 parsing a try though to see how awkward it
> >> > > really gets.
> >> >
> >> > Ok, doesn't look a good way to go.  Apart from making it difficult
> >> > to handle in the parser you can't distinguish a conversion from an
> >> > integer literal and a short literal for
> >> >
> >> >  short s;
> >> >  s_1 = (short) 1;
> >>
> >> As there are tons of types the integer literals can have, wouldn't it be
> >> better to just introduce _Literal  where you could supply
> >> the type if it is not one where C provides a suffix for it or int?
> >> Then we could avoid adding lots of suffixes for new and newer types.
> >> Of course for integer literals with int, unsigned int, {,unsigned} long 
> >> {,long}
> >> one would still use no suffix, U, {,U}L{,L} suffixes.
> >
> > That's an interesting idea.  _Literal (type) value might be alternative
> > syntax (a cast to be evaulated as literal).  I'll give it a shot.
> Um, how about just type(value) ?
> s_1 = short (10);
> AFAIU this isn't legal C and could be added as an extension ?

Even C++ doesn't allow this syntax if the type isn't a single token.
So you can't use unsigned __int128 (5) or unsigned char (7) or signed char (-5).

Jakub

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

2017-01-12 Thread Prathamesh Kulkarni

On 12 January 2017 at 16:15, Richard Biener  wrote:
> On Thu, 12 Jan 2017, Jakub Jelinek wrote:
>
>> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
>> > > I'll give the (short) 1 parsing a try though to see how awkward it
>> > > really gets.
>> >
>> > Ok, doesn't look a good way to go.  Apart from making it difficult
>> > to handle in the parser you can't distinguish a conversion from an
>> > integer literal and a short literal for
>> >
>> >  short s;
>> >  s_1 = (short) 1;
>>
>> As there are tons of types the integer literals can have, wouldn't it be
>> better to just introduce _Literal  where you could supply
>> the type if it is not one where C provides a suffix for it or int?
>> Then we could avoid adding lots of suffixes for new and newer types.
>> Of course for integer literals with int, unsigned int, {,unsigned} long 
>> {,long}
>> one would still use no suffix, U, {,U}L{,L} suffixes.
>
> That's an interesting idea.  _Literal (type) value might be alternative
> syntax (a cast to be evaulated as literal).  I'll give it a shot.
Um, how about just type(value) ?
s_1 = short (10);
AFAIU this isn't legal C and could be added as an extension ?

Thanks,
Prathamesh
>
>> > It looks like we currently have no way to write __int128 literals in C?
>> >
>> > __int128 x = 0x;
>>
>> Yeah, one typically has to use
>> __int128 x = (((unsigned __int128) 0xULL) << 64) | 
>> 0xULL;
>> or something similar.
>
> I see.
>
> Thanks,
> Richard.

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On Thu, 12 Jan 2017, Jakub Jelinek wrote:

> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
> > > I'll give the (short) 1 parsing a try though to see how awkward it
> > > really gets.
> > 
> > Ok, doesn't look a good way to go.  Apart from making it difficult
> > to handle in the parser you can't distinguish a conversion from an
> > integer literal and a short literal for
> > 
> >  short s;
> >  s_1 = (short) 1;
> 
> As there are tons of types the integer literals can have, wouldn't it be
> better to just introduce _Literal  where you could supply
> the type if it is not one where C provides a suffix for it or int?
> Then we could avoid adding lots of suffixes for new and newer types.
> Of course for integer literals with int, unsigned int, {,unsigned} long 
> {,long}
> one would still use no suffix, U, {,U}L{,L} suffixes.

That's an interesting idea.  _Literal (type) value might be alternative
syntax (a cast to be evaulated as literal).  I'll give it a shot.

> > It looks like we currently have no way to write __int128 literals in C?
> > 
> > __int128 x = 0x;
> 
> Yeah, one typically has to use
> __int128 x = (((unsigned __int128) 0xULL) << 64) | 
> 0xULL;
> or something similar.

I see.

Thanks,
Richard.

Re: [fixincludes] Only declare gets for C++ < 2014 on Solaris (PR libstdc++/78979)

2017-01-12 Thread Rainer Orth

Rainer Orth  writes:

> While investigating PR libstdc++/78979, it turns out that Solaris
>  incorrectly declares std::gets even for C++14 where it's been
> removed.  This patch fixes that by adding an additional __cplusplus <
> 201402L guard via fixincludes.  This works for Solaris 12 (and 11), but
> Solaris 10 declares the function unconditionally (i.e. without the
> __STDC_VERSION__ < 201112L guard and the deprecated attribute), so
> another fix adds both to handle that version, too.  With this in place,
> the std::gets declaration in  needs a guard, too.
>
> While testing this patch together with
>
>   https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00288.html
>
> it turned out another fix is needed which I'm throwing in here, too:
>
>  declares
>
> #if defined(_STDC_C11)
> extern _Noreturn void quick_exit(int);
> #else
> extern void quick_exit(int) __NORETURN;
> #endif  /* _STDC_C11 */
>
> and the first one now breaks badly with __STDC_VERSION__ defined to the
> C11 value:
>
> /usr/include/iso/stdlib_c99.h:83:8: error: '_Noreturn' does not name a type
>  extern _Noreturn void quick_exit(int);
> ^
>
> To avoid this, I've changed to C11-only _Noreturn to
> __attribute__((__noreturn__)).
>
> Bootstrapped without regressions on i386-pc-solaris2.1[02] and
> sparc-sun-solaris2.12 and fixing
>
> FAIL: 27_io/headers/cstdio/functions_neg.cc  (test for errors, line 24)
>
> as designed.  fixincludes make check, passes, too.
>
> Ok for mainline now?  I'd like to backport the patch to the gcc-5 and
> gcc-6 branches which are equally affected.

I just noticed that the submitted patch lacked the _Noreturn part
described above.  Here it is.

Rainer

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


# HG changeset patch
# Parent  8b946d3b0b1ff1d40660db201feee5925260f9ee
Only declare gets for C++ < 2014 on Solaris (PR libstdc++/78979)

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -3593,6 +3593,43 @@ fix = {
 };
 
 /*
+ *  Solaris  should deprecate gets before C11.
+ */
+fix = {
+hackname  = solaris_gets_c11;
+mach  = "*-*-solaris2*";
+files = "iso/stdio_iso.h";
+select= "(extern char[ \t]*\\*gets\\(char \\*\\));";
+
+c_fix = format;
+c_fix_arg = "#if __STDC_VERSION__ < 201112L && __cplusplus < 201402L\n"
+		"%1 __attribute__((__deprecated__));\n"
+		"#endif";
+
+test_text = "extern char	*gets(char *);";
+};
+
+/*
+ *  Solaris  shouldn't declare gets for C++14.
+ */
+fix = {
+hackname  = solaris_gets_cxx14;
+mach  = "*-*-solaris2*";
+files = "iso/stdio_iso.h";
+select= <<- _EOSelect_
+(#if __STDC_VERSION__ < 201112L)
+(extern char	\*gets\(char \*\) __ATTR_DEPRECATED;)
+_EOSelect_;
+c_fix = format;
+c_fix_arg = "%1 && __cplusplus < 201402L\n%2";
+
+test_text = <<- _EOText_
+#if __STDC_VERSION__ < 201112L
+extern char	*gets(char *) __ATTR_DEPRECATED;
+_EOText_;
+};
+
+/*
  * Sun Solaris 2 has a version of sys/int_const.h that defines
  * UINT8_C and UINT16_C to unsigned constants.
  */
@@ -3982,6 +4019,21 @@ fix = {
 };
 
 /*
+ *  Solaris  shouldn't use std::gets for C++14.
+ */
+fix = {
+hackname  = solaris_std_gets_cxx14;
+mach  = "*-*-solaris2*";
+files = "stdio.h";
+select= "using std::gets;";
+
+c_fix = format;
+c_fix_arg = "#if __cplusplus < 201402L\n%0\n#endif";
+
+test_text = "using std::gets;";
+};
+
+/*
  * Sun Solaris 8 has what appears to be some gross workaround for
  * some old version of their c++ compiler.  G++ doesn't want it
  * either, but doesn't want to be tied to SunPRO version numbers.
@@ -4000,6 +4052,21 @@ fix = {
 };
 
 /*
+ *  Solaris  shouldn't use _Noreturn, breaks with C++.
+ */
+fix = {
+hackname  = solaris_stdlib_noreturn;
+mach  = "*-*-solaris2*";
+files = "iso/stdlib_c99.h";
+select= "(extern) _Noreturn (void quick_exit\\(int\\));";
+
+c_fix = format;
+c_fix_arg = "%1 %2 __attribute__((__noreturn__));";
+
+test_text = "extern _Noreturn void quick_exit(int);";
+};
+
+/*
  *  a missing semi-colon at the end of the statsswtch structure definition.
  */
 fix = {
diff --git a/fixincludes/tests/base/iso/stdio_iso.h b/fixincludes/tests/base/iso/stdio_iso.h
--- a/fixincludes/tests/base/iso/stdio_iso.h
+++ b/fixincludes/tests/base/iso/stdio_iso.h
@@ -12,3 +12,16 @@
 #if defined( SOLARIS_GETC_STRICT_STDC_CHECK )
 #if	!defined(_REENTRANT) && !defined(_LP64) && (!defined(_STRICT_STDC) || (__cplusplus >= 199711L))
 #endif  /* SOLARIS_GETC_STRICT_STDC_CHECK */
+
+
+#if defined( SOLARIS_GETS_C11_CHECK )
+#if __STDC_VERSION__ < 201112L && __cplusplus < 201402L
+extern char	*gets(char *) __attribute__((__deprecated__));
+#endif
+#endif  /* SOLARIS_GETS_C11_CHECK */
+
+
+#if defined(

Re: [RFC] combine: Handle zero_extend without subreg in change_zero_ext.

2017-01-12 Thread Dominik Vogt

On Wed, Jan 11, 2017 at 12:02:40PM -0600, Segher Boessenkool wrote:
> On Thu, Jan 05, 2017 at 05:46:51PM +0100, Dominik Vogt wrote:
> > The attached patch deals with another type of zero_extend that is
> > not yet handled in change_zero_ext, i.e. (zero_extend
> > (pseudoreg)), without a "subreg" in between.  What do you think?
> > (Mostly untested yet.)
> 
> My main question is: where is this useful?  Can you show some example
> please?

With this test program:

  int foo (int *b)
  {
int i;
int r;
for (i = 0; i < 77; i++)
{
  r |= b[0] > 0;
  r |= b[i] > 0;
}
return r;
  }

before combine we have

  (insn 47 45 48 7 (set (reg:SI 104)
  (zero_extend:SI (reg:QI 103)))
  (insn 48 47 49 7 (parallel [
  (set (reg/v:SI 88 [ r ])
  (ior:SI (reg/v:SI 88 [ r ])
  (reg:SI 104)))
  (clobber (reg:CC 33 %cc))
  ])

combine tries

  (set (reg/v:SI 88 [ r ])
  (ior:SI (zero_extend:SI (reg:QI 103))
  (reg/v:SI 88 [ r ])))

With the patch it also tries

(set (reg/v:SI 88 [ r ])
(ior:SI (and:SI (subreg:SI (reg:QI 103) 0)
(const_int -1 [0x]))
(reg/v:SI 88 [ r ])))

which is just one of the standard patterns for rosbg.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs

On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
> > I'll give the (short) 1 parsing a try though to see how awkward it
> > really gets.
> 
> Ok, doesn't look a good way to go.  Apart from making it difficult
> to handle in the parser you can't distinguish a conversion from an
> integer literal and a short literal for
> 
>  short s;
>  s_1 = (short) 1;

As there are tons of types the integer literals can have, wouldn't it be
better to just introduce _Literal  where you could supply
the type if it is not one where C provides a suffix for it or int?
Then we could avoid adding lots of suffixes for new and newer types.
Of course for integer literals with int, unsigned int, {,unsigned} long {,long}
one would still use no suffix, U, {,U}L{,L} suffixes.

> It looks like we currently have no way to write __int128 literals in C?
> 
> __int128 x = 0x;

Yeah, one typically has to use
__int128 x = (((unsigned __int128) 0xULL) << 64) | 
0xULL;
or something similar.

Jakub

Re: [patch,avr] PR78883: Implement a dummy scheduler

2017-01-12 Thread Georg-Johann Lay


On 12.01.2017 10:00, Richard Sandiford wrote:

Georg-Johann Lay  writes:

On 04.01.2017 20:29, Jeff Law wrote:

On 01/04/2017 12:18 PM, Segher Boessenkool wrote:

On Wed, Jan 04, 2017 at 06:42:23PM +, Richard Sandiford wrote:

1. reload has a bug that no-one really wants to fix (understandable)
2. the bug is triggered by paradoxical subregs of mems
3. those subregs are normally disabled on targets that support insn
   scheduling
4. therefore, define an insn scheduler
5. we don't actually want insn scheduling, so either
   (a) make sure the insn scheduler is never actually used for insn
   scheduling, or
   (b) allow the insn scheduler to run anyway but encourage it to do
nothing
   (other than take compile time)

(4) and (5) feel like too much of a hack to me.  They're going to have
other consequences, e.g. we'll no longer give the warning:

  instruction scheduling not supported on this target machine

if users try to use -fschedule-insns.  And since we don't support
meaningful insn scheduling even after this patch, giving the warning
seems more user-friendly than dropping it.

I think the consensus is that we don't want these subregs for AVR
regardless of whether scheduling is used, and probably wouldn't want
them even without this bug.


Right, and the same is true for most targets.  Subregs of memory are not
something you want.  As rtl.texi says:


@item mem
@code{subreg}s of @code{mem} were common in earlier versions of GCC and
are still supported.  During the reload pass these are replaced by plain
@code{mem}s.  On machines that do not do instruction scheduling, use of
@code{subreg}s of @code{mem} are still used, but this is no longer
recommended.  Such @code{subreg}s are considered to be
@code{register_operand}s rather than @code{memory_operand}s before and
during reload.  Because of this, the scheduling passes cannot properly
schedule instructions with @code{subreg}s of @code{mem}, so for machines
that do scheduling, @code{subreg}s of @code{mem} should never be used.
To support this, the combine and recog passes have explicit code to
inhibit the creation of @code{subreg}s of @code{mem} when
@code{INSN_SCHEDULING} is defined.



So why not instead change the condition
used by general_operand, like we were talking about yesterday?
It seems simpler and more direct.


We should split off a new "SUBREGS_OF_MEM_ALLOWED" from !INSN_SCHEDULING,
and then probably even default it to false.

That would work for me :-)  The question in my mind would be unexpected
fallout at this point in the release process.  Maybe default it to
!INSN_SCHEDULING to minimize such fallout now, then to false for gcc-8?


jeff


Bit if we disable it, what's the point of introducing changes to combine
which come up with even more of such subregs?

For targets with scheduling, which applies to most of the targets, the
"optimization" in combine will be void as rejected by general_operand,
hence a target would have explicit paradoxical subregs in the back end
or use some home brew predicated that allow that stuff and use internal
knowledge of what combine does.

Moreover I have some problems in explaining what the new hook macro is
supposed to do:

"Disable/enable paradoxical SUBREGs of MEM in general_operands before
register allocation.  Use this hook if your back end has trouble with
paradoxical subregs of mem.  Enabled per default iff the target
provides an insn scheduler."


Sounds OK to me, but...


Who would understand this and infer from the docs whether this macro
should be used?



Who would understand this and infer from the docs whether this macro
should be used?


...how about:

---
Define this macro if you do not want predicates such as
@code{general_operand} and @code{register_operand} to accept paradoxical
@code{subreg}s of @code{mem}s before register allocation.  Early versions
of GCC treated such @code{subreg}s as register operands and required
the register allocator to load the inner @code{mem} into a temporary
register.  However, this approach effectively hid the load from
pre-allocation optimizations like CSE and scheduling and is therefore
deprecated.


As avr cannot operate on memory, it will have to load such values,
hence the conclusion would be to enable that stuff?


The macro exists so that targets can individually move to the new,
preferred, behavior before the deprecated behavior is removed.
The macro is defined by default for targets that support instruction
scheduling.


Also it appears as purely an optimization tweak, not about kicking
out expressions which ICE your backend.


---


And if such subregs are forbidden, why are they generated in the first
place? Shouldn't combine also respect that hook?


Combine often tries things that the target doesn't accept, so I think
what it's doing is valid.  Are you worried about a missed optimisation?

Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs