Re: Remove ca.mirror.babylon.network

[Gerald Pfeifer]

On Sun, 16 Jul 2017, Tim Semeijn wrote:
> We will soon decommission our Canadian mirror due to restructuring.
> Please remove the following server from the mirror list:
> 
> ca.mirror.babylon.network/gcc

Thank for you the head-up, Tim.  I applied the patch below to make
this change accordingly.

> Our French mirrors will remain active.

Good to know; kept in place.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.243
diff -u -r1.243 mirrors.html
--- mirrors.html22 Apr 2017 13:47:58 -  1.243
+++ mirrors.html16 Jul 2017 05:37:55 -
@@ -19,11 +19,6 @@
 -->
 Canada: http://gcc.parentingamerica.com;>http://gcc.parentingamerica.com, 
thanks to James Miller (jmiller at parentingamerica.com).
 Canada: http://gcc.skazkaforyou.com;>http://gcc.skazkaforyou.com, thanks to 
Sergey Ivanov (mirrors at skazkaforyou.com)
-Canada, Quebec:
-  http://ca.mirror.babylon.network/gcc/;>http://ca.mirror.babylon.network/gcc/
 |
-  ftp://ca.mirror.babylon.network/gcc/;>ftp://ca.mirror.babylon.network/gcc/
 |
-  rsync://ca.mirror.babylon.network/gcc/,
-  thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/;>ftp.lip6.fr, thanks to ftpmaint at 
lip6.fr
 France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/;>ftp.irisa.fr, thanks 
to ftpmaint at irisa.fr
 France, Gravelines:

[PATCH 4/6] lra-assigns.c: give up on qsort checking in assign_by_spills

[Alexander Monakov]

The reload_pseudo_compare_func comparator, when used from assign_by_spills,
can be non-transitive, indicating A < B < C < A if both A and C satisfy
!bitmap_bit_p (_reload_pseudos, rAC), but B does not.

This function was originally a proper comparator, and the problematic
clause was added to fix PR 57878:
https://gcc.gnu.org/ml/gcc-patches/2013-07/msg00732.html

That the comparator is invalid implies that that PR, if it still exists,
can reappear (but probably under more complicated circumstances).

This looks like a sensitive area, so disabling checking is the only
obvious approach.

* lra-assigns.c (reload_pseudo_compare_func): Add a FIXME.
(assign_by_spills): Use non-checking qsort.
---
 gcc/lra-assigns.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/lra-assigns.c b/gcc/lra-assigns.c
index 2aadeef..a67d1a6 100644
--- a/gcc/lra-assigns.c
+++ b/gcc/lra-assigns.c
@@ -217,6 +217,7 @@ reload_pseudo_compare_func (const void *v1p, const void 
*v2p)
   /* The code below executes rarely as nregs == 1 in most cases.
 So we should not worry about using faster data structures to
 check reload pseudos.  */
+  /* FIXME this makes comparator non-transitive and thus invalid.  */
   && ! bitmap_bit_p (_reload_pseudos, r1)
   && ! bitmap_bit_p (_reload_pseudos, r2))
 return diff;
@@ -1384,7 +1385,7 @@ assign_by_spills (void)
   bitmap_ior_into (_reload_pseudos, _optional_reload_pseudos);
   for (iter = 0; iter <= 1; iter++)
 {
-  qsort (sorted_pseudos, n, sizeof (int), reload_pseudo_compare_func);
+  qsort_nochk (sorted_pseudos, n, sizeof (int), 
reload_pseudo_compare_func);
   nfails = 0;
   for (i = 0; i < n; i++)
{
-- 
1.8.3.1

[PATCH 6/6] qsort comparator consistency checking

[Alexander Monakov]

This is the updated qsort comparator verifier.

Since we have vec::qsort(cmp), the patch uses the macro argument counting
trick to redirect only the four-argument invocations of qsort to qsort_chk.
I realize that won't win much sympathies, but a patch doing mass-renaming
of qsort in the whole GCC codebase would win even fewer, I suspect.

The macro ENABLE_FULL_QSORT_CHECKING could be used to enable full O(n^2)
checking, but there's no accompanying configure.ac change.  I'm not sure
that would be useful in practice, so I'd rather turn it into #if 0.

The suppression in genmodes was needed because it's not linked with vec.o.

* genmodes.c (calc_wider_mode): Suppress qsort macro.
* system.h [CHECKING_P] (qsort): Redirect to qsort_chk.
(qsort_nochk): New macro.
(qsort_chk): Declare.
(qsort_disable_checking): Declare.
* vec.c (qsort_chk_error): New static function.
(qsort_disable_checking): Define.
(qsort_chk): New function.
---
 gcc/genmodes.c |  2 +-
 gcc/system.h   | 11 +++
 gcc/vec.c  | 95 ++
 3 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/gcc/genmodes.c b/gcc/genmodes.c
index f7eaeef..01a0e65 100644
--- a/gcc/genmodes.c
+++ b/gcc/genmodes.c
@@ -880,7 +880,7 @@ calc_wider_mode (void)
  for (i = 0, m = modes[c]; m; i++, m = m->next)
sortbuf[i] = m;
 
- qsort (sortbuf, i, sizeof (struct mode_data *), cmp_modes);
+ (qsort) (sortbuf, i, sizeof (struct mode_data *), cmp_modes);
 
  sortbuf[i] = 0;
  for (j = 0; j < i; j++)
diff --git a/gcc/system.h b/gcc/system.h
index b091794..0f44942 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1170,4 +1170,15 @@ helper_const_non_const_cast (const char *p)
 /* Get definitions of HOST_WIDE_INT.  */
 #include "hwint.h"
 
+/* qsort comparator consistency checking machinery.  */
+#if CHECKING_P
+/* Except in release-checking compilers, redirect 4-argument qsort calls.  */
+#undef qsort
+#define _5th(_1, _2, _3, _4, _5, ...) _5
+#define qsort(...) _5th (__VA_ARGS__, qsort_chk, 3, 2, qsort, 0) (__VA_ARGS__)
+#endif
+#define qsort_nochk (qsort)
+void qsort_chk (void *, size_t, size_t, int (*)(const void *, const void *));
+extern unsigned qsort_disable_checking;
+
 #endif /* ! GCC_SYSTEM_H */
diff --git a/gcc/vec.c b/gcc/vec.c
index d612703..5d9f1e9 100644
--- a/gcc/vec.c
+++ b/gcc/vec.c
@@ -31,6 +31,12 @@ along with GCC; see the file COPYING3.  If not see
 #include "coretypes.h"
 #include "hash-table.h"
 #include "selftest.h"
+#ifdef GENERATOR_FILE
+#include "errors.h"
+#else
+#include "input.h"
+#include "diagnostic-core.h"
+#endif
 
 /* vNULL is an empty type with a template cast operation that returns
a zero-initialized vec instance.  Use this when you want
@@ -42,6 +48,95 @@ along with GCC; see the file COPYING3.  If not see
they cannot have ctors/dtors.  */
 vnull vNULL;
 
+/* Report qsort comparator CMP consistency check failure with P1, P2, P3 as
+   witness elements.  */
+ATTRIBUTE_NORETURN ATTRIBUTE_COLD
+static void
+qsort_chk_error (const void *p1, const void *p2, const void *p3,
+int (*cmp) (const void *, const void *))
+{
+  if (!p3)
+{
+  int r1 = cmp (p1, p2), r2 = cmp (p2, p1);
+  error ("qsort comparator not anti-commutative: %d, %d", r1, r2);
+}
+  else if (p1 == p2)
+{
+  int r = cmp (p1, p3);
+  error ("qsort comparator non-negative on sorted output: %d", r);
+}
+  else
+{
+  int r1 = cmp (p1, p2), r2 = cmp (p2, p3), r3 = cmp (p1, p3);
+  error ("qsort comparator not transitive: %d, %d, %d", r1, r2, r3);
+}
+  internal_error ("qsort checking failed");
+}
+
+unsigned qsort_disable_checking;
+
+/* Wrapper around qsort with checking that CMP is consistent on given input.
+
+   Strictly speaking, passing invalid (non-transitive, non-anti-commutative)
+   comparators to libc qsort can result in undefined behavior.  Therefore we
+   should ideally perform consistency checks prior to invoking qsort, but in
+   order to do that optimally we'd need to sort the array ourselves beforehand
+   with a sorting routine known to be "safe".  Instead, we expect that most
+   implementations in practice will still produce some permutation of input
+   array even for invalid comparators, which enables us to perform checks on
+   the output array.  */
+void
+qsort_chk (void *base, size_t n, size_t size,
+  int (*cmp)(const void *, const void *))
+{
+  if (!CHECKING_P || qsort_disable_checking)
+return (qsort) (base, n, size, cmp);
+  (qsort) (base, n, size, cmp);
+#ifdef ENABLE_FULL_QSORT_CHECKING
+#define LIM(n) (n)
+#else
+  /* Limit overall time complexity to O(n log n).  */
+#define LIM(n) ((n) <= 16 ? (n) : 12 + floor_log2 (n))
+#endif
+#define ELT(i) ((const char *) base + (i) * size)
+#define CMP(i, j) cmp (ELT (i), ELT (j))
+#define ERR2(i, j) qsort_chk_error (ELT (i), ELT (j), NULL, 

[PATCH 0/6] qsort comparator consistency fixes

[Alexander Monakov]

Hello,

(previous thread here:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00944.html )

we still have a few places in GCC where the comparator function passed to qsort
is not actually a proper sorting predicate.  Most commonly it fails to impose
total ordering by lacking transitivity.  It's useful to fix such instances,
because:

- such comparators don't work as intended;
- they lead to issues that can only be reproduced with a specific libc;
- failure usually happens not in qsort, but quite some time later.

(PR 71702 and its duplicates is a good highlight for the latter two, it
could only be observed with qsort from musl libc and manifested as assert
failure in the vectorizer, which was not trivial to diagnose)

The goal of this patchset is to introduce automatic comparator consistency
verification in GCC, with zero impact on release-checking compilers and
minimal workflow disturbance (it should be possible to easily suppress
checking to e.g. unblock bootstrap when there's no obvious fix).

Changes from the last year's patch:

+ both vec::qsort and libc ::qsort are checked (previously only vec::)
+ individual callers can opt out of checking
+ a bit more sensible cutoff for avoiding O(n^2) time complexity
+ unlike a year ago, now this needs 5 accompanying patches for broken
  comparators, meaning new issues have crept in

The first question last year from Richard was about bootstrap time impact.
Last year it appeared to be in the noise, I can do it again if there's
interest.

Patches 1-3 fix broken comparators where the fix is evident, patches 4-5
avoid qsort checking where comparators needs nontrivial fixes, and patch
6 is the actual checking implementation.

  tree-vrp: fix compare_assert_loc qsort comparator
  gimple-ssa-store-merging.c: fix sort_by_bitpos
  lra-assigns.c: fix pseudo_compare_func
  lra-assigns.c: give up on qsort checking in assign_by_spills
  haifa-sched.c: give up qsort checking when autoprefetch heuristic is
in use
  qsort comparator consistency checking

 gcc/genmodes.c |  2 +-
 gcc/gimple-ssa-store-merging.c |  6 +--
 gcc/haifa-sched.c  |  8 
 gcc/lra-assigns.c  | 10 ++---
 gcc/system.h   | 11 +
 gcc/tree-vrp.c |  2 +-
 gcc/vec.c  | 95 ++
 7 files changed, 124 insertions(+), 10 deletions(-)

-- 
1.8.3.1

[PATCH 1/6] tree-vrp: fix compare_assert_loc qsort comparator

[Alexander Monakov]

Subtracting values to produce a -/0/+ comparison value only works when
original values have limited range.  Otherwise it leads to broken
comparator that indicates 0 < 0x4000 < 0x8000 < 0.

Yuri posted an equivalent patch just a few hours ago:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00882.html

* tree-vrp.c (compare_assert_loc): Properly compare hash values.
---
 gcc/tree-vrp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 28205f1..d1888f6 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -6459,7 +6459,7 @@ compare_assert_loc (const void *pa, const void *pb)
 return (a->e != NULL
? a->e->src->index - b->e->src->index
: a->bb->index - b->bb->index);
-  return ha - hb;
+  return ha < hb ? -1 : 1;
 }
 
 /* Process all the insertions registered for every name N_i registered
-- 
1.8.3.1

[PATCH 2/6] gimple-ssa-store-merging.c: fix sort_by_bitpos

[Alexander Monakov]

This qsort comparator lacks anti-commutativity and can indicate
A < B < A if A and B have the same bitpos.  Return 0 in that case.

* gimple-ssa-store-merging.c (sort_by_bitpos): Return 0 on equal bitpos.
---
 gcc/gimple-ssa-store-merging.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index 64b8351..c99960b 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -516,12 +516,12 @@ sort_by_bitpos (const void *x, const void *y)
   store_immediate_info *const *tmp = (store_immediate_info * const *) x;
   store_immediate_info *const *tmp2 = (store_immediate_info * const *) y;
 
-  if ((*tmp)->bitpos <= (*tmp2)->bitpos)
+  if ((*tmp)->bitpos < (*tmp2)->bitpos)
 return -1;
   else if ((*tmp)->bitpos > (*tmp2)->bitpos)
 return 1;
-
-  gcc_unreachable ();
+  else
+return 0;
 }
 
 /* Sorting function for store_immediate_info objects.
-- 
1.8.3.1

[PATCH 5/6] haifa-sched.c: give up qsort checking when autoprefetch heuristic is in use

[Alexander Monakov]

The autopref_rank_for_schedule sub-comparator and its subroutine
autopref_rank_data lack transitivity.  Skip checking if they are in use.

This heuristic is disabled by default everywhere except ARM and AArch64,
so on other targets this does not suppress  checking all the time.

* haifa-sched.c (ready_sort_real): Disable qsort checking if
autoprefetch heuristic will be used.
(autopref_rank_for_schedule): Add FIXME.
---
 gcc/haifa-sched.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index af0ed27..71ad3c4 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -3081,11 +3081,18 @@ ready_sort_real (struct ready_list *ready)
   if (sched_verbose >= 4)
 stats1 = rank_for_schedule_stats;
 
+  /* autopref_rank_for_schedule lacks transitivity.  */
+  if (PARAM_VALUE (PARAM_SCHED_AUTOPREF_QUEUE_DEPTH) >= 0)
+qsort_disable_checking |= 1;
+
   if (n_ready_real == 2)
 swap_sort (first, n_ready_real);
   else if (n_ready_real > 2)
 qsort (first, n_ready_real, sizeof (rtx), rank_for_schedule);
 
+  if (PARAM_VALUE (PARAM_SCHED_AUTOPREF_QUEUE_DEPTH) >= 0)
+qsort_disable_checking &= ~1;
+
   if (sched_verbose >= 4)
 {
   rank_for_schedule_stats_diff (, _for_schedule_stats);
@@ -5704,6 +5711,7 @@ autopref_rank_data (autopref_multipass_data_t data1,
 }
 
 /* Helper function for rank_for_schedule sorting.  */
+/* FIXME: this comparator lacks transitivity and is thus invalid for qsort.  */
 static int
 autopref_rank_for_schedule (const rtx_insn *insn1, const rtx_insn *insn2)
 {
-- 
1.8.3.1

[PATCH 3/6] lra-assigns.c: fix pseudo_compare_func

[Alexander Monakov]

This comparator lacks anti-commutativity and can indicate
A < B < A if both A and B satisfy non_spilled_static_chain_regno_p.
Proceed to following tie-breakers in that case.

(it looks like the code incorrectly assumes that at most one register
in the array will satisfy non_spilled_static_chain_regno_p)

* lra-assigns.c (pseudo_compare_func): Fix comparison step based on
non_spilled_static_chain_regno_p.
---
 gcc/lra-assigns.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/gcc/lra-assigns.c b/gcc/lra-assigns.c
index 42556d3..2aadeef 100644
--- a/gcc/lra-assigns.c
+++ b/gcc/lra-assigns.c
@@ -253,10 +253,9 @@ pseudo_compare_func (const void *v1p, const void *v2p)
 
   /* Assign hard reg to static chain pointer first pseudo when
  non-local goto is used.  */
-  if (non_spilled_static_chain_regno_p (r1))
-return -1;
-  else if (non_spilled_static_chain_regno_p (r2))
-return 1;
+  if ((diff = (non_spilled_static_chain_regno_p (r2)
+  - non_spilled_static_chain_regno_p (r1))) != 0)
+return diff;
 
   /* Prefer to assign more frequently used registers first.  */
   if ((diff = lra_reg_info[r2].freq - lra_reg_info[r1].freq) != 0)
-- 
1.8.3.1

Re: [DOC PATCH, i386] Fix PR 81294, _subborrow_u64 argument order inconsistent with intrinsic reference

[Gerald Pfeifer]

On Thu, 13 Jul 2017, Jakub Jelinek wrote:
> Ok for wwwdocs, with a nit:

Thanks for the review, Jakub, and the patch, Uros.

I applied the small follow-up below which uses  for the
intrinsics.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.86
diff -u -r1.86 changes.html
--- changes.html13 Jul 2017 20:21:31 -  1.86
+++ changes.html15 Jul 2017 16:50:08 -
@@ -1244,9 +1244,9 @@
 
 IA-32/x86-64
   
-The argument order of _subborrow_u32 and _subborrow_u64
-  intrinsics has been changed to follow the latest update
-  to the reference documentation.
+The argument order of _subborrow_u32 and
+  _subborrow_u64 intrinsics has been changed to follow
+  the latest update to the reference documentation.
   
 -->
 

gotools patch committed: Set GOROOT in tests

[Ian Lance Taylor]

This patch to the gotools Makefile sets GOROOT while running tests.
Otherwise some of the tests that invoke the go tool may use an
installed go tool, if there is one, rather than the one that was just
built.  Bootstrapped and ran gotools tests on x86_64-pc-linux-gnu.
Committed to mainline.

Ian

2017-07-15  Ian Lance Taylor  

* Makefile.am (CHECK_ENV): Set GOROOT.
(ECHO_ENV): Report setting GOROOT.
* Makefile.in: Rebuild.
Index: Makefile.am
===
--- Makefile.am (revision 250186)
+++ Makefile.am (working copy)
@@ -174,11 +174,13 @@ CHECK_ENV = \
export GO_TESTING_GOTOOLS; \
abs_libgodir=`cd $(libgodir) && $(PWD_COMMAND)`; \
LD_LIBRARY_PATH=`echo $${abs_libgodir}/.libs:$${LD_LIBRARY_PATH} | sed 
's,::*,:,g;s,^:*,,;s,:*$$,,'`; \
-   export LD_LIBRARY_PATH;
+   export LD_LIBRARY_PATH; \
+   GOROOT=$${abs_libgodir}; \
+   export GOROOT;
 
 # ECHO_ENV is a variant of CHECK_ENV to put into a testlog file.
 # It assumes that abs_libgodir is set.
-ECHO_ENV = PATH=`echo $(abs_builddir):$${PATH} | sed 
's,::*,:,g;s,^:*,,;s,:*$$,,'` GCCGO='$(abs_builddir)/check-gccgo' 
GCCGOTOOLDIR='$(abs_builddir)' GO_TESTING_GOTOOLS=yes LD_LIBRARY_PATH=`echo 
$${abs_libgodir}/.libs:$${LD_LIBRARY_PATH} | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`
+ECHO_ENV = PATH=`echo $(abs_builddir):$${PATH} | sed 
's,::*,:,g;s,^:*,,;s,:*$$,,'` GCCGO='$(abs_builddir)/check-gccgo' 
GCCGOTOOLDIR='$(abs_builddir)' GO_TESTING_GOTOOLS=yes LD_LIBRARY_PATH=`echo 
$${abs_libgodir}/.libs:$${LD_LIBRARY_PATH} | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'` 
GOROOT=`echo $${abs_libgodir}`
 
 # check-go-tools runs `go test cmd/go` in our environment.
 check-go-tool: go$(EXEEXT) cgo$(EXEEXT) check-head check-gccgo

Re: [PATCH] match.pd: reassociate multiplications with constants

[Alexander Monakov]

On Thu, 13 Jul 2017, Marc Glisse wrote:
> X*big*big where abs(big*big)>abs(INT_MIN) can be optimized to 0

I'm not sure that would be a win, eliminating X prevents the compiler from
deducing that X must be zero (if overflow invokes undefined behavior).

> the only hard case is when the product of the constants is -INT_MIN, which we
> could turn into X<<31 for instance (sadly loses range info), or (-X)*INT_MIN
> or whatever. That would make a nice follow-up, if you are interested.

Here's a patch that combines constants, but doesn't handle this case,
(I'm not sure we want to handle it, would it be useful in practice?)
and neither does substitute zero on overflow, per the above concern.

(slsr-4.c needs to be adjusted due to new simplifications)

* match.pd ((X * CST1) * CST2): Simplify to X * (CST1 * CST2)
if the product does not overflow.
testsuite:
* gcc.dg/tree-ssa/assoc-2.c: Enhance.
* gcc.dg/tree-ssa/slsr-4.c: Adjust.

diff --git a/gcc/match.pd b/gcc/match.pd
index 36045f1..7f384db 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -283,6 +283,17 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 || mul != wi::min_value (TYPE_PRECISION (type), SIGNED))
  { build_zero_cst (type); })
 
+/* Combine successive multiplications.  Similar to above, but handling
+   overflow is different.  */
+(simplify
+ (mult (mult @0 INTEGER_CST@1) INTEGER_CST@2)
+ (with {
+   bool overflow_p;
+   wide_int mul = wi::mul (@1, @2, TYPE_SIGN (type), _p);
+  }
+  (if (!overflow_p || TYPE_OVERFLOW_WRAPS (type))
+   (mult @0 {wide_int_to_tree (type, mul); }
+
 /* Optimize A / A to 1.0 if we don't care about
NaNs or Infinities.  */
 (simplify
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/assoc-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/assoc-2.c
index a92c882..cc0e9d4 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/assoc-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/assoc-2.c
@@ -5,4 +5,15 @@ int f0(int a, int b){
   return a * 33 * b * 55;
 }
 
-/* { dg-final { scan-tree-dump-times "mult_expr" 2 "gimple" } } */
+int f1(int a){
+  a *= 33;
+  return a * 55;
+}
+
+int f2(int a, int b){
+  a *= 33;
+  return a * b * 55;
+}
+
+/* { dg-final { scan-tree-dump-times "mult_expr" 7 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "mult_expr" 5 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/slsr-4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/slsr-4.c
index 17d7b4c..1e943b7 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/slsr-4.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/slsr-4.c
@@ -23,13 +23,9 @@ f (int i)
   foo (y);
 }
 
-/* { dg-final { scan-tree-dump-times "\\* 4" 1 "slsr" } } */
-/* { dg-final { scan-tree-dump-times "\\* 10" 1 "slsr" } } */
-/* { dg-final { scan-tree-dump-times "\\+ 20;" 1 "slsr" } } */
+/* { dg-final { scan-tree-dump-times "\\* 40" 1 "slsr" } } */
 /* { dg-final { scan-tree-dump-times "\\+ 200" 1 "slsr" } } */
-/* { dg-final { scan-tree-dump-times "\\- 16;" 1 "slsr" } } */
 /* { dg-final { scan-tree-dump-times "\\- 160" 1 "slsr" } } */
-/* { dg-final { scan-tree-dump-times "\\* 4" 1 "optimized" } } */
-/* { dg-final { scan-tree-dump-times "\\* 10" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\* 40" 1 "optimized" } } */
 /* { dg-final { scan-tree-dump-times "\\+ 200" 1 "optimized" } } */
 /* { dg-final { scan-tree-dump-times "\\+ 40" 1 "optimized" } } */

Re: [PATCH] match.pd: reassociate multiplications with constants

[Alexander Monakov]

On Thu, 13 Jul 2017, Marc Glisse wrote:
> I notice that we do not turn (X*10)*10 into X*100 in GIMPLE [...]

I've completely missed that.  Posting another patch to address that.

> Relying on inner expressions being folded can be slightly dangerous,
> especially for generic IIRC. It seems easy enough to check that @1 is neither
> 0 nor -1 for safety.

Yep - done.

> Probably needs :s on the inner multiplication.

Not 100% sure, but done in this version.

> Unless the test on TYPE_OVERFLOW_SANITIZED etc is shared with adjacent
> transformations, I'd rather put it inside, with the other if, but that's a
> matter of taste.

Done, probably better that way.
 
> One small testcase please? Or is there already one that is currently failing?

No, I'm not aware of any preexisting testcase.  Added.

* match.pd ((X * CST) * Y): Reassociate to (X * Y) * CST.
testsuite/
* gcc.dg/tree-ssa/assoc-2.c: New testcase.

diff --git a/gcc/match.pd b/gcc/match.pd
index 4c64b21..36045f1 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2139,6 +2139,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (mult @0 integer_minus_onep)
  (negate @0))
 
+/* Reassociate (X * CST) * Y to (X * Y) * CST.  This does not introduce
+   signed overflow for CST != 0 && CST != -1.  */
+(simplify
+ (mult:c (mult:s @0 INTEGER_CST@1) @2)
+ (if (TREE_CODE (@2) != INTEGER_CST
+  && !integer_zerop (@1) && !integer_minus_onep (@1)
+  && !TYPE_OVERFLOW_SANITIZED (type) && !TYPE_SATURATING (type))
+  (mult (mult @0 @2) @1)))
+
 /* True if we can easily extract the real and imaginary parts of a complex
number.  */
 (match compositional_complex
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/assoc-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/assoc-2.c
new file mode 100644
index 000..a92c882
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/assoc-2.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-gimple-raw -fdump-tree-optimized-raw" } */
+
+int f0(int a, int b){
+  return a * 33 * b * 55;
+}
+
+/* { dg-final { scan-tree-dump-times "mult_expr" 2 "gimple" } } */

Re: [PATCH 2/6] New warnings -Wstring-plus-{char, int} (PR c++/62181)

[Gerald Pfeifer]

On Thu, 22 Jun 2017, Xi Ruoyao wrote:
> I created PR 81172.  For const char *p = "123" + 'c' we should have:
> 
> warning: offset 99 is above array bounds, the behaviour is
> undefined [-Warray-bounds]
> const char *p = "123" + 'c';
> 
> and perhaps (for the case the pointer operand is a string or a string
> pointer):
> note: adding integer to a string does not append to the string.

I do think this makes sense.  I'm really not convinced there is a 
lot of code out there that uses the "123" + i idiom to create a pointer, 
even if it is legitimate code, so a warning makes sense to me.

Gerald

[PATCH] Reorder std::scoped_lock parameters as per P0739R0 DR status

[Jonathan Wakely]

WG21 just approved this change as a DR for C++17, so that class
template argument deduction works when using std::adopt_lock with a
std::scoped_lock.

* include/std/mutex (scoped_lock): Reorder std::adopt_lock_t parameter
as per P0739R0.
* testsuite/30_threads/scoped_lock/cons/1.cc: Reorder arguments.
* testsuite/30_threads/scoped_lock/cons/deduction.cc: Test deduction
with std::adopt_lock_t.
* testsuite/30_threads/scoped_lock/requirements/typedefs.cc: Check
feature-test macro.

Tested powerpc64le-linux, committed to trunk.

I think we should also make this change and the r250213 one to
std::variant (which is in the same paper) on gcc-7-branch.

commit bd39b9c170c46347e521130ec368964b5977e866
Author: Jonathan Wakely 
Date:   Sat Jul 15 16:14:48 2017 +0100

Reorder std::scoped_lock parameters as per P0739R0 DR status

* include/std/mutex (scoped_lock): Reorder std::adopt_lock_t parameter
as per P0739R0.
* testsuite/30_threads/scoped_lock/cons/1.cc: Reorder arguments.
* testsuite/30_threads/scoped_lock/cons/deduction.cc: Test deduction
with std::adopt_lock_t.
* testsuite/30_threads/scoped_lock/requirements/typedefs.cc: Check
feature-test macro.

diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex
index df48b46..fadb9f6 100644
--- a/libstdc++-v3/include/std/mutex
+++ b/libstdc++-v3/include/std/mutex
@@ -557,7 +557,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
 
 #if __cplusplus > 201402L
-#define __cpp_lib_scoped_lock 201703
+#define __cpp_lib_scoped_lock 201707
   /** @brief A scoped lock type for multiple lockable objects.
*
* A scoped_lock controls mutex ownership within a scope, releasing
@@ -570,7 +570,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   explicit scoped_lock(_MutexTypes&... __m) : _M_devices(std::tie(__m...))
   { std::lock(__m...); }
 
-  explicit scoped_lock(_MutexTypes&... __m, adopt_lock_t) noexcept
+  explicit scoped_lock(adopt_lock_t, _MutexTypes&... __m) noexcept
   : _M_devices(std::tie(__m...))
   { } // calling thread owns mutex
 
@@ -609,7 +609,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   explicit scoped_lock(mutex_type& __m) : _M_device(__m)
   { _M_device.lock(); }
 
-  explicit scoped_lock(mutex_type& __m, adopt_lock_t) noexcept
+  explicit scoped_lock(adopt_lock_t, mutex_type& __m) noexcept
   : _M_device(__m)
   { } // calling thread owns mutex
 
diff --git a/libstdc++-v3/testsuite/30_threads/scoped_lock/cons/1.cc 
b/libstdc++-v3/testsuite/30_threads/scoped_lock/cons/1.cc
index 9f1b48c..e420ab0 100644
--- a/libstdc++-v3/testsuite/30_threads/scoped_lock/cons/1.cc
+++ b/libstdc++-v3/testsuite/30_threads/scoped_lock/cons/1.cc
@@ -79,7 +79,7 @@ void test01()
 
   try
 {
-  std::scoped_lock l(m, std::adopt_lock);
+  std::scoped_lock l(std::adopt_lock, m);
 }
   catch (...)
 {
@@ -113,7 +113,7 @@ void test02()
 
   try
 {
-  std::scoped_lock, Lockable<2>> l(m1, m2, std::adopt_lock);
+  std::scoped_lock, Lockable<2>> l(std::adopt_lock, m1, m2);
   VERIFY( m1.m.locked );
   VERIFY( m2.m.locked );
 }
diff --git a/libstdc++-v3/testsuite/30_threads/scoped_lock/cons/deduction.cc 
b/libstdc++-v3/testsuite/30_threads/scoped_lock/cons/deduction.cc
index 399de7a..7d4f5bf 100644
--- a/libstdc++-v3/testsuite/30_threads/scoped_lock/cons/deduction.cc
+++ b/libstdc++-v3/testsuite/30_threads/scoped_lock/cons/deduction.cc
@@ -51,3 +51,28 @@ test01()
   std::scoped_lock l2(m2, m3);
   check_type>(l2);
 }
+
+void
+test02()
+{
+  std::scoped_lock l0(std::adopt_lock);
+  check_type>(l0);
+
+  struct BasicLockable {
+void lock() { }
+void unlock() { }
+  } m1;
+
+  std::scoped_lock l1(std::adopt_lock, m1);
+  check_type(l1);
+
+  struct Lockable {
+void lock() { }
+void unlock() { }
+bool try_lock() { return true; }
+  } m2;
+
+  std::mutex m3;
+  std::scoped_lock l2(std::adopt_lock, m2, m3);
+  check_type>(l2);
+}
diff --git 
a/libstdc++-v3/testsuite/30_threads/scoped_lock/requirements/typedefs.cc 
b/libstdc++-v3/testsuite/30_threads/scoped_lock/requirements/typedefs.cc
index 55756d8..0a8903e 100644
--- a/libstdc++-v3/testsuite/30_threads/scoped_lock/requirements/typedefs.cc
+++ b/libstdc++-v3/testsuite/30_threads/scoped_lock/requirements/typedefs.cc
@@ -25,6 +25,12 @@
 
 #include 
 
+#ifndef __cpp_lib_scoped_lock
+# error "Feature-test macro for scoped_lock missing"
+#elif __cpp_lib_scoped_lock != 201707
+# error "Feature-test macro for scoped_lock has wrong value"
+#endif
+
 void test01()
 {
   // Check for required typedefs

Re: [PATCH] Fix pr80044, -static and -pie insanity, and pr81170

[H.J. Lu]

On Thu, Jun 22, 2017 at 8:28 AM, Alan Modra  wrote:
> PR80044 notes that -static and -pie together behave differently when
> gcc is configured with --enable-default-pie as compared to configuring
> without (or --disable-default-pie).  This patch removes that
> difference.  In both cases you now will have -static completely
> overriding -pie.
>
> Fixing this wasn't quite as simple as you'd expect, due to poor
> separation of functionality.  PIE_SPEC didn't just mean that -pie was
> on explicitly or by default, but also -r and -shared were *not* on.
> Fortunately the three files touched by this patch are the only places
> PIE_SPEC and NO_PIE_SPEC are used, so it isn't too hard to see that
> the reason PIE_SPEC and NO_PIE_SPEC are not inverses is the use of
> PIE_SPEC in LINK_PIE_SPEC.  So, move the inelegant symmetry breaking
> addition, to LINK_PIE_SPEC where it belongs.  Doing that showed
> another problem in gnu-user.h, with PIE_SPEC and NO_PIE_SPEC selection
> of crtbegin*.o not properly hooked into a chain of if .. elseif ..
> conditions, which required both PIE_SPEC and NO_PIE_SPEC to exclude
> -static and -shared.  Fixing that particular problem finally allows
> PIE_SPEC to serve just one purpose, and NO_PIE_SPEC to disappear.
>
> Bootstrapped and regression tested powerpc64le-linux c,c++.  No
> regressions and a bunch of --enable-default-pie failures squashed.
> OK mainline and active branches?
>
> Incidentally, there is a fairly strong case to be made for adding
> -static to the -shared, -pie, -no-pie chain of RejectNegative's in
> common.opt.  Since git 0d6378a9e (svn r48039) 2001-11-15, -static has
> done more than just the traditional "prevent linking with dynamic
> libraries", as -static selects crtbeginT.o rather than crtbegin.o
> on GNU systems.  Realizing this is what led me to close pr80044, which
> I'd opened with the aim of making -pie -static work together (with the
> traditional meaning of -static).  I don't that is worth doing, but
> mention pr80044 in the changelog due to fixing the insane output
> produced by -pie -static with --disable-default-pie.
>

On x86-64, without --enable-default-pie, "-static -pie" and "-pie -static"
never worked since both -static and -pie are passed to linker, which
uses libc.a to build PIE.  With --enable-default-pie, -static and -pie
override each other.  What does your patch do on x86-64?  Make
with and without --enable-default-pie behave the same?  Does it
mean that both fail to create executable?

-- 
H.J.

Re: [PATCH] Fix pr80044, -static and -pie insanity, and pr81170

[Alan Modra]

On Thu, Jun 29, 2017 at 11:03:56PM +0930, Alan Modra wrote:
> Ping?  Linux startfile and endfile specs.
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01678.html

3 week ping.  Also fixes PR81295.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] Kill TYPE_METHODS rtl 3/9

[Nathan Sidwell]

On 07/15/2017 12:43 AM, Jeff Law wrote:

On 07/14/2017 10:54 AM, Nathan Sidwell wrote:

This was the most surprising check of TYPE_METHODS.  When not optimizing
we use the non-nullness of TYPE_METHODS to figure out if we want to
place a non BLKmode structure into a register.  On the grounds that one
can't call a member function with a register-located object.

That seems overly enthusiastic -- if we're not optimizing, who cares?

(When we zap TYHPE_METHODS we currently set it to error_mark_node, if it
was non-null, so that this above check will work).



As a result gdb was unable to do an inferior call to its the object's
methods.


Right, I realize I failed to mention gdb in the email.  To be clear, what the 
snippet does is NEVER put record types in registers, when not optimizing.


nathan
--
Nathan Sidwell

Re: [PATCH 2/3] Simplify wrapped binops

[Marc Glisse]

On Wed, 5 Jul 2017, Robin Dapp wrote:


While the initialization value doesn't matter (wi::add will overwrite it)
better initialize both to false ;)  Ah, you mean because we want to
transform only if get_range_info returned VR_RANGE.  Indeed somewhat
unintuitive (but still the best variant for now).



so I'm still missing a comment on why min_ovf && max_ovf is ok.
The simple-minded would have written [...]


I suppose it's more a matter of considering too many things at the same
time for me...  I was still thinking of including more cases than
necessary for the regression.  Guess the attached version will do as
well and should not contain any more surprises.  If needed, I'll add
additional cases some time.


What happens for (long)(X+10)+LONG_MAX where X has type int and is in 
[-30, -20]? It looks like wi::add will overflow and you will generate 
X+negative which overflows at runtime.


(It looks like you don't need to name @3, you could just use the type of 
@0 instead)


--
Marc Glisse

[PATCH] Fix qsort ordering violation in tree-vrp.c

[Yuri Gribov]

Hi,

This is a follow-up on https://gcc.gnu.org/ml/gcc/2017-07/msg00078.html

compare_assert_loc in tree-vrp.c could return unpredictable results
due to implicit conversion of unsigned subtraction to int here:
  return ha - hb;

This could return inconsistent results for objects with the following hashes:
  a: 0xdc8e4f72U
  b: 0x912ab538U
  c: 0x5ae66e3bU
Then
  a > b because (int)(0xdc8e4f72U - 0x912ab538U) > 0
  b > c because (int)(0x912ab538U - 0x5ae66e3bU) > 0
but
  a < c because (int)(0xdc8e4f72U - 0x5ae66e3bU) == (int)0x81a7e137U < 0

Bug was found with https://github.com/yugr/sortcheck

Bootstrapped and regtested in x64, ok for trunk?

-Y


fix-order-1.patch
Description: Binary data

Re: Add support to trace comparison instructions and switch statements

[Dmitry Vyukov via gcc-patches]

On Sat, Jul 15, 2017 at 9:21 AM, 吴潍浠(此彼)  wrote:
> Hi
>
> Implementing __sanitizer_cov_trace_cmp[1248]_const is OK .
> And I will try to find some determinate way to judge this comparison is for 
> loop or not.
> Because all the loops(for() or while()) seem to be transformed to "if" and 
> "goto" before running sancov pass.
> Does it necessary to include APIs for float and double comparison ? like 
> __sanitizer_cov_trace_cmpf(float, float)
> Why you do not include them ?


Note you don't need to implement any of this right now, since we can
make it [almost] backwards compatible. Unless, of course, it's simple
and you find it useful and want to do this.
I think it's better to get a first version of the change in as is
(implement current clang API), and then do improvements in subsequent
patches. I would expect that detecting consts should be simple. Re
loops, I don't know, I would expect that gcc has some existing
analysis for loop (it does lots of optimization with counting loop).
Re floats/doubles, I am not sure, we managed to live without them in
go-fuzz and then in libfuzzer, and I still don't see lots of value in
them. Anyway, it should be a separate patch.




> Now, I am following some suggests about my codes from Gribow. Final patch is 
> still on processing.
> I am also waiting for copyright assignment of FSF which is requested by Jeff.
>
> With Regards
> Wish Wu
>
> --
> From:Dmitry Vyukov 
> Time:2017 Jul 15 (Sat) 13:41
> To:Kostya Serebryany 
> Cc:Wish Wu ; gcc ; gcc-patches 
> ; Wish Wu ; Alexander 
> Potapenko ; andreyknvl ; Victor 
> Chibotaru ; Yuri Gribov 
> Subject:Re: Add support to trace comparison instructions and switch statements
>
>
> On Fri, Jul 14, 2017 at 11:17 PM, Kostya Serebryany  wrote:
> > Hi
> >
> > I wrote a test for "-fsanitize-coverage=trace-cmp" .
> >
> > Is there anybody tells me if these codes could be merged into gcc ?
>
>
> Nice!
>
> We are currently working on Linux kernel fuzzing that use the
> comparison tracing. We use clang at the moment, but having this
> support in gcc would be great for kernel land.
>
> One concern I have: do we want to do some final refinements to the API
> before we implement this in both compilers?
>
> 2 things we considered from our perspective:
>  - communicating to the runtime which operands are constants
>  - communicating to the runtime which comparisons are counting loop checks
>
> First is useful if you do "find one operand in input and replace with
> the other one" thing. Second is useful because counting loop checks
> are usually not useful (at least all but one).
> In the original Go implementation I also conveyed signedness of
> operands, exact comparison operation (<, >, etc):
> https://github.com/dvyukov/go-fuzz/blob/master/go-fuzz-defs/defs.go#L13
> But I did not find any use for that.
> I also gave all comparisons unique IDs:
> https://github.com/dvyukov/go-fuzz/blob/master/go-fuzz-dep/sonar.go#L24
> That turned out to be useful. And there are chances we will want this
> for C/C++ as well.
>
> Kostya, did anything like this pop up in your work on libfuzzer?
> Can we still change the clang API? At least add an additional argument
> to the callbacks?


 I'd prefer not to change the API, but extend it (new compiler flag, new
 callbacks), if absolutely needed.
 Probably make it trace-cmp-guard (similar to trace-pc-guard, with an extra
 parameter that has the ID).
 I don't like the approach with compiler-generated constant IDs.
>>>
>>> Yes, if we do it for C/C++, we need to create globals and pass pointer
>>> to a global to the callbacks. IDs do not work for C/C++.
>>>
 Yes, it's a bit more efficient, but much less flexible in presence of
 multiple modules, DSOs, dlopen, etc.

 I was also looking at completely inlining this instrumentation because it's
 pretty expensive even in it's current form
 (adding more parameters will make things worse).
 This is going to be much less flexible, of course, so I'll attack it only
 once I settle on the algorithm to handle CMPs in libFuzzer.
>>>
>>> This will require a new, completely different API for
>>> compiler<->runtime anyway, so we can put this aside for now.
>>>
>>>
> At the very least I would suggest that we add an additional arg that
> contains some flags (1/2 arg is a const, this is counting loop check,
> etc). If we do that we can also have just 1 callback that accepts
> uint64's for args because we can pass operand size in the flags:


 How many flag 

Re: [PATCH] Remove Java references in source code.

[Eric Botcazou]

> Patch removes some remaining references in gcc/ subfolder.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

You need to configure with --enable-languages=all for cleanups like this, the 
patch trivially breaks the Ada compiler everywhere:

+===GNAT BUG DETECTED==+
| 8.0.0 20170715 (experimental) [trunk revision 250221] (x86_64-suse-linux) 
GCC error:|
| in gimplify_save_expr, at gimplify.c:5805|
| Error detected around /home/eric/svn/gcc/gcc/ada/butil.adb:40:31 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |

-- 
Eric Botcazou

Re: Add support to trace comparison instructions and switch statements

[吴潍浠(此彼)]

Hi

Implementing __sanitizer_cov_trace_cmp[1248]_const is OK . 
And I will try to find some determinate way to judge this comparison is for 
loop or not.
Because all the loops(for() or while()) seem to be transformed to "if" and 
"goto" before running sancov pass.
Does it necessary to include APIs for float and double comparison ? like 
__sanitizer_cov_trace_cmpf(float, float)
Why you do not include them ?

Now, I am following some suggests about my codes from Gribow. Final patch is 
still on processing.
I am also waiting for copyright assignment of FSF which is requested by Jeff.

With Regards
Wish Wu

--
From:Dmitry Vyukov 
Time:2017 Jul 15 (Sat) 13:41
To:Kostya Serebryany 
Cc:Wish Wu ; gcc ; gcc-patches 
; Wish Wu ; Alexander Potapenko 
; andreyknvl ; Victor Chibotaru 
; Yuri Gribov 
Subject:Re: Add support to trace comparison instructions and switch statements


On Fri, Jul 14, 2017 at 11:17 PM, Kostya Serebryany  wrote:
 > Hi
 >
 > I wrote a test for "-fsanitize-coverage=trace-cmp" .
 >
 > Is there anybody tells me if these codes could be merged into gcc ?


 Nice!

 We are currently working on Linux kernel fuzzing that use the
 comparison tracing. We use clang at the moment, but having this
 support in gcc would be great for kernel land.

 One concern I have: do we want to do some final refinements to the API
 before we implement this in both compilers?

 2 things we considered from our perspective:
  - communicating to the runtime which operands are constants
  - communicating to the runtime which comparisons are counting loop checks

 First is useful if you do "find one operand in input and replace with
 the other one" thing. Second is useful because counting loop checks
 are usually not useful (at least all but one).
 In the original Go implementation I also conveyed signedness of
 operands, exact comparison operation (<, >, etc):
 https://github.com/dvyukov/go-fuzz/blob/master/go-fuzz-defs/defs.go#L13
 But I did not find any use for that.
 I also gave all comparisons unique IDs:
 https://github.com/dvyukov/go-fuzz/blob/master/go-fuzz-dep/sonar.go#L24
 That turned out to be useful. And there are chances we will want this
 for C/C++ as well.

 Kostya, did anything like this pop up in your work on libfuzzer?
 Can we still change the clang API? At least add an additional argument
 to the callbacks?
>>>
>>>
>>> I'd prefer not to change the API, but extend it (new compiler flag, new
>>> callbacks), if absolutely needed.
>>> Probably make it trace-cmp-guard (similar to trace-pc-guard, with an extra
>>> parameter that has the ID).
>>> I don't like the approach with compiler-generated constant IDs.
>>
>> Yes, if we do it for C/C++, we need to create globals and pass pointer
>> to a global to the callbacks. IDs do not work for C/C++.
>>
>>> Yes, it's a bit more efficient, but much less flexible in presence of
>>> multiple modules, DSOs, dlopen, etc.
>>>
>>> I was also looking at completely inlining this instrumentation because it's
>>> pretty expensive even in it's current form
>>> (adding more parameters will make things worse).
>>> This is going to be much less flexible, of course, so I'll attack it only
>>> once I settle on the algorithm to handle CMPs in libFuzzer.
>>
>> This will require a new, completely different API for
>> compiler<->runtime anyway, so we can put this aside for now.
>>
>>
 At the very least I would suggest that we add an additional arg that
 contains some flags (1/2 arg is a const, this is counting loop check,
 etc). If we do that we can also have just 1 callback that accepts
 uint64's for args because we can pass operand size in the flags:
>>>
>>>
>>> How many flag combinations do we need and do we *really* need them?
>>>
>>> If the number of flag combinations is small, I'd prefer to have separate
>>> callbacks (__sanitizer_cov_trace_cmp_loop_bound ?)
>>>
>>> Do we really need to know that one arg is a const?
>>> It could well be a constant in fact, but compiler won't see it.
>>>
>>> int foo(int n) {   ... if (i < n) ... }
>>> ...
>>> foo(42);  // not inlined.
>>>
>>> We need to handle both cases the same way.
>>
>>
>> Well, following this line of reasoning we would need only
>> __asan_load/storeN callbacks for asan and remove
>> __asan_load/store1/2/4/8, because compiler might not know the size at
>> compile time. Constant-ness is only an optimization. If compiler does
>> not know that something is a const, fine. Based on my experience with
>> go-fuzz and our early experience with kernel, we badly need const
>> hint.
>> Otherwise fuzzer 

Re: [patch,avr] Fix PR80929, work around middle-end PR81444

[Denis Chertykov]

2017-07-14 18:16 GMT+04:00 Georg-Johann Lay :
> Hi, this patch restores some of the divmod handling.
>
> It addresses two issues:
>
> 1) rtx_costs might be called with code = LSHIFTRT for a mul_highpart. This
> is the case when outer_code = TRUNCATE.  This patch uses a new function to
> compute the costs for that case (also used for code = TRUNCATE).
>
> 2) Due to PR81444, the middle-end is calling the cost functions with strange
> RTXes like
>
>   (truncate:HI (lshiftrt:PSI (mult:PSI (zero_extend:PSI (reg:TI 42))
>(zero_extend:PSI (reg:TI 42)))
>  (const_int 16 [0x10])))
>
> i.e. completely messed up modes.  The correct RTX would be
>
>   (truncate:HI (lshiftrt:SI (mult:SI (zero_extend:SI (reg:HI 42))
>  (zero_extend:SI (reg:HI 42)))
> (const_int 16 [0x10])))
>
> The is worked around by also considering PSImode in the cost computation.
>
> FYI, I am currently also just reg-testing a fix for PR81444, cf.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81444#c1
>
> Ok to apply the patch below (trunk and v7)?
>
> Johann
>
> PR 80929
> * config/avr/avr.c (avr_mul_highpart_cost): New static function.
> (avr_rtx_costs_1) [TRUNCATE]: Use it to compute mul_highpart cost.
> [LSHIFTRT, outer_code = TRUNCATE]: Same.

Approved. Please apply.

Re: [PATCH/AARCH64] Decimal floating point support for AARCH64

[Andrew Pinski]

On Thu, Jul 13, 2017 at 5:12 PM, Andrew Pinski  wrote:
> Hi,
>   This patch adds Decimal floating point support to aarch64.  It is
> the base support in that since there is no hardware support for DFP,
> it just defines the ABI.  The ABI I chose is that _Decimal32 is
> treated like float, _Decimal64 is treated like double and _Decimal128
> is treated like long double.  In that they are passed via the floating
> registers (sN, dN, qN).
> Is this ok an ABI?
>
> Is the patch ok?  Bootstrapped and tested on aarch64-linux-gnu with
> --enable-decimal-float with no regressions and all of the dfp
> testcases pass.

I just noticed I messed up by attaching the wrong patch.
Here is the correct one.

Thanks,
Andrew

>
> Thanks,
> Andrew Pinski
>
> gcc/ChangeLog:
> * config/aarch64/aarch64.c (aarch64_split_128bit_move): Handle TDmode.
> (aarch64_classify_address): Likewise.
> (aarch64_legitimize_address_displacement): Likewise.
> (aarch64_legitimize_address): Likewise.
> (aarch64_constant_pool_reload_icode): Handle SD, DD, and TD modes.
> (aarch64_secondary_reload): Handle TDmode.
> (aarch64_valid_floating_const): For decimal floating point return false.
> (aarch64_gimplify_va_arg_expr): Handle SD, DD, and TD modes.
> (aapcs_vfp_sub_candidate): Likewise.
> (aarch64_vfp_is_call_or_return_candidate): Handle MODE_DECIMAL_FLOAT.
> (aarch64_scalar_mode_supported_p): For DECIMAL_FLOAT_MODE_P, return
> default_decimal_float_supported_p.
> * config/aarch64/iterators.md (GPF_TF_F16): Add SD, DD, and TD modes.
> (SFD): New iterator.
> (DFD): New iterator.
> (TFD): New iterator.
> (GPF_TF): Add SD, DD, and TD modes.
> (TX): Add TD mode.
> * config/aarch64/aarch64.md (*movsf_aarch64): Use SFD iterator.
> (*movdf_aarch64): Use DFD iterator.
> (*movtf_aarch64): Use TFD iterator.
> (define_split for TF): Use TFD iterator.
>
>
> gcc/testsuite/ChangeLog:
> * c-c++-common/dfp/pr39986.c: Allow for word instead of just long.
>
> libgcc/ChangeLog:
> * config.host (aarch64*-*-elf): Add t-dfprules to tmake_file.
> (aarch64*-*-freebsd*): Likewise.
> (aarch64*-*-linux*): Likewise.
Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c(revision 250186)
+++ gcc/config/aarch64/aarch64.c(working copy)
@@ -1653,7 +1653,7 @@ aarch64_split_128bit_move (rtx dst, rtx
 
   machine_mode mode = GET_MODE (dst);
 
-  gcc_assert (mode == TImode || mode == TFmode);
+  gcc_assert (mode == TImode || mode == TFmode || mode == TDmode);
   gcc_assert (!(side_effects_p (src) || side_effects_p (dst)));
   gcc_assert (mode == GET_MODE (src) || GET_MODE (src) == VOIDmode);
 
@@ -1673,11 +1673,16 @@ aarch64_split_128bit_move (rtx dst, rtx
  emit_insn (gen_aarch64_movtilow_di (dst, src_lo));
  emit_insn (gen_aarch64_movtihigh_di (dst, src_hi));
}
- else
+ else if (mode == TFmode)
{
  emit_insn (gen_aarch64_movtflow_di (dst, src_lo));
  emit_insn (gen_aarch64_movtfhigh_di (dst, src_hi));
}
+ else
+   {
+ emit_insn (gen_aarch64_movtdlow_di (dst, src_lo));
+ emit_insn (gen_aarch64_movtdhigh_di (dst, src_hi));
+   }
  return;
}
   else if (GP_REGNUM_P (dst_regno) && FP_REGNUM_P (src_regno))
@@ -1690,11 +1695,16 @@ aarch64_split_128bit_move (rtx dst, rtx
  emit_insn (gen_aarch64_movdi_tilow (dst_lo, src));
  emit_insn (gen_aarch64_movdi_tihigh (dst_hi, src));
}
- else
+ else if (mode == TFmode)
{
  emit_insn (gen_aarch64_movdi_tflow (dst_lo, src));
  emit_insn (gen_aarch64_movdi_tfhigh (dst_hi, src));
}
+ else if (mode == TDmode)
+   {
+ emit_insn (gen_aarch64_movdi_tdlow (dst_lo, src));
+ emit_insn (gen_aarch64_movdi_tdhigh (dst_hi, src));
+   }
  return;
}
 }
@@ -4420,10 +4430,11 @@ aarch64_classify_address (struct aarch64
   rtx op0, op1;
 
   /* On BE, we use load/store pair for all large int mode load/stores.
- TI/TFmode may also use a load/store pair.  */
+ TI/TF/TDmode may also use a load/store pair.  */
   bool load_store_pair_p = (outer_code == PARALLEL
|| mode == TImode
|| mode == TFmode
+   || mode == TDmode
|| (BYTES_BIG_ENDIAN
&& aarch64_vect_struct_mode_p (mode)));
 
@@ -4473,7 +4484,7 @@ aarch64_classify_address (struct aarch64
  info->base = op0;
  info->offset = op1;
 
- /* TImode and TFmode values are allowed in both pairs of X
+ /* TImode and TFmode and TDmode values are allowed in both pairs of X
 registers and individual Q registers.  The available
 address modes are:
 X,X: 7-bit signed scaled 

Re: [PATCH] Make __FUNCTION__ a mergeable string and do not generate symbol entry.

[Jim Wilson]

On Fri, Jul 14, 2017 at 12:59 PM, Jim Wilson  wrote:
> On Fri, Jul 14, 2017 at 1:35 AM, Martin Liška  wrote:
>> May I ask Jim to test the patch?
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> I started an aarch64 bootstrap to test.  My fast machine is busy with
> work tasks, so I have to use a slower machine, and hence this will
> take some time.

The aarch64-linux bootstrap with the patch succeeds.  I also did a
make check, and see no regressions.

Jim