Re: [PATCH] Adjust a dump file in a test-case (PR testsuite/88436).

2019-01-02 Thread Segher Boessenkool
Hi Martin,

On Thu, Jan 03, 2019 at 08:41:09AM +0100, Martin Liška wrote:
> There's a small test-case update requested by Richi in 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88436#c1.
> Tests are fine on ppc64le-linux-gnu.
> 
> Ready for trunk?

Yes please.  Thanks,


Segher


> 2019-01-02  Martin Liska  
> 
>   PR testsuite/88436
>   * gcc.target/powerpc/pr54240.c: Scan phiopt2.


[PATCH] Adjust a dump file in a test-case (PR testsuite/88436).

2019-01-02 Thread Martin Liška
Hi.

There's a small test-case update requested by Richi in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88436#c1.
Tests are fine on ppc64le-linux-gnu.

Ready for trunk?
Martin

gcc/testsuite/ChangeLog:

2019-01-02  Martin Liska  

PR testsuite/88436
* gcc.target/powerpc/pr54240.c: Scan phiopt2.
---
 gcc/testsuite/gcc.target/powerpc/pr54240.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/gcc/testsuite/gcc.target/powerpc/pr54240.c b/gcc/testsuite/gcc.target/powerpc/pr54240.c
index 1425ecddd6e..300e4f59647 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr54240.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr54240.c
@@ -23,4 +23,4 @@ int foo(S *s)
   return next->v;
 }
 
-/* { dg-final { scan-tree-dump "Hoisting adjacent loads" "phiopt1" } } */
+/* { dg-final { scan-tree-dump "Hoisting adjacent loads" "phiopt2" } } */



[PATCH (sync with binutils-gdb)] Don't build readline/libreadline.a, when --with-system-readline is supplied

2019-01-02 Thread Simon Marchi
From: Дилян Палаузов 

[I (Simon) just pushed this to binutils-gdb, please consider merging it
 in gcc to keep the files sync-ed(-ish).]

https://sourceware.org/bugzilla/show_bug.cgi?id=18632

The bundled libreadline is always built, even if the system is
./configure'd --with-system-readline and the build libreadline.a is not
used.

Proposed patch:

Fix ./configure.ac not to proceed readline/, when --with-system-
readline is provided
---
 ChangeLog| 7 +++
 configure| 6 ++
 configure.ac | 6 ++
 3 files changed, 19 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index a86c3fc40c01..5c98e93d1922 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2019-01-03  Дилян Палаузов  
+
+   Merge from binutils-gdb:
+   * configure.ac: Don't configure readline if --with-system-readline is
+   used.
+   * configure: Re-generate.
+
 2018-12-21  Thomas Preud'homme  
 
* MAINTAINERS (Write After Approval): Update my maintainer address.
diff --git a/configure b/configure
index 4b095de5b0ae..29c2eebc81b9 100755
--- a/configure
+++ b/configure
@@ -2920,6 +2920,12 @@ if test x$with_system_zlib = xyes ; then
   noconfigdirs="$noconfigdirs zlib"
 fi
 
+# Don't compile the bundled readline/libreadline.a if --with-system-readline
+# is provided.
+if test x$with_system_readline = xyes ; then
+  noconfigdirs="$noconfigdirs readline"
+fi
+
 # some tools are so dependent upon X11 that if we're not building with X,
 # it's not even worth trying to configure, much less build, that tool.
 
diff --git a/configure.ac b/configure.ac
index 05475105ffc0..2c4b917e5334 100644
--- a/configure.ac
+++ b/configure.ac
@@ -246,6 +246,12 @@ if test x$with_system_zlib = xyes ; then
   noconfigdirs="$noconfigdirs zlib"
 fi
 
+# Don't compile the bundled readline/libreadline.a if --with-system-readline
+# is provided.
+if test x$with_system_readline = xyes ; then
+  noconfigdirs="$noconfigdirs readline"
+fi
+
 # some tools are so dependent upon X11 that if we're not building with X, 
 # it's not even worth trying to configure, much less build, that tool.
 
-- 
2.20.1



Re: add tsv110 pipeline scheduling

2019-01-02 Thread wuyuan (E)
Hi , guys
  Happy new year! 
  On the 20th of last month, I submitted a tsv110 pipeline patch. I 
want to know if you have received  it. Looking forward to your reply.


 
Best Regards,


   
wuyuan
   



   

-邮件原件-
发件人: wuyuan (E) 
发送时间: 2018年12月20日 14:06
收件人: 'Ramana Radhakrishnan' ; 
'gcc-patches@gcc.gnu.org' 
抄送: Zhanghaijian (A) ; Zhangyichao (AB) 
; Yangfei (Felix) ; 
'ni...@redhat.com' ; 'Richard Earnshaw' 
; 'Kyrylo Tkachov' ; 'nd' 
; Zhangshaokun 
主题: Re: add tsv110 pipeline scheduling


Hi Ramana,
 Please ignore the patch in the previous email attachment (the 
ChangeLog has deleted in this patch..)  I have already communicated with Shao 
Kun, he has fixed the problem of the previous patch. So I resubmitted the 
tsv110 pipeline patch, please review.
 The patch  as follows :



2018-12-20   wuyuan  

* config/aarch64/aarch64-cores.def: New CPU.
* config/aarch64/aarch64.md : Add "tsv110.md"
* config/aarch64/tsv110.md : tsv110.md   new file






diff --git a/gcc/config/aarch64/aarch64-cores.def 
b/gcc/config/aarch64/aarch64-cores.def
old mode 100644
new mode 100755
index 20f4924..ea9b7c5
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -97,7 +97,7 @@ AARCH64_CORE("cortex-a76",  cortexa76, cortexa57, 8_2A,  
AARCH64_FL_FOR_ARCH8_2  AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  
AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD 
| AARCH64_FL_PROFILE, cortexa72, 0x41, 0xd0c, -1)
 
 /* HiSilicon ('H') cores. */
-AARCH64_CORE("tsv110",  tsv110, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | 
AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,  
 0x48, 0xd01, -1)
+AARCH64_CORE("tsv110",  tsv110, tsv110, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | 
AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,  
 0x48, 0xd01, -1)
 
 /* ARMv8.4-A Architecture Processors.  */
 
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md old 
mode 100644 new mode 100755 index cf2732e..7f7673a
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -349,6 +349,7 @@
 (include "thunderx.md")
 (include "../arm/xgene1.md")
 (include "thunderx2t99.md")
+(include "tsv110.md")
 
 ;; ---
 ;; Jumps and other miscellaneous insns
diff --git a/gcc/config/aarch64/tsv110.md b/gcc/config/aarch64/tsv110.md new 
file mode 100644 index 000..758ab95
--- /dev/null
+++ b/gcc/config/aarch64/tsv110.md
@@ -0,0 +1,708 @@
+;; tsv110 pipeline description
+;; Copyright (C) 2018 Free Software Foundation, Inc.
+;;
+;; This file is part of GCC.
+;;
+;; GCC is free software; you can redistribute it and/or modify it ;; 
+under the terms of the GNU General Public License as published by ;; 
+the Free Software Foundation; either version 3, or (at your option) ;; 
+any later version.
+;;
+;; GCC is distributed in the hope that it will be useful, but ;; 
+WITHOUT ANY WARRANTY; without even the implied warranty of ;; 
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU ;; 
+General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License ;; 
+along with GCC; see the file COPYING3.  If not see ;; 
+.
+
+(define_automaton "tsv110")
+
+(define_attr "tsv110_neon_type"
+  "neon_arith_acc, neon_arith_acc_q,
+   neon_arith_basic, neon_arith_complex,
+   neon_reduc_add_acc, neon_multiply, neon_multiply_q,
+   neon_multiply_long, neon_mla, neon_mla_q, neon_mla_long,
+   neon_sat_mla_long, neon_shift_acc, neon_shift_imm_basic,
+   neon_shift_imm_complex,
+   neon_shift_reg_basic, neon_shift_reg_basic_q, neon_shift_reg_complex,
+   neon_shift_reg_complex_q, neon_fp_negabs, neon_fp_arith,
+   neon_fp_arith_q, neon_fp_reductions_q, neon_fp_cvt_int,
+   neon_fp_cvt_int_q, neon_fp_cvt16, neon_fp_minmax, neon_fp_mul,
+   neon_fp_mul_q, neon_fp_mla, neon_fp_mla_q, neon_fp_recpe_rsqrte,
+   neon_fp_recpe_rsqrte_q, neon_fp_recps_rsqrts, neon_fp_recps_rsqrts_q,
+   neon_bitops, neon_bitops_q, neon_from_gp,
+   neon_from_gp_q, neon_move, neon_tbl3_tbl4, neon_zip_q, neon_to_gp,
+   neon_load_a, neon_load_b, 

Re: [Patch 3/4][Aarch64] v2: Implement Aarch64 SIMD ABI

2019-01-02 Thread Steve Ellcey

Here is an update of this patch.  I believe I addressed all of the
issues you raised.  Thanks for the new target.def description, it
seems much clearer than mine.  I did a full build and test on x86 as
well as aarch64 to make sure that architectures that do not define
TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS build correctly.

Steve Ellcey
sell...@marvell.com


2019-01-02  Steve Ellcey  

* config/aarch64/aarch64.c (aarch64_simd_call_p): New function.
(aarch64_remove_extra_call_preserved_regs): New function.
(TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS): New macro.
* doc/tm.texi.in (TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS): New hook.
* final.c (get_call_reg_set_usage): Call new hook.
* target.def (remove_extra_call_preserved_regs): New hook.
* targhooks.c (default_remove_extra_call_preserved_regs): New function.
* targhooks.h (default_remove_extra_call_preserved_regs): New function.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c5036c8..c916689 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1565,6 +1565,45 @@ aarch64_reg_save_mode (tree fndecl, unsigned regno)
 	   : (aarch64_simd_decl_p (fndecl) ? E_TFmode : E_DFmode);
 }
 
+/* Return true if the instruction is a call to a SIMD function, false
+   if it is not a SIMD function or if we do not know anything about
+   the function.  */
+
+static bool
+aarch64_simd_call_p (rtx_insn *insn)
+{
+  rtx symbol;
+  rtx call;
+  tree fndecl;
+
+  gcc_assert (CALL_P (insn));
+  call = get_call_rtx_from (insn);
+  symbol = XEXP (XEXP (call, 0), 0);
+  if (GET_CODE (symbol) != SYMBOL_REF)
+return false;
+  fndecl = SYMBOL_REF_DECL (symbol);
+  if (!fndecl)
+return false;
+
+  return aarch64_simd_decl_p (fndecl);
+}
+
+/* Implement TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS.  If INSN calls
+   a function that uses the SIMD ABI, take advantage of the extra
+   call-preserved registers that the ABI provides.  */
+
+void
+aarch64_remove_extra_call_preserved_regs (rtx_insn *insn,
+	  HARD_REG_SET *return_set)
+{
+  if (aarch64_simd_call_p (insn))
+{
+  for (int regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
+	if (FP_SIMD_SAVED_REGNUM_P (regno))
+	  CLEAR_HARD_REG_BIT (*return_set, regno);
+}
+}
+
 /* Implement TARGET_HARD_REGNO_CALL_PART_CLOBBERED.  The callee only saves
the lower 64 bits of a 128-bit register.  Tell the compiler the callee
clobbers the top 64 bits when restoring the bottom 64 bits.  */
@@ -18524,6 +18563,10 @@ aarch64_libgcc_floating_mode_supported_p
 #define TARGET_HARD_REGNO_CALL_PART_CLOBBERED \
   aarch64_hard_regno_call_part_clobbered
 
+#undef TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS
+#define TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS \
+  aarch64_remove_extra_call_preserved_regs
+
 #undef TARGET_CONSTANT_ALIGNMENT
 #define TARGET_CONSTANT_ALIGNMENT aarch64_constant_alignment
 
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 976a700..d9f40a1 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -1707,6 +1707,8 @@ of @code{CALL_USED_REGISTERS}.
 @cindex call-saved register
 @hook TARGET_HARD_REGNO_CALL_PART_CLOBBERED
 
+@hook TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS
+
 @findex fixed_regs
 @findex call_used_regs
 @findex global_regs
diff --git a/gcc/final.c b/gcc/final.c
index 6dc1cd1..f6edd6a 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -5095,7 +5095,7 @@ get_call_reg_set_usage (rtx_insn *insn, HARD_REG_SET *reg_set,
 	  return true;
 	}
 }
-
   COPY_HARD_REG_SET (*reg_set, default_set);
+  targetm.remove_extra_call_preserved_regs (insn, reg_set);
   return false;
 }
diff --git a/gcc/target.def b/gcc/target.def
index e8f0f70..908f9b9 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -5775,6 +5775,20 @@ for targets that don't have partly call-clobbered registers.",
  bool, (unsigned int regno, machine_mode mode),
  hook_bool_uint_mode_false)
 
+DEFHOOK
+(remove_extra_call_preserved_regs,
+ "This hook removes registers from the set of call-clobbered registers\n\
+ in @var{used_regs} if, contrary to the default rules, something guarantees\n\
+ that @samp{insn} preserves those registers.  For example, some targets\n\
+ support variant ABIs in which functions preserve more registers than\n\
+ normal functions would.  Removing those extra registers from @var{used_regs}\n\
+ can lead to better register allocation.\n\
+ \n\
+ The default implementation does nothing, which is always safe.\n\
+ Defining the hook is purely an optimization.",
+ void, (rtx_insn *insn, HARD_REG_SET *used_regs),
+ default_remove_extra_call_preserved_regs)
+
 /* Return the smallest number of different values for which it is best to
use a jump-table instead of a tree of conditional branches.  */
 DEFHOOK
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index 898848f..6bd9767 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -2374,4 +2374,9 @@ default_speculation_safe_value (machine_mode mode 

[committed] Drop SRK_LENRANGE_2 scaffolding

2019-01-02 Thread Jeff Law
This removes SRK_LENRANGE_2 which was used temporarily as I pulled apart
different parts of the API changes for get_range_strlen.   As of a
couple patches ago, it's no longer needed.

Bootstrapped and regression tested on x86_64-linux-gnu.  Installing on
the trunk.

jeff

commit 54a7a5e3a7b392f05c72a292e778099e5c023c35
Author: Jeff Law 
Date:   Tue Jan 1 22:17:44 2019 -0500

* gimple-fold.c (strlen_range_kind): Remove SRK_LENRANGE_2.
(get_range_strlen_tree): Update appropriately.
(get_range_strlen)
* gimple-fold.h (get_range_strlen): Drop unused last argument.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b4e2f25a2cc..634de2b0d18 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,6 +1,10 @@
 2019-01-02  Martin Sebor  
 Jeff Law  
 
+   * gimple-fold.c (strlen_range_kind): Remove SRK_LENRANGE_2.
+   (get_range_strlen_tree): Update appropriately.
+   (get_range_strlen)
+   * gimple-fold.h (get_range_strlen): Drop unused last argument.
 
* gimple-fold.c (gimple_fold_builtin_strlen): Use set_strlen_range
rather than set_range_info.
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 0bb4db5e160..529149acda3 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -77,8 +77,6 @@ enum strlen_range_kind {
  or element of.  Also determine the size of the largest character
  array the string may refer to.  */
   SRK_LENRANGE,
-  /* Temporary until the rest of Martin's strlen range work is integrated.  */
-  SRK_LENRANGE_2,
   /* Determine the integer value of the argument (not string length).  */
   SRK_INT_VALUE
 };
@@ -1309,7 +1307,7 @@ get_range_strlen_tree (tree arg, bitmap *visited, 
strlen_range_kind rkind,
 pdata, eltsize);
}
   else if (TREE_CODE (TREE_OPERAND (op, 0)) == COMPONENT_REF
-  && (rkind == SRK_LENRANGE || rkind == SRK_LENRANGE_2))
+  && rkind == SRK_LENRANGE)
{
  /* Fail if an array is the last member of a struct object
 since it could be treated as a (fake) flexible array
@@ -1349,7 +1347,7 @@ get_range_strlen_tree (tree arg, bitmap *visited, 
strlen_range_kind rkind,
}
 }
 
-  if (!val && (rkind == SRK_LENRANGE || rkind == SRK_LENRANGE_2))
+  if (!val && rkind == SRK_LENRANGE)
 {
   if (TREE_CODE (arg) == ADDR_EXPR)
return get_range_strlen (TREE_OPERAND (arg, 0), visited, rkind,
@@ -1484,7 +1482,7 @@ get_range_strlen_tree (tree arg, bitmap *visited, 
strlen_range_kind rkind,
 on the length of the string based on the referenced object's
 or subobject's type.  Determine the conservative upper bound
 based on the enclosing object's size if possible.  */
-  if (rkind == SRK_LENRANGE || rkind == SRK_LENRANGE_2)
+  if (rkind == SRK_LENRANGE)
{
  poly_int64 offset;
  tree base = get_addr_base_and_unit_offset (arg, );
@@ -1538,7 +1536,7 @@ get_range_strlen_tree (tree arg, bitmap *visited, 
strlen_range_kind rkind,
 }
 
   pdata->maxlen = val;
-  return rkind == SRK_LENRANGE || rkind == SRK_LENRANGE_2 || 
!integer_all_onesp (val);
+  return rkind == SRK_LENRANGE || !integer_all_onesp (val);
 }
 
 /* For an ARG referencing one or more strings, try to obtain the range
@@ -1600,7 +1598,7 @@ get_range_strlen (tree arg, bitmap *visited,
for (unsigned int i = 0; i < 2; i++)
  if (!get_range_strlen (ops[i], visited, rkind, pdata, eltsize))
{
- if (rkind != SRK_LENRANGE_2)
+ if (rkind != SRK_LENRANGE)
return false;
  /* Set the upper bound to the maximum to prevent
 it from being adjusted in the next iteration but
@@ -1634,7 +1632,7 @@ get_range_strlen (tree arg, bitmap *visited,
 
if (!get_range_strlen (arg, visited, rkind, pdata, eltsize))
  {
-   if (rkind != SRK_LENRANGE_2)
+   if (rkind != SRK_LENRANGE)
  return false;
/* Set the upper bound to the maximum to prevent
   it from being adjusted in the next iteration but
@@ -1680,12 +1678,11 @@ get_range_strlen (tree arg, bitmap *visited,
4 for wide characer strings.  ELTSIZE is by default 1.  */
 
 bool
-get_range_strlen (tree arg, c_strlen_data *pdata, unsigned eltsize, bool 
strict)
+get_range_strlen (tree arg, c_strlen_data *pdata, unsigned eltsize)
 {
   bitmap visited = NULL;
 
-  if (!get_range_strlen (arg, , strict ? SRK_LENRANGE : SRK_LENRANGE_2,
-pdata, eltsize))
+  if (!get_range_strlen (arg, , SRK_LENRANGE, pdata, eltsize))
 {
   /* On failure extend the length range to an impossible maximum
 (a valid MAXLEN must be less than PTRDIFF_MAX - 1).  Other
diff --git a/gcc/gimple-fold.h b/gcc/gimple-fold.h
index 35f1ba26953..673d484ff52 100644
--- a/gcc/gimple-fold.h
+++ b/gcc/gimple-fold.h
@@ 

C++ PATCH to add tests for c++/81486

2019-01-02 Thread Marek Polacek
My recent fix for c++/88612 fixed these two testcases too.  Let's add them.

Tested on x86_64-linux, applying to trunk.

2019-01-02  Marek Polacek  

PR c++/81486 - CTAD failing with ().
* g++.dg/cpp1z/class-deduction60.C: New test.
* g++.dg/cpp1z/class-deduction61.C: New test.

diff --git gcc/testsuite/g++.dg/cpp1z/class-deduction60.C 
gcc/testsuite/g++.dg/cpp1z/class-deduction60.C
new file mode 100644
index 000..dbc5732a2a8
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction60.C
@@ -0,0 +1,19 @@
+// PR c++/81486
+// { dg-do compile { target c++17 } }
+
+template 
+struct C {
+  C(T);
+};
+
+template <>
+struct C { };
+
+C() -> C;
+
+int
+main()
+{
+  auto a = C{};
+  auto b = C();
+}
diff --git gcc/testsuite/g++.dg/cpp1z/class-deduction61.C 
gcc/testsuite/g++.dg/cpp1z/class-deduction61.C
new file mode 100644
index 000..9ef095e2af0
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction61.C
@@ -0,0 +1,15 @@
+// PR c++/81486
+// { dg-do compile { target c++17 } }
+
+template 
+struct foo
+{
+  template 
+  foo(Us...) { }
+};
+
+int
+main ()
+{
+  auto f = foo();
+}


[PATCH] ARM: add test case for -masm-syntax-unified (PR88648)

2019-01-02 Thread Stefan Agner
Add a test case to check whether -masm-syntax-unified is indeed
emitting the inline assembler with .syntax unified.
---
 .../gcc.target/arm/pr88648-asm-syntax-unified.c| 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c

diff --git a/gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c 
b/gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c
new file mode 100644
index 000..2bd9d891b9e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c
@@ -0,0 +1,14 @@
+/* Test for unified syntax assembly generation.  */
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v7a_ok } */
+/* { dg-add-options arm_arch_v7a } */
+/* { dg-options "-marm -march=armv7-a -masm-syntax-unified" } */
+
+void test ()
+{
+  asm("nop");
+}
+
+/* { dg-final { scan-assembler-times {\.syntax\sunified} 3 } } */
+/* { dg-final { scan-assembler-times {\.syntax\sdivided} 0 } } */
+
-- 
2.20.1



Re: [C++ Patch] Improve handle_nodiscard_attribute location

2019-01-02 Thread Jason Merrill

On 1/2/19 4:26 PM, Paolo Carlini wrote:
it seems we can easily improve this location by using 
DECL_SOURCE_LOCATION in the standard way. Tested x86_64-linux.


OK.

Jason


Re: C++ PATCH for c++/88631, CTAD failing for value-initialization

2019-01-02 Thread Jason Merrill

On 12/30/18 11:08 AM, Marek Polacek wrote:

This PR points out that while we are able to deduce the template arguments
for A{}, we fail for A().

For A{}, the deduction happens in finish_compound_literal:
2789   if (tree anode = type_uses_auto (type))
2790 if (CLASS_PLACEHOLDER_TEMPLATE (anode))
2791   {
2792 type = do_auto_deduction (type, compound_literal, anode, complain,
2793   adc_variable_type)

and for A() in build_functional_cast, but there we always give error if there
are no parameters.  That is wrong because even though there are no arguments
to deduce from, we might still be able to deduce from default template
arguments as in the test.  Fixed thus; I'm passing tf_none if there are no
params because we don't want to give redundant diagnostics if the deduction
fails.


OK.

Jason


Re: [C++ PATCH] [PR87768] do not suppress location wrappers when tsubsting

2019-01-02 Thread Jason Merrill

On 12/30/18 11:31 PM, Alexandre Oliva wrote:

Concepts-checking and other kinds of early tsubsting may often take
place while location wrappers are suppressed, e.g. because we've
triggered template instantiation within template parameter lists.

With that, exprs that are usually wrapped by VIEW_CONVERT_EXPRs
location wrappers may end up wrapped by NON_LVALUE_EXPRs that are not
marked as location wrappers.  If such NON_LVALUE_EXPRs tsubsted exprs
undergo another round of tsubsting, say for constraint checking, or
even for another round of specialization, they will be rejected by
tsubst_copy_and_build.



This patch introduces a sentinel to reset suppress_location_wrappers
to zero, and uses it for template class and decl instantiation,
including constraint checking.


Instead of a new class, let's add this to saved_scope and 
push_to/pop_from_top_level.


Jason


[committed] Be more conservative with string length range computations

2019-01-02 Thread Jeff Law

This is the last of the major pieces of Martin's work.
set_strlen_range is extracted out of maybe_set_strlen_range and used by
the strlen folder.

The remnants of maybe_set_strlen_range is made more conservative,
particularly for cases where we might cross a subobject boundary.

There's the usual testsuite tweaks as well as a few new tests.

Bootstrapped and regression tested on x86_64.  My testers will be
spinning on this later today.

There's one or two very minor cleanup patches still to wrap up and some
verification steps, but in terms of notable behavior changes I think
we're done.

Installing on the trunk,
jeff
commit 0ec4b03364a1893baa78b1ebe4006bfe6a03c134
Author: Jeff Law 
Date:   Fri Dec 28 00:09:35 2018 -0500

* gimple-fold.c (gimple_fold_builtin_strlen): Use set_strlen_range
rather than set_range_info.
* tree-ssa-strlen.c (set_strlen_range): Extracted from
maybe_set_strlen_range.  Handle potentially boundary crossing
cases more conservatively.
(maybe_set_strlen_range): Parts refactored into set_strlen_range.
Call set_strlen_range.
* tree-ssa-strlen.h (set_strlen_range): Add prototype.

* gcc.dg/strlenopt-36.c: Update.
* gcc.dg/strlenopt-45.c: Update.
* gcc.c-torture/execute/strlen-5.c: New test.
* gcc.c-torture/execute/strlen-6.c: New test.
* gcc.c-torture/execute/strlen-7.c: New test.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b344f6be61e..b4e2f25a2cc 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,6 +1,16 @@
 2019-01-02  Martin Sebor  
 Jeff Law  
 
+
+   * gimple-fold.c (gimple_fold_builtin_strlen): Use set_strlen_range
+   rather than set_range_info.
+   * tree-ssa-strlen.c (set_strlen_range): Extracted from
+   maybe_set_strlen_range.  Handle potentially boundary crossing
+   cases more conservatively.
+   (maybe_set_strlen_range): Parts refactored into set_strlen_range.
+   Call set_strlen_range.
+   * tree-ssa-strlen.h (set_strlen_range): Add prototype.
+   
PR middle-end/88663
* gimple-fold.c (get_range_strlen): Update prototype to no longer
need the flexp argument.
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 688daf92154..0bb4db5e160 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -3739,10 +3739,9 @@ gimple_fold_builtin_strlen (gimple_stmt_iterator *gsi)
   return true;
 }
 
+  /* Set the strlen() range to [0, MAXLEN].  */
   if (tree lhs = gimple_call_lhs (stmt))
-if (TREE_CODE (lhs) == SSA_NAME
-   && INTEGRAL_TYPE_P (TREE_TYPE (lhs)))
-  set_range_info (lhs, VR_RANGE, minlen, maxlen);
+set_strlen_range (lhs, maxlen);
 
   return false;
 }
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 40703c62017..1d5a8769fae 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,12 @@
+2019-01-02  Martin Sebor  
+Jeff Law  
+
+   * gcc.dg/strlenopt-36.c: Update.
+   * gcc.dg/strlenopt-45.c: Update.
+   * gcc.c-torture/execute/strlen-5.c: New test.
+   * gcc.c-torture/execute/strlen-6.c: New test.
+   * gcc.c-torture/execute/strlen-7.c: New test.
+
 2019-01-02  Jakub Jelinek  
 
PR testsuite/87304
diff --git a/gcc/testsuite/gcc.c-torture/execute/strlen-5.c 
b/gcc/testsuite/gcc.c-torture/execute/strlen-5.c
new file mode 100644
index 000..9af57d5ee39
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/strlen-5.c
@@ -0,0 +1,653 @@
+/* Test to verify that even strictly undefined strlen() calls with
+   unterminated character arrays yield the "expected" results when
+   the terminating nul is present in a subsequent suobobject.  */
+
+extern __SIZE_TYPE__ strlen (const char *);
+
+unsigned nfails;
+
+#define A(expr, N) \
+  do { \
+const char *s = (expr);\
+unsigned n = strlen (s);   \
+((n == N)  \
+ ? 0   \
+ : (__builtin_printf ("line %i: strlen (%s = \"%s\")"  \
+ " == %u failed\n",\
+ __LINE__, #expr, s, N),   \
+   ++nfails)); \
+  } while (0)
+
+
+int idx;
+
+
+const char ca[][4] = {
+  { '1', '2', '3', '4' }, { '5' },
+  { '1', '2', '3', '4' }, { '5', '6' },
+  { '1', '2', '3', '4' }, { '5', '6', '7' },
+  { '1', '2', '3', '4' }, { '5', '6', '7', '8' },
+  { '9' }
+};
+
+static void test_const_global_arrays (void)
+{
+  A (ca[0], 5);
+  A ([0][0], 5);
+  A ([0][1], 4);
+  A ([0][3], 2);
+
+  int i = 0;
+  A (ca[i], 5);
+  A ([i][0], 5);
+  A ([i][1], 4);
+  A ([i][3], 2);
+
+  int j = i;
+  A ([i][i], 

Re: C++ PATCH for c++/88612, ICE with -Waddress-of-packed-member

2019-01-02 Thread Jason Merrill

On 12/31/18 10:13 AM, Marek Polacek wrote:

This new warning was missing tf_warning checks so we may've wound up
re-entering the reporting routines.  Fixed thus.

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


OK.


Re: [C++ PATCH] Fix ICEs with builtin redeclaration (PR c++/88636)

2019-01-02 Thread Jason Merrill

On 1/2/19 5:09 AM, Jakub Jelinek wrote:

Hi!

On the following testcase we ICE, because pushdecl* ggc_frees the decl
passed to it, but builtin_function_1 returns it anyway.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?


OK.


[C++ Patch] Improve handle_nodiscard_attribute location

2019-01-02 Thread Paolo Carlini

Hi,

it seems we can easily improve this location by using 
DECL_SOURCE_LOCATION in the standard way. Tested x86_64-linux.


Thanks, Paolo.

//

/cp
2019-01-02  Paolo Carlini  

* tree.c (handle_nodiscard_attribute): Improve warning location.

/testsuite
2019-01-02  Paolo Carlini  

* g++.dg/cpp1z/nodiscard3.C: Test locations too.
Index: cp/tree.c
===
--- cp/tree.c   (revision 267507)
+++ cp/tree.c   (working copy)
@@ -4372,8 +4372,9 @@ handle_nodiscard_attribute (tree *node, tree name,
   if (TREE_CODE (*node) == FUNCTION_DECL)
 {
   if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (*node
-   warning (OPT_Wattributes, "%qE attribute applied to %qD with void "
-"return type", name, *node);
+   warning_at (DECL_SOURCE_LOCATION (*node),
+   OPT_Wattributes, "%qE attribute applied to %qD with void "
+   "return type", name, *node);
 }
   else if (OVERLOAD_TYPE_P (*node))
 /* OK */;
Index: testsuite/g++.dg/cpp1z/nodiscard3.C
===
--- testsuite/g++.dg/cpp1z/nodiscard3.C (revision 267507)
+++ testsuite/g++.dg/cpp1z/nodiscard3.C (working copy)
@@ -13,8 +13,8 @@ typedef struct { char big[1024]; fnt fn; } C;
 struct [[nodiscard]] D { int i; D(); ~D(); };
 
 WUR E check1 (void);
-WUR void check2 (void); /* { dg-warning "nodiscard" } */
-WUR int foo;   /* { dg-warning "nodiscard" } */
+WUR void check2 (void); /* { dg-warning "10:.nodiscard." } */
+WUR int foo;   /* { dg-warning "9:.nodiscard." } */
 int bar (void);
 WURAI E check3 (void) { return (E)bar (); }
 WUR A check4 (void);


Re: [PATCH] Tweak gcc.dg/vect/bb-slp-over-widen-1.c testcase (PR testsuite/87304)

2019-01-02 Thread Richard Biener
On January 2, 2019 7:26:19 PM GMT+01:00, Jakub Jelinek  wrote:
>Hi!
>
>As mentioned in the PR, this testcase is not vectorized e.g. on power7
>(32-bit as well as 64-bit), because there is no misalign support.
>
>Tested on x86_64-linux (-m32/-m64) where the scan-tree-dump-times still
>passes and on powerpc64-linux (-m32/-m64) where it previously FAILed
>and now
>isn't tested.
>
>Ok for trunk?

OK.. 
Richard. 

>2019-01-02  Jakub Jelinek  
>
>   PR testsuite/87304
>   * gcc.dg/vect/bb-slp-over-widen-1.c: Expect basic block vectorized
>   messages only on vect_hw_misalign targets.
>
>--- gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c.jj 2018-08-03
>17:05:27.067196476 +0200
>+++ gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c2019-01-02
>19:18:50.205495553 +0100
>@@ -64,4 +64,4 @@ main (void)
>/* { dg-final { scan-tree-dump "demoting int to signed short" "slp2" {
>target { ! vect_widen_shift } } } } */
>/* { dg-final { scan-tree-dump "demoting int to unsigned short" "slp2"
>{ target { ! vect_widen_shift } } } } */
>/* { dg-final { scan-tree-dump {\.AVG_FLOOR} "slp2" { target
>vect_avg_qi } } } */
>-/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2"
>} } */
>+/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2"
>{ target vect_hw_misalign } } } */
>
>   Jakub



[committed][middle-end/88663] Simplify get_range_strlen and fix test of return value

2019-01-02 Thread Jeff Law
This fixes pr88663.

We drop the flexp special handling and instead handle the trailing array
just like any other situation where we need to be conservative.  It also
removes some special casing when we had an unterminated character array.
 Generic code handles that just fine now.  Make return value from
get_range_strlen more consistent.Most importantly it fixes the tense
of a return value check in gimple_fold_builtin_strlen.

Bootstrapped and regression tested on x86_64.  Spot tested on a 32bit
port (crisv32 which was showing the same failure as HJ reported).  I've
got a dozen or so other 32bit ports which showed overnight failures that
I suspect are the same thing.  I'll spin those independently to confirm
and take appropriate actions.

Installing on the trunk.

Jeff
commit 9fd69efdd821c1afeb25e5469ed36993426adb37
Author: Jeff Law 
Date:   Fri Dec 21 17:50:22 2018 -0500

PR middle-end/88663
* gimple-fold.c (get_range_strlen): Update prototype to no longer
need the flexp argument.
(get_range_strlen_tree): Drop flexp argument.  Drop flexp argument
from calls to get_range_strlen.  Update comments.  Just update
VAL for an unterminated const char array and let the reset of the
code handle it normally.  No longer try to set *flexp.  Adjust
return value.
(get_range_strlen): Update for the new get_range_strlen API.
(get_maxval_strlen): Similarly.
(gimple_fold_builtin_strlen): Handle update meaning of return value
from get_range_strlen.
* gimple-ssa-sprintf.c (get_string_length): Update for the new
get_range_strlen API.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 708eb500cf2..b344f6be61e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,21 @@
+2019-01-02  Martin Sebor  
+Jeff Law  
+
+   PR middle-end/88663
+   * gimple-fold.c (get_range_strlen): Update prototype to no longer
+   need the flexp argument.
+   (get_range_strlen_tree): Drop flexp argument.  Drop flexp argument
+   from calls to get_range_strlen.  Update comments.  Just update
+   VAL for an unterminated const char array and let the reset of the
+   code handle it normally.  No longer try to set *flexp.  Adjust
+   return value.
+   (get_range_strlen): Update for the new get_range_strlen API.
+   (get_maxval_strlen): Similarly.
+   (gimple_fold_builtin_strlen): Handle update meaning of return value
+   from get_range_strlen.
+   * gimple-ssa-sprintf.c (get_string_length): Update for the new
+   get_range_strlen API.
+   
 2019-01-02  Jan Hubicka  
 
PR lto/88130
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index cf19db268ad..688daf92154 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -83,8 +83,8 @@ enum strlen_range_kind {
   SRK_INT_VALUE
 };
 
-static bool get_range_strlen (tree, bitmap *, strlen_range_kind,
- c_strlen_data *, bool *, unsigned);
+static bool
+get_range_strlen (tree, bitmap *, strlen_range_kind, c_strlen_data *, 
unsigned);
 
 /* Return true when DECL can be referenced from current unit.
FROM_DECL (if non-null) specify constructor of variable DECL was taken from.
@@ -1281,10 +1281,8 @@ gimple_fold_builtin_memset (gimple_stmt_iterator *gsi, 
tree c, tree len)
 /* Helper of get_range_strlen for ARG that is not an SSA_NAME.  */
 
 static bool
-get_range_strlen_tree (tree arg, bitmap *visited,
-  strlen_range_kind rkind,
-  c_strlen_data *pdata,
-  bool *flexp, unsigned eltsize)
+get_range_strlen_tree (tree arg, bitmap *visited, strlen_range_kind rkind,
+  c_strlen_data *pdata, unsigned eltsize)
 {
   gcc_assert (TREE_CODE (arg) != SSA_NAME);
  
@@ -1307,8 +1305,8 @@ get_range_strlen_tree (tree arg, bitmap *visited,
  tree aop0 = TREE_OPERAND (op, 0);
  if (TREE_CODE (aop0) == INDIRECT_REF
  && TREE_CODE (TREE_OPERAND (aop0, 0)) == SSA_NAME)
-   return get_range_strlen (TREE_OPERAND (aop0, 0), visited,
-rkind, pdata, flexp, eltsize);
+   return get_range_strlen (TREE_OPERAND (aop0, 0), visited, rkind,
+pdata, eltsize);
}
   else if (TREE_CODE (TREE_OPERAND (op, 0)) == COMPONENT_REF
   && (rkind == SRK_LENRANGE || rkind == SRK_LENRANGE_2))
@@ -1342,14 +1340,12 @@ get_range_strlen_tree (tree arg, bitmap *visited,
   c_strlen_data lendata = { };
   val = c_strlen (arg, 1, , eltsize);
 
-  /* If we potentially had a non-terminated string, then
-bubble that information up to the caller.  */
   if (!val && lendata.decl)
{
+ /* ARG refers to an unterminated const character array.
+DATA.DECL with size DATA.LEN.  */
+ val = lendata.minlen;
  pdata->decl = 

[PATCH] Tweak gcc.dg/vect/bb-slp-over-widen-1.c testcase (PR testsuite/87304)

2019-01-02 Thread Jakub Jelinek
Hi!

As mentioned in the PR, this testcase is not vectorized e.g. on power7
(32-bit as well as 64-bit), because there is no misalign support.

Tested on x86_64-linux (-m32/-m64) where the scan-tree-dump-times still
passes and on powerpc64-linux (-m32/-m64) where it previously FAILed and now
isn't tested.

Ok for trunk?

2019-01-02  Jakub Jelinek  

PR testsuite/87304
* gcc.dg/vect/bb-slp-over-widen-1.c: Expect basic block vectorized
messages only on vect_hw_misalign targets.

--- gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c.jj  2018-08-03 
17:05:27.067196476 +0200
+++ gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c 2019-01-02 
19:18:50.205495553 +0100
@@ -64,4 +64,4 @@ main (void)
 /* { dg-final { scan-tree-dump "demoting int to signed short" "slp2" { target 
{ ! vect_widen_shift } } } } */
 /* { dg-final { scan-tree-dump "demoting int to unsigned short" "slp2" { 
target { ! vect_widen_shift } } } } */
 /* { dg-final { scan-tree-dump {\.AVG_FLOOR} "slp2" { target vect_avg_qi } } } 
*/
-/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" } } */
+/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" { 
target vect_hw_misalign } } } */

Jakub


Re: deprecations in OpenMP 5.0

2019-01-02 Thread Jakub Jelinek
On Wed, Jan 02, 2019 at 06:29:27PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 02, 2019 at 06:23:57PM +0100, Ulrich Drepper wrote:
> > On 1/2/19 6:21 PM, Jakub Jelinek wrote:
> > > As we aren't implementing OpenMP 5.0 fully yet and especially because
> > > we aren't implementing the new nesting ICV semantics, we shouldn't do it 
> > > now,
> > > they are valid in OpenMP 4.5.
> > 
> > OK, that applies to omp_[gs]et_nested.
> > 
> > How about the lock symbols?  All the sync symbols are already defined as
> > aliases (or more correctly, the other way around).  The sooner people
> > change, the better, and at least those parts of OpenMP5 are "implemented".
> 
> We ignore the hints, so "implemented" is the right term ;).
> 
> I'd say there is no hurry for them either, I believe what is deprecated in
> 5.0 is going to be removed only (if at all) in 6.0, so like 5 years from
> now, so waiting until we implement all of OpenMP 5.0 shouldn't hurt that
> much.

E.g. if somebody tries hard to write portable OpenMP code and has:
  omp_lock_t lock;
  #if __OPENMP__ >= 201811L
  omp_init_lock_with_hint (, omp_sync_hint_contended);
  #elif __OPENMP__ >= 201511L
  omp_init_lock_with_hint (, omp_lock_hint_contended);
  #else
  omp_init_lock ();
  #endif
they would now get a warning even when they did the right thing.
So, deprecating those when we change __OPENMP__ macro is the right thing.

Jakub


New Spanish PO file for 'gcc' (version 8.2.0)

2019-01-02 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/es.po

(This file, 'gcc-8.2.0.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.




Re: deprecations in OpenMP 5.0

2019-01-02 Thread Jakub Jelinek
On Wed, Jan 02, 2019 at 06:23:57PM +0100, Ulrich Drepper wrote:
> On 1/2/19 6:21 PM, Jakub Jelinek wrote:
> > As we aren't implementing OpenMP 5.0 fully yet and especially because
> > we aren't implementing the new nesting ICV semantics, we shouldn't do it 
> > now,
> > they are valid in OpenMP 4.5.
> 
> OK, that applies to omp_[gs]et_nested.
> 
> How about the lock symbols?  All the sync symbols are already defined as
> aliases (or more correctly, the other way around).  The sooner people
> change, the better, and at least those parts of OpenMP5 are "implemented".

We ignore the hints, so "implemented" is the right term ;).

I'd say there is no hurry for them either, I believe what is deprecated in
5.0 is going to be removed only (if at all) in 6.0, so like 5 years from
now, so waiting until we implement all of OpenMP 5.0 shouldn't hurt that
much.

Jakub


Re: deprecations in OpenMP 5.0

2019-01-02 Thread Ulrich Drepper
On 1/2/19 6:21 PM, Jakub Jelinek wrote:
> As we aren't implementing OpenMP 5.0 fully yet and especially because
> we aren't implementing the new nesting ICV semantics, we shouldn't do it now,
> they are valid in OpenMP 4.5.

OK, that applies to omp_[gs]et_nested.

How about the lock symbols?  All the sync symbols are already defined as
aliases (or more correctly, the other way around).  The sooner people
change, the better, and at least those parts of OpenMP5 are "implemented".




signature.asc
Description: OpenPGP digital signature


Re: deprecations in OpenMP 5.0

2019-01-02 Thread Jakub Jelinek
On Wed, Jan 02, 2019 at 05:58:07PM +0100, Ulrich Drepper wrote:
> Should we mark the symbols that are deprecated in OpenMP 5.0 as such in
> the header?  Yes, this will break code that uses the symbols and -Werror
> but this is the standard writers intend, right?  It's easy enough to
> work around for the time being.

As we aren't implementing OpenMP 5.0 fully yet and especially because
we aren't implementing the new nesting ICV semantics, we shouldn't do it now,
they are valid in OpenMP 4.5.

We can reconsider that for GCC 10 if all of OpenMP 5.0 is implemented by
then or at least that nesting semantics and we want people to move over.

Jakub


deprecations in OpenMP 5.0

2019-01-02 Thread Ulrich Drepper
Should we mark the symbols that are deprecated in OpenMP 5.0 as such in
the header?  Yes, this will break code that uses the symbols and -Werror
but this is the standard writers intend, right?  It's easy enough to
work around for the time being.

Aside from the header changes the files implementing the
omp_[gs]et_nested functions had to be changed.  I just use the pragma to
disable the warning temporarily instead of a more global option like
using -Wno-deprecated-declarations in the Makefile.

What do people think about this?


2019-01-02  Ulrich Drepper  

   Newly deprecated symbols in OpenMP 5.0.
   * omp.h.in (__GOMP_DEPRECATED): Define.
   Make omp_lock_hint_* enum values, omp_lock_hint_t, omp_set_nested,
   and omp_get_nested with __GOMP_DEPRECATED.
   * fortran.c: Wrap uses of omp_set_nested and omp_get_nested with
   pragmas to ignore -Wdeprecated-declarations warnings.
   * icv.c: Likewise.
diff --git a/libgomp/fortran.c b/libgomp/fortran.c
index 4d544be1c99..24d361157f0 100644
--- a/libgomp/fortran.c
+++ b/libgomp/fortran.c
@@ -47,10 +47,13 @@ ialias_redirect (omp_test_lock)
 ialias_redirect (omp_test_nest_lock)
 # endif
 ialias_redirect (omp_set_dynamic)
-ialias_redirect (omp_set_nested)
-ialias_redirect (omp_set_num_threads)
 ialias_redirect (omp_get_dynamic)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+ialias_redirect (omp_set_nested)
 ialias_redirect (omp_get_nested)
+#pragma GCC diagnostic pop
+ialias_redirect (omp_set_num_threads)
 ialias_redirect (omp_in_parallel)
 ialias_redirect (omp_get_max_threads)
 ialias_redirect (omp_get_num_procs)
@@ -276,6 +279,8 @@ omp_set_dynamic_8_ (const int64_t *set)
   omp_set_dynamic (!!*set);
 }
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
 void
 omp_set_nested_ (const int32_t *set)
 {
@@ -287,6 +292,7 @@ omp_set_nested_8_ (const int64_t *set)
 {
   omp_set_nested (!!*set);
 }
+#pragma GCC diagnostic pop
 
 void
 omp_set_num_threads_ (const int32_t *set)
@@ -306,11 +312,14 @@ omp_get_dynamic_ (void)
   return omp_get_dynamic ();
 }
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
 int32_t
 omp_get_nested_ (void)
 {
   return omp_get_nested ();
 }
+#pragma GCC diagnostic pop
 
 int32_t
 omp_in_parallel_ (void)
diff --git a/libgomp/icv.c b/libgomp/icv.c
index 095d57a93b1..af0f4c0596e 100644
--- a/libgomp/icv.c
+++ b/libgomp/icv.c
@@ -51,6 +51,8 @@ omp_get_dynamic (void)
   return icv->dyn_var;
 }
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
 void
 omp_set_nested (int val)
 {
@@ -64,6 +66,7 @@ omp_get_nested (void)
   struct gomp_task_icv *icv = gomp_icv (false);
   return icv->nest_var;
 }
+#pragma GCC diagnostic pop
 
 void
 omp_set_schedule (omp_sched_t kind, int chunk_size)
@@ -198,10 +201,13 @@ omp_get_partition_place_nums (int *place_nums)
 }
 
 ialias (omp_set_dynamic)
-ialias (omp_set_nested)
-ialias (omp_set_num_threads)
 ialias (omp_get_dynamic)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+ialias (omp_set_nested)
 ialias (omp_get_nested)
+#pragma GCC diagnostic pop
+ialias (omp_set_num_threads)
 ialias (omp_set_schedule)
 ialias (omp_get_schedule)
 ialias (omp_get_max_threads)
diff --git a/libgomp/omp.h.in b/libgomp/omp.h.in
index d7ac71400ad..060ee374829 100644
--- a/libgomp/omp.h.in
+++ b/libgomp/omp.h.in
@@ -26,6 +26,13 @@
 #ifndef _OMP_H
 #define _OMP_H 1
 
+
+#ifdef __GNUC__
+# define __GOMP_DEPRECATED __attribute__((__deprecated__))
+#else
+# define __GOMP_DEPRECATED
+#endif
+
 #ifndef _LIBGOMP_OMP_LOCK_DEFINED
 #define _LIBGOMP_OMP_LOCK_DEFINED 1
 /* These two structures get edited by the libgomp build process to 
@@ -66,18 +73,18 @@ typedef enum omp_proc_bind_t
 typedef enum omp_sync_hint_t
 {
   omp_sync_hint_none = 0,
-  omp_lock_hint_none = omp_sync_hint_none,
+  omp_lock_hint_none __GOMP_DEPRECATED = omp_sync_hint_none,
   omp_sync_hint_uncontended = 1,
-  omp_lock_hint_uncontended = omp_sync_hint_uncontended,
+  omp_lock_hint_uncontended __GOMP_DEPRECATED = omp_sync_hint_uncontended,
   omp_sync_hint_contended = 2,
-  omp_lock_hint_contended = omp_sync_hint_contended,
+  omp_lock_hint_contended __GOMP_DEPRECATED = omp_sync_hint_contended,
   omp_sync_hint_nonspeculative = 4,
-  omp_lock_hint_nonspeculative = omp_sync_hint_nonspeculative,
+  omp_lock_hint_nonspeculative __GOMP_DEPRECATED = 
omp_sync_hint_nonspeculative,
   omp_sync_hint_speculative = 8,
-  omp_lock_hint_speculative = omp_sync_hint_speculative
+  omp_lock_hint_speculative __GOMP_DEPRECATED = omp_sync_hint_speculative
 } omp_sync_hint_t;
 
-typedef omp_sync_hint_t omp_lock_hint_t;
+typedef __GOMP_DEPRECATED omp_sync_hint_t omp_lock_hint_t;
 
 typedef struct __attribute__((__aligned__ (sizeof (void * omp_depend_t
 {
@@ -108,8 +115,8 @@ extern int omp_in_parallel (void) __GOMP_NOTHROW;
 extern void omp_set_dynamic (int) 

C++ PATCH to add test for c++/86875

2019-01-02 Thread Marek Polacek
The testcase in this PR was fixed by r267272, so I've reduced it and am going
to add it to the testsuite.

Tested on x86_64-linux (and with -m32), applying onto trunk.

2019-01-02  Marek Polacek  

PR c++/86875
* g++.dg/cpp1y/lambda-generic-86875.C: New test.

diff --git gcc/testsuite/g++.dg/cpp1y/lambda-generic-86875.C 
gcc/testsuite/g++.dg/cpp1y/lambda-generic-86875.C
new file mode 100644
index 000..3a81b00df96
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-86875.C
@@ -0,0 +1,21 @@
+// PR c++/86875
+// { dg-do compile { target c++14 } }
+
+template  using decay_t = _Tp;
+template  class A {
+  Fun fun_;
+
+public:
+  template  A(T p1) : fun_(p1) {}
+  auto operator()() { fun_(this); }
+};
+
+template  auto y_combinator(Fun p1) { return A>(p1); }
+
+int
+main()
+{
+  const unsigned int w = 1;
+  auto foo = y_combinator([=](auto) { auto i = +w; });
+  foo();
+}


Re: [patch, fortran] Fix PR 88658, wrong type for MAX1 and friends type when simplifying

2019-01-02 Thread Dominique d'Humières
Hi Thomas,

Your patch LGTM (and works as expected).

Thanks for the quick fix and happy new year,

Dominique



[PATCH] Add more testcases for class template argument deduction of maps

2019-01-02 Thread Jonathan Wakely

This adds additional tests for std::map and std::multimap CTAD. The
tests ensure that deduction works for braced-init-list of value_type
objects, and for pairs of input iterators (with both std::pair
and value_type as the iterator's value_type). This ensures deduction
from value_type still works, as well as the non-value_type cases in LWG
3025.

Similar tests for unordered maps do not work, apparently because the
constructor taking an initializer_list is not usable for
deduction, and the deduction guide taking initializer_list>
deduces key_type to be const. I am not addressing that.

* testsuite/23_containers/map/cons/deduction.cc: Test deduction from
initializer_list and from input iterator ranges.
* testsuite/23_containers/multimap/cons/deduction.cc: Likewise.

Tested x86_64-linux, committed to trunk.


commit d595c72ef9482a8597493f49a263258dbe634776
Author: Jonathan Wakely 
Date:   Wed Jan 2 15:42:29 2019 +

Add more testcases for class template argument deduction of maps

This adds additional tests for std::map and std::multimap CTAD. The
tests ensure that deduction works for braced-init-list of value_type
objects, and for pairs of input iterators (with both std::pair
and value_type as the iterator's value_type). This ensures deduction
from value_type still works, as well as the non-value_type cases in LWG
3025.

Similar tests for unordered maps do not work, apparently because the
constructor taking an initializer_list is not usable for
deduction, and the deduction guide taking initializer_list>
deduces key_type to be const. I am not addressing that.

* testsuite/23_containers/map/cons/deduction.cc: Test deduction from
initializer_list and from input iterator ranges.
* testsuite/23_containers/multimap/cons/deduction.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/23_containers/map/cons/deduction.cc 
b/libstdc++-v3/testsuite/23_containers/map/cons/deduction.cc
index 3880cd5e79d..f4195257e9c 100644
--- a/libstdc++-v3/testsuite/23_containers/map/cons/deduction.cc
+++ b/libstdc++-v3/testsuite/23_containers/map/cons/deduction.cc
@@ -3,32 +3,58 @@
 
 #include 
 #include 
+#include 
 
 using __gnu_test::SimpleAllocator;
+using value_type = std::map::value_type;
+
+static_assert(std::is_same_v<
+ decltype(std::map{value_type{1, 2.0}, {2, 3.0}, {3, 4.0}}),
+ std::map>);
 
 static_assert(std::is_same_v<
  decltype(std::map{std::pair{1, 2.0}, {2, 3.0}, {3, 4.0}}),
  std::map>);
 
+static_assert(std::is_same_v<
+ decltype(std::map{{value_type{1, 2.0}, {2, 3.0}, {3, 4.0}}}),
+ std::map>);
+
 static_assert(std::is_same_v<
  decltype(std::map{{std::pair{1, 2.0}, {2, 3.0}, {3, 4.0}}}),
  std::map>);
 
 static_assert(std::is_same_v<
- decltype(std::map{{std::pair{1, 2.0}, {2, 3.0}, {3, 4.0}},
-   std::less{}, {}}),
+ decltype(std::map{{value_type{1, 2.0}, {2, 3.0}, {3, 4.0}},
+   std::less{}, {}}),
  std::map>);
 
 static_assert(std::is_same_v<
  decltype(std::map{{std::pair{1, 2.0}, {2, 3.0}, {3, 4.0}},
-   {}}),
+   std::less{}, {}}),
+ std::map>);
+
+/* This is not deducible, {} could be deduced as _Compare or _Allocator.
+static_assert(std::is_same_v<
+ decltype(std::map{{value_type{1, 2.0}, {2, 3.0}, {3, 4.0}}, {}}),
+ std::map>);
+*/
+
+static_assert(std::is_same_v<
+ decltype(std::map{{std::pair{1, 2.0}, {2, 3.0}, {3, 4.0}}, {}}),
  std::map>);
 
 static_assert(std::is_same_v<
- decltype(std::map{{std::pair{1, 2.0}, {2, 3.0}, {3, 4.0}},
-   {}, SimpleAllocator>{}}),
+ decltype(std::map{{value_type{1, 2.0}, {2, 3.0}, {3, 4.0}},
+   {}, SimpleAllocator{}}),
  std::map,
- SimpleAllocator>>>);
+  SimpleAllocator>>);
+
+static_assert(std::is_same_v<
+ decltype(std::map{{std::pair{1, 2.0}, {2, 3.0}, {3, 4.0}},
+   {}, SimpleAllocator{}}),
+ std::map,
+  SimpleAllocator>>);
 
 void f()
 {
@@ -39,13 +65,13 @@ void f()
 
   static_assert(std::is_same_v<
decltype(std::map{x.begin(), x.end(),
- std::less{},
- std::allocator>{}}),
+ std::less{},
+ std::allocator{}}),
std::map>);
-  
+
   static_assert(std::is_same_v<
decltype(std::map{x.begin(), x.end(),
- std::less{}, {}}),
+ std::less{}, {}}),
std::map>);
 
   static_assert(std::is_same_v<
@@ -55,14 +81,95 @@ void f()
 
   static_assert(std::is_same_v<
   

[Fortran, test case, committed] Test case for PR 48543

2019-01-02 Thread Thomas Koenig

Hell world,

somebody fixed PR 48543 for us, so I have committed the
attached test case as obvious and closed the PR.  Thanks
to however did this!

Regards

Thomas

2019-01-02  Thomas Koenig  

PR fortran/48543
* gfortran.dg/const_chararacter_merge.f90: New test.
! { dg-do compile }
! { dg-options "-Os" }
! PR 48543
program main
  character(len=17) :: a
  character(len=34) :: b
  a = 'Supercalifragilis'
  b = 'Supercalifragilisticexpialidocious'
  print *,a," ",b
end program main
! { dg-final { scan-assembler-times "Supercalifragilis" 1 } }


Fix ICE in copy_function_or_variable

2019-01-02 Thread Jan Hubicka
Hi,
this patch fixes ICE when at WPA we try to look for ctor which was
removed at compilation time and thus not streamed.  While testcase seems
to reproduce only on gcc 9, this is old bug and thus the fix should be
backported to gcc 8 and 7 after some additional testing.

Bootstrapped/regtested x86_64-linux, comitted.

PR lto/88130
* varpool.c (varpool_node::ctor_useable_for_folding_p): Also return
false at WPA time when body was removed.
* g++.dg/torture/pr88130.C: New testcase.
Index: varpool.c
===
--- varpool.c   (revision 267499)
+++ varpool.c   (working copy)
@@ -335,16 +335,16 @@ varpool_node::ctor_useable_for_folding_p
   if (TREE_THIS_VOLATILE (decl))
 return false;
 
+  /* Avoid attempts to load constructors that was not streamed.  */
+  if (in_lto_p && DECL_INITIAL (real_node->decl) == error_mark_node
+  && real_node->body_removed)
+return false;
+
   /* If we do not have a constructor, we can't use it.  */
   if (DECL_INITIAL (real_node->decl) == error_mark_node
   && !real_node->lto_file_data)
 return false;
 
-  /* Avoid attempts to load constructors that was not streamed.  */
-  if (flag_ltrans && DECL_INITIAL (real_node->decl) == error_mark_node
-  && real_node->body_removed)
-return false;
-
   /* Vtables are defined by their types and must match no matter of 
interposition
  rules.  */
   if (DECL_VIRTUAL_P (decl))
Index: testsuite/g++.dg/torture/pr88130.C
===
--- testsuite/g++.dg/torture/pr88130.C  (nonexistent)
+++ testsuite/g++.dg/torture/pr88130.C  (working copy)
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+/* { dg-options "-flto" } */
+/* { dg-require-effective-target lto } */
+class a {
+public:
+  static const long b = 1;
+};
+struct c {
+  enum d { e };
+};
+class C;
+class f {
+public:
+  f(c::d);
+  template  C operator<=(g);
+};
+class C {
+public:
+  template  void operator!=(h &);
+};
+void i() {
+  f j(c::e);
+  try {
+j <= 0 != a::b;
+  } catch (...) {
+  }
+}


Re: [patch] Add OpenACC Fortran support for deviceptr and variable in common blocks

2019-01-02 Thread Chung-Lin Tang

Hi Jakub,
I have updated this patch and rebased with current trunk. The issues you 
identified
in the last review should all be resolved. Is this now okay for trunk?

Thanks, and Happy New Year~
Chung-Lin

Index: gcc/fortran/openmp.c
===
--- gcc/fortran/openmp.c(revision 267513)
+++ gcc/fortran/openmp.c(working copy)
@@ -914,10 +914,11 @@ omp_inv_mask::omp_inv_mask (const omp_mask ) : o
mapping.  */
 
 static bool
-gfc_match_omp_map_clause (gfc_omp_namelist **list, gfc_omp_map_op map_op)
+gfc_match_omp_map_clause (gfc_omp_namelist **list, gfc_omp_map_op map_op,
+ bool common_blocks = true)
 {
   gfc_omp_namelist **head = NULL;
-  if (gfc_match_omp_variable_list ("", list, false, NULL, , true)
+  if (gfc_match_omp_variable_list ("", list, common_blocks, NULL, , true)
   == MATCH_YES)
 {
   gfc_omp_namelist *n;
@@ -1156,12 +1157,12 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
  && openacc
  && gfc_match ("device ( ") == MATCH_YES
  && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
-  OMP_MAP_FORCE_TO))
+  OMP_MAP_FORCE_TO, false))
continue;
  if ((mask & OMP_CLAUSE_DEVICEPTR)
  && gfc_match ("deviceptr ( ") == MATCH_YES
  && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
-  OMP_MAP_FORCE_DEVICEPTR))
+  OMP_MAP_FORCE_DEVICEPTR, false))
continue;
  if ((mask & OMP_CLAUSE_DEVICE_RESIDENT)
  && gfc_match_omp_variable_list
@@ -1531,7 +1532,7 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
  if ((mask & OMP_CLAUSE_PRESENT)
  && gfc_match ("present ( ") == MATCH_YES
  && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
-  OMP_MAP_FORCE_PRESENT))
+  OMP_MAP_FORCE_PRESENT, false))
continue;
  if ((mask & OMP_CLAUSE_COPY)
  && gfc_match ("present_or_copy ( ") == MATCH_YES
@@ -3762,7 +3763,7 @@ check_symbol_not_pointer (gfc_symbol *sym, locus l
 /* Emits error when symbol represents assumed size/rank array.  */
 
 static void
-check_array_not_assumed (gfc_symbol *sym, locus loc, const char *name)
+check_oacc_array_not_assumed (gfc_symbol *sym, locus loc, const char *name)
 {
   if (sym->as && sym->as->type == AS_ASSUMED_SIZE)
 gfc_error ("Assumed size array %qs in %s clause at %L",
@@ -3770,10 +3771,6 @@ static void
   if (sym->as && sym->as->type == AS_ASSUMED_RANK)
 gfc_error ("Assumed rank array %qs in %s clause at %L",
   sym->name, name, );
-  if (sym->as && sym->as->type == AS_DEFERRED && sym->attr.pointer
-  && !sym->attr.contiguous)
-gfc_error ("Noncontiguous deferred shape array %qs in %s clause at %L",
-  sym->name, name, );
 }
 
 static void
@@ -3788,7 +3785,7 @@ resolve_oacc_data_clauses (gfc_symbol *sym, locus
 gfc_error ("ALLOCATABLE object %qs of polymorphic type "
   "in %s clause at %L", sym->name, name, );
   check_symbol_not_pointer (sym, loc, name);
-  check_array_not_assumed (sym, loc, name);
+  check_oacc_array_not_assumed (sym, loc, name);
 }
 
 static void
@@ -3817,7 +3814,7 @@ resolve_oacc_deviceptr_clause (gfc_symbol *sym, lo
   if (sym->attr.value)
 gfc_error ("VALUE object %qs in %s clause at %L",
   sym->name, name, );
-  check_array_not_assumed (sym, loc, name);
+  check_oacc_array_not_assumed (sym, loc, name);
 }
 
 
@@ -4508,7 +4505,7 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_claus
  }
if (code
&& (oacc_is_loop (code) || code->op == EXEC_OACC_PARALLEL))
- check_array_not_assumed (n->sym, n->where, name);
+ check_oacc_array_not_assumed (n->sym, n->where, name);
else if (n->sym->as && n->sym->as->type == AS_ASSUMED_SIZE)
  gfc_error ("Assumed size array %qs in %s clause at %L",
 n->sym->name, name, >where);
@@ -4725,7 +4722,7 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_claus
  /* FALLTHRU */
  case OMP_LIST_DEVICE_RESIDENT:
check_symbol_not_pointer (n->sym, n->where, name);
-   check_array_not_assumed (n->sym, n->where, name);
+   check_oacc_array_not_assumed (n->sym, n->where, name);
break;
  default:
break;
@@ -5760,7 +5757,13 @@ resolve_oacc_nested_loops (gfc_code *code, gfc_cod
 "at %L", _code->loc);
  break;
}
-  gcc_assert (do_code->op == EXEC_DO || do_code->op == EXEC_DO_CONCURRENT);
+  if (do_code->op == EXEC_DO_CONCURRENT)
+   

Re: [committed] Fix a couple minor problems with string length range computations

2019-01-02 Thread H.J. Lu
On Tue, Jan 1, 2019 at 10:02 PM Jeff Law  wrote:
>
>
> So the first of probably 3 patches to fix issues with string length
> computations now that the underlying infrastructure is in place.  Like
> the prior patches, this is primarily Martin's work.  My contribution has
> been to break it down into more manageable hunks.
>
> In this patch we change the external API for get_range_strlen to pass in
> the c_strlen_data pointer.  Hence the various changes in client code
> such as builtins.c, calls.c, tree-ssa-strlen.c, etc.
>
> Internally in the public get_range_strlen we also massage the result of
> the internal call slightly.  For example, if the internal call fails, we
> set the range info to impossible values that we can check for elsewhere.
>  If the internal call didn't set maxbound, then we set it to an
> appropriate value, etc.
>
> With the change in how failures are reported we twiddle the sprintf call
> site slightly more than the others since it cares.  Ultimately it's a
> slight simplification.  This patch also fixes when we set the unlikely
> range.
>
> There's a few new tests and Martin made a couple tweaks to existing
> tests that are included in this patch.
>
> Bootstrapped and regression tested on x86_64.  My testers will iterate
> on this overnight for the other targets.
>
> Committing to the trunk momentarily.
>

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88663

-- 
H.J.


[patch, fortran] Fix PR 88658, wrong type for MAX1 and friends type when simplifying

2019-01-02 Thread Thomas Koenig

Hello world,

the attached patch fixes the PR, a regression introduced by r265649,
by special-casing those intrinsics of the min/max family which
need to be special-cased.

This is actually something that had been fixed before (PR 14377),
but at the time, no test case had been committed.

Regression-tested. OK for trunk?

Regards

Thomas

2019-01-02  Thomas Koenig  

PR fortran/88658
* gfortran.h: Add macro gfc_real_4_kind
* simplify.c (simplify_min_max): Special case for the types of
AMAX0, AMIN0, MAX1 and MIN1, which actually change the types of
their arguments.

2019-01-02  Thomas Koenig  

PR fortran/88658
* gfortran.dg/min_max_type_2.f90: New test.
Index: gfortran.h
===
--- gfortran.h	(Revision 267335)
+++ gfortran.h	(Arbeitskopie)
@@ -2967,6 +2967,7 @@ extern int gfc_character_storage_size;
 
 #define gfc_logical_4_kind 4
 #define gfc_integer_4_kind 4
+#define gfc_real_4_kind 4
 
 /* symbol.c */
 void gfc_clear_new_implicit (void);
Index: simplify.c
===
--- simplify.c	(Revision 267335)
+++ simplify.c	(Arbeitskopie)
@@ -4963,6 +4963,8 @@ static gfc_expr *
 simplify_min_max (gfc_expr *expr, int sign)
 {
   gfc_actual_arglist *arg, *last, *extremum;
+  gfc_expr *tmp, *ret;
+  const char *fname;
 
   last = NULL;
   extremum = NULL;
@@ -4995,7 +4997,27 @@ simplify_min_max (gfc_expr *expr, int sign)
   if (expr->value.function.actual->next != NULL)
 return NULL;
 
-  return gfc_copy_expr (expr->value.function.actual->expr);
+  /* Handle special cases of specific functions (min|max)1 and
+ a(min|max)0.  */
+
+  tmp = expr->value.function.actual->expr;
+  fname = expr->value.function.isym->name;
+
+  if ((tmp->ts.type != BT_INTEGER || tmp->ts.kind != gfc_integer_4_kind)
+  && (strcmp (fname, "min1") == 0 || strcmp (fname, "max1") == 0))
+{
+  ret = gfc_convert_constant (tmp, BT_INTEGER, gfc_integer_4_kind);
+}
+  else if ((tmp->ts.type != BT_REAL || tmp->ts.kind != gfc_real_4_kind)
+	   && (strcmp (fname, "amin0") == 0 || strcmp (fname, "amax0") == 0))
+{
+  ret = gfc_convert_constant (tmp, BT_REAL, gfc_real_4_kind);
+}
+  else
+ret = gfc_copy_expr (tmp);
+
+  return ret;
+
 }
 
 
! { dg-do  run }
! PR 88658 - make sure the types for min1, max1, amax0 and amin0 are
! correct when simplified

program main
  real :: RVCOMP
  character (len=12) :: line
  integer :: n

  RVCOMP = MAX1(2.3, 3.1, 4.4) / 5 
  if (rvcomp /= 0.) stop 1
  rvcomp = min1(2.3, 3.1, 5.1) / 5
  if (rvcomp /= 0.) stop 2
  write (unit=line, fmt='(F12.5)') amax0(42, 21, 7)
  if (line /= '42.0') stop 3
  write (unit=line, fmt='(F12.5)') amin0(42,21,7)
  if (line /= ' 7.0') stop 4
end program main


Re: [PATCH] Calculate prediction remainder at proper place (PR tree-optimization/88650).

2019-01-02 Thread Richard Biener
On Wed, Jan 2, 2019 at 12:14 PM Martin Liška  wrote:
>
> Hi.
>
> Following patch moves a probability calculation to a place where
> it's really used. Otherwise one can end up with division by zero
> that can't happen as there's no edge for which the probability
> would be used.
>
> Patch survives tests on x86_64-linux-gnu and bootstrap fine.
>
> Ready for trunk?
OK.

Richard.

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-01-02  Martin Liska  
>
> PR tree-optimization/88650
> * predict.c (set_even_probabilities): Calculate probability
> remainer only when really used.
>
> gcc/testsuite/ChangeLog:
>
> 2019-01-02  Martin Liska  
>
> PR tree-optimization/88650
> * gfortran.dg/predict-3.f90: New test.
> ---
>  gcc/predict.c   | 16 +++---
>  gcc/testsuite/gfortran.dg/predict-3.f90 | 28 +
>  2 files changed, 37 insertions(+), 7 deletions(-)
>  create mode 100644 gcc/testsuite/gfortran.dg/predict-3.f90
>
>


[PATCH] Fix PR88651

2019-01-02 Thread Richard Biener


The following should fix PR88651 (don't have UBSAN GCC to verify).
We mangle HWI max_stmt_execution result in ways not considering
overflow but max_stmt_execution can return quite large numbers.

The following switches the code over to widest_ints.

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

Richard.

2019-01-02  Richard Biener  

PR middle-end/88651
* tree-data-ref.c (analyze_subscript_affine_affine): Use
widest_ints when mangling max_stmt_execution results.

diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index d9a8d3a7d9d..7d1f03c66af 100644
--- a/gcc/tree-data-ref.c
+++ b/gcc/tree-data-ref.c
@@ -3761,10 +3761,6 @@ analyze_subscript_affine_affine (tree chrec_a,
 
  if (niter > 0)
{
- HOST_WIDE_INT tau2 = MIN (FLOOR_DIV (niter_a - i0, i1),
-   FLOOR_DIV (niter_b - j0, j1));
- HOST_WIDE_INT last_conflict = tau2 - (x1 - i0)/i1;
-
  /* If the overlap occurs outside of the bounds of the
 loop, there is no dependence.  */
  if (x1 >= niter_a || y1 >= niter_b)
@@ -3774,8 +3770,20 @@ analyze_subscript_affine_affine (tree chrec_a,
  *last_conflicts = integer_zero_node;
  goto end_analyze_subs_aa;
}
+
+ /* max stmt executions can get quite large, avoid
+overflows by using wide ints here.  */
+ widest_int tau2
+   = wi::smin (wi::sdiv_floor (wi::sub (niter_a, i0), i1),
+   wi::sdiv_floor (wi::sub (niter_b, j0), j1));
+ widest_int last_conflict = wi::sub (tau2, (x1 - i0)/i1);
+ if (wi::min_precision (last_conflict, SIGNED)
+ <= TYPE_PRECISION (integer_type_node))
+   *last_conflicts
+  = build_int_cst (integer_type_node,
+   last_conflict.to_shwi ());
  else
-   *last_conflicts = build_int_cst (NULL_TREE, last_conflict);
+   *last_conflicts = chrec_dont_know;
}
  else
*last_conflicts = chrec_dont_know;


Re: [PATCH] Don't run ident tests on powerpc-darwin

2019-01-02 Thread Rainer Orth
Hi Iain,

> The c-c++-common tests fail (or XPASS depending on which) on Darwin
> because it doesn't currently emit .ident marker. 
>
> For powerpc darwin (and, I think, AIX - hence copying David), there’s no
> .ident support in the assembler, and we need to skip the tests.
>
> In this case, I suggest that it’s not worth having a target-supports entry.
> This is because what a target chooses to emit for -fident is controlled by
> a target hook and therefore there’s no guarantee that a target-supports
> that triggers off “ .ident” in the asm would be generically useful.

however, if you look at the three implementations not using
default_asm_output_ident_directive (cris, microblaze, and pdp11), cris
calls the default if it does anything and the pdp11 string also includes
.ident.  Only microblaze desn't.

> OTOH, if the testsuite maintainers prefer a support .. it can be done ;-)

It's on the brink, I'd say.  The effective-keyword form is shorter and
more descriptive and can be extended to more targets way more easily.
Checking 2018-12 testresults, I find failures of the ident-*.c tests on
hppa2.0w-hp-hpux11.11 and powerpc-ibm-aix7.2.0.0.  If those were to be
handled as well, I'd strongly prefer the effective-keyword variant
rather than adding more and more targets to the individual tests.

Rainer

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


Re: [PATCH 4/4][libbacktrace] Add tests for unused formats

2019-01-02 Thread Iain Sandoe


> On 2 Jan 2019, at 13:20, Rainer Orth  wrote:
> 
> Gerald Pfeifer  writes:
> 
>> On Fri, 23 Nov 2018, Tom de Vries wrote:
>>> When building libbacktrace, we typically use elf.c, and don't build 
>>> pecoff.c, xcoff.c or unknown.c
>>> 
>>> Add testcases that use unused format to ensure that we also build and
>>> test those on a typical development setup.
>> 
>> This is a good idea!
>> 
>>> Bootstrapped and reg-tested on x86_64.
>> 
>> Unfortunately, on i586-unknown-freebsd11 I'm now seeing the likes of
>> 
>>  gmake[3]: *** [Makefile:1086: xcoff_32.lo] Error 1
>>  xcoff_64.c:54:29: error: extra tokens at end of #undef directive [-Werror]
>> 54 | #undef BACKTRACE_XCOFF_SIZEn#define BACKTRACE_XCOFF_SIZE 64
>>| ^
>>  xcoff_64.c:54:29: warning: extra tokens at end of #undef directive
>> 54 | #undef BACKTRACE_XCOFF_SIZEn#define BACKTRACE_XCOFF_SIZE 64
>>| ^
>>  cc1: all warnings being treated as errors
>>  gmake[3]: *** [Makefile:1086: xcoff_64.lo] Error 1
>> 
>> The reason is that GNU sed supports \n in the replacement pattern
>> 
>>  % echo "abc" | sed -E 's:b:\n:' 
>>  a
>>  c
>> 
>> whereas BSD sed does not
>> 
>>  % echo "abc" | sed -E 's:b:\n:' 
>>  anc
>> 
>> so the following in libbacktrace/Makefile.am doesn't work:
>> 
>>  xcoff_%.c: xcoff.c
>>  SEARCH='#error "Unknown BACKTRACE_XCOFF_SIZE"'; \
>>  REPLACE='#undef BACKTRACE_XCOFF_SIZE\n#define BACKTRACE_XCOFF_SIZE'; \
>>  $(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
>>  $(srcdir)/xcoff.c \
>>  > $@
>> 
>> 
>> I believe that in addition to FreeBSD this probably also fails on
>> Solaris and Darwin.
> 
> I cannot test Darwin right now,

I have builds running on a number of versions, will take a look 
- is it missing a “macho_xx.c” implementation, anyway ?

> but Solaris sed is indeed affected.  On
> Solaris 10 where there's only /usr/bin/sed (and /usr/xpg4/bin/sed which
> has the same issue), the failure does occur.  On Solaris 11 where I have
> GNU sed earlier in PATH, the issue is hidden.
> 
> Your patch does indeed fix the problem with Solaris 10 /bin/sed.
> 
> Unfortunately, libbacktrace is one of those libraries that don't produce
> Dejagnu-style .sum and .log files, so test failures are buried in the
> make check output and very easily overlooked.
> 
>   Rainer
> 
> -- 
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University



Re: [WIP] Reimplementation of IPA-SRA

2019-01-02 Thread Martin Liška
On 12/30/18 12:41 AM, Martin Jambor wrote:
> Any comments welcome,

Hi Martin.

I'll run smoke test for OBS Factory with -flto flags enabled for the patch.
So far I've noticed that current trunk can't profilebootstrap with following
configuration:

$ ../configure --enable-languages=c,c++,d --disable-multilib 
--disable-libsanitizer --disable-werror
...
$ make profiledbootstrap
...
during RTL pass: expand
/home/mliska/Programming/gcc/libphobos/src/std/range/package.d: In function 
‘sanitize’:
/home/mliska/Programming/gcc/libphobos/src/std/range/package.d:10053:5: 
internal compiler error: in make_decl_rtl, at varasm.c:1333
10053 | return SortedRange!(Unqual!R, pred)(r);
  | ^
0xa97a21 make_decl_rtl(tree_node*)
../../gcc/varasm.c:1333
0x1086da5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9938
0x151427c expand_expr
../../gcc/expr.h:279
0x151427c expand_expr_addr_expr_1
../../gcc/expr.c:7945
0x1086417 expand_expr_addr_expr
../../gcc/expr.c:8066
0x1086417 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11221
0x1085909 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10303
0x1514648 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5352
0x101a32e expand_gimple_stmt_1
../../gcc/cfgexpand.c:3746
0x101a32e expand_gimple_stmt
../../gcc/cfgexpand.c:3844
0x10185ad expand_gimple_basic_block
../../gcc/cfgexpand.c:5880
0x1015e31 execute
../../gcc/cfgexpand.c:6502

Martin



Re: [PATCH 4/4][libbacktrace] Add tests for unused formats

2019-01-02 Thread Rainer Orth
Gerald Pfeifer  writes:

> On Fri, 23 Nov 2018, Tom de Vries wrote:
>> When building libbacktrace, we typically use elf.c, and don't build 
>> pecoff.c, xcoff.c or unknown.c
>> 
>> Add testcases that use unused format to ensure that we also build and
>> test those on a typical development setup.
>
> This is a good idea!
>
>> Bootstrapped and reg-tested on x86_64.
>
> Unfortunately, on i586-unknown-freebsd11 I'm now seeing the likes of
>
>   gmake[3]: *** [Makefile:1086: xcoff_32.lo] Error 1
>   xcoff_64.c:54:29: error: extra tokens at end of #undef directive [-Werror]
>  54 | #undef BACKTRACE_XCOFF_SIZEn#define BACKTRACE_XCOFF_SIZE 64
> | ^
>   xcoff_64.c:54:29: warning: extra tokens at end of #undef directive
>  54 | #undef BACKTRACE_XCOFF_SIZEn#define BACKTRACE_XCOFF_SIZE 64
> | ^
>   cc1: all warnings being treated as errors
>   gmake[3]: *** [Makefile:1086: xcoff_64.lo] Error 1
>
> The reason is that GNU sed supports \n in the replacement pattern
>
>   % echo "abc" | sed -E 's:b:\n:' 
>   a
>   c
>
> whereas BSD sed does not
>
>   % echo "abc" | sed -E 's:b:\n:' 
>   anc
>
> so the following in libbacktrace/Makefile.am doesn't work:
>
>   xcoff_%.c: xcoff.c
>   SEARCH='#error "Unknown BACKTRACE_XCOFF_SIZE"'; \
>   REPLACE='#undef BACKTRACE_XCOFF_SIZE\n#define BACKTRACE_XCOFF_SIZE'; \
>   $(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
>   $(srcdir)/xcoff.c \
>   > $@
>
>
> I believe that in addition to FreeBSD this probably also fails on
> Solaris and Darwin.

I cannot test Darwin right now, but Solaris sed is indeed affected.  On
Solaris 10 where there's only /usr/bin/sed (and /usr/xpg4/bin/sed which
has the same issue), the failure does occur.  On Solaris 11 where I have
GNU sed earlier in PATH, the issue is hidden.

Your patch does indeed fix the problem with Solaris 10 /bin/sed.

Unfortunately, libbacktrace is one of those libraries that don't produce
Dejagnu-style .sum and .log files, so test failures are buried in the
make check output and very easily overlooked.

Rainer

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


Re: [PATCH] Use proper location for tls_init function (PR c++/88263).

2019-01-02 Thread Martin Liška
On 1/2/19 1:41 PM, Rainer Orth wrote:
> Hi Martin,
> 
>> The PR is about a function (__tls_init) that ends before it begins
>> (from line point of view). The patch uses location of a variable where
>> we first create the function declaration. I'm not much familiar with C++ FE,
>> but it works.
>>
>> Survives bootstrap and regression test on ppc64le-linux-gnu.
>>
>> Ready for trunk?
>> Thanks,
>> Martin
>>
>> gcc/cp/ChangeLog:
>>
>> 2018-11-30  Martin Liska  
>>
>>  PR c++/88263
>>  * decl2.c (get_local_tls_init_fn): Add location_t argument and
>>  use it.
>>  (get_tls_init_fn): Call it with location of variable for which
>>  we'll need to create tls_init function.
>>  (handle_tls_init): Likewise.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-11-30  Martin Liska  
>>
>>  * g++.dg/gcov/pr88263.C: New test.
> 
> the new testcase FAILs on Solaris:
> 
> +FAIL: g++.dg/gcov/pr88263.C   (test for excess errors)
> 
> Excess errors:
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr88263.C:7:11: error: 
> 'namespace log { }' conflicts with a previous declaration
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr88263.C:19:11: error: 
> 'namespace log { }' conflicts with a previous declaration
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr88263.C:21:33: error: 
> 'Logstream' has not been declared
> 
> /var/gcc/regression/trunk/11.5-gcc/build/gcc/include-fixed/iso/math_iso.h:69:15:
>  note: previous declaration 'namespace std { }::log'
> 
> +UNRESOLVED: g++.dg/gcov/pr88263.C   compilation failed to produce executable
> +FAIL: g++.dg/gcov/pr88263.C   gcov failed: pr88263.C.gcov does not exist
> 
>  has
> 
> namespace std {
> extern double log __P((double));
> extern "C++" {
>   inline float log(float __X) { return __logf(__X); }
>   inline long double log(long double __X) { return __logl(__X); }
> }
> }
> 
> Fixed by renaming namespace log to logging to avoid the clash.  Tested
> on i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu.
> Installed no mainline.

Thanks for the patch.

Martin

> 
>   Rainer
> 



Re: [PATCH 2/6, OpenACC, libgomp] Async re-work, oacc-* parts (revised, v2)

2019-01-02 Thread Chung-Lin Tang

Hi Thomas, Happy New Year,

On 2018/12/19 5:03 AM, Thomas Schwinge wrote:

+
+  if (!dev->openacc.async.asyncqueue[async])
+{
+  dev->openacc.async.asyncqueue[async] = dev->openacc.async.construct_func 
();
+
+  if (!dev->openacc.async.asyncqueue[async])
+   {
+ gomp_mutex_unlock (>openacc.async.lock);
+ gomp_fatal ("async %d creation failed", async);
+   }

That will now always fail for host fallback, where
"host_openacc_async_construct" just always does "return NULL".

Actually, if the device doesn't support asyncqueues, this whole function
should turn into some kind of no-op, so that we don't again and again try
to create a new one for every call to "lookup_goacc_asyncqueue".

I'm attaching one possible solution.  I think it's fine to assume that
the majority of devices will support asyncqueues, and for those that
don't, this is just a one-time overhead per async-argument.  So, no
special handling required in "lookup_goacc_asyncqueue".



--- a/libgomp/oacc-host.c
+++ b/libgomp/oacc-host.c
@@ -212,7 +212,8 @@ host_openacc_async_queue_callback (struct goacc_asyncqueue 
*aq
  static struct goacc_asyncqueue *
  host_openacc_async_construct (void)
  {
-  return NULL;
+  /* We have to return non-NULL here, but it's OK to use a dummy.  */
+  return (struct goacc_asyncqueue *) -1;
  }


I'm not sure I understand the meaning of this? Is there any use to segfaulting 
somewhere else
due to this 0x... pointer?

A feature of a NULL asyncqueue should mean that it is simply synchronous, 
however this does somewhat
conflict with the case of async.construct_func() returning NULL on error...

Perhaps, again using an explicit success code as the return value (and return 
asyncqueue using
an out parameter)?

Chung-Lin


Re: [PATCH] Use proper location for tls_init function (PR c++/88263).

2019-01-02 Thread Rainer Orth
Hi Martin,

> The PR is about a function (__tls_init) that ends before it begins
> (from line point of view). The patch uses location of a variable where
> we first create the function declaration. I'm not much familiar with C++ FE,
> but it works.
>
> Survives bootstrap and regression test on ppc64le-linux-gnu.
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/cp/ChangeLog:
>
> 2018-11-30  Martin Liska  
>
>   PR c++/88263
>   * decl2.c (get_local_tls_init_fn): Add location_t argument and
>   use it.
>   (get_tls_init_fn): Call it with location of variable for which
>   we'll need to create tls_init function.
>   (handle_tls_init): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> 2018-11-30  Martin Liska  
>
>   * g++.dg/gcov/pr88263.C: New test.

the new testcase FAILs on Solaris:

+FAIL: g++.dg/gcov/pr88263.C   (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr88263.C:7:11: error: 
'namespace log { }' conflicts with a previous declaration
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr88263.C:19:11: error: 
'namespace log { }' conflicts with a previous declaration
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr88263.C:21:33: error: 
'Logstream' has not been declared

/var/gcc/regression/trunk/11.5-gcc/build/gcc/include-fixed/iso/math_iso.h:69:15:
 note: previous declaration 'namespace std { }::log'

+UNRESOLVED: g++.dg/gcov/pr88263.C   compilation failed to produce executable
+FAIL: g++.dg/gcov/pr88263.C   gcov failed: pr88263.C.gcov does not exist

 has

namespace std {
extern double log __P((double));
extern "C++" {
inline float log(float __X) { return __logf(__X); }
inline long double log(long double __X) { return __logl(__X); }
}
}

Fixed by renaming namespace log to logging to avoid the clash.  Tested
on i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu.
Installed no mainline.

Rainer

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


2018-12-28  Rainer Orth  

* g++.dg/gcov/pr88263.C: Rename namespace log to logging.

# HG changeset patch
# Parent  2f1e3e01d8c86c4908cd3e52bf256667f8ae9bb8
Fix g++.dg/gcov/pr88263.C compilation on Solaris

diff --git a/gcc/testsuite/g++.dg/gcov/pr88263.C b/gcc/testsuite/g++.dg/gcov/pr88263.C
--- a/gcc/testsuite/g++.dg/gcov/pr88263.C
+++ b/gcc/testsuite/g++.dg/gcov/pr88263.C
@@ -4,7 +4,7 @@
 
 #include 
 
-namespace log {
+namespace logging {
 
 class Logstream {
 public:
@@ -16,7 +16,7 @@ private:
 
 }
 
-namespace log {
+namespace logging {
 
 thread_local std::ostringstream Logstream::os_;
 


[PATCH] Fix PR88621

2019-01-02 Thread Richard Biener


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

Richard.

2019-01-02  Richard Biener  

PR tree-optimization/88621
* tree-ssa-loop-im.c (gather_mem_refs_stmt): Fix pastos, avoid
bitfields when canoncalizing.

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

diff --git a/gcc/testsuite/gcc.dg/torture/pr88621.c 
b/gcc/testsuite/gcc.dg/torture/pr88621.c
new file mode 100644
index 000..78492a34dd7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr88621.c
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+
+struct S
+{
+  int b:4;
+  int c; 
+} e = { -1, 0 };
+
+int d, f;
+
+int main ()
+{
+  while (f)
+{
+  struct S g = { 0, 0 };
+  e = g;
+}
+L:
+  while (e.b > 0)
+;
+  e.b = 0;
+  if (d)
+goto L;
+  return 0;
+}
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 58da79d0545..0919931cec3 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -1468,9 +1468,10 @@ gather_mem_refs_stmt (struct loop *loop, gimple *stmt)
   tree mem_base;
   if (aor.max_size_known_p ()
  && aor.offset.is_constant ()
- && aor.offset.is_constant ()
- && aor.offset.is_constant (_size)
+ && aor.size.is_constant ()
+ && aor.max_size.is_constant (_size)
  && size == max_size
+ && (size % BITS_PER_UNIT) == 0
  && (mem_base = get_addr_base_and_unit_offset (aor.ref, _off)))
{
  hash = iterative_hash_expr (ao_ref_base (), 0);


Re: GCC 8 backports

2019-01-02 Thread Jan Hubicka
> 
> Honza, in order to make the test working I would need to backport
> r267495. Is it a good idea?

Yes, my apologies for the mistake! I should stop looking for failures
via grep and use test_summary consistently since I tend to miss
unresolved tests.  Old habits are hard to change.

Honza
> 
> Thanks,
> Martin


Re: Question on Disable no throw for -flive-patching master option.

2019-01-02 Thread Martin Liška
Honza: PING

On 12/6/18 12:16 AM, Qing Zhao wrote:
> Hi, Honza,
> 
> I have one question relate to whether to disable nothrow for -flive-patching 
> as following:
> 
> actually, there are two passes here:
> 
> 1. local nothrow pass:  in this pass, nothrow attribute is set locally after 
> analyzing every stmt of the function
> body: 
> 
> unsigned int
> pass_nothrow::execute (function *)
> {
>   struct cgraph_node *node;
>   basic_block this_block;
> …
> 
> }
> 
> 2. nothrow propagation pass:  (it’s included in the ipa_pure_const pass as 
> following, propagate the nothrow 
> attribute along callcgraph)
> 
> unsigned int
> pass_ipa_pure_const::
> execute (function *)
> {
>   bool remove_p;
> 
>   /* Nothrow makes more function to not lead to return and improve
>      later analysis.  */
>   propagate_nothrow ();
>   propagate_malloc ();
>   remove_p = propagate_pure_const ();
> 
>   delete funct_state_summaries;
>   return remove_p ? TODO_remove_functions : 0;
> }
> 
> the nothrow propagation pass is included in ipa_pure_const pass, and is 
> guarded by flag_ipa_pure_const, 
> this flag_ipa_pure_const is disabled when -flive-patching is ON.
> 
> 
> So, my question is:
> 
> shall we disable local nothrow pass as well when -flive-patching is ON?
> 
> my understanding is: we should. 
> 
> the reason is:   the local nothrow pass is setting the nothrow attribute for 
> the current routine based on its
> body,  and this “nothrow” attribute will be used  when generating EH code 
> around callsite from the caller
> of the routine. so the nothrow attribute might impact other routines than the 
> current routine.  as a result,
> we should disable this pass?
> 
> what’s your opinion on this?
> 
> thanks.
> 
> Qing
> 
>> On Nov 28, 2018, at 2:24 PM, Qing Zhao > > wrote:
>>>
>>> Shall we also disable nothrow or we will worry about C++ only ter?
>>
>> This is also mainly for C++ applications, so currently should not be a 
>> problem.
>> But I can add a separate simple patch to add another flag to control nothrow 
>> propagation and disable it when -flive-patching is ON.
>>
>>>
>>> Patch is OK,
>>
>> thanks for the review.
>>
>> I will commit the patch very soon.
>>
>> Qing
>>> thanks!
>>> Honza
> 


Re: GCC 8 backports

2019-01-02 Thread Martin Liška
On 12/28/18 12:24 PM, Sudakshina Das wrote:
> Hi Martin
> 
> On 27/12/18 12:32 PM, Martin Liška wrote:
>> On 11/20/18 11:58 AM, Martin Liška wrote:
>>> On 10/3/18 11:23 AM, Martin Liška wrote:
 On 9/25/18 8:48 AM, Martin Liška wrote:
> Hi.
>
> One more tested patch.
>
> Martin
>
 One more tested patch.

 Martin

>>> Hi.
>>>
>>> One another tested patch that I'm going to install.
>>>
>>> Martin
>>>
>> Hi.
>>
>> One another tested patch that I'm going to install.
>>
>> Thanks,
>> Martin
> 
> The last backport of r267338 causes the following failures on 
> arm-none-linux-gnueabihf and aarch64-none-linux-gnu
> 
> UNRESOLVED: g++.dg/tree-prof/devirt.C scan-ipa-dump-times dom3 "3" 
> folding virtual function call to virtual unsigned int 
> mozPersonalDictionary::AddRef
> UNRESOLVED: g++.dg/tree-prof/devirt.C scan-ipa-dump-times dom3 "3" 
> folding virtual function call to virtual unsigned int 
> mozPersonalDictionary::_ZThn16
> 
> with
> 
> g++.dg/tree-prof/devirt.C: dump file does not exist
> 
> Thanks
> 
> Sudi
> 

Honza, in order to make the test working I would need to backport
r267495. Is it a good idea?

Thanks,
Martin


Re: [ARM/FDPIC v4 00/20] FDPIC ABI for ARM

2019-01-02 Thread Christophe Lyon
Hi,

Ping^4 ?

Thanks,

Christophe



On Tue, 11 Dec 2018 at 11:27, Christophe Lyon  wrote:
>
> Ping?
>
>
> On 03/12/2018 10:19, Christophe Lyon wrote:
> > Ping?
> >
> > The series started here:
> > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01464.html
> >
> > Thanks,
> >
> > Christophe
> >
> > On Mon, 26 Nov 2018 at 11:14, Christophe Lyon
> >  wrote:
> >>
> >> Ping?
> >>
> >> Thanks
> >>
> >> On Fri, 16 Nov 2018 at 16:48, Christophe Lyon  
> >> wrote:
> >>>
> >>> From: Christophe Lyon 
> >>>
> >>> Hello,
> >>>
> >>> This patch series implements the GCC contribution of the FDPIC ABI for
> >>> ARM targets.
> >>>
> >>> This ABI enables to run Linux on ARM MMU-less cores and supports
> >>> shared libraries to reduce the memory footprint.
> >>>
> >>> Without MMU, text and data segments relative distances are different
> >>> from one process to another, hence the need for a dedicated FDPIC
> >>> register holding the start address of the data segment. One of the
> >>> side effects is that function pointers require two words to be
> >>> represented: the address of the code, and the data segment start
> >>> address. These two words are designated as "Function Descriptor",
> >>> hence the "FD PIC" name.
> >>>
> >>> On ARM, the FDPIC register is r9 [1], and the target name is
> >>> arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another
> >>> ABI and the BFLAT file format; it does not support code sharing.
> >>> The -mfdpic option is enabled by default, and -mno-fdpic should be
> >>> used to build the Linux kernel.
> >>>
> >>> This work was developed some time ago by STMicroelectronics, and was
> >>> presented during Linaro Connect SFO15 (September 2015). You can watch
> >>> the discussion and read the slides [2].
> >>> This presentation was related to the toolchain published on github [3],
> >>> which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1
> >>> and qemu-2.3.0, and for which pre-built binaries are available [3].
> >>>
> >>> The ABI itself is described in details in [1].
> >>>
> >>> Our Linux kernel patches have been updated and committed by Nicolas
> >>> Pitre (Linaro) in July 2017. They are required so that the loader is
> >>> able to handle this new file type. Indeed, the ELF files are tagged
> >>> with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as
> >>> well as the new relocations involved.
> >>>
> >>> The binutils, QEMU and uclibc-ng patch series have been merged
> >>> recently. [4][5][6]
> >>>
> >>> This series provides support for architectures that support ARM and/or
> >>> Thumb-2 and has been tested on arm-linux-gnueabi without regression,
> >>> as well as arm-uclinuxfdpiceabi, using QEMU. arm-uclinuxfdpiceabi has
> >>> more failures than arm-linux-gnueabi, but is quite functional.
> >>>
> >>> Are the GCC patches OK for inclusion in master?
> >>>
> >>> Changes between v3 and v4:
> >>>
> >>> - improved documentation (patch 1)
> >>> - emit an error message (sorry) if the target architecture does not
> >>>support arm nor thumb-2 modes (patch 4)
> >>> - handle Richard's comments on patch 4 (comments, unspec)
> >>> - added .align directive (patch 5)
> >>> - fixed use of kernel helpers (__kernel_cmpxchg, __kernel_dmb) (patch 6)
> >>> - code factorization in patch 7
> >>> - typos/internal function name in patch 8
> >>> - improved patch 12
> >>> - dropped patch 16
> >>> - patch 20 introduces arm_arch*_thumb_ok effective targets to help
> >>>skip some tests
> >>> - I tested patch 2 on xtensa-buildroot-uclinux-uclibc, it adds many
> >>>new tests, but a few regressions
> >>>(https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00713.html)
> >>> - I compiled and executed several LTP tests to exercise pthreads and 
> >>> signals
> >>> - I wrote and executed a simple testcase to change the interaction
> >>>with __kernel_cmpxchg (ie. call the kernel helper rather than use an
> >>>implementation in libgcc as requested by Richard)
> >>>
> >>> Changes between v2 and v3:
> >>> - added doc entry for -mfdpic new option
> >>> - took Kyrill's comments into account (use "Armv7" instead of "7",
> >>>code factorization, use preprocessor instead of hard-coding "r9",
> >>>remove leftover code for thumb1 support, fixed comments)
> >>> - rebase over recent trunk
> >>> - patches with changes: 1, 2 (commit message), 3 (rebase), 4, 6, 7, 9,
> >>>14 (rebase), 19 (rebase)
> >>>
> >>> Changes between v1 and v2:
> >>> - fix GNU coding style
> >>> - exit with an error for pre-Armv7
> >>> - use ACLE __ARM_ARCH and remove dead code for pre-Armv4
> >>> - remove unsupported attempts of pre-Armv7/thumb1 support
> >>> - add instructions in comments next to opcodes
> >>> - merge patches 11 and 13
> >>> - fixed protected visibility handling in patch 8
> >>> - merged legitimize_tls_address_fdpic and
> >>>legitimize_tls_address_not_fdpic as requested
> >>>
> >>> Thanks,
> >>>
> >>> Christophe.
> >>>
> >>>
> >>> [1] 

RE: [PATCH 7/9][GCC][Arm] Enable autovectorization of Half float values

2019-01-02 Thread Tamar Christina
Hi Kyrill,

> >
> > Bootstrap and Regtest on aarch64-none-linux-gnu, arm-none-gnueabihf
> > and x86_64-pc-linux-gnu are still on going but previous patch showed no
> regressions.
> >
> 
> Did the testing go okay in the end?

Yes it was clean.

> This looks ok to me but can you provide an example, or better yet, add a test
> that demonstrates this changes?

I've tried, but without the rest of the patch series I can't seem to come with 
an example that enters the given path.
The failure only happens when the vectorizer tries to vectorize to an unknown 
size. 

Most simple math operations would have a known size based on the vectorization 
factor, in any case, I'll hold off this patch then
Until the rest of the series is retried in stage 1.

Thanks,
Tamar

> 
> Thanks,
> Kyrill
> 
> > Ok for trunk?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > 2018-11-11  Tamar Christina  
> >
> > * config/arm/arm.c (arm_preferred_simd_mode): Add V4HF and V8HF.
> >
> > --



[PATCH] Calculate prediction remainder at proper place (PR tree-optimization/88650).

2019-01-02 Thread Martin Liška
Hi.

Following patch moves a probability calculation to a place where
it's really used. Otherwise one can end up with division by zero
that can't happen as there's no edge for which the probability
would be used.

Patch survives tests on x86_64-linux-gnu and bootstrap fine.

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2019-01-02  Martin Liska  

PR tree-optimization/88650
* predict.c (set_even_probabilities): Calculate probability
remainer only when really used.

gcc/testsuite/ChangeLog:

2019-01-02  Martin Liska  

PR tree-optimization/88650
* gfortran.dg/predict-3.f90: New test.
---
 gcc/predict.c   | 16 +++---
 gcc/testsuite/gfortran.dg/predict-3.f90 | 28 +
 2 files changed, 37 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/predict-3.f90


diff --git a/gcc/predict.c b/gcc/predict.c
index 745be185a29..0ac8adf286f 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -877,19 +877,21 @@ set_even_probabilities (basic_block bb,
 	int p = prediction->ep_probability;
 	profile_probability prob
 	  = profile_probability::from_reg_br_prob_base (p);
-	profile_probability remainder = prob.invert ();
-	remainder -= profile_probability::very_unlikely ()
-	  .apply_scale (unlikely_count, 1);
-	int count = nedges - unlikely_count - 1;
-	gcc_assert (count >= 0);
-	profile_probability even = remainder.apply_scale (1, count);
 
 	if (prediction->ep_edge == e)
 	  e->probability = prob;
 	else if (unlikely_edges != NULL && unlikely_edges->contains (e))
 	  e->probability = profile_probability::very_unlikely ();
 	else
-	  e->probability = even;
+	  {
+		profile_probability remainder = prob.invert ();
+		remainder -= profile_probability::very_unlikely ()
+		  .apply_scale (unlikely_count, 1);
+		int count = nedges - unlikely_count - 1;
+		gcc_assert (count >= 0);
+
+		e->probability = remainder.apply_scale (1, count);
+	  }
 	  }
 	else
 	  e->probability = profile_probability::never ();
diff --git a/gcc/testsuite/gfortran.dg/predict-3.f90 b/gcc/testsuite/gfortran.dg/predict-3.f90
new file mode 100644
index 000..f5437883f9d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/predict-3.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+! { dg-options "-fno-tree-fre -fno-tree-ccp -Og" }
+
+program simplify_transfer
+  call pr30881 ()
+contains
+  subroutine pr18769 ()
+type t
+end type t
+  end subroutine pr18769
+  subroutine pr30881 ()
+INTEGER, PARAMETER :: K=1
+I=TRANSFER(.TRUE.,K)
+SELECT CASE(I)
+  CASE(TRANSFER(.TRUE.,K))
+  CASE(TRANSFER(.FALSE.,K))
+STOP 2
+  CASE DEFAULT
+STOP 3
+END SELECT
+  END subroutine pr30881
+  subroutine pr31194 ()
+  end subroutine pr31194
+  subroutine pr31216 ()
+  END subroutine pr31216
+  subroutine pr31427 ()
+  END subroutine pr31427
+end program simplify_transfer



[PATCH] "Fix" PR87545

2019-01-02 Thread Richard Biener


This adjusts intel costs to reflect other intel CPU costs in _one_ place
to fix PR87545.  But I noted that -mtune=intel lacks any common sense
so please intel folks do your homework.

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

Richard.

2019-01-02  Richard Biener  

PR target/87545
* config/i386/x86-tune-costs.h (intel_cost): Adjust
cost of cheap SSE instruction.

Index: gcc/config/i386/x86-tune-costs.h
===
--- gcc/config/i386/x86-tune-costs.h(revision 267505)
+++ gcc/config/i386/x86-tune-costs.h(working copy)
@@ -2115,7 +2115,7 @@ struct processor_costs intel_cost = {
   COSTS_N_INSNS (8),   /* cost of FCHS instruction.  */
   COSTS_N_INSNS (40),  /* cost of FSQRT instruction.  */
 
-  COSTS_N_INSNS (8),   /* cost of cheap SSE instruction.  */
+  COSTS_N_INSNS (1),   /* cost of cheap SSE instruction.  */
   COSTS_N_INSNS (8),   /* cost of ADDSS/SD SUBSS/SD insns.  */
   COSTS_N_INSNS (8),   /* cost of MULSS instruction.  */
   COSTS_N_INSNS (8),   /* cost of MULSD instruction.  */


Re: [PATCH,Fortran] Suppress unclassifiable statement error message

2019-01-02 Thread Thomas Koenig

Hi Steve,


Due to the nuances of issuing error messages with ieee_selected_real_kind
when used in an initialization expression, it became painfully obvious
that gfortran will often issue an "Unclassifiable statement" error
as a run-on error.  I tried to make the "Unclassifiable ..." error a
fatal error, but there is at least one case were the US error is
emitted before a useful error message.  So, as a compromise I have
elected to make emitting a US error conditional on whether any other
error has been emitted.  Patch tested on i586-*-freebsd.  OK to commit?


Good idea!  OK for trunk, and thanks.

Regards

Thomas


Re: [RFA] fix copyright year range in libstdc++ test file (was: "Re: [v3 PATCH] Implement std::string_view and P0254r2, Integrating std::string_view and std::string.")

2019-01-02 Thread Jonathan Wakely

On 01/01/19 09:45 +0400, Joel Brobecker wrote:

Hello,

In working on updating the copyright year notices for the GDB files,
I noticed something very minor regarding the patch which added the
file below (the same file was copied in gdb's testsuite); it looks
like the year range for one of the files is truncated:

   | diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
   | new file mode 100644
   | index 000..c0f8206
   | --- /dev/null
   | +++ 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
   | @@ -0,0 +1,40 @@
   | +// { dg-options "-std=gnu++17" }
   | +
   | +// Copyright (C) 3 Free Software Foundation, Inc.

The file was contributed around July 2016, so it should be at least
2016-2018 now, but, looking at all the other test files around,
all ranges start with 2013, so I suspect the intention was for
this file to be the same. This is what the attached patch proposes.

libstdc++-v3/ChangeLog:

* testsuite/21_strings/basic_string_view/element_access/char/empty.cc:
   Fix year range in copyright header.

OK for trunk?

One a fix pushed to GCC, I will take care of the GDB side.


That file was copied from an older one in the testsuite (which is why
it has a date of 2013). This fixes the older one.

Committed to trunk.


commit 4f2fb88e3108defff663f51ebfddbdfb4a3b751a
Author: Jonathan Wakely 
Date:   Wed Jan 2 10:33:53 2019 +

Fix year range in copyright header

* testsuite/experimental/string_view/element_access/char/empty.cc:
Fix year range in copyright header.

diff --git a/libstdc++-v3/testsuite/experimental/string_view/element_access/char/empty.cc b/libstdc++-v3/testsuite/experimental/string_view/element_access/char/empty.cc
index 977e41e79ae..299447fefe8 100644
--- a/libstdc++-v3/testsuite/experimental/string_view/element_access/char/empty.cc
+++ b/libstdc++-v3/testsuite/experimental/string_view/element_access/char/empty.cc
@@ -1,6 +1,6 @@
 // { dg-do run { target c++14 } }
 
-// Copyright (C) 3 Free Software Foundation, Inc.
+// Copyright (C) 2013-2019 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the


[C++ PATCH] Fix ICEs with builtin redeclaration (PR c++/88636)

2019-01-02 Thread Jakub Jelinek
Hi!

On the following testcase we ICE, because pushdecl* ggc_frees the decl
passed to it, but builtin_function_1 returns it anyway.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2019-01-02  Jakub Jelinek  

PR c++/88636
* decl.c (builtin_function_1): Return result of pushdecl_top_level
or pushdecl rather than decl.

* g++.target/i386/pr88636.C: New test.

--- gcc/cp/decl.c.jj2018-12-20 08:50:29.68240 +0100
+++ gcc/cp/decl.c   2018-12-30 22:28:36.012759687 +0100
@@ -4536,11 +4536,9 @@ builtin_function_1 (tree decl, tree cont
 }
 
   if (is_global)
-pushdecl_top_level (decl);
+return pushdecl_top_level (decl);
   else
-pushdecl (decl);
-
-  return decl;
+return pushdecl (decl);
 }
 
 tree
--- gcc/testsuite/g++.target/i386/pr88636.C.jj  2018-12-31 10:11:18.224723703 
+0100
+++ gcc/testsuite/g++.target/i386/pr88636.C 2018-12-31 10:10:58.253050173 
+0100
@@ -0,0 +1,6 @@
+// PR c++/88636
+// { dg-do compile }
+// { dg-options "-msse2 -mno-sse3 -fno-exceptions --param ggc-min-heapsize=0" }
+
+extern unsigned int __builtin_ia32_crc32si (unsigned int, unsigned int);
+#pragma GCC target("sse4.2")

Jakub


Re: Fix devirtualiation in expanded thunks

2019-01-02 Thread Jan Hubicka
> On Wed, Jan 02, 2019 at 12:15:53AM +0100, Jan Hubicka wrote:
> > > /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/tree-prof/devirt.C:99:26:
> > >  optimized: folding virtual function call to virtual unsigned int 
> > > mozPersonalDictionary::_ZThn8_N21mozPersonalDictionary6AddRefEv()
> > > 
> > > > Is there a way to dump files for different patterns for 32bit or 64bit
> > > 
> > > Why would we: many similar scans just use _ZThn\[0-9\]+ instead.
> > 
> > Becuase the testcase was formely dispatching into ZThn8 (or some other
> > constant I forgot) instead of ZThn16 causing wrong code.
> > 
> > Well, there is runtime test that right thunk is used, so perhaps we can
> > just drop the part maching the actual value since most probably testcase
> > will ICE if wrong variant is picked again.
> 
> The testcase was written so that it aborts if it is miscompiled and succeeds
> otherwise, so I agree there is no urgent need for further dg-final scans on 
> it.
> 
> I don't think we have effective targets for various exact pointer sizes
> though, what we could do to cover most of the targets is e.g. following.
> Tested on x86_64-linux with both -m64 and -m32, ok for trunk?
> 
> 2019-01-02  Jakub Jelinek  
> 
>   PR ipa/88561
>   * g++.dg/tree-prof/devirt.C: Expect _ZThn16 only for lp64 and llp64 
> targets
>   and expect _ZThn8 for ilp32 targets.

Looks good to me, thanks for working on it.
Another option would be to just remove the 16 from string so we check
that devirtualization happens and at runtime we check that it goes right
way.

Honza


Re: Fix devirtualiation in expanded thunks

2019-01-02 Thread Jakub Jelinek
On Wed, Jan 02, 2019 at 12:15:53AM +0100, Jan Hubicka wrote:
> > /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/tree-prof/devirt.C:99:26: 
> > optimized: folding virtual function call to virtual unsigned int 
> > mozPersonalDictionary::_ZThn8_N21mozPersonalDictionary6AddRefEv()
> > 
> > > Is there a way to dump files for different patterns for 32bit or 64bit
> > 
> > Why would we: many similar scans just use _ZThn\[0-9\]+ instead.
> 
> Becuase the testcase was formely dispatching into ZThn8 (or some other
> constant I forgot) instead of ZThn16 causing wrong code.
> 
> Well, there is runtime test that right thunk is used, so perhaps we can
> just drop the part maching the actual value since most probably testcase
> will ICE if wrong variant is picked again.

The testcase was written so that it aborts if it is miscompiled and succeeds
otherwise, so I agree there is no urgent need for further dg-final scans on it.

I don't think we have effective targets for various exact pointer sizes
though, what we could do to cover most of the targets is e.g. following.
Tested on x86_64-linux with both -m64 and -m32, ok for trunk?

2019-01-02  Jakub Jelinek  

PR ipa/88561
* g++.dg/tree-prof/devirt.C: Expect _ZThn16 only for lp64 and llp64 
targets
and expect _ZThn8 for ilp32 targets.

--- gcc/testsuite/g++.dg/tree-prof/devirt.C.jj  2019-01-01 12:14:22.973597202 
+0100
+++ gcc/testsuite/g++.dg/tree-prof/devirt.C 2019-01-02 10:07:42.389899657 
+0100
@@ -1,4 +1,6 @@
+/* PR ipa/88561 */
 /* { dg-options "-O3 -fdump-tree-dom3-details" } */
+
 struct nsISupports
 {
   virtual int QueryInterface (const int , void **aInstancePtr) = 0;
@@ -119,5 +121,6 @@ main ()
 __builtin_abort ();
 }
 
-/* { dg-final-use-not-autofdo { scan-tree-dump-times "folding virtual function 
call to virtual unsigned int mozPersonalDictionary::_ZThn16" 1 "dom3" } } */
+/* { dg-final-use-not-autofdo { scan-tree-dump-times "folding virtual function 
call to virtual unsigned int mozPersonalDictionary::_ZThn16" 1 "dom3" { target 
{ lp64 || llp64 } } } } */
+/* { dg-final-use-not-autofdo { scan-tree-dump-times "folding virtual function 
call to virtual unsigned int mozPersonalDictionary::_ZThn8" 1 "dom3" { target 
ilp32 } } } */
 /* { dg-final-use-not-autofdo { scan-tree-dump-times "folding virtual function 
call to virtual unsigned int mozPersonalDictionary::AddRef" 1 "dom3" } } */


Jakub


Re: [PATCH 0/8] asm inline backport

2019-01-02 Thread Richard Biener
On Wed, Jan 2, 2019 at 10:09 AM Richard Biener
 wrote:
>
> On Thu, Dec 27, 2018 at 3:59 PM Segher Boessenkool
>  wrote:
> >
> > Hi!
> >
> > I'd like to backport the "asm inline" series to 8 branch and 7 branch.
> > The patches are identical to trunk, except I added a patch 8/8 that
> > makes these branches not error on code it only warned on before (that
> > is, C code that uses restrict or const as asm qualifier).
> >
> > The 7 backport has a context change in tree-inline.c, but everything
> > else is identical.
> >
> > The goal of backporting is that users (Linux, mostly) can start using
> > it sooner.
> >
> > Is this okay for 8?  Is it okay for 7?
>
> OK for GCC 8 and 7.

Btw, please make entries into gcc7/8/changes.html for this in the .dot
release sections (you might have to create a new one for the next releases).

Richard.

> Richard.
>
> >
> > Segher
> >
> >
> > Segher Boessenkool (8):
> >   asm qualifiers (PR55681)
> >   asm inline
> >   c: Delete a stray line in asm inline
> >   c/c++, asm: Write the asm-qualifier loop without "done" boolean
> >   c/c++, asm: Use nicer error for duplicate asm qualifiers
> >   c/c++, asm: Use nicer error for const and restrict
> >   c++, asm: Do not handle any asm-qualifiers in top-level asm
> >   c: Don't error for const or restrict as asm-qualifier
> >
> >  gcc/c/c-parser.c| 112 
> > ---
> >  gcc/c/c-tree.h  |   5 +-
> >  gcc/c/c-typeck.c|  11 ++-
> >  gcc/cp/cp-tree.h|   2 +-
> >  gcc/cp/parser.c | 117 
> > +---
> >  gcc/cp/pt.c |   2 +-
> >  gcc/cp/semantics.c  |   5 +-
> >  gcc/doc/extend.texi |  23 -
> >  gcc/gimple-pretty-print.c   |   2 +
> >  gcc/gimple.h|  26 +-
> >  gcc/gimplify.c  |   1 +
> >  gcc/ipa-icf-gimple.c|   3 +
> >  gcc/testsuite/c-c++-common/torture/asm-inline.c |  53 +++
> >  gcc/testsuite/g++.dg/asm-qual-1.C   |  13 +++
> >  gcc/testsuite/g++.dg/asm-qual-2.C   |  46 ++
> >  gcc/testsuite/g++.dg/asm-qual-3.C   |  12 +++
> >  gcc/testsuite/gcc.dg/asm-qual-1.c   |   8 +-
> >  gcc/testsuite/gcc.dg/asm-qual-2.c   |  46 ++
> >  gcc/testsuite/gcc.dg/asm-qual-3.c   |   9 ++
> >  gcc/tree-core.h |   3 +
> >  gcc/tree-inline.c   |   3 +
> >  gcc/tree.h  |   3 +
> >  22 files changed, 420 insertions(+), 85 deletions(-)
> >  create mode 100644 gcc/testsuite/c-c++-common/torture/asm-inline.c
> >  create mode 100644 gcc/testsuite/g++.dg/asm-qual-1.C
> >  create mode 100644 gcc/testsuite/g++.dg/asm-qual-2.C
> >  create mode 100644 gcc/testsuite/g++.dg/asm-qual-3.C
> >  create mode 100644 gcc/testsuite/gcc.dg/asm-qual-2.c
> >  create mode 100644 gcc/testsuite/gcc.dg/asm-qual-3.c
> >
> > --
> > 1.8.3.1
> >


Re: [PATCH 0/8] asm inline backport

2019-01-02 Thread Richard Biener
On Thu, Dec 27, 2018 at 3:59 PM Segher Boessenkool
 wrote:
>
> Hi!
>
> I'd like to backport the "asm inline" series to 8 branch and 7 branch.
> The patches are identical to trunk, except I added a patch 8/8 that
> makes these branches not error on code it only warned on before (that
> is, C code that uses restrict or const as asm qualifier).
>
> The 7 backport has a context change in tree-inline.c, but everything
> else is identical.
>
> The goal of backporting is that users (Linux, mostly) can start using
> it sooner.
>
> Is this okay for 8?  Is it okay for 7?

OK for GCC 8 and 7.

Richard.

>
> Segher
>
>
> Segher Boessenkool (8):
>   asm qualifiers (PR55681)
>   asm inline
>   c: Delete a stray line in asm inline
>   c/c++, asm: Write the asm-qualifier loop without "done" boolean
>   c/c++, asm: Use nicer error for duplicate asm qualifiers
>   c/c++, asm: Use nicer error for const and restrict
>   c++, asm: Do not handle any asm-qualifiers in top-level asm
>   c: Don't error for const or restrict as asm-qualifier
>
>  gcc/c/c-parser.c| 112 ---
>  gcc/c/c-tree.h  |   5 +-
>  gcc/c/c-typeck.c|  11 ++-
>  gcc/cp/cp-tree.h|   2 +-
>  gcc/cp/parser.c | 117 
> +---
>  gcc/cp/pt.c |   2 +-
>  gcc/cp/semantics.c  |   5 +-
>  gcc/doc/extend.texi |  23 -
>  gcc/gimple-pretty-print.c   |   2 +
>  gcc/gimple.h|  26 +-
>  gcc/gimplify.c  |   1 +
>  gcc/ipa-icf-gimple.c|   3 +
>  gcc/testsuite/c-c++-common/torture/asm-inline.c |  53 +++
>  gcc/testsuite/g++.dg/asm-qual-1.C   |  13 +++
>  gcc/testsuite/g++.dg/asm-qual-2.C   |  46 ++
>  gcc/testsuite/g++.dg/asm-qual-3.C   |  12 +++
>  gcc/testsuite/gcc.dg/asm-qual-1.c   |   8 +-
>  gcc/testsuite/gcc.dg/asm-qual-2.c   |  46 ++
>  gcc/testsuite/gcc.dg/asm-qual-3.c   |   9 ++
>  gcc/tree-core.h |   3 +
>  gcc/tree-inline.c   |   3 +
>  gcc/tree.h  |   3 +
>  22 files changed, 420 insertions(+), 85 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/torture/asm-inline.c
>  create mode 100644 gcc/testsuite/g++.dg/asm-qual-1.C
>  create mode 100644 gcc/testsuite/g++.dg/asm-qual-2.C
>  create mode 100644 gcc/testsuite/g++.dg/asm-qual-3.C
>  create mode 100644 gcc/testsuite/gcc.dg/asm-qual-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/asm-qual-3.c
>
> --
> 1.8.3.1
>


Re: [PATCH] Check requested alignment in SET_{DECL,TYPE}_ALIGN is pow2_or_zerop before aligning on targets with partial int modes

2019-01-02 Thread Richard Biener
On Sun, Dec 30, 2018 at 12:51 PM Jozef Lawrynowicz
 wrote:
>
> There have been some ICEs in the past for msp430-elf with the large
> memory model (20-bit pointers), caused by SET_{DECL,TYPE}_ALIGN being called
> with an argument which resolves to 20 i.e. POINTER_SIZE,
> or the default value of TARGET_VTABLE_ENTRY_ALIGN (which is POINTER_SIZE).
>
> The attached patch adds an assertion that SET_{DECL,TYPE}_ALIGN is called with
> a value which is a power of 2, or 0, for targets which support a partial int
> mode. This should catch issues in the future with non-power of 2
> alignments being set, which could propagate into serious problems later in the
> compilation process.
>
> If the filtering to only perform this check for targets supporting a partial
> int mode is unnecessary, I can remove that so CHECK_POW2_OR_ZEROP always
> expands to check_pow2_or_zerop.
>
> Successfully bootstrapped and regtested on x86_64-pc-linux-gnu and
> msp430-elf/-mlarge.
>
> Ok for trunk, or does this have to wait for GCC10 Stage 1?

I think the use of ffs_hwi suggests that the current behavior was intended
(or kept exactly because of calls with bougs values).  If that's not wanted
why not simply use exact_log2 instead of ffs_hwi in the SET_ macros?

Btw, I'd simply make SET_{TYPE,DECL}_ALIGN inline functions and
then gcc_checking_assert that exact_log2 didn't return -1.

Richard.


Re: [PATCH] Improve PR85574

2019-01-02 Thread Richard Biener
On Fri, 21 Dec 2018, Richard Biener wrote:

> 
> It looks like IPA ICF does code generation based on the order of
> a hahstable walk which is keyed on pointers.  That's a no-no.
> Fixing that doesn't solve the cc1 miscompare for LTO bootstrap
> but at least the IPA ICF WPA dumps are now consistent between
> stages.
> 
> [LTO] Bootstrapped and tested on x86_64-unknown-linux-gnu, ok
> for trunk (and branches)?

Now applied to trunk.  Will continue poking at PR85574 after
digging through backlog.

Richard.

> Will only get to applying after Christmas holidays so in case
> you want to poke further feel free to apply yourself.
> 
> Thanks,
> Richard.
> 
> 2018-12-21  Richard Biener  
> 
>   PR ipa/85574
>   * ipa-icf.h (sem_item_optimizer::sort_congruence_split): Declare.
>   * ipa-icf.c (sem_item_optimizer::sort_congruence_split): New
>   function.
>   (sem_item_optimizer::do_congruence_step_f): Sort the congruence
>   set after UIDs before splitting them.
> 
> Index: gcc/ipa-icf.c
> ===
> --- gcc/ipa-icf.c (revision 267301)
> +++ gcc/ipa-icf.c (working copy)
> @@ -3117,6 +3117,18 @@ sem_item_optimizer::traverse_congruence_
>return true;
>  }
>  
> +int
> +sem_item_optimizer::sort_congruence_split (const void *a_, const void *b_)
> +{
> +  const std::pair *a = (const 
> std::pair *)a_;
> +  const std::pair *b = (const 
> std::pair *)b_;
> +  if (a->first->id < b->first->id)
> +return -1;
> +  else if (a->first->id > b->first->id)
> +return 1;
> +  return 0;
> +}
> +
>  /* Tests if a class CLS used as INDEXth splits any congruence classes.
> Bitmap stack BMSTACK is used for bitmap allocation.  */
>  
> @@ -3157,13 +3169,20 @@ sem_item_optimizer::do_congruence_step_f
>   }
>  }
>  
> +  auto_vec > to_split;
> +  to_split.reserve_exact (split_map.elements ());
> +  for (hash_map ::iterator i = split_map.begin 
> ();
> +   i != split_map.end (); ++i)
> +to_split.safe_push (*i);
> +  to_split.qsort (sort_congruence_split);
> +
>traverse_split_pair pair;
>pair.optimizer = this;
>pair.cls = cls;
>  
>splitter_class_removed = false;
> -  split_map.traverse  -   sem_item_optimizer::traverse_congruence_split> ();
> +  for (unsigned i = 0; i < to_split.length (); ++i)
> +traverse_congruence_split (to_split[i].first, to_split[i].second, );
>  
>/* Bitmap clean-up.  */
>split_map.traverse  Index: gcc/ipa-icf.h
> ===
> --- gcc/ipa-icf.h (revision 267301)
> +++ gcc/ipa-icf.h (working copy)
> @@ -599,6 +599,8 @@ private:
>bitmap const ,
>traverse_split_pair *pair);
>  
> +  static int sort_congruence_split (const void *, const void *);
> +
>/* Reads a section from LTO stream file FILE_DATA. Input block for DATA
>   contains LEN bytes.  */
>void read_section (lto_file_decl_data *file_data, const char *data,
> 

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