[PATCH] Fix PR87349/87342

[Richard Biener]

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

Richard.

2018-09-19  Richard Biener  

PR tree-optimization/87349
PR tree-optimization/87342
* tree-ssa-sccvn.c (do_rpo_vn): Iterate max_rpo computation.

* gcc.dg/torture/pr87349-1.c: New testcase.
* gcc.dg/torture/pr87349-2.c: Likewise.
* gcc.dg/torture/pr87342.c: Likewise.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 264390)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -6374,6 +6374,7 @@ do_rpo_vn (function *fn, edge entry, bit
   vn_valueize = rpo_vn_valueize;
 
   /* Initialize the unwind state and edge/BB executable state.  */
+  bool need_max_rpo_iterate = false;
   for (int i = 0; i < n; ++i)
 {
   basic_block bb = BASIC_BLOCK_FOR_FN (fn, rpo[i]);
@@ -6388,11 +6389,14 @@ do_rpo_vn (function *fn, edge entry, bit
  if (e->flags & EDGE_DFS_BACK)
has_backedges = true;
  e->flags &= ~EDGE_EXECUTABLE;
- if (e == entry)
+ if (iterate || e == entry)
continue;
  if (bb_to_rpo[e->src->index] > i)
-   rpo_state[i].max_rpo = MAX (rpo_state[i].max_rpo,
-   bb_to_rpo[e->src->index]);
+   {
+ rpo_state[i].max_rpo = MAX (rpo_state[i].max_rpo,
+ bb_to_rpo[e->src->index]);
+ need_max_rpo_iterate = true;
+   }
  else
rpo_state[i].max_rpo
  = MAX (rpo_state[i].max_rpo,
@@ -6403,6 +6407,35 @@ do_rpo_vn (function *fn, edge entry, bit
   entry->flags |= EDGE_EXECUTABLE;
   entry->dest->flags |= BB_EXECUTABLE;
 
+  /* When there are irreducible regions the simplistic max_rpo computation
+ above for the case of backedges doesn't work and we need to iterate
+ until there are no more changes.  */
+  unsigned nit = 0;
+  while (need_max_rpo_iterate)
+{
+  nit++;
+  need_max_rpo_iterate = false;
+  for (int i = 0; i < n; ++i)
+   {
+ basic_block bb = BASIC_BLOCK_FOR_FN (fn, rpo[i]);
+ edge e;
+ edge_iterator ei;
+ FOR_EACH_EDGE (e, ei, bb->preds)
+   {
+ if (e == entry)
+   continue;
+ int max_rpo = MAX (rpo_state[i].max_rpo,
+rpo_state[bb_to_rpo[e->src->index]].max_rpo);
+ if (rpo_state[i].max_rpo != max_rpo)
+   {
+ rpo_state[i].max_rpo = max_rpo;
+ need_max_rpo_iterate = true;
+   }
+   }
+   }
+}
+  statistics_histogram_event (cfun, "RPO max_rpo iterations", nit);
+
   /* As heuristic to improve compile-time we handle only the N innermost
  loops and the outermost one optimistically.  */
   if (iterate)
Index: gcc/testsuite/gcc.dg/torture/pr87349-1.c
===
--- gcc/testsuite/gcc.dg/torture/pr87349-1.c(nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr87349-1.c(working copy)
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+
+void
+h1 (int *fh, int pw)
+{
+  *fh = 0;
+  if (*fh != 0)
+for (;;)
+  {
+   fh = &pw;
+
+   if (pw == 0)
+ {
+ }
+   else
+ while (pw < 1)
+   {
+ if (pw == 0)
+   {
+ut:
+ ;
+   }
+
+ ++pw;
+   }
+
+   if (pw == 0)
+ goto ut;
+  }
+
+  goto ut;
+}
+
Index: gcc/testsuite/gcc.dg/torture/pr87349-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr87349-2.c(nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr87349-2.c(working copy)
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+
+void
+h1 (int *fh, int pw)
+{
+  *fh = 0;
+  if (*fh != 0)
+for (;;)
+  {
+   fh = &pw;
+
+   if (pw == 0)
+ {
+ }
+   else
+ while (pw < 1)
+   {
+ if (pw == 0)
+   {
+ut:
+ ;
+   }
+
+ ++pw;
+   }
+
+   if (pw == *fh)
+ goto ut;
+  }
+
+  goto ut;
+}
+
Index: gcc/testsuite/gcc.dg/torture/pr87342.c
===
--- gcc/testsuite/gcc.dg/torture/pr87342.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr87342.c  (working copy)
@@ -0,0 +1,44 @@
+/* { dg-do compile } */
+
+int ix;
+
+void
+o6 (int rh)
+{
+  if (rh == 0)
+{
+  ix = 0;
+  while (ix < 1)
+   {
+   }
+
+  for (;;)
+   if (ix == 0)
+ while (rh < 1)
+   {
+ if (rh == 0)
+   {
+ __builtin_unreachable ();
+
+kp:
+ if (ix == 0)
+   {
+hk:
+ ix = 0;
+   }
+   }
+
+ while (rh < 1)
+   if 

Re: [Patch, fortran] PR87239 - ICE in deferred-length string

[Janne Blomqvist]

On Tue, Sep 18, 2018 at 10:41 PM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> This is sufficiently 'obvious'  that I have committed the patch to
> trunk as revision 264409.
>
> My inclination is to commit it to 8-branch as well since deferred
> character bugs were one of the complaints in the fortran standards
> survey. OK?
>

Ok, seems obvious enough.


-- 
Janne Blomqvist

Re: [PATCH] S/390: Fix conditional returns

[Ilya Leoshkevich]

> Am 19.09.2018 um 06:15 schrieb Jeff Law :
> 
> On 9/18/18 8:04 AM, Segher Boessenkool wrote:
>> On Wed, Sep 05, 2018 at 10:34:48AM +0200, Ilya Leoshkevich wrote:
>>> S/390 epilogue ends with (parallel [(return) (use %r14)]) instead of
>>> the more usual (return) or (simple_return).  This sequence is not
>>> recognized by the conditional return logic in try_optimize_cfg ().
>> 
>> Why does it need this?  Other targets with a link register make
>> EPILOGUE_USES handle this.
> I think because he's trying to optimize a conditional jump to a return
> insn into a conditional return insn.  I don't think we do that on other
> targets, though I have pondered it from time to time.
S/390 back-end already uses EPILOGUE_USES.  The reason RETURN in
PARALLEL still exists is that on older processors sequences using
non-standard dynamically chosen link register are sometimes more
efficient, and for such use cases EPILOGUE_USES doesn't work.

I talked to Ulrich Weigand about this yesterday, and he suggested to
drop RETURN in PARALLEL for newer processors.  I will give this a try,
and if it works, middle-end changes in this patch will no longer be
needed.

Re: [PATCH] PR libstdc++/87135 Rehash only when necessary (LWG2156)

[Jonathan Wakely]

On 18/09/18 22:39 +0200, François Dumont wrote:

On 09/18/2018 10:41 AM, Jonathan Wakely wrote:

On 13/09/18 07:49 +0200, François Dumont wrote:

All changes limited to hashtable_c++0x.cc file.

_Prime_rehash_policy::_M_next_bkt now really does what its comment 
was declaring that is to say:

  // Return a prime no smaller than n.

_Prime_rehash_policy::_M_need_rehash rehash only when _M_next_size 
is exceeded, not only when it is reach.


    PR libstdc++/87135
    * src/c++11/hashtable_c++0x.cc:
    (_Prime_rehash_policy::_M_next_bkt): Return a prime no smaller than
    requested size, but not necessarily greater.
    (_Prime_rehash_policy::_M_need_rehash): Rehash only if target 
size is

    strictly greater than next resize threshold.
    * testsuite/23_containers/unordered_map/modifiers/reserve.cc: 
Adapt test
    to validate that there is no rehash as long as number of 
insertion is

    lower or equal to the reserved number of elements.

unordered_map tests successful, ok to commit once all other tests 
completed ?


François


diff --git a/libstdc++-v3/src/c++11/hashtable_c++0x.cc 
b/libstdc++-v3/src/c++11/hashtable_c++0x.cc

index a776a8506fe..ec6031b3f5b 100644
--- a/libstdc++-v3/src/c++11/hashtable_c++0x.cc
+++ b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
@@ -46,10 +46,10 @@ namespace __detail
  {
    // Optimize lookups involving the first elements of __prime_list.
    // (useful to speed-up, eg, constructors)
-    static const unsigned char __fast_bkt[13]
-  = { 2, 2, 3, 5, 5, 7, 7, 11, 11, 11, 11, 13, 13 };
+    static const unsigned char __fast_bkt[]
+  = { 2, 2, 2, 3, 5, 5, 7, 7, 11, 11, 11, 11, 13, 13 };

-    if (__n <= 12)
+    if (__n < sizeof(__fast_bkt) / sizeof(unsigned char))


sizeof(unsigned char) is defined to be 1, always.


I also though it was overkill but there are so many platforms that I 
prefer to be caution. Good to know that it can't be otherwise.




I think this should be just sizeof(__fast_bkt), or if you're trying to
guard against the type of __fast_bkt changing, then use
sizeof(__fast_bkt) / sizeof(__fast_bkt[0]))


I committed with simply sizeof(__fast_bkt)


Thanks.

Re: Transform assertion into optimization hints

[Jonathan Wakely]

On 17/09/18 23:15 +0200, Marc Glisse wrote:

On Mon, 17 Sep 2018, François Dumont wrote:


We talk about it a while back.

I've run testsuite several times since I have this patch on my local 
copy. Note that when I implemented it the wrong way tests started to 
fail so it is clearly having an effect on the generated code.


* include/bits/c++config [__OPTIMIZE__](__glibcxx_assert): Define as 
optimization hint


using __builtin_unreachable.

Ok to commit ?


I see for instance in bits/regex_automaton.tcc:

 __glibcxx_assert(__m.count(__ref._M_next) > 0);

where __m is a map, which does not look so well suited for a 
__builtin_unreachable. Is it using the wrong macro?


Yes, that looks like it's checking the implementation, but we should
only add assertions to check what users do (we just need to get our
own implementation right).

PR 85184 points out some similar assertions.

Re: [GCC][PATCH v2][Aarch64] Exploiting BFXIL when OR-ing two AND-operations with appropriate bitmasks

[Kyrill Tkachov]

Hi Christophe,

On 18/09/18 23:00, Christophe Lyon wrote:

On Thu, 13 Sep 2018 at 11:49, Kyrill Tkachov
 wrote:


On 13/09/18 10:25, Sam Tebbs wrote:

On 09/11/2018 04:20 PM, James Greenhalgh wrote:

On Tue, Sep 04, 2018 at 10:13:43AM -0500, Sam Tebbs wrote:

Hi James,

Thanks for the feedback. Here is an update with the changes you proposed
and an updated changelog.

gcc/
2018-09-04  Sam Tebbs  

   PR target/85628
   * config/aarch64/aarch64.md (*aarch64_bfxil):
   Define.
   * config/aarch64/constraints.md (Ulc): Define
   * config/aarch64/aarch64-protos.h (aarch64_high_bits_all_ones_p):
   Define.
   * config/aarch64/aarch64.c (aarch64_high_bits_all_ones_p): New 
function.

gcc/testsuite
2018-09-04  Sam Tebbs  

   PR target/85628
   * gcc.target/aarch64/combine_bfxil.c: New file.
   * gcc.target/aarch64/combine_bfxil_2.c: New file.






+/* Return true if I's bits are consecutive ones from the MSB.  */
+bool
+aarch64_high_bits_all_ones_p (HOST_WIDE_INT i)
+{
+  return exact_log2(-i) != HOST_WIDE_INT_M1;
+}

You need a space in here between the function name and the bracket:

exact_log2 (-i)



+extern void abort(void);

The same comment applies multiple places in this file.

Likewise; if (

Otherwise, OK, please apply with those fixes.

Thanks,
James

Thanks for noticing that, here's the fixed version.


Thanks Sam, I've committed the patch on your behalf with r264264.
If you want to get write-after-approval access to the SVN repo to commit 
patches yourself in the future
please fill out the form at https://sourceware.org/cgi-bin/pdw/ps_form.cgi 
putting my address from the MAINTAINERS file as the approver.


Hi,

You've probably already noticed by now since you fixed the
combine_bfi_1 issue introduced by this commit, but it add another
regression:
FAIL: gcc.target/aarch64/copysign-bsl.c scan-assembler b(sl|it|if)\tv[0-9]


Yeah, that one is a bit more involved as it's an unexpected interaction with 
the copysign BSL pattern.
Would you be able to file a bugzilla issue to track it?

Thanks,
Kyrill


Christophe


Kyrill


Sam

Re: Transform assertion into optimization hints

[Jonathan Wakely]

On 19/09/18 10:16 +0100, Jonathan Wakely wrote:

On 17/09/18 23:15 +0200, Marc Glisse wrote:

On Mon, 17 Sep 2018, François Dumont wrote:


We talk about it a while back.

I've run testsuite several times since I have this patch on my 
local copy. Note that when I implemented it the wrong way tests 
started to fail so it is clearly having an effect on the generated 
code.


* include/bits/c++config [__OPTIMIZE__](__glibcxx_assert): Define 
as optimization hint


using __builtin_unreachable.

Ok to commit ?


I see for instance in bits/regex_automaton.tcc:

__glibcxx_assert(__m.count(__ref._M_next) > 0);

where __m is a map, which does not look so well suited for a 
__builtin_unreachable. Is it using the wrong macro?


Yes, that looks like it's checking the implementation, but we should
only add assertions to check what users do (we just need to get our
own implementation right).


I'll test this patch.


diff --git a/libstdc++-v3/include/bits/regex_automaton.tcc b/libstdc++-v3/include/bits/regex_automaton.tcc
index 7a0e6a36a7a..5993fcfeeaf 100644
--- a/libstdc++-v3/include/bits/regex_automaton.tcc
+++ b/libstdc++-v3/include/bits/regex_automaton.tcc
@@ -220,16 +220,9 @@ namespace __detail
 	  auto __v = __it.second;
 	  auto& __ref = _M_nfa[__v];
 	  if (__ref._M_next != _S_invalid_state_id)
-	{
-	  __glibcxx_assert(__m.count(__ref._M_next) > 0);
-	  __ref._M_next = __m[__ref._M_next];
-	}
-	  if (__ref._M_has_alt())
-	if (__ref._M_alt != _S_invalid_state_id)
-	  {
-		__glibcxx_assert(__m.count(__ref._M_alt) > 0);
-		__ref._M_alt = __m[__ref._M_alt];
-	  }
+	__ref._M_next = __m.find(__ref._M_next)->second;
+	  if (__ref._M_has_alt() && __ref._M_alt != _S_invalid_state_id)
+	__ref._M_alt = __m.find(__ref._M_alt)->second;
 	}
   return _StateSeq(_M_nfa, __m[_M_start], __m[_M_end]);
 }

[PATCH v4] [aarch64] Add HiSilicon tsv110 CPU support

[Shaokun Zhang]

This patch adds HiSilicon's an mcpu: tsv110, which supports v8_4A.
It has been tested on aarch64 and no regressions from this patch.

---
 gcc/ChangeLog|   9 +++
 gcc/config/aarch64/aarch64-cores.def |   3 +
 gcc/config/aarch64/aarch64-cost-tables.h | 104 +++
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  82 
 gcc/doc/invoke.texi  |   2 +-
 6 files changed, 200 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 69e2e14..a040daa 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2018-09-19  Shaokun Zhang  
+Bo Zhou  
+
+   * config/aarch64/aarch64-cores.def (tsv110): New CPU.
+   * config/aarch64/aarch64-tune.md: Regenerated.
+   * doc/invoke.texi (AArch64 Options/-mtune): Add "tsv110".
+   * config/aarch64/aarch64.c (tsv110_tunings): New tuning table.
+   * config/aarch64/aarch64-cost-tables.h: Add "tsv110" extra costs.
+
 2018-09-18  Marek Polacek  
 
P1064R0 - Allowing Virtual Function Calls in Constant Expressions
diff --git a/gcc/config/aarch64/aarch64-cores.def 
b/gcc/config/aarch64/aarch64-cores.def
index 437ed1e..b1278fc 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -92,6 +92,9 @@ AARCH64_CORE("cortex-a76",  cortexa76, cortexa57, 8_2A,  
AARCH64_FL_FOR_ARCH8_2
 
 /* ARMv8.4-A Architecture Processors.  */
 
+/* HiSilicon ('H') cores. */
+AARCH64_CORE("tsv110", tsv110,cortexa57,8_4A, 
AARCH64_FL_FOR_ARCH8_4 | AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | 
AARCH64_FL_SHA2, tsv110,   0x48, 0xd01, -1)
+
 /* Qualcomm ('Q') cores. */
 AARCH64_CORE("saphira", saphira,falkor,8_4A,  
AARCH64_FL_FOR_ARCH8_4 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC, saphira,   0x51, 
0xC01, -1)
 
diff --git a/gcc/config/aarch64/aarch64-cost-tables.h 
b/gcc/config/aarch64/aarch64-cost-tables.h
index a455c62..b138aa3 100644
--- a/gcc/config/aarch64/aarch64-cost-tables.h
+++ b/gcc/config/aarch64/aarch64-cost-tables.h
@@ -334,4 +334,108 @@ const struct cpu_cost_table thunderx2t99_extra_costs =
   }
 };
 
+const struct cpu_cost_table tsv110_extra_costs =
+{
+  /* ALU */
+  {
+0, /* arith.  */
+0, /* logical.  */
+0, /* shift.  */
+0, /* shift_reg.  */
+COSTS_N_INSNS (1), /* arith_shift.  */
+COSTS_N_INSNS (1), /* arith_shift_reg.  */
+COSTS_N_INSNS (1), /* log_shift.  */
+COSTS_N_INSNS (1), /* log_shift_reg.  */
+0, /* extend.  */
+COSTS_N_INSNS (1), /* extend_arith.  */
+0, /* bfi.  */
+0, /* bfx.  */
+0, /* clz.  */
+0, /* rev.  */
+0, /* non_exec.  */
+true   /* non_exec_costs_exec.  */
+  },
+
+  {
+/* MULT SImode */
+{
+  COSTS_N_INSNS (2),   /* simple.  */
+  COSTS_N_INSNS (2),   /* flag_setting.  */
+  COSTS_N_INSNS (2),   /* extend.  */
+  COSTS_N_INSNS (2),   /* add.  */
+  COSTS_N_INSNS (2),   /* extend_add.  */
+  COSTS_N_INSNS (11)   /* idiv.  */
+},
+/* MULT DImode */
+{
+  COSTS_N_INSNS (3),   /* simple.  */
+  0,   /* flag_setting (N/A).  */
+  COSTS_N_INSNS (3),   /* extend.  */
+  COSTS_N_INSNS (3),   /* add.  */
+  COSTS_N_INSNS (3),   /* extend_add.  */
+  COSTS_N_INSNS (19)   /* idiv.  */
+}
+  },
+  /* LD/ST */
+  {
+COSTS_N_INSNS (3), /* load.  */
+COSTS_N_INSNS (4), /* load_sign_extend.  */
+COSTS_N_INSNS (3), /* ldrd.  */
+COSTS_N_INSNS (3), /* ldm_1st.  */
+1, /* ldm_regs_per_insn_1st.  */
+2, /* ldm_regs_per_insn_subsequent.  */
+COSTS_N_INSNS (4), /* loadf.  */
+COSTS_N_INSNS (4), /* loadd.  */
+COSTS_N_INSNS (4), /* load_unaligned.  */
+0, /* store.  */
+0, /* strd.  */
+0, /* stm_1st.  */
+1, /* stm_regs_per_insn_1st.  */
+2, /* stm_regs_per_insn_subsequent.  */
+0, /* storef.  */
+0, /* stored.  */
+COSTS_N_INSNS (1), /* store_unaligned.  */
+COSTS_N_INSNS (4), /* loadv.  */
+COSTS_N_INSNS (4)  /* storev.  */
+  },
+  {
+/* FP SFmode */
+{
+  COSTS_N_INSNS (10),  /* div.  */
+  COSTS_N_INSNS (4),   /* mult.  */
+  COSTS_N_INSNS (4),   /* mult_addsub.  */
+  COSTS_N_INSNS (4),   /* fma.  */
+  COSTS_N_INSNS (4),   /* addsub.  */
+  COSTS_N_INSNS (1),   /* fpconst.  */
+  COSTS_N_INSNS (1),   /* neg.  */

[PATCH] dumpfile.c: fix stray dump_loc output (PR tree-optimization/87309)

[David Malcolm]

In r262891 I reimplemented this call:
  dump_printf_loc (MSG_NOTE, loc, "=== %s ===\n", name);
in dump_begin_scope to use direct calls to dump_loc:
  if (dump_file)
{
  dump_loc (MSG_NOTE, dump_file, loc.get_location_t ());
  fprintf (dump_file, "=== %s ===\n", name);
}

  if (alt_dump_file)
   {
 dump_loc (MSG_NOTE, alt_dump_file, loc.get_location_t ());
 fprintf (alt_dump_file, "=== %s ===\n", name);
   }

However ::dump_loc doesn't filter with pflags and alt_flags.

This caused stray output of the form:
  test.cpp:1:6: note: test.cpp:1:11: note:
when using -fopt-info with "optimized" or "missed".

This patch adds this missing filtering, eliminating the stray partial
note output.

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

OK for trunk?

gcc/ChangeLog:
PR tree-optimization/87309
* dumpfile.c (dump_context::begin_scope): Filter the dump_loc
calls with pflags and alt_flags.

gcc/testsuite/ChangeLog:
PR tree-optimization/87309
* gcc.dg/pr87309.c: New test.
---
 gcc/dumpfile.c | 4 ++--
 gcc/testsuite/gcc.dg/pr87309.c | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr87309.c

diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index a81ab3e..7333ee3 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -1048,10 +1048,10 @@ dump_context::get_scope_depth () const
 void
 dump_context::begin_scope (const char *name, const dump_location_t &loc)
 {
-  if (dump_file)
+  if (dump_file && (MSG_NOTE & pflags))
 ::dump_loc (MSG_NOTE, dump_file, loc.get_location_t ());
 
-  if (alt_dump_file)
+  if (alt_dump_file && (MSG_NOTE & alt_flags))
 ::dump_loc (MSG_NOTE, alt_dump_file, loc.get_location_t ());
 
   /* Support for temp_dump_context in selftests.  */
diff --git a/gcc/testsuite/gcc.dg/pr87309.c b/gcc/testsuite/gcc.dg/pr87309.c
new file mode 100644
index 000..8bd5a44
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr87309.c
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options "-fopt-info-vec-optimized -O3" } */
+
+void a() {} /* { dg-bogus "note" } */
-- 
1.8.5.3

Re: [PATCH] PR libstdc++/87135 Rehash only when necessary (LWG2156)

[Jonathan Wakely]

On 18/09/18 22:39 +0200, François Dumont wrote:

On 09/18/2018 10:41 AM, Jonathan Wakely wrote:

On 13/09/18 07:49 +0200, François Dumont wrote:

All changes limited to hashtable_c++0x.cc file.

_Prime_rehash_policy::_M_next_bkt now really does what its comment 
was declaring that is to say:

  // Return a prime no smaller than n.

_Prime_rehash_policy::_M_need_rehash rehash only when _M_next_size 
is exceeded, not only when it is reach.


    PR libstdc++/87135
    * src/c++11/hashtable_c++0x.cc:
    (_Prime_rehash_policy::_M_next_bkt): Return a prime no smaller than
    requested size, but not necessarily greater.
    (_Prime_rehash_policy::_M_need_rehash): Rehash only if target 
size is

    strictly greater than next resize threshold.
    * testsuite/23_containers/unordered_map/modifiers/reserve.cc: 
Adapt test
    to validate that there is no rehash as long as number of 
insertion is

    lower or equal to the reserved number of elements.

unordered_map tests successful, ok to commit once all other tests 
completed ?


François


diff --git a/libstdc++-v3/src/c++11/hashtable_c++0x.cc 
b/libstdc++-v3/src/c++11/hashtable_c++0x.cc

index a776a8506fe..ec6031b3f5b 100644
--- a/libstdc++-v3/src/c++11/hashtable_c++0x.cc
+++ b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
@@ -46,10 +46,10 @@ namespace __detail
  {
    // Optimize lookups involving the first elements of __prime_list.
    // (useful to speed-up, eg, constructors)
-    static const unsigned char __fast_bkt[13]
-  = { 2, 2, 3, 5, 5, 7, 7, 11, 11, 11, 11, 13, 13 };
+    static const unsigned char __fast_bkt[]
+  = { 2, 2, 2, 3, 5, 5, 7, 7, 11, 11, 11, 11, 13, 13 };

-    if (__n <= 12)
+    if (__n < sizeof(__fast_bkt) / sizeof(unsigned char))


sizeof(unsigned char) is defined to be 1, always.


I also though it was overkill but there are so many platforms that I 
prefer to be caution. Good to know that it can't be otherwise.




I think this should be just sizeof(__fast_bkt), or if you're trying to
guard against the type of __fast_bkt changing, then use
sizeof(__fast_bkt) / sizeof(__fast_bkt[0]))


I committed with simply sizeof(__fast_bkt)



This caused some testsuite regressions:

FAIL: 23_containers/unordered_set/hash_policy/71181.cc execution test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc:42:
 void test(int) [with _USet = std::unordered_set]: Assertion 
'us.bucket_count() == bkts' failed.

FAIL: 23_containers/unordered_set/hash_policy/load_factor.cc execution test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/load_factor.cc:50:
 void test() [with _USet = std::unordered_set]: Assertion 'us.load_factor() 
<= us.max_load_factor()' failed.

FAIL: 23_containers/unordered_set/hash_policy/prime_rehash.cc execution test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc:37:
 void test01(): Assertion 'nxt == policy._M_next_bkt(mx)' failed.

Re: Transform assertion into optimization hints

[Jonathan Wakely]

On 19/09/18 10:42 +0100, Jonathan Wakely wrote:

On 19/09/18 10:16 +0100, Jonathan Wakely wrote:

On 17/09/18 23:15 +0200, Marc Glisse wrote:

On Mon, 17 Sep 2018, François Dumont wrote:


We talk about it a while back.

I've run testsuite several times since I have this patch on my 
local copy. Note that when I implemented it the wrong way tests 
started to fail so it is clearly having an effect on the 
generated code.


* include/bits/c++config [__OPTIMIZE__](__glibcxx_assert): 
Define as optimization hint


using __builtin_unreachable.

Ok to commit ?


I see for instance in bits/regex_automaton.tcc:

   __glibcxx_assert(__m.count(__ref._M_next) > 0);

where __m is a map, which does not look so well suited for a 
__builtin_unreachable. Is it using the wrong macro?


Yes, that looks like it's checking the implementation, but we should
only add assertions to check what users do (we just need to get our
own implementation right).


I'll test this patch.


Committed to trunk.

  * include/bits/regex_automaton.tcc (_StateSeq<_TraitsT>::_M_clone()):
  Remove __glibcxx_assert statements and use map::find instead of
  map::operator[].



diff --git a/libstdc++-v3/include/bits/regex_automaton.tcc 
b/libstdc++-v3/include/bits/regex_automaton.tcc
index 7a0e6a36a7a..5993fcfeeaf 100644
--- a/libstdc++-v3/include/bits/regex_automaton.tcc
+++ b/libstdc++-v3/include/bits/regex_automaton.tcc
@@ -220,16 +220,9 @@ namespace __detail
  auto __v = __it.second;
  auto& __ref = _M_nfa[__v];
  if (__ref._M_next != _S_invalid_state_id)
-   {
- __glibcxx_assert(__m.count(__ref._M_next) > 0);
- __ref._M_next = __m[__ref._M_next];
-   }
- if (__ref._M_has_alt())
-   if (__ref._M_alt != _S_invalid_state_id)
- {
-   __glibcxx_assert(__m.count(__ref._M_alt) > 0);
-   __ref._M_alt = __m[__ref._M_alt];
- }
+   __ref._M_next = __m.find(__ref._M_next)->second;
+ if (__ref._M_has_alt() && __ref._M_alt != _S_invalid_state_id)
+   __ref._M_alt = __m.find(__ref._M_alt)->second;
}
  return _StateSeq(_M_nfa, __m[_M_start], __m[_M_end]);
}

Re: [PATCH] S/390: Fix conditional returns

[Segher Boessenkool]

On Tue, Sep 18, 2018 at 10:15:00PM -0600, Jeff Law wrote:
> On 9/18/18 8:04 AM, Segher Boessenkool wrote:
> > On Wed, Sep 05, 2018 at 10:34:48AM +0200, Ilya Leoshkevich wrote:
> >> S/390 epilogue ends with (parallel [(return) (use %r14)]) instead of
> >> the more usual (return) or (simple_return).  This sequence is not
> >> recognized by the conditional return logic in try_optimize_cfg ().
> > 
> > Why does it need this?  Other targets with a link register make
> > EPILOGUE_USES handle this.
> I think because he's trying to optimize a conditional jump to a return
> insn into a conditional return insn.  I don't think we do that on other
> targets, though I have pondered it from time to time.

See r248351, r236106, and importantly r235904.  I wrote that because it
is quite useful on Power.

s390 already _has_ a proper EPILOGUE_USES btw.  So just the return
patterns themselves need fixing and all will be good, it seems.


Segher

[PATCH][RFC] Fix PR63155 (some more)

[Richard Biener]

The second testcase in the above PR runs into our O(N) bitmap element
search limitation and spends 8s (60%) of the compile-time in the SSA propagator
engine (when optimizing).  The patch improves that to 0.9s (15%).  For the 
first testcase it isn't that bad but still the patch improves CCP from 36% to 
14%.

The "solution" is to use sbitmap instead of a bitmap to avoid
the linearity when doing add_ssa_edge.  We pay for that (but not
actually with the testcases) with a linear-time bitmap_first_set_bit
in process_ssa_edge_worklist.  I do not (yet...) have a testcase
that overall gets slower with this approach.  I suppose using
std::set would "solve" the complexity issue but we'd pay
back with horribly inefficient memory use.  Similarly with
our sparse bitmap implementation which lacks an ordered
first_set_bit (it only can get any set bit fast, breaking optimal
iteration order).

If we'd only had a O(log n) search sparse bitmap implementation ...
(Steven posted patches to switch bitmap from/to such one but IIRC
that at least lacked bitmap_first_set_bit).

Bootstrapped and tested on x86_64-unknown-linux-gnu.

OK for trunk?

Thanks,
Richard.

2018-09-19  Richard Biener  

PR tree-optimization/63155
* tree-ssa-propagate.h
(ssa_propagation_engine::process_ssa_edge_worklist): Change
prototype.
* tree-ssa-propagate.c (ssa_edge_worklist): Turn into an sbitmap.
(add_ssa_edge): Adjust.
(ssa_propagation_engine::process_ssa_edge_worklist): If there
was nothing to do return false.
(ssa_prop_init): Allocate and clear ssa_edge_worklist.
(ssa_prop_fini): Adjust.
(ssa_propagation_engine::ssa_propagate): Elide the check
for an empty ssa_edge_worklist by using the
process_ssa_edge_worklist return value.

Index: gcc/tree-ssa-propagate.h
===
--- gcc/tree-ssa-propagate.h(revision 264418)
+++ gcc/tree-ssa-propagate.h(working copy)
@@ -94,7 +94,7 @@ class ssa_propagation_engine
  private:
   /* Internal implementation details.  */
   void simulate_stmt (gimple *stmt);
-  void process_ssa_edge_worklist (void);
+  bool process_ssa_edge_worklist (void);
   void simulate_block (basic_block);
 
 };
Index: gcc/tree-ssa-propagate.c
===
--- gcc/tree-ssa-propagate.c(revision 264418)
+++ gcc/tree-ssa-propagate.c(working copy)
@@ -119,7 +119,7 @@ static int *cfg_order_to_bb;
definition has changed.  SSA edges are def-use edges in the SSA
web.  For each D-U edge, we store the target statement or PHI node
UID in a bitmap.  UIDs order stmts in execution order.   */
-static bitmap ssa_edge_worklist;
+static sbitmap ssa_edge_worklist;
 static vec uid_to_stmt;
 
 /* Return true if the block worklist empty.  */
@@ -175,8 +175,9 @@ add_ssa_edge (tree var)
continue;
 
   if (prop_simulate_again_p (use_stmt)
- && bitmap_set_bit (ssa_edge_worklist, gimple_uid (use_stmt)))
+ && !bitmap_bit_p (ssa_edge_worklist, gimple_uid (use_stmt)))
{
+ bitmap_set_bit (ssa_edge_worklist, gimple_uid (use_stmt));
  uid_to_stmt[gimple_uid (use_stmt)] = use_stmt;
  if (dump_file && (dump_flags & TDF_DETAILS))
{
@@ -317,11 +318,14 @@ ssa_propagation_engine::simulate_stmt (g
when an SSA edge is added to it in simulate_stmt.  Return true if a stmt
was simulated.  */
 
-void
+bool
 ssa_propagation_engine::process_ssa_edge_worklist (void)
 {
   /* Process the next entry from the worklist.  */
-  unsigned stmt_uid = bitmap_first_set_bit (ssa_edge_worklist);
+  int stmt_uid = bitmap_first_set_bit (ssa_edge_worklist);
+  if (stmt_uid == -1)
+return false;
+
   bitmap_clear_bit (ssa_edge_worklist, stmt_uid);
   gimple *stmt = uid_to_stmt[stmt_uid];
 
@@ -335,6 +339,7 @@ ssa_propagation_engine::process_ssa_edge
 }
 
   simulate_stmt (stmt);
+  return true;
 }
 
 
@@ -412,9 +417,6 @@ ssa_prop_init (void)
   edge_iterator ei;
   basic_block bb;
 
-  /* Worklists of SSA edges.  */
-  ssa_edge_worklist = BITMAP_ALLOC (NULL);
-
   /* Worklist of basic-blocks.  */
   bb_to_cfg_order = XNEWVEC (int, last_basic_block_for_fn (cfun) + 1);
   cfg_order_to_bb = XNEWVEC (int, n_basic_blocks_for_fn (cfun));
@@ -455,6 +457,10 @@ ssa_prop_init (void)
 }
   uid_to_stmt.safe_grow (gimple_stmt_max_uid (cfun));
 
+  /* Worklists of SSA edges.  */
+  ssa_edge_worklist = sbitmap_alloc (gimple_stmt_max_uid (cfun));
+  bitmap_clear (ssa_edge_worklist);
+
   /* Seed the algorithm by adding the successors of the entry block to the
  edge worklist.  */
   FOR_EACH_EDGE (e, ei, ENTRY_BLOCK_PTR_FOR_FN (cfun)->succs)
@@ -473,7 +479,8 @@ ssa_prop_fini (void)
   BITMAP_FREE (cfg_blocks);
   free (bb_to_cfg_order);
   free (cfg_order_to_bb);
-  BITMAP_FREE (ssa_edge_worklist);
+  sbitmap_free (ssa_edge_worklist);
+  ssa_edge_worklist = NULL;
   uid_to_stmt.releas

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

[Andreas Schwab]

I'm getting this ICE on ia64:

libtool: compile:  /usr/local/gcc/gcc-20180919/Build/./gcc/xgcc -shared-libgcc 
-B/usr/local/gcc/gcc-20180919/Build/./gcc -nostdinc++ 
-L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/src 
-L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/src/.libs 
-L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/libsupc++/.libs
 -B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem 
/usr/ia64-suse-linux/include -isystem /usr/ia64-suse-linux/sys-include 
-fno-checking -I/usr/local/gcc/gcc-20180919/libstdc++-v3/../libgcc 
-I/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux
 -I/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/include 
-I/usr/local/gcc/gcc-20180919/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED 
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections 
-frandom-seed=bad_typeid.lo -O2 -g -D_GNU_SOURCE -c 
../../../../libstdc++-v3/libsupc++/bad_typeid.cc  -fPIC -DPIC -D_GLIBCXX_SHARED 
-o bad_typeid.o
../../../../libstdc++-v3/libsupc++/bad_typeid.cc:36:1: internal compiler error: 
in output_constructor_regular_field, at varasm.c:5165
36 | } // namespace std
   | ^
0x4176abaf output_constructor_regular_field
../../gcc/varasm.c:5165
0x4176d09f output_constructor
../../gcc/varasm.c:5475
0x4176940f output_constant
../../gcc/varasm.c:4967
0x4175414f assemble_variable_contents
../../gcc/varasm.c:2143
0x4175586f assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2319
0x417a564f varpool_node::assemble_decl()
../../gcc/varpool.c:586
0x417a74cf symbol_table::output_variables()
../../gcc/varpool.c:752
0x407b806f symbol_table::compile()
../../gcc/cgraphunit.c:2611
0x407bd8ef symbol_table::compile()
../../gcc/cgraphunit.c:2791
0x407bd8ef symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2788

(gdb) up
#1  0x4176abb0 in output_constructor_regular_field (
local=0x600ee920) at ../../gcc/varasm.c:5165
5165gcc_assert (fieldpos == local->total_bytes);
(gdb) p fieldpos
$1 = 16
(gdb) p local->total_bytes
$2 = 24

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH][RFC] Fix PR63155 (some more)

[Jakub Jelinek]

On Wed, Sep 19, 2018 at 03:06:30PM +0200, Richard Biener wrote:
> 
> The second testcase in the above PR runs into our O(N) bitmap element
> search limitation and spends 8s (60%) of the compile-time in the SSA 
> propagator
> engine (when optimizing).  The patch improves that to 0.9s (15%).  For the 
> first testcase it isn't that bad but still the patch improves CCP from 36% to 
> 14%.
> 
> The "solution" is to use sbitmap instead of a bitmap to avoid
> the linearity when doing add_ssa_edge.  We pay for that (but not
> actually with the testcases) with a linear-time bitmap_first_set_bit
> in process_ssa_edge_worklist.  I do not (yet...) have a testcase

Perhaps you could remember the first set bit number in an integral variable
next to the bitmap.  On bitmap_set_bit this would be just a comparison +
conditional update, in simulate_stmt it would be again conditional on
clearing the first set bit and in that case it could start from that bit
onwards rather than from the beginning (EXECUTE_IF_SET_IN_BITMAP), similarly
in process_ssa_edge_worklist (non-conditional in that case, we are always
clearing the first bit).  Or instead of tracking exact first bit track
it lazily, i.e. just remember the smallest bitnum we've set and in
process_ssa_edge_worklist don't use bitmap_first_set_bit, but walk from
that minimum using EXECUTE_IF_SET_IN_BITMAP and update the minimum to
whatever we've found.

Similarly, empty_p can be done linearly by keeping on the side the count of
set bits and updating it on set_bit when previously not set, as well on
clear_bit.

Jakub

Re: [PATCH 13/25] Create TARGET_DISABLE_CURRENT_VECTOR_SIZE

[Richard Biener]

On Tue, Sep 18, 2018 at 10:22 PM Andrew Stubbs  wrote:
>
> On 18/09/18 12:21, Richard Sandiford wrote:
> > Would the same be useful for GCN, or do you basically always
> > want a VF of 64?
>
> Always 64; the vector size varies between 512-bit and 4096-bit, as needed.
>
> > None of this is a fundamental restriction in theory.  It's just
> > something that needs to be fixed.
> >
> > One approach would be to get the loop vectoriser to iterate over the
> > number of lanes the target supports insteaad of all possible vector
> > sizes.  The problem is that on its own this would mean trying 4
> > lane counts even on targets with a single supported vector size.
> > So we'd need to do something a bit smarter...
>
> Yeah, that sounds like an interesting project, but way more than I think
> I need. Basically, we don't need to iterate over anything; there's only
> one option for each mode.
>
> For the purposes of this patch, might it be enough to track down all the
> places that use the current_vector_size and fix them up, somehow?
>
> Obviously, I'm not sure what that means just yet ...

I think the only part that wants a "fixed" size is the code iterating over
vector sizes.  All the rest of the code simply wants to commit to
a specific vector type for each DEF - to match the ISAs we've faced
sofar the approach is simply to choose the vector type of current_vector_size
size and proper element type.

I've long wanted to fix that part in a way to actually commit to vector types
later and compute the DEF vector type of a stmt by looking at the vector
type of the USEs and the operation.

So I guess the current_vector_size thing isn't too hard to get rid of, what
you'd end up with would be using that size when you decide for vector
types for loads (where there are no USEs with vector types, so for example
this would not apply to gathers).

So I'd say you want to refactor get_same_sized_vectype uses and
make the size argument to get_vectype_for_scalar_type_and_size
a hint only.

Richard.

>
> Andrew

Re: [PATCH] dump_printf: use %T and %G throughout

[Richard Biener]

On Wed, Sep 19, 2018 at 1:18 AM David Malcolm  wrote:
>
> As promised at Cauldron, this patch uses %T and %G with dump_printf and
> dump_printf_loc calls to eliminate calls to
>
>   dump_generic_expr (MSG_*, arg, TDF_SLIM)  (via %T)
>
> and
>
>   dump_gimple_stmt (MSG_*, TDF_SLIM, stmt, 0)  (via %G)
>
> throughout the middle-end, simplifying numerous dump callsites.
>
> A few calls to these functions didn't match the above pattern; I didn't
> touch these.  I wasn't able to use %E anywhere.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> OK for trunk?

OK.

> gcc/ChangeLog:
> * tree-data-ref.c (runtime_alias_check_p): Use formatted printing
> with %T in place of calls to dump_generic_expr.
> (prune_runtime_alias_test_list): Likewise.
> (create_runtime_alias_checks): Likewise.
> * tree-vect-data-refs.c (vect_check_nonzero_value): Likewise.
> (vect_analyze_data_ref_dependence): Likewise.
> (vect_slp_analyze_data_ref_dependence): Likewise.
> (vect_record_base_alignment): Likewise.  Use %G in place of call
> to dump_gimple_stmt.
> (vect_compute_data_ref_alignment): Likewise.
> (verify_data_ref_alignment): Likewise.
> (vect_find_same_alignment_drs): Likewise.
> (vect_analyze_group_access_1): Likewise.
> (vect_analyze_data_ref_accesses): Likewise.
> (dependence_distance_ge_vf): Likewise.
> (dump_lower_bound): Likewise.
> (vect_prune_runtime_alias_test_list): Likewise.
> (vect_find_stmt_data_reference): Likewise.
> (vect_analyze_data_refs): Likewise.
> (vect_create_addr_base_for_vector_ref): Likewise.
> (vect_create_data_ref_ptr): Likewise.
> * tree-vect-loop-manip.c (vect_set_loop_condition): Likewise.
> (vect_can_advance_ivs_p): Likewise.
> (vect_update_ivs_after_vectorizer): Likewise.
> (vect_gen_prolog_loop_niters): Likewise.
> (vect_prepare_for_masked_peels): Likewise.
> * tree-vect-loop.c (vect_determine_vf_for_stmt): Likewise.
> (vect_determine_vectorization_factor): Likewise.
> (vect_is_simple_iv_evolution): Likewise.
> (vect_analyze_scalar_cycles_1): Likewise.
> (vect_analyze_loop_operations): Likewise.
> (report_vect_op): Likewise.
> (vect_is_slp_reduction): Likewise.
> (check_reduction_path): Likewise.
> (vect_is_simple_reduction): Likewise.
> (vect_create_epilog_for_reduction): Likewise.
> (vect_finalize_reduction:): Likewise.
> (vectorizable_induction): Likewise.
> (vect_transform_loop_stmt): Likewise.
> (vect_transform_loop): Likewise.
> (optimize_mask_stores): Likewise.
> * tree-vect-patterns.c (vect_pattern_detected): Likewise.
> (vect_split_statement): Likewise.
> (vect_recog_over_widening_pattern): Likewise.
> (vect_recog_average_pattern): Likewise.
> (vect_determine_min_output_precision_1): Likewise.
> (vect_determine_precisions_from_range): Likewise.
> (vect_determine_precisions_from_users): Likewise.
> (vect_mark_pattern_stmts): Likewise.
> (vect_pattern_recog_1): Likewise.
> * tree-vect-slp.c (vect_get_and_check_slp_defs): Likewise.
> (vect_record_max_nunits): Likewise.
> (vect_build_slp_tree_1): Likewise.
> (vect_build_slp_tree_2): Likewise.
> (vect_print_slp_tree): Likewise.
> (vect_analyze_slp_instance): Likewise.
> (vect_detect_hybrid_slp_stmts): Likewise.
> (vect_detect_hybrid_slp_1): Likewise.
> (vect_slp_analyze_operations): Likewise.
> (vect_slp_analyze_bb_1): Likewise.
> (vect_transform_slp_perm_load): Likewise.
> (vect_schedule_slp_instance): Likewise.
> * tree-vect-stmts.c (vect_mark_relevant): Likewise.
> (vect_mark_stmts_to_be_vectorized): Likewise.
> (vect_init_vector_1): Likewise.
> (vect_get_vec_def_for_operand): Likewise.
> (vect_finish_stmt_generation_1): Likewise.
> (vect_check_load_store_mask): Likewise.
> (vectorizable_call): Likewise.
> (vectorizable_conversion): Likewise.
> (vectorizable_operation): Likewise.
> (vectorizable_load): Likewise.
> (vect_analyze_stmt): Likewise.
> (vect_is_simple_use): Likewise.
> (vect_get_vector_types_for_stmt): Likewise.
> (vect_get_mask_type_for_stmt): Likewise.
> * tree-vectorizer.c (increase_alignment): Likewise.
> ---
>  gcc/tree-data-ref.c|  48 ++---
>  gcc/tree-vect-data-refs.c  | 481 
> +++--
>  gcc/tree-vect-loop-manip.c |  36 ++--
>  gcc/tree-vect-loop.c   | 215 ++--
>  gcc/tree-vect-patterns.c   | 106 --
>  gcc/tree-vect-slp.c| 242 ---
>  gcc/tree-vect-stmts.c  | 290 ---
>

Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

[Richard Biener]

On Tue, Sep 18, 2018 at 8:58 PM Jeff Law  wrote:
>
> On 9/18/18 11:12 AM, Martin Sebor wrote:
>
> >> My bad.  Sigh. CCP doesn't track copies, just constants, so there's not
> >> going to be any data structure you can exploit.  And I don't think
> >> there's a value number you can use to determine the two objects are the
> >> same.
> >>
> >> Hmm, let's back up a bit, what is does the relevant part of the IL look
> >> like before CCP?  Is the real problem here that we have unpropagated
> >> copies lying around in the IL?  Hmm, more likely the IL looksl ike:
> >>
> >>_8 = &pb_3(D)->a;
> >>_9 = _8;
> >>_1 = _9;
> >>strncpy (MEM_REF (&pb_3(D)->a), ...);
> >>MEM[(struct S *)_1].a[n_7] = 0;
> >
> > Yes, that is what the folder sees while the strncpy call is
> > being transformed/folded by ccp.  The MEM_REF is folded just
> > after the strncpy call and that's when it's transformed into
> >
> >   MEM[(struct S *)_8].a[n_7] = 0;
> >
> > (The assignments to _1 and _9 don't get removed until after
> > the dom walk finishes).
> >
> >>
> >> If we were to propagate the copies out we'd at best have:
> >>
> >>_8 = &pb_3(D)->a;
> >>strncpy (MEM_REF (&pb_3(D)->a), ...);
> >>MEM[(struct S *)_8].a[n_7] = 0;
> >>
> >>
> >> Is that in a form you can handle?  Or would we also need to forward
> >> propagate the address computation into the use of _8?
> >
> > The above works as long as we look at the def_stmt of _8 in
> > the MEM_REF (we currently don't).  That's also what the last
> > iteration of the loop does.  In this case (with _8) it would
> > be discovered in the first iteration, so the loop could be
> > replaced by a simple if statement.
> >
> > But I'm not sure I understand the concern with the loop.  Is
> > it that we are looping at all, i.e., the cost?  Or that ccp
> > is doing something wrong or suboptimal? (Should have
> > propagated the value of _8 earlier?)
> I suspect it's more a concern that things like copies are typically
> propagated away.   So their existence in the IL (and consequently your
> need to handle them) raises the question "has something else failed to
> do its job earlier".
>
> During which of the CCP passes is this happening?  Can we pull the
> warning out of the folder (even if that means having a distinct warning
> pass over the IL?)

Note CCP also propagates copies.

Richard.

>
> Jeff

Re: [PATCH] dumpfile.c: fix stray dump_loc output (PR tree-optimization/87309)

[Richard Biener]

On Wed, Sep 19, 2018 at 12:42 PM David Malcolm  wrote:
>
> In r262891 I reimplemented this call:
>   dump_printf_loc (MSG_NOTE, loc, "=== %s ===\n", name);
> in dump_begin_scope to use direct calls to dump_loc:
>   if (dump_file)
> {
>   dump_loc (MSG_NOTE, dump_file, loc.get_location_t ());
>   fprintf (dump_file, "=== %s ===\n", name);
> }
>
>   if (alt_dump_file)
>{
>  dump_loc (MSG_NOTE, alt_dump_file, loc.get_location_t ());
>  fprintf (alt_dump_file, "=== %s ===\n", name);
>}
>
> However ::dump_loc doesn't filter with pflags and alt_flags.
>
> This caused stray output of the form:
>   test.cpp:1:6: note: test.cpp:1:11: note:
> when using -fopt-info with "optimized" or "missed".
>
> This patch adds this missing filtering, eliminating the stray partial
> note output.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> OK for trunk?

OK

> gcc/ChangeLog:
> PR tree-optimization/87309
> * dumpfile.c (dump_context::begin_scope): Filter the dump_loc
> calls with pflags and alt_flags.
>
> gcc/testsuite/ChangeLog:
> PR tree-optimization/87309
> * gcc.dg/pr87309.c: New test.
> ---
>  gcc/dumpfile.c | 4 ++--
>  gcc/testsuite/gcc.dg/pr87309.c | 4 
>  2 files changed, 6 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/pr87309.c
>
> diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
> index a81ab3e..7333ee3 100644
> --- a/gcc/dumpfile.c
> +++ b/gcc/dumpfile.c
> @@ -1048,10 +1048,10 @@ dump_context::get_scope_depth () const
>  void
>  dump_context::begin_scope (const char *name, const dump_location_t &loc)
>  {
> -  if (dump_file)
> +  if (dump_file && (MSG_NOTE & pflags))
>  ::dump_loc (MSG_NOTE, dump_file, loc.get_location_t ());
>
> -  if (alt_dump_file)
> +  if (alt_dump_file && (MSG_NOTE & alt_flags))
>  ::dump_loc (MSG_NOTE, alt_dump_file, loc.get_location_t ());
>
>/* Support for temp_dump_context in selftests.  */
> diff --git a/gcc/testsuite/gcc.dg/pr87309.c b/gcc/testsuite/gcc.dg/pr87309.c
> new file mode 100644
> index 000..8bd5a44
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr87309.c
> @@ -0,0 +1,4 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fopt-info-vec-optimized -O3" } */
> +
> +void a() {} /* { dg-bogus "note" } */
> --
> 1.8.5.3
>

Re: [PATCH][RFC] Fix PR63155 (some more)

[Richard Biener]

On Wed, 19 Sep 2018, Jakub Jelinek wrote:

> On Wed, Sep 19, 2018 at 03:06:30PM +0200, Richard Biener wrote:
> > 
> > The second testcase in the above PR runs into our O(N) bitmap element
> > search limitation and spends 8s (60%) of the compile-time in the SSA 
> > propagator
> > engine (when optimizing).  The patch improves that to 0.9s (15%).  For the 
> > first testcase it isn't that bad but still the patch improves CCP from 36% 
> > to 
> > 14%.
> > 
> > The "solution" is to use sbitmap instead of a bitmap to avoid
> > the linearity when doing add_ssa_edge.  We pay for that (but not
> > actually with the testcases) with a linear-time bitmap_first_set_bit
> > in process_ssa_edge_worklist.  I do not (yet...) have a testcase
> 
> Perhaps you could remember the first set bit number in an integral variable
> next to the bitmap.  On bitmap_set_bit this would be just a comparison +
> conditional update, in simulate_stmt it would be again conditional on
> clearing the first set bit and in that case it could start from that bit
> onwards rather than from the beginning (EXECUTE_IF_SET_IN_BITMAP), similarly
> in process_ssa_edge_worklist (non-conditional in that case, we are always
> clearing the first bit).  Or instead of tracking exact first bit track
> it lazily, i.e. just remember the smallest bitnum we've set and in
> process_ssa_edge_worklist don't use bitmap_first_set_bit, but walk from
> that minimum using EXECUTE_IF_SET_IN_BITMAP and update the minimum to
> whatever we've found.

I thought about that but as you say it's easily invalidated and we can
only optimize the searching start point.  So it felt somewhat like
a hack ;)

I can still do that if you think that otherwise using an sbitmap
is fine (I'm not 100% convinced about that yet).

> Similarly, empty_p can be done linearly by keeping on the side the count of
> set bits and updating it on set_bit when previously not set, as well on
> clear_bit.

I elided empty_p by re-using the fact that bitmap_first_set_bit
already has to do the walk (and may fail).  Of course using a 
on-the-side count might be more optimal (I was wondering why
sbitmap itself didn't have that).

I wonder if reviving Stevens [patch][RFC] bitmaps as lists *or* trees
makes more sense so we can turn this kind of random-access bitmaps
to tree view.

Richard.

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

[Marek Polacek]

On Wed, Sep 19, 2018 at 03:25:02PM +0200, Andreas Schwab wrote:
> I'm getting this ICE on ia64:
> 
> libtool: compile:  /usr/local/gcc/gcc-20180919/Build/./gcc/xgcc 
> -shared-libgcc -B/usr/local/gcc/gcc-20180919/Build/./gcc -nostdinc++ 
> -L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/src 
> -L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/src/.libs 
> -L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/libsupc++/.libs
>  -B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem 
> /usr/ia64-suse-linux/include -isystem /usr/ia64-suse-linux/sys-include 
> -fno-checking -I/usr/local/gcc/gcc-20180919/libstdc++-v3/../libgcc 
> -I/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux
>  -I/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/include 
> -I/usr/local/gcc/gcc-20180919/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED 
> -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 
> -fdiagnostics-show-location=once -ffunction-sections -fdata-sections 
> -frandom-seed=bad_typeid.lo -O2 -g -D_GNU_SOURCE -c 
> ../../../../libstdc++-v3/libsupc++/bad_typeid.cc  -fPIC -DPIC 
> -D_GLIBCXX_SHARED -o bad_typeid.o
> ../../../../libstdc++-v3/libsupc++/bad_typeid.cc:36:1: internal compiler 
> error: in output_constructor_regular_field, at varasm.c:5165
> 36 | } // namespace std
>| ^
> 0x4176abaf output_constructor_regular_field
> ../../gcc/varasm.c:5165
> 0x4176d09f output_constructor
> ../../gcc/varasm.c:5475
> 0x4176940f output_constant
> ../../gcc/varasm.c:4967
> 0x4175414f assemble_variable_contents
> ../../gcc/varasm.c:2143
> 0x4175586f assemble_variable(tree_node*, int, int, int)
> ../../gcc/varasm.c:2319
> 0x417a564f varpool_node::assemble_decl()
> ../../gcc/varpool.c:586
> 0x417a74cf symbol_table::output_variables()
> ../../gcc/varpool.c:752
> 0x407b806f symbol_table::compile()
> ../../gcc/cgraphunit.c:2611
> 0x407bd8ef symbol_table::compile()
> ../../gcc/cgraphunit.c:2791
> 0x407bd8ef symbol_table::finalize_compilation_unit()
> ../../gcc/cgraphunit.c:2788
> 
> (gdb) up
> #1  0x4176abb0 in output_constructor_regular_field (
> local=0x600ee920) at ../../gcc/varasm.c:5165
> 5165gcc_assert (fieldpos == local->total_bytes);
> (gdb) p fieldpos
> $1 = 16
> (gdb) p local->total_bytes
> $2 = 24

That muset be because ia64 uses TARGET_VTABLE_USES_DESCRIPTORS.
Does this help?

2018-09-19  Marek Polacek  

* class.c (build_vtbl_initializer): Don't mess with *inits for
TARGET_VTABLE_USES_DESCRIPTORS.

diff --git gcc/cp/class.c gcc/cp/class.c
index 9ca46441871..0239f6ae045 100644
--- gcc/cp/class.c
+++ gcc/cp/class.c
@@ -9370,7 +9370,7 @@ build_vtbl_initializer (tree binfo,
  int i;
  if (init == size_zero_node)
for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
- CONSTRUCTOR_APPEND_ELT (*inits, idx, init);
+ CONSTRUCTOR_APPEND_ELT (*inits, NULL_TREE, init);
  else
for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
  {
@@ -9378,7 +9378,7 @@ build_vtbl_initializer (tree binfo,
 fn, build_int_cst (NULL_TREE, i));
TREE_CONSTANT (fdesc) = 1;
 
-   CONSTRUCTOR_APPEND_ELT (*inits, idx, fdesc);
+   CONSTRUCTOR_APPEND_ELT (*inits, NULL_TREE, fdesc);
  }
}
   else

Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

[Martin Sebor]

On 09/18/2018 10:23 PM, Jeff Law wrote:

On 9/18/18 1:46 PM, Martin Sebor wrote:

On 09/18/2018 12:58 PM, Jeff Law wrote:

On 9/18/18 11:12 AM, Martin Sebor wrote:


My bad.  Sigh. CCP doesn't track copies, just constants, so there's not
going to be any data structure you can exploit.  And I don't think
there's a value number you can use to determine the two objects are the
same.

Hmm, let's back up a bit, what is does the relevant part of the IL look
like before CCP?  Is the real problem here that we have unpropagated
copies lying around in the IL?  Hmm, more likely the IL looksl ike:

   _8 = &pb_3(D)->a;
   _9 = _8;
   _1 = _9;
   strncpy (MEM_REF (&pb_3(D)->a), ...);
   MEM[(struct S *)_1].a[n_7] = 0;


Yes, that is what the folder sees while the strncpy call is
being transformed/folded by ccp.  The MEM_REF is folded just
after the strncpy call and that's when it's transformed into

  MEM[(struct S *)_8].a[n_7] = 0;

(The assignments to _1 and _9 don't get removed until after
the dom walk finishes).



If we were to propagate the copies out we'd at best have:

   _8 = &pb_3(D)->a;
   strncpy (MEM_REF (&pb_3(D)->a), ...);
   MEM[(struct S *)_8].a[n_7] = 0;


Is that in a form you can handle?  Or would we also need to forward
propagate the address computation into the use of _8?


The above works as long as we look at the def_stmt of _8 in
the MEM_REF (we currently don't).  That's also what the last
iteration of the loop does.  In this case (with _8) it would
be discovered in the first iteration, so the loop could be
replaced by a simple if statement.

But I'm not sure I understand the concern with the loop.  Is
it that we are looping at all, i.e., the cost?  Or that ccp
is doing something wrong or suboptimal? (Should have
propagated the value of _8 earlier?)

I suspect it's more a concern that things like copies are typically
propagated away.   So their existence in the IL (and consequently your
need to handle them) raises the question "has something else failed to
do its job earlier".

During which of the CCP passes is this happening?  Can we pull the
warning out of the folder (even if that means having a distinct warning
pass over the IL?)


It happens during the third run of the pass.

The only way to do what you suggest that I could think of is
to defer the strncpy to memcpy transformation until after
the warning pass.  That was also my earlier suggestion: defer
both it and the warning until the tree-ssa-strlen pass (where
the warning is implemented to begin with -- the folder calls
into it).

If it's happening that late (CCP3) in general, then ISTM we ought to be
able to get the warning out of the folder.  We just have to pick the
right spot.

warn_restrict runs before fold_all_builtins, but after dom/vrp so we
should have the IL in pretty good shape.  That seems like about the
right time.

I wonder if we could generalize warn_restrict to be a more generic
warning pass over the IL and place it right before fold_builtins.


The restrict pass doesn't know about string lengths so it can't
handle all the warnings about string built-ins (the strlen pass
now calls into it to issue some).  The strlen pass does so it
could handle most if not all of them (the folder also calls
into it to issue some warnings).  It would work even better if
it were also integrated with the object size pass.

We're already working on merging strlen with sprintf.  It seems
to me that the strlen pass would benefit not only from that but
also from integrating with object size and warn-restrict.  With
that, -Wstringop-overflow could be moved from builtins.c into
it as well (and also benefit not only from accurate string
lengths but also from the more accurate object size info).

What do you think about that?

Martin

PS I don't think I could do more than merger strlen and sprintf
before stage 1 ends (if even that much) so this would be a longer
term goal.

Re: [PATCH][RFC] Fix PR63155 (some more)

[Steven Bosscher]

On Wed, Sep 19, 2018 at 3:06 PM Richard Biener wrote:
> If we'd only had a O(log n) search sparse bitmap implementation ...
> (Steven posted patches to switch bitmap from/to such one but IIRC
> that at least lacked bitmap_first_set_bit).

But bitmap_first_set_bit would be easy to implement. Just take the
left-most node of the splay tree.

Actually all bit-tests would be easy to implement. It's only
enumeration and set operations on the tree-views that would be
complicated fluff (easier to "switch views" than re-implement).

Impressive that you remember >5yr old patches like that ;-)

Ciao!
Steven

Re: [PATCH,FORTRAN 00/29] Move towards stringpool, part 1

[Bernhard Reutner-Fischer]

On Fri, 7 Sep 2018 at 10:07, Bernhard Reutner-Fischer
 wrote:
>
> On Wed, 5 Sep 2018 at 20:57, Janne Blomqvist  
> wrote:
> >
> > On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer 
> >  wrote:
>
> >> Bootstrapped and regtested on x86_64-foo-linux.
> >>
> >> I'd appreciate if someone could double check for regressions on other
> >> setups. Git branch:
> >> https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool
> >>
> >> Ok for trunk?
> >
> >
> > Hi,
> >
> > this is quite an impressive patch set. I have looked through all the 
> > patches, and on the surface they all look ok.
>
> Thanks alot for your appreciation!
> >
> > Unfortunately I don't have any exotic target to test on either, so I think 
> > you just have to commit it and check for regression reports. Though I don't 
> > see this set doing anything which would work differently on other targets, 
> > but you never know..
> >
> > I'd say wait a few days in case anybody else wants to comment on it, then 
> > commit it to trunk.
>
> Upon further testing i encountered a regression in module writing,
> manifesting itself in a failure to compile ieee_8.f90 (and only this).

> Sorry for that, I'll have another look during the weekend.

so in free_pi_tree we should not free true_name nor module:

@@ -239,12 +239,6 @@ free_pi_tree (pointer_info *p)
   free_pi_tree (p->left);
   free_pi_tree (p->right);

-  if (iomode == IO_INPUT)
-{
-  XDELETEVEC (p->u.rsym.true_name);
-  XDELETEVEC (p->u.rsym.module);
-}
-
   free (p);
 }

This fixes the module writing but leaks, obviously.
Now the reason why i initially did not use mio_pool_string for both
rsym.module and rsym.true_name was that mio_pool_string sets the name
to NULL if the string is empty.
Currently these are read by read_string() [which we should get rid of
entirely, the 2 mentioned fields are the last two who use
read_string()] which does not nullify the empty string but returns
just the pointer. For e.g. ieee_8.f90 using mio_pool_string gives us a
NULL module which leads to gfc_use_module -> load_needed ->
gfc_find_symbol -> gfc_find_sym_tree -> gfc_find_symtree which tries
to c = strcmp (name, st->name); where name is NULL.

The main culprits seem to be class finalization wrapper variables so
i'm adding modules to those now.
Which leaves me with regressions like allocate_with_source_14.f03.
"Fixing" these by falling back to gfc_current_ns->proc_name->name in
load_needed for !ns->proc_name if the rsym->module is NULL seems to
work.

Now there are a number of issues with names of fixups. Like the 9 in e.g.:

$ zcat /tmp/n/m.mod | egrep -v "^(\(\)|\(\(\)|$)"
GFORTRAN module version '15' created from generic_27.f90
(('testif' 'm' 2 3))
(4 'm' 'm' '' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0)
3 'test1' 'm' '' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL UNKNOWN 0
0 FUNCTION) () (REAL 4 0 0 0 REAL ()) 5 0 (6) () 3 () () () 0 0)
2 'test2' 'm' '' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL UNKNOWN 0
0 FUNCTION ARRAY_OUTER_DEPENDENCY) () (REAL 4 0 0 0 REAL ()) 7 0 (8) ()
2 () () () 0 0)
6 'obj' '' '' 5 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0
0 DUMMY) () (REAL 4 0 0 0 REAL ()) 0 0 () () 0 () () () 0 0)
8 'pr' '' '' 7 ((PROCEDURE UNKNOWN-INTENT DUMMY-PROC UNKNOWN UNKNOWN 0 0
EXTERNAL DUMMY FUNCTION PROCEDURE ARRAY_OUTER_DEPENDENCY) () (REAL 4 9 0
0 REAL ()) 0 0 () () 8 () () () 0 0)
9 '' '' '' 7 ((PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0
FUNCTION) () (REAL 4 0 0 0 REAL ()) 0 0 () () 0 () () () 0 0)
)
('m' 0 4 'test1' 0 3 'test2' 0 2)

which is a bit of a complication since we need them to verify proper
interface types and attributes etc, etc.
generic_27.f90 would then warn in check_proc_interface() that
"Interface %qs at %L must be explicit".
To bypass this warning i suggest to flag these as artificial like so:
@@ -6679,10 +6683,12 @@ match_procedure_decl (void)
return MATCH_ERROR;
  sym->ts.interface = gfc_new_symbol ("", gfc_current_ns);
  sym->ts.interface->ts = current_ts;
  sym->ts.interface->attr.flavor = FL_PROCEDURE;
  sym->ts.interface->attr.function = 1;
+ /* Suppress warnings about explicit interface */
+ sym->ts.interface->attr.artificial = 1;
  sym->attr.function = 1;
  sym->attr.if_source = IFSRC_UNKNOWN;
}

   if (gfc_match (" =>") == MATCH_YES)
@@ -6818,10 +6824,12 @@ match_ppc_decl (void)
  c->ts.interface = gfc_new_symbol ("", gfc_current_ns);
  c->ts.interface->result = c->ts.interface;
  c->ts.interface->ts = ts;
  c->ts.interface->attr.flavor = FL_PROCEDURE;
  c->ts.interface->attr.function = 1;
+ /* Suppress warnings about explicit interface */
+ c->ts.interface->attr.artificial = 1;
  c->attr.function = 1;
  c->attr.if_source = IFSRC_UNKNOWN;
}

   if (gfc_match (" =>") == MATCH_YES)

and then not exclude ""-names but att

[C++ Patch] PR 87324 ("g++ ICE with overriding initializers: Segmentation fault")

[Paolo Carlini]

Hi,

in this simple error-recovery issue we ICE in get_class_binding_direct 
when we try to use IDENTIFIER_CONV_OP_P on the index which we nulled in 
cp_parser_initializer_list. If, instead, we assign error_mark_node to it 
we catch it later in reshape_init_class and error-recovery goes well.


Tested x86_64-linux.

Thanks, Paolo.



/cp
2018-09-19  Paolo Carlini  

PR c++/87324
* parser.c (cp_parser_initializer_list): Assign error_mark_node
to the index upon error.

/testsuite
2018-09-19  Paolo Carlini  

PR c++/87324
* g++.dg/cpp0x/desig5.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 264419)
+++ cp/parser.c (working copy)
@@ -22394,7 +22394,7 @@ cp_parser_initializer_list (cp_parser* parser, boo
  "%<.%s%> designator used multiple times in "
  "the same initializer list",
  IDENTIFIER_POINTER (designator));
-   (*v)[i].index = NULL_TREE;
+   (*v)[i].index = error_mark_node;
  }
else
  IDENTIFIER_MARKED (designator) = 1;
Index: testsuite/g++.dg/cpp0x/desig5.C
===
--- testsuite/g++.dg/cpp0x/desig5.C (nonexistent)
+++ testsuite/g++.dg/cpp0x/desig5.C (working copy)
@@ -0,0 +1,13 @@
+// PR c++/87324
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wno-pedantic" }
+
+struct {
+  struct {
+double a;
+struct {
+  short b;
+};
+  };
+  int c;
+} d{.a = 7, .a = 8.09};  // { dg-error "designator used multiple times in the 
same initializer list" }

Re: [Patch, Fortran, OOP] PR 46313: OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

[Bernhard Reutner-Fischer]

On Mon, 17 Sep 2018 at 22:25, Janus Weil  wrote:

> The regtest was successful. I don't think the off-by-two error for the
> vtab/vtype comparisons is a big problem in practice, since the number
> of internal symbols with leading underscores is very limited, but of
> course it should still be fixed ...

Luckily it should make no difference indeed as "__vta" and "__vtyp"
are only used for this one purpose.
I don't think the DTIO op keyword fix would hit any real user either.
Thanks for taking care of it, patch LGTM.

cheers,

Re: [PATCH][Middle-end][Version 3]Add a new option to control inlining only on static functions

[Qing Zhao]

thanks, Martin.

> On Sep 18, 2018, at 5:26 PM, Martin Sebor  wrote:
>> 
>> gcc/ChangeLog
>> 
>> +2018-09-18  Qing Zhao  mailto:qing.z...@oracle.com>>
>> +
>> +* cif-code.def (FUNCTION_EXTERN): New CIFCODE.
>> +* common.opt (-finline-only-static): New option.
>> +* doc/invoke.texi: Document -finline-only-static.
>> +* ipa-inline.c (can_inline_edge_p): Control inlining based on
>> +function's visibility.
> 
> Probably "linkage" would be a more fitting term here.
Okay.

> 
>> 
>> gcc/testsuite/ChangeLog
>> 
>> +2018-09-18  Qing Zhao  mailto:qing.z...@oracle.com>>
>> +
>> +* gcc.dg/inline_only_static.c: New test.
>> +
> 
> 
> diff --git a/gcc/cif-code.def b/gcc/cif-code.def
> index 19a7621..64b2b1a 100644
> --- a/gcc/cif-code.def
> +++ b/gcc/cif-code.def
> @@ -132,6 +132,12 @@
> DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
> DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
>  N_("function attribute mismatch"))
> 
> +/* We can't inline because the user requests only inlining static function
> +   but the function is external visible.  */
> 
> I suspect you meant: "only static functions" (plural) and
> "the function has external linkage" (as defined in the C and
> C++ standards).
Okay.

> 
> +DEFCIFCODE(FUNCTION_EXTERN, CIF_FINAL_ERROR,
> +N_("function is external visible when the user requests only"
> +   " inlining static"))
> +
> 
> Here as well: either "function has external linkage" or "function
> is extern.”
Okay.
> 
> ===
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index ec12711..b6b0db5 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @ -8066,6 +8067,15 @@
> having large chains of nested wrapper functions.
> 
> Enabled by default.
> 
> +@item -finline-only-static
> +@opindex finline-only-static
> +By default, GCC inlines functions without considering whether they are static
> +or not. This flag guides inliner to only inline static functions.
> 
> Guides "the inliner" (missing article).
Okay.

> 
> +This option has any effect only when inlining itself is turned on by the
> +-finline-functions or -finline-small-fiunctions.
> 
> "by the -f... options."  (Missing "options") and
> -finline-small-functions (note the spelling of functions).

Okay.
> 
> +
> +Off by default.
> 
> I think the customary way to word it is: "Disabled by default."
> or "The finline-only-static option/flag is disabled/off by default”

Okay.

Qing
> 
> Martin

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

[Andreas Schwab]

On Sep 19 2018, Marek Polacek  wrote:

> 2018-09-19  Marek Polacek  
>
>   * class.c (build_vtbl_initializer): Don't mess with *inits for
>   TARGET_VTABLE_USES_DESCRIPTORS.
>
> diff --git gcc/cp/class.c gcc/cp/class.c
> index 9ca46441871..0239f6ae045 100644
> --- gcc/cp/class.c
> +++ gcc/cp/class.c
> @@ -9370,7 +9370,7 @@ build_vtbl_initializer (tree binfo,
> int i;
> if (init == size_zero_node)
>   for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
> -   CONSTRUCTOR_APPEND_ELT (*inits, idx, init);
> +   CONSTRUCTOR_APPEND_ELT (*inits, NULL_TREE, init);
> else
>   for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
> {
> @@ -9378,7 +9378,7 @@ build_vtbl_initializer (tree binfo,
>fn, build_int_cst (NULL_TREE, i));
>   TREE_CONSTANT (fdesc) = 1;
>  
> - CONSTRUCTOR_APPEND_ELT (*inits, idx, fdesc);
> + CONSTRUCTOR_APPEND_ELT (*inits, NULL_TREE, fdesc);
> }
>   }
>else

Thanks, that works.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

[Marek Polacek]

On Wed, Sep 19, 2018 at 05:07:34PM +0200, Andreas Schwab wrote:
> On Sep 19 2018, Marek Polacek  wrote:
> 
> > 2018-09-19  Marek Polacek  
> >
> > * class.c (build_vtbl_initializer): Don't mess with *inits for
> > TARGET_VTABLE_USES_DESCRIPTORS.
> >
> > diff --git gcc/cp/class.c gcc/cp/class.c
> > index 9ca46441871..0239f6ae045 100644
> > --- gcc/cp/class.c
> > +++ gcc/cp/class.c
> > @@ -9370,7 +9370,7 @@ build_vtbl_initializer (tree binfo,
> >   int i;
> >   if (init == size_zero_node)
> > for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
> > - CONSTRUCTOR_APPEND_ELT (*inits, idx, init);
> > + CONSTRUCTOR_APPEND_ELT (*inits, NULL_TREE, init);
> >   else
> > for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
> >   {
> > @@ -9378,7 +9378,7 @@ build_vtbl_initializer (tree binfo,
> >  fn, build_int_cst (NULL_TREE, i));
> > TREE_CONSTANT (fdesc) = 1;
> >  
> > -   CONSTRUCTOR_APPEND_ELT (*inits, idx, fdesc);
> > +   CONSTRUCTOR_APPEND_ELT (*inits, NULL_TREE, fdesc);
> >   }
> > }
> >else
> 
> Thanks, that works.

Great.  Jason, can I commit it then?

Marek

Re: [PATCH 03/25] Improve TARGET_MANGLE_DECL_ASSEMBLER_NAME.

[Julian Brown]

On Fri, 14 Sep 2018 22:49:35 -0400
Julian Brown  wrote:

> > > On 12/09/18 16:16, Richard Biener wrote:
> > > It may well be that there's a better way to solve the problem, or
> > > at least to do the lookups.
> > > 
> > > It may also be that there are some unintended consequences, such
> > > as false name matches, but I don't know of any at present.

> > Possibly, this was an abuse of these hooks, but it's arguably wrong
> > that that e.g. handle_alias_pairs has the "assembler name" leak
> > through into the user's source code -- if it's expected that the
> > hook could make arbitrary transformations to the string. (The
> > latter hook is only used by PE code for x86 at present, by the look
> > of it, and the default handles only special-purpose mangling
> > indicated by placing a '*' at the front of the symbol.)  

Two places I've found that currently expose the underlying symbol name
in the user's source code: one (documented!) is C++, where one must
write the mangled symbol name as the alias target:

int foo (int c) { ... }
int bar (int) __attribute__((alias("_Z3fooi")));

another (perhaps obscure) is x86/PE with "fastcall":

__attribute__((fastcall)) void foo(void) { ... }
void bar(void) __attribute__((alias("@foo@0")));

both of which probably suggest that using the decl name, rather than
demangling the assembler name (or using some completely different
solution) was the wrong thing to do.

I'll keep thinking about this...

Julian

[PATCH] Change EQ_ATTR_ALT to support up to 64 alternatives

[Ilya Leoshkevich]

On S/390 there is a need to support more than 32 instruction
alternatives per define_insn.  Currently this is not explicitly
prohibited or unsupported: MAX_RECOG_ALTERNATIVES is equal 35, and,
futhermore, the related code uses uint64_t for bitmaps in most places.

However, genattrtab contains the logic to convert (eq_attr "attribute"
"value") RTXs to (eq_attr_alt bitmap) RTXs, where bitmap contains
alternatives, whose "attribute" has the corresponding "value".
Unfortunately, bitmap is only 32 bits.

When adding the 33rd alternative, this led to (eq_attr "type" "larl")
becoming (eq_attr_alt -1050625 1), where -1050625 == 0xffeff7ff.  The
cleared bits 12, 21 and 32 correspond to two existing and one newly
added insn of type "larl".  compute_alternative_mask sign extended this
to 0xffeff7ff, which contained non-existent alternatives, and
this made simplify_test_exp fail with "invalid alternative specified".

I'm not sure why it didn't fail the same way before, since the top bit,
which led to sign extension, should have been set even with 32
alternatives.  Maybe simplify_test_exp was not called for "type"
attribute for some reason?

This patch widens EQ_ATTR_ALT bitmap to 64 bits, making it possible to
gracefully handle up to 64 alternatives.  It eliminates the problem with
the 33rd alternative on S/390.

gcc/ChangeLog:

2018-09-18  Ilya Leoshkevich  

* genattrtab.c (mk_attr_alt): Use alternative_mask.
(attr_rtx_1): Adjust caching to match the new EQ_ATTR_ALT field
types.
(check_attr_test): Use alternative_mask.
(get_attr_value): Likewise.
(compute_alternative_mask): Use alternative_mask and XWINT.
(make_alternative_compare): Use alternative_mask.
(attr_alt_subset_p): Use XWINT.
(attr_alt_subset_of_compl_p): Likewise.
(attr_alt_intersection): Likewise.
(attr_alt_union): Likewise.
(attr_alt_complement): Likewise.
(mk_attr_alt): Use alternative_mask.
(simplify_test_exp): Use alternative_mask and XWINT.
(write_test_expr): Use alternative_mask and XWINT, adjust bit
number calculation to support 64 bits.  Generate code that
checks 64-bit masks.
(main): Use alternative_mask.
* rtl.def (EQ_ATTR_ALT): Change field types from ii to ww.
---
 gcc/genattrtab.c | 127 +--
 gcc/recog.h  |   2 +-
 gcc/rtl.def  |   2 +-
 3 files changed, 71 insertions(+), 60 deletions(-)

diff --git a/gcc/genattrtab.c b/gcc/genattrtab.c
index f9b0bc94b0f..f8ff054fc7c 100644
--- a/gcc/genattrtab.c
+++ b/gcc/genattrtab.c
@@ -228,7 +228,9 @@ static int *insn_n_alternatives;
 /* Stores, for each insn code, a bitmap that has bits on for each possible
alternative.  */
 
-static uint64_t *insn_alternatives;
+/* Keep this in sync with recog.h.  */
+typedef uint64_t alternative_mask;
+static alternative_mask *insn_alternatives;
 
 /* Used to simplify expressions.  */
 
@@ -256,7 +258,7 @@ static char *attr_printf   (unsigned int, const 
char *, ...)
   ATTRIBUTE_PRINTF_2;
 static rtx make_numeric_value  (int);
 static struct attr_desc *find_attr (const char **, int);
-static rtx mk_attr_alt (uint64_t);
+static rtx mk_attr_alt (alternative_mask);
 static char *next_comma_elt   (const char **);
 static rtx insert_right_side  (enum rtx_code, rtx, rtx, int, int);
 static rtx copy_boolean   (rtx);
@@ -494,26 +496,26 @@ attr_rtx_1 (enum rtx_code code, va_list p)
}
 }
   else if (GET_RTX_LENGTH (code) == 2
-  && GET_RTX_FORMAT (code)[0] == 'i'
-  && GET_RTX_FORMAT (code)[1] == 'i')
+  && GET_RTX_FORMAT (code)[0] == 'w'
+  && GET_RTX_FORMAT (code)[1] == 'w')
 {
-  int  arg0 = va_arg (p, int);
-  int  arg1 = va_arg (p, int);
+  HOST_WIDE_INT arg0 = va_arg (p, HOST_WIDE_INT);
+  HOST_WIDE_INT arg1 = va_arg (p, HOST_WIDE_INT);
 
   hashcode = ((HOST_WIDE_INT) code + RTL_HASH (arg0) + RTL_HASH (arg1));
   for (h = attr_hash_table[hashcode % RTL_HASH_SIZE]; h; h = h->next)
if (h->hashcode == hashcode
&& GET_CODE (h->u.rtl) == code
-   && XINT (h->u.rtl, 0) == arg0
-   && XINT (h->u.rtl, 1) == arg1)
+   && XWINT (h->u.rtl, 0) == arg0
+   && XWINT (h->u.rtl, 1) == arg1)
  return h->u.rtl;
 
   if (h == 0)
{
  rtl_obstack = hash_obstack;
  rt_val = rtx_alloc (code);
- XINT (rt_val, 0) = arg0;
- XINT (rt_val, 1) = arg1;
+ XWINT (rt_val, 0) = arg0;
+ XWINT (rt_val, 1) = arg1;
}
 }
   else if (code == CONST_INT)
@@ -703,7 +705,8 @@ check_attr_test (file_location loc, rtx exp, attr_desc 
*attr)
  if (attr2 == NULL)
{
  if (! strcmp (XSTR (exp, 0), "alternative"))
-   return mk_attr_alt (((uint64_t) 1) << atoi (XSTR (exp, 1)));
+   return mk_attr

Re: C++ PATCH for c++/87357, missing -Wconversion warning

[Martin Sebor]

On 09/18/2018 09:47 PM, Marek Polacek wrote:

As I mentioned in the PR, [class.conv.fct] says "A conversion function is never
used to convert a (possibly cv-qualified) object to the (possibly cv-qualified)
same object type (or a reference to it), to a (possibly cv-qualified) base class
of that type (or a reference to it), or to (possibly cv-qualified) void." but I
noticed we weren't warning about

struct X {
  operator X();
};

(and there are no tests for this case) because comparing types directly only
works for TYPE_CANONICAL, otherwise we have to use same_type_*.

I'm also changing the warning about 'void' since we can't form a reference to
void.


Since you're changing the text of the void warning it would also
be nice to add quoting around the type name if it doesn't involve
adjusting too many tests.  But...

...

+struct B { };
+
+struct X : public B {
+  operator X(); // { dg-warning "3:conversion to the same type will never use a 
type conversion operator" }


Is the operator function mentioned in the warning?

If not, mentioning it would make it clearer which of a set of
operators is not going to be used (when there are multiple like
in this test) and also make it easier to distinguish one from
the others if they're on the same line (e.g., if the class is
the result of macro expansion).

Martin


+  operator X&(); // { dg-warning "3:conversion to a reference to the same type will 
never use a type conversion operator" }
+  operator X() const; // { dg-warning "3:conversion to the same type will never use 
a type conversion operator" }
+  operator const X(); // { dg-warning "3:conversion to the same type will never use 
a type conversion operator" }
+
+  operator B(); // { dg-warning "3:conversion to a base class will never use a type 
conversion operator" }
+  operator B&(); // { dg-warning "3:conversion to a reference to a base class will 
never use a type conversion operator" }
+  operator B() const; // { dg-warning "3:conversion to a base class will never use 
a type conversion operator" }
+  operator const B(); // { dg-warning "3:conversion to a base class will never use 
a type conversion operator" }
+
+  operator void(); // { dg-warning "3:conversion to void will never use a type 
conversion operator" }
+  operator void() const; // { dg-warning "3:conversion to void will never use a 
type conversion operator" }
+};

Re: C++ PATCH for c++/87357, missing -Wconversion warning

[Marek Polacek]

On Wed, Sep 19, 2018 at 09:51:44AM -0600, Martin Sebor wrote:
> On 09/18/2018 09:47 PM, Marek Polacek wrote:
> > As I mentioned in the PR, [class.conv.fct] says "A conversion function is 
> > never
> > used to convert a (possibly cv-qualified) object to the (possibly 
> > cv-qualified)
> > same object type (or a reference to it), to a (possibly cv-qualified) base 
> > class
> > of that type (or a reference to it), or to (possibly cv-qualified) void." 
> > but I
> > noticed we weren't warning about
> > 
> > struct X {
> >   operator X();
> > };
> > 
> > (and there are no tests for this case) because comparing types directly only
> > works for TYPE_CANONICAL, otherwise we have to use same_type_*.
> > 
> > I'm also changing the warning about 'void' since we can't form a reference 
> > to
> > void.
> 
> Since you're changing the text of the void warning it would also
> be nice to add quoting around the type name if it doesn't involve
> adjusting too many tests.  But...

Only two tests besides the new one trigger this warning, so that would be
trivial.

> ...
> > +struct B { };
> > +
> > +struct X : public B {
> > +  operator X(); // { dg-warning "3:conversion to the same type will never 
> > use a type conversion operator" }
> 
> Is the operator function mentioned in the warning?

Nope, just what the dg-warning says.

> If not, mentioning it would make it clearer which of a set of
> operators is not going to be used (when there are multiple like
> in this test) and also make it easier to distinguish one from
> the others if they're on the same line (e.g., if the class is
> the result of macro expansion).

Good idea.  Maybe let's commit this first (a bugfix) and then I can add
the types printing (an enhancement)?

Marek

Re: [C++ Patch] PR 87324 ("g++ ICE with overriding initializers: Segmentation fault")

[Jason Merrill]

OK.

On Wed, Sep 19, 2018 at 10:42 AM, Paolo Carlini
 wrote:
> Hi,
>
> in this simple error-recovery issue we ICE in get_class_binding_direct when
> we try to use IDENTIFIER_CONV_OP_P on the index which we nulled in
> cp_parser_initializer_list. If, instead, we assign error_mark_node to it we
> catch it later in reshape_init_class and error-recovery goes well.
>
> Tested x86_64-linux.
>
> Thanks, Paolo.
>
> 
>

Re: C++ PATCH for c++/87357, missing -Wconversion warning

[Jason Merrill]

On Tue, Sep 18, 2018 at 11:47 PM, Marek Polacek  wrote:
> As I mentioned in the PR, [class.conv.fct] says "A conversion function is 
> never
> used to convert a (possibly cv-qualified) object to the (possibly 
> cv-qualified)
> same object type (or a reference to it), to a (possibly cv-qualified) base 
> class
> of that type (or a reference to it), or to (possibly cv-qualified) void." but 
> I
> noticed we weren't warning about
>
> struct X {
>   operator X();
> };
>
> (and there are no tests for this case) because comparing types directly only
> works for TYPE_CANONICAL, otherwise we have to use same_type_*.
>
> I'm also changing the warning about 'void' since we can't form a reference to
> void.
>
> I'll also note that I think we should warn about this by default, not only
> when -Wconversion is in effect.

Agreed, this should get a new flag that is on by default.

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

OK.

> 2018-09-18  Marek Polacek  
>
> PR c++/87357 - missing -Wconversion warning
> * decl.c (grok_op_properties): Remove diagnostic parts mentioning
> a conversion to a reference to void.  Use
> same_type_ignoring_top_level_qualifiers_p rather than comparing types
> directly.
>
> * g++.dg/warn/Wconversion5.C: New test.
>
> diff --git gcc/cp/decl.c gcc/cp/decl.c
> index 827c1720335..503b433cbd1 100644
> --- gcc/cp/decl.c
> +++ gcc/cp/decl.c
> @@ -13553,15 +13553,11 @@ grok_op_properties (tree decl, bool complain)
> t = TYPE_MAIN_VARIANT (TREE_TYPE (t));
>
>if (VOID_TYPE_P (t))
> -   warning_at (loc, OPT_Wconversion,
> -   ref
> -   ? G_("conversion to a reference to void "
> -"will never use a type conversion operator")
> -   : G_("conversion to void "
> -"will never use a type conversion operator"));
> +   warning_at (loc, OPT_Wconversion, "conversion to void "
> +   "will never use a type conversion operator");
>else if (class_type)
> {
> - if (t == class_type)
> + if (same_type_ignoring_top_level_qualifiers_p (t, class_type))
> warning_at (loc, OPT_Wconversion,
> ref
> ? G_("conversion to a reference to the same type "
> diff --git gcc/testsuite/g++.dg/warn/Wconversion5.C 
> gcc/testsuite/g++.dg/warn/Wconversion5.C
> index e69de29bb2d..00b1ddab188 100644
> --- gcc/testsuite/g++.dg/warn/Wconversion5.C
> +++ gcc/testsuite/g++.dg/warn/Wconversion5.C
> @@ -0,0 +1,20 @@
> +// PR c++/87357
> +// { dg-do compile }
> +// { dg-options "-Wconversion" }
> +
> +struct B { };
> +
> +struct X : public B {
> +  operator X(); // { dg-warning "3:conversion to the same type will never 
> use a type conversion operator" }
> +  operator X&(); // { dg-warning "3:conversion to a reference to the same 
> type will never use a type conversion operator" }
> +  operator X() const; // { dg-warning "3:conversion to the same type will 
> never use a type conversion operator" }
> +  operator const X(); // { dg-warning "3:conversion to the same type will 
> never use a type conversion operator" }
> +
> +  operator B(); // { dg-warning "3:conversion to a base class will never use 
> a type conversion operator" }
> +  operator B&(); // { dg-warning "3:conversion to a reference to a base 
> class will never use a type conversion operator" }
> +  operator B() const; // { dg-warning "3:conversion to a base class will 
> never use a type conversion operator" }
> +  operator const B(); // { dg-warning "3:conversion to a base class will 
> never use a type conversion operator" }
> +
> +  operator void(); // { dg-warning "3:conversion to void will never use a 
> type conversion operator" }
> +  operator void() const; // { dg-warning "3:conversion to void will never 
> use a type conversion operator" }
> +};

Re: C++ PATCH for c++/87357, missing -Wconversion warning

[Martin Sebor]

On 09/19/2018 10:02 AM, Marek Polacek wrote:

On Wed, Sep 19, 2018 at 09:51:44AM -0600, Martin Sebor wrote:

On 09/18/2018 09:47 PM, Marek Polacek wrote:

As I mentioned in the PR, [class.conv.fct] says "A conversion function is never
used to convert a (possibly cv-qualified) object to the (possibly cv-qualified)
same object type (or a reference to it), to a (possibly cv-qualified) base class
of that type (or a reference to it), or to (possibly cv-qualified) void." but I
noticed we weren't warning about

struct X {
  operator X();
};

(and there are no tests for this case) because comparing types directly only
works for TYPE_CANONICAL, otherwise we have to use same_type_*.

I'm also changing the warning about 'void' since we can't form a reference to
void.


Since you're changing the text of the void warning it would also
be nice to add quoting around the type name if it doesn't involve
adjusting too many tests.  But...


Only two tests besides the new one trigger this warning, so that would be
trivial.


...

+struct B { };
+
+struct X : public B {
+  operator X(); // { dg-warning "3:conversion to the same type will never use a 
type conversion operator" }


Is the operator function mentioned in the warning?


Nope, just what the dg-warning says.


If not, mentioning it would make it clearer which of a set of
operators is not going to be used (when there are multiple like
in this test) and also make it easier to distinguish one from
the others if they're on the same line (e.g., if the class is
the result of macro expansion).


Good idea.  Maybe let's commit this first (a bugfix) and then I can add
the types printing (an enhancement)?


Sure, whatever works for you.

Martin

Re: [PATCH] PR libstdc++/87135 Rehash only when necessary (LWG2156)

[François Dumont]

On 09/19/2018 01:07 PM, Jonathan Wakely wrote:

On 18/09/18 22:39 +0200, François Dumont wrote:

On 09/18/2018 10:41 AM, Jonathan Wakely wrote:

On 13/09/18 07:49 +0200, François Dumont wrote:

All changes limited to hashtable_c++0x.cc file.

_Prime_rehash_policy::_M_next_bkt now really does what its comment 
was declaring that is to say:

  // Return a prime no smaller than n.

_Prime_rehash_policy::_M_need_rehash rehash only when _M_next_size 
is exceeded, not only when it is reach.


    PR libstdc++/87135
    * src/c++11/hashtable_c++0x.cc:
    (_Prime_rehash_policy::_M_next_bkt): Return a prime no smaller 
than

    requested size, but not necessarily greater.
    (_Prime_rehash_policy::_M_need_rehash): Rehash only if target 
size is

    strictly greater than next resize threshold.
    * testsuite/23_containers/unordered_map/modifiers/reserve.cc: 
Adapt test
    to validate that there is no rehash as long as number of 
insertion is

    lower or equal to the reserved number of elements.

unordered_map tests successful, ok to commit once all other tests 
completed ?


François


diff --git a/libstdc++-v3/src/c++11/hashtable_c++0x.cc 
b/libstdc++-v3/src/c++11/hashtable_c++0x.cc

index a776a8506fe..ec6031b3f5b 100644
--- a/libstdc++-v3/src/c++11/hashtable_c++0x.cc
+++ b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
@@ -46,10 +46,10 @@ namespace __detail
  {
    // Optimize lookups involving the first elements of __prime_list.
    // (useful to speed-up, eg, constructors)
-    static const unsigned char __fast_bkt[13]
-  = { 2, 2, 3, 5, 5, 7, 7, 11, 11, 11, 11, 13, 13 };
+    static const unsigned char __fast_bkt[]
+  = { 2, 2, 2, 3, 5, 5, 7, 7, 11, 11, 11, 11, 13, 13 };

-    if (__n <= 12)
+    if (__n < sizeof(__fast_bkt) / sizeof(unsigned char))


sizeof(unsigned char) is defined to be 1, always.


I also though it was overkill but there are so many platforms that I 
prefer to be caution. Good to know that it can't be otherwise.




I think this should be just sizeof(__fast_bkt), or if you're trying to
guard against the type of __fast_bkt changing, then use
sizeof(__fast_bkt) / sizeof(__fast_bkt[0]))


I committed with simply sizeof(__fast_bkt)



This caused some testsuite regressions:

FAIL: 23_containers/unordered_set/hash_policy/71181.cc execution test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc:42: 
void test(int) [with _USet = std::unordered_set]: Assertion 
'us.bucket_count() == bkts' failed.


FAIL: 23_containers/unordered_set/hash_policy/load_factor.cc execution 
test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/load_factor.cc:50: 
void test() [with _USet = std::unordered_set]: Assertion 
'us.load_factor() <= us.max_load_factor()' failed.


FAIL: 23_containers/unordered_set/hash_policy/prime_rehash.cc 
execution test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc:37: 
void test01(): Assertion 'nxt == policy._M_next_bkt(mx)' failed.




I forgot I only run unordered_map tests. I'll run the others this 
evening and will fix those.


François

Re: [PATCH 08/25] Fix co-array allocation

[Andrew Stubbs]

On 05/09/18 19:07, Janne Blomqvist wrote:

The argument must be of type size_type_node, not sizetype. Please instead
use

size = build_zero_cst (size_type_node);



 * trans-intrinsic.c (conv_intrinsic_event_query): Convert computed
 index to a size_t type.



Using integer_type_node is wrong, but the correct type for calculating
array indices (lbound, ubound,  etc.) is not size_type_node but rather
gfc_array_index_type (which in practice maps to ptrdiff_t). So please use
that, and then fold_convert index to size_type_node just before generating
the call to event_query.



 * trans-stmt.c (gfc_trans_event_post_wait): Likewise.



Same here as above.


How is the attached? I retested and found no regressions.

Andrew
Fix co-array allocation

The Fortran front-end has a bug in which it uses "int" values for "size_t"
parameters.  I don't know why this isn't problem for all 64-bit architectures,
but GCN ends up with the data in the wrong argument register and/or stack slot,
and bad things happen.

This patch corrects the issue by setting the correct type.

2018-09-19  Andrew Stubbs  
Kwok Cheung Yeung  

	gcc/fortran/
	* trans-expr.c (gfc_trans_structure_assign): Ensure that the first
	argument of a call to _gfortran_caf_register is of size_type_node.
	* trans-intrinsic.c (conv_intrinsic_event_query): Convert computed
	index to a size_type_node type.
	* trans-stmt.c (gfc_trans_event_post_wait): Likewise.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 56ce98c..28079ac 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -7729,7 +7729,7 @@ gfc_trans_structure_assign (tree dest, gfc_expr * expr, bool init, bool coarray)
 		 suffices to recognize the data as array.  */
 	  if (rank < 0)
 		rank = 1;
-	  size = integer_zero_node;
+	  size = build_zero_cst (size_type_node);
 	  desc = field;
 	  gfc_add_modify (&block, gfc_conv_descriptor_rank (desc),
 			  build_int_cst (signed_char_type_node, rank));
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index b2cea93..569435d 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -10732,7 +10732,9 @@ conv_intrinsic_event_query (gfc_code *code)
 	  tmp = fold_build2_loc (input_location, MULT_EXPR,
  integer_type_node, extent, tmp);
 	  index = fold_build2_loc (input_location, PLUS_EXPR,
-   integer_type_node, index, tmp);
+   gfc_array_index_type, index,
+   fold_convert (gfc_array_index_type,
+		 tmp));
 	  if (i < ar->dimen - 1)
 		{
 		  ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[i]);
@@ -10756,6 +10758,7 @@ conv_intrinsic_event_query (gfc_code *code)
 	  stat = gfc_create_var (integer_type_node, "stat");
 	}
 
+  index = fold_convert (size_type_node, index);
   tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_event_query, 5,
token, index, image_index, count
    ? gfc_build_addr_expr (NULL, count) : count,
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 795d3cc..92d9c37 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -1096,7 +1096,8 @@ gfc_trans_event_post_wait (gfc_code *code, gfc_exec_op op)
 	  tmp = fold_build2_loc (input_location, MULT_EXPR,
  integer_type_node, extent, tmp);
 	  index = fold_build2_loc (input_location, PLUS_EXPR,
-   integer_type_node, index, tmp);
+   gfc_array_index_type, index,
+   fold_convert (gfc_array_index_type, tmp));
 	  if (i < ar->dimen - 1)
 	{
 	  ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[i]);
@@ -1130,6 +1131,7 @@ gfc_trans_event_post_wait (gfc_code *code, gfc_exec_op op)
   stat = gfc_create_var (integer_type_node, "stat");
 }
 
+  index = fold_convert (size_type_node, index);
   if (op == EXEC_EVENT_POST)
 tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_event_post, 6,
 			   token, index, image_index,

Re: [PATCH 09/25] Elide repeated RTL elements.

[Andrew Stubbs]

On 11/09/18 23:45, Jeff Law wrote:

On 9/5/18 5:49 AM, a...@codesourcery.com wrote:


GCN's 64-lane vectors tend to make RTL dumps very long.  This patch makes them
far more bearable by eliding long sequences of the same element into "repeated"
messages.

2018-09-05  Andrew Stubbs  
Jan Hubicka  
Martin Jambor  

* print-rtl.c (print_rtx_operand_codes_E_and_V): Print how many times
the same elements are repeated rather than printing all of them.

Does this need a corresponding change to the RTL front-end so that it
can read the new form?


Here's an updated patch incorporating the RTL front-end changes. I had 
to change from "repeated 2x" to "repeated x2" because the former is not 
a valid C token, and apparently that's important.


I've confirmed that it can read RTL and that subsequent dumps look correct.

OK?

Andrew
Elide repeated RTL elements.

GCN's 64-lane vectors tend to make RTL dumps very long.  This patch makes them
far more bearable by eliding long sequences of the same element into "repeated"
messages.

This also takes care of reading repeated sequences in the RTL front-end.

2018-09-19  Andrew Stubbs  
	Jan Hubicka  
	Martin Jambor  

	gcc.
	* print-rtl.c (print_rtx_operand_codes_E_and_V): Print how many times
	the same elements are repeated rather than printing all of them.
	* read-rtl.c (rtx_reader::read_rtx_operand): Recognize and expand
	"repeated" elements.

diff --git a/gcc/print-rtl.c b/gcc/print-rtl.c
index 5dd2e31..1228483 100644
--- a/gcc/print-rtl.c
+++ b/gcc/print-rtl.c
@@ -370,7 +370,20 @@ rtx_writer::print_rtx_operand_codes_E_and_V (const_rtx in_rtx, int idx)
 	m_sawclose = 1;
 
   for (int j = 0; j < XVECLEN (in_rtx, idx); j++)
-	print_rtx (XVECEXP (in_rtx, idx, j));
+	{
+	  int j1;
+
+	  print_rtx (XVECEXP (in_rtx, idx, j));
+	  for (j1 = j + 1; j1 < XVECLEN (in_rtx, idx); j1++)
+	if (XVECEXP (in_rtx, idx, j) != XVECEXP (in_rtx, idx, j1))
+	  break;
+
+	  if (j1 != j + 1)
+	{
+	  fprintf (m_outfile, " repeated x%i", j1 - j);
+	  j = j1 - 1;
+	}
+	}
 
   m_indent -= 2;
 }
diff --git a/gcc/read-rtl.c b/gcc/read-rtl.c
index 723c3e1..7ede18f 100644
--- a/gcc/read-rtl.c
+++ b/gcc/read-rtl.c
@@ -1690,6 +1690,8 @@ rtx_reader::read_rtx_operand (rtx return_rtx, int idx)
 	struct obstack vector_stack;
 	int list_counter = 0;
 	rtvec return_vec = NULL_RTVEC;
+	rtx saved_rtx = NULL_RTX;
+	int repeat_count = 0;
 
 	require_char_ws ('[');
 
@@ -1700,8 +1702,34 @@ rtx_reader::read_rtx_operand (rtx return_rtx, int idx)
 	if (c == EOF)
 	  fatal_expected_char (']', c);
 	unread_char (c);
+
+	rtx value;
+	if (repeat_count <= 0 && c == 'r')
+	  {
+		/* Process "repeated Nx" directive.  */
+		read_name (&name);
+		if (strcmp (name.string, "repeated"))
+		  fatal_with_file_and_line ("invalid directive \"%s\"\n",
+	name.string);
+		read_name (&name);
+		if (!sscanf (name.string, "x%d", &repeat_count))
+		  fatal_with_file_and_line ("invalid repeat count \"%s\"\n",
+	name.string);
+
+		/* We already saw one of the instances.  */
+		repeat_count--;
+	  }
+	if (repeat_count > 0)
+	  {
+		repeat_count--;
+		value = saved_rtx;
+	  }
+	else
+	  value = read_nested_rtx ();
+
 	list_counter++;
-	obstack_ptr_grow (&vector_stack, read_nested_rtx ());
+	obstack_ptr_grow (&vector_stack, value);
+	saved_rtx = value;
 	  }
 	if (list_counter > 0)
 	  {

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

[Jason Merrill]

On Wed, Sep 19, 2018 at 11:10 AM, Marek Polacek  wrote:
> On Wed, Sep 19, 2018 at 05:07:34PM +0200, Andreas Schwab wrote:
>> On Sep 19 2018, Marek Polacek  wrote:
>>
>> > 2018-09-19  Marek Polacek  
>> >
>> > * class.c (build_vtbl_initializer): Don't mess with *inits for
>> > TARGET_VTABLE_USES_DESCRIPTORS.
>> >
>> > diff --git gcc/cp/class.c gcc/cp/class.c
>> > index 9ca46441871..0239f6ae045 100644
>> > --- gcc/cp/class.c
>> > +++ gcc/cp/class.c
>> > @@ -9370,7 +9370,7 @@ build_vtbl_initializer (tree binfo,
>> >   int i;
>> >   if (init == size_zero_node)
>> > for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
>> > - CONSTRUCTOR_APPEND_ELT (*inits, idx, init);
>> > + CONSTRUCTOR_APPEND_ELT (*inits, NULL_TREE, init);
>> >   else
>> > for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
>> >   {
>> > @@ -9378,7 +9378,7 @@ build_vtbl_initializer (tree binfo,
>> >  fn, build_int_cst (NULL_TREE, i));
>> > TREE_CONSTANT (fdesc) = 1;
>> >
>> > -   CONSTRUCTOR_APPEND_ELT (*inits, idx, fdesc);
>> > +   CONSTRUCTOR_APPEND_ELT (*inits, NULL_TREE, fdesc);
>> >   }
>> > }
>> >else
>>
>> Thanks, that works.
>
> Great.  Jason, can I commit it then?

Andreas, do the new testcases pass?  That would surprise me, but OK if so.

Jason

[PATCH] combine: Use correct mode in new comparison (PR86902)

[Segher Boessenkool]

This code in try_combine uses the wrong mode.  This fails (with RTL
checking) in trunk, but not in any released branches.

Committing to trunk.


Segher


2018-09-19  Segher Boessenkool  

* combine.c (try_combine): When changing the CC mode used, don't change
an unrelated mode in other_insn to that new CC mode.

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

diff --git a/gcc/combine.c b/gcc/combine.c
index d3f7143..256b5a4 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -3338,7 +3338,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, 
rtx_insn *i0,
{
  /* Replace cc_use_loc with entire new RTX.  */
  SUBST (*cc_use_loc,
-gen_rtx_fmt_ee (compare_code, compare_mode,
+gen_rtx_fmt_ee (compare_code, GET_MODE (*cc_use_loc),
 newpat_dest, const0_rtx));
  undobuf.other_insn = cc_use_insn;
}
@@ -3347,7 +3347,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, 
rtx_insn *i0,
  /* Just replace the CC reg with a new mode.  */
  SUBST (XEXP (*cc_use_loc, 0), newpat_dest);
  undobuf.other_insn = cc_use_insn;
-   } 
+   }
}
 
  /* Now we modify the current newpat:
-- 
1.8.3.1

Re: [PATCH] Provide extension hint for aarch64 target (PR driver/83193).

[Martin Liška]

PING^3

On 8/23/18 1:00 PM, Martin Liška wrote:

PING^2

On 08/01/2018 03:56 PM, Martin Liška wrote:

PING^1

On 07/18/2018 05:49 PM, Martin Liška wrote:

Hi.

This patch improves aarch64 feature modifier hints.

May I please ask ARM folks to test the patch?
Thanks,
Martin

gcc/ChangeLog:

2018-07-18  Martin Liska  

 PR driver/83193
* common/config/aarch64/aarch64-common.c (aarch64_parse_extension):
 Set invalid_extension when there's any.
(aarch64_get_all_extension_candidates): New function.
(aarch64_rewrite_selected_cpu): Pass NULL as new argument.
* config/aarch64/aarch64-protos.h 
(aarch64_get_all_extension_candidates):
 Declare new function.
* config/aarch64/aarch64.c (aarch64_parse_arch): Record
 invalid_feature.
(aarch64_parse_cpu): Likewise.
(aarch64_print_hint_for_feature_modifier): New.
(aarch64_validate_mcpu): Record invalid feature modifier
 and print hint for it.
(aarch64_validate_march): Likewise.
(aarch64_handle_attr_arch): Likewise.
(aarch64_handle_attr_cpu): Likewise.
(aarch64_handle_attr_isa_flags): Likewise.

gcc/testsuite/ChangeLog:

2018-07-18  Martin Liska  

 PR driver/83193
* gcc.target/aarch64/spellcheck_7.c: New test.
* gcc.target/aarch64/spellcheck_8.c: New test.
---
  gcc/common/config/aarch64/aarch64-common.c| 20 +-
  gcc/config/aarch64/aarch64-protos.h   |  4 +-
  gcc/config/aarch64/aarch64.c  | 67 +++
  .../gcc.target/aarch64/spellcheck_7.c | 11 +++
  .../gcc.target/aarch64/spellcheck_8.c | 12 
  5 files changed, 97 insertions(+), 17 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_7.c
  create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_8.c

[PATCH] Remove arc profile histogram in non-LTO mode.

[Martin Liška]

Hello.

I've been working for some time on a patch that simplifies how we set
the hotness threshold of basic blocks. Currently, we calculate so called
arc profile histograms that should identify edges that cover 99.9% of all
branching. These edges are then identified as hot. Disadvantage of the approach
is that it comes with significant overhead in run-time and GCC related code
is also not trivial. Moreover, anytime a histogram is merged after an 
instrumented
run, the resulting histogram is misleading.

That said, I decided to simplify it again, remove usage of the histogram and 
return
to what we have before (--param hot-bb-count-fraction). That basically says that
we consider hot each edge that has execution count bigger than sum_max / 10.000.

Note that LTO+PGO remains untouched as it still uses histogram that is 
dynamically
calculated by read arc counts.

Note the statistics of the patch:
 19 files changed, 101 insertions(+), 1216 deletions(-)

I'm attaching file sizes of SPEC2006 int benchmark.

Patch survives testing on x86_64-linux-gnu machine.
Ready to be installed?

Martin

gcc/ChangeLog:

2018-09-19  Martin Liska  

* auto-profile.c (autofdo_source_profile::read): Do not
set sum_all.
(read_profile): Do not add working sets.
(read_autofdo_file): Remove sum_all.
(afdo_callsite_hot_enough_for_early_inline): Remove const
qualifier.
* coverage.c (struct counts_entry): Remove gcov_summary.
(read_counts_file): Read new GCOV_TAG_OBJECT_SUMMARY,
do not support GCOV_TAG_PROGRAM_SUMMARY.
(get_coverage_counts): Remove summary and expected
arguments.
* coverage.h (get_coverage_counts): Likewise.
* doc/gcov-dump.texi: Remove -w option.
* gcov-dump.c (dump_working_sets): Remove.
(main): Do not support '-w' option.
(print_usage): Likewise.
(tag_summary): Likewise.
* gcov-io.c (gcov_write_summary): Do not dump
histogram.
(gcov_read_summary): Likewise.
(gcov_histo_index): Remove.
(gcov_histogram_merge): Likewise.
(compute_working_sets): Likewise.
* gcov-io.h (GCOV_TAG_OBJECT_SUMMARY): Mark
it not obsolete.
(GCOV_TAG_PROGRAM_SUMMARY): Mark it obsolete.
(GCOV_TAG_SUMMARY_LENGTH): Adjust.
(GCOV_HISTOGRAM_SIZE): Remove.
(GCOV_HISTOGRAM_BITVECTOR_SIZE): Likewise.
(struct gcov_summary): Simplify rapidly just
to runs and sum_max fields.
(gcov_histo_index): Remove.
(NUM_GCOV_WORKING_SETS): Likewise.
(compute_working_sets): Likewise.
* gcov-tool.c (print_overlap_usage_message): Remove
trailing empty line.
* gcov.c (read_count_file): Read GCOV_TAG_OBJECT_SUMMARY.
(output_lines): Remove program related line.
* ipa-profile.c (ipa_profile): Do not consider GCOV histogram.
* lto-cgraph.c (output_profile_summary): Do not stream GCOV
histogram.
(input_profile_summary): Do not read it.
(merge_profile_summaries): And do not merge it.
(input_symtab): Do not call removed function.
* modulo-sched.c (sms_schedule): Do not print sum_max.
* params.def (HOT_BB_COUNT_FRACTION): Reincarnate param that was
removed when histogram method was invented.
(HOT_BB_COUNT_WS_PERMILLE): Mention that it's used only in LTO
mode.
* postreload-gcse.c (eliminate_partially_redundant_load): Fix
GCOV coding style.
* predict.c (get_hot_bb_threshold): Use HOT_BB_COUNT_FRACTION
and dump selected value.
* profile.c (add_working_set): Remove.
(get_working_sets): Likewise.
(find_working_set): Likewise.
(get_exec_counts): Do not work with working sets.
(read_profile_edge_counts): Do not inform as sum_max is removed.
(compute_branch_probabilities): Likewise.
(compute_value_histograms): Remove argument for call of
get_coverage_counts.
* profile.h: Do not make gcov_summary const.

libgcc/ChangeLog:

2018-09-19  Martin Liska  

* libgcov-driver.c (crc32_unsigned): Remove.
(gcov_histogram_insert): Likewise.
(gcov_compute_histogram): Likewise.
(compute_summary): Simplify rapidly.
(merge_one_data): Do not handle PROGRAM_SUMMARY tag.
(merge_summary): Rapidly simplify.
(dump_one_gcov): Ignore gcov_summary.
(gcov_do_dump): Do not handle program summary, it's not
used.
* libgcov-util.c (tag_summary): Remove.
(read_gcda_finalize): Fix coding style.
(read_gcda_file): Initialize curr_object_summary.
(compute_summary): Remove.
(calculate_overlap): Remove settings of run_max.
---
 gcc/auto-profile.c  |  21 +--
 gcc/coverage.c  |  59 +-
 gcc/coverage.h  |   4 +-
 gcc/doc/gcov-dump.texi  |   6 +-
 gcc/gcov-dump.c |  81 +---
 gcc/gcov-io.c   

[PATCH v2] S/390: Fix conditional returns on z196+

[Ilya Leoshkevich]

S/390 epilogue ends with (parallel [(return) (use %r14)]) instead of
the more usual (return) or (simple_return).  This sequence is not
recognized by the conditional return logic in try_optimize_cfg ().

This was introduced for processors older than z196, where it is
sometimes profitable to use call-clobbered register for returning
instead of %r14.  On newer processors we always return via %r14,
for which the fact that it's used is already reflected by
EPILOGUE_USES.  In this case a simple (return) suffices.

This patch changes return_use () to emit simple (return)s when
returning via %r14.  The resulting sequences are recognized by the
conditional return logic in try_optimize_cfg ().

gcc/ChangeLog:

2018-09-19  Ilya Leoshkevich  

PR target/80080
* config/s390/s390.md: Do not use PARALLEL RETURN+USE when
returning via %r14.

gcc/testsuite/ChangeLog:

2018-09-19  Ilya Leoshkevich  

PR target/80080
* gcc.target/s390/risbg-ll-3.c: Expect conditional returns.
* gcc.target/s390/zvector/vec-cmp-2.c: Likewise.
---
 gcc/config/s390/s390.md   |  7 +++
 gcc/testsuite/gcc.target/s390/risbg-ll-3.c|  6 +--
 .../gcc.target/s390/zvector/vec-cmp-2.c   | 48 +--
 3 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 35d22eb50cc..eb363e6d7f8 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -10831,6 +10831,13 @@
  (use (match_operand 0 "register_operand" "a"))])]
   ""
 {
+  if (REGNO (operands[0]) == RETURN_REGNUM && s390_can_use_return_insn ())
+{
+  /* The fact that RETURN_REGNUM is used is already reflected by
+ EPILOGUE_USES.  Emit plain (return).  */
+  emit_jump_insn (gen_return ());
+  DONE;
+}
   if (!TARGET_CPU_Z10
   && TARGET_INDIRECT_BRANCH_NOBP_RET_OPTION)
 {
diff --git a/gcc/testsuite/gcc.target/s390/risbg-ll-3.c 
b/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
index 838f1ffbd91..2a2db543cd9 100644
--- a/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
+++ b/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
@@ -23,7 +23,7 @@ i64 f1 (i64 v_a, i64 v_b)
 extern i64 f2_foo();
 i64 f2 (i64 v_a, i64 v_b)
 {
-/* { dg-final { scan-assembler "f2:\n\trisbg\t%r2,%r3,60,62,0\n\tje\t" { 
target { lp64 } } } } */
+/* { dg-final { scan-assembler 
"f2:\n\trisbg\t%r2,%r3,60,62,0\n\tbner\t%r14\n\tjg\tf2_foo\n" { target { lp64 } 
} } } */
 /* { dg-final { scan-assembler 
"f2:\n\trisbgn\t%r3,%r2,0,0\\\+32-1,64-0-32\n\trisbg\t%r3,%r5,60,62,0" { target 
{ ! lp64 } } } } */
   i64 v_anda = v_a & -15;
   i64 v_andb = v_b & 14;
@@ -37,8 +37,8 @@ i64 f2 (i64 v_a, i64 v_b)
 void f2_bar ();
 void f2_cconly (i64 v_a, i64 v_b)
 {
-/* { dg-final { scan-assembler "f2_cconly:\n\trisbg\t%r3,%r2,63,59,0\n\tjne\t" 
 { target { lp64 } } } } */
-/* { dg-final { scan-assembler 
"f2_cconly:\n\trisbgn\t%r3,%r2,0,0\\\+32-1,64-0-32\n\trisbg\t%r3,%r5,60,62,0\n\tjne\t"
 { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler 
"f2_cconly:\n\trisbg\t%r3,%r2,63,59,0\n\tber\t%r14\n\tjg\tf2_bar\n" { target { 
lp64 } } } } */
+/* { dg-final { scan-assembler 
"f2_cconly:\n\trisbgn\t%r3,%r2,0,0\\\+32-1,64-0-32\n\trisbg\t%r3,%r5,60,62,0\n\tber\t%r14\n\tjg\tf2_bar\n"
 { target { ! lp64 } } } } */
   if ((v_a & -15) | (v_b & 14))
 f2_bar();
 }
diff --git a/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c 
b/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c
index 1e63defa063..09a15eb25f0 100644
--- a/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c
+++ b/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c
@@ -15,7 +15,7 @@ all_eq_double (vector double a, vector double b)
   if (__builtin_expect (vec_all_eq (a, b), 1))
 g = 2;
 }
-/* { dg-final { scan-assembler-times 
all_eq_double:\n\tvfcedbs\t%v\[0-9\]*,%v24,%v26\n\tjne 1 } } */
+/* { dg-final { scan-assembler-times 
all_eq_double:\n\tvfcedbs\t%v\[0-9\]*,%v24,%v26\n\tbner\t%r14\n 1 } } */
 
 void __attribute__((noinline,noclone))
 all_ne_double (vector double a, vector double b)
@@ -23,7 +23,7 @@ all_ne_double (vector double a, vector double b)
   if (__builtin_expect (vec_all_ne (a, b), 1))
 g = 2;
 }
-/* { dg-final { scan-assembler-times 
all_ne_double:\n\tvfcedbs\t%v\[0-9\]*,%v24,%v26\n\tjle 1 } } */
+/* { dg-final { scan-assembler-times 
all_ne_double:\n\tvfcedbs\t%v\[0-9\]*,%v24,%v26\n\tbler\t%r14\n 1 } } */
 
 void __attribute__((noinline,noclone))
 all_gt_double (vector double a, vector double b)
@@ -31,7 +31,7 @@ all_gt_double (vector double a, vector double b)
   if (__builtin_expect (vec_all_gt (a, b), 1))
 g = 2;
 }
-/* { dg-final { scan-assembler-times 
all_gt_double:\n\tvfchdbs\t%v\[0-9\]*,%v24,%v26\n\tjne 1 } } */
+/* { dg-final { scan-assembler-times 
all_gt_double:\n\tvfchdbs\t%v\[0-9\]*,%v24,%v26\n\tbner\t%r14\n 1 } } */
 
 void __attribute__((noinline,noclone))
 all_lt_double (vector double a, vector double b)
@@ -39,7 +39,7 @@ all_lt_double (vector double a, vector double b)

[Patch, fortran] PR84109 - ICE in adjustl on allocatable array of strings

[Paul Richard Thomas]

As Dominique pointed out (and I denied initially - sorry!) this PR is
essentially the same as PR87239 except that an intrinsic, rather than
an extrinsic, function is involved. I have treated it in the same way
but have added a slight improvement to keep scalar elemental calls
outside of the scalarization loop.

Committed to trunk as r264427. Like the patch for PR87239 I think that
it is worth applying to 8-branch as a quality of implementation issue.
I will wait a while before applying either patch to 8-branch.

Cheers

Paul

2018-09-19  Paul Thomas  

PR fortran/84109
* trans-expr.c (gfc_trans_assignment_1): The rse.pre for the
assignment of deferred character intrinsic elemental function
results to a realocatable lhs must not be added to the exterior
block if they are array valued but must go to the loop body.

2018-09-19  Paul Thomas  

PR fortran/84109
* gfortran.dg/elemental_function_3.f90 : New test.

Re: [PATCH 01/14] Add D front-end (DMD) language implementation and license.

[Iain Buclaw]

On 18 September 2018 at 02:31, Iain Buclaw  wrote:
> This patch adds the DMD front-end proper and license (Boost) files,
> comprised of a lexer, parser, and semantic analyzer.
>
> ftp://ftp.gdcproject.org/patches/v4/01-v4-d-frontend-dmd.patch
>

I've dug up the history of what was reviewed before, so perhaps we can
avoid repeating what has been previously been discussed.

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00582.html

All sources in this patch are mainlined on github, and we are just a
downstream user.

The FSF has said that there's no problem including these in gcc as they are.

Iain.

Re: [PATCH] Add a dwarf unit type to represent 24 bit values.

[John Darrington]

Thank you for your insight.  I will investigate further and see if I can
find out what is going on.

J'

On Thu, Sep 13, 2018 at 01:33:34PM -0400, Jason Merrill wrote:

 Well, that's curious, given that GCC doesn't have that address type either.
 
 Ah, looking closer, I see that we aren't dealing with the EH unwind
 information, but rather the normal DWARF unwind information, which
 uses
 
   /* The encoding for FDE's in a normal .debug_frame section
  depends on the target address size.  */
   cie->encoding = DW_EH_PE_absptr;
 
 it seems strange that GDB then wants to use one of the other codes as
 a proxy for loading a particular number of bytes.
 
 I also notice that the default definition of DWARF2_ADDR_SIZE in GCC
 has a comment,
 
 /* The size of addresses as they appear in the Dwarf 2 data.
Some architectures use word addresses to refer to code locations,
but Dwarf 2 info always uses byte addresses.  On such machines,
Dwarf 2 addresses need to be larger than the architecture's
pointers.  */
 #define DWARF2_ADDR_SIZE ((POINTER_SIZE + BITS_PER_UNIT - 1) / 
BITS_PER_UNIT)
 
 And many targets with smaller pointers override this in GCC and GAS, e.g.
 
 ./gas/config/tc-msp430.h:#define DWARF2_ADDR_SIZE(bfd) 4
 ./gas/config/tc-s12z.h:#define DWARF2_ADDR_SIZE(bfd) 4
 ./gas/config/tc-wasm32.h:#define DWARF2_ADDR_SIZE(bfd)   4
 ./gas/config/tc-xgate.h:#define DWARF2_ADDR_SIZE(bfd) 4
 ./gas/config/tc-aarch64.c:/* Implement DWARF2_ADDR_SIZE.  */
 ./gas/config/tc-csky.h:#define DWARF2_ADDR_SIZE(bfd)   4
 ./gas/config/tc-avr.h:#define DWARF2_ADDR_SIZE(bfd) 4
 
 Is this appropriate for your target, as well?
 
 Perhaps GCC should double check that DWARF2_ADDR_SIZE is 2, 4, or 8.
 
 Jason

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

C++ PATCH to add -Wclass-conversion

[Marek Polacek]

This patch adds a new warning -Wclass-conversion that is on by default, and
warns about conversion functions converting a class to the wrong type.  This
was under the -Wconversion umbrella, but we should warn about this by default.

It also makes the warning print the types in question.

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

2018-09-19  Marek Polacek  

Add -Wclass-conversion.
* c.opt (Wclass-conversion): New.

* decl.c (grok_op_properties): Change a warning from -Wconversion to
-Wclass-conversion.  Make it print the types.

* doc/invoke.texi: Document -Wclass-conversion.

* g++.dg/conversion/op4.C: Add dg-warning.
* g++.dg/warn/Wclass-conversion1.C: New test.
* g++.dg/warn/Wclass-conversion2.C: New test.
* g++.dg/warn/Wconversion5.C: Remove file.
* g++.dg/warn/conversion-function-1.C: Use -Wno-class-converison.
* g++.old-deja/g++.bugs/900215_01.C: Adjust dg-warning.
* g++.old-deja/g++.jason/conversion5.C: Likewise.

diff --git gcc/c-family/c.opt gcc/c-family/c.opt
index 092ec940d86..ea863f71e34 100644
--- gcc/c-family/c.opt
+++ gcc/c-family/c.opt
@@ -850,6 +850,10 @@ Wnon-template-friend
 C++ ObjC++ Var(warn_nontemplate_friend) Init(1) Warning
 Warn when non-templatized friend functions are declared within a template.
 
+Wclass-conversion
+C++ ObjC++ Var(warn_class_conversion) Init(1) Warning
+Warn about user-defined conversions converting a class to the wrong type.
+
 Wclass-memaccess
 C++ ObjC++ Var(warn_class_memaccess) Warning LangEnabledBy(C++ ObjC++, Wall)
 Warn for unsafe raw memory writes to objects of class types.
diff --git gcc/cp/decl.c gcc/cp/decl.c
index 503b433cbd1..2d9d56ef6e1 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -13544,7 +13544,7 @@ grok_op_properties (tree decl, bool complain)
   /* Warn about conversion operators that will never be used.  */
   if (IDENTIFIER_CONV_OP_P (name)
   && ! DECL_TEMPLATE_INFO (decl)
-  && warn_conversion)
+  && warn_class_conversion)
 {
   tree t = TREE_TYPE (name);
   int ref = TYPE_REF_P (t);
@@ -13553,27 +13553,29 @@ grok_op_properties (tree decl, bool complain)
t = TYPE_MAIN_VARIANT (TREE_TYPE (t));
 
   if (VOID_TYPE_P (t))
-   warning_at (loc, OPT_Wconversion, "conversion to void "
-   "will never use a type conversion operator");
+   warning_at (loc, OPT_Wclass_conversion, "converting %qT to % "
+   "will never use a type conversion operator", class_type);
   else if (class_type)
{
  if (same_type_ignoring_top_level_qualifiers_p (t, class_type))
-   warning_at (loc, OPT_Wconversion,
+   warning_at (loc, OPT_Wclass_conversion,
ref
-   ? G_("conversion to a reference to the same type "
+   ? G_("converting %qT to a reference to the same type "
 "will never use a type conversion operator")
-   : G_("conversion to the same type "
-"will never use a type conversion operator"));
+   : G_("converting %qT to the same type "
+"will never use a type conversion operator"),
+   class_type);
  /* Don't force t to be complete here.  */
  else if (MAYBE_CLASS_TYPE_P (t)
   && COMPLETE_TYPE_P (t)
   && DERIVED_FROM_P (t, class_type))
-   warning_at (loc, OPT_Wconversion,
+   warning_at (loc, OPT_Wclass_conversion,
ref
-   ? G_("conversion to a reference to a base class "
-"will never use a type conversion operator")
-   : G_("conversion to a base class "
-"will never use a type conversion operator"));
+   ? G_("converting %qT to a reference to a base class "
+"%qT will never use a type conversion operator")
+   : G_("converting %qT to a base class %qT "
+"will never use a type conversion operator"),
+   class_type, t);
}
 }
 
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 685c211e176..26f7031498d 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -237,6 +237,7 @@ in the following sections.
 -Weffc++  -Wstrict-null-sentinel  -Wtemplates @gol
 -Wno-non-template-friend  -Wold-style-cast @gol
 -Woverloaded-virtual  -Wno-pmf-conversions @gol
+-Wno-class-conversion  -Wno-terminate @gol
 -Wsign-promo  -Wvirtual-inheritance}
 
 @item Objective-C and Objective-C++ Language Options
@@ -3367,6 +3368,13 @@ use the STL.  One may also use using directives and 
qualified names.
 @opindex Wno-terminate
 Disable the warning about a throw-expression that will immediately
 result in a call to @code{terminate}.
+
+@item -Wno-class-co

Re: C++ PATCH to add -Wclass-conversion

[Florian Weimer]

Marek Polacek  writes:

> +@item -Wno-class-conversion @r{(C++ and Objective-C++ only)}
> +@opindex Wno-class-conversion
> +@opindex Wclass-conversion
> +Disable the warning about user-defined conversions converting a class to
> +the wrong type, such as having a conversion function converting an
> +object to the same type, to a base class of that type, or to void.
>  @end table

I'm not sure if “the wrong type” is correct in this context because
there is no single wrong type here.

What's the actual problem?  That the user-defined conversion operator
will never be called?

Thanks,
Florian

Re: C++ PATCH to add -Wclass-conversion

[Marek Polacek]

On Wed, Sep 19, 2018 at 09:40:05PM +0200, Florian Weimer wrote:
> Marek Polacek  writes:
> 
> > +@item -Wno-class-conversion @r{(C++ and Objective-C++ only)}
> > +@opindex Wno-class-conversion
> > +@opindex Wclass-conversion
> > +Disable the warning about user-defined conversions converting a class to
> > +the wrong type, such as having a conversion function converting an
> > +object to the same type, to a base class of that type, or to void.
> >  @end table
> 
> I'm not sure if “the wrong type” is correct in this context because
> there is no single wrong type here.

Maybe "to *a* wrong type" then.

> What's the actual problem?  That the user-defined conversion operator
> will never be called?

That such a conversion function will never be called, yes.

Marek

Re: [PATCH 02/14] Add D frontend (GDC) implementation.

[Iain Buclaw]

On 18 September 2018 at 02:33, Iain Buclaw  wrote:
> This patch adds the D front-end implementation, the only part of the
> compiler that interacts with GCC directly, and being the parts that I
> maintain, is something that I can talk about more directly.
>
> For the actual code generation pass, that converts the front-end AST
> to GCC trees, most parts use a separate Visitor interfaces to do a
> certain kind of lowering, for instance, types.cc builds *_TYPE trees
> from AST Type's.  The Visitor class is part of the DMD front-end, and
> is defined in dfrontend/visitor.h.
>
> There are also a few interfaces which have their headers in the DMD
> frontend, but are implemented here because they do something that
> requires knowledge of the GCC backend (d-target.cc), does something
> that may not be portable, or differ between D compilers
> (d-frontend.cc) or are a thin wrapper around something that is managed
> by GCC (d-diagnostic.cc).
>
> Many high level operations result in generation of calls to D runtime
> library functions (runtime.def), all with require some kind of runtime
> type information (typeinfo.cc).  The compiler also generates functions
> for registering/deregistering compiled modules with the D runtime
> library (modules.cc).
>
> As well as the D language having it's own built-in functions
> (intrinsics.cc), we also expose GCC builtins to D code via a
> `gcc.builtins' module (d-builtins.cc), and give special treatment to a
> number of UDAs that could be applied to functions (d-attribs.cc).
>
>
> That is roughly the high level jist of how things are currently organized.
>
> ftp://ftp.gdcproject.org/patches/v4/02-v4-d-frontend-gdc.patch
>

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00587.html

During the last round, the last comment given was that the reviewer
wasn't going to dive deep into this code, as it's essentially
converting between the different representations and is code that I'd
be maintaining.

As this is code that other gcc maintainers will be potentially looking
after as well, I'd like any glaring problems to be dealt with
immediately.

Iain.

Re: [PATCH 03/14] Add D frontend (GDC) changelogs.

[Iain Buclaw]

On 18 September 2018 at 02:34, Iain Buclaw  wrote:
> This patch just includes all changelogs for the D front-end (GDC),
> going back to the dawn of time itself.
>

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00734.html

This was previously ok'd, if I understand right.

Iain.

Re: [PATCH 04/14] Add D front-end (GDC) config, Makefile, and manpages.

[Iain Buclaw]

On 18 September 2018 at 02:34, Iain Buclaw  wrote:
>
> This patch adds the D frontend language configure make files, as described on 
> the anatomy of a language front-end.
>

This is where the last conversation ended up.

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00612.html

I've just noticed that I left one question unanswered.


> So out of curiosity, when multiple sources are specified on the command
> line, are they subject to IPA as a group or are they handled individually?

They are subject as a group, the compiler proper is only invoked once
with all source files passed to it.

Iain.

Re: C++ PATCH to add -Wclass-conversion

[Jason Merrill]

On Wed, Sep 19, 2018 at 3:44 PM, Marek Polacek  wrote:
> On Wed, Sep 19, 2018 at 09:40:05PM +0200, Florian Weimer wrote:
>> Marek Polacek  writes:
>>
>> > +@item -Wno-class-conversion @r{(C++ and Objective-C++ only)}
>> > +@opindex Wno-class-conversion
>> > +@opindex Wclass-conversion
>> > +Disable the warning about user-defined conversions converting a class to
>> > +the wrong type, such as having a conversion function converting an
>> > +object to the same type, to a base class of that type, or to void.
>> >  @end table
>>
>> I'm not sure if “the wrong type” is correct in this context because
>> there is no single wrong type here.
>
> Maybe "to *a* wrong type" then.
>
>> What's the actual problem?  That the user-defined conversion operator
>> will never be called?
>
> That such a conversion function will never be called, yes.

And that's what the documentation should say, rather than the vague "wrong".

Jason

Re: [PATCH 05/14] Add GCC configuration file changes and documentation.

[Iain Buclaw]

On 18 September 2018 at 02:35, Iain Buclaw  wrote:
>
> This patch adds the D language front-end to GCC documentation and 
> configuration files, as described on the anatomy of a language front-end.
>

It looks like this was previously ok'd, with reason as it's mostly
auto-generated boilerplate.

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00592.html

Iain.

Re: [PATCH 06/14] Add patches for D language support in GCC proper.

[Iain Buclaw]

On 18 September 2018 at 02:35, Iain Buclaw  wrote:
>
> This patch adds D language support to GCC itself.
>

Likewise, this was approved so long as all prerequisites have been
approved also.

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00609.html

Iain.

Re: C++ PATCH to add -Wclass-conversion

[Marek Polacek]

On Wed, Sep 19, 2018 at 04:14:25PM -0400, Jason Merrill wrote:
> On Wed, Sep 19, 2018 at 3:44 PM, Marek Polacek  wrote:
> > On Wed, Sep 19, 2018 at 09:40:05PM +0200, Florian Weimer wrote:
> >> Marek Polacek  writes:
> >>
> >> > +@item -Wno-class-conversion @r{(C++ and Objective-C++ only)}
> >> > +@opindex Wno-class-conversion
> >> > +@opindex Wclass-conversion
> >> > +Disable the warning about user-defined conversions converting a class to
> >> > +the wrong type, such as having a conversion function converting an
> >> > +object to the same type, to a base class of that type, or to void.
> >> >  @end table
> >>
> >> I'm not sure if “the wrong type” is correct in this context because
> >> there is no single wrong type here.
> >
> > Maybe "to *a* wrong type" then.
> >
> >> What's the actual problem?  That the user-defined conversion operator
> >> will never be called?
> >
> > That such a conversion function will never be called, yes.
> 
> And that's what the documentation should say, rather than the vague "wrong".

How about this then?

2018-09-19  Marek Polacek  

Add -Wclass-conversion.
* c.opt (Wclass-conversion): New.

* decl.c (grok_op_properties): Change a warning from -Wconversion to
-Wclass-conversion.  Make it print the types.

* doc/invoke.texi: Document -Wclass-conversion.

* g++.dg/conversion/op4.C: Add dg-warning.
* g++.dg/warn/Wclass-conversion1.C: New test.
* g++.dg/warn/Wclass-conversion2.C: New test.
* g++.dg/warn/Wconversion5.C: Remove file.
* g++.dg/warn/conversion-function-1.C: Use -Wno-class-converison.
* g++.old-deja/g++.bugs/900215_01.C: Adjust dg-warning.
* g++.old-deja/g++.jason/conversion5.C: Likewise.

diff --git gcc/c-family/c.opt gcc/c-family/c.opt
index 092ec940d86..43d1d27ac00 100644
--- gcc/c-family/c.opt
+++ gcc/c-family/c.opt
@@ -850,6 +850,10 @@ Wnon-template-friend
 C++ ObjC++ Var(warn_nontemplate_friend) Init(1) Warning
 Warn when non-templatized friend functions are declared within a template.
 
+Wclass-conversion
+C++ ObjC++ Var(warn_class_conversion) Init(1) Warning
+Warn when a conversion function will never be called due to the type it 
converts to.
+
 Wclass-memaccess
 C++ ObjC++ Var(warn_class_memaccess) Warning LangEnabledBy(C++ ObjC++, Wall)
 Warn for unsafe raw memory writes to objects of class types.
diff --git gcc/cp/decl.c gcc/cp/decl.c
index 503b433cbd1..2d9d56ef6e1 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -13544,7 +13544,7 @@ grok_op_properties (tree decl, bool complain)
   /* Warn about conversion operators that will never be used.  */
   if (IDENTIFIER_CONV_OP_P (name)
   && ! DECL_TEMPLATE_INFO (decl)
-  && warn_conversion)
+  && warn_class_conversion)
 {
   tree t = TREE_TYPE (name);
   int ref = TYPE_REF_P (t);
@@ -13553,27 +13553,29 @@ grok_op_properties (tree decl, bool complain)
t = TYPE_MAIN_VARIANT (TREE_TYPE (t));
 
   if (VOID_TYPE_P (t))
-   warning_at (loc, OPT_Wconversion, "conversion to void "
-   "will never use a type conversion operator");
+   warning_at (loc, OPT_Wclass_conversion, "converting %qT to % "
+   "will never use a type conversion operator", class_type);
   else if (class_type)
{
  if (same_type_ignoring_top_level_qualifiers_p (t, class_type))
-   warning_at (loc, OPT_Wconversion,
+   warning_at (loc, OPT_Wclass_conversion,
ref
-   ? G_("conversion to a reference to the same type "
+   ? G_("converting %qT to a reference to the same type "
 "will never use a type conversion operator")
-   : G_("conversion to the same type "
-"will never use a type conversion operator"));
+   : G_("converting %qT to the same type "
+"will never use a type conversion operator"),
+   class_type);
  /* Don't force t to be complete here.  */
  else if (MAYBE_CLASS_TYPE_P (t)
   && COMPLETE_TYPE_P (t)
   && DERIVED_FROM_P (t, class_type))
-   warning_at (loc, OPT_Wconversion,
+   warning_at (loc, OPT_Wclass_conversion,
ref
-   ? G_("conversion to a reference to a base class "
-"will never use a type conversion operator")
-   : G_("conversion to a base class "
-"will never use a type conversion operator"));
+   ? G_("converting %qT to a reference to a base class "
+"%qT will never use a type conversion operator")
+   : G_("converting %qT to a base class %qT "
+"will never use a type conversion operator"),
+   class_type, t);
}
 }
 

Re: [PATCH 07/14] Add patches for D language support in GCC targets.

[Iain Buclaw]

On 18 September 2018 at 02:35, Iain Buclaw  wrote:
>
> This patch add D language support to targets of GCC itself.
>
> These are used to declare pre-defined version identifiers in the D
> language that describe something about the target that the front-end
> itself is unable to obtain.  Version conditions in D can be thought of
> as being like the target macros of C, but that where the similarity
> ends.

https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00270.html

Only the ARM and Aarch64 backends have been checked so far, and have
been fixed up as requested.

Iain.

Re: [PATCH 09/14] Add D2 Testsuite Dejagnu files.

[Iain Buclaw]

On 18 September 2018 at 02:36, Iain Buclaw  wrote:
>
> This patch adds D language support to the GCC testsuite.
>
> As well as generating the DejaGNU options for compile and link tests,
> handles the conversion from DMD-style compiler options to GDC.

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00112.html

I take it from the comment in the last review, that I can self-approve
this, and the other testsuite related patches.

Correct me if I'm mistaken.

Iain.

Re: [PATCH 11/14] D runtime library and license.

[Iain Buclaw]

On 18 September 2018 at 02:37, Iain Buclaw  wrote:
> This patch adds the D runtime library and license (Boost) files.  D
> runtime is a low level that implements the building blocks of the
> runtime environment, as well as C and C++ platform bindings.  Many
> high level operations are lowered to generate calls to various
> functions defined in this library.
>
> ftp://ftp.gdcproject.org/patches/v4/11-v4-d-runtime-library.patch
>

https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00029.html

Same as the dmd front end here, we are strictly downstream and no one
should be maintaining any of the sources in this patch.

Any submitted changes would be appropriately redirected to the
repository were its maintained.

Iain.

Re: [PATCH 12/14] Add GDC/GCC builtins and runtime support (part of D runtime)

[Iain Buclaw]

On 18 September 2018 at 02:37, Iain Buclaw  wrote:
> This patch adds GCC builtins and runtime support for GDC compiled code.
>
>   - module __entrypoint defines the C main function.  Its contents are
> parsed and compiled in during compilation, but only if needed.
>   - module gcc.attribute exposes GDC-specific attributes.
>   - module gcc.backtrace implements backtrace support for GDC.
>   - module gcc.builtins exposes GCC builtins to D code.
>   - module gcc.config exposes things determined at configure time to D code.
>   - module gcc.deh implements D unwind EH.
>   - module gcc.libbacktrace defines C bindings to libbacktrace.
>   - module gcc.unwind defines C bindings to libgcc unwind library.
>   - libgphobos.spec contains a list of libraries to link in that are
> dependencies of D runtime and/or the Phobos standard library.  It is
> used by the GDC driver.
>

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00735.html

It looks like this patch was previously approved.  All sources here
are linked as part of druntime, but would be maintained in tree by
myself and other D front end maintainers.

Iain.

Re: [PATCH 13/14] Add D Phobos standard library and license.

[Iain Buclaw]

On 18 September 2018 at 02:38, Iain Buclaw  wrote:
> This patch add the Phobos runtime library and license (Boost) files.
> Phobos is the standard runtime library that comes with the D language
> compiler.  The bulk of which is comprised mostly of generic algorithms
> and high level primitives for D applications.
>
> ftp://ftp.gdcproject.org/patches/v4/13-v4-d-phobos-library.patch
>

As far as I can tell, no one has made a comment on this yet.  But FYI,
all sources here are strictly downstream, same as dmd front end and
druntime patches.

Iain.

Re: [PATCH] PR libstdc++/78179 run long double tests separately

[Christophe Lyon]

On Mon, 3 Sep 2018 at 16:54, Jonathan Wakely  wrote:
>
> Split the long double testing into a separate file, so that we can XFAIL
> targets where the long double precision doesn't meet the expected
> tolerances. The float and double tests are still expefted to PASS for
> all targets.
>
> PR libstdc++/78179
> * testsuite/26_numerics/headers/cmath/hypot-long-double.cc: New test
> that runs the long double part of hypot.cc.
> * testsuite/26_numerics/headers/cmath/hypot.cc: Disable long double
> tests unless TEST_HYPOT_LONG_DOUBLE is defined.
>
> Tested x86_64-linux, committed to trunk.
>

Hi,

I have noticed failures on hypot-long-double.cc on arm, so I suggest we add:

diff --git 
a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
index 8a05473..4c2e33b 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
@@ -17,7 +17,7 @@

 // { dg-options "-std=gnu++17" }
 // { dg-do run { target c++17 } }
-// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux* nios2-*-* } }
+// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
nios2-*-* arm*-*-* } }

 // Run the long double tests from hypot.cc separately, because they fail on a
 // number of targets. See PR libstdc++/78179 for details.

OK?

Christophe

Re: [PATCH] PR libstdc++/78179 run long double tests separately

[Rainer Orth]

Hi Christophe,

> I have noticed failures on hypot-long-double.cc on arm, so I suggest we add:
>
> diff --git
> a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> index 8a05473..4c2e33b 100644
> --- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> +++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> @@ -17,7 +17,7 @@
>
>  // { dg-options "-std=gnu++17" }
>  // { dg-do run { target c++17 } }
> -// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux* nios2-*-* } 
> }
> +// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
> nios2-*-* arm*-*-* } }
>
>  // Run the long double tests from hypot.cc separately, because they fail on a
>  // number of targets. See PR libstdc++/78179 for details.
>
> OK?

just a nit (and not a review): I'd prefer the target list to be sorted
alphabetically, not completely random.

Thanks.
Rainer

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

Re: [PATCH 08/25] Fix co-array allocation

[Damian Rouson]

Has this been tested in multi-image execution using OpenCoarrays?   If not,
I would be glad to assist with installing OpenCoarrays so that it can be
part of the testing process.

On a related note, two Sourcery Institute developers have attempted to edit
the GCC build system to make the downloading and building of OpenCoarrays
automatically part of the gfortran build process.  Neither developer
succeeded.  If anyone has any interest in figuring out how to do this, it
will prevent a lot of potential regressions when single-image testing
doesn't expose issues that only arise with multi-image execution.

Damian

On Wed, Sep 19, 2018 at 9:25 AM Andrew Stubbs  wrote:

> On 05/09/18 19:07, Janne Blomqvist wrote:
> > The argument must be of type size_type_node, not sizetype. Please instead
> > use
> >
> > size = build_zero_cst (size_type_node);
> >
> >
> >>  * trans-intrinsic.c (conv_intrinsic_event_query): Convert
> computed
> >>  index to a size_t type.
> >>
> >
> > Using integer_type_node is wrong, but the correct type for calculating
> > array indices (lbound, ubound,  etc.) is not size_type_node but rather
> > gfc_array_index_type (which in practice maps to ptrdiff_t). So please use
> > that, and then fold_convert index to size_type_node just before
> generating
> > the call to event_query.
> >
> >
> >>  * trans-stmt.c (gfc_trans_event_post_wait): Likewise.
> >>
> >
> > Same here as above.
>
> How is the attached? I retested and found no regressions.
>
> Andrew
>

Re: [openacc] Teach gfortran to lower OpenACC routine dims

[Bernhard Reutner-Fischer]

On Wed, 5 Sep 2018 12:52:03 -0700
Cesar Philippidis  wrote:

> At present, gfortran does not encode the gang, worker or vector
> parallelism clauses when it creates acc routines dim attribute for
> subroutines and functions. While support for acc routine is lacking in
> other areas in gfortran (including modules), this patch is important
> because it encodes the parallelism attributes using the same function
> as the C and C++ FEs. This will become important with the forthcoming
> nvptx vector length extensions, because large vectors are not
> supported in acc routines yet.
> 
> Is this OK for trunk? I regtested and bootstrapped for x86_64 with
> nvptx offloading.

> diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
> index 94a7f7eaa50..d48c9351e25 100644
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -2234,34 +2234,45 @@ gfc_match_oacc_cache (void)
>return MATCH_YES;
>  }
>  
> -/* Determine the loop level for a routine.   */
> +/* Determine the loop level for a routine.  Returns
> OACC_FUNCTION_NONE
> +   if any error is detected.  */
>  
> -static int
> +static oacc_function
>  gfc_oacc_routine_dims (gfc_omp_clauses *clauses)
>  {
>int level = -1;
> +  oacc_function ret = OACC_FUNCTION_AUTO;
>  
>if (clauses)
>  {
>unsigned mask = 0;
>  
>if (clauses->gang)
> - level = GOMP_DIM_GANG, mask |= GOMP_DIM_MASK (level);
> + {
> +   level = GOMP_DIM_GANG, mask |= GOMP_DIM_MASK (level);
> +   ret = OACC_FUNCTION_GANG;
> + }
>if (clauses->worker)
> - level = GOMP_DIM_WORKER, mask |= GOMP_DIM_MASK (level);
> + {
> +   level = GOMP_DIM_WORKER, mask |= GOMP_DIM_MASK (level);
> +   ret = OACC_FUNCTION_WORKER;
> + }
>if (clauses->vector)
> - level = GOMP_DIM_VECTOR, mask |= GOMP_DIM_MASK (level);
> + {
> +   level = GOMP_DIM_VECTOR, mask |= GOMP_DIM_MASK (level);
> +   ret = OACC_FUNCTION_VECTOR;
> + }
>if (clauses->seq)
> - level = GOMP_DIM_MAX, mask |= GOMP_DIM_MASK (level);
> + {
> +   level = GOMP_DIM_MAX, mask |= GOMP_DIM_MASK (level);
> +   ret = OACC_FUNCTION_SEQ;
> + }
>  
>if (mask != (mask & -mask))
> - gfc_error ("Multiple loop axes specified for routine");
> + ret = OACC_FUNCTION_NONE;
>  }
>  
> -  if (level < 0)
> -level = GOMP_DIM_MAX;
> -
> -  return level;
> +  return ret;
>  }
>  
>  match
> @@ -2272,6 +2283,8 @@ gfc_match_oacc_routine (void)
>match m;
>gfc_omp_clauses *c = NULL;
>gfc_oacc_routine_name *n = NULL;
> +  oacc_function dims = OACC_FUNCTION_NONE;

Unneeded initialisation of dims.

> +  bool seen_error = false;
>  
>old_loc = gfc_current_locus;
>  
> @@ -2318,17 +2331,15 @@ gfc_match_oacc_routine (void)
>   }
>else
>  {
> -   gfc_error ("Syntax error in !$ACC ROUTINE ( NAME ) at %C");
> -   gfc_current_locus = old_loc;
> -   return MATCH_ERROR;
> +   gfc_error ("Syntax error in !$ACC ROUTINE ( NAME ) at %L",
> &old_loc);
> +   goto cleanup;
>   }
>  
>if (gfc_match_char (')') != MATCH_YES)
>   {
> -   gfc_error ("Syntax error in !$ACC ROUTINE ( NAME ) at %C,
> expecting"
> -  " ')' after NAME");
> -   gfc_current_locus = old_loc;
> -   return MATCH_ERROR;
> +   gfc_error ("Syntax error in !$ACC ROUTINE ( NAME ) at %L,
> expecting"
> +  " ')' after NAME", &old_loc);
> +   goto cleanup;
>   }
>  }
>  
> @@ -2337,26 +2348,83 @@ gfc_match_oacc_routine (void)
> != MATCH_YES))
>  return MATCH_ERROR;
>  
> +  /* Scan for invalid routine geometry.  */
> +  dims = gfc_oacc_routine_dims (c);
> +  if (dims == OACC_FUNCTION_NONE)
> +{
> +  gfc_error ("Multiple loop axes specified in !$ACC ROUTINE at
> %L",
> +  &old_loc);
> +
> +  /* Don't abort early, because it's important to let the user
> +  know of any potential duplicate routine directives.  */
> +  seen_error = true;
> +}
> +  else if (dims == OACC_FUNCTION_AUTO)
> +{
> +  gfc_warning (0, "Expected one of %, %,
> % or "
> +"% clauses in !$ACC ROUTINE at %L",
> &old_loc);
> +  dims = OACC_FUNCTION_SEQ;
> +}
> +
>if (sym != NULL)
>  {
> -  n = gfc_get_oacc_routine_name ();
> -  n->sym = sym;
> -  n->clauses = NULL;
> -  n->next = NULL;
> -  if (gfc_current_ns->oacc_routine_names != NULL)
> - n->next = gfc_current_ns->oacc_routine_names;
> -
> -  gfc_current_ns->oacc_routine_names = n;
> +  bool needs_entry = true;
> +
> +  /* Scan for any repeated routine directives on 'sym' and report
> +  an error if necessary.  TODO: Extend this function to scan
> +  for compatible DEVICE_TYPE dims.  */
> +  for (n = gfc_current_ns->oacc_routine_names; n; n = n->next)
> + if (n->sym == sym)
> +   {
> + needs_entry = false;
> + if (dims != gfc_oacc_routine_dims (n->clauses))
> +   {
> +

Re: [PATCH 08/25] Fix co-array allocation

[Andrew Stubbs]

On 19/09/18 22:18, Damian Rouson wrote:
Has this been tested in multi-image execution using OpenCoarrays?   If 
not, I would be glad to assist with installing OpenCoarrays so that it 
can be part of the testing process.


It's been tested with the GCC testsuite -- the same suite that found the 
issue in the first place.


If you want to port your tool to GCN that would be cool, but I suspect 
non-trivial.


On a related note, two Sourcery Institute developers have attempted to 
edit the GCC build system to make the downloading and building of 
OpenCoarrays automatically part of the gfortran build process.  Neither 
developer succeeded.  If anyone has any interest in figuring out how to 
do this, it will prevent a lot of potential regressions when 
single-image testing doesn't expose issues that only arise with 
multi-image execution.


I suggest you post this question in a fresh thread.

Andrew

[PATCH,FORTRAN v2] Use stringpool on loading module symbols

[Bernhard Reutner-Fischer]

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

2018-09-19  Bernhard Reutner-Fischer  

* class.c (generate_finalization_wrapper, gfc_find_derived_vtab,
find_intrinsic_vtab): Set module if in module context.
* decl.c (gfc_match_decl_type_spec): Likewise.
(match_procedure_decl, match_ppc_decl): Flag interface function
as artificial.
* resolve.c (check_proc_interface): Do not warn about missing
explicit interface for artificial interface functions.
* module.c (free_pi_tree): Do not free true_name nor module.
(parse_string): Avoid needless reallocation.
(read_string): Delete.
(read_module): Use stringpool when generating symbols and module
names.
(mio_symtree_ref): Use stringpool for module.
(mio_omp_udr_expr): Likewise.
(load_needed): Use stringpool for module and symbol name.
(find_symbols_to_write): Fix indentation.
---
 gcc/fortran/class.c   | 18 -
 gcc/fortran/decl.c|  8 
 gcc/fortran/module.c  | 92 +++
 gcc/fortran/resolve.c |  2 +-
 4 files changed, 65 insertions(+), 55 deletions(-)

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 33c772c6eba..370b6387744 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -1641,6 +1641,8 @@ generate_finalization_wrapper (gfc_symbol *derived, 
gfc_namespace *ns,
   array->as->type = AS_ASSUMED_RANK;
   array->as->rank = -1;
   array->attr.intent = INTENT_INOUT;
+  if (ns->proc_name->attr.flavor == FL_MODULE)
+array->module = ns->proc_name->name;
   gfc_set_sym_referenced (array);
   final->formal = gfc_get_formal_arglist ();
   final->formal->sym = array;
@@ -1654,6 +1656,8 @@ generate_finalization_wrapper (gfc_symbol *derived, 
gfc_namespace *ns,
   byte_stride->attr.dummy = 1;
   byte_stride->attr.value = 1;
   byte_stride->attr.artificial = 1;
+  if (ns->proc_name->attr.flavor == FL_MODULE)
+byte_stride->module = ns->proc_name->name;
   gfc_set_sym_referenced (byte_stride);
   final->formal->next = gfc_get_formal_arglist ();
   final->formal->next->sym = byte_stride;
@@ -1667,6 +1671,8 @@ generate_finalization_wrapper (gfc_symbol *derived, 
gfc_namespace *ns,
   fini_coarray->attr.dummy = 1;
   fini_coarray->attr.value = 1;
   fini_coarray->attr.artificial = 1;
+  if (ns->proc_name->attr.flavor == FL_MODULE)
+fini_coarray->module = ns->proc_name->name;
   gfc_set_sym_referenced (fini_coarray);
   final->formal->next->next = gfc_get_formal_arglist ();
   final->formal->next->next->sym = fini_coarray;
@@ -2432,7 +2438,9 @@ gfc_find_derived_vtab (gfc_symbol *derived)
  src->attr.flavor = FL_VARIABLE;
  src->attr.dummy = 1;
  src->attr.artificial = 1;
- src->attr.intent = INTENT_IN;
+ src->attr.intent = INTENT_IN;
+ if (ns->proc_name->attr.flavor == FL_MODULE)
+   src->module = sub_ns->proc_name->name;
  gfc_set_sym_referenced (src);
  copy->formal = gfc_get_formal_arglist ();
  copy->formal->sym = src;
@@ -2443,6 +2451,8 @@ gfc_find_derived_vtab (gfc_symbol *derived)
  dst->attr.dummy = 1;
  dst->attr.artificial = 1;
  dst->attr.intent = INTENT_INOUT;
+ if (ns->proc_name->attr.flavor == FL_MODULE)
+   dst->module = sub_ns->proc_name->name;
  gfc_set_sym_referenced (dst);
  copy->formal->next = gfc_get_formal_arglist ();
  copy->formal->next->sym = dst;
@@ -2761,7 +2771,7 @@ find_intrinsic_vtab (gfc_typespec *ts)
  copy->attr.elemental = 1;
  if (ns->proc_name->attr.flavor == FL_MODULE)
copy->module = ns->proc_name->name;
- gfc_set_sym_referenced (copy);
+ gfc_set_sym_referenced (copy);
  /* Set up formal arguments.  */
  gfc_get_symbol (gfc_get_string ("%s", "src"), sub_ns, &src);
  src->ts.type = ts->type;
@@ -2769,6 +2779,8 @@ find_intrinsic_vtab (gfc_typespec *ts)
  src->attr.flavor = FL_VARIABLE;
  src->attr.dummy = 1;
  src->attr.intent = INTENT_IN;
+ if (ns->proc_name->attr.flavor == FL_MODULE)
+   src->module = sub_ns->proc_name->name;
  gfc_set_sym_referenced (src);
  copy->formal = gfc_get_formal_arglist ();
  copy->formal->sym = src;
@@ -2778,6 +2790,8 @@ find_intrinsic_vtab (gfc_typespec *ts)
  dst->attr.flavor = FL_VARIABLE;
  dst->attr.dummy = 1;
  dst->attr.intent = INTENT_INOUT;
+ if (ns->proc_name->attr.flavor == FL_MODULE)
+   dst->module = sub_ns->proc_name->name;
  gfc_set_sym_referenced (dst);
  copy->formal->next = gfc_get_formal_arglist ();
  copy->fo

Re: [PATCH 08/25] Fix co-array allocation

[Damian Rouson]

On Wed, Sep 19, 2018 at 3:30 PM Andrew Stubbs  wrote:

>
> If you want to port your tool to GCN that would be cool, but I suspect
> non-trivial.
>

To clarify, OpenCoarrays is not a tool.  It is the parallel ABI required to
create executable programs capable of executing in multiple images as
required by the Fortran 2008 standard.  Multi-image execution is the reason
coarray features exist so I hope the maintainers won't approve a patch that
impacts coarray features but has not been tested against OpenCoarrays,
which has its own test suite.  Again, I would be glad to assist with
installing OpenCoarrays on your system. Whether it's trivial or not, it's
essential to protect against breaking a large feature set that is part of
Fortran 2008 and 2018.

Damian

Re: C++ PATCH to add -Wclass-conversion

[Jason Merrill]

On Wed, Sep 19, 2018 at 4:25 PM, Marek Polacek  wrote:
> On Wed, Sep 19, 2018 at 04:14:25PM -0400, Jason Merrill wrote:
>> On Wed, Sep 19, 2018 at 3:44 PM, Marek Polacek  wrote:
>> > On Wed, Sep 19, 2018 at 09:40:05PM +0200, Florian Weimer wrote:
>> >> Marek Polacek  writes:
>> >>
>> >> > +@item -Wno-class-conversion @r{(C++ and Objective-C++ only)}
>> >> > +@opindex Wno-class-conversion
>> >> > +@opindex Wclass-conversion
>> >> > +Disable the warning about user-defined conversions converting a class 
>> >> > to
>> >> > +the wrong type, such as having a conversion function converting an
>> >> > +object to the same type, to a base class of that type, or to void.
>> >> >  @end table
>> >>
>> >> I'm not sure if “the wrong type” is correct in this context because
>> >> there is no single wrong type here.
>> >
>> > Maybe "to *a* wrong type" then.
>> >
>> >> What's the actual problem?  That the user-defined conversion operator
>> >> will never be called?
>> >
>> > That such a conversion function will never be called, yes.
>>
>> And that's what the documentation should say, rather than the vague "wrong".
>
> How about this then?

Looks good, the patch is OK.

Jason

Re: [committed] hppa: Revise atomic support to use sync barrier

[John David Anglin]

On 2018-08-11 6:17 PM, John David Anglin wrote:
It recently came to my attention that PA 2.0 supports out-of-order 
execution for loads and
stores.  Loads and stores are strongly ordered on PA 1.x.  This has 
caused no end of confusion.


This out-of-order execution is discussed in the following article:
http://web.archive.org/web/20040214092531/http://www.cpus.hp.com/technical_references/advperf.shtml 



This patch defines a new barrier pattern to enforce ordering of memory 
accesses.


The existing atomic patterns have been removed from pa.md except for 
atomic_loaddi and atomic_storedi
which use floating point double instructions.  The defaults are okay 
when combined with the new barrier.


Since we want PA 1.x code to be PA 2.0 compatible, it gets the barrier 
as well.


The linux atomic support is modified to use the new barrier in the 
lock release code.  This should improve

performance.

Tested on hppa-unknown-linux-gnu.  Committed to trunk.  Probably, I 
will backport the change once the

change receives more testing.
This patch partially reverts the above change.  I should not have 
removed the integer atomic store patterns.


We need to use the kernel compare and swap helper for atomic stores on 
linux as the compare and swap
operation is synthesized and a store in the middle of this operation can 
be lost.  It should occur either

before or after the operation.

Tested on hppa-unknown-linux-gnu.  Committed to active branches.

Dave

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

2018-09-19  John David Anglin  

* config/pa/pa.md (atomic_storeqi): Restore deleted expander.
(atomic_storehi): Likewise.
(atomic_storesi): Likewise.
(atomic_loaddi): Restore compare and swap exchange loop code.

Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 264413)
+++ config/pa/pa.md (working copy)
@@ -9958,8 +9958,60 @@
 
 ;; These patterns are at the bottom so the non atomic versions are preferred.
 
-;; Implement atomic DImode load using 64-bit floating point load.
+(define_expand "atomic_storeqi"
+  [(match_operand:QI 0 "memory_operand");; memory
+   (match_operand:QI 1 "register_operand")  ;; val out
+   (match_operand:SI 2 "const_int_operand")];; model
+  ""
+{
+  if (TARGET_SYNC_LIBCALL)
+{
+  rtx mem = operands[0];
+  rtx val = operands[1];
+  if (pa_maybe_emit_compare_and_swap_exchange_loop (NULL_RTX, mem, val))
+   DONE;
+}
+  FAIL;
+})
 
+;; Implement atomic HImode stores using exchange.
+
+(define_expand "atomic_storehi"
+  [(match_operand:HI 0 "memory_operand");; memory
+   (match_operand:HI 1 "register_operand")  ;; val out
+   (match_operand:SI 2 "const_int_operand")];; model
+  ""
+{
+  if (TARGET_SYNC_LIBCALL)
+{
+  rtx mem = operands[0];
+  rtx val = operands[1];
+  if (pa_maybe_emit_compare_and_swap_exchange_loop (NULL_RTX, mem, val))
+   DONE;
+}
+  FAIL;
+})
+
+;; Implement atomic SImode store using exchange.
+
+(define_expand "atomic_storesi"
+  [(match_operand:SI 0 "memory_operand");; memory
+   (match_operand:SI 1 "register_operand")  ;; val out
+   (match_operand:SI 2 "const_int_operand")];; model
+  ""
+{
+  if (TARGET_SYNC_LIBCALL)
+{
+  rtx mem = operands[0];
+  rtx val = operands[1];
+  if (pa_maybe_emit_compare_and_swap_exchange_loop (NULL_RTX, mem, val))
+   DONE;
+}
+  FAIL;
+})
+
+;; Implement atomic DImode load.
+
 (define_expand "atomic_loaddi"
   [(match_operand:DI 0 "register_operand")  ;; val out
(match_operand:DI 1 "memory_operand");; memory
@@ -,6 +10051,14 @@
 {
   enum memmodel model;
 
+  if (TARGET_SYNC_LIBCALL)
+{
+  rtx mem = operands[0];
+  rtx val = operands[1];
+  if (pa_maybe_emit_compare_and_swap_exchange_loop (NULL_RTX, mem, val))
+   DONE;
+}
+
   if (TARGET_64BIT || TARGET_DISABLE_FPREGS || TARGET_SOFT_FLOAT)
 FAIL;
 

[PATCH] hppa: Remove TARGET_SCHED_ADJUST_PRIORITY hook

[John David Anglin]

On 2018-09-06 1:05 PM, Jeff Law wrote:

Anyway, the patch is fine.  Your call if you want to just kill the code
in the target file, it's just not terribly important anymore.

The attached patch removes the TARGET_SCHED_ADJUST_PRIORITY hook.

Tested on hppa-unknown-linux-gnu.  Committed to trunk.

Dave

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

2018-09-19  John David Anglin  

* config/pa/pa.c (pa_adjust_priority): Delete.
(TARGET_SCHED_ADJUST_PRIORITY): Delete define.

Index: config/pa/pa.c
===
--- config/pa/pa.c  (revision 264168)
+++ config/pa/pa.c  (working copy)
@@ -122,7 +122,6 @@
 static void update_total_code_bytes (unsigned int);
 static void pa_output_function_epilogue (FILE *);
 static int pa_adjust_cost (rtx_insn *, int, rtx_insn *, int, unsigned int);
-static int pa_adjust_priority (rtx_insn *, int);
 static int pa_issue_rate (void);
 static int pa_reloc_rw_mask (void);
 static void pa_som_asm_init_sections (void) ATTRIBUTE_UNUSED;
@@ -280,8 +279,6 @@
 
 #undef TARGET_SCHED_ADJUST_COST
 #define TARGET_SCHED_ADJUST_COST pa_adjust_cost
-#undef TARGET_SCHED_ADJUST_PRIORITY
-#define TARGET_SCHED_ADJUST_PRIORITY pa_adjust_priority
 #undef TARGET_SCHED_ISSUE_RATE
 #define TARGET_SCHED_ISSUE_RATE pa_issue_rate
 
@@ -4995,37 +4992,6 @@
 }
 }
 
-/* Adjust scheduling priorities.  We use this to try and keep addil
-   and the next use of %r1 close together.  */
-static int
-pa_adjust_priority (rtx_insn *insn, int priority)
-{
-  rtx set = single_set (insn);
-  rtx src, dest;
-  if (set)
-{
-  src = SET_SRC (set);
-  dest = SET_DEST (set);
-  if (GET_CODE (src) == LO_SUM
- && symbolic_operand (XEXP (src, 1), VOIDmode)
- && ! read_only_operand (XEXP (src, 1), VOIDmode))
-   priority >>= 3;
-
-  else if (GET_CODE (src) == MEM
-  && GET_CODE (XEXP (src, 0)) == LO_SUM
-  && symbolic_operand (XEXP (XEXP (src, 0), 1), VOIDmode)
-  && ! read_only_operand (XEXP (XEXP (src, 0), 1), VOIDmode))
-   priority >>= 1;
-
-  else if (GET_CODE (dest) == MEM
-  && GET_CODE (XEXP (dest, 0)) == LO_SUM
-  && symbolic_operand (XEXP (XEXP (dest, 0), 1), VOIDmode)
-  && ! read_only_operand (XEXP (XEXP (dest, 0), 1), VOIDmode))
-   priority >>= 3;
-}
-  return priority;
-}
-
 /* The 700 can only issue a single insn at a time.
The 7XXX processors can issue two insns at a time.
The 8000 can issue 4 insns at a time.  */

C++ PATCH to refine c++/87109 patch

[Marek Polacek]

Aaaand this addresses ,
as I promised earlier.  I hope I got it right.

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

2018-09-19  Marek Polacek  

PR c++/87109 - wrong ctor with maybe-rvalue semantics.
* call.c (build_user_type_conversion_1): Refine the maybe-rvalue
check to only return if we're converting from a base class.

* g++.dg/cpp0x/ref-qual19.C: Adjust the expected results.
* g++.dg/cpp0x/ref-qual20.C: New test.

diff --git gcc/cp/call.c gcc/cp/call.c
index ddf0ed044a0..4bbd77b9cef 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -4034,9 +4034,13 @@ build_user_type_conversion_1 (tree totype, tree expr, 
int flags,
 conv->bad_p = true;
 
   /* We're performing the maybe-rvalue overload resolution and
- a conversion function is in play.  This isn't going to work
- because we would not end up with a suitable constructor.  */
-  if ((flags & LOOKUP_PREFER_RVALUE) && !DECL_CONSTRUCTOR_P (cand->fn))
+ a conversion function is in play.  If we're converting from
+ a base class to a derived class, reject the conversion.  */
+  if ((flags & LOOKUP_PREFER_RVALUE)
+  && !DECL_CONSTRUCTOR_P (cand->fn)
+  && CLASS_TYPE_P (fromtype)
+  && CLASS_TYPE_P (totype)
+  && DERIVED_FROM_P (fromtype, totype))
 return NULL;
 
   /* Remember that this was a list-initialization.  */
diff --git gcc/testsuite/g++.dg/cpp0x/ref-qual19.C 
gcc/testsuite/g++.dg/cpp0x/ref-qual19.C
index 8494b83e5b0..50f92977c49 100644
--- gcc/testsuite/g++.dg/cpp0x/ref-qual19.C
+++ gcc/testsuite/g++.dg/cpp0x/ref-qual19.C
@@ -85,13 +85,13 @@ int
 main ()
 {
   C c1 = f (A());
-  if (c1.i != 1)
+  if (c1.i != 2)
 __builtin_abort ();
   C c2 = f2 (A());
   if (c2.i != 2)
 __builtin_abort ();
   C c3 = f3 ();
-  if (c3.i != 1)
+  if (c3.i != 2)
 __builtin_abort ();
   C c4 = f4 ();
   if (c4.i != 2)
@@ -100,13 +100,13 @@ main ()
   if (c5.i != 2)
 __builtin_abort ();
   D c6 = f6 (B());
-  if (c6.i != 3)
+  if (c6.i != 4)
 __builtin_abort ();
   D c7 = f7 (B());
   if (c7.i != 4)
 __builtin_abort ();
   D c8 = f8 ();
-  if (c8.i != 3)
+  if (c8.i != 4)
 __builtin_abort ();
   D c9 = f9 ();
   if (c9.i != 4)
diff --git gcc/testsuite/g++.dg/cpp0x/ref-qual20.C 
gcc/testsuite/g++.dg/cpp0x/ref-qual20.C
index e69de29bb2d..49c10564c11 100644
--- gcc/testsuite/g++.dg/cpp0x/ref-qual20.C
+++ gcc/testsuite/g++.dg/cpp0x/ref-qual20.C
@@ -0,0 +1,73 @@
+// PR c++/87109
+// { dg-do run { target c++11 } }
+
+#include 
+
+struct A;
+
+struct B {
+  int i;
+  B() : i(0) { }
+  B(int i) : i(i) { }
+  operator A() &;
+  operator A() &&;
+};
+
+struct A : public B {
+  A(int i) : B(i) { }
+};
+
+B::operator A() & { return { 1 }; }
+B::operator A() && { return { 2 }; }
+
+A
+f (B b)
+{
+  return b;
+}
+
+A
+f2 (B b)
+{
+  return std::move (b);
+}
+
+A
+f3 ()
+{
+  B b;
+  return b;
+}
+
+A
+f4 ()
+{
+  B b;
+  return std::move (b);
+}
+
+A
+f5 ()
+{
+  return B();
+}
+
+int
+main ()
+{
+  A a1 = f (B());
+  if (a1.i != 1)
+__builtin_abort ();
+  A a2 = f2 (B());
+  if (a2.i != 2)
+__builtin_abort ();
+  A a3 = f3 ();
+  if (a3.i != 1)
+__builtin_abort ();
+  A a4 = f4 ();
+  if (a4.i != 2)
+__builtin_abort ();
+  A a5 = f5 ();
+  if (a5.i != 2)
+__builtin_abort ();
+}

Re: [PATCH] Remove arc profile histogram in non-LTO mode.

[Bin.Cheng]

On Thu, Sep 20, 2018 at 2:11 AM Martin Liška  wrote:
>
> Hello.
>
> I've been working for some time on a patch that simplifies how we set
> the hotness threshold of basic blocks. Currently, we calculate so called
> arc profile histograms that should identify edges that cover 99.9% of all
> branching. These edges are then identified as hot. Disadvantage of the 
> approach
> is that it comes with significant overhead in run-time and GCC related code
> is also not trivial. Moreover, anytime a histogram is merged after an 
> instrumented
> run, the resulting histogram is misleading.
>
> That said, I decided to simplify it again, remove usage of the histogram and 
> return
> to what we have before (--param hot-bb-count-fraction). That basically says 
> that
> we consider hot each edge that has execution count bigger than sum_max / 
> 10.000.
>
> Note that LTO+PGO remains untouched as it still uses histogram that is 
> dynamically
> calculated by read arc counts.
Hi,
Does this affect AutoFDO stuff?  AutoFDO is broken and I am fixing it
now, on the basis of current code.

Thanks,
bin
>
> Note the statistics of the patch:
>   19 files changed, 101 insertions(+), 1216 deletions(-)
>
> I'm attaching file sizes of SPEC2006 int benchmark.
>
> Patch survives testing on x86_64-linux-gnu machine.
> Ready to be installed?
>
> Martin
>
> gcc/ChangeLog:
>
> 2018-09-19  Martin Liska  
>
> * auto-profile.c (autofdo_source_profile::read): Do not
> set sum_all.
> (read_profile): Do not add working sets.
> (read_autofdo_file): Remove sum_all.
> (afdo_callsite_hot_enough_for_early_inline): Remove const
> qualifier.
> * coverage.c (struct counts_entry): Remove gcov_summary.
> (read_counts_file): Read new GCOV_TAG_OBJECT_SUMMARY,
> do not support GCOV_TAG_PROGRAM_SUMMARY.
> (get_coverage_counts): Remove summary and expected
> arguments.
> * coverage.h (get_coverage_counts): Likewise.
> * doc/gcov-dump.texi: Remove -w option.
> * gcov-dump.c (dump_working_sets): Remove.
> (main): Do not support '-w' option.
> (print_usage): Likewise.
> (tag_summary): Likewise.
> * gcov-io.c (gcov_write_summary): Do not dump
> histogram.
> (gcov_read_summary): Likewise.
> (gcov_histo_index): Remove.
> (gcov_histogram_merge): Likewise.
> (compute_working_sets): Likewise.
> * gcov-io.h (GCOV_TAG_OBJECT_SUMMARY): Mark
> it not obsolete.
> (GCOV_TAG_PROGRAM_SUMMARY): Mark it obsolete.
> (GCOV_TAG_SUMMARY_LENGTH): Adjust.
> (GCOV_HISTOGRAM_SIZE): Remove.
> (GCOV_HISTOGRAM_BITVECTOR_SIZE): Likewise.
> (struct gcov_summary): Simplify rapidly just
> to runs and sum_max fields.
> (gcov_histo_index): Remove.
> (NUM_GCOV_WORKING_SETS): Likewise.
> (compute_working_sets): Likewise.
> * gcov-tool.c (print_overlap_usage_message): Remove
> trailing empty line.
> * gcov.c (read_count_file): Read GCOV_TAG_OBJECT_SUMMARY.
> (output_lines): Remove program related line.
> * ipa-profile.c (ipa_profile): Do not consider GCOV histogram.
> * lto-cgraph.c (output_profile_summary): Do not stream GCOV
> histogram.
> (input_profile_summary): Do not read it.
> (merge_profile_summaries): And do not merge it.
> (input_symtab): Do not call removed function.
> * modulo-sched.c (sms_schedule): Do not print sum_max.
> * params.def (HOT_BB_COUNT_FRACTION): Reincarnate param that was
> removed when histogram method was invented.
> (HOT_BB_COUNT_WS_PERMILLE): Mention that it's used only in LTO
> mode.
> * postreload-gcse.c (eliminate_partially_redundant_load): Fix
> GCOV coding style.
> * predict.c (get_hot_bb_threshold): Use HOT_BB_COUNT_FRACTION
> and dump selected value.
> * profile.c (add_working_set): Remove.
> (get_working_sets): Likewise.
> (find_working_set): Likewise.
> (get_exec_counts): Do not work with working sets.
> (read_profile_edge_counts): Do not inform as sum_max is removed.
> (compute_branch_probabilities): Likewise.
> (compute_value_histograms): Remove argument for call of
> get_coverage_counts.
> * profile.h: Do not make gcov_summary const.
>
> libgcc/ChangeLog:
>
> 2018-09-19  Martin Liska  
>
> * libgcov-driver.c (crc32_unsigned): Remove.
> (gcov_histogram_insert): Likewise.
> (gcov_compute_histogram): Likewise.
> (compute_summary): Simplify rapidly.
> (merge_one_data): Do not handle PROGRAM_SUMMARY tag.
> (merge_summary): Rapidly simplify.
> (dump_one_gcov): Ignore gcov_summary.
> (gcov_do_dump): Do not handle program summary, it's not
> used.
> * libgcov-util.c (tag_summary): Remove.
> (re

[Ada] Fix comment typo in exp_ch9.adb

[Oliver Kellogg]

Index: gcc/ada/ChangeLog
===
--- gcc/ada/ChangeLog   (revision 264438)
+++ gcc/ada/ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2018-09-20  Oliver Kellogg  
+
+   * exp_ch9.adb: Fix typo 'geenrated' to 'generated'.
+
 2018-09-13  Eric Botcazou  

* Makefile.rtl (arm% linux-gnueabi%): Always set EH_MECHANISM to -arm.
Index: gcc/ada/exp_ch9.adb
===
--- gcc/ada/exp_ch9.adb (revision 264438)
+++ gcc/ada/exp_ch9.adb (working copy)
@@ -481,7 +481,7 @@
--  to be E. Bod is either a block or a subprogram body.  Used after
--  expanding various kinds of entry bodies into their corresponding
--  constructs. This is needed during unnesting to determine whether a
-   --  body geenrated for an entry or an accept alternative includes uplevel
+   --  body generated for an entry or an accept alternative includes uplevel
--  references.

function Trivial_Accept_OK return Boolean;