Re: [PATCH 9/12] adjust tests to quoting/spelling diagnostics fixes

[Martin Sebor]

On 5/17/19 2:54 PM, Jeff Law wrote:

On 5/17/19 12:35 PM, Martin Sebor wrote:

On 5/16/19 1:35 PM, Jeff Law wrote:

On 5/14/19 3:32 PM, Martin Sebor wrote:

The attached patch adjusts the expected test output to the quoting,
spelling and other formatting changes in diagnostics to fix issues
pointed out by the -Wformat-diag warning.

Martin

gcc-wformat-diag-tests.diff

gcc/testsuite/ChangeLog:

 * c-c++-common/Wbool-operation-1.c: Adjust text of expected
diagnostics.
 * c-c++-common/Wvarargs-2.c: Same.
 * c-c++-common/Wvarargs.c: Same.
 * c-c++-common/pr51768.c: Same.
 * c-c++-common/tm/inline-asm.c: Same.
 * c-c++-common/tm/safe-1.c: Same.
 * g++.dg/asm-qual-1.C: Same.
 * g++.dg/asm-qual-3.C: Same.
 * g++.dg/conversion/dynamic1.C: Same.
 * g++.dg/cpp0x/constexpr-89599.C: Same.
 * g++.dg/cpp0x/constexpr-cast.C: Same.
 * g++.dg/cpp0x/constexpr-shift1.C: Same.
 * g++.dg/cpp0x/lambda/lambda-conv11.C: Same.
 * g++.dg/cpp0x/nullptr04.C: Same.
 * g++.dg/cpp0x/static_assert12.C: Same.
 * g++.dg/cpp0x/static_assert8.C: Same.
 * g++.dg/cpp1y/lambda-conv1.C: Same.
 * g++.dg/cpp1y/pr79393-3.C: Same.
 * g++.dg/cpp1y/static_assert1.C: Same.
 * g++.dg/cpp1z/constexpr-if4.C: Same.
 * g++.dg/cpp1z/constexpr-if5.C: Same.
 * g++.dg/cpp1z/constexpr-if9.C: Same.
 * g++.dg/eh/goto2.C: Same.
 * g++.dg/eh/goto3.C: Same.
 * g++.dg/expr/static_cast8.C: Same.
 * g++.dg/ext/flexary5.C: Same.
 * g++.dg/ext/utf-array-short-wchar.C: Same.
 * g++.dg/ext/utf-array.C: Same.
 * g++.dg/ext/utf8-2.C: Same.
 * g++.dg/gomp/loop-4.C: Same.
 * g++.dg/gomp/macro-4.C: Same.
 * g++.dg/gomp/udr-1.C: Same.
 * g++.dg/init/initializer-string-too-long.C: Same.
 * g++.dg/other/offsetof9.C: Same.
 * g++.dg/ubsan/pr63956.C: Same.
 * g++.dg/warn/Wbool-operation-1.C: Same.
 * g++.dg/warn/Wtype-limits-Wextra.C: Same.
 * g++.dg/warn/Wtype-limits.C: Same.
 * g++.dg/wrappers/pr88680.C: Same.
 * g++.old-deja/g++.mike/eh55.C: Same.
 * gcc.dg/Wsign-compare-1.c: Same.
 * gcc.dg/Wtype-limits-Wextra.c: Same.
 * gcc.dg/Wtype-limits.c: Same.
 * gcc.dg/Wunknownprag.c: Same.
 * gcc.dg/Wunsuffixed-float-constants-1.c: Same.
 * gcc.dg/asm-6.c: Same.
 * gcc.dg/asm-qual-1.c: Same.
 * gcc.dg/cast-1.c: Same.
 * gcc.dg/cast-2.c: Same.
 * gcc.dg/cast-3.c: Same.
 * gcc.dg/cpp/source_date_epoch-2.c: Same.
 * gcc.dg/debug/pr85252.c: Same.
 * gcc.dg/dfp/cast-bad.c: Same.
 * gcc.dg/format/gcc_diag-1.c: Same.
 * gcc.dg/format/gcc_diag-11.c: Same.New test.
 * gcc.dg/gcc_diag-11.c: Same.New test.
 * gcc.dg/gnu-cond-expr-2.c: Same.
 * gcc.dg/gnu-cond-expr-3.c: Same.
 * gcc.dg/gomp/macro-4.c: Same.
 * gcc.dg/init-bad-1.c: Same.
 * gcc.dg/init-bad-2.c: Same.
 * gcc.dg/init-bad-3.c: Same.
 * gcc.dg/pr27528.c: Same.
 * gcc.dg/pr48552-1.c: Same.
 * gcc.dg/pr48552-2.c: Same.
 * gcc.dg/pr59846.c: Same.
 * gcc.dg/pr61096-1.c: Same.
 * gcc.dg/pr8788-1.c: Same.
 * gcc.dg/pr90082.c: Same.
 * gcc.dg/simd-2.c: Same.
 * gcc.dg/spellcheck-params-2.c: Same.
 * gcc.dg/spellcheck-params.c: Same.
 * gcc.dg/strlenopt-49.c: Same.
 * gcc.dg/tm/pr52141.c: Same.
 * gcc.dg/torture/pr51106-1.c: Same.
 * gcc.dg/torture/pr51106-2.c: Same.
 * gcc.dg/utf-array-short-wchar.c: Same.
 * gcc.dg/utf-array.c: Same.
 * gcc.dg/utf8-2.c: Same.
 * gcc.dg/warn-sprintf-no-nul.c: Same.
 * gcc.target/i386/asm-flag-0.c: Same.
 * gcc.target/i386/inline_error.c: Same.
 * gcc.target/i386/pr30848.c: Same.
 * gcc.target/i386/pr39082-1.c: Same.
 * gcc.target/i386/pr39678.c: Same.
 * gcc.target/i386/pr57756.c: Same.
 * gcc.target/i386/pr68843-1.c: Same.
 * gcc.target/i386/pr79804.c: Same.
 * gcc.target/i386/pr82673.c: Same.
 * obj-c++.dg/class-protocol-1.mm: Same.
 * obj-c++.dg/exceptions-3.mm: Same.
 * obj-c++.dg/exceptions-4.mm: Same.
 * obj-c++.dg/exceptions-5.mm: Same.
 * obj-c++.dg/exceptions-6.mm: Same.
 * obj-c++.dg/method-12.mm: Same.
 * obj-c++.dg/method-13.mm: Same.
 * obj-c++.dg/method-6.mm: Same.
 * obj-c++.dg/method-7.mm: Same.
 * obj-c++.dg/method-9.mm: Same.
 * obj-c++.dg/method-lookup-1.mm: Same.
 * obj-c++.dg/proto-lossage-4.mm: Same.
 * obj-c++.dg/protocol-qualifier-2.mm: Same.
 * objc.dg/call-super-2.m: Same.
 * objc.dg/class-protocol-1.m: Same.
 * objc.dg/desig-init-1.m: Same.
 * objc.dg/exceptions-3.m: Same.
 * objc.dg/exceptions-4.m: Same.
 * objc.dg/exceptions-5.m: Same.
 * objc.dg/exceptions-6.m: Same.
 * objc.dg/method-19.m: Same.
 * objc.dg/method-2.m: Same.
 * objc.dg/method-5.m: Same.
 * objc.dg/method-6.m: Same.
 * objc.dg/method-7.m: Same.
 * objc.dg/method-lookup-1.m: Same.
 * objc.dg/proto-hier-1.m: Same.
 * objc.dg/proto-lossage-4.m: Same.

OK.  

Re: [PATCH] LWG 2899 - Make is_move_constructible correct for unique_ptr

[Jonathan Wakely]

On 14/05/19 12:17 +0100, Jonathan Wakely wrote:

* include/bits/unique_ptr.h (__uniq_ptr_impl): Add move constructor,
move assignment operator.
(__uniq_ptr_impl::release(), __uniq_ptr_impl::reset(pointer)): Add.
(__uniq_ptr_data): New class template with conditionally deleted
special members.
(unique_ptr, unique_ptr): Change type of data member from
__uniq_ptr_impl to __uniq_ptr_data. Define move
constructor and move assignment operator as defaulted.
(unique_ptr::release(), unique_ptr::release()): Forward to
__uniq_ptr_impl::release().
(unique_ptr::reset(pointer), unique_ptr::reset(U)): Forward
to __uniq_ptr_impl::reset(pointer).
* python/libstdcxx/v6/printers.py (UniquePointerPrinter.__init__):
Check for new __uniq_ptr_data type.
* testsuite/20_util/unique_ptr/dr2899.cc: New test.


This updates the Xmethod for the new base class.

Tested x86_64-linux, committed to trunk.
commit 5b013bcaeae51850ced6eaff0c6626915565c88a
Author: Jonathan Wakely 
Date:   Sat May 18 00:05:47 2019 +0100

PR libstdc++/90520 adjust Xmethod for recent unique_ptr changes

PR libstdc++/90520
* python/libstdcxx/v6/printers.py (UniquePointerPrinter.__init__):
Raise exception if unique_ptr tuple member has unknown structure.
* python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker.__call__):
Adjust worker to support new __uniq_ptr_data base class. Do not
assume field called _M_head_impl is the first tuple element.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 162b00760e6..05143153bee 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -197,6 +197,8 @@ class UniquePointerPrinter:
 self.pointer = tuple_member['_M_head_impl']
 elif head_field.is_base_class:
 self.pointer = tuple_member.cast(head_field.type)
+else:
+raise ValueError("Unsupported implementation for tuple in unique_ptr: %s" % impl_type)
 
 def children (self):
 return SmartPtrIterator(self.pointer)
diff --git a/libstdc++-v3/python/libstdcxx/v6/xmethods.py b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
index c405d8a25d5..623cb80bc0e 100644
--- a/libstdc++-v3/python/libstdcxx/v6/xmethods.py
+++ b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
@@ -586,11 +586,22 @@ class UniquePtrGetWorker(gdb.xmethod.XMethodWorker):
 
 def __call__(self, obj):
 impl_type = obj.dereference().type.fields()[0].type.tag
-if re.match('^std::(__\d+::)?__uniq_ptr_impl<.*>$', impl_type): # New implementation
-return obj['_M_t']['_M_t']['_M_head_impl']
+# Check for new implementations first:
+if re.match('^std::(__\d+::)?__uniq_ptr_(data|impl)<.*>$', impl_type):
+tuple_member = obj['_M_t']['_M_t']
 elif re.match('^std::(__\d+::)?tuple<.*>$', impl_type):
-return obj['_M_t']['_M_head_impl']
-return None
+tuple_member = obj['_M_t']
+else:
+return None
+tuple_impl_type = tuple_member.type.fields()[0].type # _Tuple_impl
+tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
+head_field = tuple_head_type.fields()[0]
+if head_field.name == '_M_head_impl':
+return tuple_member['_M_head_impl']
+elif head_field.is_base_class:
+return tuple_member.cast(head_field.type)
+else:
+return None
 
 class UniquePtrDerefWorker(UniquePtrGetWorker):
 "Implements std::unique_ptr::operator*()"

[PATCH] rs6000: Some rs6000_emit_epilogue improvements

[Segher Boessenkool]

This uses epilogue_type directly.  It also changes some ints to bools,
declares variables later, and simplifies some code.

There is one actual change:

   else if (info->push_p
   && DEFAULT_ABI != ABI_V4
-  && !crtl->calls_eh_return)
+  && epilogue_type != EPILOGUE_TYPE_EH_RETURN)
 {
   /* Prevent reordering memory accesses against stack pointer restore.  */

(different because calls_eh_return can be true for sibcalls).  This is
a bugfix.  The code was never exercised.

One place in the epilogue still uses crtl->calls_eh_return.  If that
is changed the prologue has to have a corresponding change, and the
emit_prologue function does not have an epilogue_type parameter, so
bail on changing this for now.  We might want to do this (saving the
CR fields to separate stack slots) always, not just for functions
calling eh_return, but that will require more investigation.

Tested on powerpc64-linux ({-m32,-m64}, p7) and on powerpc64le-linux
(p9); committing to trunk.


Segher


2019-05-17  Segher Boessenkool  

* config/rs6000/rs6000.c (restore_saved_cr): Change a boolean
argument to be type bool (was int before).
(rs6000_emit_epilogue): Simplify some code.  Declare some variables
at first use.  Use type bool for some variables.  Fix a theoretical
eh_return bug for svr4.

---
 gcc/config/rs6000/rs6000.c | 97 +-
 1 file changed, 53 insertions(+), 44 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 2992ba5..da7dae1 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -27712,7 +27712,7 @@ load_cr_save (int regno, rtx frame_reg_rtx, int offset, 
bool exit_func)
 /* Reload CR from REG.  */
 
 static void
-restore_saved_cr (rtx reg, int using_mfcr_multiple, bool exit_func)
+restore_saved_cr (rtx reg, bool using_mfcr_multiple, bool exit_func)
 {
   int count = 0;
   int i;
@@ -27876,15 +27876,6 @@ emit_cfa_restores (rtx cfa_restores)
 void
 rs6000_emit_epilogue (enum epilogue_type epilogue_type)
 {
-  int sibcall = (epilogue_type == EPILOGUE_TYPE_SIBCALL);
-  rs6000_stack_t *info;
-  int restoring_GPRs_inline;
-  int restoring_FPRs_inline;
-  int using_load_multiple;
-  int using_mtcr_multiple;
-  int use_backchain_to_restore_sp;
-  int restore_lr;
-  int strategy;
   HOST_WIDE_INT frame_off = 0;
   rtx sp_reg_rtx = gen_rtx_REG (Pmode, 1);
   rtx frame_reg_rtx = sp_reg_rtx;
@@ -27896,30 +27887,38 @@ rs6000_emit_epilogue (enum epilogue_type 
epilogue_type)
   machine_mode fp_reg_mode = TARGET_HARD_FLOAT ? DFmode : SFmode;
   int fp_reg_size = 8;
   int i;
-  bool exit_func;
   unsigned ptr_regno;
 
-  info = rs6000_stack_info ();
+  rs6000_stack_t *info = rs6000_stack_info ();
+
+  if (epilogue_type == EPILOGUE_TYPE_NORMAL && crtl->calls_eh_return)
+epilogue_type = EPILOGUE_TYPE_EH_RETURN;
+
+  int strategy = info->savres_strategy;
+  bool using_load_multiple = !!(strategy & REST_MULTIPLE);
+  bool restoring_GPRs_inline = !!(strategy & REST_INLINE_GPRS);
+  bool restoring_FPRs_inline = !!(strategy & REST_INLINE_FPRS);
+  if (epilogue_type == EPILOGUE_TYPE_SIBCALL)
+{
+  restoring_GPRs_inline = true;
+  restoring_FPRs_inline = true;
+}
+
+  bool using_mtcr_multiple = (rs6000_tune == PROCESSOR_PPC601
+ || rs6000_tune == PROCESSOR_PPC603
+ || rs6000_tune == PROCESSOR_PPC750
+ || optimize_size);
 
-  strategy = info->savres_strategy;
-  using_load_multiple = strategy & REST_MULTIPLE;
-  restoring_FPRs_inline = sibcall || (strategy & REST_INLINE_FPRS);
-  restoring_GPRs_inline = sibcall || (strategy & REST_INLINE_GPRS);
-  using_mtcr_multiple = (rs6000_tune == PROCESSOR_PPC601
-|| rs6000_tune == PROCESSOR_PPC603
-|| rs6000_tune == PROCESSOR_PPC750
-|| optimize_size);
   /* Restore via the backchain when we have a large frame, since this
  is more efficient than an addis, addi pair.  The second condition
  here will not trigger at the moment;  We don't actually need a
  frame pointer for alloca, but the generic parts of the compiler
  give us one anyway.  */
-  use_backchain_to_restore_sp = (info->total_size + (info->lr_save_p
-? info->lr_save_offset
-: 0) > 32767
-|| (cfun->calls_alloca
-&& !frame_pointer_needed));
-  restore_lr = (info->lr_save_p
+  bool use_backchain_to_restore_sp
+= (info->total_size + (info->lr_save_p ? info->lr_save_offset : 0) > 32767
+   || (cfun->calls_alloca && !frame_pointer_needed));
+
+  bool restore_lr = (info->lr_save_p
&& (restoring_FPRs_inline
|| (strategy & REST_NOINLINE_FPRS_DOESNT_RESTORE_LR))
&& 

[PATCH] Don't use localized strings for -print-search-dirs output (cf. bug 14351)

[Pieter "PoroCYon" Sluys]

As the output of that flag is usually parsed by scripts, having the keys
translated is more of a curse than a blessing. This problem seems to
have been known for about 15 years now:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14351

This patch simply removes the gettext _() macro invocations.
---
 gcc/gcc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 4f57765b0..87eba2e98 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -7861,12 +7861,12 @@ driver::maybe_print_and_exit () const
 {
   if (print_search_dirs)
 {
-  printf (_("install: %s%s\n"),
+  printf ("install: %s%s\n",
  gcc_exec_prefix ? gcc_exec_prefix : standard_exec_prefix,
  gcc_exec_prefix ? "" : machine_suffix);
-  printf (_("programs: %s\n"),
+  printf ("programs: %s\n",
  build_search_list (_prefixes, "", false, false));
-  printf (_("libraries: %s\n"),
+  printf ("libraries: %s\n",
  build_search_list (_prefixes, "", false, true));
   return (0);
 }
-- 
2.21.0
>From 396c29fba15dd21de596042eaaf66d1534c71cc7 Mon Sep 17 00:00:00 2001
From: PoroCYon 
Date: Fri, 17 May 2019 23:34:58 +0200
Subject: [PATCH] Don't use localized strings for -print-search-dirs output

As the output of that flag is usually parsed by scripts, having the keys
translated is more of a curse than a blessing. This problem seems to
have been known for about 15 years now:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14351

This patch simply removes the gettext _() macro invocations.
---
 gcc/gcc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 4f57765b0..87eba2e98 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -7861,12 +7861,12 @@ driver::maybe_print_and_exit () const
 {
   if (print_search_dirs)
 {
-  printf (_("install: %s%s\n"),
+  printf ("install: %s%s\n",
 	  gcc_exec_prefix ? gcc_exec_prefix : standard_exec_prefix,
 	  gcc_exec_prefix ? "" : machine_suffix);
-  printf (_("programs: %s\n"),
+  printf ("programs: %s\n",
 	  build_search_list (_prefixes, "", false, false));
-  printf (_("libraries: %s\n"),
+  printf ("libraries: %s\n",
 	  build_search_list (_prefixes, "", false, true));
   return (0);
 }
-- 
2.21.0

[PATCH] rs6000: Add "enabled" attribute

[Segher Boessenkool]

This adds the "enabled" attribute to the rs6000 backend.  It uses the
(new) "isa" attribute to automatically select which instruction
alternatives should be enabled.

For now it allows isa strings of "p5", "p6", "p7", meaning the
instructions introduced on that CPU, not requiring vectors; and "p7v",
"p8v", "p9v" for the same, but with vectors.

These are currently mapped to TARGET_POPCNTB, TARGET_CMPB,
TARGET_POPCNTD, TARGET_VSX, TARGET_P8_VECTOR, and TARGET_P9_VECTOR;
that will change to something a bit saner later.

This patch does not use those attributes anywhere yet.  Committing
to trunk.


Segher


2019-05-17  Segher Boessenkool  

* config/rs6000/rs6000.md (isa): New attribute.
(enabled): New attribute.

---
 gcc/config/rs6000/rs6000.md | 33 +
 1 file changed, 33 insertions(+)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 31fc90a..0906ccb 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -265,6 +265,39 @@ (define_attr "cpu"
rs64a,mpccore,cell,ppca2,titan"
   (const (symbol_ref "(enum attr_cpu) rs6000_tune")))
 
+;; The ISA we implement.
+(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p9v" (const_string "any"))
+
+;; Is this alternative enabled for the current CPU/ISA/etc.?
+(define_attr "enabled" ""
+  (cond
+[(eq_attr "isa" "any")
+ (const_int 1)
+
+ (and (eq_attr "isa" "p5")
+ (match_test "TARGET_POPCNTB"))
+ (const_int 1)
+
+ (and (eq_attr "isa" "p6")
+ (match_test "TARGET_CMPB"))
+ (const_int 1)
+
+ (and (eq_attr "isa" "p7")
+ (match_test "TARGET_POPCNTD"))
+ (const_int 1)
+
+ (and (eq_attr "isa" "p7v")
+ (match_test "TARGET_VSX"))
+ (const_int 1)
+
+ (and (eq_attr "isa" "p8v")
+ (match_test "TARGET_P8_VECTOR"))
+ (const_int 1)
+
+ (and (eq_attr "isa" "p9v")
+ (match_test "TARGET_P9_VECTOR"))
+ (const_int 1)
+] (const_int 0)))
 
 ;; If this instruction is microcoded on the CELL processor
 ; The default for load extended, the recorded instructions and rotate/shifts 
by a variable is always microcoded
-- 
1.8.3.1

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jason Merrill]

On Fri, May 17, 2019 at 3:51 PM Segher Boessenkool
 wrote:
> Yes -- one of the problems I have with the current git-svn mirror is that
> it doesn't have any of the SVN branches under ibm/ as separate Git branches.
> It looks like Maxim's scripts will handle this; the conversion hasn't
> reached those branches yet though.  Soon :-)

I talk about how to rewrite subdirectory branches without doing the
slow git-svn checkout in

https://gcc.gnu.org/wiki/GitMirror#Subdirectory_branches

Jason

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Steve Ellcey]

I hope this isn't too much of a thread drift but I was wondering if,
after the Git conversion, will the GCC repo look like a 'normal' GIT
repo with the main line sources on the master branch?

I.e. right now instead of a simple clone, the GCC Wiki says to use a
sequence of git init/config/fetch/checkout commands.  After the
conversion will we be able to just use 'git clone'?  And will the
default master branch be the usable GCC top-of-tree sources (vs the
trunk branch) that we can do checkins to?

Steve Ellcey
sell...@marvell.com

Re: [PATCH 9/12] adjust tests to quoting/spelling diagnostics fixes

[Jeff Law]

On 5/17/19 12:35 PM, Martin Sebor wrote:
> On 5/16/19 1:35 PM, Jeff Law wrote:
>> On 5/14/19 3:32 PM, Martin Sebor wrote:
>>> The attached patch adjusts the expected test output to the quoting,
>>> spelling and other formatting changes in diagnostics to fix issues
>>> pointed out by the -Wformat-diag warning.
>>>
>>> Martin
>>>
>>> gcc-wformat-diag-tests.diff
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * c-c++-common/Wbool-operation-1.c: Adjust text of expected
>>> diagnostics.
>>> * c-c++-common/Wvarargs-2.c: Same.
>>> * c-c++-common/Wvarargs.c: Same.
>>> * c-c++-common/pr51768.c: Same.
>>> * c-c++-common/tm/inline-asm.c: Same.
>>> * c-c++-common/tm/safe-1.c: Same.
>>> * g++.dg/asm-qual-1.C: Same.
>>> * g++.dg/asm-qual-3.C: Same.
>>> * g++.dg/conversion/dynamic1.C: Same.
>>> * g++.dg/cpp0x/constexpr-89599.C: Same.
>>> * g++.dg/cpp0x/constexpr-cast.C: Same.
>>> * g++.dg/cpp0x/constexpr-shift1.C: Same.
>>> * g++.dg/cpp0x/lambda/lambda-conv11.C: Same.
>>> * g++.dg/cpp0x/nullptr04.C: Same.
>>> * g++.dg/cpp0x/static_assert12.C: Same.
>>> * g++.dg/cpp0x/static_assert8.C: Same.
>>> * g++.dg/cpp1y/lambda-conv1.C: Same.
>>> * g++.dg/cpp1y/pr79393-3.C: Same.
>>> * g++.dg/cpp1y/static_assert1.C: Same.
>>> * g++.dg/cpp1z/constexpr-if4.C: Same.
>>> * g++.dg/cpp1z/constexpr-if5.C: Same.
>>> * g++.dg/cpp1z/constexpr-if9.C: Same.
>>> * g++.dg/eh/goto2.C: Same.
>>> * g++.dg/eh/goto3.C: Same.
>>> * g++.dg/expr/static_cast8.C: Same.
>>> * g++.dg/ext/flexary5.C: Same.
>>> * g++.dg/ext/utf-array-short-wchar.C: Same.
>>> * g++.dg/ext/utf-array.C: Same.
>>> * g++.dg/ext/utf8-2.C: Same.
>>> * g++.dg/gomp/loop-4.C: Same.
>>> * g++.dg/gomp/macro-4.C: Same.
>>> * g++.dg/gomp/udr-1.C: Same.
>>> * g++.dg/init/initializer-string-too-long.C: Same.
>>> * g++.dg/other/offsetof9.C: Same.
>>> * g++.dg/ubsan/pr63956.C: Same.
>>> * g++.dg/warn/Wbool-operation-1.C: Same.
>>> * g++.dg/warn/Wtype-limits-Wextra.C: Same.
>>> * g++.dg/warn/Wtype-limits.C: Same.
>>> * g++.dg/wrappers/pr88680.C: Same.
>>> * g++.old-deja/g++.mike/eh55.C: Same.
>>> * gcc.dg/Wsign-compare-1.c: Same.
>>> * gcc.dg/Wtype-limits-Wextra.c: Same.
>>> * gcc.dg/Wtype-limits.c: Same.
>>> * gcc.dg/Wunknownprag.c: Same.
>>> * gcc.dg/Wunsuffixed-float-constants-1.c: Same.
>>> * gcc.dg/asm-6.c: Same.
>>> * gcc.dg/asm-qual-1.c: Same.
>>> * gcc.dg/cast-1.c: Same.
>>> * gcc.dg/cast-2.c: Same.
>>> * gcc.dg/cast-3.c: Same.
>>> * gcc.dg/cpp/source_date_epoch-2.c: Same.
>>> * gcc.dg/debug/pr85252.c: Same.
>>> * gcc.dg/dfp/cast-bad.c: Same.
>>> * gcc.dg/format/gcc_diag-1.c: Same.
>>> * gcc.dg/format/gcc_diag-11.c: Same.New test.
>>> * gcc.dg/gcc_diag-11.c: Same.New test.
>>> * gcc.dg/gnu-cond-expr-2.c: Same.
>>> * gcc.dg/gnu-cond-expr-3.c: Same.
>>> * gcc.dg/gomp/macro-4.c: Same.
>>> * gcc.dg/init-bad-1.c: Same.
>>> * gcc.dg/init-bad-2.c: Same.
>>> * gcc.dg/init-bad-3.c: Same.
>>> * gcc.dg/pr27528.c: Same.
>>> * gcc.dg/pr48552-1.c: Same.
>>> * gcc.dg/pr48552-2.c: Same.
>>> * gcc.dg/pr59846.c: Same.
>>> * gcc.dg/pr61096-1.c: Same.
>>> * gcc.dg/pr8788-1.c: Same.
>>> * gcc.dg/pr90082.c: Same.
>>> * gcc.dg/simd-2.c: Same.
>>> * gcc.dg/spellcheck-params-2.c: Same.
>>> * gcc.dg/spellcheck-params.c: Same.
>>> * gcc.dg/strlenopt-49.c: Same.
>>> * gcc.dg/tm/pr52141.c: Same.
>>> * gcc.dg/torture/pr51106-1.c: Same.
>>> * gcc.dg/torture/pr51106-2.c: Same.
>>> * gcc.dg/utf-array-short-wchar.c: Same.
>>> * gcc.dg/utf-array.c: Same.
>>> * gcc.dg/utf8-2.c: Same.
>>> * gcc.dg/warn-sprintf-no-nul.c: Same.
>>> * gcc.target/i386/asm-flag-0.c: Same.
>>> * gcc.target/i386/inline_error.c: Same.
>>> * gcc.target/i386/pr30848.c: Same.
>>> * gcc.target/i386/pr39082-1.c: Same.
>>> * gcc.target/i386/pr39678.c: Same.
>>> * gcc.target/i386/pr57756.c: Same.
>>> * gcc.target/i386/pr68843-1.c: Same.
>>> * gcc.target/i386/pr79804.c: Same.
>>> * gcc.target/i386/pr82673.c: Same.
>>> * obj-c++.dg/class-protocol-1.mm: Same.
>>> * obj-c++.dg/exceptions-3.mm: Same.
>>> * obj-c++.dg/exceptions-4.mm: Same.
>>> * obj-c++.dg/exceptions-5.mm: Same.
>>> * obj-c++.dg/exceptions-6.mm: Same.
>>> * obj-c++.dg/method-12.mm: Same.
>>> * obj-c++.dg/method-13.mm: Same.
>>> * obj-c++.dg/method-6.mm: Same.
>>> * obj-c++.dg/method-7.mm: Same.
>>> * obj-c++.dg/method-9.mm: Same.
>>> * obj-c++.dg/method-lookup-1.mm: Same.
>>> * obj-c++.dg/proto-lossage-4.mm: Same.
>>> * obj-c++.dg/protocol-qualifier-2.mm: Same.
>>> * objc.dg/call-super-2.m: Same.
>>> * objc.dg/class-protocol-1.m: Same.
>>> * objc.dg/desig-init-1.m: Same.
>>> * objc.dg/exceptions-3.m: Same.
>>> * objc.dg/exceptions-4.m: Same.
>>> * objc.dg/exceptions-5.m: 

Re: Hashtable comment cleanups & renamings

[Jonathan Wakely]

On 17/05/19 18:19 +0200, François Dumont wrote:

Hi

    I got tired of '__n' being used in _Hashtable for many different 
purposes: node, bucket, bucket count, bucket hint. It makes the code 
difficult to read. This code makes sure that __n is a node except is 
some very limited use cases where the method name is clear enough to 
tell what __n means.


    So I'd like to commit this patch which only change that and some 
comments before moving forward to more serious stuff. The only code 
change is a use of auto return type on _M_allocate_node.


    My main concern is the ChangeLog entry. Is the following entry ok ?

    Rename variables and cleanup comments.
    * include/bits/hashtable_policy.h
    * include/bits/hashtable.h

    Tested under Linux x86_64 (even if it can't be otherwise)

François




@@ -350,24 +347,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _M_base_alloc() { return *this; }

  __bucket_type*
-  _M_allocate_buckets(size_type __n)
+  _M_allocate_buckets(size_type __bkt_count)


This is a much more helpful name, thanks.


@@ -439,30 +436,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { }

  explicit
-  _Hashtable(size_type __n,
+  _Hashtable(size_type __bkt_hint,


This seems less helpful. Would __num_bkts_hint be clearer?
Or for consistency, __bkt_count_hint?


@@ -1415,9 +1414,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
-> iterator
{
  __hash_code __code = this->_M_hash_code(__k);
-  std::size_t __n = _M_bucket_index(__k, __code);
-  __node_type* __p = _M_find_node(__n, __k, __code);
-  return __p ? iterator(__p) : end();
+  std::size_t __bkt = _M_bucket_index(__k, __code);
+  __node_type* __n = _M_find_node(__bkt, __k, __code);
+  return __n ? iterator(__n) : end();


Is __n really an improvement over __p here?

If you're changing it, __node or __ptr might be an improvement, but
changing __p to __n seems like unnecessary churn.

I'm not convinced that __n is a big enough improvement over __p to
bother changing dozens of lines, for not much benefit. All those
changes will make it slower to use git blame to track down when thigns
changed, and will make it harder to review diffs between trunk and
older branches.



@@ -1479,17 +1478,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
-> pair
{
  __hash_code __code = this->_M_hash_code(__k);
-  std::size_t __n = _M_bucket_index(__k, __code);
-  __node_type* __p = _M_find_node(__n, __k, __code);
+  std::size_t __bkt = _M_bucket_index(__k, __code);
+  __node_type* __n = _M_find_node(__bkt, __k, __code);

-  if (__p)
+  if (__n)
{
- __node_type* __p1 = __p->_M_next();
- while (__p1 && _M_bucket_index(__p1) == __n
-&& this->_M_equals(__k, __code, __p1))
-   __p1 = __p1->_M_next();
+ __node_type* __n1 = __n->_M_next();


__p1 is not a good name, but __n1 is no better.

At least with __p the second pointer could be __q, which is a fairly
idiomatic pairing of letters :-)

How about __first and __last? Or __n and __next?  Even __n1 and __n2
seems better than __n and __n1. Those pointers end up being used for
the 'first' and 'second' members of a pair, so __n1 and __n2 makes
more sense than setting 'first' from __n and 'second' from __n1.

But I don't feel strongly about it, so if it's just me who dislikes
__n and __n1 then it doesn't matter.


diff --git a/libstdc++-v3/include/bits/hashtable_policy.h 
b/libstdc++-v3/include/bits/hashtable_policy.h
index a4d2a97f4f3..bb2e7b762ff 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -181,7 +181,7 @@ namespace __detail
   *  @tparam _Cache_hash_code  Boolean value. True if the value of
   *  the hash function is stored along with the value. This is a
   *  time-space tradeoff.  Storing it may improve lookup speed by
-   *  reducing the number of times we need to call the _Equal
+   *  reducing the number of times we need to call the _Hash


Doesn't it reduce both?

In _M_equals we don't bother calling the _Equal predicate if the
cached hash code doesn't match the one for the key we're comparing.

[PATCH] gcc: aarch64: move assemble_start_function / assemble_end_function

[Max Filippov]

Change that moved assemble_start_function/assemble_end_function to
backends missed aarch64. Fix that.

Committed as obvious.

gcc/
2019-05-17  Max Filippov  

* config/aarch64/aarch64.c (aarch64_output_mi_thunk): Call
assemble_start_function and assemble_end_function.
---
 gcc/config/aarch64/aarch64.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1f904671c690..be5e30ac1025 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5979,6 +5979,7 @@ aarch64_output_mi_thunk (FILE *file, tree thunk 
ATTRIBUTE_UNUSED,
   int this_regno = R0_REGNUM;
   rtx this_rtx, temp0, temp1, addr, funexp;
   rtx_insn *insn;
+  const char *fnname = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (thunk));
 
   if (aarch64_bti_enabled ())
 emit_insn (gen_bti_c());
@@ -6046,9 +6047,12 @@ aarch64_output_mi_thunk (FILE *file, tree thunk 
ATTRIBUTE_UNUSED,
 
   insn = get_insns ();
   shorten_branches (insn);
+
+  assemble_start_function (thunk, fnname);
   final_start_function (insn, file, 1);
   final (insn, file, 1);
   final_end_function ();
+  assemble_end_function (thunk, fnname);
 
   /* Stop pretending to be a post-reload pass.  */
   reload_completed = 0;
-- 
2.11.0

Backports to gcc-9-branch

[Jakub Jelinek]

Hi!

I've backported following 11 patches from trunk to gcc-9-branch,
bootstrapped/regtested on x86_64-linux and i686-linux, committed.

Jakub
2019-05-17  Jakub Jelinek  

Backported from mainline
2019-04-26  Jakub Jelinek  

PR debug/90197
* c-tree.h (c_finish_loop): Add 2 further location_t arguments.
* c-parser.c (c_parser_while_statement): Adjust c_finish_loop caller.
(c_parser_do_statement): Likewise.
(c_parser_for_statement): Likewise.  Formatting fixes.
* c-typeck.c (c_finish_loop): Add COND_LOCUS and INCR_LOCUS arguments,
emit DEBUG_BEGIN_STMTs if needed.

--- gcc/c/c-tree.h  (revision 270605)
+++ gcc/c/c-tree.h  (revision 270606)
@@ -694,7 +694,8 @@ extern int c_types_compatible_p (tree, t
 extern tree c_begin_compound_stmt (bool);
 extern tree c_end_compound_stmt (location_t, tree, bool);
 extern void c_finish_if_stmt (location_t, tree, tree, tree);
-extern void c_finish_loop (location_t, tree, tree, tree, tree, tree, bool);
+extern void c_finish_loop (location_t, location_t, tree, location_t, tree,
+  tree, tree, tree, bool);
 extern tree c_begin_stmt_expr (void);
 extern tree c_finish_stmt_expr (location_t, tree);
 extern tree c_process_expr_stmt (location_t, tree);
--- gcc/c/c-parser.c(revision 270605)
+++ gcc/c/c-parser.c(revision 270606)
@@ -6001,7 +6001,8 @@ c_parser_while_statement (c_parser *pars
   location_t loc_after_labels;
   bool open_brace = c_parser_next_token_is (parser, CPP_OPEN_BRACE);
   body = c_parser_c99_block_statement (parser, if_p, _after_labels);
-  c_finish_loop (loc, cond, NULL, body, c_break_label, c_cont_label, true);
+  c_finish_loop (loc, loc, cond, UNKNOWN_LOCATION, NULL, body,
+c_break_label, c_cont_label, true);
   add_stmt (c_end_compound_stmt (loc, block, flag_isoc99));
   c_parser_maybe_reclassify_token (parser);
 
@@ -6046,6 +6047,7 @@ c_parser_do_statement (c_parser *parser,
   c_break_label = save_break;
   new_cont = c_cont_label;
   c_cont_label = save_cont;
+  location_t cond_loc = c_parser_peek_token (parser)->location;
   cond = c_parser_paren_condition (parser);
   if (ivdep && cond != error_mark_node)
 cond = build3 (ANNOTATE_EXPR, TREE_TYPE (cond), cond,
@@ -6059,7 +6061,8 @@ c_parser_do_statement (c_parser *parser,
   build_int_cst (integer_type_node, unroll));
   if (!c_parser_require (parser, CPP_SEMICOLON, "expected %<;%>"))
 c_parser_skip_to_end_of_block_or_statement (parser);
-  c_finish_loop (loc, cond, NULL, body, new_break, new_cont, false);
+  c_finish_loop (loc, cond_loc, cond, UNKNOWN_LOCATION, NULL, body,
+new_break, new_cont, false);
   add_stmt (c_end_compound_stmt (loc, block, flag_isoc99));
 }
 
@@ -6132,7 +6135,9 @@ c_parser_for_statement (c_parser *parser
   /* Silence the bogus uninitialized warning.  */
   tree collection_expression = NULL;
   location_t loc = c_parser_peek_token (parser)->location;
-  location_t for_loc = c_parser_peek_token (parser)->location;
+  location_t for_loc = loc;
+  location_t cond_loc = UNKNOWN_LOCATION;
+  location_t incr_loc = UNKNOWN_LOCATION;
   bool is_foreach_statement = false;
   gcc_assert (c_parser_next_token_is_keyword (parser, RID_FOR));
   token_indent_info for_tinfo
@@ -6166,7 +6171,8 @@ c_parser_for_statement (c_parser *parser
  c_parser_consume_token (parser);
  is_foreach_statement = true;
  if (check_for_loop_decls (for_loc, true) == NULL_TREE)
-   c_parser_error (parser, "multiple iterating variables in fast 
enumeration");
+   c_parser_error (parser, "multiple iterating variables in "
+   "fast enumeration");
}
  else
check_for_loop_decls (for_loc, flag_isoc99);
@@ -6196,7 +6202,8 @@ c_parser_for_statement (c_parser *parser
  c_parser_consume_token (parser);
  is_foreach_statement = true;
  if (check_for_loop_decls (for_loc, true) == NULL_TREE)
-   c_parser_error (parser, "multiple iterating variables in 
fast enumeration");
+   c_parser_error (parser, "multiple iterating variables in "
+   "fast enumeration");
}
  else
check_for_loop_decls (for_loc, flag_isoc99);
@@ -6218,15 +6225,18 @@ c_parser_for_statement (c_parser *parser
c_parser_consume_token (parser);
is_foreach_statement = true;
if (! lvalue_p (init_expression))
- c_parser_error (parser, "invalid iterating variable in fast 
enumeration");
-   object_expression = c_fully_fold (init_expression, false, NULL);
+ c_parser_error (parser, "invalid iterating variable in "
+ "fast enumeration");
+   object_expression
+  

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Fri, May 17, 2019 at 09:18:53AM +0100, Richard Sandiford wrote:
> Joseph Myers  writes:
> > On Thu, 16 May 2019, Maxim Kuvyrkov wrote:
> >> With git, we can always split away unneeded history by removing 
> >> unnecessary branches and tags and re-packing the repo.  We can equally 
> >> easily bring that history back if we change our minds.

Only if we have stored it somewhere!  But we all agree we will never
delete any (non-user) branches I think.

> > (I support a move to git, but not one using git-svn, and only one that 
> > properly takes into account the large amount of work previously done on 
> > author maps, understanding the repository peculiarities and how to 

I am very much **against** most of that author map stuff.  It is falsifying
history.  Replacing the sourceware account name of people by one of their
current email addresses is just foolish anyway.

In many cases anyone can trivially glance the correct info from the
changelogs.  In some other cases it is hard or impossible to find the
correct info.

The information we have now in SVN is what we have there now.  We should
convert *that* information to Git, nothing more, nothing less.  And that
is very much possible to do, not a gargantuan task.

> > correctly identify exactly which directories are branches or tags, fixing 
> > cases where there are both a branch and tag of the same name, identifying 
> > which tags to remove and which to keep, etc.)

Yes -- one of the problems I have with the current git-svn mirror is that
it doesn't have any of the SVN branches under ibm/ as separate Git branches.
It looks like Maxim's scripts will handle this; the conversion hasn't
reached those branches yet though.  Soon :-)

> FWIW, I've been using the "official" git-svn based mirror for at least
> the last five years, only using SVN to actually commit.  And I've never
> needed any of the above during that time.

I do look through all history pretty often.  The current mirror is good
enough for most of that, and there is no way to get the rest back AFAIK.

> It would be a really neat project to create a GCC git repo that goes
> far back in time and gives the closest illusion possible that git had
> been used all that time.  And personally I'd be very interested in
> seeing that.  But its main use would be as a historical artefact,
> to show how a long-running software project evolved over time.

Agreed.

> I think the focus for the development git repo should be on what's
> needed for day-to-day work, and like I say, the git-svn mirror we
> have now is in practice a good enough conversion for that.  If we can
> do better then great.  But I think we're in serious danger of making the
> best the enemy of the good here.

Yes.  There are a few things that should be fixed though, like that branches
vs. tags thing, and the subdir branches problem.

> The big advantage of Maxim's approach is that it's a public script in
> our own repo that anyone can contribute to.  So if there are specific
> tweaks people want to make, there's now the opportunity to do that.
> 
> So FWIW, my vote would be for having a window to allow people to tweak
> the script if they want to, then make the switch.

I agree.


Segher

Re: [PATCH] Add workaround for broken C/C++ wrappers to LAPACK (PR fortran/90329)

[Jakub Jelinek]

On Fri, May 17, 2019 at 10:33:30PM +0300, Janne Blomqvist wrote:
> I don't think it's this simple, unfortunately. If it would be only R,
> then yes, we could help the R people fix their code and then it would
> all be done. But seems this is everywhere. It's in CBLAS & LAPACKE
> (the official BLAS and LAPACK C interfaces), it's in numpy (probably
> scipy also), R, arma. And BLAS/LAPACK are pretty central, and probably
> the single biggest reason why non-Fortran programmers use Fortran
> code. And while the issue has been known, it seems to have been
> happily ignored for the past 30 years.
> 
> And yes, while I think one year might be a quite optimistic timeframe
> to get this fixed, I agree we shouldn't keep the workaround
> indefinitely either. I think the best way would be if CBLAS & LAPACKE
> would be fixed, and then we could tell people to use those rather than
> their own in-house broken interfaces.

Could we easily detect at resolve time whether a subroutine/function
makes any implicitly prototyped calls and limit this workaround to those
cases (i.e. only old-style Fortran)?  I've mentioned it in the PR, but not
sure how exactly to check that.
The thing is, if all calls are explicitly prototyped, then we've been using
tail calls before as well and so the workaround would just pessimize
something we've been optimizing fine before.

Jakub

Re: [PATCH] Add workaround for broken C/C++ wrappers to LAPACK (PR fortran/90329)

[Janne Blomqvist]

On Fri, May 17, 2019 at 9:57 PM Jerry DeLisle  wrote:
>
> On 5/17/19 10:48 AM, Jeff Law wrote:
> > My first, second and third thought has been we shouldn't be catering to
> > code that is so clearly broken.  Maybe we could do this on the release
> > branches which would in turn give folks roughly a year to fix up this mess?
> >
> > jeff
> >
>
> Not that I have much say, but I have been following this thread and the others
> about broken wrappers and screwed up prototypes being used by R for there use 
> of
> LAPACK.  I have been holding off saying anything.
>
> I don't thing we should be doing anything in gfortran at all. I think the R
> people need to fix their calls. People get caught by not following the proper
> conventions and then want the compiler to fix it. Its not the compiler writers
> job to fix users bad code. The Fortran conventions of having the string 
> lengths
> appended to the end has been known for many many years and well documented
> everywhere.
>
> Sorry for ranting and I understand everyone is just trying to do the right
> thing.  It would have been about an editorial fix on the R side.
>
> Maybe Jeff as a good compromise here in that at least we would not have to 
> carry
> it forward in time.

I don't think it's this simple, unfortunately. If it would be only R,
then yes, we could help the R people fix their code and then it would
all be done. But seems this is everywhere. It's in CBLAS & LAPACKE
(the official BLAS and LAPACK C interfaces), it's in numpy (probably
scipy also), R, arma. And BLAS/LAPACK are pretty central, and probably
the single biggest reason why non-Fortran programmers use Fortran
code. And while the issue has been known, it seems to have been
happily ignored for the past 30 years.

And yes, while I think one year might be a quite optimistic timeframe
to get this fixed, I agree we shouldn't keep the workaround
indefinitely either. I think the best way would be if CBLAS & LAPACKE
would be fixed, and then we could tell people to use those rather than
their own in-house broken interfaces.

-- 
Janne Blomqvist

[committed] PR89433 "Repeated use of the OpenACC 'routine' directive"

[Thomas Schwinge]

Hi!

On Fri, 22 Feb 2019 12:22:38 +0100, I wrote:
> To resolve PR89433 "Repeated use of the OpenACC 'routine' directive" at
> least for C/C++, I intend to push the attached patches in next GCC
> development stage 1 (unless that should be addressed right now, and also
> on other GCC release branches?).

(I still ponder on the question whether to eventually backport all this
to other GCC release branches...)

> The corresponding Fortran changes will require additional effort.

..., which I actually already have committed a while ago.

Now committed to trunk in r271343 "[PR89433] Refer to OpenACC 'routine'
clauses from "omp declare target" attribute", r271344 "[PR89433] Use
'oacc_verify_routine_clauses' for C/C++ OpenACC 'routine' directives",
r271345 "[PR89433] Repeated use of the C/C++ OpenACC 'routine'
directive", see attached.


Grüße
 Thomas


>From 9b5009857b50944d7711f34dd0ac98364b7f1f9b Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Fri, 17 May 2019 19:13:04 +
Subject: [PATCH 1/3] [PR89433] Refer to OpenACC 'routine' clauses from "omp
 declare target" attribute

	gcc/c-family/
	PR c/89433
	* c-attribs.c (c_common_attribute_table): Set min_len to -1 for
	"omp declare target".
	gcc/c/
	PR c/89433
	* c-parser.c (c_finish_oacc_routine): Refer to OpenACC 'routine'
	clauses from "omp declare target" attribute.
	gcc/cp/
	PR c++/89433
	* parser.c (cp_finalize_oacc_routine): Refer to OpenACC 'routine'
	clauses from "omp declare target" attribute.
	gcc/fortran/
	PR fortran/89433
	* f95-lang.c (gfc_attribute_table): Set min_len to -1 for "omp
	declare target".
	* trans-decl.c (add_attributes_to_decl): Refer to OpenACC
	'routine' clauses from "omp declare target" attribute.
	gcc/testsuite/
	PR testsuite/89433
	* c-c++-common/goacc/classify-routine.c: Update.
	* gfortran.dg/goacc/classify-routine.f95: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@271343 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/c-family/ChangeLog |  6 ++
 gcc/c-family/c-attribs.c   |  2 +-
 gcc/c/ChangeLog|  6 ++
 gcc/c/c-parser.c   |  2 +-
 gcc/cp/ChangeLog   |  6 ++
 gcc/cp/parser.c|  2 +-
 gcc/fortran/ChangeLog  |  8 
 gcc/fortran/f95-lang.c |  2 +-
 gcc/fortran/trans-decl.c   | 18 +++---
 gcc/testsuite/ChangeLog|  6 ++
 .../c-c++-common/goacc/classify-routine.c  |  4 ++--
 .../gfortran.dg/goacc/classify-routine.f95 |  4 ++--
 12 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index 47c1d3d51f50..50687764221b 100644
--- a/gcc/c-family/ChangeLog
+++ b/gcc/c-family/ChangeLog
@@ -1,3 +1,9 @@
+2019-05-17  Thomas Schwinge  
+
+	PR c/89433
+	* c-attribs.c (c_common_attribute_table): Set min_len to -1 for
+	"omp declare target".
+
 2019-05-16  Martin Sebor  
 
 * c-attribs.c (handle_no_sanitize_attribute): Quote identifiers,
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 12c0b9bfb543..03203470955a 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -437,7 +437,7 @@ const struct attribute_spec c_common_attribute_table[] =
 			  handle_omp_declare_simd_attribute, NULL },
   { "simd",		  0, 1, true,  false, false, false,
 			  handle_simd_attribute, NULL },
-  { "omp declare target", 0, 0, true, false, false, false,
+  { "omp declare target", 0, -1, true, false, false, false,
 			  handle_omp_declare_target_attribute, NULL },
   { "omp declare target link", 0, 0, true, false, false, false,
 			  handle_omp_declare_target_attribute, NULL },
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index f558d28dc259..f0cab2e65929 100644
--- a/gcc/c/ChangeLog
+++ b/gcc/c/ChangeLog
@@ -1,3 +1,9 @@
+2019-05-17  Thomas Schwinge  
+
+	PR c/89433
+	* c-parser.c (c_finish_oacc_routine): Refer to OpenACC 'routine'
+	clauses from "omp declare target" attribute.
+
 2019-05-16  Martin Sebor  
 
 * c-decl.c (start_decl): Quote keywords, operators, and
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 993cfe05ecb0..3cbbb199bdda 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -15904,7 +15904,7 @@ c_finish_oacc_routine (struct oacc_routine_data *data, tree fndecl,
   /* Add an "omp declare target" attribute.  */
   DECL_ATTRIBUTES (fndecl)
 = tree_cons (get_identifier ("omp declare target"),
-		 NULL_TREE, DECL_ATTRIBUTES (fndecl));
+		 data->clauses, DECL_ATTRIBUTES (fndecl));
 
   /* Remember that we've used this "#pragma acc routine".  */
   data->fndecl_seen = true;
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 08b7d5337071..40622acc0ff2 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2019-05-17  Thomas Schwinge  
+
+	PR c++/89433
+	* parser.c 

Re: [PATCH] tbb-backend effective target should check ability to link TBB

[Thomas Rodgers]

I have it fixed locally, but yeah I have not yet committed it.

Jonathan Wakely writes:

> On 25/04/19 15:58 -0700, Thomas Rodgers wrote:
>>
>>  PR libstdc++/90252
>>  * testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
>>  Changed v3_target_compile check from preprocess to executable.
>>---
>> libstdc++-v3/testsuite/lib/libstdc++.exp | 9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> This patch is still pending, but I think it's missing -ltbb that would
> actually make the link succeed, isn't it?
>
>>diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
>>b/libstdc++-v3/testsuite/lib/libstdc++.exp
>>index c48b4d78bbb..fa61bccc9f6 100644
>>--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
>>+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
>>@@ -1612,15 +1612,20 @@ proc check_effective_target_tbb-backend { } {
>> # Set up and preprocess a C++ test program that depends
>> # on tbb
>> set src tbb_backend[pid].cc
>>-
>>+set exe tbb_backend[pid].x
>>+
>> set f [open $src "w"]
>> puts $f "#include "
>> puts $f "#if TBB_INTERFACE_VERSION < 1"
>> puts $f "#  error Intel(R) Threading Building Blocks 2018 is required; 
>> older versions are not supported."
>> puts $f "#endif"
>>+puts $f "int main ()"
>>+puts $f "{"
>>+puts $f "  return 0;"
>>+puts $f "}"
>> close $f
>>
>>-set lines [v3_target_compile $src /dev/null preprocess ""]
>>+set lines [v3_target_compile $src $exe executable ""]
>> file delete $src
>>
>> if [string match "" $lines] {
>> -- 
>>2.20.1
>>

[PATCH, Darwin, PPC] Adjust formatting of picbase labels.

[Iain Sandoe]

The rest of the Darwin ports now emit Lnnn$pb as the picbase
lable instead of the ancient (and hard to read) "L000nnn$pb".

This just updates this part of the rs6000 port, NFC intended.

tested on powerpc-darwin9 and powerpc-linux-gnu (power7)
applied to mainline.
Iain

gcc/

2019-05-17  Iain Sandoe  

* config/rs6000/rs6000.c (machopic_output_stub): Adjust the
formatting of picbase labels to match other ports.

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 155bc08..7f7b167 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -33039,7 +33039,7 @@ machopic_output_stub (FILE *file, const char *symb, 
const char *stub)
   unsigned int length;
   char *symbol_name, *lazy_ptr_name;
   char *local_label_0;
-  static int label = 0;
+  static unsigned label = 0;
 
   /* Lose our funky encoding stuff so it doesn't contaminate the stub.  */
   symb = (*targetm.strip_name_encoding) (symb);
@@ -33065,8 +33065,8 @@ machopic_output_stub (FILE *file, const char *symb, 
const char *stub)
   fprintf (file, "\t.indirect_symbol %s\n", symbol_name);
 
   label++;
-  local_label_0 = XALLOCAVEC (char, sizeof ("\"L000$spb\""));
-  sprintf (local_label_0, "\"L%011d$spb\"", label);
+  local_label_0 = XALLOCAVEC (char, 16);
+  sprintf (local_label_0, "L%u$spb", label);
 
   fprintf (file, "\tmflr r0\n");
   if (TARGET_LINK_STACK)

Re: [PATCH] Add workaround for broken C/C++ wrappers to LAPACK (PR fortran/90329)

[Jerry DeLisle]

On 5/17/19 10:48 AM, Jeff Law wrote:

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

Hi!

Fortran subroutines/functions that have CHARACTER arguments have also
hidden arguments at the end of the argument list which hold the string
length.  This is something all Fortran compilers I've tried do and is
done in order to support calling unprototyped subroutines/functions
where one can't know if the callee is using character(len=constant)
or character(len=*) argument, where for the latter one has to pass
the extra argument because there is no other way to propagate that info,
while for the former it is kind of redundant but still part of the ABI;
the compiler just uses the constant directly instead of asking about the
real passed string length.

Another thing is that until PR87689 has been fixed, the Fortran FE has been
broken, used vararg-ish prototypes in most cases and that prevented (all?)
tail call optimizations in the Fortran code.

Apparently it is a common case that buggy C/C++ wrappers around the Fortran
functions just ignore the ABI and don't pass the hidden string length
arguments at all, which seemed to work fine in gfortran until recently
(because the arguments weren't used).  When we started making tail calls
from such functions, this has of course changed, because when making a tail
call we overwrite the caller's argument slots with the arguments we want to
pass to the callee.  Not really sure why it seemed to work with other
compilers; trying https://fortran.godbolt.org/z/ckMt1t
subroutine foo (a, b, c, d, e, f, g, h)
   integer :: b, c, d, e, f, g, h
   character(len=1) :: a
   call bar (a, b, c, d, e, f, g, h)
end subroutine foo
both older/new gfortran and ifort 19.0.0 emit a tail call which overwrites
the hidden string length argument with 1, but when trying the
https://fortran.godbolt.org/z/xpsH8e LAPACK routine, ifort for some reason
doesn't tail call it.

I'm not really happy to provide workarounds for undefined behavior,
especially because that will mean it might take longer if ever if those
buggy programs are fixed.  On the other side, the PR87689 bug fix has been
backported to all release branches and so now not only trunk, but also 9.1,
8.3.1 and 7.4.1 are affected.  Instead of trying to disable all tail calls,
this patch disables tail calls from functions/subroutines that have those
hidden string length arguments and don't use character(len=*) (in that case
the function wouldn't seem to work previously either, because the argument
is really used), where those hidden string length arguments are passed
on the stack and where the tail callee also would want to pass arguments
on the stack (if we spent even more time on this, we could narrow it down
further and check if the tail call would actually store anything overlapping
the hidden string length arguments on the stack).

This workaround probably needs guarding with some Fortran FE specific
option, so that it can be disabled, will defer that to the Fortran
maintainers.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
release branches (not sure about LTO on the release branches, does one need
to bump anything when changing the LTO format by streaming another bit)?

2019-05-16  Jakub Jelinek  

PR fortran/90329
* tree-core.h (struct tree_decl_common): Document
decl_nonshareable_flag for PARM_DECLs.
* tree.h (DECL_HIDDEN_STRING_LENGTH): Define.
* calls.c (expand_call): Don't try tail call if caller
has any DECL_HIDDEN_STRING_LENGTH PARM_DECLs that are or might be
passed on the stack and callee needs to pass any arguments on the
stack.
* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Use
else if instead of series of mutually exclusive ifs.  Handle
DECL_HIDDEN_STRING_LENGTH for PARM_DECLs.
* tree-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.

* trans-decl.c (create_function_arglist): Set
DECL_HIDDEN_STRING_LENGTH on hidden string length PARM_DECLs if
len is constant.

My first, second and third thought has been we shouldn't be catering to
code that is so clearly broken.  Maybe we could do this on the release
branches which would in turn give folks roughly a year to fix up this mess?

jeff



Not that I have much say, but I have been following this thread and the others 
about broken wrappers and screwed up prototypes being used by R for there use of 
LAPACK.  I have been holding off saying anything.


I don't thing we should be doing anything in gfortran at all. I think the R 
people need to fix their calls. People get caught by not following the proper 
conventions and then want the compiler to fix it. Its not the compiler writers 
job to fix users bad code. The Fortran conventions of having the string lengths 
appended to the end has been known for many many years and well documented 
everywhere.


Sorry for ranting and I understand everyone is just trying to do the right 

[PATCH, Darwin, PPC] Fix generated code whitespace, NFC.

[Iain Sandoe]

NFC intended, this simply adds a missing tab to the generated code
for pic symbol stubs.

tested on powerpc-darwin9, powerpc-linux-gnu (power7)
applied to mainline
Iain

gcc/

2019-05-17  Iain Sandoe  

* config/rs6000/rs6000.c (macho_branch_islands): Fix bad indent
on the generated code.

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ee44a20..155bc08 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -32986,7 +32986,7 @@ macho_branch_islands (void)
}
   else
{
- strcat (tmp_buf, ":\nlis r12,hi16(");
+ strcat (tmp_buf, ":\n\tlis r12,hi16(");
  strcat (tmp_buf, name_buf);
  strcat (tmp_buf, ")\n\tori r12,r12,lo16(");
  strcat (tmp_buf, name_buf);

Re: [PATCH 5/12] fix diagnostic quoting/spelling in c-family

[David Malcolm]

On Fri, 2019-05-17 at 12:07 -0600, Martin Sebor wrote:
> On 5/17/19 11:16 AM, David Malcolm wrote:
> > On Fri, 2019-05-17 at 09:02 -0600, Martin Sebor wrote:
> > > On 5/17/19 7:43 AM, David Malcolm wrote:
> > > > On Thu, 2019-05-16 at 18:40 -0600, Martin Sebor wrote:
> > > > > On 5/16/19 5:22 PM, Joseph Myers wrote:
> > > > > > On Tue, 14 May 2019, Martin Sebor wrote:
> > > > > > 
> > > > > > > The attached patch fixes quoting, spelling, and other
> > > > > > > formatting
> > > > > > > issues in diagnostics issued from files in the c-family/
> > > > > > > directory
> > > > > > > and pointed out by the -Wformat-diag warning.
> > > > > > 
> > > > > > Some of the changes in this patch are questionable.  The
> > > > > > diagnostics for
> > > > > > attribute scalar_storage_order and visibility arguments use
> > > > > > \"
> > > > > > because the
> > > > > > argument is a string constant not an identifier.  So making
> > > > > > those
> > > > > > use %qs
> > > > > > makes the diagnostics misleading, by suggesting an
> > > > > > attribute
> > > > > > argument is
> > > > > > used that is not in fact valid for that attribute.
> > > > > 
> > > > > Hmm, yes.  I introduced it elsewhere as well in some of my
> > > > > prior
> > > > > changes, and it existed even before then in
> > > > > handle_visibility_attribute:
> > > > > 
> > > > >error ("%qD was declared %qs which implies default
> > > > > visibility",
> > > > >   decl, "dllexport");
> > > > > 
> > > > > There is a way to highlight a string without enclosing it in
> > > > > both
> > > > > single and double quotes:
> > > > > 
> > > > >error ("attribute %qE argument must be one of %r%s%R
> > > > > or
> > > > > %r%s%R",
> > > > >   name, "locus", "\"big-endian\"",
> > > > >   "locus", "\"little-endian\"");
> > > > > 
> > > > > It's not pretty but it does the job.
> > > > 
> > > > Interesting idea, but I'm not sure if it's the right way to go
> > > > here.
> > > > 
> > > > Do we have other examples of highlighting strings within a
> > > > diagnostic?
> > > > 
> > > > The colorization typically doesn't show up in compilation
> > > > logs.  It's
> > > > also not easy to test for in DejaGnu (but I can think of some
> > > > ways
> > > > to
> > > > make that easier).
> > > > 
> > > > >Unless you know of some other
> > > > > trick I'll go with it and fix up the existing mistakes the
> > > > > same
> > > > > way
> > > > > in a followup commit.
> > > > 
> > > > Please can we focus this discussion on what it ought to look
> > > > like
> > > > from
> > > > the end-user's point of view? (rather than on our
> > > > implementation
> > > > details)
> > > > 
> > > > Can you give a concrete example of some source that triggers
> > > > this
> > > > diagnostic, what the current output is, and what the output
> > > > given
> > > > the
> > > > current candidate patch is?
> > > > 
> > > > (i.e. what does it look like to the end-user? what are our
> > > > ideas
> > > > for
> > > > what should it look like?)
> > > > 
> > > > [this may be lack of coffee on my part, but I find it easier to
> > > > think
> > > > and talk about actual input/output examples, rather than
> > > > diagnostic
> > > > API
> > > > calls and DejaGnu testcases, and let the former lead the
> > > > latter]
> > > 
> > > Here's an example:
> > > 
> > > struct __attribute__ ((scalar_storage_order ("big endian")))
> > > S {
> > > int
> > > i; };
> > > 
> > > and here's the output with the latest patch and using %r/%R:
> > > 
> > > $ gcc -O2 -S -Wall b.c
> > > b.c:1:62: error: attribute ‘scalar_storage_order’ argument must
> > > be
> > > one
> > > of "big-endian" or "little-endian"
> > >   1 | struct __attribute__ ((scalar_storage_order ("big
> > > endian")))
> > > S
> > > { int i; };
> > > |
> > >   ^
> > > 
> > > The name scalar_storage_order is highlighted (and in single
> > > quotes)
> > > and the strings "big-endian" and "little-endian" are just
> > > highlighted
> > > (including the quotes, but no single-quotes).  That looks right
> > > to
> > > me but YMMV.
> > > 
> > > What Joseph pointed out is that using %qs to quote big-endian
> > > ends
> > > up with either
> > > 
> > > error: attribute ‘scalar_storage_order’ argument must be one
> > > of
> > > 'big-endian' or 'little-endian'
> > > 
> > > if the strings are just big-endian and little-endian (i.e., not
> > > including the double-quotes), which suggests to the user they
> > > shouldn't be quoted in the source either, or with
> > > 
> > > error: attribute ‘scalar_storage_order’ argument must be one
> > > of
> > > '"big-endian"' or '"little-endian"'
> > 
> > This was actually the thing I had in the back in my mind when I
> > sent my
> > last email.
> > 
> > The above uses "'", but the quoting would use "‘" and "’":
> 
> Sure, depending on the locale.  Either way, we end up two pairs
> of quotes around the string.
> 
> > 
> > error: attribute ‘scalar_storage_order’ argument must be one 

Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713)

[Richard Biener]

On May 17, 2019 6:47:00 PM GMT+02:00, Jeff Law  wrote:
>On 5/16/19 10:17 PM, Feng Xue OS wrote:
>> This patch is meant to give user a way to optimize away those empty
>loops which are impossible to be recognized by compiler, such as C++
>STL container-based loop,
>> 
>> void f (std::map )
>>     {
>>     for (auto it = m.begin (); it != m.end (); ++it);
>>     }
>>  
>> An option "-ffinite-loop" is added to tell compiler about finiteness
>of loops so that compiler can apply the optimization.
>> 
>> Feng
>> 
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index d8bed3a..c55f2e6 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,18 @@
>> +2019-05-16  Feng Xue  
>> +
>> +PR tree-optimization/89713
>> +* doc/invoke.texi (-ffinite-loop): Document new option.
>> +* common.opt (-ffinite-loop): New option.
>> +* passes.def: Replace pass_cd_dce with pass_cd_dce2.
>> +* tree-pass.h (pass_cd_dce2): New declaration.
>> +* tree-ssa-dce.c (loop_has_true_exits): New function.
>> +(find_obviously_necessary_stmts): Add
>aggressive_loop_removal
>> +parameter.
>> +(perform_tree_ssa_dce, tree_ssa_cd_dce): Likewise.
>> +(class pass_cd_dce): Add new member aggressive_loop_removal.
>> +(pass_cd_dce::pass_cd_dce: Add alr parameter.
>> +(make_pass_cd_dce2): New function.
>I'm not a big fan of this patch.  I'd rather be looking at either
>improving our analysis or adding attributes to the loops to help the
>analysis bits prove termination.

And we had sth similar in the past and ended up removing it. 
-funsafe-loop-optimizations IIRC. 

Richard. 

>Jeff

Re: [PATCH 9/12] adjust tests to quoting/spelling diagnostics fixes

[Martin Sebor]

On 5/16/19 1:35 PM, Jeff Law wrote:

On 5/14/19 3:32 PM, Martin Sebor wrote:

The attached patch adjusts the expected test output to the quoting,
spelling and other formatting changes in diagnostics to fix issues
pointed out by the -Wformat-diag warning.

Martin

gcc-wformat-diag-tests.diff

gcc/testsuite/ChangeLog:

* c-c++-common/Wbool-operation-1.c: Adjust text of expected diagnostics.
* c-c++-common/Wvarargs-2.c: Same.
* c-c++-common/Wvarargs.c: Same.
* c-c++-common/pr51768.c: Same.
* c-c++-common/tm/inline-asm.c: Same.
* c-c++-common/tm/safe-1.c: Same.
* g++.dg/asm-qual-1.C: Same.
* g++.dg/asm-qual-3.C: Same.
* g++.dg/conversion/dynamic1.C: Same.
* g++.dg/cpp0x/constexpr-89599.C: Same.
* g++.dg/cpp0x/constexpr-cast.C: Same.
* g++.dg/cpp0x/constexpr-shift1.C: Same.
* g++.dg/cpp0x/lambda/lambda-conv11.C: Same.
* g++.dg/cpp0x/nullptr04.C: Same.
* g++.dg/cpp0x/static_assert12.C: Same.
* g++.dg/cpp0x/static_assert8.C: Same.
* g++.dg/cpp1y/lambda-conv1.C: Same.
* g++.dg/cpp1y/pr79393-3.C: Same.
* g++.dg/cpp1y/static_assert1.C: Same.
* g++.dg/cpp1z/constexpr-if4.C: Same.
* g++.dg/cpp1z/constexpr-if5.C: Same.
* g++.dg/cpp1z/constexpr-if9.C: Same.
* g++.dg/eh/goto2.C: Same.
* g++.dg/eh/goto3.C: Same.
* g++.dg/expr/static_cast8.C: Same.
* g++.dg/ext/flexary5.C: Same.
* g++.dg/ext/utf-array-short-wchar.C: Same.
* g++.dg/ext/utf-array.C: Same.
* g++.dg/ext/utf8-2.C: Same.
* g++.dg/gomp/loop-4.C: Same.
* g++.dg/gomp/macro-4.C: Same.
* g++.dg/gomp/udr-1.C: Same.
* g++.dg/init/initializer-string-too-long.C: Same.
* g++.dg/other/offsetof9.C: Same.
* g++.dg/ubsan/pr63956.C: Same.
* g++.dg/warn/Wbool-operation-1.C: Same.
* g++.dg/warn/Wtype-limits-Wextra.C: Same.
* g++.dg/warn/Wtype-limits.C: Same.
* g++.dg/wrappers/pr88680.C: Same.
* g++.old-deja/g++.mike/eh55.C: Same.
* gcc.dg/Wsign-compare-1.c: Same.
* gcc.dg/Wtype-limits-Wextra.c: Same.
* gcc.dg/Wtype-limits.c: Same.
* gcc.dg/Wunknownprag.c: Same.
* gcc.dg/Wunsuffixed-float-constants-1.c: Same.
* gcc.dg/asm-6.c: Same.
* gcc.dg/asm-qual-1.c: Same.
* gcc.dg/cast-1.c: Same.
* gcc.dg/cast-2.c: Same.
* gcc.dg/cast-3.c: Same.
* gcc.dg/cpp/source_date_epoch-2.c: Same.
* gcc.dg/debug/pr85252.c: Same.
* gcc.dg/dfp/cast-bad.c: Same.
* gcc.dg/format/gcc_diag-1.c: Same.
* gcc.dg/format/gcc_diag-11.c: Same.New test.
* gcc.dg/gcc_diag-11.c: Same.New test.
* gcc.dg/gnu-cond-expr-2.c: Same.
* gcc.dg/gnu-cond-expr-3.c: Same.
* gcc.dg/gomp/macro-4.c: Same.
* gcc.dg/init-bad-1.c: Same.
* gcc.dg/init-bad-2.c: Same.
* gcc.dg/init-bad-3.c: Same.
* gcc.dg/pr27528.c: Same.
* gcc.dg/pr48552-1.c: Same.
* gcc.dg/pr48552-2.c: Same.
* gcc.dg/pr59846.c: Same.
* gcc.dg/pr61096-1.c: Same.
* gcc.dg/pr8788-1.c: Same.
* gcc.dg/pr90082.c: Same.
* gcc.dg/simd-2.c: Same.
* gcc.dg/spellcheck-params-2.c: Same.
* gcc.dg/spellcheck-params.c: Same.
* gcc.dg/strlenopt-49.c: Same.
* gcc.dg/tm/pr52141.c: Same.
* gcc.dg/torture/pr51106-1.c: Same.
* gcc.dg/torture/pr51106-2.c: Same.
* gcc.dg/utf-array-short-wchar.c: Same.
* gcc.dg/utf-array.c: Same.
* gcc.dg/utf8-2.c: Same.
* gcc.dg/warn-sprintf-no-nul.c: Same.
* gcc.target/i386/asm-flag-0.c: Same.
* gcc.target/i386/inline_error.c: Same.
* gcc.target/i386/pr30848.c: Same.
* gcc.target/i386/pr39082-1.c: Same.
* gcc.target/i386/pr39678.c: Same.
* gcc.target/i386/pr57756.c: Same.
* gcc.target/i386/pr68843-1.c: Same.
* gcc.target/i386/pr79804.c: Same.
* gcc.target/i386/pr82673.c: Same.
* obj-c++.dg/class-protocol-1.mm: Same.
* obj-c++.dg/exceptions-3.mm: Same.
* obj-c++.dg/exceptions-4.mm: Same.
* obj-c++.dg/exceptions-5.mm: Same.
* obj-c++.dg/exceptions-6.mm: Same.
* obj-c++.dg/method-12.mm: Same.
* obj-c++.dg/method-13.mm: Same.
* obj-c++.dg/method-6.mm: Same.
* obj-c++.dg/method-7.mm: Same.
* obj-c++.dg/method-9.mm: Same.
* obj-c++.dg/method-lookup-1.mm: Same.
* obj-c++.dg/proto-lossage-4.mm: Same.
* obj-c++.dg/protocol-qualifier-2.mm: Same.
* objc.dg/call-super-2.m: Same.
* objc.dg/class-protocol-1.m: Same.
* objc.dg/desig-init-1.m: Same.
* objc.dg/exceptions-3.m: Same.
* objc.dg/exceptions-4.m: Same.
* objc.dg/exceptions-5.m: Same.
* objc.dg/exceptions-6.m: Same.
* objc.dg/method-19.m: Same.
 

Re: [PATCH 5/12] fix diagnostic quoting/spelling in c-family

[Martin Sebor]

On 5/17/19 11:16 AM, David Malcolm wrote:

On Fri, 2019-05-17 at 09:02 -0600, Martin Sebor wrote:

On 5/17/19 7:43 AM, David Malcolm wrote:

On Thu, 2019-05-16 at 18:40 -0600, Martin Sebor wrote:

On 5/16/19 5:22 PM, Joseph Myers wrote:

On Tue, 14 May 2019, Martin Sebor wrote:


The attached patch fixes quoting, spelling, and other
formatting
issues in diagnostics issued from files in the c-family/
directory
and pointed out by the -Wformat-diag warning.


Some of the changes in this patch are questionable.  The
diagnostics for
attribute scalar_storage_order and visibility arguments use \"
because the
argument is a string constant not an identifier.  So making
those
use %qs
makes the diagnostics misleading, by suggesting an attribute
argument is
used that is not in fact valid for that attribute.


Hmm, yes.  I introduced it elsewhere as well in some of my prior
changes, and it existed even before then in
handle_visibility_attribute:

   error ("%qD was declared %qs which implies default
visibility",
  decl, "dllexport");

There is a way to highlight a string without enclosing it in both
single and double quotes:

   error ("attribute %qE argument must be one of %r%s%R or
%r%s%R",
  name, "locus", "\"big-endian\"",
  "locus", "\"little-endian\"");

It's not pretty but it does the job.


Interesting idea, but I'm not sure if it's the right way to go
here.

Do we have other examples of highlighting strings within a
diagnostic?

The colorization typically doesn't show up in compilation
logs.  It's
also not easy to test for in DejaGnu (but I can think of some ways
to
make that easier).


   Unless you know of some other
trick I'll go with it and fix up the existing mistakes the same
way
in a followup commit.


Please can we focus this discussion on what it ought to look like
from
the end-user's point of view? (rather than on our implementation
details)

Can you give a concrete example of some source that triggers this
diagnostic, what the current output is, and what the output given
the
current candidate patch is?

(i.e. what does it look like to the end-user? what are our ideas
for
what should it look like?)

[this may be lack of coffee on my part, but I find it easier to
think
and talk about actual input/output examples, rather than diagnostic
API
calls and DejaGnu testcases, and let the former lead the latter]


Here's an example:

struct __attribute__ ((scalar_storage_order ("big endian"))) S {
int
i; };

and here's the output with the latest patch and using %r/%R:

$ gcc -O2 -S -Wall b.c
b.c:1:62: error: attribute ‘scalar_storage_order’ argument must be
one
of "big-endian" or "little-endian"
  1 | struct __attribute__ ((scalar_storage_order ("big endian")))
S
{ int i; };
|
  ^

The name scalar_storage_order is highlighted (and in single quotes)
and the strings "big-endian" and "little-endian" are just highlighted
(including the quotes, but no single-quotes).  That looks right to
me but YMMV.

What Joseph pointed out is that using %qs to quote big-endian ends
up with either

error: attribute ‘scalar_storage_order’ argument must be one of
'big-endian' or 'little-endian'

if the strings are just big-endian and little-endian (i.e., not
including the double-quotes), which suggests to the user they
shouldn't be quoted in the source either, or with

error: attribute ‘scalar_storage_order’ argument must be one of
'"big-endian"' or '"little-endian"'


This was actually the thing I had in the back in my mind when I sent my
last email.

The above uses "'", but the quoting would use "‘" and "’":


Sure, depending on the locale.  Either way, we end up two pairs
of quotes around the string.



error: attribute ‘scalar_storage_order’ argument must be one of
‘"big-endian"’ or ‘"little-endian"’


if the strings themselves contain the double-quotes (i.e., are
passed to %qs as "\"big-endian\""...


An easy way to implement this would be via:
   "must be one of %<\"%s\"%> or " etc
which would avoid having to manipulate the name.


Yes, but bug 90156 and check-internal-format-escaping.py want to
banish this form so that's what I've implemented in the -Wformat-
diag checker as well.


Single-quoting a string in
double-quotes, although technically correct, looks odd to me.


I think it's clearer, though I agree it does look odd.

I think I prefer single-quoting the double-quoted string in that the
user isn't meant to have wrapped
   scalar_storage_order
in double-quotes, but they are meant to have wrapped the argument in
double-quotes.


Unpatched trunk doesn't highlight anything which is what I'm fixing.


My other thought is: do we have enough location information to offer
fix-it hints.  Then it could be something like:


I don't think we do have the location of attribute arguments.  It
would be nice if we did for reasons other than the quoting issue.



error: attribute ‘scalar_storage_order’ argument must be
one of ‘"big-endian"’...
1 | struct 

[PATCH] Add myself to MAINTAINERS

[Thomas Rodgers]

diff --git a/ChangeLog b/ChangeLog
index 8a6638497b8..4c8e3c91d55 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2019-05-17  Thomas Rodgers  
+
+	* MAINTAINERS (Write After Approval): Add myself.
+
 2019-05-16  Jun Ma  
 
 	* MAINTAINERS (Write After Approval): Add myself.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c5942ad817..a1809f1ad34 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -554,6 +554,7 @@ Fritz Reese	
 Volker Reichelt	
 Bernhard Reutner-Fischer			
 Tom Rix		
+Thomas Rodgers	
 Craig Rodrigues	
 Erven Rohou	
 Ira Rosen	

Re: [PATCH] Add workaround for broken C/C++ wrappers to LAPACK (PR fortran/90329)

[Jeff Law]

On 5/16/19 2:09 AM, Jakub Jelinek wrote:
> Hi!
> 
> Fortran subroutines/functions that have CHARACTER arguments have also
> hidden arguments at the end of the argument list which hold the string
> length.  This is something all Fortran compilers I've tried do and is
> done in order to support calling unprototyped subroutines/functions
> where one can't know if the callee is using character(len=constant)
> or character(len=*) argument, where for the latter one has to pass
> the extra argument because there is no other way to propagate that info,
> while for the former it is kind of redundant but still part of the ABI;
> the compiler just uses the constant directly instead of asking about the
> real passed string length.
> 
> Another thing is that until PR87689 has been fixed, the Fortran FE has been
> broken, used vararg-ish prototypes in most cases and that prevented (all?)
> tail call optimizations in the Fortran code.
> 
> Apparently it is a common case that buggy C/C++ wrappers around the Fortran
> functions just ignore the ABI and don't pass the hidden string length
> arguments at all, which seemed to work fine in gfortran until recently
> (because the arguments weren't used).  When we started making tail calls
> from such functions, this has of course changed, because when making a tail
> call we overwrite the caller's argument slots with the arguments we want to
> pass to the callee.  Not really sure why it seemed to work with other
> compilers; trying https://fortran.godbolt.org/z/ckMt1t
> subroutine foo (a, b, c, d, e, f, g, h)
>   integer :: b, c, d, e, f, g, h
>   character(len=1) :: a
>   call bar (a, b, c, d, e, f, g, h)
> end subroutine foo
> both older/new gfortran and ifort 19.0.0 emit a tail call which overwrites
> the hidden string length argument with 1, but when trying the
> https://fortran.godbolt.org/z/xpsH8e LAPACK routine, ifort for some reason
> doesn't tail call it.
> 
> I'm not really happy to provide workarounds for undefined behavior,
> especially because that will mean it might take longer if ever if those
> buggy programs are fixed.  On the other side, the PR87689 bug fix has been
> backported to all release branches and so now not only trunk, but also 9.1,
> 8.3.1 and 7.4.1 are affected.  Instead of trying to disable all tail calls,
> this patch disables tail calls from functions/subroutines that have those
> hidden string length arguments and don't use character(len=*) (in that case
> the function wouldn't seem to work previously either, because the argument
> is really used), where those hidden string length arguments are passed
> on the stack and where the tail callee also would want to pass arguments
> on the stack (if we spent even more time on this, we could narrow it down
> further and check if the tail call would actually store anything overlapping
> the hidden string length arguments on the stack).
> 
> This workaround probably needs guarding with some Fortran FE specific
> option, so that it can be disabled, will defer that to the Fortran
> maintainers.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
> release branches (not sure about LTO on the release branches, does one need
> to bump anything when changing the LTO format by streaming another bit)?
> 
> 2019-05-16  Jakub Jelinek  
> 
>   PR fortran/90329
>   * tree-core.h (struct tree_decl_common): Document
>   decl_nonshareable_flag for PARM_DECLs.
>   * tree.h (DECL_HIDDEN_STRING_LENGTH): Define.
>   * calls.c (expand_call): Don't try tail call if caller
>   has any DECL_HIDDEN_STRING_LENGTH PARM_DECLs that are or might be
>   passed on the stack and callee needs to pass any arguments on the
>   stack.
>   * tree-streamer-in.c (unpack_ts_decl_common_value_fields): Use
>   else if instead of series of mutually exclusive ifs.  Handle
>   DECL_HIDDEN_STRING_LENGTH for PARM_DECLs.
>   * tree-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.
> 
>   * trans-decl.c (create_function_arglist): Set
>   DECL_HIDDEN_STRING_LENGTH on hidden string length PARM_DECLs if
>   len is constant.
My first, second and third thought has been we shouldn't be catering to
code that is so clearly broken.  Maybe we could do this on the release
branches which would in turn give folks roughly a year to fix up this mess?

jeff

Re: [PATCH 5/12] fix diagnostic quoting/spelling in c-family

[David Malcolm]

On Fri, 2019-05-17 at 09:02 -0600, Martin Sebor wrote:
> On 5/17/19 7:43 AM, David Malcolm wrote:
> > On Thu, 2019-05-16 at 18:40 -0600, Martin Sebor wrote:
> > > On 5/16/19 5:22 PM, Joseph Myers wrote:
> > > > On Tue, 14 May 2019, Martin Sebor wrote:
> > > > 
> > > > > The attached patch fixes quoting, spelling, and other
> > > > > formatting
> > > > > issues in diagnostics issued from files in the c-family/
> > > > > directory
> > > > > and pointed out by the -Wformat-diag warning.
> > > > 
> > > > Some of the changes in this patch are questionable.  The
> > > > diagnostics for
> > > > attribute scalar_storage_order and visibility arguments use \"
> > > > because the
> > > > argument is a string constant not an identifier.  So making
> > > > those
> > > > use %qs
> > > > makes the diagnostics misleading, by suggesting an attribute
> > > > argument is
> > > > used that is not in fact valid for that attribute.
> > > 
> > > Hmm, yes.  I introduced it elsewhere as well in some of my prior
> > > changes, and it existed even before then in
> > > handle_visibility_attribute:
> > > 
> > >   error ("%qD was declared %qs which implies default
> > > visibility",
> > >  decl, "dllexport");
> > > 
> > > There is a way to highlight a string without enclosing it in both
> > > single and double quotes:
> > > 
> > >   error ("attribute %qE argument must be one of %r%s%R or
> > > %r%s%R",
> > >  name, "locus", "\"big-endian\"",
> > >  "locus", "\"little-endian\"");
> > > 
> > > It's not pretty but it does the job.
> > 
> > Interesting idea, but I'm not sure if it's the right way to go
> > here.
> > 
> > Do we have other examples of highlighting strings within a
> > diagnostic?
> > 
> > The colorization typically doesn't show up in compilation
> > logs.  It's
> > also not easy to test for in DejaGnu (but I can think of some ways
> > to
> > make that easier).
> > 
> > >   Unless you know of some other
> > > trick I'll go with it and fix up the existing mistakes the same
> > > way
> > > in a followup commit.
> > 
> > Please can we focus this discussion on what it ought to look like
> > from
> > the end-user's point of view? (rather than on our implementation
> > details)
> > 
> > Can you give a concrete example of some source that triggers this
> > diagnostic, what the current output is, and what the output given
> > the
> > current candidate patch is?
> > 
> > (i.e. what does it look like to the end-user? what are our ideas
> > for
> > what should it look like?)
> > 
> > [this may be lack of coffee on my part, but I find it easier to
> > think
> > and talk about actual input/output examples, rather than diagnostic
> > API
> > calls and DejaGnu testcases, and let the former lead the latter]
> 
> Here's an example:
> 
>struct __attribute__ ((scalar_storage_order ("big endian"))) S {
> int 
> i; };
> 
> and here's the output with the latest patch and using %r/%R:
> 
> $ gcc -O2 -S -Wall b.c
> b.c:1:62: error: attribute ‘scalar_storage_order’ argument must be
> one 
> of "big-endian" or "little-endian"
>  1 | struct __attribute__ ((scalar_storage_order ("big endian")))
> S 
> { int i; };
>| 
>  ^
> 
> The name scalar_storage_order is highlighted (and in single quotes)
> and the strings "big-endian" and "little-endian" are just highlighted
> (including the quotes, but no single-quotes).  That looks right to
> me but YMMV.
> 
> What Joseph pointed out is that using %qs to quote big-endian ends
> up with either
> 
>error: attribute ‘scalar_storage_order’ argument must be one of 
> 'big-endian' or 'little-endian'
> 
> if the strings are just big-endian and little-endian (i.e., not
> including the double-quotes), which suggests to the user they
> shouldn't be quoted in the source either, or with
> 
>error: attribute ‘scalar_storage_order’ argument must be one of 
> '"big-endian"' or '"little-endian"'

This was actually the thing I had in the back in my mind when I sent my
last email.

The above uses "'", but the quoting would use "‘" and "’":

   error: attribute ‘scalar_storage_order’ argument must be one of 
   ‘"big-endian"’ or ‘"little-endian"’

> if the strings themselves contain the double-quotes (i.e., are
> passed to %qs as "\"big-endian\""...  

An easy way to implement this would be via:
  "must be one of %<\"%s\"%> or " etc
which would avoid having to manipulate the name.

> Single-quoting a string in
> double-quotes, although technically correct, looks odd to me.

I think it's clearer, though I agree it does look odd.

I think I prefer single-quoting the double-quoted string in that the
user isn't meant to have wrapped
  scalar_storage_order
in double-quotes, but they are meant to have wrapped the argument in
double-quotes.

> Unpatched trunk doesn't highlight anything which is what I'm fixing.

My other thought is: do we have enough location information to offer
fix-it hints.  Then it could be 

Re: [PATCH] Export forgotten _gfortran_{,m,s}findloc0_i2 (PR fortran/54613)

[Thomas Koenig]

Hi Jakub,


I've found that gfortran.map doesn't export these 3 symbols (while it does
export other variants, with i1, i4, i8, i16, etc.).
Do we want to export them from both GCC 9.2 and 10 the following way, or
just on the trunk using GFORTRAN_10?


Both, please.


Tested on x86_64-linux.

Another thing is, but that one isn't just about exported symbols, but also
about not even generating such files and listing them in Makefile.am,
there are no findloc r10 entrypoints.  Is that intentional?


No, it is not.


BTW, this shows that there is no testsuite coverage for findloc (but
apparently not for minloc, maxloc etc.) that would actually try all the
supported kinds and have at least one test for each supported kind, that
is something that would have caught this.


It is not only the supported kinds, it is also the version of findloc
that is called. There are five findloc*.m4 files, three of them for
character and two for numeric types. Each of of the m4 files
contains several functions, and the correct one is chosen from
the presence or absence (and rank and ...) of certain arguments.

(At least we got rid of the combinatorial explosion with the different
return kinds with minloc/maxloc.  I would not be surprised if some of
these are missing, too...)

So, OK for the patch (and the other one with the _r10 files), and
thanks!

Regards

Thomas

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

[Alexander Monakov]

On Fri, 17 May 2019, Jeff Law wrote:

> So my question is are these showing up in practice?  The gimple based
> tests seem to be skipping the optimizers that would have eliminated this
> stuff.
> 
> In each of the testcases I would have expected jump threading to have
> eliminated the problematical path through the CFG.

If there's anything slightly complicated, like say a loop, between the
(lack of) definition and the use, optimizations won't be able to simplify
the flow and the false positive/negative can be seen.

In fact Vlad's first patch submission used a trivial loop in a C testcase
alongside a minimized gimple testcase to showcase how this happens:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00040.html

Alexander

Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713)

[Jeff Law]

On 5/16/19 10:17 PM, Feng Xue OS wrote:
> This patch is meant to give user a way to optimize away those empty loops 
> which are impossible to be recognized by compiler, such as C++ STL 
> container-based loop,
> 
> void f (std::map )
>     {
>     for (auto it = m.begin (); it != m.end (); ++it);
>     }
>  
> An option "-ffinite-loop" is added to tell compiler about finiteness of loops 
> so that compiler can apply the optimization.
> 
> Feng
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index d8bed3a..c55f2e6 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,18 @@
> +2019-05-16  Feng Xue  
> +
> +PR tree-optimization/89713
> +* doc/invoke.texi (-ffinite-loop): Document new option.
> +* common.opt (-ffinite-loop): New option.
> +* passes.def: Replace pass_cd_dce with pass_cd_dce2.
> +* tree-pass.h (pass_cd_dce2): New declaration.
> +* tree-ssa-dce.c (loop_has_true_exits): New function.
> +(find_obviously_necessary_stmts): Add aggressive_loop_removal
> +parameter.
> +(perform_tree_ssa_dce, tree_ssa_cd_dce): Likewise.
> +(class pass_cd_dce): Add new member aggressive_loop_removal.
> +(pass_cd_dce::pass_cd_dce: Add alr parameter.
> +(make_pass_cd_dce2): New function.
I'm not a big fan of this patch.  I'd rather be looking at either
improving our analysis or adding attributes to the loops to help the
analysis bits prove termination.

Jeff

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

[Jeff Law]

On 5/17/19 2:12 AM, Vladislav Ivanishin wrote:
> Hi!
> 
> Without the patch, two of the newly added tests fail with bogus warnings:
> 
> - gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
>   BIT_AND_EXPR.  This is an FP my previous patch [1] knowingly
>   overlooks.)
> - gcc.dg/uninit-30-gimple.c (EQ_EXPR in the predicate guarding use.
>   This is what I spotted while refactoring.  It never worked, and is
>   easy to handle).
> 
> Bootstraped with `BOOT_CFLAGS="-O -Wno-error=maybe-uninitialized
> -Wuninitialized"` and regtested on x86_64-pc-linux-gnu.  OK for trunk?
> 
> Also, Richard, would you mind being a sponsor for my svn account?
> 
> [1]: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00896.html
> 
> 
> 0001-tree-ssa-uninit-suppress-more-spurious-warnings.patch
> 
>   * tree-ssa-uninit.c (value_sat_pred_p): This new function is a wrapper
> around is_value_included_in that knows how to handle BIT_AND_EXPR.
> (is_pred_expr_subset_of): Use the new function.  Handle more cases 
> where
> code1 == EQ_EXPR and where code1 == BIT_AND_EXPR and thus fix some 
> false
> positives.
> 
> testsuite/
> * gcc.dg/uninit-28-gimple.c: New test.
> * gcc.dg/uninit-29-gimple.c: New test.
> * gcc.dg/uninit-30-gimple.c: New test.
> * gcc.dg/uninit-31-gimple.c: New test.
So my question is are these showing up in practice?  The gimple based
tests seem to be skipping the optimizers that would have eliminated this
stuff.

In each of the testcases I would have expected jump threading to have
eliminated the problematical path through the CFG.

I'm not philosophically opposed to improving tree-ssa-uninit.c, but I
just want to understand why we're looking at this aspect of it right now.

If you wanted an interesting project to tackle, separating the predicate
analysis done by tree-ssa-uninit.c from using it to prune false positive
-Wuninitialized warnings would be hugely appreciated.  I think there's
value in re-using the predicate analysis elsewhere in GCC.

jeff

ps. You could list me as a sponsor if Richi doesn't respond.

Re: [RFC, PATCH] Don't introduce useless edge splits unless in PRE

[Vladislav Ivanishin]

Richard Biener  writes:

> On Tue, May 14, 2019 at 3:58 PM Vladislav Ivanishin  wrote:
>>
>> Hi!
>>
>> The split_critical_edges() function has multiple uses and it seems, a
>> portion of its code was added to work only when called from tree-ssa-pre
>> but right now it is executed regardless of the caller.
>>
>> The below patch survives bootstrap and regression testing on
>> x86_64-pc-linux-gnu.  Does it make sense?
>
> Yeah.  Please rename the in_pre_p parameter to for_edge_insertion_p
> since that is what it ensures.  Note that the use in tree-ssa-sink.c
> also requires this since it looks for places to sink code to.  Similar
> the use in tree-tail-merge.c (where I'm not sure why it needs split
> critical edges at all...).
>
> So, it seems more safe to have the default of the parameter to true,
> or rather have no default but adjust all few cases effectively only
> changing the one before uninit.
>
> Better (source) documentation would be using an overload,
> split_edges_for_insertion?

Thanks for the feedback. 

Here is a safer version of the patch.

gcc/ChangeLog:

* tree-cfg.h (split_critical_edges): Add for_edge_insertion_p
	parameter with default value false to declaration.
(split_edges_for_insertion): New inline function.  Wrapper for
	split_critical_edges with for_edge_insertion_p = true.
* tree-cfg.c (split_critical_edges): Don't split non-critical
	edges if for_edge_insertion_p is false.  Fix whitespace.
* tree-ssa-pre.c (pass_pre::execute): Call
	split_edges_for_insertion instead of split_critical_edges.
* gcc/tree-ssa-tail-merge.c (tail_merge_optimize): Ditto.
* gcc/tree-ssa-sink.c (pass_sink_code::execute): Ditto.
	(pass_data_sink_code): Update function name in the comment.
---
 gcc/tree-cfg.c| 14 --
 gcc/tree-cfg.h|  9 -
 gcc/tree-ssa-pre.c|  2 +-
 gcc/tree-ssa-sink.c   |  4 ++--
 gcc/tree-ssa-tail-merge.c |  2 +-
 5 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index c6a70c8f10b..eacf494d45f 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -8899,10 +8899,11 @@ struct cfg_hooks gimple_cfg_hooks = {
 };
 
 
-/* Split all critical edges.  */
+/* Split all critical edges.  Split some extra (not necessarily critical) edges
+   if FOR_EDGE_INSERTION_P is true.  */
 
 unsigned int
-split_critical_edges (void)
+split_critical_edges (bool for_edge_insertion_p /* = false */)
 {
   basic_block bb;
   edge e;
@@ -8925,11 +8926,12 @@ split_critical_edges (void)
 	 end by control flow statements, such as RESX.
 	 Go ahead and split them too.  This matches the logic in
 	 gimple_find_edge_insert_loc.  */
-	  else if ((!single_pred_p (e->dest)
-	|| !gimple_seq_empty_p (phi_nodes (e->dest))
-		|| e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun))
+	  else if (for_edge_insertion_p
+		   && (!single_pred_p (e->dest)
+		   || !gimple_seq_empty_p (phi_nodes (e->dest))
+		   || e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun))
 		   && e->src != ENTRY_BLOCK_PTR_FOR_FN (cfun)
-	   && !(e->flags & EDGE_ABNORMAL))
+		   && !(e->flags & EDGE_ABNORMAL))
 	{
 	  gimple_stmt_iterator gsi;
 
diff --git a/gcc/tree-cfg.h b/gcc/tree-cfg.h
index 212f5ff5919..836f8e8af51 100644
--- a/gcc/tree-cfg.h
+++ b/gcc/tree-cfg.h
@@ -105,7 +105,7 @@ extern void extract_true_false_edges_from_block (basic_block, edge *, edge *);
 extern tree find_case_label_for_value (const gswitch *switch_stmt, tree val);
 extern edge find_taken_edge_switch_expr (const gswitch *switch_stmt, tree val);
 extern unsigned int execute_fixup_cfg (void);
-extern unsigned int split_critical_edges (void);
+extern unsigned int split_critical_edges (bool for_edge_insertion_p = false);
 extern basic_block insert_cond_bb (basic_block, gimple *, gimple *,
    profile_probability);
 extern bool gimple_find_sub_bbs (gimple_seq, gimple_stmt_iterator *);
@@ -128,4 +128,11 @@ should_remove_lhs_p (tree lhs)
 	  && !TREE_ADDRESSABLE (TREE_TYPE (lhs)));
 }
 
+
+inline unsigned int
+split_edges_for_insertion ()
+{
+  return split_critical_edges (/*for_edge_insertion_p=*/true);
+}
+
 #endif /* _TREE_CFG_H  */
diff --git a/gcc/tree-ssa-pre.c b/gcc/tree-ssa-pre.c
index 469199fa213..086f8c6 100644
--- a/gcc/tree-ssa-pre.c
+++ b/gcc/tree-ssa-pre.c
@@ -4183,7 +4183,7 @@ pass_pre::execute (function *fun)
   /* This has to happen before VN runs because
  loop_optimizer_init may create new phis, etc.  */
   loop_optimizer_init (LOOPS_NORMAL);
-  split_critical_edges ();
+  split_edges_for_insertion ();
   scev_initialize ();
   calculate_dominance_info (CDI_DOMINATORS);
 
diff --git a/gcc/tree-ssa-sink.c b/gcc/tree-ssa-sink.c
index fe762f54d96..77abe3aa4b6 100644
--- a/gcc/tree-ssa-sink.c
+++ b/gcc/tree-ssa-sink.c
@@ -610,7 +610,7 @@ const pass_data pass_data_sink_code =
   "sink", /* name */
   OPTGROUP_NONE, /* optinfo_flags */
   TV_TREE_SINK, /* tv_id */
-  /* PROP_no_crit_edges is 

Re: [PATCH] Fix __builtin_init_dwarf_reg_size_table when built with -mfpxx

[Jeff Law]

On 5/16/19 7:15 AM, Dragan Mladjenovic wrote:
> Ping.
> 
> 
> 
> From: Dragan Mladjenovic
> Sent: Thursday, May 9, 2019 12:29 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Dragan Mladjenovic; Jakub Jelinek; Matthew Fortune
> Subject: [PATCH] Fix __builtin_init_dwarf_reg_size_table when built with 
> -mfpxx
> 
> From: "Dragan Mladjenovic" 
> 
> 
> Hi all,
> 
> For TARGET_FLOATXX the odd-numbered FP registers in SFmode are
> HARD_REGNO_CALL_PART_CLOBBERED. This causes dwarf_frame_reg_mode to fall
> back to VOIDmode and for __builtin_init_dwarf_reg_size_table to fill them
> as zero sized.
> 
> This prevents libgcc's unwinder form ever restoring high parts of
> calle-saved double precision registers.
> 
> This patch fixes the issue by forcing dwarf_frame_reg_mode to use SImode
> for FP registers.
> 
> Bootstrapped and done regression tests on mipsel-unknown-linux-gnu -
> no new failures found.
> 
> 
> Best regards,
> Dragan
> 
> 
> gcc/ChangeLog:
> 
> 2019-04-23  Dragan Mladjenovic  
> 
>   * gcc/config/mips/mips.c(mips_dwarf_frame_reg_mode): Replace TARGET_FLOAT64
>   with !TARGET_FLOAT32, thus handling both fp64 and fpxx modes.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-04-23  Dragan Mladjenovic  
> 
>   * g++.dg/eh/o32-fp.C: New.
>   * gcc.target/mips/dwarfregtable-1.c: New.
>   * gcc.target/mips/dwarfregtable-2.c: New.
>   * gcc.target/mips/dwarfregtable-3.c: New.
>   * gcc.target/mips/dwarfregtable-4.c: New.
>   * gcc.target/mips/dwarfregtable.h: New.
THanks.  I've installed this on the trunk.
jeff

Hashtable comment cleanups & renamings

[François Dumont]

Hi

    I got tired of '__n' being used in _Hashtable for many different 
purposes: node, bucket, bucket count, bucket hint. It makes the code 
difficult to read. This code makes sure that __n is a node except is 
some very limited use cases where the method name is clear enough to 
tell what __n means.


    So I'd like to commit this patch which only change that and some 
comments before moving forward to more serious stuff. The only code 
change is a use of auto return type on _M_allocate_node.


    My main concern is the ChangeLog entry. Is the following entry ok ?

    Rename variables and cleanup comments.
    * include/bits/hashtable_policy.h
    * include/bits/hashtable.h

    Tested under Linux x86_64 (even if it can't be otherwise)

François

diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index ab24b5bb537..78e6aeed5b1 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -253,7 +253,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	_Equal, _H1, _H2, _Hash,
 	_RehashPolicy, _Traits>;
 
-  using __reuse_or_alloc_node_type =
+  using __reuse_or_alloc_node_gen_t =
 	__detail::_ReuseOrAllocNode<__node_alloc_type>;
 
   // Metaprogramming for picking apart hash caching.
@@ -278,9 +278,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 		"Cache the hash code or qualify your functors involved"
 		" in hash code and bucket index computation with noexcept");
 
-  // Following two static assertions are necessary to guarantee
-  // that local_iterator will be default constructible.
-
   // When hash codes are cached local iterator inherits from H2 functor
   // which must then be default constructible.
   static_assert(__if_hash_cached>::value,
@@ -331,7 +328,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _RehashPolicy		_M_rehash_policy;
 
   // A single bucket used when only need for 1 bucket. Especially
-  // interesting in move semantic to leave hashtable with only 1 buckets
+  // interesting in move semantic to leave hashtable with only 1 bucket
   // which is not allocated so that we can have those operations noexcept
   // qualified.
   // Note that we can't leave hashtable with 0 bucket without adding
@@ -350,24 +347,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_base_alloc() { return *this; }
 
   __bucket_type*
-  _M_allocate_buckets(size_type __n)
+  _M_allocate_buckets(size_type __bkt_count)
   {
-	if (__builtin_expect(__n == 1, false))
+	if (__builtin_expect(__bkt_count == 1, false))
 	  {
 	_M_single_bucket = nullptr;
 	return &_M_single_bucket;
 	  }
 
-	return __hashtable_alloc::_M_allocate_buckets(__n);
+	return __hashtable_alloc::_M_allocate_buckets(__bkt_count);
   }
 
   void
-  _M_deallocate_buckets(__bucket_type* __bkts, size_type __n)
+  _M_deallocate_buckets(__bucket_type* __bkts, size_type __bkt_count)
   {
 	if (_M_uses_single_bucket(__bkts))
 	  return;
 
-	__hashtable_alloc::_M_deallocate_buckets(__bkts, __n);
+	__hashtable_alloc::_M_deallocate_buckets(__bkts, __bkt_count);
   }
 
   void
@@ -394,10 +391,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	_M_assign(const _Hashtable&, const _NodeGenerator&);
 
   void
-  _M_move_assign(_Hashtable&&, std::true_type);
+  _M_move_assign(_Hashtable&&, true_type);
 
   void
-  _M_move_assign(_Hashtable&&, std::false_type);
+  _M_move_assign(_Hashtable&&, false_type);
 
   void
   _M_reset() noexcept;
@@ -439,30 +436,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { }
 
   explicit
-  _Hashtable(size_type __n,
+  _Hashtable(size_type __bkt_hint,
 		 const _H1& __hf = _H1(),
 		 const key_equal& __eql = key_equal(),
 		 const allocator_type& __a = allocator_type())
-  : _Hashtable(__n, __hf, _H2(), _Hash(), __eql,
+  : _Hashtable(__bkt_hint, __hf, _H2(), _Hash(), __eql,
 		   __key_extract(), __a)
   { }
 
   template
 	_Hashtable(_InputIterator __f, _InputIterator __l,
-		   size_type __n = 0,
+		   size_type __bkt_hint = 0,
 		   const _H1& __hf = _H1(),
 		   const key_equal& __eql = key_equal(),
 		   const allocator_type& __a = allocator_type())
-	: _Hashtable(__f, __l, __n, __hf, _H2(), _Hash(), __eql,
+	: _Hashtable(__f, __l, __bkt_hint, __hf, _H2(), _Hash(), __eql,
 		 __key_extract(), __a)
 	{ }
 
   _Hashtable(initializer_list __l,
-		 size_type __n = 0,
+		 size_type __bkt_hint = 0,
 		 const _H1& __hf = _H1(),
 		 const key_equal& __eql = key_equal(),
 		 const allocator_type& __a = allocator_type())
-  : _Hashtable(__l.begin(), __l.end(), __n, __hf, _H2(), _Hash(), __eql,
+  : _Hashtable(__l.begin(), __l.end(), __bkt_hint,
+		   __hf, _H2(), _Hash(), __eql,
 		   __key_extract(), __a)
   { }
 
@@ -485,7 +483,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Hashtable&
   operator=(initializer_list __l)
   {
-	__reuse_or_alloc_node_type __roan(_M_begin(), 

Re: [PATCH] x86-64: Add vararg ABI tests

[Uros Bizjak]

On Fri, May 17, 2019 at 5:05 PM H.J. Lu  wrote:
>
> On Fri, May 17, 2019 at 12:08 AM Uros Bizjak  wrote:
> >
> > On Thu, May 16, 2019 at 10:10 PM H.J. Lu  wrote:
> > >
> > > We can scan stack for return address to get vector arguments passed on
> > > stack.
> > >
> > > * gcc.target/x86_64/abi/test_varargs-m128.c: New file.
> > > * gcc.target/x86_64/abi/avx/test_varargs-m256.c: Likewise.
> > > * gcc.target/x86_64/abi/avx512f/test_varargs-m512.c: Likewise.
> >
> > Bootstrapped and regression tested on which target? Does x32 passes the 
> > test?
>
> Tested on Linux/x86-64 and Linux/x32.
>
> > > +  /* Check __m256 arguments passed on stack.  */
> > > +  argp = (__m256 *) (((char *) fp) + 8);
> >
> > It took me a while to figure out that RA slot is skipped here. Please
> > add some comment, maybe:
> >
> >   /* Skip return address stack slot.  */
> >   argp = (__m256 *) (((char *) fp) + 8);
> >
> >   /* Check __m256 arguments passed on stack.  */
> >   compare (values.i4, argp[0], __m256);
> >
>
> Updated.
>
> Here is the updated patch.   OK for trunk?

LGTM.

Thanks,
Uros.

Re: [PATCH][RFC] Come up with TARGET_HAS_FAST_MEMPCPY_ROUTINE (PR middle-end/90263).

[Jeff Law]

On 5/15/19 5:35 AM, Martin Liška wrote:
> On 5/14/19 5:07 PM, Martin Sebor wrote:
>> On 5/14/19 8:55 AM, Martin Liška wrote:
>>> On 5/13/19 3:07 PM, Jakub Jelinek wrote:
 On Mon, May 13, 2019 at 12:14:37PM +0200, Martin Liška wrote:
> On 5/10/19 11:21 AM, Jakub Jelinek wrote:
>> On Fri, May 10, 2019 at 11:04:12AM +0200, Martin Liška wrote:
>>> --- a/gcc/config/i386/i386.h
>>> +++ b/gcc/config/i386/i386.h
>>> @@ -1906,6 +1906,9 @@ typedef struct ix86_args {
>>>     #define CLEAR_RATIO(speed) ((speed) ? MIN (6, 
>>> ix86_cost->move_ratio) : 2)
>>>   +/* C library provides fast implementation of mempcpy function.  */
>>> +#define TARGET_HAS_FAST_MEMPCPY_ROUTINE 1
>>> +
>> 1) we shouldn't be adding further target macros, but target hooks
> Done.
>
>> 2) I don't think this is a property of the x86 target, but of x86 glibc,
>>     so you should set it on x86 glibc only (i.e. i?86/x86_64 linux and 
>> hurd
>>     when using glibc, not newlib, nor bionic/android, nor uclibc, nor 
>> musl)
> I've implemented the in i386.c with DEFAULT_LIBC == LIBC_GLIBC. Hope it's 
> correct?
 No, that would be correct only in the rare SINGLE_LIBC configurations.
 Either you can do
 #ifdef OPTION_GLIBC
    return OPTION_GLIBC;
 #else
    return false;
 #endif
 or define something in config/linux.h (or .[ch]) that you can then use in
 i386.c.

 Jakub

>>> Hi.
>>>
>>> You always have nice ideas. I'm sending updated patch which addresses both 
>>> Jakub's
>>> and Wilco's comments.
>>>
>> index 66cee075018..7bff5cbd313 100644
>> --- a/gcc/target.def
>> +++ b/gcc/target.def
>> @@ -5797,6 +5797,12 @@ DEFHOOK
>>   const char *, (void),
>>   hook_constcharptr_void_null)
>>
>> +DEFHOOK
>> +(has_fast_mempcpy_routine,
>> + "Return true if a target has a fast mempcpy routine.",
>> + bool, (void),
>> + hook_bool_void_false)
>> +
>>
>> Not to be too nit-picky about the name but target.def refers to
>> functions rather than routines.  It also defines a hook called
>> libc_has_function with the obvious semantics so if there's
>> a chance that it could be useful to query whether another libc
>> function is "fast" I would suggest to consider defining the hook
>> correspondingly, i.e.,
>>
>>   bool libc_has_fast_function (enum function_class)
>>
>> and naming the macro similarly.
>>
>> Martin
> Hi Martin.
> 
> That's a very good suggestion and I'm implementing that!
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Thanks,
> Martin
> 
> 
> 0001-Come-up-with-hook-libc_has_fast_function-PR-middle-e.patch
> 
> From f865ba74008acc651e9ef2fbfc9f2d4bb9ce8fb8 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Mon, 29 Apr 2019 13:46:25 +0200
> Subject: [PATCH] Come up with hook libc_has_fast_function (PR
>  middle-end/90263).
> 
> gcc/ChangeLog:
> 
> 2019-05-15  Martin Liska  
> 
>   PR middle-end/90263
>   * builtins.c (expand_builtin_memory_copy_args): When having a
>   target with fast mempcpy implementation do now use memcpy.
>   * config/i386/i386.c (ix86_libc_has_fast_function): New.
>   (TARGET_LIBC_HAS_FAST_FUNCTION): Likewise.
>   * doc/tm.texi: Likewise.
>   * doc/tm.texi.in: Likewise.
>   * target.def:
>   * expr.c (emit_block_move_hints): Add 2 new arguments.
>   * expr.h (emit_block_move_hints): Bail out when libcall
>   to memcpy would be used.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-05-15  Martin Liska  
> 
>   PR middle-end/90263
>   * gcc.c-torture/compile/pr90263.c: New test.
>   * lib/target-supports.exp: Add check_effective_target_glibc.
> ---
>  gcc/builtins.c| 17 +++--
>  gcc/config/i386/i386.c| 15 +++
>  gcc/doc/tm.texi   |  5 +
>  gcc/doc/tm.texi.in|  2 ++
>  gcc/expr.c| 13 -
>  gcc/expr.h|  4 +++-
>  gcc/target.def|  7 +++
>  gcc/testsuite/gcc.c-torture/compile/pr90263.c | 10 ++
>  gcc/testsuite/lib/target-supports.exp | 11 +++
>  9 files changed, 80 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr90263.c
>
OK
jeff

Re: preserve more debug stmts in gimple jump threading

[Jeff Law]

On 5/15/19 2:20 AM, Alexandre Oliva wrote:
> Gimple jump threading does not duplicate forwarder blocks that might
> be present before or after the second copied block.  This silently
> drops debug binds and markers that might be present in them.  This
> patch attempts to preserve them.
> 
> For blocks after either copied block, we attempt to append debug stmts
> to the copied block, if it does not end with a block-ending stmt.
> Failing that, for blocks between both copied blocks, we prepend its
> debug stmts to the copy of the second block.
> 
> If everything fails, we still drop debug stmts on the floor, though
> preexisting code consolidates debug binds in the block that threading
> flows into, so only markers are really lost.  We can't do much better
> than that without conditional binds and markers, or debug stmts in
> edges, or somesuch.
> 
> If we append debug stmts to a reusable template block, we copy it
> after splitting out the debug stmts, and before putting them back.
> 
> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok to install?
> 
> 
> for  gcc/ChangeLog
> 
>   * tree-ssa-threadupdate.c (struct ssa_local_info_t): Add
>   field template_last_to_copy.
>   (ssa_create_duplicates): Set it, and use it.  Attempt to
>   preserve more debug stmts.
OK.  Presumably creating a reliable testcase was painful?

jeff
> ---

Re: [PATCH] Add workaround for broken C/C++ wrappers to LAPACK (PR fortran/90329)

[Jeff Law]

On 5/16/19 3:36 AM, Jakub Jelinek wrote:
> On Thu, May 16, 2019 at 11:22:08AM +0200, Richard Biener wrote:
>> Which reminds me I forgot to update LTO_major_version on trunk - can
>> you do that?
> 
> Done with:
> 
> 2019-05-16  Jakub Jelinek  
> 
>   * lto-streamer.h (LTO_major_version): Bump to 9.
OK
jeff

Re: [PATCH] Export forgotten _gfortran_{,m,s}findloc{0,1}_r10 (PR fortran/54613)

[Jakub Jelinek]

On Fri, May 17, 2019 at 02:16:36PM +0200, Jakub Jelinek wrote:
> As the attached testcase shows, that can't be intentional, as that
> testcase fails to link.

Forgot to attach the testcases (that said, it would be better to write
something cleaner, perhaps one call for each library entry-point to be
tested, not really sure how best to iterate over all supported kinds)
that fail to link without these patches.

Jakub
! { dg-do run }
! Various tests with findloc.
program main
  implicit none
  integer(kind=2), dimension(2,2) :: a, b
  integer, dimension(2,3) :: c
  logical, dimension(2,2) :: lo
  integer, dimension(:), allocatable :: e
  a = reshape([1,2,3,4], shape(a))
  b = reshape([1,2,1,2], shape(b))

  lo = .true.

  if (any(findloc(a, 5) /= [0,0])) stop 1
  if (any(findloc(a, 5, back=.true.) /= [0,0])) stop 2
  if (any(findloc(a, 2) /= [2,1])) stop 2
  if (any(findloc(a, 2 ,back=.true.) /= [2,1])) stop 3

  if (any(findloc(a,3,mask=lo) /= [1,2])) stop 4
  if (any(findloc(a,3,mask=.true.) /= [1,2])) stop 5
  lo(1,2) = .false.
  if (any(findloc(a,3,mask=lo) /= [0,0])) stop 6
  if (any(findloc(b,2) /= [2,1])) stop 7
  if (any(findloc(b,2,back=.true.) /= [2,2])) stop 8
  if (any(findloc(b,1,mask=lo,back=.true.) /= [1,1])) stop 9
  if (any(findloc(b,1,mask=.false.) /= [0,0])) stop 10

  c = reshape([1,2,2,2,-9,6], shape(c))
  if (any(findloc(c,value=2,dim=1) /= [2,1,0])) stop 11
  if (any(findloc(c,value=2,dim=2) /= [2,1])) stop 12
end program main
! { dg-do run }
! Various tests with findloc.
program main
  implicit none
  real(kind=10), dimension(2,2) :: a, b
  integer, dimension(2,3) :: c
  logical, dimension(2,2) :: lo
  integer, dimension(:), allocatable :: e
  a = reshape([1.,2.,3.,4.], shape(a))
  b = reshape([1.,2.,1.,2.], shape(b))

  lo = .true.

  if (any(findloc(a, 5.) /= [0,0])) stop 1
  if (any(findloc(a, 5., back=.true.) /= [0,0])) stop 2
  if (any(findloc(a, 2.) /= [2,1])) stop 2
  if (any(findloc(a, 2. ,back=.true.) /= [2,1])) stop 3

  if (any(findloc(a,3.,mask=lo) /= [1,2])) stop 4
  if (any(findloc(a,3,mask=.true.) /= [1,2])) stop 5
  lo(1,2) = .false.
  if (any(findloc(a,3.,mask=lo) /= [0,0])) stop 6
  if (any(findloc(b,2.) /= [2,1])) stop 7
  if (any(findloc(b,2.,back=.true.) /= [2,2])) stop 8
  if (any(findloc(b,1.,mask=lo,back=.true.) /= [1,1])) stop 9
  if (any(findloc(b,1.,mask=.false.) /= [0,0])) stop 10

  c = reshape([1,2,2,2,-9,6], shape(c))
  if (any(findloc(c,value=2,dim=1) /= [2,1,0])) stop 11
  if (any(findloc(c,value=2,dim=2) /= [2,1])) stop 12
end program main

Re: [PATCH 0/3] Small clean up of profile_{count,probability}

[Jeff Law]

On 5/17/19 1:28 AM, Martin Liška wrote:
> PING^1
> 
> On 4/29/19 1:01 PM, marxin wrote:
>> The patch makes couple of adjustements:
>> 1) I changed enum values to use capital letters. It's aligned with
>>our coding style and it makes the code more readable. E.g.
>>profile_quality::profile_guessed_local
>>vs. static profile_probability guessed_always ()
>>
>> 2) I removed usage of fully qualified names.
>> 3) I added vertical spaces to separate different functions (operators).
>>
>> Survives bootstrap and tests on x86_64-linux-gnu.
>>
>> Ready for trunk after 9.1 release?
>> Thanks,
>> Martin
>>
>> marxin (3):
>>   Use cappital letters for enum value names.
>>   Do not use full qualified names if possible.
>>   Add vertical spacing in order to separate functions.
>>
>>  gcc/profile-count.c |  76 +--
>>  gcc/profile-count.h | 320 +---
>>  2 files changed, 220 insertions(+), 176 deletions(-)
>>
> 
OK
jeff

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 17, 2019, at 4:07 PM, Jason Merrill  wrote:
> 
> On Tue, May 14, 2019 at 12:11 PM Maxim Kuvyrkov
>  wrote:
>> 
>> This patch adds scripts to contrib/ to migrate full history of GCC's 
>> subversion repository to git.  My hope is that these scripts will finally 
>> allow GCC project to migrate to Git.
> 
> Thanks for looking into this.  My feeling has been that, if we give up
> on reposurgeon, there's no need to start a new conversion at all: we
> can just switch the current mirror over to being the primary
> repository with some minor surgery (e.g. using git filter-branch to
> fix subdirectory branches).  That approach will produce the least
> disruption in the workflows of people already using it.  Do you see a
> problem with this?

No technical problem.  The scripts start with the existing git mirror and only 
convert the parts that are not present in it.  FWIW, the scripts can start with 
a bare repo, but that would take longer time.

It is a good idea to run a test conversion without using existing mirror as 
cache to confirm that there are no discrepancies in repos produced by old and 
new versions of git-svn.

However, if the community decides that we want use author maps, then, iiuc, the 
new repo would not be compatible with the existing mirror.

--
Maxim Kuvyrkov
www.linaro.org

Re: [PATCH] x86-64: Add vararg ABI tests

[H.J. Lu]

On Fri, May 17, 2019 at 12:08 AM Uros Bizjak  wrote:
>
> On Thu, May 16, 2019 at 10:10 PM H.J. Lu  wrote:
> >
> > We can scan stack for return address to get vector arguments passed on
> > stack.
> >
> > * gcc.target/x86_64/abi/test_varargs-m128.c: New file.
> > * gcc.target/x86_64/abi/avx/test_varargs-m256.c: Likewise.
> > * gcc.target/x86_64/abi/avx512f/test_varargs-m512.c: Likewise.
>
> Bootstrapped and regression tested on which target? Does x32 passes the test?

Tested on Linux/x86-64 and Linux/x32.

> > +  /* Check __m256 arguments passed on stack.  */
> > +  argp = (__m256 *) (((char *) fp) + 8);
>
> It took me a while to figure out that RA slot is skipped here. Please
> add some comment, maybe:
>
>   /* Skip return address stack slot.  */
>   argp = (__m256 *) (((char *) fp) + 8);
>
>   /* Check __m256 arguments passed on stack.  */
>   compare (values.i4, argp[0], __m256);
>

Updated.

Here is the updated patch.   OK for trunk?

Thanks.

-- 
H.J.
From 4a9ab6e9d543dc921e00ef39d24e00f04f8450a0 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 16 May 2019 11:31:40 -0700
Subject: [PATCH] x86-64: Add vararg ABI tests

We can scan stack for return address to get vector arguments passed on
stack.

Tested on Linux/x86-64 and Linux/x32.

	* gcc.target/x86_64/abi/test_varargs-m128.c: New file.
	* gcc.target/x86_64/abi/avx/test_varargs-m256.c: Likewise.
	* gcc.target/x86_64/abi/avx512f/test_varargs-m512.c: Likewise.
---
 .../x86_64/abi/avx/test_varargs-m256.c| 104 +
 .../x86_64/abi/avx512f/test_varargs-m512.c| 104 +
 .../gcc.target/x86_64/abi/test_varargs-m128.c | 110 ++
 3 files changed, 318 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/x86_64/abi/avx/test_varargs-m256.c
 create mode 100644 gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_varargs-m512.c
 create mode 100644 gcc/testsuite/gcc.target/x86_64/abi/test_varargs-m128.c

diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx/test_varargs-m256.c b/gcc/testsuite/gcc.target/x86_64/abi/avx/test_varargs-m256.c
new file mode 100644
index 000..0c6d61f072f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx/test_varargs-m256.c
@@ -0,0 +1,104 @@
+/* Test variable number of 256-bit vector arguments passed to functions.  */
+
+#include 
+#include "avx-check.h"
+#include "args.h"
+
+struct IntegerRegisters iregs;
+struct FloatRegisters fregs;
+
+/* This struct holds values for argument checking.  */
+struct 
+{
+  YMM_T i0, i1, i2, i3, i4, i5, i6, i7, i8, i9;
+} values;
+
+char *pass;
+int failed = 0;
+
+#undef assert
+#define assert(c) do { \
+  if (!(c)) {failed++; printf ("failed %s\n", pass); } \
+} while (0)
+
+#define compare(X1,X2,T) do { \
+  assert (memcmp (, , sizeof (T)) == 0); \
+} while (0)
+
+void
+fun_check_passing_m256_varargs (__m256 i0, __m256 i1, __m256 i2,
+__m256 i3, ...)
+{
+  /* Check argument values.  */
+  void **fp = __builtin_frame_address (0);
+  void *ra = __builtin_return_address (0);
+  __m256 *argp;
+
+  compare (values.i0, i0, __m256);
+  compare (values.i1, i1, __m256);
+  compare (values.i2, i2, __m256);
+  compare (values.i3, i3, __m256);
+
+  /* Get the pointer to the return address on stack.  */
+  while (*fp != ra)
+fp++;
+
+  /* Skip the return address stack slot.  */
+  argp = (__m256 *) (((char *) fp) + 8);
+
+  /* Check __m256 arguments passed on stack.  */
+  compare (values.i4, argp[0], __m256);
+  compare (values.i5, argp[1], __m256);
+  compare (values.i6, argp[2], __m256);
+  compare (values.i7, argp[3], __m256);
+  compare (values.i8, argp[4], __m256);
+  compare (values.i9, argp[5], __m256);
+
+  /* Check register contents.  */
+  compare (fregs.ymm0, ymm_regs[0], __m256);
+  compare (fregs.ymm1, ymm_regs[1], __m256);
+  compare (fregs.ymm2, ymm_regs[2], __m256);
+  compare (fregs.ymm3, ymm_regs[3], __m256);
+}
+
+#define def_check_int_passing_varargs(_i0, _i1, _i2, _i3, _i4, _i5, \
+  _i6, _i7, _i8, _i9, \
+  _func, TYPE) \
+  values.i0.TYPE[0] = _i0; \
+  values.i1.TYPE[0] = _i1; \
+  values.i2.TYPE[0] = _i2; \
+  values.i3.TYPE[0] = _i3; \
+  values.i4.TYPE[0] = _i4; \
+  values.i5.TYPE[0] = _i5; \
+  values.i6.TYPE[0] = _i6; \
+  values.i7.TYPE[0] = _i7; \
+  values.i8.TYPE[0] = _i8; \
+  values.i9.TYPE[0] = _i9; \
+  clear_struct_registers; \
+  fregs.F0.TYPE[0] = _i0; \
+  fregs.F1.TYPE[0] = _i1; \
+  fregs.F2.TYPE[0] = _i2; \
+  fregs.F3.TYPE[0] = _i3; \
+  WRAP_CALL(_func) (_i0, _i1, _i2, _i3, _i4, _i5, _i6, _i7, _i8, _i9);
+
+void
+test_m256_varargs (void)
+{
+  __m256 x[10];
+  int i;
+  for (i = 0; i < 10; i++)
+x[i] = (__m256){32+i, 0, 0, 0, 0, 0, 0, 0};
+  pass = "m256-varargs";
+  def_check_int_passing_varargs (x[0], x[1], x[2], x[3], x[4], x[5],
+ x[6], x[7], x[8], x[9],
+ fun_check_passing_m256_varargs,
+ _m256);
+}
+
+void
+avx_test (void)
+{
+  test_m256_varargs ();
+  if (failed)
+abort ();
+}
diff --git 

Re: [PATCH 5/12] fix diagnostic quoting/spelling in c-family

[Martin Sebor]

On 5/17/19 7:43 AM, David Malcolm wrote:

On Thu, 2019-05-16 at 18:40 -0600, Martin Sebor wrote:

On 5/16/19 5:22 PM, Joseph Myers wrote:

On Tue, 14 May 2019, Martin Sebor wrote:


The attached patch fixes quoting, spelling, and other formatting
issues in diagnostics issued from files in the c-family/
directory
and pointed out by the -Wformat-diag warning.


Some of the changes in this patch are questionable.  The
diagnostics for
attribute scalar_storage_order and visibility arguments use \"
because the
argument is a string constant not an identifier.  So making those
use %qs
makes the diagnostics misleading, by suggesting an attribute
argument is
used that is not in fact valid for that attribute.


Hmm, yes.  I introduced it elsewhere as well in some of my prior
changes, and it existed even before then in
handle_visibility_attribute:

  error ("%qD was declared %qs which implies default visibility",
 decl, "dllexport");

There is a way to highlight a string without enclosing it in both
single and double quotes:

  error ("attribute %qE argument must be one of %r%s%R or %r%s%R",
 name, "locus", "\"big-endian\"",
 "locus", "\"little-endian\"");

It's not pretty but it does the job.


Interesting idea, but I'm not sure if it's the right way to go here.

Do we have other examples of highlighting strings within a diagnostic?

The colorization typically doesn't show up in compilation logs.  It's
also not easy to test for in DejaGnu (but I can think of some ways to
make that easier).


  Unless you know of some other
trick I'll go with it and fix up the existing mistakes the same way
in a followup commit.


Please can we focus this discussion on what it ought to look like from
the end-user's point of view? (rather than on our implementation
details)

Can you give a concrete example of some source that triggers this
diagnostic, what the current output is, and what the output given the
current candidate patch is?

(i.e. what does it look like to the end-user? what are our ideas for
what should it look like?)

[this may be lack of coffee on my part, but I find it easier to think
and talk about actual input/output examples, rather than diagnostic API
calls and DejaGnu testcases, and let the former lead the latter]


Here's an example:

  struct __attribute__ ((scalar_storage_order ("big endian"))) S { int 
i; };


and here's the output with the latest patch and using %r/%R:

$ gcc -O2 -S -Wall b.c
b.c:1:62: error: attribute ‘scalar_storage_order’ argument must be one 
of "big-endian" or "little-endian"
1 | struct __attribute__ ((scalar_storage_order ("big endian"))) S 
{ int i; };

  |  ^

The name scalar_storage_order is highlighted (and in single quotes)
and the strings "big-endian" and "little-endian" are just highlighted
(including the quotes, but no single-quotes).  That looks right to
me but YMMV.

What Joseph pointed out is that using %qs to quote big-endian ends
up with either

  error: attribute ‘scalar_storage_order’ argument must be one of 
'big-endian' or 'little-endian'


if the strings are just big-endian and little-endian (i.e., not
including the double-quotes), which suggests to the user they
shouldn't be quoted in the source either, or with

  error: attribute ‘scalar_storage_order’ argument must be one of 
'"big-endian"' or '"little-endian"'


if the strings themselves contain the double-quotes (i.e., are
passed to %qs as "\"big-endian\""...  Single-quoting a string in
double-quotes, although technically correct, looks odd to me.

Unpatched trunk doesn't highlight anything which is what I'm fixing.

Martin

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 17, 2019, at 3:22 PM, Martin Liška  wrote:
> 
> On 5/17/19 1:06 AM, Joseph Myers wrote:
>> That repository 
>> represents what I consider the collaboratively built consensus on such 
>> things as the desired author map (including handling of the ambiguous 
>> author name), which directories represent branches and tags, and what tags 
>> should be kept or removed - but building up such a consensus and keeping 
> 
> About the map. I agree with Richard that we should do best approach and not
> to fully reconstruct history of people who has switched email address multi
> times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
> a clean up:
> 
> - for logins with duplicite emails I chose the latest one used on gcc-patches 
> mailing list
> - comments were removed
> - a few entries contained timezone and I stripped that
> 
> Final version of the map can be seen here:
> https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map
> 
> @Maxim: would it be possible to update your script so that it will use:
> --authors-file=gcc.map ?

Should not be a problem.  I'll try that.

> 
> Is it desired for the transition to use the author map? Do we want it?

IIUC, the downside is that converted repo will not match current git mirror 
unless we do log re-writing, which would add extra info on the side.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 17, 2019, at 2:06 AM, Joseph Myers  wrote:
> 
> On Tue, 14 May 2019, Maxim Kuvyrkov wrote:
> 
>> The scripts convert svn history branch by branch.  They rely on git-svn 
>> on convert individual branches.  Git-svn is a good tool for converting 
>> individual branches.  It is, however, either very slow at converting the 
>> entire GCC repo, or goes into infinite loop.
> 
> I think git-svn is in fact a bad tool for repository conversion when the 
> history is nontrivial (for the reasons that have been discussed at length 
> in the past),

I agree with this.  However, with git -- we don't need to force ourselves to 
convert the whole history in one go; git-svn seems to be doing a good job at 
converting branch at a time.

> and we should convert with reposurgeon.

If reposurgeon works -- great, let's convert with it.  It's good to have two 
independent tools so that we can compare and sanity check the results; from the 
top of my head:
1. number of merges should match on all branches,
2. changed files should match for all revisions.

What I want to avoid is delaying the switch to git.

> 
> ESR, can you give an update on the status of the conversion with 
> reposurgeon?  You said "another serious attack on the repository 
> conversion is probably about two months out" in 
> .  Is it on target to be 
> done by the time of the GNU Tools Cauldron in Montreal in September?
> 
> And, could you bring git://thyrsus.com/repositories/gcc-conversion.git up 
> to date with changes since Jan 2018, or push the latest version of that 
> repository to some other public hosting location?  That repository 
> represents what I consider the collaboratively built consensus on such 
> things as the desired author map (including handling of the ambiguous 
> author name), which directories represent branches and tags, and what tags 
> should be kept or removed - but building up such a consensus and keeping 
> it up to date over time (for new committers etc.) requires that the public 
> repository actually reflects the latest version of the conversion 
> machinery, day by day as the consensus develops.  Review of that 
> repository will be important for reviewing the details of whether the 
> conversion is being done as desired - the details of the machinery will 
> help suggest things to spot-check in a converted repository.



--
Maxim Kuvyrkov
www.linaro.org

Re: [PATCH] i386: Enable MMX intrinsics without SSE/SSE2/SSSE3

[H.J. Lu]

On Thu, May 16, 2019 at 11:21 PM Uros Bizjak  wrote:
>
> On Thu, May 16, 2019 at 11:59 PM H.J. Lu  wrote:
> >
> > Since MMX intrinsics are marked with SSE/SSE2/SSSE3 for SSE emulation,
> > enable them without SSE/SSE2/SSSE3 if MMX is enabled.
> >
> > Restore TARGET_3DNOW check, which was changed to TARGET_3DNOW_A by
> > revision 271235.
> >
> > gcc/
> >
> > PR target/90497
> > * config/i386/i386-expand.c (ix86_expand_builtin): Enable MMX
> > intrinsics without SSE/SSE2/SSSE3.
> > * config/i386/mmx.md (mmx_uavgv8qi3): Restore TARGET_3DNOW
> > check.
> > (*mmx_uavgv8qi3): Likewise.
>
> OK with a small nit.
>
> Thanks,
> Uros.
>
> >
> > gcc/testsuite/
> >
> > PR target/90497
> > * gcc.target/i386/pr90497-1.c: New test.
> > * gcc.target/i386/pr90497-2.c: Likewise.
> > ---
> >  gcc/config/i386/i386-expand.c |  6 --
> >  gcc/config/i386/mmx.md|  4 ++--
> >  gcc/testsuite/gcc.target/i386/pr90497-1.c | 12 
> >  gcc/testsuite/gcc.target/i386/pr90497-2.c | 11 +++
> >  4 files changed, 29 insertions(+), 4 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr90497-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr90497-2.c
> >
> > diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> > index df035607fa7..35aadefdef3 100644
> > --- a/gcc/config/i386/i386-expand.c
> > +++ b/gcc/config/i386/i386-expand.c
> > @@ -10937,8 +10937,10 @@ ix86_expand_builtin (tree exp, rtx target, rtx 
> > subtarget,
> >&& (isa & (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4)) != 0)
> >  isa |= (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4);
> >/* Use SSE/SSE2/SSSE3 to emulate MMX intrinsics in 64-bit mode when
> > - MMX is disabled.  */
> > -  if (TARGET_MMX_WITH_SSE)
> > + MMX is disabled.  NB: Since MMX intrinsics are marked with
> > + SSE/SSE2/SSSE3, enable them without SSE/SSE2/SSSE3 if MMX is
> > + enabled.  */
> > +  if (TARGET_MMX_WITH_SSE || TARGET_MMX)
>
> Please use  "TARGET_MMX || TARGET_MMX_WITH_SSE" as is the case with
> all these conditions.
>

This is what I am checking in.

Thanks.

-- 
H.J.
From 0b333fd40fb43f65858a9441e21e2abe8f910a8a Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Wed, 15 May 2019 14:33:42 -0700
Subject: [PATCH] i386: Enable MMX intrinsics without SSE/SSE2/SSSE3

Since MMX intrinsics are marked with SSE/SSE2/SSSE3 for SSE emulation,
enable them without SSE/SSE2/SSSE3 if MMX is enabled.

Restore TARGET_3DNOW check, which was changed to TARGET_3DNOW_A by
revision 271235.

gcc/

	PR target/90497
	* config/i386/i386-expand.c (ix86_expand_builtin): Enable MMX
	intrinsics without SSE/SSE2/SSSE3.
	* config/i386/mmx.md (mmx_uavgv8qi3): Restore TARGET_3DNOW
	check.
	(*mmx_uavgv8qi3): Likewise.

gcc/testsuite/

	PR target/90497
	* gcc.target/i386/pr90497-1.c: New test.
	* gcc.target/i386/pr90497-2.c: Likewise.
---
 gcc/config/i386/i386-expand.c |  6 --
 gcc/config/i386/mmx.md|  4 ++--
 gcc/testsuite/gcc.target/i386/pr90497-1.c | 12 
 gcc/testsuite/gcc.target/i386/pr90497-2.c | 11 +++
 4 files changed, 29 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr90497-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr90497-2.c

diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index df035607fa7..f2a82a01899 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -10937,8 +10937,10 @@ ix86_expand_builtin (tree exp, rtx target, rtx subtarget,
   && (isa & (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4)) != 0)
 isa |= (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4);
   /* Use SSE/SSE2/SSSE3 to emulate MMX intrinsics in 64-bit mode when
- MMX is disabled.  */
-  if (TARGET_MMX_WITH_SSE)
+ MMX is disabled.  NB: Since MMX intrinsics are marked with
+ SSE/SSE2/SSSE3, enable them without SSE/SSE2/SSSE3 if MMX is
+ enabled.  */
+  if (TARGET_MMX || TARGET_MMX_WITH_SSE)
 {
   if (((bisa & (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_MMX))
 	   == (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_MMX))
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 29bcf931836..adad950fa04 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -1745,7 +1745,7 @@
   (const_int 1) (const_int 1)]))
 	(const_int 1]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE)
-   && (TARGET_SSE || TARGET_3DNOW_A)"
+   && (TARGET_SSE || TARGET_3DNOW)"
   "ix86_fixup_binary_operands_no_copy (PLUS, V8QImode, operands);")
 
 (define_insn "*mmx_uavgv8qi3"
@@ -1764,7 +1764,7 @@
   (const_int 1) (const_int 1)]))
 	(const_int 1]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE)
-   && (TARGET_SSE || TARGET_3DNOW_A)
+   && (TARGET_SSE || TARGET_3DNOW)
&& ix86_binary_operator_ok (PLUS, V8QImode, operands)"
 {
   /* These two instructions have the same operation, but their encoding
diff 

[PATCH] PR libstdc++/90246 Improve text of std::variant exceptions and assertions

[Jonathan Wakely]

PR libstdc++/90246
* include/std/variant (holds_alternative, get, get_if): Improve
static assertion messages.
(bad_variant_access::bad_variant_access()): Change default message.
(__throw_bad_variant_access(bool)): New overload.
(get): Use new overload.
(visit, visit): Improve exception message.

Tested x86_64-linux, committed to trunk.


commit dfb7731e63f19549ba31e3b89dc0ec63a3f3119e
Author: Jonathan Wakely 
Date:   Thu Apr 25 17:20:26 2019 +0100

PR libstdc++/90246 Improve text of std::variant exceptions and assertions

PR libstdc++/90246
* include/std/variant (holds_alternative, get, get_if): Improve
static assertion messages.
(bad_variant_access::bad_variant_access()): Change default message.
(__throw_bad_variant_access(bool)): New overload.
(get): Use new overload.
(visit, visit): Improve exception message.

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index eec41750da7..60472b4c799 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1065,7 +1065,7 @@ namespace __variant
 holds_alternative(const variant<_Types...>& __v) noexcept
 {
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
-   "T should occur for exactly once in alternatives");
+   "T must occur exactly once in alternatives");
   return __v.index() == __detail::__variant::__index_of_v<_Tp, _Types...>;
 }
 
@@ -1073,7 +1073,7 @@ namespace __variant
 constexpr _Tp& get(variant<_Types...>& __v)
 {
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
-   "T should occur for exactly once in alternatives");
+   "T must occur exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
   return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(__v);
 }
@@ -1082,7 +1082,7 @@ namespace __variant
 constexpr _Tp&& get(variant<_Types...>&& __v)
 {
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
-   "T should occur for exactly once in alternatives");
+   "T must occur exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
   return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(
std::move(__v));
@@ -1092,7 +1092,7 @@ namespace __variant
 constexpr const _Tp& get(const variant<_Types...>& __v)
 {
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
-   "T should occur for exactly once in alternatives");
+   "T must occur exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
   return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(__v);
 }
@@ -1101,7 +1101,7 @@ namespace __variant
 constexpr const _Tp&& get(const variant<_Types...>&& __v)
 {
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
-   "T should occur for exactly once in alternatives");
+   "T must occur exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
   return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(
std::move(__v));
@@ -1139,7 +1139,7 @@ namespace __variant
 get_if(variant<_Types...>* __ptr) noexcept
 {
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
-   "T should occur for exactly once in alternatives");
+   "T must occur exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
   return std::get_if<__detail::__variant::__index_of_v<_Tp, _Types...>>(
  __ptr);
@@ -1150,7 +1150,7 @@ namespace __variant
 get_if(const variant<_Types...>* __ptr) noexcept
 {
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
-   "T should occur for exactly once in alternatives");
+   "T must occur exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
   return std::get_if<__detail::__variant::__index_of_v<_Tp, _Types...>>(
  __ptr);
@@ -1213,22 +1213,34 @@ namespace __variant
   class bad_variant_access : public exception
   {
   public:
-bad_variant_access() noexcept : _M_reason("Unknown reason") { }
+bad_variant_access() noexcept { }
+
 const char* what() const noexcept override
 { return _M_reason; }
 
   private:
-bad_variant_access(const char* __reason) : _M_reason(__reason) { }
+bad_variant_access(const char* __reason) noexcept : _M_reason(__reason) { }
 
-const char* _M_reason;
+// Must point to a string with static storage duration:
+const char* 

Re: C++ PATCH to improve diagnostic for non-type template parameters

[Marek Polacek]

Ping.

On Fri, May 10, 2019 at 07:10:16PM -0400, Marek Polacek wrote:
> When we have 
> 
>   template
>   struct S { };
> 
> then in
> 
>S s;
> 
> "int()" is resolved to a type-id, as per [temp.arg]/2, causing this program to
> fail to compile.  This can be rather confusing so I think we want to improve 
> the
> diagnostic a bit. 
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2019-05-10  Marek Polacek  
> 
>   * pt.c (convert_template_argument): Add a diagnostic for the
>   [temp.arg]/2 ambiguity case.
> 
>   * g++.dg/cpp2a/nontype-class17.C: New test.
> 
> diff --git gcc/cp/pt.c gcc/cp/pt.c
> index 08da94ae0c9..b38e65d7f7e 100644
> --- gcc/cp/pt.c
> +++ gcc/cp/pt.c
> @@ -7961,10 +7961,22 @@ convert_template_argument (tree parm,
>"parameter list for %qD",
>i + 1, in_decl);
> if (is_type)
> - inform (input_location,
> - "  expected a constant of type %qT, got %qT",
> - TREE_TYPE (parm),
> - (DECL_P (arg) ? DECL_NAME (arg) : orig_arg));
> + {
> +   /* The template argument is a type, but we're expecting
> +  an expression.  */
> +   inform (input_location,
> +   "  expected a constant of type %qT, got %qT",
> +   TREE_TYPE (parm),
> +   (DECL_P (arg) ? DECL_NAME (arg) : orig_arg));
> +   /* [temp.arg]/2: "In a template-argument, an ambiguity
> +  between a type-id and an expression is resolved to a
> +  type-id, regardless of the form of the corresponding
> +  template-parameter."  So give the user a clue.  */
> +   if (TREE_CODE (arg) == FUNCTION_TYPE)
> + inform (input_location, "  template argument for "
> + "non-type template parameter is treated as "
> + "function type");
> + }
> else if (requires_tmpl_type)
>   inform (input_location,
>   "  expected a class template, got %qE", orig_arg);
> diff --git gcc/testsuite/g++.dg/cpp2a/nontype-class17.C 
> gcc/testsuite/g++.dg/cpp2a/nontype-class17.C
> new file mode 100644
> index 000..ca5f68e1611
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp2a/nontype-class17.C
> @@ -0,0 +1,17 @@
> +// { dg-do compile { target c++2a } }
> +
> +template
> +struct S { };
> +
> +struct R { };
> +
> +void
> +g (void)
> +{
> +  S s; // { dg-error "mismatch" }
> +// { dg-message "treated as function" "note" { target *-*-* } .-1 }
> +  S s2;
> +  S s3; // { dg-error "mismatch" }
> +// { dg-message "treated as function" "note" { target *-*-* } .-1 }
> +  S s4;
> +}

Marek

Re: C++ PATCH to implement deferred parsing of noexcept-specifiers (c++/86476, c++/52869)

[Marek Polacek]

Ping.

On Fri, May 10, 2019 at 03:21:33PM -0400, Marek Polacek wrote:
> Coming back to this.  I didn't think this was suitable for GCC 9.
> 
> On Mon, Jan 07, 2019 at 10:44:37AM -0500, Jason Merrill wrote:
> > On 12/19/18 3:27 PM, Marek Polacek wrote:
> > > Prompted by Jon's observation in 52869, I noticed that we don't treat
> > > a noexcept-specifier as a complete-class context of a class 
> > > ([class.mem]/6).
> > > As with member function bodies, default arguments, and NSDMIs, names used 
> > > in
> > > a noexcept-specifier of a member-function can be declared later in the 
> > > class
> > > body, so we need to wait and parse them at the end of the class.
> > > For that, I've made use of DEFAULT_ARG (now best to be renamed to 
> > > UNPARSED_ARG).
> > 
> > Or DEFERRED_PARSE, yes.
> 
> I didn't change the name but I'm happy to do it as a follow up.
> 
> > > +  /* We can't compare unparsed noexcept-specifiers.  Save the old decl
> > > + and check this again after we've parsed the noexcept-specifiers
> > > + for real.  */
> > > +  if (UNPARSED_NOEXCEPT_SPEC_P (new_exceptions))
> > > +{
> > > +  vec_safe_push (DEFARG_INSTANTIATIONS (TREE_PURPOSE 
> > > (new_exceptions)),
> > > +  copy_decl (old_decl));
> > > +  return;
> > > +}
> > 
> > Why copy_decl?
> 
> This is so that we don't lose the diagnostic in noexcept46.C.  If I don't use
> copy_decl then the tree is shared and subsequent changes to it make us not
> detect discrepancies like noexcept(false) vs. noexcept(true) on the same decl.
> 
> > It seems wasteful to allocate a vec to hold this single decl; let's make the
> > last field of tree_default_arg a union instead.  And add a new macro for the
> > single decl case.
> 
> Done.  But that required also adding GTY markers *and* a new BOOL_BITFIELD for
> the sake of GTY((desc)).
> 
> > I notice that default_arg currently uses tree_common for some reason, and we
> > ought to be able to save two words by switching to tree_base
> 
> Done.
> 
> > > @@ -1245,6 +1245,7 @@ nothrow_spec_p (const_tree spec)
> > > || TREE_VALUE (spec)
> > > || spec == noexcept_false_spec
> > > || TREE_PURPOSE (spec) == error_mark_node
> > > +   || TREE_CODE (TREE_PURPOSE (spec)) == DEFAULT_ARG
> > 
> > Maybe use UNPARSED_NOEXCEPT_SPEC_P here?
>  
> Done.
> 
> > > +/* Make sure that any member-function parameters are in scope.
> > > +   For instance, a function's noexcept-specifier can use the function's
> > > +   parameters:
> > > +
> > > +   struct S {
> > > + void fn (int p) noexcept(noexcept(p));
> > > +   };
> > > +
> > > +   so we need to make sure name lookup can find them.  This is used
> > > +   when we delay parsing of the noexcept-specifier.  */
> > > +
> > > +static void
> > > +maybe_begin_member_function_processing (tree decl)
> > 
> > This name is pretty misleading.  How about inject_parm_decls, to go with
> > inject_this_parameter?
> 
> Done.
> 
> > > +/* Undo the effects of maybe_begin_member_function_processing.  */
> > > +
> > > +static void
> > > +maybe_end_member_function_processing (void)
> > 
> > And then perhaps pop_injected_parms.
> 
> Done.
> 
> > > +/* Check throw specifier of OVERRIDER is at least as strict as
> > > +   the one of BASEFN.  */
> > > +
> > > +bool
> > > +maybe_check_throw_specifier (tree overrider, tree basefn)
> > > +{
> > > +  maybe_instantiate_noexcept (basefn);
> > > +  maybe_instantiate_noexcept (overrider);
> > > +  tree base_throw = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (basefn));
> > > +  tree over_throw = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (overrider));
> > > +
> > > +  if (DECL_INVALID_OVERRIDER_P (overrider))
> > > +return true;
> > > +
> > > +  /* Can't check this yet.  Pretend this is fine and let
> > > + noexcept_override_late_checks check this later.  */
> > > +  if (UNPARSED_NOEXCEPT_SPEC_P (base_throw)
> > > +  || UNPARSED_NOEXCEPT_SPEC_P (over_throw))
> > > +return true;
> > > +
> > > +  if (!comp_except_specs (base_throw, over_throw, ce_derived))
> > > +{
> > > +  auto_diagnostic_group d;
> > > +  error ("looser throw specifier for %q+#F", overrider);
> > 
> > Since we're touching this diagnostic, let's correct it now to "exception
> > specification".  And add "on overriding virtual function".
> 
> Ok, changed to the more up-to-date term.
> 
> Two further changes were required since my changes to detecting 'this' for
> static member functions:
> 1) use THIS_FORBIDDEN if needed when parsing the delayed noexcept,
> 2) careful about friend member functions -- its DECL_CONTEXT is not the
>   containing class, need to use DECL_FRIEND_CONTEXT.
> 
> Both of these points are tested in g++.dg/cpp0x/this1.C.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2019-05-10  Marek Polacek  
> 
>   PR c++/86476 - noexcept-specifier is a complete-class context.
>   PR c++/52869
>   * cp-tree.def (DEFAULT_ARG): Update commentary.
>   * cp-tree.h 

[PATCH] Fix uses of non-reserved names for template parameters

[Jonathan Wakely]

* include/bits/random.h (seed_seq::param): Fix non-reserved name.
* include/experimental/type_traits (is_detected_exact)
(is_detected_exact_v): Likewise.
* include/pstl/execution_defs.h (is_execution_policy)
(is_execution_policy_v, __enable_if_execution_policy): Likewise.
* include/pstl/execution_impl.h (__policy_traits): Likewise.
* testsuite/17_intro/names.cc: Check for more non-reserved names.
* testsuite/experimental/names.cc: New test.

Tested powerpc64le-linux, committed to trunk.

Tom, two pieces of this need to be fixed in upstream PSTL too.


commit 95d3f45c61c52c82d0a0faa3ecd55394a114c5ec
Author: Jonathan Wakely 
Date:   Fri May 17 13:17:00 2019 +0100

Fix uses of non-reserved names for template parameters

* include/bits/random.h (seed_seq::param): Fix non-reserved name.
* include/experimental/type_traits (is_detected_exact)
(is_detected_exact_v): Likewise.
* include/pstl/execution_defs.h (is_execution_policy)
(is_execution_policy_v, __enable_if_execution_policy): Likewise.
* include/pstl/execution_impl.h (__policy_traits): Likewise.
* testsuite/17_intro/names.cc: Check for more non-reserved names.
* testsuite/experimental/names.cc: New test.

diff --git a/libstdc++-v3/include/bits/random.h 
b/libstdc++-v3/include/bits/random.h
index 3f5ae53086e..2b1df4cb59e 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -6080,9 +6080,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 size_t size() const noexcept
 { return _M_v.size(); }
 
-template
+template
   void
-  param(OutputIterator __dest) const
+  param(_OutputIterator __dest) const
   { std::copy(_M_v.begin(), _M_v.end(), __dest); }
 
 // no copy functions
diff --git a/libstdc++-v3/include/experimental/type_traits 
b/libstdc++-v3/include/experimental/type_traits
index c2b2dcc2739..2403bd24223 100644
--- a/libstdc++-v3/include/experimental/type_traits
+++ b/libstdc++-v3/include/experimental/type_traits
@@ -252,12 +252,12 @@ template class 
_Op, typename... _Args>
 template class _Op, typename... _Args>
   using detected_or_t = typename detected_or<_Default, _Op, _Args...>::type;
 
-template class _Op, typename... _Args>
-  using is_detected_exact = is_same>;
+template class _Op, typename... 
_Args>
+  using is_detected_exact = is_same<_Expected, detected_t<_Op, _Args...>>;
 
-template class _Op, typename... _Args>
+template class _Op, typename... 
_Args>
   constexpr bool is_detected_exact_v
-= is_detected_exact::value;
+= is_detected_exact<_Expected, _Op, _Args...>::value;
 
 template class _Op, typename... _Args>
   using is_detected_convertible
diff --git a/libstdc++-v3/include/pstl/execution_defs.h 
b/libstdc++-v3/include/pstl/execution_defs.h
index 9a4b49bd46a..1a551c7871c 100644
--- a/libstdc++-v3/include/pstl/execution_defs.h
+++ b/libstdc++-v3/include/pstl/execution_defs.h
@@ -117,7 +117,7 @@ constexpr parallel_unsequenced_policy par_unseq{};
 constexpr unsequenced_policy unseq{};
 
 // 2.3, Execution policy type trait
-template 
+template 
 struct is_execution_policy : std::false_type
 {
 };
@@ -142,8 +142,8 @@ struct 
is_execution_policy<__pstl::execution::unsequenced_policy> : std::true_ty
 };
 
 #if __PSTL_CPP14_VARIABLE_TEMPLATES_PRESENT
-template 
-constexpr bool is_execution_policy_v = 
__pstl::execution::is_execution_policy::value;
+template 
+constexpr bool is_execution_policy_v = 
__pstl::execution::is_execution_policy<_Tp>::value;
 #endif
 
 } // namespace v1
@@ -151,10 +151,10 @@ constexpr bool is_execution_policy_v = 
__pstl::execution::is_execution_policy
 
 namespace __internal
 {
-template 
+template 
 using __enable_if_execution_policy =
-typename std::enable_if<__pstl::execution::is_execution_policy::type>::value,
-T>::type;
+typename std::enable_if<__pstl::execution::is_execution_policy::type>::value,
+_Tp>::type;
 } // namespace __internal
 
 } // namespace __pstl
diff --git a/libstdc++-v3/include/pstl/execution_impl.h 
b/libstdc++-v3/include/pstl/execution_impl.h
index 8ee5fa062a8..cbebbbd4239 100644
--- a/libstdc++-v3/include/pstl/execution_impl.h
+++ b/libstdc++-v3/include/pstl/execution_impl.h
@@ -66,7 +66,7 @@ struct __is_random_access_iterator<_IteratorType>
 };
 
 /* policy */
-template 
+template 
 struct __policy_traits
 {
 };
diff --git a/libstdc++-v3/testsuite/17_intro/names.cc 
b/libstdc++-v3/testsuite/17_intro/names.cc
index c3c753b35e5..20123a41287 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -19,7 +19,6 @@
 
 // Define macros for some common variables names that we must not use for
 // naming variables, parameters etc. in the library.
-#define tmp (
 #define A (
 #define B (
 #define C (
@@ -99,6 +98,78 @@
 #define y (
 #define z (
 
+#define tmp 

Re: [PATCH] Implement sane variant converting constructor (P0608R3)

[Jonathan Wakely]

On 17/05/19 15:55 +0200, Rainer Orth wrote:

Hi Jonathan,


* include/std/variant (__overload_set): Remove.
(_Arr): New helper.
(_Build_FUN): New class template to define a single FUN overload,
with specializations to prevent unwanted conversions, as per P0608R3.
(_Build_FUNs): New class template to build an overload set of FUN.
(_FUN_type): New alias template to perform overload resolution.
(__accepted_type): Use integer_constant base for failure case. Use
_FUN_type for successful case.
(variant::__accepted_index): Use _Tp instead of _Tp&&.
(variant::variant(_Tp&&)): Likewise.
(variant::operator=(_Tp&&)): Likewise.

Tested powerpc64le-linux, committed to trunk.

[...]

diff --git a/libstdc++-v3/testsuite/20_util/variant/compile.cc 
b/libstdc++-v3/testsuite/20_util/variant/compile.cc
index c6b18d08258..4560f774452 100644
--- a/libstdc++-v3/testsuite/20_util/variant/compile.cc
+++ b/libstdc++-v3/testsuite/20_util/variant/compile.cc
@@ -142,6 +142,11 @@ void arbitrary_ctor()
   static_assert(noexcept(variant(int{})));
   static_assert(!noexcept(variant(Empty{})));
   static_assert(noexcept(variant(DefaultNoexcept{})));
+
+  // P0608R3 disallow narrowing conversions and boolean conversions
+  static_assert(!is_constructible_v, long>);
+  static_assert(!is_constructible_v, int>);
+  static_assert(!is_constructible_v, void*>);


this test (which didn't make it into the ChangeLog, btw.) FAILs on


Drat, not sure how I missed the two test changes out, sorry.


32-bit targets (seen on i386-pc-solaris2.11, sparc-sun-solaris.11, and
x86_64-pc-linux-gnu -m32):

+FAIL: 20_util/variant/compile.cc (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/20_util/variant/compile.cc:147:
 error: static assertion failed


I keep forgetting 32-bit exists ;-)

Of course if sizeof(int) == sizeof(long) then it's not a lossy
conversion, and so is allowed.

This patch makes it always a narrowing conversion, irrespective of
target. I'll commit it shortly.


commit 2ae870b13cf1d493706188d2ec1f8c93a8b81bf5
Author: Jonathan Wakely 
Date:   Fri May 17 14:59:15 2019 +0100

Fix std::variant test for ILP32 targets

* testsuite/20_util/variant/compile.cc: Fix narrowing test for ILP32
targets. Add more cases from P0608R3.
* testsuite/20_util/variant/run.cc: Add more cases from P0608R3.

diff --git a/libstdc++-v3/testsuite/20_util/variant/compile.cc b/libstdc++-v3/testsuite/20_util/variant/compile.cc
index 4560f774452..dc3d4c2b3f1 100644
--- a/libstdc++-v3/testsuite/20_util/variant/compile.cc
+++ b/libstdc++-v3/testsuite/20_util/variant/compile.cc
@@ -144,7 +144,15 @@ void arbitrary_ctor()
   static_assert(noexcept(variant(DefaultNoexcept{})));
 
   // P0608R3 disallow narrowing conversions and boolean conversions
-  static_assert(!is_constructible_v, long>);
+  static_assert(!is_constructible_v, int>);
+  static_assert(!is_constructible_v>, int>);
+  static_assert(is_constructible_v, char>);
+  static_assert(!is_constructible_v, int>);
+  static_assert(is_constructible_v, int>);
+  struct big_int { big_int(int) { } };
+  static_assert(is_constructible_v, int>);
+
+  static_assert(!is_constructible_v, unsigned>);
   static_assert(!is_constructible_v, int>);
   static_assert(!is_constructible_v, void*>);
 }
diff --git a/libstdc++-v3/testsuite/20_util/variant/run.cc b/libstdc++-v3/testsuite/20_util/variant/run.cc
index ac60ccbc13e..045e1f23ada 100644
--- a/libstdc++-v3/testsuite/20_util/variant/run.cc
+++ b/libstdc++-v3/testsuite/20_util/variant/run.cc
@@ -128,6 +128,17 @@ void arbitrary_ctor()
 VERIFY(y.index() == 1);
 VERIFY(std::get<1>(y).d == d);
   }
+
+  {
+// P0608R3
+variant v1 = 'a';
+VERIFY(std::get<1>(v1) == int('a'));
+variant v2 = 0;
+VERIFY(std::get<1>(v2) == 0L);
+struct big_int { big_int(int) { } };
+variant v3 = 0;
+VERIFY(v3.index() == 1);
+  }
 }
 
 struct ThrowingMoveCtorThrowsCopyCtor

Re: Strenghten aliasing_component_refs_p

[Jan Hubicka]

> On Fri, 17 May 2019, Jan Hubicka wrote:
> 
> > Hi,
> > this patch cuts walks in aliasing_component_refs_p if the type we look for
> > can not fit into a given type by comparing their sizes. Similar logic
> > already exists in indirect_ref_may_alias_decl_p.
> > 
> > When we walk reference a.b.c.d.e looking for type x we only need to do
> > it if sizeof(a)>=sizeof(x) and continue woking from e until
> > sizeof(e)<=sizeof(x). We do not need to compare types where sizes are
> > known to be different.
> > 
> > This saves some work (by not walking refs and not comparing their types
> > if they can not match) but also increases number of disambiguations
> > quite noticably. This is because same_type_for_tbaa often returns -1 and
> > makes aliasing_compinent_refs_p to give up.  Using the simple size check
> > prevents hitting such problematic type pairs in many common cases.
> > 
> > Stats on tramp3d lto build change From:
> > 
> > Alias oracle query stats:
> >   refs_may_alias_p: 0 disambiguations, 0 queries
> >   ref_maybe_used_by_call_p: 6451 disambiguations, 25578 queries
> >   call_may_clobber_ref_p: 817 disambiguations, 817 queries
> >   aliasing_component_ref_p: 14 disambiguations, 12528 queries
> >   TBAA oracle: 1468347 disambiguations 3010562 queries
> >550690 are in alias set 0
> >614235 queries asked about the same object
> >0 queries asked about the same alias set
> >0 access volatile
> >260937 are dependent in the DAG
> >116353 are aritificially in conflict with void *
> > 
> > to:
> > 
> > Alias oracle query stats:
> >   refs_may_alias_p: 0 disambiguations, 0 queries
> >   ref_maybe_used_by_call_p: 6451 disambiguations, 25580 queries
> >   call_may_clobber_ref_p: 817 disambiguations, 817 queries
> >   aliasing_component_ref_p: 118 disambiguations, 12552 queries
> >   TBAA oracle: 1468413 disambiguations 3010714 queries
> >550719 are in alias set 0
> >614247 queries asked about the same object
> >0 queries asked about the same alias set
> >0 access volatile
> >260970 are dependent in the DAG
> >116365 are aritificially in conflict with void *
> > 
> > So disambiguations are up from 14 to 118 which is still quite low.
> > 
> > A followup patch making types_same_for_tbaa to not give up for
> > TYPE_STRUCTURAL_EQUALITY pointers and arrays improves hitrate to 2723.
> > 
> > Bootstrapped/regtested x86_64-linux, OK?
> > 
> > * tree-ssa-alias.c (type_big_enough_for_type_p): New function.
> > (aliasing_component_refs_p): Use it.
> > Index: tree-ssa-alias.c
> > ===
> > --- tree-ssa-alias.c(revision 271292)
> > +++ tree-ssa-alias.c(working copy)
> > @@ -735,6 +735,27 @@ ao_ref_init_from_ptr_and_size (ao_ref *r
> >ref->volatile_p = false;
> >  }
> >  
> > +/* Return true if TYPE1 may contain TYPE2 by its size.  */
> > +
> > +static bool
> > +type_big_enough_for_type_p (tree type1, tree type2)
> > +{
> > +  if (!TYPE_SIZE (type1) || !TYPE_SIZE (type2))
> > +return true;
> > +  /* Be conservative for arrays and vectors.  We want to support partial
> > + overlap on int[3] and int[3] as tested in gcc.dg/torture/alias-2.c.  
> > */
> > +  while (TREE_CODE (type2) == ARRAY_TYPE
> > +|| TREE_CODE (type2) == VECTOR_TYPE)
> > +type2 = TREE_TYPE (type2);
> 
> Eww ;)  I guess this means same-type can never return true for
> array or vectors?

It can still return 0. Current implementation is bit questionable:

static inline int
same_type_for_tbaa (tree type1, tree type2)
{
  type1 = TYPE_MAIN_VARIANT (type1);
  type2 = TYPE_MAIN_VARIANT (type2);

  /* If we would have to do structural comparison bail out.  */
  if (TYPE_STRUCTURAL_EQUALITY_P (type1)
  || TYPE_STRUCTURAL_EQUALITY_P (type2))
return -1;

  /* Compare the canonical types.  */
  if (TYPE_CANONICAL (type1) == TYPE_CANONICAL (type2))
return 1;

  /* ??? Array types are not properly unified in all cases as we have
 spurious changes in the index types for example.  Removing this
 causes all sorts of problems with the Fortran frontend.  */
  if (TREE_CODE (type1) == ARRAY_TYPE
  && TREE_CODE (type2) == ARRAY_TYPE)
return -1;

I plan to check what testcases breaks if that conditional goes away. The
aforementioned testcase dues :)
> 
> > +  if (!poly_int_tree_p (TYPE_SIZE (type1))
> > +  || !poly_int_tree_p (TYPE_SIZE (type2)))
> > +return true;
> 
> Use
> 
> poly_uint64 size1;
> if (!poly_int_tree_p (TYPE_SIZE (type1), )
>  ...
> 
> > +  if (known_lt (wi::to_poly_widest (TYPE_SIZE (type1)),
> > +   wi::to_poly_widest (TYPE_SIZE (type2
> 
> and
> 
>  if (known_lt (size1, size2))
> 
> I wonder if you can compute whether type1 fits in type2 and
> the other way around at the same time, saving seemingly
> redundant 

Re: [PATCH] Implement sane variant converting constructor (P0608R3)

[Rainer Orth]

Hi Jonathan,

>   * include/std/variant (__overload_set): Remove.
>   (_Arr): New helper.
>   (_Build_FUN): New class template to define a single FUN overload,
>   with specializations to prevent unwanted conversions, as per P0608R3.
>   (_Build_FUNs): New class template to build an overload set of FUN.
>   (_FUN_type): New alias template to perform overload resolution.
>   (__accepted_type): Use integer_constant base for failure case. Use
>   _FUN_type for successful case.
>   (variant::__accepted_index): Use _Tp instead of _Tp&&.
>   (variant::variant(_Tp&&)): Likewise.
>   (variant::operator=(_Tp&&)): Likewise.
>
> Tested powerpc64le-linux, committed to trunk.
[...]
> diff --git a/libstdc++-v3/testsuite/20_util/variant/compile.cc 
> b/libstdc++-v3/testsuite/20_util/variant/compile.cc
> index c6b18d08258..4560f774452 100644
> --- a/libstdc++-v3/testsuite/20_util/variant/compile.cc
> +++ b/libstdc++-v3/testsuite/20_util/variant/compile.cc
> @@ -142,6 +142,11 @@ void arbitrary_ctor()
>static_assert(noexcept(variant(int{})));
>static_assert(!noexcept(variant(Empty{})));
>static_assert(noexcept(variant(DefaultNoexcept{})));
> +
> +  // P0608R3 disallow narrowing conversions and boolean conversions
> +  static_assert(!is_constructible_v, long>);
> +  static_assert(!is_constructible_v, int>);
> +  static_assert(!is_constructible_v, void*>);

this test (which didn't make it into the ChangeLog, btw.) FAILs on
32-bit targets (seen on i386-pc-solaris2.11, sparc-sun-solaris.11, and
x86_64-pc-linux-gnu -m32):

+FAIL: 20_util/variant/compile.cc (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/20_util/variant/compile.cc:147:
 error: static assertion failed

Rainer

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

Re: [PATCH 5/12] fix diagnostic quoting/spelling in c-family

[David Malcolm]

On Thu, 2019-05-16 at 18:40 -0600, Martin Sebor wrote:
> On 5/16/19 5:22 PM, Joseph Myers wrote:
> > On Tue, 14 May 2019, Martin Sebor wrote:
> > 
> > > The attached patch fixes quoting, spelling, and other formatting
> > > issues in diagnostics issued from files in the c-family/
> > > directory
> > > and pointed out by the -Wformat-diag warning.
> > 
> > Some of the changes in this patch are questionable.  The
> > diagnostics for
> > attribute scalar_storage_order and visibility arguments use \"
> > because the
> > argument is a string constant not an identifier.  So making those
> > use %qs
> > makes the diagnostics misleading, by suggesting an attribute
> > argument is
> > used that is not in fact valid for that attribute.
> 
> Hmm, yes.  I introduced it elsewhere as well in some of my prior
> changes, and it existed even before then in
> handle_visibility_attribute:
> 
>  error ("%qD was declared %qs which implies default visibility",
> decl, "dllexport");
> 
> There is a way to highlight a string without enclosing it in both
> single and double quotes:
> 
>  error ("attribute %qE argument must be one of %r%s%R or %r%s%R",
> name, "locus", "\"big-endian\"",
> "locus", "\"little-endian\"");
> 
> It's not pretty but it does the job.

Interesting idea, but I'm not sure if it's the right way to go here.

Do we have other examples of highlighting strings within a diagnostic?

The colorization typically doesn't show up in compilation logs.  It's
also not easy to test for in DejaGnu (but I can think of some ways to
make that easier).

>  Unless you know of some other
> trick I'll go with it and fix up the existing mistakes the same way
> in a followup commit.

Please can we focus this discussion on what it ought to look like from
the end-user's point of view? (rather than on our implementation
details)

Can you give a concrete example of some source that triggers this
diagnostic, what the current output is, and what the output given the
current candidate patch is?

(i.e. what does it look like to the end-user? what are our ideas for
what should it look like?)

[this may be lack of coffee on my part, but I find it easier to think
and talk about actual input/output examples, rather than diagnostic API
calls and DejaGnu testcases, and let the former lead the latter]

Thanks
Dave

Go patch committed: Use SHA1 hash for long gcbits symbols

[Ian Lance Taylor]

This patch to the Go frontend by Than McIntosh uses a SHA1-hash for
the symbol name for long gcbits symbols.  The current scheme used by
the compiler for "gcbits" symbols involves generating a symbol name
based on a 32-char encoding of the bits data.  This scheme works well
in most cases but can generate very long symbol names in rare cases.
To help avoid such long symbol names, switch to a different encoding
scheme based on the SHA1 digest of the payload if the symbol size
would be too large.  This fixes https://golang.org/issue/32083.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 271310)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-b5ab7b419d6328f5126ba8d6795280129eaf6e79
+54aacecc8167bfba8420cb7b245787ff80bde61b
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 271310)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -12,6 +12,7 @@
 #include "gogo.h"
 #include "go-diagnostics.h"
 #include "go-encode-id.h"
+#include "go-sha1.h"
 #include "operator.h"
 #include "expressions.h"
 #include "statements.h"
@@ -2776,22 +2777,43 @@ Ptrmask::set_from(Gogo* gogo, Type* type
 }
 }
 
-// Return a symbol name for this ptrmask.  This is used to coalesce
-// identical ptrmasks, which are common.  The symbol name must use
-// only characters that are valid in symbols.  It's nice if it's
-// short.  We convert it to a string that uses only 32 characters,
-// avoiding digits and u and U.
-
+// Return a symbol name for this ptrmask. This is used to coalesce identical
+// ptrmasks, which are common. The symbol name must use only characters that 
are
+// valid in symbols. It's nice if it's short. For smaller ptrmasks, we convert
+// it to a string that uses only 32 characters, avoiding digits and u and U. 
For
+// longer pointer masks, apply the same process to the SHA1 digest of the bits,
+// so as to avoid pathologically long symbol names (see related Go issues 
#32083
+// and #11583 for more on this). To avoid collisions between the two encoding
+// schemes, use a prefix ("X") for the SHA form to disambiguate.
 std::string
 Ptrmask::symname() const
 {
+  const std::vector* bits(>bits_);
+  std::vector shabits;
+  std::string prefix;
+
+  if (this->bits_.size() > 128)
+{
+  // Produce a SHA1 digest of the data.
+  Go_sha1_helper* sha1_helper = go_create_sha1_helper();
+  sha1_helper->process_bytes(>bits_[0], this->bits_.size());
+  std::string digest = sha1_helper->finish();
+  delete sha1_helper;
+
+  // Redirect the bits vector to the digest, and update the prefix.
+  prefix = "X";
+  for (char c : digest)
+shabits.push_back((unsigned char) c);
+  bits = 
+}
+
   const char chars[33] = "abcdefghijklmnopqrstvwxyzABCDEFG";
   go_assert(chars[32] == '\0');
-  std::string ret;
+  std::string ret(prefix);
   unsigned int b = 0;
   int remaining = 0;
-  for (std::vector::const_iterator p = this->bits_.begin();
-   p != this->bits_.end();
+  for (std::vector::const_iterator p = bits->begin();
+   p != bits->end();
++p)
 {
   b |= *p << remaining;

Re: [PATCH] debug: make -feliminate-unused-debug-symbols the default [PR debug/86964]

[Richard Biener]

On Fri, May 17, 2019 at 12:07 PM Thomas De Schampheleire
 wrote:
>
>
>
> On Fri, May 17, 2019, 11:57 Richard Biener  wrote:
>>
>> On Fri, May 17, 2019 at 9:42 AM Thomas De Schampheleire
>>  wrote:
>> >
>> > Hi Richard,
>> >
>> > El jue., 16 may. 2019 a las 14:41, Richard Biener
>> > () escribió:
>> > >
>> > > On Thu, May 16, 2019 at 11:20 AM Thomas De Schampheleire
>> > >  wrote:
>> > > >
>> > > > From: Thomas De Schampheleire 
>> > > >
>> > > > In addition to making -feliminate-unused-debug-symbols work for the 
>> > > > DWARF
>> > > > format (see [1]), make this option the default. This behavior was the 
>> > > > case
>> > > > before, e.g. under gcc 4.9.x.
>> > > > [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=269925
>> > >
>> > > I have tested this patch and it causes a few FAILs, eventually hinting
>> > > at implementation issues:
>> > >
>> > > === g++ tests ===
>> > >
>> > >
>> > > Running target unix
>> > > FAIL: g++.dg/debug/enum-2.C -gstabs -O2  scan-assembler JTI_MAX
>> > > FAIL: g++.dg/debug/enum-2.C -gstabs -O3  scan-assembler JTI_MAX
>> > > FAIL: g++.dg/debug/enum-2.C -gstabs+ -O2  scan-assembler JTI_MAX
>> > > FAIL: g++.dg/debug/enum-2.C -gstabs+ -O3  scan-assembler JTI_MAX
>> > > FAIL: g++.dg/debug/enum-2.C -gstabs+3 -O2  scan-assembler JTI_MAX
>> > > FAIL: g++.dg/debug/enum-2.C -gstabs+3 -O3  scan-assembler JTI_MAX
>> > > FAIL: g++.dg/debug/enum-2.C -gstabs3 -O2  scan-assembler JTI_MAX
>> > > FAIL: g++.dg/debug/enum-2.C -gstabs3 -O3  scan-assembler JTI_MAX
>> > >
>> > > maybe expected (stabs)
>> > >
>> > > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
>> > > field_head_or
>> > > dy_defn_fld_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
>> > > field_head_or
>> > > dy_defn_ptr_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
>> > > field_head_or
>> > > dy_defn_ref_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
>> > > field_head_or
>> > > dy_defn_var_head_fld.*DW_AT_name
>> > > ... more ...
>> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++14  scan-assembler 
>> > > gstruct_
>> > > head_ordy_defn_var_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++14  scan-assembler 
>> > > gstruct_
>> > > head_tmpl_defn_var_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++17  scan-assembler 
>> > > gstruct_
>> > > head_ordy_defn_var_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++17  scan-assembler 
>> > > gstruct_
>> > > head_tmpl_defn_var_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++98  scan-assembler 
>> > > gstruct_
>> > > head_ordy_defn_var_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++98
>> > > scan-assembler gstruct_head_tmpl_defn_var_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-none.C  -std=gnu++14  scan-assembler
>> > > gstruct_head_ordy_defn_var_head.*DW_AT_name
>> > > FAIL: g++.dg/debug/dwarf2/fesd-none.C  -std=gnu++14  scan-assembler
>> > > gstruct_head_tmpl_defn_var_head.*DW_AT_name
>> > > ... more fesd-* testcases FAIL ...
>> > > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
>> > > scan-assembler-times  DW_AT_[^\\n\\r]*linkage_name 7
>> > > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
>> > > scan-assembler-times  DW_AT_specification 6
>> > > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
>> > > scan-assembler-times 0x3[^\\n\\r]* DW_AT_inline 6
>> > >
>> > > C variants of the fesd-* testcases also FAIL.  Those testcases are
>> > > huge, a quick look didn't
>> > > reveal whether those are expected FAILs or not.
>> >
>> >
>> > I tried reproducing these failures, using 'make bootstrap && make
>> > check', but I see many many test failures:
>> >
>> > === gcc Summary ===
>> >
>> > # of expected passes144268
>> > # of unexpected failures113
>> > # of unexpected successes28
>> > # of expected failures593
>> > # of unresolved testcases2
>> > # of unsupported tests2279
>> >
>> > === g++ Summary ===
>> >
>> > # of expected passes134673
>> > # of unexpected failures137
>> > # of expected failures527
>> > # of unsupported tests5944
>> >
>> > /home/tdescham/repo/contrib/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc
>> > version 10.0.0 20190516 (experimental) (GCC)
>> >
>> >
>> > Is it expected that 'master' (gcc 10) has such failures? Should I test
>> > on another branch, if so which?
>>
>> The guality ones are probably the most "disturbing", but yes, there
>> are quite a number of FAILs, my last result shows
>>
>> === gcc Summary ===
>>
>> # of expected passes144773
>> # of unexpected failures102
>> # of unexpected successes   28
>> # of expected failures  602
>> # of unresolved testcases   2
>> # of unsupported tests 

[PATCH] Move VEC_PERM_EXPR folding to match.pd

[Richard Biener]

This moves things from fold-const.c to match.pd.

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2019-05-17  Richard Biener  

* gimple-match-head.c: Include vec-perm-indices.h.
* generic-match-head.c: Likewise.
* fold-const.h (fold_vec_perm): Declare when vec-perm-indices.h
is included.
* fold-const.c (fold_vec_perm): Export.
(fold_ternary_loc): Move non-constant folding of VEC_PERM_EXPR...
(match.pd): ...here.

Index: gcc/gimple-match-head.c
===
--- gcc/gimple-match-head.c (revision 271320)
+++ gcc/gimple-match-head.c (working copy)
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.
 #include "gimple.h"
 #include "ssa.h"
 #include "cgraph.h"
+#include "vec-perm-indices.h"
 #include "fold-const.h"
 #include "fold-const-call.h"
 #include "stor-layout.h"
Index: gcc/generic-match-head.c
===
--- gcc/generic-match-head.c(revision 271320)
+++ gcc/generic-match-head.c(working copy)
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.
 #include "gimple.h"
 #include "ssa.h"
 #include "cgraph.h"
+#include "vec-perm-indices.h"
 #include "fold-const.h"
 #include "stor-layout.h"
 #include "tree-dfa.h"
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 271320)
+++ gcc/fold-const.c(working copy)
@@ -9015,7 +9015,7 @@ vec_cst_ctor_to_array (tree arg, unsigne
selector.  Return the folded VECTOR_CST or CONSTRUCTOR if successful,
NULL_TREE otherwise.  */
 
-static tree
+tree
 fold_vec_perm (tree type, tree arg0, tree arg1, const vec_perm_indices )
 {
   unsigned int i;
@@ -11763,7 +11763,10 @@ fold_ternary_loc (location_t loc, enum t
   return NULL_TREE;
 
 case VEC_PERM_EXPR:
-  if (TREE_CODE (arg2) == VECTOR_CST)
+  /* Perform constant folding of BIT_INSERT_EXPR.  */
+  if (TREE_CODE (arg2) == VECTOR_CST
+ && TREE_CODE (op0) == VECTOR_CST
+ && TREE_CODE (op1) == VECTOR_CST)
{
  /* Build a vector of integers from the tree mask.  */
  vec_perm_builder builder;
@@ -11774,61 +11777,7 @@ fold_ternary_loc (location_t loc, enum t
  poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (type);
  bool single_arg = (op0 == op1);
  vec_perm_indices sel (builder, single_arg ? 1 : 2, nelts);
-
- /* Check for cases that fold to OP0 or OP1 in their original
-element order.  */
- if (sel.series_p (0, 1, 0, 1))
-   return op0;
- if (sel.series_p (0, 1, nelts, 1))
-   return op1;
-
- if (!single_arg)
-   {
- if (sel.all_from_input_p (0))
-   op1 = op0;
- else if (sel.all_from_input_p (1))
-   {
- op0 = op1;
- sel.rotate_inputs (1);
-   }
-   }
-
- if ((TREE_CODE (op0) == VECTOR_CST
-  || TREE_CODE (op0) == CONSTRUCTOR)
- && (TREE_CODE (op1) == VECTOR_CST
- || TREE_CODE (op1) == CONSTRUCTOR))
-   {
- tree t = fold_vec_perm (type, op0, op1, sel);
- if (t != NULL_TREE)
-   return t;
-   }
-
- bool changed = (op0 == op1 && !single_arg);
-
- /* Generate a canonical form of the selector.  */
- if (arg2 == op2 && sel.encoding () != builder)
-   {
- /* Some targets are deficient and fail to expand a single
-argument permutation while still allowing an equivalent
-2-argument version.  */
- if (sel.ninputs () == 2
- || can_vec_perm_const_p (TYPE_MODE (type), sel, false))
-   op2 = vec_perm_indices_to_tree (TREE_TYPE (arg2), sel);
- else
-   {
- vec_perm_indices sel2 (builder, 2, nelts);
- if (can_vec_perm_const_p (TYPE_MODE (type), sel2, false))
-   op2 = vec_perm_indices_to_tree (TREE_TYPE (arg2), sel2);
- else
-   /* Not directly supported with either encoding,
-  so use the preferred form.  */
-   op2 = vec_perm_indices_to_tree (TREE_TYPE (arg2), sel);
-   }
- changed = true;
-   }
-
- if (changed)
-   return build3_loc (loc, VEC_PERM_EXPR, type, op0, op1, op2);
+ return fold_vec_perm (type, op0, op1, sel);
}
   return NULL_TREE;
 
Index: gcc/fold-const.h
===
--- gcc/fold-const.h(revision 271320)
+++ gcc/fold-const.h(working copy)
@@ -100,6 +100,9 @@ extern tree fold_bit_and_mask (tree, tre
   tree, enum tree_code, tree, tree,
   tree, enum tree_code, 

[PATCH][RFC] Fix PR90510, VEC_PERM -> BIT_INSERT folding

[Richard Biener]

This adds, incrementally ontop of moving VEC_PERM_EXPR folding
to match.pd (but not incremental patch - sorry...), folding
of single-element insert permutations to BIT_INSERT_EXPR.

Things are quite awkward with the new poly-int vec-perm stuff
so effectively this doesn't work for SVE and is still very
ugly.  I wonder how to make it generic enough so SVE would
be happy and / or how to make the code prettier.

I also can't find a helper to read a specific vector element
from a VECTOR_CST/CONSTRUCTOR (can I even do that "generally"
with a poly-int index?!), but there surely must be one.

Richard - any comments / hints?  Look at the match.pd
change next to /* See if the permutation is performing a single elem

Thanks,
Richard.

Index: gcc/gimple-match-head.c
===
--- gcc/gimple-match-head.c (revision 271321)
+++ gcc/gimple-match-head.c (working copy)
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.
 #include "gimple.h"
 #include "ssa.h"
 #include "cgraph.h"
+#include "vec-perm-indices.h"
 #include "fold-const.h"
 #include "fold-const-call.h"
 #include "stor-layout.h"
Index: gcc/generic-match-head.c
===
--- gcc/generic-match-head.c(revision 271321)
+++ gcc/generic-match-head.c(working copy)
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.
 #include "gimple.h"
 #include "ssa.h"
 #include "cgraph.h"
+#include "vec-perm-indices.h"
 #include "fold-const.h"
 #include "stor-layout.h"
 #include "tree-dfa.h"
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 271321)
+++ gcc/fold-const.c(working copy)
@@ -9015,7 +9015,7 @@ vec_cst_ctor_to_array (tree arg, unsigne
selector.  Return the folded VECTOR_CST or CONSTRUCTOR if successful,
NULL_TREE otherwise.  */
 
-static tree
+tree
 fold_vec_perm (tree type, tree arg0, tree arg1, const vec_perm_indices )
 {
   unsigned int i;
@@ -11763,7 +11763,10 @@ fold_ternary_loc (location_t loc, enum t
   return NULL_TREE;
 
 case VEC_PERM_EXPR:
-  if (TREE_CODE (arg2) == VECTOR_CST)
+  /* Perform constant folding of BIT_INSERT_EXPR.  */
+  if (TREE_CODE (arg2) == VECTOR_CST
+ && TREE_CODE (op0) == VECTOR_CST
+ && TREE_CODE (op1) == VECTOR_CST)
{
  /* Build a vector of integers from the tree mask.  */
  vec_perm_builder builder;
@@ -11774,61 +11777,7 @@ fold_ternary_loc (location_t loc, enum t
  poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (type);
  bool single_arg = (op0 == op1);
  vec_perm_indices sel (builder, single_arg ? 1 : 2, nelts);
-
- /* Check for cases that fold to OP0 or OP1 in their original
-element order.  */
- if (sel.series_p (0, 1, 0, 1))
-   return op0;
- if (sel.series_p (0, 1, nelts, 1))
-   return op1;
-
- if (!single_arg)
-   {
- if (sel.all_from_input_p (0))
-   op1 = op0;
- else if (sel.all_from_input_p (1))
-   {
- op0 = op1;
- sel.rotate_inputs (1);
-   }
-   }
-
- if ((TREE_CODE (op0) == VECTOR_CST
-  || TREE_CODE (op0) == CONSTRUCTOR)
- && (TREE_CODE (op1) == VECTOR_CST
- || TREE_CODE (op1) == CONSTRUCTOR))
-   {
- tree t = fold_vec_perm (type, op0, op1, sel);
- if (t != NULL_TREE)
-   return t;
-   }
-
- bool changed = (op0 == op1 && !single_arg);
-
- /* Generate a canonical form of the selector.  */
- if (arg2 == op2 && sel.encoding () != builder)
-   {
- /* Some targets are deficient and fail to expand a single
-argument permutation while still allowing an equivalent
-2-argument version.  */
- if (sel.ninputs () == 2
- || can_vec_perm_const_p (TYPE_MODE (type), sel, false))
-   op2 = vec_perm_indices_to_tree (TREE_TYPE (arg2), sel);
- else
-   {
- vec_perm_indices sel2 (builder, 2, nelts);
- if (can_vec_perm_const_p (TYPE_MODE (type), sel2, false))
-   op2 = vec_perm_indices_to_tree (TREE_TYPE (arg2), sel2);
- else
-   /* Not directly supported with either encoding,
-  so use the preferred form.  */
-   op2 = vec_perm_indices_to_tree (TREE_TYPE (arg2), sel);
-   }
- changed = true;
-   }
-
- if (changed)
-   return build3_loc (loc, VEC_PERM_EXPR, type, op0, op1, op2);
+ return fold_vec_perm (type, op0, op1, sel);
}
   return NULL_TREE;
 
Index: gcc/fold-const.h
===
--- gcc/fold-const.h

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jason Merrill]

On Tue, May 14, 2019 at 12:11 PM Maxim Kuvyrkov
 wrote:
>
> This patch adds scripts to contrib/ to migrate full history of GCC's 
> subversion repository to git.  My hope is that these scripts will finally 
> allow GCC project to migrate to Git.

Thanks for looking into this.  My feeling has been that, if we give up
on reposurgeon, there's no need to start a new conversion at all: we
can just switch the current mirror over to being the primary
repository with some minor surgery (e.g. using git filter-branch to
fix subdirectory branches).  That approach will produce the least
disruption in the workflows of people already using it.  Do you see a
problem with this?

Jason

Re: Deque code cleanup and optimizations

[Jonathan Wakely]

On 17/05/19 07:06 +0200, François Dumont wrote:
Here is the simplified patch. I put back the _M_map checks, we'll see 
later if those can be removed.


    * include/bits/stl_deque.h
    (_Deque_iterator<>::__ptr_to): Remove, use std::__ptr_rebind.
    (_Deque_base(_Deque_base&&, const allocator_type&)): New.
    (_Deque_base::_Deque_impl_data): New.
    (_Deque_base::_Deque_impl): Inherit latter.
    (_Deque_base::_Deque_impl::_M_swap_data): Move...
    (_Deque_base::_Deque_impl_data::_M_swap_data): ... here.
    (_Deque_base::_Deque_impl()): Add noexcept qualification.
    (_Deque_base::_Deque_impl(_Deque_impl&&, _Tp_alloc_type&&)): New.
    (_Deque_base::_Deque_impl::_M_get_Tp_allocator()): Remove static_cast.
    (deque<>::deque()): Default.
    (deque<>::deque(deque&&)): Default.
    (deque<>::deque(deque&&, const allocator_type&, false_type)): New.
    (deque<>::deque(deque&&, const allocator_type&, true_type)): New.
    (deque<>::deque(deque&&, const allocator_type&)): Delegate to latters.
    (deque<>::deque<_It>(_It, _It, const allocator_type&)): Use
    _M_range_initialize.
    (deque<>::assign<_It>(_It, _It)): Use _M_assign_aux.
    (deque<>::resize(size_type, const value_type&)): Share a single
    implementation.
    (deque<>::insert<_It>(const_iterator, _It, _It)): Use
    _M_range_insert_aux.
    [__cplusplus >= 201103L](_M_initialize_dispatch): Remove.
    [__cplusplus >= 201103L](_M_assign_dispatch): Remove.
    [__cplusplus >= 201103L](_M_insert_dispatch): Remove.
    * testsuite/23_containers/deque/allocator/default_init.cc: New.

Tested under Linux x86_64.

Ok to commit ?


OK for trunk, thanks.

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jakub Jelinek]

On Fri, May 17, 2019 at 02:22:47PM +0200, Martin Liška wrote:
> On 5/17/19 1:06 AM, Joseph Myers wrote:
> > That repository 
> > represents what I consider the collaboratively built consensus on such 
> > things as the desired author map (including handling of the ambiguous 
> > author name), which directories represent branches and tags, and what tags 
> > should be kept or removed - but building up such a consensus and keeping 
> 
> About the map. I agree with Richard that we should do best approach and not
> to fully reconstruct history of people who has switched email address multi
> times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
> a clean up:
> 
> - for logins with duplicite emails I chose the latest one used on gcc-patches 
> mailing list
> - comments were removed
> - a few entries contained timezone and I stripped that
> 
> Final version of the map can be seen here:
> https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map
> 
> @Maxim: would it be possible to update your script so that it will use:
> --authors-file=gcc.map ?
> 
> Is it desired for the transition to use the author map? Do we want it?

Can people proposing the conversion also come up with the precommit hooks
etc. scripts we'll need?
I'd think we want to enforce linear history (and stress that every commit
should be bootstrappable, with git it is much easier to screw that up by
pushing many git commits at once, even with rebase actually not testing each
of them).
And something to keep the numeric commit numbers working for
http://gcc.gnu.org/rNN (I believe a roughly working scheme has been
identified, but not implemented).

Jakub

Re: [PATCH] tbb-backend effective target should check ability to link TBB

[Jonathan Wakely]

On 25/04/19 15:58 -0700, Thomas Rodgers wrote:


PR libstdc++/90252
* testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
Changed v3_target_compile check from preprocess to executable.
---
libstdc++-v3/testsuite/lib/libstdc++.exp | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)


This patch is still pending, but I think it's missing -ltbb that would
actually make the link succeed, isn't it?


diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index c48b4d78bbb..fa61bccc9f6 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1612,15 +1612,20 @@ proc check_effective_target_tbb-backend { } {
# Set up and preprocess a C++ test program that depends
# on tbb
set src tbb_backend[pid].cc
-
+set exe tbb_backend[pid].x
+
set f [open $src "w"]
puts $f "#include "
puts $f "#if TBB_INTERFACE_VERSION < 1"
puts $f "#  error Intel(R) Threading Building Blocks 2018 is required; older 
versions are not supported."
puts $f "#endif"
+puts $f "int main ()"
+puts $f "{"
+puts $f "  return 0;"
+puts $f "}"
close $f

-set lines [v3_target_compile $src /dev/null preprocess ""]
+set lines [v3_target_compile $src $exe executable ""]
file delete $src

if [string match "" $lines] {
--
2.20.1

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/17/19 1:06 AM, Joseph Myers wrote:
> That repository 
> represents what I consider the collaboratively built consensus on such 
> things as the desired author map (including handling of the ambiguous 
> author name), which directories represent branches and tags, and what tags 
> should be kept or removed - but building up such a consensus and keeping 

About the map. I agree with Richard that we should do best approach and not
to fully reconstruct history of people who has switched email address multi
times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
a clean up:

- for logins with duplicite emails I chose the latest one used on gcc-patches 
mailing list
- comments were removed
- a few entries contained timezone and I stripped that

Final version of the map can be seen here:
https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map

@Maxim: would it be possible to update your script so that it will use:
--authors-file=gcc.map ?

Is it desired for the transition to use the author map? Do we want it?

Martin

[PATCH] Export forgotten _gfortran_{,m,s}findloc{0,1}_r10 (PR fortran/54613)

[Jakub Jelinek]

On Fri, May 17, 2019 at 01:45:25PM +0200, Jakub Jelinek wrote:
> Another thing is, but that one isn't just about exported symbols, but also
> about not even generating such files and listing them in Makefile.am,
> there are no findloc r10 entrypoints.  Is that intentional?

As the attached testcase shows, that can't be intentional, as that
testcase fails to link.

So, here is an incremental patch to also export those, tested on
x86_64-linux.  Verified that sed 's/10/16/g' on the new generated files
results in identical files to the corresponding *_r16.c ones.
Ok for trunk/9.2?

2019-05-17  Jakub Jelinek  

PR fortran/54613
* gfortran.map (GFORTRAN_9.2): Export _gfortran_{,m,s}findloc{0,1}_r10.
* Makefile.am (i_findloc0_c): Add $(srcdir)/generated/findloc0_r10.c.
(i_findloc1_c): Add $(srcdir)/generated/findloc1_r10.c.
* Makefile.in: Regenerated.
* generated/findloc0_r10.c: Generated.
* generated/findloc1_r10.c: Generated.

--- libgfortran/gfortran.map.jj 2019-05-17 12:53:34.614042579 +0200
+++ libgfortran/gfortran.map2019-05-17 14:04:37.705814046 +0200
@@ -1593,6 +1593,12 @@ GFORTRAN_9 {
 
 GFORTRAN_9.2 {
   _gfortran_findloc0_i2;
+  _gfortran_findloc0_r10;
   _gfortran_mfindloc0_i2;
+  _gfortran_mfindloc0_r10;
   _gfortran_sfindloc0_i2;
+  _gfortran_sfindloc0_r10;
+  _gfortran_findloc1_r10;
+  _gfortran_mfindloc1_r10;
+  _gfortran_sfindloc1_r10;
 } GFORTRAN_9;
--- libgfortran/Makefile.am.jj  2019-05-02 22:22:24.329149579 +0200
+++ libgfortran/Makefile.am 2019-05-17 13:48:33.945668458 +0200
@@ -278,6 +278,7 @@ $(srcdir)/generated/findloc0_i8.c \
 $(srcdir)/generated/findloc0_i16.c \
 $(srcdir)/generated/findloc0_r4.c \
 $(srcdir)/generated/findloc0_r8.c \
+$(srcdir)/generated/findloc0_r10.c \
 $(srcdir)/generated/findloc0_r16.c \
 $(srcdir)/generated/findloc0_c4.c \
 $(srcdir)/generated/findloc0_c8.c \
@@ -295,6 +296,7 @@ $(srcdir)/generated/findloc1_i8.c \
 $(srcdir)/generated/findloc1_i16.c \
 $(srcdir)/generated/findloc1_r4.c \
 $(srcdir)/generated/findloc1_r8.c \
+$(srcdir)/generated/findloc1_r10.c \
 $(srcdir)/generated/findloc1_r16.c \
 $(srcdir)/generated/findloc1_c4.c \
 $(srcdir)/generated/findloc1_c8.c \
--- libgfortran/Makefile.in.jj  2019-05-02 22:22:24.326149627 +0200
+++ libgfortran/Makefile.in 2019-05-17 13:53:09.651132685 +0200
@@ -371,11 +371,13 @@ am__objects_45 = maxval1_s1.lo maxval1_s
 am__objects_46 = minval1_s1.lo minval1_s4.lo
 am__objects_47 = findloc0_i1.lo findloc0_i2.lo findloc0_i4.lo \
findloc0_i8.lo findloc0_i16.lo findloc0_r4.lo findloc0_r8.lo \
-   findloc0_r16.lo findloc0_c4.lo findloc0_c8.lo findloc0_c16.lo
+   findloc0_r10.lo findloc0_r16.lo findloc0_c4.lo findloc0_c8.lo \
+   findloc0_c16.lo
 am__objects_48 = findloc0_s1.lo findloc0_s4.lo
 am__objects_49 = findloc1_i1.lo findloc1_i2.lo findloc1_i4.lo \
findloc1_i8.lo findloc1_i16.lo findloc1_r4.lo findloc1_r8.lo \
-   findloc1_r16.lo findloc1_c4.lo findloc1_c8.lo findloc1_c16.lo
+   findloc1_r10.lo findloc1_r16.lo findloc1_c4.lo findloc1_c8.lo \
+   findloc1_c16.lo
 am__objects_50 = findloc1_s1.lo findloc1_s4.lo
 am__objects_51 = findloc2_s1.lo findloc2_s4.lo
 am__objects_52 = ISO_Fortran_binding.lo
@@ -836,6 +838,7 @@ $(srcdir)/generated/findloc0_i8.c \
 $(srcdir)/generated/findloc0_i16.c \
 $(srcdir)/generated/findloc0_r4.c \
 $(srcdir)/generated/findloc0_r8.c \
+$(srcdir)/generated/findloc0_r10.c \
 $(srcdir)/generated/findloc0_r16.c \
 $(srcdir)/generated/findloc0_c4.c \
 $(srcdir)/generated/findloc0_c8.c \
@@ -853,6 +856,7 @@ $(srcdir)/generated/findloc1_i8.c \
 $(srcdir)/generated/findloc1_i16.c \
 $(srcdir)/generated/findloc1_r4.c \
 $(srcdir)/generated/findloc1_r8.c \
+$(srcdir)/generated/findloc1_r10.c \
 $(srcdir)/generated/findloc1_r16.c \
 $(srcdir)/generated/findloc1_c4.c \
 $(srcdir)/generated/findloc1_c8.c \
@@ -1824,6 +1828,7 @@ distclean-compile:
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc0_i2.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc0_i4.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc0_i8.Plo@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc0_r10.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc0_r16.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc0_r4.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc0_r8.Plo@am__quote@
@@ -1837,6 +1842,7 @@ distclean-compile:
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc1_i2.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc1_i4.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc1_i8.Plo@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc1_r10.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc1_r16.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/findloc1_r4.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ 

[PATCH] Export forgotten _gfortran_{,m,s}findloc0_i2 (PR fortran/54613)

[Jakub Jelinek]

Hi!

I've found that gfortran.map doesn't export these 3 symbols (while it does
export other variants, with i1, i4, i8, i16, etc.).
Do we want to export them from both GCC 9.2 and 10 the following way, or
just on the trunk using GFORTRAN_10?

Tested on x86_64-linux.

Another thing is, but that one isn't just about exported symbols, but also
about not even generating such files and listing them in Makefile.am,
there are no findloc r10 entrypoints.  Is that intentional?

BTW, this shows that there is no testsuite coverage for findloc (but
apparently not for minloc, maxloc etc.) that would actually try all the
supported kinds and have at least one test for each supported kind, that
is something that would have caught this.

2019-05-17  Jakub Jelinek  

PR fortran/54613
* gfortran.map (GFORTRAN_9.2): New symbol version, export
_gfortran_{,m,s}findloc0_i2 in it.

--- libgfortran/gfortran.map.jj 2019-01-14 22:13:47.503717103 +0100
+++ libgfortran/gfortran.map2019-05-17 12:53:34.614042579 +0200
@@ -1590,3 +1590,9 @@ GFORTRAN_9 {
   __ieee_arithmetic_MOD_ieee_support_subnormal_8;
   __ieee_arithmetic_MOD_ieee_support_subnormal_noarg;
 } GFORTRAN_8;
+
+GFORTRAN_9.2 {
+  _gfortran_findloc0_i2;
+  _gfortran_mfindloc0_i2;
+  _gfortran_sfindloc0_i2;
+} GFORTRAN_9;

Jakub

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/17/19 12:04 AM, Jonathan Wakely wrote:
> On 16/05/19 13:07 -0600, Jeff Law wrote:
>> On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
>>> On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
>>>  wrote:

> On May 16, 2019, at 7:22 PM, Jeff Law  wrote:
>
> On 5/15/19 5:19 AM, Richard Biener wrote:
>>
>> For the official converted repo do we really want all (old)
>> development branches to be in the
>> main git repo?  I suppose we could create a readonly git from the
>> state of the whole repository
>> at the point of conversion (and also keep the SVN in readonly mode),
>> just to make migration
>> of content we want easy in the future?
> I've always assumed we'd keep the old SVN tree read-only for historical
> purposes.  I strongly suspect that, ignoring release branches, that
> non-active branches just aren't terribly interesting.

 Let's avoid mixing the two discussions: (1) converting svn repo to git 
 (and getting community consensus to switch to git) and (2) deciding on 
 which branches to keep in the new repo.

>>>
>>> I'm hoping that there is still community consensus to switch to git.
>>>
>>> Personally speaking, a +1 to switch to git.
>> Absolutely +1 for converting as well.
> 
> Yes please!
> 
> Thanks for working on this, Maxim.
> 
> 

I fully support that and thank you Maxim for working on that!

Martin

[Committed] S/390: Fix vec_sldw builtin

[Andreas Krebbel]

The builtin was wired up to the wrong pattern.  Fixed with this patch.

gcc/ChangeLog:

2019-05-17  Andreas Krebbel  

* config/s390/s390-builtins.def (s390_vec_sldw_*): Use the
vec_sldw insn pattern.

gcc/testsuite/ChangeLog:

2019-05-17  Andreas Krebbel  

* gcc.target/s390/zvector/vec-sldw.c: New test.
---
 gcc/config/s390/s390-builtins.def | 20 ---
 .../gcc.target/s390/zvector/vec-sldw.c| 55 +++
 2 files changed, 66 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/zvector/vec-sldw.c

diff --git a/gcc/config/s390/s390-builtins.def 
b/gcc/config/s390/s390-builtins.def
index fbf7d9f50e8..cfc69651b0d 100644
--- a/gcc/config/s390/s390-builtins.def
+++ b/gcc/config/s390/s390-builtins.def
@@ -2079,15 +2079,17 @@ OB_DEF_VAR (s390_vec_sld_dbl,   s390_vsldb, 
0,
 B_DEF  (s390_vsldb, vec_sldv16qi,   0, 
 B_VX,   O3_U4,  BT_FN_UV16QI_UV16QI_UV16QI_INT)
 
 OB_DEF (s390_vec_sldw,  s390_vec_sldw_s8,   s390_vec_sldw_dbl, 
 B_VX,   BT_FN_OV4SI_OV4SI_OV4SI_INT)
-OB_DEF_VAR (s390_vec_sldw_s8,   s390_vsldb, 0, 
 O3_U4,  BT_OV_V16QI_V16QI_V16QI_INT)
-OB_DEF_VAR (s390_vec_sldw_u8,   s390_vsldb, 0, 
 O3_U4,  BT_OV_UV16QI_UV16QI_UV16QI_INT)
-OB_DEF_VAR (s390_vec_sldw_s16,  s390_vsldb, 0, 
 O3_U4,  BT_OV_V8HI_V8HI_V8HI_INT)
-OB_DEF_VAR (s390_vec_sldw_u16,  s390_vsldb, 0, 
 O3_U4,  BT_OV_UV8HI_UV8HI_UV8HI_INT)
-OB_DEF_VAR (s390_vec_sldw_s32,  s390_vsldb, 0, 
 O3_U4,  BT_OV_V4SI_V4SI_V4SI_INT)
-OB_DEF_VAR (s390_vec_sldw_u32,  s390_vsldb, 0, 
 O3_U4,  BT_OV_UV4SI_UV4SI_UV4SI_INT)
-OB_DEF_VAR (s390_vec_sldw_s64,  s390_vsldb, 0, 
 O3_U4,  BT_OV_V2DI_V2DI_V2DI_INT)
-OB_DEF_VAR (s390_vec_sldw_u64,  s390_vsldb, 0, 
 O3_U4,  BT_OV_UV2DI_UV2DI_UV2DI_INT)
-OB_DEF_VAR (s390_vec_sldw_dbl,  s390_vsldb, B_DEP, 
 O3_U4,  BT_OV_V2DF_V2DF_V2DF_INT)
+OB_DEF_VAR (s390_vec_sldw_s8,   s390_vsldw, 0, 
 O3_U4,  BT_OV_V16QI_V16QI_V16QI_INT)
+OB_DEF_VAR (s390_vec_sldw_u8,   s390_vsldw, 0, 
 O3_U4,  BT_OV_UV16QI_UV16QI_UV16QI_INT)
+OB_DEF_VAR (s390_vec_sldw_s16,  s390_vsldw, 0, 
 O3_U4,  BT_OV_V8HI_V8HI_V8HI_INT)
+OB_DEF_VAR (s390_vec_sldw_u16,  s390_vsldw, 0, 
 O3_U4,  BT_OV_UV8HI_UV8HI_UV8HI_INT)
+OB_DEF_VAR (s390_vec_sldw_s32,  s390_vsldw, 0, 
 O3_U4,  BT_OV_V4SI_V4SI_V4SI_INT)
+OB_DEF_VAR (s390_vec_sldw_u32,  s390_vsldw, 0, 
 O3_U4,  BT_OV_UV4SI_UV4SI_UV4SI_INT)
+OB_DEF_VAR (s390_vec_sldw_s64,  s390_vsldw, 0, 
 O3_U4,  BT_OV_V2DI_V2DI_V2DI_INT)
+OB_DEF_VAR (s390_vec_sldw_u64,  s390_vsldw, 0, 
 O3_U4,  BT_OV_UV2DI_UV2DI_UV2DI_INT)
+OB_DEF_VAR (s390_vec_sldw_dbl,  s390_vsldw, B_DEP, 
 O3_U4,  BT_OV_V2DF_V2DF_V2DF_INT)
+
+B_DEF  (s390_vsldw, vec_sldwv16qi,  0, 
 B_VX,   O3_U4,  BT_FN_UV16QI_UV16QI_UV16QI_INT)
 
 OB_DEF (s390_vec_sral,  s390_vec_sral_u8q,  
s390_vec_sral_b64s, B_VX,   BT_FN_OV4SI_OV4SI_OV4SI)
 OB_DEF_VAR (s390_vec_sral_u8q,  s390_vsra,  0, 
 0,  BT_OV_UV16QI_UV16QI_UV16QI)
diff --git a/gcc/testsuite/gcc.target/s390/zvector/vec-sldw.c 
b/gcc/testsuite/gcc.target/s390/zvector/vec-sldw.c
new file mode 100644
index 000..2d4b30f47ec
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/zvector/vec-sldw.c
@@ -0,0 +1,55 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -mzarch -march=z13 -mzvector --save-temps" } */
+
+#include 
+
+vector signed char __attribute__((noinline,noclone))
+foo8 (vector signed char a)
+{
+  return vec_sldw (a, (vector signed char){ 0 }, 2);
+}
+
+vector signed short __attribute__((noinline,noclone))
+foo16 (vector signed short a)
+{
+  return vec_sldw (a, (vector signed short){ 0 }, 2);
+}
+
+vector int __attribute__((noinline,noclone))
+foo32 (vector int a)
+{
+  return vec_sldw (a, (vector int){ 0 }, 2);
+}
+
+vector long long __attribute__((noinline,noclone))
+foo64 (vector long long a)
+{
+  return vec_sldw (a, (vector long long){ 0 }, 2);
+}
+
+int
+main ()
+{
+  vector long long x;
+
+  x = (vector long long)foo8 ((vector signed char)
+{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 });
+  

Re: [PATCH] debug: make -feliminate-unused-debug-symbols the default [PR debug/86964]

[Thomas De Schampheleire]

On Fri, May 17, 2019, 11:57 Richard Biener 
wrote:

> On Fri, May 17, 2019 at 9:42 AM Thomas De Schampheleire
>  wrote:
> >
> > Hi Richard,
> >
> > El jue., 16 may. 2019 a las 14:41, Richard Biener
> > () escribió:
> > >
> > > On Thu, May 16, 2019 at 11:20 AM Thomas De Schampheleire
> > >  wrote:
> > > >
> > > > From: Thomas De Schampheleire 
> > > >
> > > > In addition to making -feliminate-unused-debug-symbols work for the
> DWARF
> > > > format (see [1]), make this option the default. This behavior was
> the case
> > > > before, e.g. under gcc 4.9.x.
> > > > [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=269925
> > >
> > > I have tested this patch and it causes a few FAILs, eventually hinting
> > > at implementation issues:
> > >
> > > === g++ tests ===
> > >
> > >
> > > Running target unix
> > > FAIL: g++.dg/debug/enum-2.C -gstabs -O2  scan-assembler JTI_MAX
> > > FAIL: g++.dg/debug/enum-2.C -gstabs -O3  scan-assembler JTI_MAX
> > > FAIL: g++.dg/debug/enum-2.C -gstabs+ -O2  scan-assembler JTI_MAX
> > > FAIL: g++.dg/debug/enum-2.C -gstabs+ -O3  scan-assembler JTI_MAX
> > > FAIL: g++.dg/debug/enum-2.C -gstabs+3 -O2  scan-assembler JTI_MAX
> > > FAIL: g++.dg/debug/enum-2.C -gstabs+3 -O3  scan-assembler JTI_MAX
> > > FAIL: g++.dg/debug/enum-2.C -gstabs3 -O2  scan-assembler JTI_MAX
> > > FAIL: g++.dg/debug/enum-2.C -gstabs3 -O3  scan-assembler JTI_MAX
> > >
> > > maybe expected (stabs)
> > >
> > > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler
> field_head_or
> > > dy_defn_fld_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler
> field_head_or
> > > dy_defn_ptr_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler
> field_head_or
> > > dy_defn_ref_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler
> field_head_or
> > > dy_defn_var_head_fld.*DW_AT_name
> > > ... more ...
> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++14
> scan-assembler gstruct_
> > > head_ordy_defn_var_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++14
> scan-assembler gstruct_
> > > head_tmpl_defn_var_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++17
> scan-assembler gstruct_
> > > head_ordy_defn_var_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++17
> scan-assembler gstruct_
> > > head_tmpl_defn_var_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++98
> scan-assembler gstruct_
> > > head_ordy_defn_var_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++98
> > > scan-assembler gstruct_head_tmpl_defn_var_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-none.C  -std=gnu++14  scan-assembler
> > > gstruct_head_ordy_defn_var_head.*DW_AT_name
> > > FAIL: g++.dg/debug/dwarf2/fesd-none.C  -std=gnu++14  scan-assembler
> > > gstruct_head_tmpl_defn_var_head.*DW_AT_name
> > > ... more fesd-* testcases FAIL ...
> > > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> > > scan-assembler-times  DW_AT_[^\\n\\r]*linkage_name 7
> > > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> > > scan-assembler-times  DW_AT_specification 6
> > > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> > > scan-assembler-times 0x3[^\\n\\r]* DW_AT_inline 6
> > >
> > > C variants of the fesd-* testcases also FAIL.  Those testcases are
> > > huge, a quick look didn't
> > > reveal whether those are expected FAILs or not.
> >
> >
> > I tried reproducing these failures, using 'make bootstrap && make
> > check', but I see many many test failures:
> >
> > === gcc Summary ===
> >
> > # of expected passes144268
> > # of unexpected failures113
> > # of unexpected successes28
> > # of expected failures593
> > # of unresolved testcases2
> > # of unsupported tests2279
> >
> > === g++ Summary ===
> >
> > # of expected passes134673
> > # of unexpected failures137
> > # of expected failures527
> > # of unsupported tests5944
> >
> > /home/tdescham/repo/contrib/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc
> > version 10.0.0 20190516 (experimental) (GCC)
> >
> >
> > Is it expected that 'master' (gcc 10) has such failures? Should I test
> > on another branch, if so which?
>
> The guality ones are probably the most "disturbing", but yes, there
> are quite a number of FAILs, my last result shows
>
> === gcc Summary ===
>
> # of expected passes144773
> # of unexpected failures102
> # of unexpected successes   28
> # of expected failures  602
> # of unresolved testcases   2
> # of unsupported tests  2297
>
> === g++ Summary ===
>
> # of expected passes134956
> # of unexpected failures1
> # of expected failures  527
> # of unsupported tests  5946
>
> so esp. the C suite has quite a lot (guality, 

Re: [PATCH] debug: make -feliminate-unused-debug-symbols the default [PR debug/86964]

[Richard Biener]

On Fri, May 17, 2019 at 9:42 AM Thomas De Schampheleire
 wrote:
>
> Hi Richard,
>
> El jue., 16 may. 2019 a las 14:41, Richard Biener
> () escribió:
> >
> > On Thu, May 16, 2019 at 11:20 AM Thomas De Schampheleire
> >  wrote:
> > >
> > > From: Thomas De Schampheleire 
> > >
> > > In addition to making -feliminate-unused-debug-symbols work for the DWARF
> > > format (see [1]), make this option the default. This behavior was the case
> > > before, e.g. under gcc 4.9.x.
> > > [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=269925
> >
> > I have tested this patch and it causes a few FAILs, eventually hinting
> > at implementation issues:
> >
> > === g++ tests ===
> >
> >
> > Running target unix
> > FAIL: g++.dg/debug/enum-2.C -gstabs -O2  scan-assembler JTI_MAX
> > FAIL: g++.dg/debug/enum-2.C -gstabs -O3  scan-assembler JTI_MAX
> > FAIL: g++.dg/debug/enum-2.C -gstabs+ -O2  scan-assembler JTI_MAX
> > FAIL: g++.dg/debug/enum-2.C -gstabs+ -O3  scan-assembler JTI_MAX
> > FAIL: g++.dg/debug/enum-2.C -gstabs+3 -O2  scan-assembler JTI_MAX
> > FAIL: g++.dg/debug/enum-2.C -gstabs+3 -O3  scan-assembler JTI_MAX
> > FAIL: g++.dg/debug/enum-2.C -gstabs3 -O2  scan-assembler JTI_MAX
> > FAIL: g++.dg/debug/enum-2.C -gstabs3 -O3  scan-assembler JTI_MAX
> >
> > maybe expected (stabs)
> >
> > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
> > field_head_or
> > dy_defn_fld_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
> > field_head_or
> > dy_defn_ptr_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
> > field_head_or
> > dy_defn_ref_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
> > field_head_or
> > dy_defn_var_head_fld.*DW_AT_name
> > ... more ...
> > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++14  scan-assembler 
> > gstruct_
> > head_ordy_defn_var_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++14  scan-assembler 
> > gstruct_
> > head_tmpl_defn_var_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++17  scan-assembler 
> > gstruct_
> > head_ordy_defn_var_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++17  scan-assembler 
> > gstruct_
> > head_tmpl_defn_var_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++98  scan-assembler 
> > gstruct_
> > head_ordy_defn_var_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++98
> > scan-assembler gstruct_head_tmpl_defn_var_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-none.C  -std=gnu++14  scan-assembler
> > gstruct_head_ordy_defn_var_head.*DW_AT_name
> > FAIL: g++.dg/debug/dwarf2/fesd-none.C  -std=gnu++14  scan-assembler
> > gstruct_head_tmpl_defn_var_head.*DW_AT_name
> > ... more fesd-* testcases FAIL ...
> > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> > scan-assembler-times  DW_AT_[^\\n\\r]*linkage_name 7
> > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> > scan-assembler-times  DW_AT_specification 6
> > FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> > scan-assembler-times 0x3[^\\n\\r]* DW_AT_inline 6
> >
> > C variants of the fesd-* testcases also FAIL.  Those testcases are
> > huge, a quick look didn't
> > reveal whether those are expected FAILs or not.
>
>
> I tried reproducing these failures, using 'make bootstrap && make
> check', but I see many many test failures:
>
> === gcc Summary ===
>
> # of expected passes144268
> # of unexpected failures113
> # of unexpected successes28
> # of expected failures593
> # of unresolved testcases2
> # of unsupported tests2279
>
> === g++ Summary ===
>
> # of expected passes134673
> # of unexpected failures137
> # of expected failures527
> # of unsupported tests5944
>
> /home/tdescham/repo/contrib/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc
> version 10.0.0 20190516 (experimental) (GCC)
>
>
> Is it expected that 'master' (gcc 10) has such failures? Should I test
> on another branch, if so which?

The guality ones are probably the most "disturbing", but yes, there
are quite a number of FAILs, my last result shows

=== gcc Summary ===

# of expected passes144773
# of unexpected failures102
# of unexpected successes   28
# of expected failures  602
# of unresolved testcases   2
# of unsupported tests  2297

=== g++ Summary ===

# of expected passes134956
# of unexpected failures1
# of expected failures  527
# of unsupported tests  5946

so esp. the C suite has quite a lot (guality, that is...)

> And is there a way to run only specific tests, e.g. the ones that you
> pointed out?

Yes, from inside gcc/ (in the build tree) do

make check-g++ RUNTESTFLAGS="debug.exp=enum-2.C"

to run a single testcase.  Omit the '=enum-2.C' to run all 

Re: [PATCH] Define std::__invoke_r for INVOKE

[Jonathan Wakely]

On 17/05/19 10:15 +0100, Jonathan Wakely wrote:

I'm testing the attached fix. Thanks for the report.


Tests passed, patch committed to trunk.



commit 6ae6283255f58ad44a159970dce6f431cf46f293
Author: Jonathan Wakely 
Date:   Fri May 17 10:10:10 2019 +0100

   Fix __invoke_r to be valid in C++11
   
   * include/bits/invoke.h [__cplusplus < 201703L] (__invoke_r):

   Use _GLIBCXX14_CONSTEXPR because void functions cannot be constexpr
   in C++11.

diff --git a/libstdc++-v3/include/bits/invoke.h 
b/libstdc++-v3/include/bits/invoke.h
index 59e22da84d4..b2e9eee1a48 100644
--- a/libstdc++-v3/include/bits/invoke.h
+++ b/libstdc++-v3/include/bits/invoke.h
@@ -144,7 +144,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

  // INVOKE when R is cv void
  template
-constexpr __can_invoke_as_void<_Res, _Callable, _Args...>
+_GLIBCXX14_CONSTEXPR __can_invoke_as_void<_Res, _Callable, _Args...>
__invoke_r(_Callable&& __fn, _Args&&... __args)
{
  using __result = __invoke_result<_Callable, _Args...>;

[PATCH] Add missing piece of P0777R1 and update C++20 status docs

[Jonathan Wakely]

* doc/xml/manual/status_cxx2020.xml: Update P0608R3, P0777R1, and
P1165R1 entries.
* doc/html/*: Regenerate.
* include/std/tuple (make_from_tuple): Use remove_reference_t instead
of decay_t (P0777R1).

Tested powerpc64le-linux, committed to trunk.


commit 867e57fbf824520973453cfa9e08c3a9ee3a5df8
Author: Jonathan Wakely 
Date:   Fri May 17 00:29:22 2019 +0100

Add missing piece of P0777R1 and update C++20 status docs

* doc/xml/manual/status_cxx2020.xml: Update P0608R3, P0777R1, and
P1165R1 entries.
* doc/html/*: Regenerate.
* include/std/tuple (make_from_tuple): Use remove_reference_t 
instead
of decay_t (P0777R1).

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
index 5cdd2227ae0..c7a543f85d9 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
@@ -227,14 +227,13 @@ Feature-testing recommendations for C++.
 
 
 
-  
 Treating Unnecessary decay 
   
 http://www.w3.org/1999/xlink; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0777r1.pdf;>
P0777R1

   
-   
+   9.1 
   
 
 
@@ -702,14 +701,13 @@ Feature-testing recommendations for C++.
 
 
 
-  
 A sane variant converting constructor 
   
 http://www.w3.org/1999/xlink; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0608r3.html;>
P0608R3

   
-   
+   10.1 
   
 
 
@@ -863,14 +861,13 @@ Feature-testing recommendations for C++.
 
 
 
-  
 Make stateful allocator propagation more consistent for 
operator+(basic_string) 
   
 http://www.w3.org/1999/xlink; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1165r1.html;>
P1165R1

   
-   
+   10.1 
   
 
 
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index a28111749f0..b81157c097b 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -1756,7 +1756,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   return __make_from_tuple_impl<_Tp>(
 std::forward<_Tuple>(__t),
-   make_index_sequence>>{});
+   make_index_sequence>>{});
 }
 #endif // C++17
 

[PATCH][gimplefe] Handle __VEC_PERM

[Richard Biener]

Bootstrap / testing in progress on x86_64-unknown-linux-gnu.

Richard.

2019-05-17  Richard Biener  

c/
* gimple-parser.c (c_parser_gimple_statement): Handle __VEC_PERM.
(c_parser_gimple_unary_expression): Likewise.
(c_parser_gimple_parentized_ternary_expression): New function.

* gimple-pretty-print.c (dump_ternary_rhs): Handle dumping
VEC_PERM_EXPR as __VEC_PERM with -gimple.

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

Index: gcc/c/gimple-parser.c
===
--- gcc/c/gimple-parser.c   (revision 271315)
+++ gcc/c/gimple-parser.c   (working copy)
@@ -746,8 +746,9 @@ c_parser_gimple_statement (gimple_parser
if (strcmp (IDENTIFIER_POINTER (id), "__ABS") == 0
|| strcmp (IDENTIFIER_POINTER (id), "__ABSU") == 0
|| strcmp (IDENTIFIER_POINTER (id), "__MIN") == 0
+   || strcmp (IDENTIFIER_POINTER (id), "__MAX") == 0
|| strcmp (IDENTIFIER_POINTER (id), "__BIT_INSERT") == 0
-   || strcmp (IDENTIFIER_POINTER (id), "__MAX") == 0)
+   || strcmp (IDENTIFIER_POINTER (id), "__VEC_PERM") == 0)
  goto build_unary_expr;
break;
   }
@@ -1012,6 +1013,38 @@ c_parser_gimple_parentized_binary_expres
   return ret;
 }
 
+/* Parse a gimple parentized binary expression.  */
+
+static c_expr
+c_parser_gimple_parentized_ternary_expression (gimple_parser ,
+  location_t op_loc,
+  tree_code code)
+{
+  struct c_expr ret;
+  ret.set_error ();
+
+  c_parser_consume_token (parser);
+  if (!c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
+return ret;
+  c_expr op1 = c_parser_gimple_postfix_expression (parser);
+  if (!c_parser_require (parser, CPP_COMMA, "expected %<,%>"))
+return ret;
+  c_expr op2 = c_parser_gimple_postfix_expression (parser);
+  if (!c_parser_require (parser, CPP_COMMA, "expected %<)%>"))
+return ret;
+  c_expr op3 = c_parser_gimple_postfix_expression (parser);
+  if (!c_parser_require (parser, CPP_CLOSE_PAREN, "expected %<)%>"))
+return ret;
+
+  if (op1.value != error_mark_node
+  && op2.value != error_mark_node
+  && op3.value != error_mark_node)
+ret.value = build3_loc (op_loc,
+   code, TREE_TYPE (op1.value),
+   op1.value, op2.value, op3.value);
+  return ret;
+}
+
 /* Parse gimple unary expression.
 
gimple-unary-expression:
@@ -1109,6 +1142,9 @@ c_parser_gimple_unary_expression (gimple
return c_parser_gimple_parentized_binary_expression (parser,
 op_loc,
 MAX_EXPR);
+ else if (strcmp (IDENTIFIER_POINTER (id), "__VEC_PERM") == 0)
+   return c_parser_gimple_parentized_ternary_expression
+   (parser, op_loc, VEC_PERM_EXPR);
  else if (strcmp (IDENTIFIER_POINTER (id), "__BIT_INSERT") == 0)
{
  /* __BIT_INSERT '(' postfix-expression, postfix-expression,
Index: gcc/gimple-pretty-print.c
===
--- gcc/gimple-pretty-print.c   (revision 271315)
+++ gcc/gimple-pretty-print.c   (working copy)
@@ -529,13 +529,19 @@ dump_ternary_rhs (pretty_printer *buffer
   break;
 
 case VEC_PERM_EXPR:
-  pp_string (buffer, "VEC_PERM_EXPR <");
+  if (flags & TDF_GIMPLE)
+   pp_string (buffer, "__VEC_PERM (");
+  else
+   pp_string (buffer, "VEC_PERM_EXPR <");
   dump_generic_node (buffer, gimple_assign_rhs1 (gs), spc, flags, false);
   pp_string (buffer, ", ");
   dump_generic_node (buffer, gimple_assign_rhs2 (gs), spc, flags, false);
   pp_string (buffer, ", ");
   dump_generic_node (buffer, gimple_assign_rhs3 (gs), spc, flags, false);
-  pp_greater (buffer);
+  if (flags & TDF_GIMPLE)
+   pp_right_paren (buffer);
+  else
+   pp_greater (buffer);
   break;
 
 case REALIGN_LOAD_EXPR:
Index: gcc/testsuite/gcc.dg/gimplefe-41.c
===
--- gcc/testsuite/gcc.dg/gimplefe-41.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/gimplefe-41.c  (working copy)
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple -Wno-psabi -w" } */
+
+typedef double __v2df __attribute__ ((__vector_size__ (16)));
+typedef unsigned long __v2di __attribute__ ((__vector_size__ (16)));
+
+__v2df __GIMPLE (ssa)
+_mm_add_sd (__v2df x, __v2df y)
+{
+  __v2df z;
+  double _1;
+  double _2;
+  double _3;
+  __v2df _7;
+
+  __BB(2):
+  _1 = __BIT_FIELD_REF  (x_4(D), 64u, 0u);
+  _2 = __BIT_FIELD_REF  (y_5(D), 64u, 0u);
+  _3 = _1 + _2;
+  _7 = _Literal (__v2df) {_3, _3};
+  z_6 = __VEC_PERM (x_4(D), _7, _Literal (__v2di) { 2ul, 1ul });
+  return z_6;
+}
+
+__v2df __GIMPLE (ssa)

Re: [PATCH] Define std::__invoke_r for INVOKE

[Jonathan Wakely]

On 17/05/19 10:49 +0200, Stephan Bergmann wrote:

On 14/05/2019 17:25, Jonathan Wakely wrote:

* include/bits/invoke.h (__invoke_r): Define new function implementing
the INVOKE pseudo-function.
* testsuite/20_util/function_objects/invoke/1.cc: Add more tests.
* testsuite/20_util/function_objects/invoke/2.cc: New test.

Tested powerpc64le-linux, committed to trunk.



diff --git a/libstdc++-v3/include/bits/invoke.h 
b/libstdc++-v3/include/bits/invoke.h
index a5278a59f0c..59e22da84d4 100644
--- a/libstdc++-v3/include/bits/invoke.h
+++ b/libstdc++-v3/include/bits/invoke.h
@@ -96,6 +96,65 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::forward<_Args>(__args)...);
}
+#if __cplusplus >= 201703L
+  // INVOKE: Invoke a callable object and convert the result to R.
+  template
+constexpr enable_if_t, _Res>
+__invoke_r(_Callable&& __fn, _Args&&... __args)
+noexcept(is_nothrow_invocable_r_v<_Res, _Callable, _Args...>)
+{
+  using __result = __invoke_result<_Callable, _Args...>;
+  using __type = typename __result::type;
+  using __tag = typename __result::__invoke_type;
+  if constexpr (is_void_v<_Res>)
+   std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
+   std::forward<_Args>(__args)...);
+  else
+   return std::__invoke_impl<__type>(__tag{},
+ std::forward<_Callable>(__fn),
+ std::forward<_Args>(__args)...);
+}
+#else // C++11
+  template
+using __can_invoke_as_void = __enable_if_t<
+  __and_, __is_invocable<_Callable, _Args...>>::value,
+  _Res
+>;
+
+  template
+using __can_invoke_as_nonvoid = __enable_if_t<
+  __and_<__not_>,
+is_convertible::type,
+   _Res>
+  >::value,
+  _Res
+>;
+
+  // INVOKE: Invoke a callable object and convert the result to R.
+  template
+constexpr __can_invoke_as_nonvoid<_Res, _Callable, _Args...>
+__invoke_r(_Callable&& __fn, _Args&&... __args)
+{
+  using __result = __invoke_result<_Callable, _Args...>;
+  using __type = typename __result::type;
+  using __tag = typename __result::__invoke_type;
+  return std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
+   std::forward<_Args>(__args)...);
+}
+
+  // INVOKE when R is cv void
+  template
+constexpr __can_invoke_as_void<_Res, _Callable, _Args...>
+__invoke_r(_Callable&& __fn, _Args&&... __args)


I think this is a problem with -std=c++11 (but not -std=c++14) where 
void is not yet a literal type, so this function can't be constexpr?



Yes, Clang diagnoses this in C++11 mode but G++ accepts it (unless you
actually try to call g() in a constant expression):

template struct voidy { using type = void; };
template constexpr typename voidy::type g() {}

$ clang++ v.cc -std=c++11
v.cc:2:56: error: no return statement in constexpr function
template constexpr typename voidy::type g() {}
  ^
1 error generated.


I'm testing the attached fix. Thanks for the report.


commit 6ae6283255f58ad44a159970dce6f431cf46f293
Author: Jonathan Wakely 
Date:   Fri May 17 10:10:10 2019 +0100

Fix __invoke_r to be valid in C++11

* include/bits/invoke.h [__cplusplus < 201703L] (__invoke_r):
Use _GLIBCXX14_CONSTEXPR because void functions cannot be constexpr
in C++11.

diff --git a/libstdc++-v3/include/bits/invoke.h b/libstdc++-v3/include/bits/invoke.h
index 59e22da84d4..b2e9eee1a48 100644
--- a/libstdc++-v3/include/bits/invoke.h
+++ b/libstdc++-v3/include/bits/invoke.h
@@ -144,7 +144,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // INVOKE when R is cv void
   template
-constexpr __can_invoke_as_void<_Res, _Callable, _Args...>
+_GLIBCXX14_CONSTEXPR __can_invoke_as_void<_Res, _Callable, _Args...>
 __invoke_r(_Callable&& __fn, _Args&&... __args)
 {
   using __result = __invoke_result<_Callable, _Args...>;

Re: [PATCH] libfortran/90038: Use posix_spawn instead of fork

[Janne Blomqvist]

On Thu, May 16, 2019 at 11:37 PM Nicolas Koenig
 wrote:
>
> Hi everyone,
>
> a quick heads up, that the native coarray patch I'm working on at the
> moment (1200 loc and growing :D) will be based upon forked processes, so
> we won't be able to eliminate fork().

I would guess that's a case where fork semantics are useful, as
presumably copying the memory of a process is exactly what you want.
posix_spawn() is a replacement for some common uses of fork+exec.

> P.S.: About the paper: A microsoft guy who doesn't like fork()? Color me
> surprised :D

Well, it's one author out of four. And it's Microsoft Research, which
does serious CS research, not PR department vomit. The paper does make
some good points, and it's worth reading.

As an interesting aside, the original libgfortran IO library was based
upon a paper by one of the authors of this paper. One of my first
contributions to GFortran back in the day was ripping out that.

>
>
> On 16/05/2019 22:10, Janne Blomqvist wrote:
> > On Thu, May 16, 2019 at 10:59 PM Thomas Koenig  
> > wrote:
> >>
> >> Hi Janne,
> >>
> >>> fork() semantics can be problematic.  Most unix style OS'es have
> >>> posix_spawn which can be used to replace fork + exec in many cases.
> >>> For more information see
> >>> e.g. 
> >>> https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
> >>>
> >>> This replaces the one use of fork in libgfortran with posix_spawn.
> >>
> >> Do I understand the patch correctly that we would no longer use fork()
> >> if posix_spawn is not available?  I think we should leave that in as
> >> a fallback option.
> >
> > Yes. But there is already a fallback in case posix_spawn (or
> > previously, fork) is not available, namely falling back to synchronous
> > behavior. Since this is anyway somewhat of a corner case (namely, with
> > wait=.false.), and posix_spawn is supported on all (well, at least
> > Linux, macOS, *BSD, cygwin, Solarix, AIX) remotely modern unix type
> > systems, a further fallback to fork() is IMHO not warranted.
> >
> >



-- 
Janne Blomqvist

Re: [PATCH] libfortran/90038: Use posix_spawn instead of fork

[Janne Blomqvist]

On Thu, May 16, 2019 at 11:54 PM Thomas Koenig  wrote:
>
> Hi Janne,
>
> > I differ there.
>
> A longer explanation:
>
> fork() is standard POSIX.

So is posix_spawn, as the name implies.

>Not all systems have posix_spawn.

Do you know of any target we support that has fork but not posix_spawn?

> The patch is OK from my side if you add fork() as a fallback option.

Sure. I'm quite sure it's dead code that will never be executed, but
hey, it's ifdeffed away so whatever.


-- 
Janne Blomqvist

Re: [PATCH] Do not allow target_clones with alias attr (PR lto/90500).

[Martin Liška]

On 5/16/19 1:42 PM, Richard Biener wrote:
>  IMHO
> a reasonable feature, not sure if a reasonable way to achieve.

Just for the record. The use case was not about having an alias to
a default clone. They just want to test multi-versioning of some glibc
math routines.

Martin

Re: Strenghten aliasing_component_refs_p

[Richard Biener]

On Fri, 17 May 2019, Jan Hubicka wrote:

> Hi,
> this patch cuts walks in aliasing_component_refs_p if the type we look for
> can not fit into a given type by comparing their sizes. Similar logic
> already exists in indirect_ref_may_alias_decl_p.
> 
> When we walk reference a.b.c.d.e looking for type x we only need to do
> it if sizeof(a)>=sizeof(x) and continue woking from e until
> sizeof(e)<=sizeof(x). We do not need to compare types where sizes are
> known to be different.
> 
> This saves some work (by not walking refs and not comparing their types
> if they can not match) but also increases number of disambiguations
> quite noticably. This is because same_type_for_tbaa often returns -1 and
> makes aliasing_compinent_refs_p to give up.  Using the simple size check
> prevents hitting such problematic type pairs in many common cases.
> 
> Stats on tramp3d lto build change From:
> 
> Alias oracle query stats:
>   refs_may_alias_p: 0 disambiguations, 0 queries
>   ref_maybe_used_by_call_p: 6451 disambiguations, 25578 queries
>   call_may_clobber_ref_p: 817 disambiguations, 817 queries
>   aliasing_component_ref_p: 14 disambiguations, 12528 queries
>   TBAA oracle: 1468347 disambiguations 3010562 queries
>550690 are in alias set 0
>614235 queries asked about the same object
>0 queries asked about the same alias set
>0 access volatile
>260937 are dependent in the DAG
>116353 are aritificially in conflict with void *
> 
> to:
> 
> Alias oracle query stats:
>   refs_may_alias_p: 0 disambiguations, 0 queries
>   ref_maybe_used_by_call_p: 6451 disambiguations, 25580 queries
>   call_may_clobber_ref_p: 817 disambiguations, 817 queries
>   aliasing_component_ref_p: 118 disambiguations, 12552 queries
>   TBAA oracle: 1468413 disambiguations 3010714 queries
>550719 are in alias set 0
>614247 queries asked about the same object
>0 queries asked about the same alias set
>0 access volatile
>260970 are dependent in the DAG
>116365 are aritificially in conflict with void *
> 
> So disambiguations are up from 14 to 118 which is still quite low.
> 
> A followup patch making types_same_for_tbaa to not give up for
> TYPE_STRUCTURAL_EQUALITY pointers and arrays improves hitrate to 2723.
> 
> Bootstrapped/regtested x86_64-linux, OK?
> 
>   * tree-ssa-alias.c (type_big_enough_for_type_p): New function.
>   (aliasing_component_refs_p): Use it.
> Index: tree-ssa-alias.c
> ===
> --- tree-ssa-alias.c  (revision 271292)
> +++ tree-ssa-alias.c  (working copy)
> @@ -735,6 +735,27 @@ ao_ref_init_from_ptr_and_size (ao_ref *r
>ref->volatile_p = false;
>  }
>  
> +/* Return true if TYPE1 may contain TYPE2 by its size.  */
> +
> +static bool
> +type_big_enough_for_type_p (tree type1, tree type2)
> +{
> +  if (!TYPE_SIZE (type1) || !TYPE_SIZE (type2))
> +return true;
> +  /* Be conservative for arrays and vectors.  We want to support partial
> + overlap on int[3] and int[3] as tested in gcc.dg/torture/alias-2.c.  */
> +  while (TREE_CODE (type2) == ARRAY_TYPE
> +  || TREE_CODE (type2) == VECTOR_TYPE)
> +type2 = TREE_TYPE (type2);

Eww ;)  I guess this means same-type can never return true for
array or vectors?

> +  if (!poly_int_tree_p (TYPE_SIZE (type1))
> +  || !poly_int_tree_p (TYPE_SIZE (type2)))
> +return true;

Use

poly_uint64 size1;
if (!poly_int_tree_p (TYPE_SIZE (type1), )
 ...

> +  if (known_lt (wi::to_poly_widest (TYPE_SIZE (type1)),
> + wi::to_poly_widest (TYPE_SIZE (type2

and

 if (known_lt (size1, size2))

I wonder if you can compute whether type1 fits in type2 and
the other way around at the same time, saving seemingly
redundant work since you test both ways most of the time below.
So sth like type_size_compare_for_fitting () returning
-1, 0, 1 and use zero for "don't know"?

> +return false;
> +  return true;
> +}
> +
>  /* Return 1 if TYPE1 and TYPE2 are to be considered equivalent for the
> purpose of TBAA.  Return 0 if they are distinct and -1 if we cannot
> decide.  */
> @@ -803,7 +824,7 @@ aliasing_component_refs_p (tree ref1,
>tree base1, base2;
>tree type1, type2;
>tree *refp;
> -  int same_p, same_p2;
> +  int same_p1 = 0, same_p2 = 0;
>  
>/* Choose bases and base types to search for.  */
>base1 = ref1;
> @@ -816,65 +837,88 @@ aliasing_component_refs_p (tree ref1,
>type2 = TREE_TYPE (base2);
>  
>/* Now search for the type1 in the access path of ref2.  This
> - would be a common base for doing offset based disambiguation on.  */
> -  refp = 
> -  while (handled_component_p (*refp)
> -  && same_type_for_tbaa (TREE_TYPE (*refp), type1) == 0)
> -refp = _OPERAND (*refp, 0);
> -  same_p = same_type_for_tbaa (TREE_TYPE (*refp), type1);
> -  if (same_p 

Re: [PATCH] Define std::__invoke_r for INVOKE

[Stephan Bergmann]

On 14/05/2019 17:25, Jonathan Wakely wrote:

 * include/bits/invoke.h (__invoke_r): Define new function implementing
 the INVOKE pseudo-function.
 * testsuite/20_util/function_objects/invoke/1.cc: Add more tests.
 * testsuite/20_util/function_objects/invoke/2.cc: New test.

Tested powerpc64le-linux, committed to trunk.



diff --git a/libstdc++-v3/include/bits/invoke.h 
b/libstdc++-v3/include/bits/invoke.h
index a5278a59f0c..59e22da84d4 100644
--- a/libstdc++-v3/include/bits/invoke.h
+++ b/libstdc++-v3/include/bits/invoke.h
@@ -96,6 +96,65 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::forward<_Args>(__args)...);
 }
 
+#if __cplusplus >= 201703L

+  // INVOKE: Invoke a callable object and convert the result to R.
+  template
+constexpr enable_if_t, _Res>
+__invoke_r(_Callable&& __fn, _Args&&... __args)
+noexcept(is_nothrow_invocable_r_v<_Res, _Callable, _Args...>)
+{
+  using __result = __invoke_result<_Callable, _Args...>;
+  using __type = typename __result::type;
+  using __tag = typename __result::__invoke_type;
+  if constexpr (is_void_v<_Res>)
+   std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
+   std::forward<_Args>(__args)...);
+  else
+   return std::__invoke_impl<__type>(__tag{},
+ std::forward<_Callable>(__fn),
+ std::forward<_Args>(__args)...);
+}
+#else // C++11
+  template
+using __can_invoke_as_void = __enable_if_t<
+  __and_, __is_invocable<_Callable, _Args...>>::value,
+  _Res
+>;
+
+  template
+using __can_invoke_as_nonvoid = __enable_if_t<
+  __and_<__not_>,
+is_convertible::type,
+   _Res>
+  >::value,
+  _Res
+>;
+
+  // INVOKE: Invoke a callable object and convert the result to R.
+  template
+constexpr __can_invoke_as_nonvoid<_Res, _Callable, _Args...>
+__invoke_r(_Callable&& __fn, _Args&&... __args)
+{
+  using __result = __invoke_result<_Callable, _Args...>;
+  using __type = typename __result::type;
+  using __tag = typename __result::__invoke_type;
+  return std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
+   std::forward<_Args>(__args)...);
+}
+
+  // INVOKE when R is cv void
+  template
+constexpr __can_invoke_as_void<_Res, _Callable, _Args...>
+__invoke_r(_Callable&& __fn, _Args&&... __args)


I think this is a problem with -std=c++11 (but not -std=c++14) where 
void is not yet a literal type, so this function can't be constexpr?


(I came across this with Clang -std=c++11 upon #include  
producing an odd



In file included from 
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/memory:81:
In file included from 
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/unique_ptr.h:37:
In file included from 
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/tuple:41:
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/invoke.h:148:5:
 error: no return statement in constexpr function
__invoke_r(_Callable&& __fn, _Args&&... __args)
^


I first reduced that to a broken reproducer and misclassified it as a 
Clang bug,  "Bogus 'error: 
no return statement in constexpr function' when void return type is 
'templated'".  But what apparently happens is that since Clang knows 
that the constexpr function must have a literal return type (which can't 
be void for -std=c++11), it just issues that error whenever it comes a 
constexpr function that lacks a return type.)



+{
+  using __result = __invoke_result<_Callable, _Args...>;
+  using __type = typename __result::type;
+  using __tag = typename __result::__invoke_type;
+  std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
+std::forward<_Args>(__args)...);
+}
+#endif // C++11
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 

Re: [PATCH 1/2] Add support for IVOPT

[Richard Sandiford]

Kugan Vivekanandarajah  writes:
> [...]
>> > +{
>> > +  struct mem_address parts = {NULL_TREE, integer_one_node,
>> > +   NULL_TREE, NULL_TREE, NULL_TREE};
>>
>> Might be better to use "= {}" and initialise the fields that matter by
>> assignment.  As it stands this uses integer_one_node as the base, but I
>> couldn't tell if that was deliberate.
>
> I just copied this part from get_address_cost, similar to what is done
> there.

Ah, sorry :-)

> I have now changed the way you suggested but using the values
> used in get_address_cost.

Thanks.

> [...]
> @@ -3479,6 +3481,35 @@ add_iv_candidate_derived_from_uses (struct ivopts_data 
> *data)
>data->iv_common_cands.truncate (0);
>  }
>  
> +/* Return the preferred mem scale factor for accessing MEM_MODE
> +   of BASE in LOOP.  */
> +static unsigned int
> +preferred_mem_scale_factor (struct loop *loop,
> + tree base, machine_mode mem_mode)

IMO this should live in tree-ssa-address.c instead.

The only use of "loop" is to test for size vs. speed, but other callers
might want to make that decision based on individual blocks, so I think
it would make sense to pass a "speed" bool instead.  Probably also worth
making it the last parameter, so that the order is consistent with
address_cost (though probably then inconsistent with something else :-)).

> [...]
> @@ -3500,6 +3531,28 @@ add_iv_candidate_for_use (struct ivopts_data *data, 
> struct iv_use *use)
>  basetype = sizetype;
>record_common_cand (data, build_int_cst (basetype, 0), iv->step, use);
>  
> +  /* Compare the cost of an address with an unscaled index with the cost of
> +an address with a scaled index and add candidate if useful. */
> +  if (use != NULL
> +  && poly_int_tree_p (iv->step)
> +  && tree_fits_poly_int64_p (iv->step)
> +  && address_p (use->type))
> +{
> +  poly_int64 new_step;
> +  poly_int64 poly_step = tree_to_poly_int64 (iv->step);

This should be:

  poly_int64 step;
  if (use != NULL
  && poly_int_tree_p (iv->step, )
  && address_p (use->type))
{
  poly_int64 new_step;

> +  unsigned int fact
> + = preferred_mem_scale_factor (data->current_loop,
> +use->iv->base,
> +TYPE_MODE (use->mem_type));
> +
> +  if ((fact != 1)
> +   && multiple_p (poly_step, fact, _step))

Should be no brackets around "fact != 1".

> [...]

Looks really good to me otherwise, thanks.  Bin, any comments?

Richard

Re: patches to detect GCC diagnostics

[Roland Illig]

Am 16.05.2019 um 22:24 schrieb Martin Sebor:
> On 5/16/19 8:58 AM, Roland Illig wrote:
>> -  error ("#pragma GCC target string... is badly formed");
>> +  error ("%<#pragma GCC target%> string is badly formed");
>> -  error ("#pragma GCC optimize string... is badly formed");
>> +  error ("%<#pragma GCC optimize%> string is badly formed");
>>
>> I think the "string..." was supposed to go inside the quotes.
>
> The "string" refers to the pragma argument and quoting it would
> imply that the word string should be verbatim.  So I think it's
> correct as is, despite the call above:
>
>   GCC_BAD ("%<#pragma GCC optimize (string [,string]...)%> does "
>    "not have a final %<)%>");
>
> where the string is part of the grammar being shown.

I disagree. All these messages are structurally the same. They refer to
"#pragma GCC target" as a fixed string and "string..." as being a
placeholder for arguments.

It doesn't make sense to say "the string '#pragma GCC target' is
malformed", which is what your suggested message implies. Either the
word "string" should be left out completely, or it should be marked as a
placeholder. You mentioned elsewhere that the diagnostics could use
italics. This might be another case for them.

Instead of the word "string", a more specific term should be used here,
such as "argument to %<#pragma GCC optimize%> is badly formed".

>> -  error_at (loc, "typeid-expression is not a constant expression "
>> +  error_at (loc, "% is not a constant expression "
>>
>> This sounds like a term from the C++ grammar.
>
> It does but there is no /typeid-expression/ in the C++ grammar.
> It's just % expression.  I took out the word "expression"
> because it seemed redundant with the "constant expression" that
> follows.
>
> That said, it could be handy to be able to uniquely distinguish
> grammar terms (do you translate C/C++ grammar terms or leave them
> in English?).  I'd like to add either a new directive or flag to
> %< to let us do that.  E.g. with something like:
>
>   "%#"
>
> GCC could render the term in italics (there's a bug where we
> discussed this that I can't find right now).

In the German translation I kept most of these grammar production names
in English, so that you can search for the exact terms.

In the French, Russian and Swedish translations, most of them are
translated into the user's native language, in order to make them more
understandable.

I'm not sure whether we really need additional directives or flags here.
I think the normal % would give a strong enough indication already.

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Sandiford]

Joseph Myers  writes:
> On Thu, 16 May 2019, Maxim Kuvyrkov wrote:
>
>> Let's avoid mixing the two discussions: (1) converting svn repo to git 
>> (and getting community consensus to switch to git) and (2) deciding on 
>> which branches to keep in the new repo.
>> 
>> With git, we can always split away unneeded history by removing 
>> unnecessary branches and tags and re-packing the repo.  We can equally 
>> easily bring that history back if we change our minds.
>
> A prerequisite of a move to git is to have policies on branch deletion / 
> force-pushes, and hook implementations that ensure those policies are 
> followed (as well as implementing what's agreed on commit messages, 
> Bugzilla updates, etc.).  There has of course been a lot of past 
> discussion of those that someone will need to find, read and describe the 
> issues and conclusions from.  I think there was a view that branch 
> deletion and force-pushes should be limited to a particular namespace for 
> user branches.

We're not starting from scratch on that though.  The public git
(semi-)mirror has been going for a long time, so IMO we should just
inherit the policies for that.  (Like you say, forced pushed are
restricted to the user namespace.)  Policies can evoluve over time :-)

Agreeing on a format for commit messages would be good, but IMO it's
a separate improvement to the repo discussion.  We don't have an agreed
format for SVN commit messages either, and although it's not ideal,
it doesn't make SVN unworkable.  The same would be true for git.
Whatever policy we come up with can't apply retrospectively anyway,
so the full git history is always going to have a mixture of styles.

And I think that's the major downside of putting so many barriers
in the way of the conversion.  Switching to git without new commit
message guidelines might not be perfect, but if we'd done it two years
ago anyway, people would have been committing (mostly) git-friendly
commits since then, even if the messages weren't very consistent.
Whereas at the moment, many commit messages are neither git-friendly
nor consistent.  And that's going to continue to be the case until
we switch.

So although the intention of these requirements seems to be to make the
final git history as good as it can be, I think in practice it's having
the opposite effect.

> (I support a move to git, but not one using git-svn, and only one that 
> properly takes into account the large amount of work previously done on 
> author maps, understanding the repository peculiarities and how to 
> correctly identify exactly which directories are branches or tags, fixing 
> cases where there are both a branch and tag of the same name, identifying 
> which tags to remove and which to keep, etc.)

But the discussion upthread seemed to be that having the very old stuff
in git wasn't necessarily that important anyway.

FWIW, I've been using the "official" git-svn based mirror for at least
the last five years, only using SVN to actually commit.  And I've never
needed any of the above during that time.

E.g. having proper author names seems like a nice-to-have rather than
a requirement.  A lot of the effort spent on compiling that list seemed
to be getting names and email addresses for people who haven't contributed
to gcc for a long time (in some cases 20 years or more).  It's interesting
historical data, but in almost all cases, the email addresses used are
going to be defunct anyway.

It would be a really neat project to create a GCC git repo that goes
far back in time and gives the closest illusion possible that git had
been used all that time.  And personally I'd be very interested in
seeing that.  But its main use would be as a historical artefact,
to show how a long-running software project evolved over time.

I think the focus for the development git repo should be on what's
needed for day-to-day work, and like I say, the git-svn mirror we
have now is in practice a good enough conversion for that.  If we can
do better then great.  But I think we're in serious danger of making the
best the enemy of the good here.

The big advantage of Maxim's approach is that it's a public script in
our own repo that anyone can contribute to.  So if there are specific
tweaks people want to make, there's now the opportunity to do that.

So FWIW, my vote would be for having a window to allow people to tweak
the script if they want to, then make the switch.

Thanks,
Richard

[PATCH] Remove another gimple_assign_rhs_to_tree call

[Richard Biener]

Stupid one.  We shouldn't have made it available...

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

Richard.

2019-05-17  Richard Biener  

* ccmp.c (expand_ccmp_expr_1): Do not use gimple_assign_rhs_to_tree.

Index: gcc/ccmp.c
===
--- gcc/ccmp.c  (revision 271293)
+++ gcc/ccmp.c  (working copy)
@@ -187,12 +187,11 @@ expand_ccmp_next (tree op, tree_code cod
 static rtx
 expand_ccmp_expr_1 (gimple *g, rtx_insn **prep_seq, rtx_insn **gen_seq)
 {
-  tree exp = gimple_assign_rhs_to_tree (g);
-  tree_code code = TREE_CODE (exp);
+  tree_code code = gimple_assign_rhs_code (g);
   basic_block bb = gimple_bb (g);
 
-  tree op0 = TREE_OPERAND (exp, 0);
-  tree op1 = TREE_OPERAND (exp, 1);
+  tree op0 = gimple_assign_rhs1 (g);
+  tree op1 = gimple_assign_rhs2 (g);
   gimple *gs0 = get_gimple_for_ssa_name (op0);
   gimple *gs1 = get_gimple_for_ssa_name (op1);
   rtx tmp;

[PATCH] tree-ssa-uninit: suppress more spurious warnings

[Vladislav Ivanishin]

Hi!

Without the patch, two of the newly added tests fail with bogus warnings:

- gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
  BIT_AND_EXPR.  This is an FP my previous patch [1] knowingly
  overlooks.)
- gcc.dg/uninit-30-gimple.c (EQ_EXPR in the predicate guarding use.
  This is what I spotted while refactoring.  It never worked, and is
  easy to handle).

Bootstraped with `BOOT_CFLAGS="-O -Wno-error=maybe-uninitialized
-Wuninitialized"` and regtested on x86_64-pc-linux-gnu.  OK for trunk?

Also, Richard, would you mind being a sponsor for my svn account?

[1]: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00896.html

	* tree-ssa-uninit.c (value_sat_pred_p): This new function is a wrapper
around is_value_included_in that knows how to handle BIT_AND_EXPR.
(is_pred_expr_subset_of): Use the new function.  Handle more cases where
code1 == EQ_EXPR and where code1 == BIT_AND_EXPR and thus fix some false
positives.

testsuite/
* gcc.dg/uninit-28-gimple.c: New test.
* gcc.dg/uninit-29-gimple.c: New test.
* gcc.dg/uninit-30-gimple.c: New test.
* gcc.dg/uninit-31-gimple.c: New test.
---
 gcc/testsuite/gcc.dg/uninit-28-gimple.c | 47 
 gcc/testsuite/gcc.dg/uninit-29-gimple.c | 45 +++
 gcc/testsuite/gcc.dg/uninit-30-gimple.c | 43 ++
 gcc/testsuite/gcc.dg/uninit-31-gimple.c | 48 +
 gcc/tree-ssa-uninit.c   | 37 +--
 5 files changed, 210 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/uninit-28-gimple.c
 create mode 100644 gcc/testsuite/gcc.dg/uninit-29-gimple.c
 create mode 100644 gcc/testsuite/gcc.dg/uninit-30-gimple.c
 create mode 100644 gcc/testsuite/gcc.dg/uninit-31-gimple.c

diff --git a/gcc/testsuite/gcc.dg/uninit-28-gimple.c b/gcc/testsuite/gcc.dg/uninit-28-gimple.c
new file mode 100644
index 000..0648b8a4aa7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-28-gimple.c
@@ -0,0 +1,47 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple -O -Wmaybe-uninitialized" } */
+
+unsigned int __GIMPLE (ssa,startwith("uninit1"))
+foo (unsigned int v)
+{
+  /* Uninit warning here would be bogus, because (16 & 3) == 0 and therefore
+ if v == 16, the uninit value is not used (the use is properly guarded).  */
+  unsigned int undef;/* { dg-bogus "may be used uninitialized" } */
+  unsigned int _2;
+  unsigned int _9;
+  unsigned int _10;
+  unsigned pred;
+
+  __BB(2):
+  if (v_4(D) != 16u)
+goto __BB3;
+  else
+goto __BB4;
+
+  /* 'undef' is defined conditionally (under 'v != 16' predicate)  */
+  __BB(3):
+  undef_8 = 8u;
+  goto __BB4;
+
+  /* An undef value flows into a phi.  */
+  __BB(4):
+  undef_1 = __PHI (__BB2: undef_5(D), __BB3: undef_8);
+  pred = v_4(D) & 3u;
+  if (pred != 0u)
+goto __BB5;
+  else
+goto __BB6;
+
+  /* The phi value is used here (under 'v & 3' predicate).  */
+  __BB(5):
+  _9 = undef_1;
+  goto __BB7;
+
+  __BB(6):
+  _10 = v_4(D);
+  goto __BB7;
+
+  __BB(7):
+  _2 = __PHI (__BB5: _9, __BB6: _10);
+  return _2;
+}
diff --git a/gcc/testsuite/gcc.dg/uninit-29-gimple.c b/gcc/testsuite/gcc.dg/uninit-29-gimple.c
new file mode 100644
index 000..cb5bc97164e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-29-gimple.c
@@ -0,0 +1,45 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple -O -Wmaybe-uninitialized" } */
+
+unsigned int __GIMPLE (ssa,startwith("uninit1"))
+foo (unsigned int v)
+{
+  unsigned int undef;/* { dg-warning "may be used uninitialized" } */
+  unsigned int _2;
+  unsigned int _9;
+  unsigned int _10;
+  unsigned pred;
+
+  __BB(2):
+  pred = v_4(D) & 3u;
+  if (pred != 0u)
+goto __BB3;
+  else
+goto __BB4;
+
+  /* 'undef' is defined conditionally (under 'v & 3' predicate)  */
+  __BB(3):
+  undef_8 = 8u;
+  goto __BB4;
+
+  /* An undef value flows into a phi.  */
+  __BB(4):
+  undef_1 = __PHI (__BB2: undef_5(D), __BB3: undef_8);
+  if (v_4(D) != 16u)
+goto __BB5;
+  else
+goto __BB6;
+
+  /* The phi value is used here (under 'v != 16' predicate).  */
+  __BB(5):
+  _9 = undef_1;
+  goto __BB7;
+
+  __BB(6):
+  _10 = v_4(D);
+  goto __BB7;
+
+  __BB(7):
+  _2 = __PHI (__BB5: _9, __BB6: _10);
+  return _2;
+}
diff --git a/gcc/testsuite/gcc.dg/uninit-30-gimple.c b/gcc/testsuite/gcc.dg/uninit-30-gimple.c
new file mode 100644
index 000..8c91f79d509
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-30-gimple.c
@@ -0,0 +1,43 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple -O -Wmaybe-uninitialized" } */
+
+unsigned int __GIMPLE (ssa,startwith("uninit1"))
+foo (unsigned int v)
+{
+  unsigned int undef;/* { dg-bogus "may be used uninitialized" } */
+  unsigned int _2;
+  unsigned int _9;
+  unsigned int _10;
+
+  __BB(2):
+  if (v_4(D) < 100u)
+goto __BB3;
+  else
+goto __BB4;
+
+  /* 'undef' is defined conditionally (under 'v < 100' predicate).  */
+  __BB(3):
+  

[PATCH] Honor OpenMP simdlen in the vectorizer

[Jakub Jelinek]

Hi!

When simdlen clause is specified on simd loop, it specifies the preferred
vectorization factor.  It is a preference, so if there is no possibility of
satisfying it, we can do something else, but still, we shouldn't ignore it
as we've been ignoring it before.

Unfortunately, we iterate over vectorization sizes rather than over
vectorization factors, so in order to determine the vectorization factor, we
need to analyze.

The following patch in the vectorizer when seeing a possible vectorization
which doesn't have the requested vectorization factor remembers first such
vectorization and continues searching and if no vectorization size with the
right vectorization factor is found, just uses the first one.

Another thing is that on x86 with -mprefer-vector-width={256,128} (the
former is the default), we don't actually push all the possible
vectorization sizes.  IMHO when one uses the simd clause and says say
simdlen(16) for loop which just uses ints, then the user wants to use %zmmN
operations even if the default is -mprefer-vector-width=256 or even if that
option is used explicitly.  Perhaps one option would be to push the
64 size to the vector always, just when it is not preferred put it last, but
then even for normal loops if 32 and 16 byte vectorization is unsuccessful,
we'd either waste compile time or in rare corner cases could in theory
vectorize using that vectorization size even when it is not preferred.
So, the patch adds an argument and does that only when the simdlen clause
is used.

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

2019-05-17  Jakub Jelinek  

* cfgloop.h (struct loop): Add simdlen member.
* omp-expand.c (expand_omp_simd): Set it if simdlen clause is present.
* tree-vect-loop.c (vect_analyze_loop): Pass loop->simdlen != 0
as new argument to autovectorize_vector_sizes target hook.  If
loop->simdlen, pick up vector size where the vectorization factor
is equal to loop->simd, and if there is none, fall back to the first
successful one.
(vect_transform_loop): Adjust autovectorize_vector_sizes target hook
caller.
* omp-low.c (omp_clause_aligned_alignment): Likewise.
* omp-general.c (omp_max_vf): Likewise.
* optabs-query.c (can_vec_mask_load_store_p): Likewise.
* tree-vect-slp.c (vect_slp_bb): Likewise.
* target.def (autovectorize_vector_sizes): Add ALL argument and
document it.
* doc/tm.texi: Adjust documentation.
* targhooks.c (default_autovectorize_vector_sizes): Add bool argument.
* targhooks.h (default_autovectorize_vector_sizes): Likewise.
* config/aarch64/aarch64.c (aarch64_autovectorize_vector_sizes): Add
bool argument.
* config/arc/arc.c (arc_autovectorize_vector_sizes): Likewise.
* config/arm/arm.c (arm_autovectorize_vector_sizes): Likewise.
* config/mips/mips.c (mips_autovectorize_vector_sizes): Likewise.
* config/i386/i386.c (ix86_autovectorize_vector_sizes): Likewise.  If
true and TARGET_AVX512F or TARGET_AVX, push 3 or 2 sizes even if
preferred vector size is not 512-bit or 256-bit, just put those
unpreferred ones last.

* gcc.target/i386/avx512f-simd-1.c: New test.

--- gcc/cfgloop.h.jj2019-03-08 11:43:35.063317726 +0100
+++ gcc/cfgloop.h   2019-05-16 15:52:05.974315760 +0200
@@ -174,6 +174,9 @@ struct GTY ((chain_next ("%h.next"))) lo
  of the loop can be safely evaluated concurrently.  */
   int safelen;
 
+  /* Preferred vectorization factor for the loop if non-zero.  */
+  int simdlen;
+
   /* Constraints are generally set by consumers and affect certain
  semantics of niter analyzer APIs.  Currently the APIs affected are
  number_of_iterations_exit* functions and their callers.  One typical
--- gcc/omp-expand.c.jj 2019-05-15 23:42:16.049859907 +0200
+++ gcc/omp-expand.c2019-05-16 16:10:46.093932348 +0200
@@ -4974,6 +4974,13 @@ expand_omp_simd (struct omp_region *regi
  && loop->safelen > 1)
{
  loop->force_vectorize = true;
+ if (simdlen && tree_fits_uhwi_p (OMP_CLAUSE_SIMDLEN_EXPR (simdlen)))
+   {
+ unsigned HOST_WIDE_INT v
+   = tree_to_uhwi (OMP_CLAUSE_SIMDLEN_EXPR (simdlen));
+ if (v < INT_MAX && v <= (unsigned HOST_WIDE_INT) loop->safelen)
+   loop->simdlen = v;
+   }
  cfun->has_force_vectorize_loops = true;
}
   else if (dont_vectorize)
--- gcc/tree-vect-loop.c.jj 2019-05-16 15:25:17.826832201 +0200
+++ gcc/tree-vect-loop.c2019-05-16 19:00:33.999540073 +0200
@@ -2254,7 +2254,8 @@ vect_analyze_loop (struct loop *loop, lo
 
   /* Autodetect first vector size we try.  */
   current_vector_size = 0;
-  targetm.vectorize.autovectorize_vector_sizes (_sizes);
+  targetm.vectorize.autovectorize_vector_sizes (_sizes,
+   

Re: [PATCH][PR90106] Builtin call transformation changes in cdce pass

[Jakub Jelinek]

On Fri, May 17, 2019 at 03:02:51PM +0800, JunMa wrote:
> 2019-05-17  Jun Ma  
> 
>     PR tree-optimization/90106
>     * gcc.dg/cdce3.c: New test.

Ok, thanks.

Jakub

Re: [PATCH] debug: make -feliminate-unused-debug-symbols the default [PR debug/86964]

[Thomas De Schampheleire]

Hi Richard,

El jue., 16 may. 2019 a las 14:41, Richard Biener
() escribió:
>
> On Thu, May 16, 2019 at 11:20 AM Thomas De Schampheleire
>  wrote:
> >
> > From: Thomas De Schampheleire 
> >
> > In addition to making -feliminate-unused-debug-symbols work for the DWARF
> > format (see [1]), make this option the default. This behavior was the case
> > before, e.g. under gcc 4.9.x.
> > [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=269925
>
> I have tested this patch and it causes a few FAILs, eventually hinting
> at implementation issues:
>
> === g++ tests ===
>
>
> Running target unix
> FAIL: g++.dg/debug/enum-2.C -gstabs -O2  scan-assembler JTI_MAX
> FAIL: g++.dg/debug/enum-2.C -gstabs -O3  scan-assembler JTI_MAX
> FAIL: g++.dg/debug/enum-2.C -gstabs+ -O2  scan-assembler JTI_MAX
> FAIL: g++.dg/debug/enum-2.C -gstabs+ -O3  scan-assembler JTI_MAX
> FAIL: g++.dg/debug/enum-2.C -gstabs+3 -O2  scan-assembler JTI_MAX
> FAIL: g++.dg/debug/enum-2.C -gstabs+3 -O3  scan-assembler JTI_MAX
> FAIL: g++.dg/debug/enum-2.C -gstabs3 -O2  scan-assembler JTI_MAX
> FAIL: g++.dg/debug/enum-2.C -gstabs3 -O3  scan-assembler JTI_MAX
>
> maybe expected (stabs)
>
> FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
> field_head_or
> dy_defn_fld_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
> field_head_or
> dy_defn_ptr_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
> field_head_or
> dy_defn_ref_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-any.C  -std=gnu++14  scan-assembler 
> field_head_or
> dy_defn_var_head_fld.*DW_AT_name
> ... more ...
> FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++14  scan-assembler 
> gstruct_
> head_ordy_defn_var_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++14  scan-assembler 
> gstruct_
> head_tmpl_defn_var_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++17  scan-assembler 
> gstruct_
> head_ordy_defn_var_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++17  scan-assembler 
> gstruct_
> head_tmpl_defn_var_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++98  scan-assembler 
> gstruct_
> head_ordy_defn_var_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-baseonly.C  -std=gnu++98
> scan-assembler gstruct_head_tmpl_defn_var_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-none.C  -std=gnu++14  scan-assembler
> gstruct_head_ordy_defn_var_head.*DW_AT_name
> FAIL: g++.dg/debug/dwarf2/fesd-none.C  -std=gnu++14  scan-assembler
> gstruct_head_tmpl_defn_var_head.*DW_AT_name
> ... more fesd-* testcases FAIL ...
> FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> scan-assembler-times  DW_AT_[^\\n\\r]*linkage_name 7
> FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> scan-assembler-times  DW_AT_specification 6
> FAIL: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
> scan-assembler-times 0x3[^\\n\\r]* DW_AT_inline 6
>
> C variants of the fesd-* testcases also FAIL.  Those testcases are
> huge, a quick look didn't
> reveal whether those are expected FAILs or not.


I tried reproducing these failures, using 'make bootstrap && make
check', but I see many many test failures:

=== gcc Summary ===

# of expected passes144268
# of unexpected failures113
# of unexpected successes28
# of expected failures593
# of unresolved testcases2
# of unsupported tests2279

=== g++ Summary ===

# of expected passes134673
# of unexpected failures137
# of expected failures527
# of unsupported tests5944

/home/tdescham/repo/contrib/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc
version 10.0.0 20190516 (experimental) (GCC)


Is it expected that 'master' (gcc 10) has such failures? Should I test
on another branch, if so which?
And is there a way to run only specific tests, e.g. the ones that you
pointed out?

Thanks,
Thomas

Re: [PATCH] Support again multiple --help options (PR other/90315).

[Martin Liška]

PING^2

On 5/10/19 3:42 PM, Martin Liška wrote:
> PING^1
> 
> On 5/3/19 12:59 PM, Martin Liška wrote:
>> Hi.
>>
>> The patch prints all values requested in multiple --help options.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2019-05-03  Martin Liska  
>>
>>  PR other/90315
>>  * opts-global.c (decode_options): Print help for all
>>  help_option_arguments.
>>  * opts.c (print_help): Add new argument.
>>  (common_handle_option): Remember all values into
>>  help_option_arguments.
>>  * opts.h (print_help): Add new argument.
>> ---
>>  gcc/opts-global.c | 4 ++--
>>  gcc/opts.c| 7 ---
>>  gcc/opts.h| 5 +++--
>>  3 files changed, 9 insertions(+), 7 deletions(-)
>>
>>
> 

Re: [PATCH 0/3] Small clean up of profile_{count,probability}

[Martin Liška]

PING^1

On 4/29/19 1:01 PM, marxin wrote:
> The patch makes couple of adjustements:
> 1) I changed enum values to use capital letters. It's aligned with
>our coding style and it makes the code more readable. E.g.
>profile_quality::profile_guessed_local
>vs. static profile_probability guessed_always ()
> 
> 2) I removed usage of fully qualified names.
> 3) I added vertical spaces to separate different functions (operators).
> 
> Survives bootstrap and tests on x86_64-linux-gnu.
> 
> Ready for trunk after 9.1 release?
> Thanks,
> Martin
> 
> marxin (3):
>   Use cappital letters for enum value names.
>   Do not use full qualified names if possible.
>   Add vertical spacing in order to separate functions.
> 
>  gcc/profile-count.c |  76 +--
>  gcc/profile-count.h | 320 +---
>  2 files changed, 220 insertions(+), 176 deletions(-)
> 

Re: [PATCH v3 2/3] Add predict_doloop_p target hook

[Kewen.Lin]

Hi Segher,

on 2019/5/17 下午2:49, Segher Boessenkool wrote:
> Hi Kewen,
> 
> On Thu, May 16, 2019 at 10:35:30PM -0500, li...@linux.ibm.com wrote:
>> 2) For the other part of target invalid stmt check, as the
>> hook invalid_within_doloop grep data shows, no all targets
>> need to check whether invalid instructions exist in doloop.
>> If we scan all stmts as generic, it can waste time for those
>> targets which don't need to check.
> 
> So make the default version of the hook NULL, and only run the hook if
> non-null?  There are many examples of this.
> 

Good tips!

>>  Besides, the scope of
>> the current check on SWITCH in rs6000 hook is wide, later
>> if we want it more exact, we may need to check more stmts
>> instead of single.  To let target hook scan the BBs/stmts
>> by itself is also more flexible.
> 
> If we'll need that flexibility, okay.
> 
>> +static bool
>> +invalid_insn_for_doloop_p (struct loop *loop)
>> +{
>> +  basic_block *body = get_loop_body (loop);
>> +  gimple_stmt_iterator gsi;
>> +
>> +  for (unsigned i = 0; i < loop->num_nodes; i++)
>> +for (gsi = gsi_start_bb (body[i]); !gsi_end_p (gsi); gsi_next ())
>> +  {
>> +gimple *stmt = gsi_stmt (gsi);
>> +if (is_gimple_call (stmt) && !gimple_call_internal_p (stmt)
>> +&& !is_inexpensive_builtin (gimple_call_fndecl (stmt)))
>> +  {
>> +if (dump_file && (dump_flags & TDF_DETAILS))
>> +  fprintf (dump_file,
>> +   "predict doloop failure due to finding call.\n");
> 
> Should this really be for -all dumps only?  "X failed because Y" is often
> very interesting info -- and it is not much output.
> 

OK, I thought users can firstly check the predict_doloop result whether
meet theirs' expectation and use -details dump for further check why.
And IVOPTs also uses "TDF_DETAILS" for dumping much.

Just remove the flags check? or which TDF level you suggested?

> (Please start the line with a capital if you end it with a period :-) )
> 

Some contexts seems missing for this?  Or it's for dumping string?

>> +  if (dump_file && (dump_flags & TDF_DETAILS))
>> +fprintf (dump_file, "predict doloop failure due to"
>> +"no innermost.\n");
> 
> If you paste strings (which is fine for debug output), you still need a
> space between words ;-)
> 

Good catches here and later!  :)

>> +@deftypefn {Target Hook} bool TARGET_PREDICT_DOLOOP_P (struct loop 
>> *@var{loop})
>> +Return true if we can predict it is possible to use low-overhead loops
>> +for a particular loop.  The parameter @var{loop} is a pointer to the loop
> 
> "... use a low-overhead loop ..."
> 
>> +which is going to be checked.  This target hook is required only when the
> 
> Just remove the whole "which is going to be checked" part?
> 
>> +target supports low-overhead loops, and will help some earlier middle-end
>> +passes to make some decisions.
> 
> Is it *required* when the target has doloops?  And what will happen if you
> do not define this hook, either if or you have doloops or if you don't?
> 
> Hook documentation often ends "The default version of this hook returns..."
> which neatly answers all this.
> 

OK, will update it with "the default version of this hook return false."

>> +  /* For now, we only consider these two RTX classes, to match what we
>> + get in doloop_optimize, excluding operations like zero/sign extend.  */
> 
> The indentation is broken here.
> 

Good catch, contrib/check_GNU_style.sh did NOT catch this.  :(


Thanks,
Kewen

>> +  if (dump_file && (dump_flags & TDF_DETAILS))
>> +fprintf (dump_file, "predict doloop failure due to"
>> +"target specific checks.\n");
> 
> Missing space as well (and more later, please check all).
>
> 
> Segher
> 

Re: [PATCH] x86-64: Add vararg ABI tests

[Uros Bizjak]

On Thu, May 16, 2019 at 10:10 PM H.J. Lu  wrote:
>
> We can scan stack for return address to get vector arguments passed on
> stack.
>
> * gcc.target/x86_64/abi/test_varargs-m128.c: New file.
> * gcc.target/x86_64/abi/avx/test_varargs-m256.c: Likewise.
> * gcc.target/x86_64/abi/avx512f/test_varargs-m512.c: Likewise.

Bootstrapped and regression tested on which target? Does x32 passes the test?

> +  /* Check __m256 arguments passed on stack.  */
> +  argp = (__m256 *) (((char *) fp) + 8);

It took me a while to figure out that RA slot is skipped here. Please
add some comment, maybe:

  /* Skip return address stack slot.  */
  argp = (__m256 *) (((char *) fp) + 8);

  /* Check __m256 arguments passed on stack.  */
  compare (values.i4, argp[0], __m256);

Uros.

> ---
>  .../x86_64/abi/avx/test_varargs-m256.c| 102 +
>  .../x86_64/abi/avx512f/test_varargs-m512.c| 102 +
>  .../gcc.target/x86_64/abi/test_varargs-m128.c | 108 ++
>  3 files changed, 312 insertions(+)
>  create mode 100644 
> gcc/testsuite/gcc.target/x86_64/abi/avx/test_varargs-m256.c
>  create mode 100644 
> gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_varargs-m512.c
>  create mode 100644 gcc/testsuite/gcc.target/x86_64/abi/test_varargs-m128.c
>
> diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx/test_varargs-m256.c 
> b/gcc/testsuite/gcc.target/x86_64/abi/avx/test_varargs-m256.c
> new file mode 100644
> index 000..d1bcf865487
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/x86_64/abi/avx/test_varargs-m256.c
> @@ -0,0 +1,102 @@
> +/* Test variable number of 256-bit vector arguments passed to functions.  */
> +
> +#include 
> +#include "avx-check.h"
> +#include "args.h"
> +
> +struct IntegerRegisters iregs;
> +struct FloatRegisters fregs;
> +
> +/* This struct holds values for argument checking.  */
> +struct
> +{
> +  YMM_T i0, i1, i2, i3, i4, i5, i6, i7, i8, i9;
> +} values;
> +
> +char *pass;
> +int failed = 0;
> +
> +#undef assert
> +#define assert(c) do { \
> +  if (!(c)) {failed++; printf ("failed %s\n", pass); } \
> +} while (0)
> +
> +#define compare(X1,X2,T) do { \
> +  assert (memcmp (, , sizeof (T)) == 0); \
> +} while (0)
> +
> +void
> +fun_check_passing_m256_varargs (__m256 i0, __m256 i1, __m256 i2,
> +   __m256 i3, ...)
> +{
> +  /* Check argument values.  */
> +  void **fp = __builtin_frame_address (0);
> +  void *ra = __builtin_return_address (0);
> +  __m256 *argp;
> +
> +  compare (values.i0, i0, __m256);
> +  compare (values.i1, i1, __m256);
> +  compare (values.i2, i2, __m256);
> +  compare (values.i3, i3, __m256);
> +
> +  /* Get the pointer to the return address on stack.  */
> +  while (*fp != ra)
> +fp++;
> +
> +  /* Check __m256 arguments passed on stack.  */
> +  argp = (__m256 *) (((char *) fp) + 8);
> +  compare (values.i4, argp[0], __m256);
> +  compare (values.i5, argp[1], __m256);
> +  compare (values.i6, argp[2], __m256);
> +  compare (values.i7, argp[3], __m256);
> +  compare (values.i8, argp[4], __m256);
> +  compare (values.i9, argp[5], __m256);
> +
> +  /* Check register contents.  */
> +  compare (fregs.ymm0, ymm_regs[0], __m256);
> +  compare (fregs.ymm1, ymm_regs[1], __m256);
> +  compare (fregs.ymm2, ymm_regs[2], __m256);
> +  compare (fregs.ymm3, ymm_regs[3], __m256);
> +}
> +
> +#define def_check_int_passing_varargs(_i0, _i1, _i2, _i3, _i4, _i5, \
> + _i6, _i7, _i8, _i9, \
> + _func, TYPE) \
> +  values.i0.TYPE[0] = _i0; \
> +  values.i1.TYPE[0] = _i1; \
> +  values.i2.TYPE[0] = _i2; \
> +  values.i3.TYPE[0] = _i3; \
> +  values.i4.TYPE[0] = _i4; \
> +  values.i5.TYPE[0] = _i5; \
> +  values.i6.TYPE[0] = _i6; \
> +  values.i7.TYPE[0] = _i7; \
> +  values.i8.TYPE[0] = _i8; \
> +  values.i9.TYPE[0] = _i9; \
> +  clear_struct_registers; \
> +  fregs.F0.TYPE[0] = _i0; \
> +  fregs.F1.TYPE[0] = _i1; \
> +  fregs.F2.TYPE[0] = _i2; \
> +  fregs.F3.TYPE[0] = _i3; \
> +  WRAP_CALL(_func) (_i0, _i1, _i2, _i3, _i4, _i5, _i6, _i7, _i8, _i9);
> +
> +void
> +test_m256_varargs (void)
> +{
> +  __m256 x[10];
> +  int i;
> +  for (i = 0; i < 10; i++)
> +x[i] = (__m256){32+i, 0, 0, 0, 0, 0, 0, 0};
> +  pass = "m256-varargs";
> +  def_check_int_passing_varargs (x[0], x[1], x[2], x[3], x[4], x[5],
> +x[6], x[7], x[8], x[9],
> +fun_check_passing_m256_varargs,
> +_m256);
> +}
> +
> +void
> +avx_test (void)
> +{
> +  test_m256_varargs ();
> +  if (failed)
> +abort ();
> +}
> diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_varargs-m512.c 
> b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_varargs-m512.c
> new file mode 100644
> index 000..328f76de3df
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_varargs-m512.c
> @@ -0,0 +1,102 @@
> +/* Test variable number of 512-bit vector 

Re: [PATCH][PR90106] Builtin call transformation changes in cdce pass

[JunMa]

在 2019/5/17 下午2:34, Jakub Jelinek 写道:

On Fri, May 17, 2019 at 02:24:22PM +0800, JunMa wrote:

2019-05-17  Jun Ma 

Two spaces before < rather than one.


     PR tree-optimization/90106
     * gcc.dg/cdce3.c: New test.
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cdce3.c
@@ -0,0 +1,12 @@
+/* { dg-do  compile } */

Just use one space instead of two.


+/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details -fdump-tree-optimized  
-lm" } */

For compile time test, no need to add "  -lm" (well, no need to add it even
for link/run tests).


+/* { dg-final { scan-tree-dump "cdce3.c:10: .* function call is shrink-wrapped into error 
conditions\." "cdce" } } */

Please use \[^\n\r]* instead of .*, you don't want newlines matched in
there.


+/* { dg-final { scan-tree-dump "sqrtf \\(\[^\n\r]*\\); \\\[tail call\\\]" 
"optimized" } } */
+
+#include 

Wouldn't it be better to just declare it yourself:
float sqrtf (float);
?
You really don't know what the target math.h includes.


+
+float foo ( float x )
+{
+  return sqrtf( x );
+}
+
--
1.8.3.1



Thanks for review so carefully. Update the patch based on your suggestion.

Regards
Jun

gcc/testsuite/ChangeLog

2019-05-17  Jun Ma  

    PR tree-optimization/90106
    * gcc.dg/cdce3.c: New test.



Jakub



---
 gcc/testsuite/gcc.dg/cdce3.c | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/cdce3.c

diff --git a/gcc/testsuite/gcc.dg/cdce3.c b/gcc/testsuite/gcc.dg/cdce3.c
new file mode 100644
index 000..8a74379
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cdce3.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
-fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump "cdce3.c:9: \[^\n\r]* function call is 
shrink-wrapped into error conditions\." "cdce" } } */
+/* { dg-final { scan-tree-dump "sqrtf \\(\[^\n\r]*\\); \\\[tail call\\\]" 
"optimized" } } */
+
+float sqrtf (float);
+float foo (float x)
+{
+  return sqrtf (x);
+}
+
-- 
1.8.3.1

Re: [PATCH v3 2/3] Add predict_doloop_p target hook

[Segher Boessenkool]

On Fri, May 17, 2019 at 03:30:41PM +1000, Kugan Vivekanandarajah wrote:
> On Fri, 17 May 2019 at 13:37,  wrote:
> > +  if (GET_CODE (body) == SET)
> > +   {
> > + rtx set_val = XEXP (body, 1);
> > + enum rtx_code code = GET_CODE (set_val);
> > + enum rtx_class cls = GET_RTX_CLASS (code);
> > + /* For now, we only consider these two RTX classes, to match what 
> > we
> > +get in doloop_optimize, excluding operations like zero/sign 
> > extend.  */
> > + if (cls == RTX_BIN_ARITH || cls == RTX_COMM_ARITH)
> > +   cost += set_src_cost (set_val, GET_MODE (set_val), speed);
> Cant you have PARALLEL with SET here?

So it should use single_set and SET_SRC?  Yeah I guess.

For Power, we don't have many PARALLELs in freshly expanded code, so it
doesn't make much difference for us.

> > +  if (cost > max_cost)
> > +return true;
> Maybe it is better to bailout early if the limit is reached instead of
> doing it outside the loop?

That won't be more complicated code here, so yes let's do that.


Segher

Re: [PATCH v3 2/3] Add predict_doloop_p target hook

[Segher Boessenkool]

Hi Kewen,

On Thu, May 16, 2019 at 10:35:30PM -0500, li...@linux.ibm.com wrote:
> 2) For the other part of target invalid stmt check, as the
> hook invalid_within_doloop grep data shows, no all targets
> need to check whether invalid instructions exist in doloop.
> If we scan all stmts as generic, it can waste time for those
> targets which don't need to check.

So make the default version of the hook NULL, and only run the hook if
non-null?  There are many examples of this.

>  Besides, the scope of
> the current check on SWITCH in rs6000 hook is wide, later
> if we want it more exact, we may need to check more stmts
> instead of single.  To let target hook scan the BBs/stmts
> by itself is also more flexible.

If we'll need that flexibility, okay.

> +static bool
> +invalid_insn_for_doloop_p (struct loop *loop)
> +{
> +  basic_block *body = get_loop_body (loop);
> +  gimple_stmt_iterator gsi;
> +
> +  for (unsigned i = 0; i < loop->num_nodes; i++)
> +for (gsi = gsi_start_bb (body[i]); !gsi_end_p (gsi); gsi_next ())
> +  {
> + gimple *stmt = gsi_stmt (gsi);
> + if (is_gimple_call (stmt) && !gimple_call_internal_p (stmt)
> + && !is_inexpensive_builtin (gimple_call_fndecl (stmt)))
> +   {
> + if (dump_file && (dump_flags & TDF_DETAILS))
> +   fprintf (dump_file,
> +"predict doloop failure due to finding call.\n");

Should this really be for -all dumps only?  "X failed because Y" is often
very interesting info -- and it is not much output.

(Please start the line with a capital if you end it with a period :-) )

> +  if (dump_file && (dump_flags & TDF_DETAILS))
> + fprintf (dump_file, "predict doloop failure due to"
> + "no innermost.\n");

If you paste strings (which is fine for debug output), you still need a
space between words ;-)

> +@deftypefn {Target Hook} bool TARGET_PREDICT_DOLOOP_P (struct loop 
> *@var{loop})
> +Return true if we can predict it is possible to use low-overhead loops
> +for a particular loop.  The parameter @var{loop} is a pointer to the loop

"... use a low-overhead loop ..."

> +which is going to be checked.  This target hook is required only when the

Just remove the whole "which is going to be checked" part?

> +target supports low-overhead loops, and will help some earlier middle-end
> +passes to make some decisions.

Is it *required* when the target has doloops?  And what will happen if you
do not define this hook, either if or you have doloops or if you don't?

Hook documentation often ends "The default version of this hook returns..."
which neatly answers all this.

> +   /* For now, we only consider these two RTX classes, to match what we
> +  get in doloop_optimize, excluding operations like zero/sign extend.  */

The indentation is broken here.

> +  if (dump_file && (dump_flags & TDF_DETAILS))
> + fprintf (dump_file, "predict doloop failure due to"
> + "target specific checks.\n");

Missing space as well (and more later, please check all).


Segher

Re: [PATCH][PR90106] Builtin call transformation changes in cdce pass

[Jakub Jelinek]

On Fri, May 17, 2019 at 02:24:22PM +0800, JunMa wrote:
> 2019-05-17  Jun Ma 

Two spaces before < rather than one.

>     PR tree-optimization/90106
>     * gcc.dg/cdce3.c: New test.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/cdce3.c
> @@ -0,0 +1,12 @@
> +/* { dg-do  compile } */

Just use one space instead of two.

> +/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
> -fdump-tree-optimized  -lm" } */

For compile time test, no need to add "  -lm" (well, no need to add it even
for link/run tests).

> +/* { dg-final { scan-tree-dump "cdce3.c:10: .* function call is 
> shrink-wrapped into error conditions\." "cdce" } } */

Please use \[^\n\r]* instead of .*, you don't want newlines matched in
there.

> +/* { dg-final { scan-tree-dump "sqrtf \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> "optimized" } } */
> +
> +#include 

Wouldn't it be better to just declare it yourself:
float sqrtf (float);
?
You really don't know what the target math.h includes.

> +
> +float foo ( float x )
> +{
> +  return sqrtf( x );
> +}
> +
> -- 
> 1.8.3.1
> 

Jakub

Re: [PATCH][PR90106] Builtin call transformation changes in cdce pass

[JunMa]

在 2019/5/17 上午11:09, JunMa 写道:

在 2019/5/17 上午6:04, Jakub Jelinek 写道:

On Thu, May 16, 2019 at 11:39:38PM +0200, Jakub Jelinek wrote:

One possibility is to add -fdump-tree-optimized and scan for
/* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail 
call\\\]" "optimized" } } */

resp.
/* { dg-final { scan-tree-dump "log \\(\[^\n\r]*\\); \\\[tail 
call\\\]" "optimized" } } */

Here it is in patch form.

That said, I'm not convinced your patch does what you wanted, because
comparing a month old trunk with today's trunk generates the same 
assembly
except for .ident, generates as many [tail call] lines in *.optimized 
dump
as before, emits the same number of jmp\tpow and jmp\tlog 
instructions as

before (one in a separate routine).



Thanks for point out the mistake and fix it.

For these two tests, cdce pass doesn't transform the builtin math 
functions in foo

with or without the patch because they cannot use internal functions.

I'll add another testcase to verify the patch.



Here is the new testcase.

The sqrtf function call keeps as tailcall with the patch
but not without the patch. For more details, you can read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106.

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

Regards
Jun


gcc/testsuite/ChangeLog

2019-05-17  Jun Ma 

    PR tree-optimization/90106
    * gcc.dg/cdce3.c: New test.




Regards
Jun



But at least the tests aren't UNSUPPORTED anymore.

2019-05-16  Jakub Jelinek  

PR tree-optimization/90106
* gcc.dg/cdce1.c: Don't scan-assembler, instead 
-fdump-tree-optimized

and scan-tree-dump for tail call.
* gcc.dg/cdce2.c: Likewise.

--- gcc/testsuite/gcc.dg/cdce1.c.jj    2019-05-16 11:28:22.750177582 
+0200

+++ gcc/testsuite/gcc.dg/cdce1.c    2019-05-16 23:50:23.618450891 +0200
@@ -1,9 +1,9 @@
-/* { dg-do  run  } */
-/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details -lm" } */
+/* { dg-do run } */
+/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
-fdump-tree-optimized -lm" } */

  /* { dg-require-effective-target int32plus } */
-/* { dg-final { scan-tree-dump  "cdce1.c:17: .* function call is 
shrink-wrapped into error conditions\."  "cdce" } } */

-/* { dg-final { scan-assembler "jmp pow" } } */
  /* { dg-require-effective-target large_double } */
+/* { dg-final { scan-tree-dump "cdce1.c:17: .* function call is 
shrink-wrapped into error conditions\." "cdce" } } */
+/* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail 
call\\\]" "optimized" } } */

    #include 
  #include 
--- gcc/testsuite/gcc.dg/cdce2.c.jj    2019-05-16 11:28:22.781177075 
+0200

+++ gcc/testsuite/gcc.dg/cdce2.c    2019-05-16 23:50:58.505880845 +0200
@@ -1,8 +1,8 @@
-/* { dg-do  run  } */
+/* { dg-do run } */
  /* { dg-skip-if "doubles are floats" { "avr-*-*" } } */
-/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details -lm" } */
-/* { dg-final { scan-tree-dump  "cdce2.c:16: .* function call is 
shrink-wrapped into error conditions\." "cdce" } } */

-/* { dg-final { scan-assembler "jmp log" } } */
+/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
-fdump-tree-optimized -lm" } */
+/* { dg-final { scan-tree-dump "cdce2.c:16: .* function call is 
shrink-wrapped into error conditions\." "cdce" } } */
+/* { dg-final { scan-tree-dump "log \\(\[^\n\r]*\\); \\\[tail 
call\\\]" "optimized" } } */

     #include 
  #include 


Jakub




---
 gcc/testsuite/gcc.dg/cdce3.c | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/cdce3.c

diff --git a/gcc/testsuite/gcc.dg/cdce3.c b/gcc/testsuite/gcc.dg/cdce3.c
new file mode 100644
index 000..0062c4f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cdce3.c
@@ -0,0 +1,12 @@
+/* { dg-do  compile } */
+/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
-fdump-tree-optimized  -lm" } */
+/* { dg-final { scan-tree-dump "cdce3.c:10: .* function call is shrink-wrapped 
into error conditions\." "cdce" } } */
+/* { dg-final { scan-tree-dump "sqrtf \\(\[^\n\r]*\\); \\\[tail call\\\]" 
"optimized" } } */
+
+#include 
+
+float foo ( float x )
+{
+  return sqrtf( x );
+}
+
-- 
1.8.3.1

Re: [PATCH] i386: Enable MMX intrinsics without SSE/SSE2/SSSE3

[Uros Bizjak]

On Thu, May 16, 2019 at 11:59 PM H.J. Lu  wrote:
>
> Since MMX intrinsics are marked with SSE/SSE2/SSSE3 for SSE emulation,
> enable them without SSE/SSE2/SSSE3 if MMX is enabled.
>
> Restore TARGET_3DNOW check, which was changed to TARGET_3DNOW_A by
> revision 271235.
>
> gcc/
>
> PR target/90497
> * config/i386/i386-expand.c (ix86_expand_builtin): Enable MMX
> intrinsics without SSE/SSE2/SSSE3.
> * config/i386/mmx.md (mmx_uavgv8qi3): Restore TARGET_3DNOW
> check.
> (*mmx_uavgv8qi3): Likewise.

OK with a small nit.

Thanks,
Uros.

>
> gcc/testsuite/
>
> PR target/90497
> * gcc.target/i386/pr90497-1.c: New test.
> * gcc.target/i386/pr90497-2.c: Likewise.
> ---
>  gcc/config/i386/i386-expand.c |  6 --
>  gcc/config/i386/mmx.md|  4 ++--
>  gcc/testsuite/gcc.target/i386/pr90497-1.c | 12 
>  gcc/testsuite/gcc.target/i386/pr90497-2.c | 11 +++
>  4 files changed, 29 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr90497-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr90497-2.c
>
> diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> index df035607fa7..35aadefdef3 100644
> --- a/gcc/config/i386/i386-expand.c
> +++ b/gcc/config/i386/i386-expand.c
> @@ -10937,8 +10937,10 @@ ix86_expand_builtin (tree exp, rtx target, rtx 
> subtarget,
>&& (isa & (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4)) != 0)
>  isa |= (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4);
>/* Use SSE/SSE2/SSSE3 to emulate MMX intrinsics in 64-bit mode when
> - MMX is disabled.  */
> -  if (TARGET_MMX_WITH_SSE)
> + MMX is disabled.  NB: Since MMX intrinsics are marked with
> + SSE/SSE2/SSSE3, enable them without SSE/SSE2/SSSE3 if MMX is
> + enabled.  */
> +  if (TARGET_MMX_WITH_SSE || TARGET_MMX)

Please use  "TARGET_MMX || TARGET_MMX_WITH_SSE" as is the case with
all these conditions.

>  {
>if (((bisa & (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_MMX))
>== (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_MMX))
> diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
> index 29bcf931836..adad950fa04 100644
> --- a/gcc/config/i386/mmx.md
> +++ b/gcc/config/i386/mmx.md
> @@ -1745,7 +1745,7 @@
>   (const_int 1) (const_int 1)]))
> (const_int 1]
>"(TARGET_MMX || TARGET_MMX_WITH_SSE)
> -   && (TARGET_SSE || TARGET_3DNOW_A)"
> +   && (TARGET_SSE || TARGET_3DNOW)"
>"ix86_fixup_binary_operands_no_copy (PLUS, V8QImode, operands);")
>
>  (define_insn "*mmx_uavgv8qi3"
> @@ -1764,7 +1764,7 @@
>   (const_int 1) (const_int 1)]))
> (const_int 1]
>"(TARGET_MMX || TARGET_MMX_WITH_SSE)
> -   && (TARGET_SSE || TARGET_3DNOW_A)
> +   && (TARGET_SSE || TARGET_3DNOW)
> && ix86_binary_operator_ok (PLUS, V8QImode, operands)"
>  {
>/* These two instructions have the same operation, but their encoding
> diff --git a/gcc/testsuite/gcc.target/i386/pr90497-1.c 
> b/gcc/testsuite/gcc.target/i386/pr90497-1.c
> new file mode 100644
> index 000..ed6ded7efbc
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr90497-1.c
> @@ -0,0 +1,12 @@
> +/* PR target/90497 */
> +/* { dg-do compile } */
> +/* { dg-options "-mno-sse -mmmx" { target ia32 } } */
> +/* { dg-options "-mno-mmx" { target { ! ia32 } } } */
> +
> +typedef char __v8qi __attribute__ ((__vector_size__ (8)));
> +
> +__v8qi
> +foo (__v8qi x, __v8qi y)
> +{
> +  return __builtin_ia32_pcmpeqb (x, y);
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr90497-2.c 
> b/gcc/testsuite/gcc.target/i386/pr90497-2.c
> new file mode 100644
> index 000..99ee5756b76
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr90497-2.c
> @@ -0,0 +1,11 @@
> +/* PR target/90497 */
> +/* { dg-do compile { target ia32 } } */
> +/* { dg-options "-mno-sse -m3dnow" } */
> +
> +typedef char __v8qi __attribute__ ((__vector_size__ (8)));
> +
> +__v8qi
> +foo (__v8qi x, __v8qi y)
> +{
> +  return __builtin_ia32_pavgusb (x, y);
> +}
> --
> 2.20.1
>

Re: [PATCH v3 2/3] Add predict_doloop_p target hook

[Kewen.Lin]

on 2019/5/17 下午1:30, Kugan Vivekanandarajah wrote:
> Hi,
> 
> On Fri, 17 May 2019 at 13:37,  wrote:
>>
>> From: Kewen Lin 
>>
>> +/* Check whether number of iteration computation is too costly for doloop
>> +   transformation.  It expands the gimple sequence to equivalent RTL insn
>> +   sequence, then evaluate the cost.
>> +
>> +   Return true if it's costly, otherwise return false.  */
>> +
>> +static bool
>> +costly_iter_for_doloop_p (struct loop *loop, tree niters)
>> +{
>> +  tree type = TREE_TYPE (niters);
>> +  unsigned cost = 0;
>> +  bool speed = optimize_loop_for_speed_p (loop);
>> +  int regno = LAST_VIRTUAL_REGISTER + 1;
>> +  walk_tree (, prepare_decl_rtl, , NULL);
>> +  start_sequence ();
>> +  expand_expr (niters, NULL_RTX, TYPE_MODE (type), EXPAND_NORMAL);
>> +  rtx_insn *seq = get_insns ();
>> +  end_sequence ();
>> +
>> +  for (; seq; seq = NEXT_INSN (seq))
>> +{
>> +  if (!INSN_P (seq))
>> +   continue;
>> +  rtx body = PATTERN (seq);
>> +  if (GET_CODE (body) == SET)
>> +   {
>> + rtx set_val = XEXP (body, 1);
>> + enum rtx_code code = GET_CODE (set_val);
>> + enum rtx_class cls = GET_RTX_CLASS (code);
>> + /* For now, we only consider these two RTX classes, to match what 
>> we
>> +get in doloop_optimize, excluding operations like zero/sign extend. 
>>  */
>> + if (cls == RTX_BIN_ARITH || cls == RTX_COMM_ARITH)
>> +   cost += set_src_cost (set_val, GET_MODE (set_val), speed);
> Cant you have PARALLEL with SET here?
> 

Thanks for catching, updated it with single_set for PARALLEL.

-  if (!INSN_P (seq))
-   continue;
-  rtx body = PATTERN (seq);
-  if (GET_CODE (body) == SET)
+  rtx set = single_set (seq);
+  if (set != NULL_RTX)
{
- rtx set_val = XEXP (body, 1);
+ rtx set_val = XEXP (set, 1);


>> +   }
>> +}
>> +  unsigned max_cost
>> += COSTS_N_INSNS (PARAM_VALUE (PARAM_MAX_ITERATIONS_COMPUTATION_COST));
>> +  if (cost > max_cost)
>> +return true;
> Maybe it is better to bailout early if the limit is reached instead of
> doing it outside the loop?
> 

Good point.  Based on those cases I've checked so far, most of them are less
than max cost, it looks most cases won't return early.  Too many early checks
seem inefficient to some extent.  Does it make sense?
And we have to collect some statistics for sure. :)


Thanks,
Kewen

> Thanks,
> Kugan
> 
>> +
>> +  return false;
>> +}
>> +
>> +/* Predict whether the given loop will be transformed in the RTL
>> +   doloop_optimize pass.  Attempt to duplicate as many doloop_optimize 
>> checks
>> +   as possible.  This is only for target independent checks, see
>> +   targetm.predict_doloop_p for the target dependent ones.
>> +
>> +   Some RTL specific checks seems unable to be checked in gimple, if any new
>> +   checks or easy checks _are_ missing here, please add them.  */
>> +
>> +static bool
>> +generic_predict_doloop_p (struct ivopts_data *data)
>> +{
>> +  struct loop *loop = data->current_loop;
>> +
>> +  /* Call target hook for target dependent checks.  */
>> +  if (!targetm.predict_doloop_p (loop))
>> +{
>> +  if (dump_file && (dump_flags & TDF_DETAILS))
>> +   fprintf (dump_file, "predict doloop failure due to"
>> +   "target specific checks.\n");
>> +  return false;
>> +}
>> +
>> +  /* Similar to doloop_optimize, check iteration description to know it's
>> + suitable or not.  */
>> +  edge exit = loop_latch_edge (loop);
>> +  struct tree_niter_desc *niter_desc = niter_for_exit (data, exit);
>> +  if (niter_desc == NULL)
>> +{
>> +  if (dump_file && (dump_flags & TDF_DETAILS))
>> +   fprintf (dump_file, "predict doloop failure due to"
>> +   "unexpected niters.\n");
>> +  return false;
>> +}
>> +
>> +  /* Similar to doloop_optimize, check whether iteration count too small
>> + and not profitable.  */
>> +  HOST_WIDE_INT est_niter = get_estimated_loop_iterations_int (loop);
>> +  if (est_niter == -1)
>> +est_niter = get_likely_max_loop_iterations_int (loop);
>> +  if (est_niter >= 0 && est_niter < 3)
>> +{
>> +  if (dump_file && (dump_flags & TDF_DETAILS))
>> +   fprintf (dump_file,
>> +"predict doloop failure due to"
>> +"too few iterations (%u).\n",
>> +(unsigned int) est_niter);
>> +  return false;
>> +}
>> +
>> +  /* Similar to doloop_optimize, check whether number of iterations too 
>> costly
>> + to compute.  */
>> +  if (costly_iter_for_doloop_p (loop, niter_desc->niter))
>> +{
>> +  if (dump_file && (dump_flags & TDF_DETAILS))
>> +   fprintf (dump_file, "predict doloop failure due to"
>> +   "costly niter computation.\n");
>> +  return false;
>> +}
>> +
>> +  return true;
>> +}
>> +
>>  /* Determines cost of the computation of EXPR.  */
>>
>>  static unsigned
>> --
>> 2.7.4