Re: [RFC][PR82479] missing popcount builtin detection

[Richard Biener]

On Wed, Jan 24, 2018 at 10:56 PM, Kugan Vivekanandarajah
 wrote:
> Hi All,
>
> Here is a patch for popcount builtin detection similar to LLVM. I
> would like to queue this for review for next stage 1.
>
> 1. This is done part of loop-distribution and effective for -O3 and above.
> 2. This does not distribute loop to detect popcount (like
> memcpy/memmove). I dont think that happens in practice. Please correct
> me if I am wrong.

But then it has no business inside loop distribution but instead is
doing final value
replacement, right?  You are pattern-matching the whole loop after all.  I think
final value replacement would already do the correct thing if you
teached number of
iteration analysis that niter for

   [local count: 955630224]:
  # b_11 = PHI 
  _1 = b_11 + -1;
  b_8 = _1 & b_11;
  if (b_8 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 850510900]:
  goto ; [100.00%]

is related to popcount (b_5).

Richard.

> Bootstrapped and regression tested on aarch64-linux-gnu with no new 
> regressions.
>
> Thanks,
> Kugan
>
> gcc/ChangeLog:
>
> 2018-01-25  Kugan Vivekanandarajah  
>
> PR middle-end/82479
> * tree-loop-distribution.c (handle_popcount): New.
> (pass_loop_distribution::execute): Use handle_popcount.
>
> gcc/testsuite/ChangeLog:
>
> 2018-01-25  Kugan Vivekanandarajah  
>
> PR middle-end/82479
> * gcc.dg/tree-ssa/popcount.c: New test.

PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

[Alan Modra]

vbpermq produces its output in bits 48..63 of the target vector reg,
so the output cannot be lane swapped.  Bootstrapped and regression
tested powerpc64le-linux.  OK to apply mainline, and backport to the
branches?

gcc/
PR target/84033
* config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Exclude
UNSPEC_VBPERMQ.  Sort other unspecs.
gcc/testsuite/
PR target/84033
* gcc.target/powerpc/swaps-p8-46.c: New.

diff --git a/gcc/config/rs6000/rs6000-p8swap.c 
b/gcc/config/rs6000/rs6000-p8swap.c
index 1f95290..ffcbba9 100644
--- a/gcc/config/rs6000/rs6000-p8swap.c
+++ b/gcc/config/rs6000/rs6000-p8swap.c
@@ -741,6 +741,7 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
  {
  default:
break;
+ case UNSPEC_VBPERMQ:
  case UNSPEC_VMRGH_DIRECT:
  case UNSPEC_VMRGL_DIRECT:
  case UNSPEC_VPACK_SIGN_SIGN_SAT:
@@ -762,8 +763,14 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
  case UNSPEC_VSUMSWS:
  case UNSPEC_VSUMSWS_DIRECT:
  case UNSPEC_VSX_CONCAT:
+ case UNSPEC_VSX_CVDPSPN:
+ case UNSPEC_VSX_CVSPDP:
+ case UNSPEC_VSX_CVSPDPN:
+ case UNSPEC_VSX_EXTRACT:
  case UNSPEC_VSX_SET:
  case UNSPEC_VSX_SLDWI:
+ case UNSPEC_VSX_VEC_INIT:
+ case UNSPEC_VSX_VSLO:
  case UNSPEC_VUNPACK_HI_SIGN:
  case UNSPEC_VUNPACK_HI_SIGN_DIRECT:
  case UNSPEC_VUNPACK_LO_SIGN:
@@ -774,12 +781,6 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
  case UNSPEC_VUPKLPX:
  case UNSPEC_VUPKLS_V4SF:
  case UNSPEC_VUPKLU_V4SF:
- case UNSPEC_VSX_CVDPSPN:
- case UNSPEC_VSX_CVSPDP:
- case UNSPEC_VSX_CVSPDPN:
- case UNSPEC_VSX_EXTRACT:
- case UNSPEC_VSX_VSLO:
- case UNSPEC_VSX_VEC_INIT:
return 0;
  case UNSPEC_VSPLT_DIRECT:
  case UNSPEC_VSX_XXSPLTD:
diff --git a/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c 
b/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
new file mode 100644
index 000..23494b6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
@@ -0,0 +1,34 @@
+/* { dg-do run { target { powerpc64le-*-* } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
+/* { dg-options "-mcpu=power8 -O2 " } */
+
+typedef __attribute__ ((__aligned__ (8))) unsigned long long __m64;
+typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
+
+/* PR84033.  Extracted from xmmintrin.h but with a pointer param to
+   allow swaps to happen when not inline.  */
+int __attribute__ ((__noinline__))
+_mm_movemask_ps (__m128 *__A)
+{
+  __vector __m64 result;
+  static const __vector unsigned int perm_mask =
+{
+  0x00204060, 0x80808080, 0x80808080, 0x80808080
+};
+
+  result = (__vector __m64)
+__builtin_vec_vbpermq ((__vector unsigned char) (*__A),
+  (__vector unsigned char) perm_mask);
+  return result[1];
+}
+
+int
+main (void)
+{
+  union { unsigned int i[4]; __m128 m; } x
+= { 0x8000, 0x8000, 0x7fff, 0x7fff };
+  if (_mm_movemask_ps (&x.m) != 3)
+__builtin_abort ();
+  return 0;
+}

-- 
Alan Modra
Australia Development Lab, IBM

Re: Add support for bitwise reductions

[Richard Sandiford]

Rainer Orth  writes:
> Jeff Law  writes:
>> On 11/22/2017 11:12 AM, Richard Sandiford wrote:
>>> Richard Sandiford  writes:
 This patch adds support for the SVE bitwise reduction instructions
 (ANDV, ORV and EORV).  It's a fairly mechanical extension of existing
 REDUC_* operators.

 Tested on aarch64-linux-gnu (with and without SVE), x86_64-linux-gnu
 and powerpc64le-linux-gnu.
>>> 
>>> Here's an updated version that applies on top of the recent
>>> removal of REDUC_*_EXPR.  Tested as before.
>>> 
>>> Thanks,
>>> Richard
>>> 
>>> 
>>> 2017-11-22  Richard Sandiford  
>>> Alan Hayward  
>>> David Sherwood  
>>> 
>>> gcc/
>>> * optabs.def (reduc_and_scal_optab, reduc_ior_scal_optab)
>>> (reduc_xor_scal_optab): New optabs.
>>> * doc/md.texi (reduc_and_scal_@var{m}, reduc_ior_scal_@var{m})
>>> (reduc_xor_scal_@var{m}): Document.
>>> * doc/sourcebuild.texi (vect_logical_reduc): Likewise.
>>> * internal-fn.def (IFN_REDUC_AND, IFN_REDUC_IOR, IFN_REDUC_XOR): New
>>> internal functions.
>>> * fold-const-call.c (fold_const_call): Handle them.
>>> * tree-vect-loop.c (reduction_fn_for_scalar_code): Return the new
>>> internal functions for BIT_AND_EXPR, BIT_IOR_EXPR and BIT_XOR_EXPR.
>>> * config/aarch64/aarch64-sve.md (reduc__scal_):
>>> (*reduc__scal_): New patterns.
>>> * config/aarch64/iterators.md (UNSPEC_ANDV, UNSPEC_ORV)
>>> (UNSPEC_XORV): New unspecs.
>>> (optab): Add entries for them.
>>> (BITWISEV): New int iterator.
>>> (bit_reduc_op): New int attributes.
>>> 
>>> gcc/testsuite/
>>> * lib/target-supports.exp (check_effective_target_vect_logical_reduc):
>>> New proc.
>>> * gcc.dg/vect/vect-reduc-or_1.c: Also run for vect_logical_reduc
>>> and add an associated scan-dump test.  Prevent vectorization
>>> of the first two loops.
>>> * gcc.dg/vect/vect-reduc-or_2.c: Likewise.
>>> * gcc.target/aarch64/sve_reduc_1.c: Add AND, IOR and XOR reductions.
>>> * gcc.target/aarch64/sve_reduc_2.c: Likewise.
>>> * gcc.target/aarch64/sve_reduc_1_run.c: Likewise.
>>> (INIT_VECTOR): Tweak initial value so that some bits are always set.
>>> * gcc.target/aarch64/sve_reduc_2_run.c: Likewise.
>> OK.
>> Jeff
>
> Two tests have regressed on sparc-sun-solaris2.*:
>
> +FAIL: gcc.dg/vect/vect-reduc-or_1.c -flto -ffat-lto-objects
> scan-tree-dump vect "Reduce using vector shifts"
> +FAIL: gcc.dg/vect/vect-reduc-or_1.c scan-tree-dump vect "Reduce using
> vector shifts"
> +FAIL: gcc.dg/vect/vect-reduc-or_2.c -flto -ffat-lto-objects
> scan-tree-dump vect "Reduce using vector shifts"
> +FAIL: gcc.dg/vect/vect-reduc-or_2.c scan-tree-dump vect "Reduce using
> vector shifts"

Bah, I think I broke this yesterday in:

2018-01-24  Richard Sandiford  

PR testsuite/83889
[...]
* gcc.dg/vect/vect-reduc-or_1.c: Remove conditional dg-do run.
* gcc.dg/vect/vect-reduc-or_2.c: Likewise.

(r257022), which removed:

  /* { dg-do run { target { whole_vector_shift || vect_logical_reduc } } } */

I'd somehow thought that the dump lines in these two tests were already
guarded, but they weren't.

Tested on aarch64-linux-gnu and x86_64-linux-gnu and applied as obvious.
Sorry for the breakage.

Richard


2018-01-25  Richard Sandiford  

gcc/testsuite/
* gcc.dg/vect/vect-reduc-or_1.c: Require whole_vector_shift for
the shift dump line.
* gcc.dg/vect/vect-reduc-or_2.c: Likewise.

Index: gcc/testsuite/gcc.dg/vect/vect-reduc-or_1.c
===
--- gcc/testsuite/gcc.dg/vect/vect-reduc-or_1.c 2018-01-24 16:22:31.724089913 
+
+++ gcc/testsuite/gcc.dg/vect/vect-reduc-or_1.c 2018-01-25 10:16:16.283500281 
+
@@ -45,5 +45,5 @@ main (unsigned char argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "Reduce using vector shifts" "vect" { target { 
! vect_logical_reduc } } } } */
+/* { dg-final { scan-tree-dump "Reduce using vector shifts" "vect" { target { 
whole_vector_shift && { ! vect_logical_reduc } } } } } */
 /* { dg-final { scan-tree-dump "Reduce using direct vector reduction" "vect" { 
target vect_logical_reduc } } } */
Index: gcc/testsuite/gcc.dg/vect/vect-reduc-or_2.c
===
--- gcc/testsuite/gcc.dg/vect/vect-reduc-or_2.c 2018-01-24 16:22:31.724089913 
+
+++ gcc/testsuite/gcc.dg/vect/vect-reduc-or_2.c 2018-01-25 10:16:16.284500239 
+
@@ -44,5 +44,5 @@ main (unsigned char argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "Reduce using vector shifts" "vect" { target { 
! vect_logical_reduc } } } } */
+/* { dg-final { scan-tree-dump "Reduce using vector shifts" "vect" { target { 
whole_vector_shift && { ! vect_logical_reduc } } } } } */
 /* { dg-final { scan-tree-dump "Reduce using direct vector reduction" "vect" { 
target vect_logical_reduc } } } */

[nvptx, PR84028] Add exit insn after noreturn call for neutered workers

[Tom de Vries]

Hi,

[ Note: this is similar to "[nvptx, PR81352] Add exit insn after 
noreturn call for neutered threads in warp" 
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02013.html ].


atm the test-case contained in this patch hangs at -O1 and higher.

For the test-case we generate:
...
$L4:
  @ %r56 bra.uni $L27;
  @ %r57 bra $L28;
  {
call _gfortran_abort;
trap;
exit;
  }
$L28:
  exit;
$L27:
...

The problem is that the neutered worker takes the branch to $L27, and 
executes random code afterwards.


The fix is to add an exit insn after the worker neutering join, as we 
did for the vector neutering join (which we can see here after $L28).


Build and reg-tested on x86_64 with nvptx accelerator.

Committed in stage4 as non-intrusive wrong-code fix.

Thanks,
- Tom
[nvptx, PR84028] Add exit insn after noreturn call for neutered workers

2018-01-25  Tom de Vries  

	PR target/84028
	* config/nvptx/nvptx.c (nvptx_single): Add exit insn after noreturn call
	for neutered workers.

	* testsuite/libgomp.oacc-fortran/pr84028.f90: New test.

---
 gcc/config/nvptx/nvptx.c   |  4 ++--
 libgomp/testsuite/libgomp.oacc-fortran/pr84028.f90 | 25 ++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index d848412..a6f4443 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4065,8 +4065,8 @@ nvptx_single (unsigned mask, basic_block from, basic_block to)
 	else
 	  {
 	rtx_insn *label_insn = emit_label_after (label, tail);
-	if (mode == GOMP_DIM_VECTOR && CALL_P (tail)
-		&& find_reg_note (tail, REG_NORETURN, NULL))
+	if ((mode == GOMP_DIM_VECTOR || mode == GOMP_DIM_WORKER)
+		&& CALL_P (tail) && find_reg_note (tail, REG_NORETURN, NULL))
 	  emit_insn_after (gen_exit (), label_insn);
 	  }
   }
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/pr84028.f90 b/libgomp/testsuite/libgomp.oacc-fortran/pr84028.f90
new file mode 100644
index 000..ed6e326
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/pr84028.f90
@@ -0,0 +1,25 @@
+! { dg-do run }
+
+program foo
+  integer :: a(3,3,3), ll, lll
+
+  a = 1
+
+  !$acc parallel num_gangs(1) num_workers(2)
+
+  if (any(a(1:3,1:3,1:3).ne.1)) call abort
+
+  do ll=1,3
+
+ !$acc loop vector
+ do lll=1,3
+a(1,ll,lll) = 2
+ enddo
+
+  enddo
+
+  if (a(1,1,1).ne.2) call abort
+
+  !$acc end parallel
+
+end program foo

[PATCH] Fix PR84003

[Richard Biener]

The following patch fixes PR84003 where RTL DSE removes a redundant
store (a store storing the same value as an earlier store) but in
doing this changing program semantics because the later store changes
the effective type of the memory location.  This in turn allows
sched2 to do an originally invalid transform.

The fix is to harden DSE so that while removing the later store
the earlier stores alias-sets are changed to reflect both dynamic
types - which means using alias-set zero.

On GIMPLE we simply avoid removing such type-changing stores because
we cannot easily get hold on the earlier store.

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

Disclaimer: this is a "local" fix, I didn't try to understand much
of the DSE data structures but only learned from +-10 lines around
the affected transform which I found by searching for the dumped
messages ...  Richard, you contributed the pass so please review.

Ok for trunk and branches?

Thanks,
Richard.

2018-01-25  Richard Biener  

PR rtl-optimization/84003
* dse.c (dse_step1): When removing redundant stores make sure
to adjust the earlier stores alias-set to match semantics of
the removed one and its own.
(dse_step6): Likewise.

* g++.dg/torture/pr77745.C: Mark foo noinline to trigger
latent bug in DSE.

Index: gcc/dse.c
===
--- gcc/dse.c   (revision 257043)
+++ gcc/dse.c   (working copy)
@@ -2725,6 +2725,19 @@ dse_step1 (void)
"eliminated\n",
 INSN_UID (ptr->insn),
 INSN_UID (s_info->redundant_reason->insn));
+ /* If the later store we delete could have changed the
+dynamic type of the memory make sure the one we
+preserve serves as a store for all loads that could
+validly have accessed the one we delete.  */
+ store_info *r_info = s_info->redundant_reason->store_rec;
+ while (r_info)
+   {
+ if (r_info->is_set
+ && (MEM_ALIAS_SET (s_info->mem)
+ != MEM_ALIAS_SET (r_info->mem)))
+   set_mem_alias_set (r_info->mem, 0);
+ r_info = r_info->next;
+   }
  delete_dead_store_insn (ptr);
}
  free_store_info (ptr);
@@ -3512,6 +3525,19 @@ dse_step6 (void)
"eliminated\n",
INSN_UID (insn_info->insn),
INSN_UID (rinsn));
+ /* If the later store we delete could have changed the
+dynamic type of the memory make sure the one we
+preserve serves as a store for all loads that could
+validly have accessed the one we delete.  */
+ store_info *r_info = s_info->redundant_reason->store_rec;
+ while (r_info)
+   {
+ if (r_info->is_set
+ && (MEM_ALIAS_SET (s_info->mem)
+ != MEM_ALIAS_SET (r_info->mem)))
+   set_mem_alias_set (r_info->mem, 0);
+ r_info = r_info->next;
+   }
  delete_dead_store_insn (insn_info);
}
}
Index: gcc/testsuite/g++.dg/torture/pr77745.C
===
--- gcc/testsuite/g++.dg/torture/pr77745.C  (revision 257043)
+++ gcc/testsuite/g++.dg/torture/pr77745.C  (working copy)
@@ -2,7 +2,7 @@
 
 inline void* operator new(__SIZE_TYPE__, void* __p) noexcept { return __p; }
 
-long foo(char *c1, char *c2)
+long __attribute__((noinline)) foo(char *c1, char *c2)
 {
   long *p1 = new (c1) long;
   *p1 = 100;

[PATCH] Fix PR81082

[Richard Biener]

The mitigation for PR66313 (bogus re-association causing undefined
overflow) causes missed optimizations because the fix was to perform
possibly dangerous transforms in unsigned arithmetic.  Unfortunately
this loses knowledge of no-overflow which means SCEV analysis when
facing the unsigned computations has to conclude IVs may wrap and thus
are not affine when used in address context.

The following fix for this issue tries to delay dangerous transforms
instead to a point where range info may allow them without resorting
to unsigned arithmetic.  So compared to the original fix we do less
foldings (unless proved safe late).  In the PR I also suggested to
do a lowering during late GIMPLE to RTL semantics (-fwrapv) where
all such transforms would become safe and also reassoc could handle
signed arithmetic freely.  This isn't something for GCC 8 though
(and in its own naturally didn't help the PR), also because it requires
some pass shuffling in the late pipeline.  I'll revisit this for GCC 9.

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

Richard.

2018-01-25  Richard Biener  

PR tree-optimization/81082
* fold-const.c (fold_plusminus_mult_expr): Do not perform the
association if it requires casting to unsigned.
* match.pd ((A * C) +- (B * C) -> (A+-B)): New patterns derived
from fold_plusminus_mult_expr to catch important cases late when
range info is available.

* gcc.dg/vect/pr81082.c: New testcase.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 257047)
+++ gcc/fold-const.c(working copy)
@@ -7097,7 +7097,7 @@ fold_plusminus_mult_expr (location_t loc
 
   /* Same may be zero and thus the operation 'code' may overflow.  Likewise
  same may be minus one and thus the multiplication may overflow.  Perform
- the operations in an unsigned type.  */
+ the sum operation in an unsigned type.  */
   tree utype = unsigned_type_for (type);
   tree tem = fold_build2_loc (loc, code, utype,
  fold_convert_loc (loc, utype, alt0),
@@ -7110,9 +7110,9 @@ fold_plusminus_mult_expr (location_t loc
 return fold_build2_loc (loc, MULT_EXPR, type,
fold_convert (type, tem), same);
 
-  return fold_convert_loc (loc, type,
-  fold_build2_loc (loc, MULT_EXPR, utype, tem,
-   fold_convert_loc (loc, utype, 
same)));
+  /* Do not resort to unsigned multiplication because
+ we lose the no-overflow property of the expression.  */
+  return NULL_TREE;
 }
 
 /* Subroutine of native_encode_expr.  Encode the INTEGER_CST
Index: gcc/match.pd
===
--- gcc/match.pd(revision 257047)
+++ gcc/match.pd(working copy)
@@ -1939,6 +1939,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (minus (convert (view_convert:stype @1))
(convert (view_convert:stype @2)))
 
+/* (A * C) +- (B * C) -> (A+-B) * C and (A * C) +- A -> A * (C+-1).
+Modeled after fold_plusminus_mult_expr.  */
+(if (!TYPE_SATURATING (type)
+ && (!FLOAT_TYPE_P (type) || flag_associative_math))
+ (for plusminus (plus minus)
+  (simplify
+   (plusminus (mult:s @0 @1) (mult:cs @0 @2))
+   (if (!ANY_INTEGRAL_TYPE_P (type)
+|| TYPE_OVERFLOW_WRAPS (type)
+|| (INTEGRAL_TYPE_P (type)
+   && tree_expr_nonzero_p (@0)
+   && expr_not_equal_to (@0, wi::minus_one (TYPE_PRECISION (type)
+(mult (plusminus @1 @2) @0)))
+  /* We cannot generate constant 1 for fract.  */
+  (if (!ALL_FRACT_MODE_P (TYPE_MODE (type)))
+   (simplify
+(plusminus @0 (mult:cs @0 @2))
+(if (!ANY_INTEGRAL_TYPE_P (type)
+|| TYPE_OVERFLOW_WRAPS (type)
+|| (INTEGRAL_TYPE_P (type)
+&& tree_expr_nonzero_p (@0)
+&& expr_not_equal_to (@0, wi::minus_one (TYPE_PRECISION (type)
+ (mult (plusminus { build_one_cst (type); } @2) @0)))
+   (simplify
+(plusminus (mult:cs @0 @2) @0)
+(if (!ANY_INTEGRAL_TYPE_P (type)
+|| TYPE_OVERFLOW_WRAPS (type)
+|| (INTEGRAL_TYPE_P (type)
+&& tree_expr_nonzero_p (@0)
+&& expr_not_equal_to (@0, wi::minus_one (TYPE_PRECISION (type)
+ (mult (plusminus @2 { build_one_cst (type); }) @0))
 
 /* Simplifications of MIN_EXPR, MAX_EXPR, fmin() and fmax().  */
 
Index: gcc/testsuite/gcc.dg/vect/pr81082.c
===
--- gcc/testsuite/gcc.dg/vect/pr81082.c (nonexistent)
+++ gcc/testsuite/gcc.dg/vect/pr81082.c (working copy)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
+
+int
+f (int *x, int b1, int b2, int b3)
+{
+  int foo = 0;
+  for (int i1 = 0; i1 < b1; ++i1)
+for (int i2 = 0; i2 < b2; ++i2)
+  for (int i3 = 0; i3 < b3; ++i3)
+   foo += x[i1 * b2 * b3 + i2 * b3 + (i3 - 1)

Re: [PATCH] Fix PR81082

[Marc Glisse]

On Thu, 25 Jan 2018, Richard Biener wrote:


--- gcc/match.pd(revision 257047)
+++ gcc/match.pd(working copy)
@@ -1939,6 +1939,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (minus (convert (view_convert:stype @1))
(convert (view_convert:stype @2)))

+/* (A * C) +- (B * C) -> (A+-B) * C and (A * C) +- A -> A * (C+-1).
+Modeled after fold_plusminus_mult_expr.  */
+(if (!TYPE_SATURATING (type)
+ && (!FLOAT_TYPE_P (type) || flag_associative_math))
+ (for plusminus (plus minus)
+  (simplify
+   (plusminus (mult:s @0 @1) (mult:cs @0 @2))


No :c on the first mult, so we don't actually handle A*C+B*C?

--
Marc Glisse

Re: [PATCH] Fix PR81082

[Richard Biener]

On Thu, 25 Jan 2018, Marc Glisse wrote:

> On Thu, 25 Jan 2018, Richard Biener wrote:
> 
> > --- gcc/match.pd(revision 257047)
> > +++ gcc/match.pd(working copy)
> > @@ -1939,6 +1939,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >  (minus (convert (view_convert:stype @1))
> > (convert (view_convert:stype @2)))
> > 
> > +/* (A * C) +- (B * C) -> (A+-B) * C and (A * C) +- A -> A * (C+-1).
> > +Modeled after fold_plusminus_mult_expr.  */
> > +(if (!TYPE_SATURATING (type)
> > + && (!FLOAT_TYPE_P (type) || flag_associative_math))
> > + (for plusminus (plus minus)
> > +  (simplify
> > +   (plusminus (mult:s @0 @1) (mult:cs @0 @2))
> 
> No :c on the first mult, so we don't actually handle A*C+B*C?

Hmm, I somehow convinced myself that it's only necessary on one
of the mults...  but you are of course right.  Will re-test with
that fixed.

Richard.

Re: PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

[Bill Schmidt]

On Jan 25, 2018, at 4:09 AM, Alan Modra  wrote:
> 
> vbpermq produces its output in bits 48..63 of the target vector reg,
> so the output cannot be lane swapped.  Bootstrapped and regression
> tested powerpc64le-linux.  OK to apply mainline, and backport to the
> branches?

I can't approve, but FWIW, I agree with this patch.

Bill

> 
> gcc/
>   PR target/84033
>   * config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Exclude
>   UNSPEC_VBPERMQ.  Sort other unspecs.
> gcc/testsuite/
>   PR target/84033
>   * gcc.target/powerpc/swaps-p8-46.c: New.
> 
> diff --git a/gcc/config/rs6000/rs6000-p8swap.c 
> b/gcc/config/rs6000/rs6000-p8swap.c
> index 1f95290..ffcbba9 100644
> --- a/gcc/config/rs6000/rs6000-p8swap.c
> +++ b/gcc/config/rs6000/rs6000-p8swap.c
> @@ -741,6 +741,7 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
> {
> default:
>   break;
> +   case UNSPEC_VBPERMQ:
> case UNSPEC_VMRGH_DIRECT:
> case UNSPEC_VMRGL_DIRECT:
> case UNSPEC_VPACK_SIGN_SIGN_SAT:
> @@ -762,8 +763,14 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
> case UNSPEC_VSUMSWS:
> case UNSPEC_VSUMSWS_DIRECT:
> case UNSPEC_VSX_CONCAT:
> +   case UNSPEC_VSX_CVDPSPN:
> +   case UNSPEC_VSX_CVSPDP:
> +   case UNSPEC_VSX_CVSPDPN:
> +   case UNSPEC_VSX_EXTRACT:
> case UNSPEC_VSX_SET:
> case UNSPEC_VSX_SLDWI:
> +   case UNSPEC_VSX_VEC_INIT:
> +   case UNSPEC_VSX_VSLO:
> case UNSPEC_VUNPACK_HI_SIGN:
> case UNSPEC_VUNPACK_HI_SIGN_DIRECT:
> case UNSPEC_VUNPACK_LO_SIGN:
> @@ -774,12 +781,6 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
> case UNSPEC_VUPKLPX:
> case UNSPEC_VUPKLS_V4SF:
> case UNSPEC_VUPKLU_V4SF:
> -   case UNSPEC_VSX_CVDPSPN:
> -   case UNSPEC_VSX_CVSPDP:
> -   case UNSPEC_VSX_CVSPDPN:
> -   case UNSPEC_VSX_EXTRACT:
> -   case UNSPEC_VSX_VSLO:
> -   case UNSPEC_VSX_VEC_INIT:
>   return 0;
> case UNSPEC_VSPLT_DIRECT:
> case UNSPEC_VSX_XXSPLTD:
> diff --git a/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c 
> b/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
> new file mode 100644
> index 000..23494b6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
> @@ -0,0 +1,34 @@
> +/* { dg-do run { target { powerpc64le-*-* } } } */
> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */
> +/* { dg-options "-mcpu=power8 -O2 " } */
> +
> +typedef __attribute__ ((__aligned__ (8))) unsigned long long __m64;
> +typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
> +
> +/* PR84033.  Extracted from xmmintrin.h but with a pointer param to
> +   allow swaps to happen when not inline.  */
> +int __attribute__ ((__noinline__))
> +_mm_movemask_ps (__m128 *__A)
> +{
> +  __vector __m64 result;
> +  static const __vector unsigned int perm_mask =
> +{
> +  0x00204060, 0x80808080, 0x80808080, 0x80808080
> +};
> +
> +  result = (__vector __m64)
> +__builtin_vec_vbpermq ((__vector unsigned char) (*__A),
> +(__vector unsigned char) perm_mask);
> +  return result[1];
> +}
> +
> +int
> +main (void)
> +{
> +  union { unsigned int i[4]; __m128 m; } x
> += { 0x8000, 0x8000, 0x7fff, 0x7fff };
> +  if (_mm_movemask_ps (&x.m) != 3)
> +__builtin_abort ();
> +  return 0;
> +}
> 
> -- 
> Alan Modra
> Australia Development Lab, IBM
> 

Re: C++ PATCH to fix ICE with vector expr folding (PR c++/83659)

[Jakub Jelinek]

On Fri, Jan 05, 2018 at 09:52:36AM +0100, Richard Biener wrote:
> On Wed, Jan 3, 2018 at 5:31 PM, Marek Polacek  wrote:
> > Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR
> > with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI.
> >
> > The matching code in fold_indirect_ref_1 uses uHWIs so I've followed suit.
> > But that code now also uses poly_uint64 and I'm not sure if any of the
> > constexpr.c code should use it, too.  But this patch fixes the ICE.
> 
> POINTER_PLUS_EXPR offets are to be interpreted as signed (ptrdiff_t)
> so using uhwi and then performing an unsigned division is wrong code.
> See mem_ref_offset how to deal with this (ugh - poly-ints...).  Basically
> you have to force the thing to signed.  Like just use
> 
>   HOST_WIDE_INT offset = TREE_INT_CST_LOW (op01);

Does it really matter here though?  Any negative offsets there are UB, we
should punt on them rather than try to optimize them.
As we known op01 is unsigned, if we check that it fits into shwi_p, it means
it will be 0 to shwi max and then we can handle it in uhwi too.

  /* ((foo*)&vectorfoo)[1] => BIT_FIELD_REF */
  if (VECTOR_TYPE_P (op00type)
  && (same_type_ignoring_top_level_qualifiers_p
-(type, TREE_TYPE (op00type
+(type, TREE_TYPE (op00type)))
+ && tree_fits_shwi_p (op01))
{
- HOST_WIDE_INT offset = tree_to_shwi (op01);
+ unsigned HOST_WIDE_INT offset = tree_to_uhwi (op01);
  tree part_width = TYPE_SIZE (type);
- unsigned HOST_WIDE_INT part_widthi = tree_to_shwi 
(part_width)/BITS_PER_UNIT;
+ unsigned HOST_WIDE_INT part_widthi
+   = tree_to_uhwi (part_width) / BITS_PER_UNIT;
  unsigned HOST_WIDE_INT indexi = offset * BITS_PER_UNIT;
  tree index = bitsize_int (indexi);
  
  if (known_lt (offset / part_widthi,
TYPE_VECTOR_SUBPARTS (op00type)))
return fold_build3_loc (loc,
BIT_FIELD_REF, type, op00,
part_width, index);

}

Jakub

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

[Steve Kargl]

On Thu, Jan 25, 2018 at 08:37:54AM +0100, Thomas Koenig wrote:
> First, why is
> 
> > @@ -2253,22 +2253,19 @@ gfc_simplify_dim (gfc_expr *x, gfc_expr *y)
> >   gfc_expr*
> >   gfc_simplify_dot_product (gfc_expr *vector_a, gfc_expr *vector_b)
> >   {
> > +  /* If vector_a is a zero-sized array, the result is 0 for INTEGER,
> > + REAL, and COMPLEX types and .false. for LOGICAL.  */
> > +  if (vector_a->shape && mpz_get_si (vector_a->shape[0]) == 0)
> > +{
> > +  if (vector_a->ts.type == BT_LOGICAL)
> > +   return gfc_get_logical_expr (gfc_default_logical_kind, NULL, false);
> > +  else
> > +   return gfc_get_int_expr (gfc_default_integer_kind, NULL, 0);
> > +}
> 
> in front of

There are two problems with is_constant_array_expr.  First,
it doesn't handle zero-sized arrays.  It returns false, and
dot_product(a,a,) is not simplified.  The dot_product reaches
gfc_conv_intrinsic_dot_product, which tries to generate
in-line code, except it isn't prepared to deal with zero-sized
arrays and ICE occurs.  Second, with the code of the testcase
on entering gfc_simplify_dot_product, we have

vector_a->expr_type == EXPR_VARIABLE
vector_a->rank == 1
vector_a->shape == some_valid_pointer.

after is_constant_array_expr is called we have

vector_a->expr_type == EXPR_CONSTANT
vector_a->rank == 1
vector_a->shape == NULL.

This NULL does not play well gfc_conv_intrinsic_dot_product().
The testcase code arrives here where some_valid_pointer points
to a GMP entity with a value of 0, i.e., a zero-sized array.
So, gfortran can simplify dot_product as I have done
above.

> > -  gfc_expr temp;
> > -
> > if (!is_constant_array_expr (vector_a)
> > || !is_constant_array_expr (vector_b))
> >   return NULL;
> 
> and / or why is the test only done for one variable?

gfc_check_dot_product checks that shape of vector_a
and shape of vector_b are the same.  If vector_a is zero
sized, then so is vector_b.

> 
> Second, why do you remove this
> 
> > -  temp.value.op.op = INTRINSIC_NONE;
> > -  temp.value.op.op1 = vector_a;
> > -  temp.value.op.op2 = vector_b;
> > -  gfc_type_convert_binary (&temp, 1);
> 
> block of code?

It is dead code.  temp is set to the typespec of 
the mixed-mode math result, but it is never used.
compute_dot_product does the mixed-mode math,
because it uses gfc_add() from arith.c.

> What would happen for code like
> 
>integer, dimension(2), parameter :: a = [ 1,2]
>real, dimension(2), parameter :: b = [1.0,2.0]
>real, parameter :: c = dot_product(a,b)

gfortran rejects it as it isn't a valid Fortran unit.  :-)

gfcx -fdump-tree-original -o z a.f90 && ./z
   5.

cat a.f90.003t.original
  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 4;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
{
  static real(kind=4) C.3752 = 5.0e+0;

  _gfortran_transfer_real_write (&dt_parm.0, &C.3752, 4);
}
_gfortran_st_write_done (&dt_parm.0);
  }

-- 
Steve

Go patch committed: Don't write sink constants to the C header file

[Ian Lance Taylor]

This patch to the Go frontend skips writing sink constants to the C
header file.  These are constants named "_".  We were generating
nonsensical $sinkconst names in the header files, which are
unnecessary and can break building the C code in some cases.
Bootstrapped on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257033)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-0bbc03f81c862fb35be3edee9824698a7892a17e
+016ea21c4cba324c6ea6424da7988c6f985e671b
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc   (revision 257033)
+++ gcc/go/gofrontend/gogo.cc   (working copy)
@@ -4633,7 +4633,9 @@ Gogo::write_c_header()
 
   if (no->is_type() && no->type_value()->struct_type() != NULL)
types.push_back(no);
-  if (no->is_const() && no->const_value()->type()->integer_type() != NULL)
+  if (no->is_const()
+ && no->const_value()->type()->integer_type() != NULL
+ && !no->const_value()->is_sink())
{
  Numeric_constant nc;
  unsigned long val;

[og7] Build libffi during bootstrap.

[Cesar Philippidis]

I've applied this patch to openacc-gcc-7-branch to build libffi during
bootstrap whenever it's required by libgomp. This was causing the host
OpenACC execution test to fail in libgomp because the struct containing
the offloaded data mappings wasn't being expanded into individual
variables at runtime.

Cesar
Build libffi during bootstrap.

2018-01-25  Cesar Philippidis  

	* Makefile.def: Bootstrap module libffi. Add libffi dependency
	to all-target-libgomp.
	* Makefile.in: Regenerate.
	* configure.ac: Add libffi to bootstrap_target_libs when libgomp
	is bootstrapped.
	* configure: Regenerate.

diff --git a/Makefile.def b/Makefile.def
index 5e94062fa75..23e3b024e40 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -165,7 +165,7 @@ target_modules = { module= libtermcap; no_check=true;
missing=maintainer-clean; };
 target_modules = { module= winsup; };
 target_modules = { module= libgloss; no_check=true; };
-target_modules = { module= libffi; no_install=true; };
+target_modules = { module= libffi; bootstrap=true; no_install=true; };
 target_modules = { module= zlib; };
 target_modules = { module= rda; };
 target_modules = { module= libada; };
@@ -550,6 +550,7 @@ dependencies = { module=configure-target-libgo; on=all-target-libstdc++-v3; };
 dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
 dependencies = { module=all-target-libgo; on=all-target-libffi; };
 dependencies = { module=all-target-libgo; on=all-target-libatomic; };
+dependencies = { module=all-target-libgomp; on=all-target-libffi; };
 dependencies = { module=configure-target-libgomp; on=configure-target-libffi; };
 dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; };
 dependencies = { module=configure-target-liboffloadmic; on=configure-target-libgomp; };
diff --git a/Makefile.in b/Makefile.in
index 9b4497e3943..ad42ffdf7ab 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1161,7 +1161,9 @@ all-target: maybe-all-target-libhsail-rt
 all-target: maybe-all-target-libtermcap
 all-target: maybe-all-target-winsup
 all-target: maybe-all-target-libgloss
+@if target-libffi-no-bootstrap
 all-target: maybe-all-target-libffi
+@endif target-libffi-no-bootstrap
 all-target: maybe-all-target-zlib
 all-target: maybe-all-target-rda
 all-target: maybe-all-target-libada
@@ -47882,7 +47884,6 @@ configure-target-libffi: stage_current
 @if target-libffi
 maybe-configure-target-libffi: configure-target-libffi
 configure-target-libffi: 
-	@: $(MAKE); $(unstage)
 	@r=`${PWD_COMMAND}`; export r; \
 	s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
 	echo "Checking multilib configuration for libffi..."; \
@@ -47920,6 +47921,367 @@ configure-target-libffi:
 
 
 
+.PHONY: configure-stage1-target-libffi maybe-configure-stage1-target-libffi
+maybe-configure-stage1-target-libffi:
+@if target-libffi-bootstrap
+maybe-configure-stage1-target-libffi: configure-stage1-target-libffi
+configure-stage1-target-libffi:
+	@[ $(current_stage) = stage1 ] || $(MAKE) stage1-start
+	@$(SHELL) $(srcdir)/mkinstalldirs $(TARGET_SUBDIR)/libffi
+	@r=`${PWD_COMMAND}`; export r; \
+	s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
+	TFLAGS="$(STAGE1_TFLAGS)"; \
+	echo "Checking multilib configuration for libffi..."; \
+	$(CC_FOR_TARGET) --print-multi-lib > $(TARGET_SUBDIR)/libffi/multilib.tmp 2> /dev/null; \
+	if test -r $(TARGET_SUBDIR)/libffi/multilib.out; then \
+	  if cmp -s $(TARGET_SUBDIR)/libffi/multilib.tmp $(TARGET_SUBDIR)/libffi/multilib.out; then \
+	rm -f $(TARGET_SUBDIR)/libffi/multilib.tmp; \
+	  else \
+	rm -f $(TARGET_SUBDIR)/libffi/Makefile; \
+	mv $(TARGET_SUBDIR)/libffi/multilib.tmp $(TARGET_SUBDIR)/libffi/multilib.out; \
+	  fi; \
+	else \
+	  mv $(TARGET_SUBDIR)/libffi/multilib.tmp $(TARGET_SUBDIR)/libffi/multilib.out; \
+	fi; \
+	test ! -f $(TARGET_SUBDIR)/libffi/Makefile || exit 0; \
+	$(NORMAL_TARGET_EXPORTS) \
+	CFLAGS="$(CFLAGS_FOR_TARGET)"; export CFLAGS; \
+	CXXFLAGS="$(CXXFLAGS_FOR_TARGET)"; export CXXFLAGS; \
+	LIBCFLAGS="$(LIBCFLAGS_FOR_TARGET)"; export LIBCFLAGS;  \
+	echo Configuring stage 1 in $(TARGET_SUBDIR)/libffi; \
+	$(SHELL) $(srcdir)/mkinstalldirs $(TARGET_SUBDIR)/libffi; \
+	cd $(TARGET_SUBDIR)/libffi || exit 1; \
+	case $(srcdir) in \
+	  /* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
+	  *) topdir=`echo $(TARGET_SUBDIR)/libffi/ | \
+		sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
+	esac; \
+	module_srcdir=libffi; \
+	$(SHELL) $$s/$$module_srcdir/configure \
+	  --srcdir=$${topdir}/$$module_srcdir \
+	  $(TARGET_CONFIGARGS) --build=${build_alias} --host=${target_alias} \
+	  --target=${target_alias} \
+	   \
+	  $(STAGE1_CONFIGURE_FLAGS)
+@endif target-libffi-bootstrap
+
+.PHONY: configure-stage2-target-libffi maybe-configure-stage2-target-libffi
+maybe-configure-stage2-target-libffi:
+@if target-libffi-bootstrap
+maybe-configure-stage2-target-libffi: configure-stage2-target-libffi
+configure-stage2-target-libffi:
+	@[ $(current_stage) = stage2 ] || $(MAKE) stage2-start
+	@$(SHEL

[C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

[Jakub Jelinek]

Hi!

Unnamed bitfields are not data members, so we should ignore them when
counting the members or picking up members to initialize from, and
also should ignore them in find_decomp_class_base, they can appear
in various bases etc. and still there could be just one base containing
direct non-static data members.

The patch also fixes an issue I ran into on the testcase, when recursing
from type in which we've found any direct non-static data members, we have
ret set to that type and if the recursion doesn't find anything nor an
error, it returns that ret rather than NULL.  So, if t == ret, it just
means it didn't find anything preventing return of ret to the caller.

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

2018-01-25  Jakub Jelinek  

PR c++/84031
* decl.c (find_decomp_class_base): Ignore unnamed bitfields.  Ignore
recursive calls that return ret.
(cp_finish_decomp): Ignore unnamed bitfields.

* g++.dg/cpp1z/decomp36.C: New test.

--- gcc/cp/decl.c.jj2018-01-24 17:18:42.376392255 +0100
+++ gcc/cp/decl.c   2018-01-25 10:22:51.267122576 +0100
@@ -7206,7 +7206,9 @@ find_decomp_class_base (location_t loc,
 {
   bool member_seen = false;
   for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
-if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
+if (TREE_CODE (field) != FIELD_DECL
+   || DECL_ARTIFICIAL (field)
+   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
   continue;
 else if (ret)
   return type;
@@ -7245,7 +7247,7 @@ find_decomp_class_base (location_t loc,
   tree t = find_decomp_class_base (loc, TREE_TYPE (base_binfo), ret);
   if (t == error_mark_node)
return error_mark_node;
-  if (t != NULL_TREE)
+  if (t != NULL_TREE && t != ret)
{
  if (ret == type)
{
@@ -7256,9 +7258,6 @@ find_decomp_class_base (location_t loc,
}
  else if (orig_ret != NULL_TREE)
return t;
- else if (ret == t)
-   /* OK, found the same base along another path.  We'll complain
-  in convert_to_base if it's ambiguous.  */;
  else if (ret != NULL_TREE)
{
  error_at (loc, "cannot decompose class type %qT: its base "
@@ -7645,7 +7644,9 @@ cp_finish_decomp (tree decl, tree first,
  goto error_out;
}
   for (tree field = TYPE_FIELDS (btype); field; field = TREE_CHAIN (field))
-   if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
+   if (TREE_CODE (field) != FIELD_DECL
+   || DECL_ARTIFICIAL (field)
+   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
  continue;
else
  eltscnt++;
@@ -7660,7 +7661,9 @@ cp_finish_decomp (tree decl, tree first,
}
   unsigned int i = 0;
   for (tree field = TYPE_FIELDS (btype); field; field = TREE_CHAIN (field))
-   if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
+   if (TREE_CODE (field) != FIELD_DECL
+   || DECL_ARTIFICIAL (field)
+   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
  continue;
else
  {
--- gcc/testsuite/g++.dg/cpp1z/decomp36.C.jj2018-01-25 10:25:23.900154509 
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp36.C   2018-01-25 10:25:15.996152860 
+0100
@@ -0,0 +1,19 @@
+// PR c++/84031
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+struct A { unsigned char : 1, a1 : 1, a2 : 2, : 1, a3 : 3; };
+struct B { unsigned char : 1, : 7; };
+struct C : B { constexpr C () : c1 (1), c2 (2), c3 (3) {} unsigned char : 1, 
c1 : 1, c2 : 2, : 1, c3 : 3; };
+struct D : C { constexpr D () {} unsigned char : 1, : 7; };
+
+int
+main ()
+{
+  static constexpr A a { 1, 2, 3 };
+  const auto &[a1, a2, a3] = a;// { dg-warning "only available 
with" "" { target c++14_down } }
+  static_assert (a1 == 1 && a2 == 2 && a3 == 3, "");
+  static constexpr D d;
+  const auto &[d1, d2, d3] = d;// { dg-warning "only available 
with" "" { target c++14_down } }
+  static_assert (d1 == 1 && d2 == 2 && d3 == 3, "");
+}

Jakub

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

[Jakub Jelinek]

On Wed, Jan 24, 2018 at 06:51:54PM +0100, Richard Biener wrote:
> >Well, "omp declare simd" is a part of the ABI just for the original
> >exported
> >functions, for everything else it is a pure optimization, but I'm not
> >sure
> >if we want to deoptimize e.g. callers of these functions outside of
> >loops
> >by disabling the signature changing cloning for those.  For calls from
> >within OpenMP simd regions or other loops where we try hard to
> >vectorize
> >them, it might make sense not to change those callers, for callers from
> >other loops, a question.
> 
> Until we can distinguish the cases I think not changing the signature by
> default might be a good thing.

Done thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.

2018-01-25  Jakub Jelinek  

PR middle-end/83977
* ipa-fnsummary.c (compute_fn_summary): Clear can_change_signature
on functions with #pragma omp declare simd or functions with simd
attribute.
* omp-simd-clone.c (expand_simd_clones): Revert 2018-01-24 change.
* config/i386/i386.c (ix86_simd_clone_compute_vecsize_and_simdlen):
Remove trailing \n from warning_at calls.

* c-c++-common/gomp/pr83977-1.c: Add -w to dg-options.

--- gcc/ipa-fnsummary.c.jj  2018-01-25 12:13:06.651327787 +0100
+++ gcc/ipa-fnsummary.c 2018-01-25 12:14:22.282340706 +0100
@@ -2467,7 +2467,11 @@ compute_fn_summary (struct cgraph_node *
 info->inlinable = tree_inlinable_function_p (node->decl);
 
/* Type attributes can use parameter indices to describe them.  */
-   if (TYPE_ATTRIBUTES (TREE_TYPE (node->decl)))
+   if (TYPE_ATTRIBUTES (TREE_TYPE (node->decl))
+  /* Likewise for #pragma omp declare simd functions or functions
+ with simd attribute.  */
+  || lookup_attribute ("omp declare simd",
+   DECL_ATTRIBUTES (node->decl)))
 node->local.can_change_signature = false;
else
 {
--- gcc/omp-simd-clone.c.jj 2018-01-25 12:13:06.624327783 +0100
+++ gcc/omp-simd-clone.c2018-01-25 12:14:22.282340706 +0100
@@ -1574,10 +1574,6 @@ expand_simd_clones (struct cgraph_node *
   tree attr = lookup_attribute ("omp declare simd",
DECL_ATTRIBUTES (node->decl));
   if (attr == NULL_TREE
-  /* Ignore artificial decls with an abstract origin, results of function
-cloning, versioning etc.  We want to handle certain builtins
-with simd attribute, like __builtin_sin.  */
-  || (DECL_ARTIFICIAL (node->decl) && DECL_ABSTRACT_ORIGIN (node->decl))
   || node->global.inlined_to
   || lookup_attribute ("noclone", DECL_ATTRIBUTES (node->decl)))
 return;
--- gcc/config/i386/i386.c.jj   2018-01-24 23:41:33.714031847 +0100
+++ gcc/config/i386/i386.c  2018-01-25 12:16:02.231357778 +0100
@@ -50224,7 +50224,7 @@ ix86_simd_clone_compute_vecsize_and_simd
break;
   default:
warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
-   "unsupported return type %qT for simd\n", ret_type);
+   "unsupported return type %qT for simd", ret_type);
return 0;
   }
 
@@ -50246,7 +50246,7 @@ ix86_simd_clone_compute_vecsize_and_simd
break;
   default:
warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
-   "unsupported argument type %qT for simd\n", TREE_TYPE (t));
+   "unsupported argument type %qT for simd", TREE_TYPE (t));
return 0;
   }
 
--- gcc/testsuite/c-c++-common/gomp/pr83977-1.c.jj  2018-01-24 
17:26:25.217357997 +0100
+++ gcc/testsuite/c-c++-common/gomp/pr83977-1.c 2018-01-25 12:18:34.196383735 
+0100
@@ -1,6 +1,6 @@
 /* PR middle-end/83977 */
 /* { dg-do compile } */
-/* { dg-additional-options "-O2" } */
+/* { dg-additional-options "-O2 -w" } */
 
 struct S { int a, b, c; };
 


Jakub

libbacktrace patch committed: Another memcpy -> coff_read4 fix

[Ian Lance Taylor]

This libbacktrace patch fixes another cases where memcpy was used in a
way that would leave some bytes uninitialized on a 64-bit system.
Committed to mainline.

Ian

2018-01-25  Ian Lance Taylor  

* pecoff.c (coff_add): Another memcpy -> coff_read4 fix.
Index: pecoff.c
===
--- pecoff.c(revision 257040)
+++ pecoff.c(working copy)
@@ -631,10 +631,10 @@ coff_add (struct backtrace_state *state,
 goto fail;
 
   {
-const char *vptr = (const char *)fhdr_view.data;
+const unsigned char *vptr = fhdr_view.data;
 
 if (vptr[0] == 'M' && vptr[1] == 'Z')
-  memcpy (&fhdr_off, vptr + 0x3c, 4);
+  fhdr_off = coff_read4 (vptr + 0x3c);
 else
   fhdr_off = 0;
   }

libbacktrace patch committed: Only free sym_view if it is valid

[Ian Lance Taylor]

Another libbacktrace patch to avoid use of uninitialized memory: only
free sym_view if it is valid.  Committed to mainline.

Ian

2018-01-25  Ian Lance Taylor  

* pecoff.c (coff_add): Only release syms_view if it is valid.
Index: pecoff.c
===
--- pecoff.c(revision 257052)
+++ pecoff.c(working copy)
@@ -804,8 +804,11 @@ coff_add (struct backtrace_state *state,
 
   backtrace_release_view (state, §s_view, error_callback, data);
   sects_view_valid = 0;
-  backtrace_release_view (state, &syms_view, error_callback, data);
-  syms_view_valid = 0;
+  if (syms_view_valid)
+{
+  backtrace_release_view (state, &syms_view, error_callback, data);
+  syms_view_valid = 0;
+}
 
   /* Read all the debug sections in a single view, since they are
  probably adjacent in the file.  We never release this view.  */

Re: [C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

[Jason Merrill]

OK.

On Thu, Jan 25, 2018 at 10:26 AM, Jakub Jelinek  wrote:
> Hi!
>
> Unnamed bitfields are not data members, so we should ignore them when
> counting the members or picking up members to initialize from, and
> also should ignore them in find_decomp_class_base, they can appear
> in various bases etc. and still there could be just one base containing
> direct non-static data members.
>
> The patch also fixes an issue I ran into on the testcase, when recursing
> from type in which we've found any direct non-static data members, we have
> ret set to that type and if the recursion doesn't find anything nor an
> error, it returns that ret rather than NULL.  So, if t == ret, it just
> means it didn't find anything preventing return of ret to the caller.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-01-25  Jakub Jelinek  
>
> PR c++/84031
> * decl.c (find_decomp_class_base): Ignore unnamed bitfields.  Ignore
> recursive calls that return ret.
> (cp_finish_decomp): Ignore unnamed bitfields.
>
> * g++.dg/cpp1z/decomp36.C: New test.
>
> --- gcc/cp/decl.c.jj2018-01-24 17:18:42.376392255 +0100
> +++ gcc/cp/decl.c   2018-01-25 10:22:51.267122576 +0100
> @@ -7206,7 +7206,9 @@ find_decomp_class_base (location_t loc,
>  {
>bool member_seen = false;
>for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
> -if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
> +if (TREE_CODE (field) != FIELD_DECL
> +   || DECL_ARTIFICIAL (field)
> +   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
>continue;
>  else if (ret)
>return type;
> @@ -7245,7 +7247,7 @@ find_decomp_class_base (location_t loc,
>tree t = find_decomp_class_base (loc, TREE_TYPE (base_binfo), ret);
>if (t == error_mark_node)
> return error_mark_node;
> -  if (t != NULL_TREE)
> +  if (t != NULL_TREE && t != ret)
> {
>   if (ret == type)
> {
> @@ -7256,9 +7258,6 @@ find_decomp_class_base (location_t loc,
> }
>   else if (orig_ret != NULL_TREE)
> return t;
> - else if (ret == t)
> -   /* OK, found the same base along another path.  We'll complain
> -  in convert_to_base if it's ambiguous.  */;
>   else if (ret != NULL_TREE)
> {
>   error_at (loc, "cannot decompose class type %qT: its base "
> @@ -7645,7 +7644,9 @@ cp_finish_decomp (tree decl, tree first,
>   goto error_out;
> }
>for (tree field = TYPE_FIELDS (btype); field; field = TREE_CHAIN 
> (field))
> -   if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
> +   if (TREE_CODE (field) != FIELD_DECL
> +   || DECL_ARTIFICIAL (field)
> +   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
>   continue;
> else
>   eltscnt++;
> @@ -7660,7 +7661,9 @@ cp_finish_decomp (tree decl, tree first,
> }
>unsigned int i = 0;
>for (tree field = TYPE_FIELDS (btype); field; field = TREE_CHAIN 
> (field))
> -   if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
> +   if (TREE_CODE (field) != FIELD_DECL
> +   || DECL_ARTIFICIAL (field)
> +   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
>   continue;
> else
>   {
> --- gcc/testsuite/g++.dg/cpp1z/decomp36.C.jj2018-01-25 10:25:23.900154509 
> +0100
> +++ gcc/testsuite/g++.dg/cpp1z/decomp36.C   2018-01-25 10:25:15.996152860 
> +0100
> @@ -0,0 +1,19 @@
> +// PR c++/84031
> +// { dg-do compile { target c++11 } }
> +// { dg-options "" }
> +
> +struct A { unsigned char : 1, a1 : 1, a2 : 2, : 1, a3 : 3; };
> +struct B { unsigned char : 1, : 7; };
> +struct C : B { constexpr C () : c1 (1), c2 (2), c3 (3) {} unsigned char : 1, 
> c1 : 1, c2 : 2, : 1, c3 : 3; };
> +struct D : C { constexpr D () {} unsigned char : 1, : 7; };
> +
> +int
> +main ()
> +{
> +  static constexpr A a { 1, 2, 3 };
> +  const auto &[a1, a2, a3] = a;// { dg-warning "only 
> available with" "" { target c++14_down } }
> +  static_assert (a1 == 1 && a2 == 2 && a3 == 3, "");
> +  static constexpr D d;
> +  const auto &[d1, d2, d3] = d;// { dg-warning "only 
> available with" "" { target c++14_down } }
> +  static_assert (d1 == 1 && d2 == 2 && d3 == 3, "");
> +}
>
> Jakub

Re: [C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

[Paolo Carlini]

Hi all,

On 25/01/2018 16:26, Jakub Jelinek wrote:

+   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
By the way, I see we are accumulating uses of DECL_C_BIT_FIELD && 
!DECL_NAME, shall we add a new macro? For Stage 1? In case, how shall we 
name it?


Paolo.

Re: [C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

[Jason Merrill]

On Thu, Jan 25, 2018 at 11:17 AM, Paolo Carlini
 wrote:
> Hi all,
>
> On 25/01/2018 16:26, Jakub Jelinek wrote:
>>
>> +   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
>
> By the way, I see we are accumulating uses of DECL_C_BIT_FIELD &&
> !DECL_NAME, shall we add a new macro? For Stage 1? In case, how shall we
> name it?

Sure.  DECL_UNNAMED_BIT_FIELD seems like the obvious choice.

Jason

Re: [C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

[Paolo Carlini]

Hi,

On 25/01/2018 17:25, Jason Merrill wrote:

On Thu, Jan 25, 2018 at 11:17 AM, Paolo Carlini
 wrote:

Hi all,

On 25/01/2018 16:26, Jakub Jelinek wrote:

+   || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))

By the way, I see we are accumulating uses of DECL_C_BIT_FIELD &&
!DECL_NAME, shall we add a new macro? For Stage 1? In case, how shall we
name it?

Sure.  DECL_UNNAMED_BIT_FIELD seems like the obvious choice.
Great. I'll take care of that. We got quite a few instances, 6 in the C 
front-end too. In the C++ front-end a couple checks were actually 
exploiting the fact that DECL_NAME can also be tested on 
non-FIELD_DECLs. The below is what  I have so far and I'm testing (+ the 
new instances corresponding to Jakub's fix).


Paolo.

//
Index: c/c-typeck.c
===
--- c/c-typeck.c(revision 257058)
+++ c/c-typeck.c(working copy)
@@ -7955,8 +7955,7 @@ really_start_incremental_init (tree type)
   constructor_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
 
   constructor_unfilled_fields = constructor_fields;
@@ -8161,8 +8160,7 @@ push_init_level (location_t loc, int implicit,
   constructor_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
 
   constructor_unfilled_fields = constructor_fields;
@@ -8930,8 +8928,7 @@ set_nonincremental_init (struct obstack * braced_i
   constructor_unfilled_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_unfilled_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_unfilled_fields))
constructor_unfilled_fields = TREE_CHAIN (constructor_unfilled_fields);
 
 }
@@ -9300,8 +9297,7 @@ output_init_element (location_t loc, tree value, t
 
   /* Skip any nameless bit fields.  */
   while (constructor_unfilled_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_unfilled_fields))
constructor_unfilled_fields =
  DECL_CHAIN (constructor_unfilled_fields);
 }
@@ -9665,8 +9661,8 @@ process_init_element (location_t loc, struct c_exp
  constructor_unfilled_fields = DECL_CHAIN (constructor_fields);
  /* Skip any nameless bit fields.  */
  while (constructor_unfilled_fields != 0
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == 0)
+&& (DECL_UNNAMED_BIT_FIELD
+(constructor_unfilled_fields)))
constructor_unfilled_fields =
  DECL_CHAIN (constructor_unfilled_fields);
}
@@ -9675,8 +9671,7 @@ process_init_element (location_t loc, struct c_exp
  constructor_fields = DECL_CHAIN (constructor_fields);
  /* Skip any nameless bit fields at the beginning.  */
  while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
}
   else if (TREE_CODE (constructor_type) == UNION_TYPE)
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 257058)
+++ c-family/c-common.h (working copy)
@@ -939,6 +939,10 @@ extern void c_parse_final_cleanups (void);
 #define CLEAR_DECL_C_BIT_FIELD(NODE) \
   (DECL_LANG_FLAG_4 (FIELD_DECL_CHECK (NODE)) = 0)
 
+/* True if the decl was an unnamed bitfield.  */
+#define DECL_UNNAMED_BIT_FIELD(NODE) \
+  (DECL_C_BIT_FIELD (NODE) && !DECL_NAME (NODE))
+
 extern tree do_case (location_t, tree, tree);
 extern tree build_stmt (location_t, enum tree_code, ...);
 extern tree build_real_imag_expr (location_t, enum tree_code, tree);
Index: cp/class.c

Re: [PATCH] Fix missing profiles with PGO (PR tree-optimization/83051).

[Jan Hubicka]

> Hello.
> 
> Following ICE can be seen when we have -fprofile-generate or -fprofile-use w/ 
> missing
> gcda file. I hope the proper fix is to check for reliable profile.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Ready to be installed?
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-01-19  Martin Liska  
> 
>   PR tree-optimization/83051
>   * predict.c (handle_missing_profiles): Consider profile only
>   if it's reliable.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-01-19  Martin Liska  
> 
>   PR tree-optimization/83051
>   * gcc.dg/torture/pr83055.c: New test.

Hi,
the problem here is that zero profiles are detected incorrectly because
they should be done at IPA level.
While doing that I also noticed that drop_profile has bug where it does
not set up node's profile that eventually leads to ICE in IRA
if the logic for dropping profiles is bad.

Bootstrapped/regtested x86_64-linux, will commit it shortly.

PR middle-end/83055
* predict.c (drop_profile): Do not push/pop cfun; update also
node->count.
(handle_missing_profiles): Fix logic looking for zero profiles.

* gcc.dg/torture/pr83055.c: New testcase.
Index: predict.c
===
--- predict.c   (revision 257010)
+++ predict.c   (working copy)
@@ -3311,32 +3311,28 @@ drop_profile (struct cgraph_node *node,
 }
 
   basic_block bb;
-  push_cfun (DECL_STRUCT_FUNCTION (node->decl));
-  if (flag_guess_branch_prob)
+  if (opt_for_fn (node->decl, flag_guess_branch_prob))
 {
   bool clear_zeros
-= ENTRY_BLOCK_PTR_FOR_FN
-(DECL_STRUCT_FUNCTION (node->decl))->count.nonzero_p ();
+= !ENTRY_BLOCK_PTR_FOR_FN (fn)->count.nonzero_p ();
   FOR_ALL_BB_FN (bb, fn)
if (clear_zeros || !(bb->count == profile_count::zero ()))
  bb->count = bb->count.guessed_local ();
-  DECL_STRUCT_FUNCTION (node->decl)->cfg->count_max =
-DECL_STRUCT_FUNCTION (node->decl)->cfg->count_max.guessed_local ();
+  fn->cfg->count_max = fn->cfg->count_max.guessed_local ();
 }
   else
 {
   FOR_ALL_BB_FN (bb, fn)
bb->count = profile_count::uninitialized ();
-  DECL_STRUCT_FUNCTION (node->decl)->cfg->count_max
-= profile_count::uninitialized ();
+  fn->cfg->count_max = profile_count::uninitialized ();
 }
-  pop_cfun ();
 
   struct cgraph_edge *e;
   for (e = node->callees; e; e = e->next_callee)
 e->count = gimple_bb (e->call_stmt)->count;
   for (e = node->indirect_calls; e; e = e->next_callee)
 e->count = gimple_bb (e->call_stmt)->count;
+  node->count = ENTRY_BLOCK_PTR_FOR_FN (fn)->count;
   
   profile_status_for_fn (fn)
   = (flag_guess_branch_prob ? PROFILE_GUESSED : PROFILE_ABSENT);
@@ -3373,12 +3369,12 @@ handle_missing_profiles (void)
   gcov_type max_tp_first_run = 0;
   struct function *fn = DECL_STRUCT_FUNCTION (node->decl);
 
-  if (!(node->count == profile_count::zero ()))
+  if (node->count.ipa ().nonzero_p ())
 continue;
   for (e = node->callers; e; e = e->next_caller)
-   if (e->count.initialized_p () && e->count > 0)
+   if (e->count.ipa ().initialized_p () && e->count.ipa () > 0)
  {
-call_count = call_count + e->count;
+call_count = call_count + e->count.ipa ();
 
if (e->caller->tp_first_run > max_tp_first_run)
  max_tp_first_run = e->caller->tp_first_run;
@@ -3411,7 +3407,8 @@ handle_missing_profiles (void)
   struct cgraph_node *callee = e->callee;
   struct function *fn = DECL_STRUCT_FUNCTION (callee->decl);
 
-  if (callee->count > 0)
+  if (!(e->count.ipa () == profile_count::zero ())
+ && callee->count.ipa ().nonzero_p ())
 continue;
   if ((DECL_COMDAT (callee->decl) || DECL_EXTERNAL (callee->decl))
  && fn && fn->cfg
Index: testsuite/gcc.dg/torture/pr83055.c
===
--- testsuite/gcc.dg/torture/pr83055.c  (revision 0)
+++ testsuite/gcc.dg/torture/pr83055.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fprofile-generate" } */
+
+void __attribute__ ((__cold__)) a (void);
+void b (void);
+void __attribute__ ((noinline)) c (void) { a (); }
+
+void
+d (void)
+{
+  b ();
+  c ();
+}

libgo patch committed: fix lfstackUnpack on ia64

[Ian Lance Taylor]

This libgo patch by James Clarke fixes lfstackUnpack on ia64.  The top
three region number bits must be masked out before right-shifting the
address bits into place, otherwise they will be copied down into the
lower always-zero address bits.  Bootstrapped and ran Go runtime tests
on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257049)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-016ea21c4cba324c6ea6424da7988c6f985e671b
+553e04735d1be372c596c720bcaea27e050b13a6
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/lfstack_64bit.go
===
--- libgo/go/runtime/lfstack_64bit.go   (revision 256593)
+++ libgo/go/runtime/lfstack_64bit.go   (working copy)
@@ -78,7 +78,7 @@ func lfstackUnpack(val uint64) *lfnode {
return (*lfnode)(unsafe.Pointer(uintptr(int64(val) >> 
sparcLinuxCntBits << 3)))
}
if GOARCH == "ia64" {
-   return 
(*lfnode)(unsafe.Pointer(uintptr((val>>ia64CntBits<<3)&(1<<(64-3)-1) | 
val&^(1<<(64-3)-1
+   return (*lfnode)(unsafe.Pointer(uintptr(((val & (1<<(64-3) - 
1)) >> ia64CntBits << 3) | val&^(1<<(64-3)-1
}
if GOARCH == "ppc64" && GOOS == "aix" {
if val&(1<<63) != 0 {

Re: bugs in external debug info support in libbacktrace

[Ian Lance Taylor]

On Mon, Nov 27, 2017 at 2:23 AM, Milian Wolff  wrote:
>
> I was made aware that libbacktrace got support for external debug info with
> [1], great work! I have just synced the latest libbacktrace into heaptrack [2]
> in a local branch and played around with it and noticed two limitations:
>
> [1]: https://github.com/gcc-mirror/gcc/commit/
> b919941efc58035debbcf69b645c072b7dd6ba4e
> [2]: https://github.com/KDE/heaptrack
>
> a) elf_open_debugfile_by_debuglink checks the crc, even if it is not provided
> by the debug file. I.e. I have a file where `debuglink_crc == 0`, but the
> got_crc calculated from elf_crc32_file is non-zero. I have patched this
> locally with the following to make it work for me:
>
> diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> index 06823fcf59b..24bf58728fd 100644
> --- a/libbacktrace/elf.c
> +++ b/libbacktrace/elf.c
> @@ -1005,7 +1005,7 @@ elf_open_debugfile_by_debuglink (struct backtrace_state
> *state,
>if (ddescriptor < 0)
>  return -1;
>
> -  got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
> +  got_crc = debuglink_crc ? elf_crc32_file (state, ddescriptor,
> error_callback, data) : 0;
>if (got_crc != debuglink_crc)
>  {
>backtrace_close (ddescriptor, error_callback, data);

Thanks.  I fixed this problem with a slightly different patch,
appended.  Committed to mainline.


> b) elf_add guards the code to inspect the symtab-shndx with a `&& !debuginfo`
> check in loc 2797. This results in all files with separate debug info yielding
> `found_sym = 0` when calling elf_add, and symbol resolution is broken.
> Personally I have patched this check out to make symbol resolution work for
> me:
>
> diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> index 06823fcf59b..6876bd3ed8e 100644
> --- a/libbacktrace/elf.c
> +++ b/libbacktrace/elf.c
> @@ -2794,7 +2794,7 @@ elf_add (struct backtrace_state *state, const char
> *filename, int descriptor,
>
>if (symtab_shndx == 0)
>  symtab_shndx = dynsym_shndx;
> -  if (symtab_shndx != 0 && !debuginfo)
> +  if (symtab_shndx != 0)
>  {
>const b_elf_shdr *symtab_shdr;
>unsigned int strtab_shndx;
>
> Could you please check whether the two patches above could be upstreamed?

I don't think that's the right approach.  In the appended patch I skip
clearing *found_sym if debuginfo is set.  I hope that will fix the
problem.

Ian

2018-01-25  Ian Lance Taylor  

* elf.c (elf_open_debugfile_by_debuglink): Don't check CRC if the
desired CRC is zero.
(elf_add): Don't clear *found_sym and *found_dwarf if debuginfo.
Index: elf.c
===
--- elf.c   (revision 257038)
+++ elf.c   (working copy)
@@ -997,7 +997,6 @@ elf_open_debugfile_by_debuglink (struct
 void *data)
 {
   int ddescriptor;
-  uint32_t got_crc;
 
   ddescriptor = elf_find_debugfile_by_debuglink (state, filename,
 debuglink_name,
@@ -1005,11 +1004,16 @@ elf_open_debugfile_by_debuglink (struct
   if (ddescriptor < 0)
 return -1;
 
-  got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
-  if (got_crc != debuglink_crc)
+  if (debuglink_crc != 0)
 {
-  backtrace_close (ddescriptor, error_callback, data);
-  return -1;
+  uint32_t got_crc;
+
+  got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
+  if (got_crc != debuglink_crc)
+   {
+ backtrace_close (ddescriptor, error_callback, data);
+ return -1;
+   }
 }
 
   return ddescriptor;
@@ -2634,8 +2638,11 @@ elf_add (struct backtrace_state *state,
   unsigned int using_debug_view;
   uint16_t *zdebug_table;
 
-  *found_sym = 0;
-  *found_dwarf = 0;
+  if (!debuginfo)
+{
+  *found_sym = 0;
+  *found_dwarf = 0;
+}
 
   shdrs_view_valid = 0;
   names_view_valid = 0;

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

[Steve Kargl]

On Thu, Jan 25, 2018 at 07:06:10AM -0800, Steve Kargl wrote:
> On Thu, Jan 25, 2018 at 08:37:54AM +0100, Thomas Koenig wrote:
> > 
> > Second, why do you remove this
> > 
> > > -  temp.value.op.op = INTRINSIC_NONE;
> > > -  temp.value.op.op1 = vector_a;
> > > -  temp.value.op.op2 = vector_b;
> > > -  gfc_type_convert_binary (&temp, 1);
> > 
> > block of code?
> 
> It is dead code.  temp is set to the typespec of 
> the mixed-mode math result, but it is never used.
> compute_dot_product does the mixed-mode math,
> because it uses gfc_add() from arith.c.
> 

Upon re-reading gfc_type_convert_binary, it isn't dead.
It simply isn't needed, because gfc_add() eventually
lands at arith.c (eval_intrinsics):

/* Numeric binary  */
case INTRINSIC_PLUS:
case INTRINSIC_MINUS:
case INTRINSIC_TIMES:
case INTRINSIC_DIVIDE:
case INTRINSIC_POWER:
  if (!gfc_numeric_ts (&op1->ts) || !gfc_numeric_ts (&op2->ts))
goto runtime;

  /* Insert any necessary type conversions to make the operands
 compatible.  */

  temp.expr_type = EXPR_OP;
  gfc_clear_ts (&temp.ts);
  temp.value.op.op = op;

  temp.value.op.op1 = op1;
  temp.value.op.op2 = op2;

  gfc_type_convert_binary (&temp, warn_conversion || warn_conversion_extra);

-- 
Steve

[PATCH] Document PowerPC 'native' cpu type

[David Edelsohn]

The PowerPC port(s) of GCC have included auto-detection of host cpu
type through the "native" option, but it had not been documented.
This patch adds the documentation to the GCC Manual.

* doc/invoke.texi (PowerPC Options): Document 'native' cpu type.

Thanks, David

Index: invoke.texi
===
--- invoke.texi (revision 257055)
+++ invoke.texi (working copy)
@@ -22333,7 +22333,7 @@
 @samp{titan}, @samp{power3}, @samp{power4}, @samp{power5}, @samp{power5+},
 @samp{power6}, @samp{power6x}, @samp{power7}, @samp{power8},
 @samp{power9}, @samp{powerpc}, @samp{powerpc64}, @samp{powerpc64le},
-and @samp{rs64}.
+@samp{rs64}, and @samp{native}.

 @option{-mcpu=powerpc}, @option{-mcpu=powerpc64}, and
 @option{-mcpu=powerpc64le} specify pure 32-bit PowerPC (either
@@ -22341,6 +22341,12 @@
 architecture machine types, with an appropriate, generic processor
 model assumed for scheduling purposes.

+Specifying @samp{native} as cpu type detects and selects the
+architecture option that corresponds to the host processor of the
+system performing the compilation.
+@option{-march=native} has no effect if GCC does not recognize the
+processor.
+
 The other options specify a specific processor.  Code generated under
 those options runs best on that processor, and may not run at all on
 others.

Re: [PATCH] Document PowerPC 'native' cpu type

[Segher Boessenkool]

Hi!

On Thu, Jan 25, 2018 at 01:24:56PM -0500, David Edelsohn wrote:
> +Specifying @samp{native} as cpu type detects and selects the
> +architecture option that corresponds to the host processor of the
> +system performing the compilation.
> +@option{-march=native} has no effect if GCC does not recognize the
> +processor.

This should be -mcpu=native ?


Segher

Re: [PATCH] Document PowerPC 'native' cpu type

[David Edelsohn]

On Thu, Jan 25, 2018 at 1:44 PM, Segher Boessenkool
 wrote:
> Hi!
>
> On Thu, Jan 25, 2018 at 01:24:56PM -0500, David Edelsohn wrote:
>> +Specifying @samp{native} as cpu type detects and selects the
>> +architecture option that corresponds to the host processor of the
>> +system performing the compilation.
>> +@option{-march=native} has no effect if GCC does not recognize the
>> +processor.
>
> This should be -mcpu=native ?

Yep.  Fixed.

Thanks, David

[PATCH] fix for diagnostic/84034

[Bernd Edlinger]

Hi,

as PR diagnostic/84034 shows, source files with
dos style line endings can cause a glitch in the
terminal emulation that erases the source line that
is supposed to be shown.

That happens when the colorizing escape sequences are
printed between the CR and the LF.  Apparently the LF is
being ignored and thus the following line overwrites
everything from the last source line.


The following patch fixes the visual glitch by handling
a CR '\r' like a TAB '\t' character.


Bootstrapped and reg-rested in x86_64-pc-linux-gnu.
OK for trunk?


Thanks
Bernd.
2018-01-25  Bernd Edlinger  

	PR diagnostic/84034
	* diagnostic-show-locus.c (get_line_width_without_trailing_whitespace):
	Handle CR like TAB.
	(layout::print_source_line): Likewise.
	(test_get_line_width_without_trailing_whitespace): Add test cases.

Index: gcc/diagnostic-show-locus.c
===
--- gcc/diagnostic-show-locus.c	(revision 257048)
+++ gcc/diagnostic-show-locus.c	(working copy)
@@ -639,7 +639,7 @@ get_line_width_without_trailing_whitespace (const
   while (result > 0)
 {
   char ch = line[result - 1];
-  if (ch == ' ' || ch == '\t')
+  if (ch == ' ' || ch == '\t' || ch == '\r')
 	result--;
   else
 	break;
@@ -648,7 +648,8 @@ get_line_width_without_trailing_whitespace (const
   gcc_assert (result <= line_width);
   gcc_assert (result == 0 ||
 	  (line[result - 1] != ' '
-	   && line[result -1] != '\t'));
+	   && line[result -1] != '\t'
+	   && line[result -1] != '\r'));
   return result;
 }
 
@@ -673,9 +674,11 @@ test_get_line_width_without_trailing_whitespace ()
   assert_eq ("", 0);
   assert_eq (" ", 0);
   assert_eq ("\t", 0);
+  assert_eq ("\r", 0);
   assert_eq ("hello world", 11);
   assert_eq ("hello world ", 11);
   assert_eq ("hello world \t\t  ", 11);
+  assert_eq ("hello world\r", 11);
 }
 
 #endif /* #if CHECKING_P */
@@ -1176,8 +1179,8 @@ layout::print_source_line (int row, const char *li
 	  else
 	m_colorizer.set_normal_text ();
 	}
-  char c = *line == '\t' ? ' ' : *line;
-  if (c == '\0')
+  char c = *line;
+  if (c == '\0' || c == '\t' || c == '\r')
 	c = ' ';
   if (c != ' ')
 	{

Re: [PATCH, rs6000] Updates for vec_neg() gimple-folding vector tests

[Segher Boessenkool]

Hi!

On Wed, Jan 24, 2018 at 10:45:49AM -0600, Will Schmidt wrote:
> Update the vec-neg-longlong folding tests to handle codegen variations
> as seen between p8 and p9 targets.

(And fold-vec-neg-int).

> 2018-01-24  Will Schmidt  
> 
>   * gcc.target/powerpcfold-vec-neg-longlong.h:  New.

Typo here (you lost a slash).

>   * gcc.target/powerpc/fold-vec-neg-longlong.p8.c:  New.
>   * gcc.target/powerpc/fold-vec-neg-longlong.p9.c:  New.
>   * gcc.target/powerpc/fold-vec-neg-longlong.c:  Delete.
>   * gcc.target/powerpc/fold-vec-neg-int.c: Remove scan-assembler stanzas.
>   * gcc.target/powerpc/fold-vec-neg-int.p7.c: New.
>   * gcc.target/powerpc/fold-vec-neg-int.p8.c: New.
>   * gcc.target/powerpc/fold-vec-neg-int.p9.c: New.

The rest looks fine.  Okay for trunk.  Thanks!


Segher

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

[Thomas Koenig]

Hi Steve,

thanks for your explanations.

The patch is OK for trunk. Thanks a lot!

Regards

Thomas

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

[Steve Kargl]

On Thu, Jan 25, 2018 at 07:58:22PM +0100, Thomas Koenig wrote:
> Hi Steve,
> 
> thanks for your explanations.
> 
> The patch is OK for trunk. Thanks a lot!
> 

Upon even further reading, the code segment with temp might
be needed.  If one looks in compute_dot_product(), one finds

  result = gfc_get_constant_expr (matrix_a->ts.type, matrix_a->ts.kind,
  &matrix_a->where);
  init_result_expr (result, 0, NULL);
 
which sets the type of result to matrix_a, unconditionally.
We may however still benefit from mixed-mode math during
the summation because we have

result = gfc_add (result, gfc_multiply (c, gfc_copy_expr (b)));

and both gfc_add and gfc_multiply should do mixed-mode math.

I'll check before I commit.

-- 
Steve

Re: [Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

[Paul Richard Thomas]

Hi Jakub,

Thanks for the OK and the help in getting the padding sorted out.

Committed as Committed revision 257065.

Paul

On 24 January 2018 at 20:26, Paul Richard Thomas
 wrote:
> Hi Jakub,
>
> I have made the changes to the types of the dtype elements that you
> suggested. It led to a cast being needed in
> trans-intrinsic.c(gfc_conv_intrinsic_rank) but, apart from that, the
> changes were straightforward. Please find the updated patch attached.
>
> OK for trunk?
>
> Once I have committed this patch, I promise that I will stick to
> regressions and bug fixes through to release :-)
>
> Paul
>
>
> On 24 January 2018 at 09:11, jakub at gcc dot gnu.org
>  wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999
>>
>> Jakub Jelinek  changed:
>>
>>What|Removed |Added
>> 
>>Priority|P3  |P4
>>  Status|UNCONFIRMED |NEW
>>Last reconfirmed||2018-01-24
>>  CC||jakub at gcc dot gnu.org,
>>||pault at gcc dot gnu.org
>>  Ever confirmed|0   |1
>>
>> --- Comment #2 from Jakub Jelinek  ---
>> Started with r254936.
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [PATCH, rs6000] Updates for vec_abs() gimple-folding vector tests

[Segher Boessenkool]

Hi!

On Wed, Jan 24, 2018 at 10:46:02AM -0600, Will Schmidt wrote:
> 2018-01-24  Will Schmidt  
> 
>   * gcc.target/powerpc/fold-vec-abs-int.c:  remove scan-assembler stanzas.

Only one space after : and start with a cap.

>   * gcc.target/powerpc/fold-vec-abs-int-fwrap.c:  Same.
>   * gcc.target/powerpc/fold-vec-abs-int.p7.c: New.
>   * gcc.target/powerpc/fold-vec-abs-int.p8.c: New.
>   * gcc.target/powerpc/fold-vec-abs-int.p9.c: New.
>   * gcc.target/powerpc/fold-vec-abs-int-fwrapv.p7.c: New.
>   * gcc.target/powerpc/fold-vec-abs-int-fwrapv.p8.c: New.
>   * gcc.target/powerpc/fold-vec-abs-int-fwrapv.p9.c: New.
>   * gcc.target/powerpc/fold-vec-abs-longlong.c:  remove scan-assembler 
> stanzas.
>   * gcc.target/powerpc/fold-vec-abs-longlong-fwrap.c:  Same.
>   * gcc.target/powerpc/fold-vec-abs-longlong.p7.c: New.
>   * gcc.target/powerpc/fold-vec-abs-longlong.p8.c: New.
>   * gcc.target/powerpc/fold-vec-abs-longlong.p9.c: New.
>   * gcc.target/powerpc/fold-vec-abs-longlong-fwrapv.p7.c: New.
>   * gcc.target/powerpc/fold-vec-abs-longlong-fwrapv.p8.c: New.
>   * gcc.target/powerpc/fold-vec-abs-longlong-fwrapv.p9.c: New.
>   * gcc.target/powerpc/fold-vec-abs-short.c:  Add xxspltib to valid 
> instruction list.
>   * gcc.target/powerpc/fold-vec-abs-short-fwrapv.c:  Same.

More of that in the other entries, please check all.

This looks fine.  One question: should we also test expected code
generation for systems that only have AltiVec, not VSX?  So something
older than p7?  That goes for this whole series of course.

But, okay for trunk either way.  Thanks!


Segher

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

[Steve Kargl]

On Thu, Jan 25, 2018 at 11:07:04AM -0800, Steve Kargl wrote:
> On Thu, Jan 25, 2018 at 07:58:22PM +0100, Thomas Koenig wrote:
> > Hi Steve,
> > 
> > thanks for your explanations.
> > 
> > The patch is OK for trunk. Thanks a lot!
> > 
> 
> Upon even further reading, the code segment with temp might
> be needed.  If one looks in compute_dot_product(), one finds
> 
>   result = gfc_get_constant_expr (matrix_a->ts.type, matrix_a->ts.kind,
> &matrix_a->where);
>   init_result_expr (result, 0, NULL);
>  
> which sets the type of result to matrix_a, unconditionally.
> We may however still benefit from mixed-mode math during
> the summation because we have
> 
>   result = gfc_add (result, gfc_multiply (c, gfc_copy_expr (b)));
> 
> and both gfc_add and gfc_multiply should do mixed-mode math.
> 
> I'll check before I commit.

This code confirms proper handling of mixed-mode math.
   program p
   integer, parameter :: a(2) = [1, 2]
   real, parameter :: b(2) = [1., 2.]
   real c
   c = dot_product(a,b)
   print *, c
   end

-- 
Steve

Re: [PATCH, rs6000] Updates for vec_cmp_*() gimple-folding vector testcases

[Segher Boessenkool]

Hi!

On Wed, Jan 24, 2018 at 10:46:11AM -0600, Will Schmidt wrote:
>   Assorted updates for the vector intrinsics / gimple folding vec_cmp()
> testcases to handle codegen variations as seen between P8,P9 targets.
> This breaks apart the testcases into a #included header that contains the
> testcase contents, and fold-vec-cmp-*.c tests that contain the target specific
> stanzas. 

> 2018-01-24  Will Schmidt  
> 
> * gcc.target/powerpc/fold-vec-cmp-int.c:  Delete.
> * gcc.target/powerpc/fold-vec-cmp-int.h:  New.
> * gcc.target/powerpc/fold-vec-cmp-int.p7.c:  New.
> * gcc.target/powerpc/fold-vec-cmp-int.p8.c:  New.
> * gcc.target/powerpc/fold-vec-cmp-int.p9.c:  New.
> * gcc.target/powerpc/fold-vec-cmp-short.c:  Delete.
> * gcc.target/powerpc/fold-vec-cmp-short.h:  New.
> * gcc.target/powerpc/fold-vec-cmp-short.p8.c:  New.
> * gcc.target/powerpc/fold-vec-cmp-short.p9.c:  New.
> * gcc.target/powerpc/fold-vec-cmp-char.c:  Delete.
> * gcc.target/powerpc/fold-vec-cmp-char.h:  New.
> * gcc.target/powerpc/fold-vec-cmp-char.p8.c:  New.
> * gcc.target/powerpc/fold-vec-cmp-char.p9.c:  New.

One space after : .

Patch looks fine.  Okay for trunk.  Thanks!


Segher

[committed] jit: remove some unused fields from recording::union_ (PR jit/81672)

[David Malcolm]

gcc::jit::recording::union_ has some stray fields, which
are duplicates of those in the compound_type base class.

It looks like these have been present since the initial merger of the jit
branch to trunk (r217374), where it had three duplicate fields:

 location *m_loc;
 string *m_name;
 fields *m_fields;

I removed the duplicate field "m_fields" in r219564 but missed the other
two.

This patch removes them.

Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.

Committed to trunk as r257066.

gcc/jit/ChangeLog:
PR jit/81672
* jit-recording.h (gcc::jit::recording::union_): Remove fields
"m_loc" and "m_name".
---
 gcc/jit/jit-recording.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index e7feceb..b1d5982 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -932,10 +932,6 @@ public:
 private:
   string * make_debug_string () FINAL OVERRIDE;
   void write_reproducer (reproducer &r) FINAL OVERRIDE;
-
-private:
-  location *m_loc;
-  string *m_name;
 };
 
 /* An abstract base class for operations that visit all rvalues within an
-- 
1.8.5.3

[PATCH] RL78 addsi3 improvement

[Sebastian Perta]

Hello,
 
The following patch improves addsi3 by eliminating addw ax, #0 and replacing
addw ax, #-1 with decw ax where possible (if operand 2 is const)

The patch adds also a test case to check this.

Regression test is OK, tested with the following command:
make -k check-gcc RUNTESTFLAGS=--target_board=rl78-sim
 
 Please let me know if this is OK to check-in, Thank you!

Best Regards,
 Sebastian

Index: ChangeLog
===
--- ChangeLog   (revision 257055)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2018-01-25  Sebastian Perta  
+
+   * config/rl78/rl78.c: if operand 2 is const avoid addition with 0
+   and use incw and decw where possible
+   * testsuite/gcc.target/rl78/test_addsi3_internal.c: new file
+
 2018-01-25  Jakub Jelinek  
 
PR middle-end/83977




Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c  (revision 257055)
+++ config/rl78/rl78.c  (working copy)
@@ -80,6 +80,9 @@
   "sp", "ap", "psw", "es", "cs"
 };
 
+/* used by rl78_addsi3_internal for formatting insns output */
+static char fmt_buffer[1024];
+
 /* Structure for G13 MDUC registers.  */
 struct mduc_reg_type
 {
@@ -4788,6 +4791,8 @@
 const char *
 rl78_addsi3_internal (rtx * operands, unsigned int alternative)
 {
+  const char *addH2 = "addw ax, %H2\n\t";
+
   /* If we are adding in a constant symbolic address when -mes0
  is active then we know that the address must be <64K and
  that it is invalid to access anything above 64K relative to
@@ -4799,16 +4804,38 @@
   && ! TREE_SIDE_EFFECTS (SYMBOL_REF_DECL (operands[2])))
 return "movw ax, %h1\n\taddw ax, %h2\n\tmovw %h0, ax";
 
+  if(CONST_INT_P(operands[2]))
+  {
+if((INTVAL(operands[2]) & 0x) == 0)
+{
+addH2 = "";
+}
+else if((INTVAL(operands[2]) & 0x) == 0x0001)
+{
+addH2 = "incw ax\n\t";
+}
+else if((INTVAL(operands[2]) & 0x) == 0x)
+{
+addH2 = "decw ax\n\t";
+}
+  }
+
   switch (alternative)
 {
 case 0:
 case 1:
-  return "movw ax, %h1\n\taddw ax, %h2\n\tmovw %h0, ax\n\tmovw ax,
%H1\n\tsknc\n\tincw ax\n\taddw ax, %H2\n\tmovw %H0, ax";
+ snprintf(fmt_buffer, sizeof(fmt_buffer),
+   "movw ax, %%h1\n\taddw ax, %%h2\n\tmovw %%h0, ax\n\tmovw ax,
%%H1\n\tsknc\n\tincw ax\n\t%smovw %%H0,ax", addH2);
+ break;
 case 2:
-  return "movw ax, %h1\n\taddw ax,%h2\n\tmovw bc, ax\n\tmovw ax,
%H1\n\tsknc\n\tincw ax\n\taddw ax, %H2\n\tmovw %H0, ax\n\tmovw ax,
bc\n\tmovw %h0, ax";
+ snprintf(fmt_buffer, sizeof(fmt_buffer),
+   "movw ax, %%h1\n\taddw ax, %%h2\n\tmovw bc, ax\n\tmovw ax,
%%H1\n\tsknc\n\tincw ax\n\t%smovw %%H0, ax\n\tmovw ax, bc\n\tmovw %%h0, ax",
addH2);
+ break;
 default:
   gcc_unreachable ();
 }
+
+  return fmt_buffer;
 }
 
 rtx
Index: testsuite/gcc.target/rl78/test_addsi3_internal.c
===
--- testsuite/gcc.target/rl78/test_addsi3_internal.c(nonexistent)
+++ testsuite/gcc.target/rl78/test_addsi3_internal.c(working copy)
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+/* { dg-options "-Os" } */
+long l, v;
+
+void test1()
+{
+   l++;
+}
+
+void test2()
+{
+   l--;
+}
+
+void test3()
+{
+   l += 10;
+}
+
+long test4()
+{
+   return l + v;
+}
+
+/* { dg-final { scan-assembler-not "addw ax, #0" } } */
+/* { dg-final { scan-assembler-not "addw ax, #-1" } } */
+/* { dg-final { scan-assembler "decw ax" } } */

Re: [PATCH] RL78 addsi3 improvement

[DJ Delorie]

This is OK.

I wonder if these types of optimizations should be added to the
assembler too?  At least, if relaxation is enabled...

Re: [PATCH] Fix PR84003

[Richard Sandiford]

Richard Biener  writes:
> The following patch fixes PR84003 where RTL DSE removes a redundant
> store (a store storing the same value as an earlier store) but in
> doing this changing program semantics because the later store changes
> the effective type of the memory location.  This in turn allows
> sched2 to do an originally invalid transform.
>
> The fix is to harden DSE so that while removing the later store
> the earlier stores alias-sets are changed to reflect both dynamic
> types - which means using alias-set zero.
>
> On GIMPLE we simply avoid removing such type-changing stores because
> we cannot easily get hold on the earlier store.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Disclaimer: this is a "local" fix, I didn't try to understand much
> of the DSE data structures but only learned from +-10 lines around
> the affected transform which I found by searching for the dumped
> messages ...  Richard, you contributed the pass so please review.

So the file says.  In reality I only wrote an early version, and what
was committed contains very little of that.  So TBH this pass is almost
a complete unknown to me.  That said...

Might it be worth keeping the store instead?  Giving things alias set
zero seems like a pretty big hammer and would turn the remaining store
into something close to a scheduling barrier.

IOW, how about checking alias_set_subset_of in:

  /* Even if PTR won't be eliminated as unneeded, if both
 PTR and this insn store the same constant value, we might
 eliminate this insn instead.  */
  if (s_info->const_rhs
  && const_rhs
  && known_subrange_p (offset, width,
   s_info->offset, s_info->width)
  && all_positions_needed_p (s_info, offset - s_info->offset,
 width))

instead?

Failing that:

> 2018-01-25  Richard Biener  
>
>   PR rtl-optimization/84003
>   * dse.c (dse_step1): When removing redundant stores make sure
>   to adjust the earlier stores alias-set to match semantics of
>   the removed one and its own.
>   (dse_step6): Likewise.
>
>   * g++.dg/torture/pr77745.C: Mark foo noinline to trigger
>   latent bug in DSE.
>
> Index: gcc/dse.c
> ===
> --- gcc/dse.c (revision 257043)
> +++ gcc/dse.c (working copy)
> @@ -2725,6 +2725,19 @@ dse_step1 (void)
>   "eliminated\n",
>INSN_UID (ptr->insn),
>INSN_UID (s_info->redundant_reason->insn));
> +   /* If the later store we delete could have changed the
> +  dynamic type of the memory make sure the one we
> +  preserve serves as a store for all loads that could
> +  validly have accessed the one we delete.  */
> +   store_info *r_info = s_info->redundant_reason->store_rec;
> +   while (r_info)
> + {
> +   if (r_info->is_set
> +   && (MEM_ALIAS_SET (s_info->mem)
> +   != MEM_ALIAS_SET (r_info->mem)))
> + set_mem_alias_set (r_info->mem, 0);
> +   r_info = r_info->next;
> + }
> delete_dead_store_insn (ptr);
>   }
> free_store_info (ptr);
> @@ -3512,6 +3525,19 @@ dse_step6 (void)
>   "eliminated\n",
>   INSN_UID (insn_info->insn),
>   INSN_UID (rinsn));
> +   /* If the later store we delete could have changed the
> +  dynamic type of the memory make sure the one we
> +  preserve serves as a store for all loads that could
> +  validly have accessed the one we delete.  */
> +   store_info *r_info = s_info->redundant_reason->store_rec;
> +   while (r_info)
> + {
> +   if (r_info->is_set
> +   && (MEM_ALIAS_SET (s_info->mem)
> +   != MEM_ALIAS_SET (r_info->mem)))
> + set_mem_alias_set (r_info->mem, 0);
> +   r_info = r_info->next;
> + }

I think this is subtle enough to be worth factoring out.  How about
checking alias_set_subset_of, rather than checking for equality?

Thanks,
Richard

> delete_dead_store_insn (insn_info);
>   }
>   }
> Index: gcc/testsuite/g++.dg/torture/pr77745.C
> ===
> --- gcc/testsuite/g++.dg/torture/pr77745.C(revision 257043)
> +++ gcc/testsuite/g++.dg/torture/pr77745.C(working copy)
> @@ -2,7 +2,7 @@
>  
>  inline void* operato

Re: [PATCH] Fix PR84003

[Richard Sandiford]

Richard Sandiford  writes:
> Richard Biener  writes:
>> The following patch fixes PR84003 where RTL DSE removes a redundant
>> store (a store storing the same value as an earlier store) but in
>> doing this changing program semantics because the later store changes
>> the effective type of the memory location.  This in turn allows
>> sched2 to do an originally invalid transform.
>>
>> The fix is to harden DSE so that while removing the later store
>> the earlier stores alias-sets are changed to reflect both dynamic
>> types - which means using alias-set zero.
>>
>> On GIMPLE we simply avoid removing such type-changing stores because
>> we cannot easily get hold on the earlier store.
>>
>> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>>
>> Disclaimer: this is a "local" fix, I didn't try to understand much
>> of the DSE data structures but only learned from +-10 lines around
>> the affected transform which I found by searching for the dumped
>> messages ...  Richard, you contributed the pass so please review.
>
> So the file says.  In reality I only wrote an early version, and what
> was committed contains very little of that.  So TBH this pass is almost
> a complete unknown to me.  That said...
>
> Might it be worth keeping the store instead?

...that is, like gimple. :-)  Sorry, I spent so long thinking about this
that I forgot you'd said that gimple already does the same thing.

Richard

> Giving things alias set
> zero seems like a pretty big hammer and would turn the remaining store
> into something close to a scheduling barrier.
>
> IOW, how about checking alias_set_subset_of in:
>
> /* Even if PTR won't be eliminated as unneeded, if both
>PTR and this insn store the same constant value, we might
>eliminate this insn instead.  */
> if (s_info->const_rhs
> && const_rhs
> && known_subrange_p (offset, width,
>  s_info->offset, s_info->width)
> && all_positions_needed_p (s_info, offset - s_info->offset,
>width))
>
> instead?
>
> Failing that:
>
>> 2018-01-25  Richard Biener  
>>
>>  PR rtl-optimization/84003
>>  * dse.c (dse_step1): When removing redundant stores make sure
>>  to adjust the earlier stores alias-set to match semantics of
>>  the removed one and its own.
>>  (dse_step6): Likewise.
>>
>>  * g++.dg/torture/pr77745.C: Mark foo noinline to trigger
>>  latent bug in DSE.
>>
>> Index: gcc/dse.c
>> ===
>> --- gcc/dse.c(revision 257043)
>> +++ gcc/dse.c(working copy)
>> @@ -2725,6 +2725,19 @@ dse_step1 (void)
>>  "eliminated\n",
>>   INSN_UID (ptr->insn),
>>   INSN_UID (s_info->redundant_reason->insn));
>> +  /* If the later store we delete could have changed the
>> + dynamic type of the memory make sure the one we
>> + preserve serves as a store for all loads that could
>> + validly have accessed the one we delete.  */
>> +  store_info *r_info = s_info->redundant_reason->store_rec;
>> +  while (r_info)
>> +{
>> +  if (r_info->is_set
>> +  && (MEM_ALIAS_SET (s_info->mem)
>> +  != MEM_ALIAS_SET (r_info->mem)))
>> +set_mem_alias_set (r_info->mem, 0);
>> +  r_info = r_info->next;
>> +}
>>delete_dead_store_insn (ptr);
>>  }
>>free_store_info (ptr);
>> @@ -3512,6 +3525,19 @@ dse_step6 (void)
>>  "eliminated\n",
>>  INSN_UID (insn_info->insn),
>>  INSN_UID (rinsn));
>> +  /* If the later store we delete could have changed the
>> + dynamic type of the memory make sure the one we
>> + preserve serves as a store for all loads that could
>> + validly have accessed the one we delete.  */
>> +  store_info *r_info = s_info->redundant_reason->store_rec;
>> +  while (r_info)
>> +{
>> +  if (r_info->is_set
>> +  && (MEM_ALIAS_SET (s_info->mem)
>> +  != MEM_ALIAS_SET (r_info->mem)))
>> +set_mem_alias_set (r_info->mem, 0);
>> +  r_info = r_info->next;
>> +}
>
> I think this is subtle enough to be worth factoring out.  How about
> checking alias_set_subset_of, rather than checking for equality?
>
> Thanks,
> Richard
>
>>delete_dead_store_insn (insn_info);
>>  }
>>  }
>> Index: gcc/testsuite/g++.dg/to

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

[Alexandre Oliva]

On Jan 24, 2018, Jakub Jelinek  wrote:

> On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote:
>> --- a/include/dwarf2.h
>> +++ b/include/dwarf2.h
>> @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type
>> DW_LLE_start_end = 0x07,
>> DW_LLE_start_length = 0x08,
>> 
>> + /*
>> 
>> +   has the proposal for now; only available to list members.
>> +
>> +   A (possibly updated) copy of the proposal is available at
>> +   .  */
>> +DW_LLE_GNU_view_pair = 0x09,
>> +#define DW_LLE_view_pair DW_LLE_GNU_view_pair
>> +

> This looks wrong.  The proposal has not been accepted yet, so you
> really can't know if DW_LLE_view_pair will be like that or whether it
> will have value of 9.  Unfortunately, the DWARF standard doesn't specify a
> vendor range for DW_LLE_* values.  I'd use 0xf0 or so, and don't pretend
> there is DW_LLE_view_pair at all, just use DW_LLE_GNU_view_pair everywhere.
> Jason, what do you think?

My reasoning was that, since we'd only emit this as an
explicitly-requested backward-incompatible extension to DWARF-5 (by
specifying -gdwarf-6 in this patch, but the option spelling could be
changed), any LLE number whatsoever would do.  The point of the #define
was to write the code in GCC so that, once DW_LLE_view_pair was
standardized (if it ever was), we'd just set up an enum for it and we'd
be done, but that would only happen at DWARF6+ anyway, so we'd be able
to tell, since we'd then have actual DWARF6, rather than DWARF5 with an
incompatible extensions (which is what we emit with the current
-gdwarf-6 option; see below).


>> --- a/gcc/dwarf2asm.c
>> +++ b/gcc/dwarf2asm.c
>> @@ -767,6 +767,33 @@ dw2_asm_output_data_sleb128 (HOST_WIDE_INT value,
>> va_end (ap);
>> }
>> 
>> +/* output symbol LAB1 as an unsigned LEB128 quantity.  */

> Capital O in Output please.

Thanks, fixed.

>> +static inline bool
>> +dwarf2out_locviews_in_attribute ()
>> +{
>> +  return debug_variable_location_views
>> +&& dwarf_version <= 5;

> Formatting, should be
>   return debug_variable_location_views && dwarf_version <= 5;
> or
>   return (debug_variable_location_views
> && dwarf_version <= 5);
> if it wouldn't fit (but it does).

Hmm...  Where does that mandate come from?, if you don't mind my asking.
I have just revised both GNU Coding Standards, and GCC-specific
conventions, to make sure I hadn't missed a change or some long-ago
established convention, and I couldn't find anything that supports that
"should".

I don't mind adjusting code to match your preferences (if that's what it
is), especially in modules you maintain, but I'd like to make sure I
haven't missed some requirement in the coding standards.  Or maybe, if
it's more than a personal preference and rather a group preference, we
should add that at least to the GCC coding conventions, if most of us
agree with it.

Personally, I don't see that line breaks before operators are only
permitted when the operand that follows wouldn't fit; the standards are
more permissive than that.  And I don't see that the parentheses are
mandatory either; GNU recommends them so that one doesn't have to indent
the subsequent lines by hand (or risk automatically reintendation to
undo that manual work), but it doesn't seem to mandate the indentation
or the paretheses, and the indentation one gets in their absence is IIUC
permitted and occasionally even desirable.  Am I missing something?

Anyway, consider the requested changes done.

> Do we really need to introduce -gdwarf-6 at this point?
> -gdwarf-5 -gvariable-location-views should be sufficient, isn't it?

No, that means something else, namely emit location view lists in a
separate attribute, matching corresponding ranges.

Maybe we shouldn't even have an option to emit that at this point, or
make it a very different spelling.  But I'd argue there's no point in
discarding the code that implements the format that was proposed for
standardization; at the very least it serves as a reference.  That's
also an argument for retaining the ability to emit it somehow, even if
with an option that we document as to-be-dropped if/when there's a
standard representation.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Alexandre Oliva]

On Jan 24, 2018, Jakub Jelinek  wrote:

> I think this asks for
>   if (flag_checking)
> gcc_assert (block_within_block_p (block,
> DECL_INITIAL (current_function_decl),
> true));

'k, changed.

> Otherwise the patch looks reasonable to me, but I think it depends on the
> 7/9.

Thanks, yeah, it very much does.  It *might* be possible to split out
the dependency, but...  it would just take most of the LVU patch with it
;-)

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [C++ PATCH] Fix constexpr handling of arrays with unknown bound (PR c++/83993)

[Martin Sebor]

On 01/24/2018 04:19 PM, Jakub Jelinek wrote:

Hi!

In constexpr evaluation of array references for arrays with unknown bounds,
we need to diagnose out of bounds accesses, but really don't know the bounds
at compile time, right now GCC will see nelts as error_mark_node + 1 and
will not consider them a constant expression at all.
From the clang commit message it seems that CWG is leaning towards allowing
&array_with_unknown_bound[0] and array_with_unknown_bound, but disallowing
any other indexes (i.e. assume the array could have zero elements).
The following patch implements that.  Bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?


Unless your goal is to have GCC 8 reject just some subset of
expressions in the reported test case (and fix the rest in
the future) then there still are other potentially invalid
expressions that GCC will continue to accept.  For example,
the initialization of p in f() is rejected with the patch but
the use of the same expression in g() is still accepted (Clang
silently accepts both).  It could be due to the same problem
as bug 82877.  Other similar issues are being tracked in bug
82876 and 82874.

  extern const int a[];

  constexpr int f ()
  {
const int *p = &a[7], *q = &a[0];
return p - q;
  }

  constexpr int g ()
  {
return &a[7] - &a[0];
  }

  constexpr const int i = f ();
  constexpr const int j = g ();

Regarding the patch, just a couple of minor nits:

The consensus we have reached some time back was not to quote
integer constants so I would suggest to follow it in new code
and take the opportunity to remove the quoting from surrounding
code.

  https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Quoting

In addition, I would suggest to phrase the error as "array
subscript value %E is used *with* array qD" as opposed to
"on array."  If we wanted to make it clearer that it's
the fact that the index is non-zero is the problem mentioning
it in the warning might help ("non-zero array subscript %E...")

Alternatively, since the bounds are unknown is evident from
the type of the array (e.g., "int[]") just: "array subscript
value %E may be outside the bounds of array %qD of type %qT"
might be good enough.

Martin



2018-01-24  Jakub Jelinek  

PR c++/83993
* constexpr.c (diag_array_subscript): Emit different diagnostics
if TYPE_DOMAIN (arraytype) is NULL.
(cxx_eval_array_reference, cxx_eval_store_expression): For arrays
with NULL TYPE_DOMAIN use size_zero_node as nelts.

* g++.dg/init/pr83993-1.C: New test.
* g++.dg/cpp0x/pr83993.C: New test.

--- gcc/cp/constexpr.c.jj   2018-01-19 23:34:04.897278768 +0100
+++ gcc/cp/constexpr.c  2018-01-24 13:38:40.572913190 +0100
@@ -2270,13 +2270,20 @@ diag_array_subscript (const constexpr_ct
   tree sidx = fold_convert (ssizetype, index);
   if (DECL_P (array))
{
- error ("array subscript value %qE is outside the bounds "
-"of array %qD of type %qT", sidx, array, arraytype);
+ if (TYPE_DOMAIN (arraytype))
+   error ("array subscript value %qE is outside the bounds "
+  "of array %qD of type %qT", sidx, array, arraytype);
+ else
+   error ("array subscript value %qE used on array %qD of "
+  "type %qT with unknown bounds", sidx, array, arraytype);
  inform (DECL_SOURCE_LOCATION (array), "declared here");
}
-  else
+  else if (TYPE_DOMAIN (arraytype))
error ("array subscript value %qE is outside the bounds "
   "of array type %qT", sidx, arraytype);
+  else
+   error ("array subscript value %qE used on array of type %qT "
+  "with unknown bounds", sidx, arraytype);
 }
 }

@@ -2361,7 +2368,12 @@ cxx_eval_array_reference (const constexp

   tree nelts;
   if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
-nelts = array_type_nelts_top (TREE_TYPE (ary));
+{
+  if (TYPE_DOMAIN (TREE_TYPE (ary)))
+   nelts = array_type_nelts_top (TREE_TYPE (ary));
+  else
+   nelts = size_zero_node;
+}
   else if (VECTOR_TYPE_P (TREE_TYPE (ary)))
 nelts = size_int (TYPE_VECTOR_SUBPARTS (TREE_TYPE (ary)));
   else
@@ -3439,7 +3451,12 @@ cxx_eval_store_expression (const constex
  tree nelts, ary;
  ary = TREE_OPERAND (probe, 0);
  if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
-   nelts = array_type_nelts_top (TREE_TYPE (ary));
+   {
+ if (TYPE_DOMAIN (TREE_TYPE (ary)))
+   nelts = array_type_nelts_top (TREE_TYPE (ary));
+ else
+   nelts = size_zero_node;
+   }
  else if (VECTOR_TYPE_P (TREE_TYPE (ary)))
nelts = size_int (TYPE_VECTOR_SUBPARTS (TREE_TYPE (ary)));
  else
--- gcc/testsuite/g++.dg/init/pr83993-1.C.jj2018-01-24 13:45:43.430864528 
+0100
+++ gcc/testsuite/g++.dg/init/pr83993-1.C   2018-01-24 13:44:59.352869530 
+0100
@@ -0,0 +1,11 @@
+// PR

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Segher Boessenkool]

Hi!

On Wed, Jan 24, 2018 at 03:49:26PM -0600, Peter Bergner wrote:
> The following patch fixes both PR56010 and PR83743.  PR56010 is fixed by
> adding an extra altname field to the RS6000_CPU table which matches the
> cases where the Linux kernel's AT_PLATFORM name differs from the name GCC
> expects.  If we match on the altname, then we return the canonical name.

Don't add this to rs6000-cpus.def; it belongs to the Linux support only.

You also need to translate multiple AT_PLATFORM names for a single -mcpu=,
not necessarily only two, so you probably want a separate translation table
to do just the translation (in driver-rs6000.c ?)

Did you check this against the kernel's arch/powerpc/kernel/cputable.c ?


Segher

Re: [PR81611] improve auto-inc

[Alexandre Oliva]

On Jan 24, 2018, Richard Biener  wrote:

> given gimple_assign_ssa_name_copy checks it is an assign

*nod*

> the lhs != preinc check is always false given you got to phi via
> SSA_NAME_DEF_STMT of preinc.

*nod*

> The simple_iv_increment_p change is ok with that change.

Thanks, I'll retest with the simplified test (just in case; for I can't
recall why I ended up with all those redundant conditions), repost and
install.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: Go patch committed: Rationalize external symbol names

[Rainer Orth]

Hi Ian,

> This patch to the Go frontend rationalizes the external symbol names
> that appear in assembler code.  It changes from the ad hoc mechanisms
> used to date to produce a set of names that are at least somewhat more
> coherent.  They are also more readable, after applying a simple
> demangling algorithms outlined in the long comment in names.cc.  The
> new names use only ASCII alphanumeric characters, underscore, and dot
> (which fixes AIX by avoiding the use of dollar sign).  If we really
> had to we could replace dot with underscore at the cost of forbidding
> some uses of underscore in Go identifier names.
>
> A minor cleanup discovered during this was that we were treating
> function types as different if one had a NULL parameters_ field and
> another has a non-NULL parameters_ field that has no parameters.  This
> worked because we mangled them slightly differently.  We now mangle
> them the same, so we treat them as equal, as we should anyhow.
>
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> to mainline.

this patch almost certainly (i.e. I didn't reghunt, but it's the only
plausible candidate between r257023 and r257057) Solaris/x86 bootstrap
with /bin/as:

Assembler: doc.go
"/var/tmp//ccbyjwCc.s", line 1043 : Syntax error
Near line: ".globl  .1fmt.fmt.clearflags"
"/var/tmp//ccbyjwCc.s", line 1044 : Syntax error
Near line: ".type   .1fmt.fmt.clearflags, @function"
"/var/tmp//ccbyjwCc.s", line 1045 : Illegal mnemonic
Near line: ".1fmt.fmt.clearflags:"
"/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
Near line: ".1fmt.fmt.clearflags:"
"/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
Near line: ".1fmt.fmt.clearflags:"
"/var/tmp//ccbyjwCc.s", line 1058 : Syntax error
Near line: ".size   .1fmt.fmt.clearflags, .-.1fmt.fmt.clearflags"
"/var/tmp//ccbyjwCc.s", line 1060 : Syntax error
Near line: ".globl  .1fmt.pp.Width"
"/var/tmp//ccbyjwCc.s", line 1061 : Syntax error
Near line: ".type   .1fmt.pp.Width, @function"
"/var/tmp//ccbyjwCc.s", line 1062 : Illegal mnemonic
Near line: ".1fmt.pp.Width:"
"/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
Near line: ".1fmt.pp.Width:"
"/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
Near line: ".1fmt.pp.Width:"
"/var/tmp//ccbyjwCc.s", line 1082 : Syntax error
Near line: ".size   .1fmt.pp.Width, .-.1fmt.pp.Width"
"/var/tmp//ccbyjwCc.s", line 1084 : Syntax error
Near line: ".globl  .1fmt.pp.Precision"
"/var/tmp//ccbyjwCc.s", line 1085 : Syntax error
Near line: ".type   .1fmt.pp.Precision, @function"
"/var/tmp//ccbyjwCc.s", line 1086 : Illegal mnemonic
Near line: ".1fmt.pp.Precision:"
"/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
Near line: ".1fmt.pp.Precision:"
"/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
Near line: ".1fmt.pp.Precision:"
"/var/tmp//ccbyjwCc.s", line 1106 : Syntax error
Near line: ".size   .1fmt.pp.Precision, .-.1fmt.pp.Precision"
"/var/tmp//ccbyjwCc.s", line 1108 : Syntax error
Near line: ".globl  .1fmt.ss.Width"
"/var/tmp//ccbyjwCc.s", line 1109 : Syntax error
Near line: ".type   .1fmt.ss.Width, @function"
"/var/tmp//ccbyjwCc.s", line 1110 : Illegal mnemonic
Near line: ".1fmt.ss.Width:"
"/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
Near line: ".1fmt.ss.Width:"
"/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
Near line: ".1fmt.ss.Width:"
"/var/tmp//ccbyjwCc.s", line 1149 : Syntax error
Near line: ".size   .1fmt.ss.Width, .-.1fmt.ss.Width"
"/var/tmp//ccbyjwCc.s", line 1151 : Syntax error
Near line: ".globl  .1fmt.ss.UnreadRune"
"/var/tmp//ccbyjwCc.s", line 1152 : Syntax error
Near line: ".type   .1fmt.ss.UnreadRune, @function"
"/var/tmp//ccbyjwCc.s", line 1153 : Illegal mnemonic
Near line: ".1fmt.ss.UnreadRune:"
"/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
Near line: ".1fmt.ss.UnreadRune:"
"/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
Near line: ".1fmt.ss.UnreadRune:"
"/var/tmp//ccbyjwCc.s", line 1209 : Syntax error
Near line: ".size   .1fmt.ss.UnreadRune, .-.1fmt.ss.UnreadRune"
"/var/tmp//ccbyjwCc.s", line 1908 : Syntax error
Near line: ".globl  .1fmt.fmt.init"
Too many errors - Goodbye
make[4]: *** [Makefile:3322: fmt.lo] Error 1

Solaris/SPARC with /bin/as is fine, but that's not too astonishing since
both assemblers are mostly different code bases.

Rainer

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

Re: [PATCH][Middle-end][version 2]2nd patch of PR78809 and PR83026

[Qing Zhao]

Hi, Jeff,

Really sorry for my  delay. 

Your email on 1/12/2018 and Richard’s email on 1/15/2018,   were completely 
lost in my mailboxes until yesterday my colleague, Paolo Carlini, forwarded it 
to me. 

I really apologize for the late reply.

Please see my reply below:

> On Jan 12, 2018, at 4:47 PM, Jeff Law  > wrote:
>> 
>> 
>>  1. replace the candidate calls with __builtin_str(n)cmp_eq instead of 
>> __builtin_memcmp_eq;
>>in builtins.c,  when expanding the new __builtin_str(n)cmp_eq 
>> call, expand them first as
>>__builtin_memcmp_eq, if Not succeed,  change the call back to 
>> __builtin_str(n)cmp.
>>  2. change the call to “get_range_strlen” with “compute_objsize”.
> Please read the big comment before compute_objsize.  If you are going to
> use it to influence code generation or optimization, then you're most
> likely doing something wrong.
> 
> compute_objsize can return an estimate in some circumstances.

> On Jan 15, 2018, at 2:48 AM, Richard Biener  > wrote:
> 
> Yes, compute_objsize cannot be used for optimizations.
Yes, I just checked the compute_objsize again, you are right, it might return 
an estimated code size.


> On Jan 12, 2018, at 4:47 PM, Jeff Law  > wrote:

> What I don't like here is the introduction of STRCMP_EQ and STRNCMP_EQ.
> ISTM that if you're going to introduce those new builtins, then you have
> to audit all the code that runs between their introduction into the IL
> and when you expand them to ensure they're handled properly.
> 
> All you're really doing is carrying along a status bit about what
> tree-ssa-strlen did.  So you could possibly store that status bit somewhere.
> 
> The concern with both is that something later invalidates the analysis
> you've done.  I'm having a hard time coming up with a case where this
> could happen, but I'm definitely concerned about this possibility.
> Though I feel it's more likely to happen if we store a status bit vs
> using STRCMP_EQ STRNCMP_EQ.
> 
> [ For example, we have two calls with the same arguments, but one feeds
> an equality test, the other does not.  If we store a status bit that one
> could be transformed, but then we end up CSE-ing the two calls, the
> status bit would be incorrect because one of the calls did not feed an
> equality test.  Hmmm. ]

See below.

>> +static HOST_WIDE_INT 
>> +compute_string_length (int idx)
>> +{
>> +  HOST_WIDE_INT string_leni = -1; 
>> +  gcc_assert (idx != 0);
>> +
>> +  if (idx < 0)
>> +string_leni = ~idx;
> So it seems to me you should just
>  return ~idx;
> 
> Then appropriately simplify the rest of the code.

Okay, I will update my code per your suggestion. 
> 
>> +
>> +/* Handle a call to strcmp or strncmp. When the result is ONLY used to do 
>> +   equality test against zero:
>> +
>> +   A. When both arguments are constant strings and it's a strcmp:
>> +  * if the length of the strings are NOT equal, we can safely fold the 
>> call
>> +to a non-zero value.
>> +  * otherwise, do nothing now.
> I'm guessing your comment needs a bit of work.  If both arguments are
> constant strings, then we can just use the host str[n]cmp to fold the
> str[n]cmp to a constant.  Presumably this is handled earlier :-)
> 
> So what I'm guessing is you're really referring to the case where the
> lengths are known constants, even if the contents of the strings
> themselves are not.  In that case if its an equality comparison, then
> you can fold to a constant.  Otherwise we do nothing.  So I think the
> comment needs updating here.

your understanding is correct, I will update the comments to make it more 
accurate.

>> +  
>> +   B. When one of the arguments is constant string, try to replace the call 
>> with
>> +   a __builtin_str(n)cmp_eq call where possible, i.e:
>> +
>> +   strncmp (s, STR, C) (!)= 0 in which, s is a pointer to a string, STR is 
>> a 
>> +   constant string, C is a constant.
>> + if (C <= strlen(STR) && sizeof_array(s) > C)
>> +   {
>> + replace this call with
>> + strncmp_eq (s, STR, C) (!)= 0
>> +   }
>> + if (C > strlen(STR)
>> +   {
>> + it can be safely treated as a call to strcmp (s, STR) (!)= 0
>> + can handled by the following strcmp.
>> +   }
>> +
>> +   strcmp (s, STR) (!)= 0 in which, s is a pointer to a string, STR is a 
>> +   constant string.
>> + if  (sizeof_array(s) > strlen(STR))
>> +   {
>> + replace this call with
>> + strcmp_eq (s, STR, strlen(STR)+1) (!)= 0
> So I'd hazard a guess that this comment has the same problem.  It's
> mixing up the concept of a constant string and the concept of a
> nonconstant string, but which has a known constant length.
> 
> First, if one of the arguments is a string constant, then it should be
> easy to get the constant at expansion time with minimal effort.  It's
> also the case that knowing if we're comparing the result a

Re: PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

[Segher Boessenkool]

On Thu, Jan 25, 2018 at 08:39:21PM +1030, Alan Modra wrote:
> vbpermq produces its output in bits 48..63 of the target vector reg,
> so the output cannot be lane swapped.  Bootstrapped and regression
> tested powerpc64le-linux.  OK to apply mainline, and backport to the
> branches?
> 
> gcc/
>   PR target/84033
>   * config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Exclude
>   UNSPEC_VBPERMQ.  Sort other unspecs.
> gcc/testsuite/
>   PR target/84033
>   * gcc.target/powerpc/swaps-p8-46.c: New.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
> @@ -0,0 +1,34 @@
> +/* { dg-do run { target { powerpc64le-*-* } } } */

/* { dg-do run { target { lp64 } } } */

would be better, since you only care whether you are running 64-bit
(and the target triple does not tell you; although standard configs
for powerpc64le pretty much enforce it, of course).

Okay for trunk with or without that change; okay for the branches after
looking for fallout.  Thanks!


Segher

[PATCH] PR libgcc/59714 complex division is surprising on aarch64

[vladimir . mezentsev]

From: Vladimir Mezentsev 

Tested on aarch64-linux-gnu, x86_64-pc-linux-gnu and sparc64-unknown-linux-gnu.
No regression. New tests now passed.
There is a performance degradation for complex double type:

  failed cases  |time
   old   new|   old  new
complex-32  150 |  3.51  3.56
complex-64  190 |  1.88  2.34
complex-128 340 |  3.71  2.88

ChangeLog:
2018-01-25  Vladimir Mezentsev  

PR libgcc/59714
* libgcc/libgcc2.c: New complex division implementation
* libgcc/config/sparc/sfp-machine.h: New
* gcc/testsuite/gcc.c-torture/execute/pr59714_128.c: New test
* gcc/testsuite/gcc.c-torture/execute/pr59714_32.c: New test
* gcc/testsuite/gcc.c-torture/execute/pr59714_64.c: New test
---
 gcc/testsuite/gcc.c-torture/execute/pr59714_128.c | 506 ++
 gcc/testsuite/gcc.c-torture/execute/pr59714_32.c  | 506 ++
 gcc/testsuite/gcc.c-torture/execute/pr59714_64.c  | 506 ++
 libgcc/config/sparc/sfp-machine.h |  13 +
 libgcc/libgcc2.c  | 175 +++-
 5 files changed, 1700 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_32.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_64.c
 create mode 100644 libgcc/config/sparc/sfp-machine.h

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c 
b/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
new file mode 100644
index 000..e26f40a
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
@@ -0,0 +1,506 @@
+#include 
+#include 
+
+extern void abort (void);
+#define FABS(x) ((x) >= 0 ? (x) : -(x))
+#define FTYPE   long double
+#define FMT "%-39.28La"
+
+/*
+   Tables of numbers for complex division testing
+   All values in hex format
+   z[i] == correctly rounded value of x[i]/y[i];
+ */
+
+#define NUMCNT 100
+
+__complex FTYPE x[NUMCNT] =
+  {
+0x1.0p0L + 0x1.0p0Li,  /* #1 */
+0x1.0p0L + 0x1.0p0Li,  /* #2 */
+0x1.0p1023L + 0x1.0p-1023Li,   /* #3 */
+0x1.0p1023L + 0x1.0p1023Li,/* #4 */
+0x1.0p1020L + 0x1.0p-844Li,/* #5 */
+0x1.0p-71L + 0x1.0p1021Li, /* #6 */
+0x1.0p-347L + 0x1.0p-54Li, /* #7 */
+0x1.0p-1074L + 0x1.0p-1074Li,  /* #8 */
+0x1.0p1015L + 0x1.0p-989Li,/* #9 */
+0x1.0p-622L + 0x1.0p-1071Li,   /* #10 */
+0x1.0p0L + 0x3.0p0Li,  /* #11 */
+-0x1.0p0L + 0x3.0p0Li, /* #12 */
+0x1.0p0L - 0x3.0p0Li,  /* #13 */
+0x3.0p0L + 0x1.0p0Li,  /* #14 */
+0x3.0p0L + 0x4.0p0Li,  /* #15 */
+0x1.0p0L - 0x3.1p-20Li,/* #16 */
+0x1.0p0L + 0x3.001p-20Li,  /* #17 */
+0x1.0p0L + 0x1.80002p1Li,  /* #18 */
+0x1.0p0L + 0x1.80004p1Li,  /* #19 */
+0x1.0p0L + 0x1.80008p1Li,  /* #20 */
+0x1.0p0L + 0x1.80010p1Li,  /* #21 */
+0x1.0p0L + 0x1.80020p1Li,  /* #22 */
+0x1.0p0L + 0x1.80040p1Li,  /* #23 */
+0x1.0p0L + 0x1.80080p1Li,  /* #24 */
+0x1.0p0L + 0x1.7ff8p1Li,   /* #25 */
+0x1.0p0L + 0x1.7ff0p1Li,   /* #26 */
+0x1.0p0L + 0x1.7f80p1Li,   /* #27 */
+0x1.0p0L + 0x1.7f00p1Li,   /* #28 */
+0x5.0p0L + 0x5.0p0Li,  /* #29 */
+0x4.0p0L + 0x3.0p0Li,  /* #30 */
+-0x4.0p0L + 0x3.1p0Li, /* #31 */
+0x3.001p-20L + 0x1.0p0Li,  /* #32 */
+0x1.001p-80L + 0x1.0p0Li,  /* #33 */
+0x1.001p-8000L + 0x1.0p0Li,/* #34 */
+0x1.0p0L + 0x1.001p-8000Li,/* #35 */
+-0x1.0p0L + 0x1.001p-8000Li,/* #36 */
+-0x1.0p0L + 0x1.001p-8000Li,/* #37 */
+-0x1.0p0L + 0x1.001p-8000Li,/* #38 */
+0x1.0p0L - 0x1.001p-8000Li,/* #39 */
+0x1.0p1000L - 0x1.001p-8000Li, /* #40 */
+0x1.97530p1000L - 0x1.001p-8000Li, /* #41 */
+0x1.97530p3000L - 0x1.001p-8000Li, /* #42 */
+0x1.97530p3770L - 0x1.001p-8000Li, /* #43 */
+0x1.97530p4770L - 0x1.001p-7000Li, /* #44 */
+0x1.97530p0L - 0x1.001p-12000Li,   /* #45 */
+0x1.97530p1000L - 0x1.001p-11000Li,/* #46 */
+0x1.97530p2000L - 0x1.001p-9000Li, /* #47 */
+0x1.97530p3000L - 0x1.001p-8000Li, /* #48 */
+0x1.97530p4000L - 0x1.001p-7000Li, /* #49 */
+0x1.97530p5000L - 0x1.001p-6000Li, /* #50 */
+0x1.97530p6000L - 0x1.001p-5000Li, /* #51 */
+0x1.97530p7000L - 0x1.001p-4000Li, /* #52 */
+0x1.97530p8000L - 0x1.001p-1000Li, /* #53 */
+0x1.97530p9000L - 0x1.001p-0Li,/* #54 */
+0x1.97530p1L + 0x1.001p2000Li, /* #55 */
+0x1.97530p10100L + 0x1.

Re: [PATCH][Middle-end][version 2]2nd patch of PR78809 and PR83026

[Qing Zhao]

> 
> We're now in stage4 so please queue this patch and ping it during
> next stage1.
> 

I will update my patch based on Jeff and your comments, and send it during next 
stage 1.

thanks.

Qing

Re: Go patch committed: Rationalize external symbol names

[Ian Lance Taylor]

On Thu, Jan 25, 2018 at 12:28 PM, Rainer Orth
 wrote:
>
>> This patch to the Go frontend rationalizes the external symbol names
>> that appear in assembler code.  It changes from the ad hoc mechanisms
>> used to date to produce a set of names that are at least somewhat more
>> coherent.  They are also more readable, after applying a simple
>> demangling algorithms outlined in the long comment in names.cc.  The
>> new names use only ASCII alphanumeric characters, underscore, and dot
>> (which fixes AIX by avoiding the use of dollar sign).  If we really
>> had to we could replace dot with underscore at the cost of forbidding
>> some uses of underscore in Go identifier names.
>>
>> A minor cleanup discovered during this was that we were treating
>> function types as different if one had a NULL parameters_ field and
>> another has a non-NULL parameters_ field that has no parameters.  This
>> worked because we mangled them slightly differently.  We now mangle
>> them the same, so we treat them as equal, as we should anyhow.
>>
>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>> to mainline.
>
> this patch almost certainly (i.e. I didn't reghunt, but it's the only
> plausible candidate between r257023 and r257057) Solaris/x86 bootstrap
> with /bin/as:
>
> Assembler: doc.go
> "/var/tmp//ccbyjwCc.s", line 1043 : Syntax error
> Near line: ".globl  .1fmt.fmt.clearflags"
> "/var/tmp//ccbyjwCc.s", line 1044 : Syntax error
> Near line: ".type   .1fmt.fmt.clearflags, @function"
> "/var/tmp//ccbyjwCc.s", line 1045 : Illegal mnemonic
> Near line: ".1fmt.fmt.clearflags:"
> "/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
> Near line: ".1fmt.fmt.clearflags:"
> "/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
> Near line: ".1fmt.fmt.clearflags:"
> "/var/tmp//ccbyjwCc.s", line 1058 : Syntax error
> Near line: ".size   .1fmt.fmt.clearflags, .-.1fmt.fmt.clearflags"
> "/var/tmp//ccbyjwCc.s", line 1060 : Syntax error
> Near line: ".globl  .1fmt.pp.Width"
> "/var/tmp//ccbyjwCc.s", line 1061 : Syntax error
> Near line: ".type   .1fmt.pp.Width, @function"
> "/var/tmp//ccbyjwCc.s", line 1062 : Illegal mnemonic
> Near line: ".1fmt.pp.Width:"
> "/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
> Near line: ".1fmt.pp.Width:"
> "/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
> Near line: ".1fmt.pp.Width:"
> "/var/tmp//ccbyjwCc.s", line 1082 : Syntax error
> Near line: ".size   .1fmt.pp.Width, .-.1fmt.pp.Width"
> "/var/tmp//ccbyjwCc.s", line 1084 : Syntax error
> Near line: ".globl  .1fmt.pp.Precision"
> "/var/tmp//ccbyjwCc.s", line 1085 : Syntax error
> Near line: ".type   .1fmt.pp.Precision, @function"
> "/var/tmp//ccbyjwCc.s", line 1086 : Illegal mnemonic
> Near line: ".1fmt.pp.Precision:"
> "/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
> Near line: ".1fmt.pp.Precision:"
> "/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
> Near line: ".1fmt.pp.Precision:"
> "/var/tmp//ccbyjwCc.s", line 1106 : Syntax error
> Near line: ".size   .1fmt.pp.Precision, .-.1fmt.pp.Precision"
> "/var/tmp//ccbyjwCc.s", line 1108 : Syntax error
> Near line: ".globl  .1fmt.ss.Width"
> "/var/tmp//ccbyjwCc.s", line 1109 : Syntax error
> Near line: ".type   .1fmt.ss.Width, @function"
> "/var/tmp//ccbyjwCc.s", line 1110 : Illegal mnemonic
> Near line: ".1fmt.ss.Width:"
> "/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
> Near line: ".1fmt.ss.Width:"
> "/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
> Near line: ".1fmt.ss.Width:"
> "/var/tmp//ccbyjwCc.s", line 1149 : Syntax error
> Near line: ".size   .1fmt.ss.Width, .-.1fmt.ss.Width"
> "/var/tmp//ccbyjwCc.s", line 1151 : Syntax error
> Near line: ".globl  .1fmt.ss.UnreadRune"
> "/var/tmp//ccbyjwCc.s", line 1152 : Syntax error
> Near line: ".type   .1fmt.ss.UnreadRune, @function"
> "/var/tmp//ccbyjwCc.s", line 1153 : Illegal mnemonic
> Near line: ".1fmt.ss.UnreadRune:"
> "/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
> Near line: ".1fmt.ss.UnreadRune:"
> "/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
> Near line: ".1fmt.ss.UnreadRune:"
> "/var/tmp//ccbyjwCc.s", line 1209 : Syntax error
> Near line: ".size   .1fmt.ss.UnreadRune, .-.1fmt.ss.UnreadRune"
> "/var/tmp//ccbyjwCc.s", line 1908 : Syntax error
> Near line: ".globl  .1fmt.fmt.init"
> Too many errors - Goodbye
> make[4]: *** [Makefile:3322: fmt.lo] Error 1
>
> Solaris/SPARC with /bin/as is fine, but that's not too astonishing since
> both assemblers are mostly different code bases.

Re: Go patch committed: Rationalize external symbol names

[Jakub Jelinek]

On Thu, Jan 25, 2018 at 12:40:13PM -0800, Ian Lance Taylor wrote:
> >> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> >> to mainline.
> >
> > this patch almost certainly (i.e. I didn't reghunt, but it's the only
> > plausible candidate between r257023 and r257057) Solaris/x86 bootstrap
> > with /bin/as:
> >
> > Assembler: doc.go
> > "/var/tmp//ccbyjwCc.s", line 1043 : Syntax error
> > Near line: ".globl  .1fmt.fmt.clearflags"
> > "/var/tmp//ccbyjwCc.s", line 1044 : Syntax error
> > Near line: ".type   .1fmt.fmt.clearflags, @function"
> > "/var/tmp//ccbyjwCc.s", line 1045 : Illegal mnemonic
> > Near line: ".1fmt.fmt.clearflags:"
> > "/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
> > Near line: ".1fmt.fmt.clearflags:"
> > "/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
> > Near line: ".1fmt.fmt.clearflags:"
> > "/var/tmp//ccbyjwCc.s", line 1058 : Syntax error
> > Near line: ".size   .1fmt.fmt.clearflags, 
> > .-.1fmt.fmt.clearflags"
> > "/var/tmp//ccbyjwCc.s", line 1060 : Syntax error
> > Near line: ".globl  .1fmt.pp.Width"
> > "/var/tmp//ccbyjwCc.s", line 1061 : Syntax error
> > Near line: ".type   .1fmt.pp.Width, @function"
> > "/var/tmp//ccbyjwCc.s", line 1062 : Illegal mnemonic
> > Near line: ".1fmt.pp.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
> > Near line: ".1fmt.pp.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
> > Near line: ".1fmt.pp.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1082 : Syntax error
> > Near line: ".size   .1fmt.pp.Width, .-.1fmt.pp.Width"
> > "/var/tmp//ccbyjwCc.s", line 1084 : Syntax error
> > Near line: ".globl  .1fmt.pp.Precision"
> > "/var/tmp//ccbyjwCc.s", line 1085 : Syntax error
> > Near line: ".type   .1fmt.pp.Precision, @function"
> > "/var/tmp//ccbyjwCc.s", line 1086 : Illegal mnemonic
> > Near line: ".1fmt.pp.Precision:"
> > "/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
> > Near line: ".1fmt.pp.Precision:"
> > "/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
> > Near line: ".1fmt.pp.Precision:"
> > "/var/tmp//ccbyjwCc.s", line 1106 : Syntax error
> > Near line: ".size   .1fmt.pp.Precision, .-.1fmt.pp.Precision"
> > "/var/tmp//ccbyjwCc.s", line 1108 : Syntax error
> > Near line: ".globl  .1fmt.ss.Width"
> > "/var/tmp//ccbyjwCc.s", line 1109 : Syntax error
> > Near line: ".type   .1fmt.ss.Width, @function"
> > "/var/tmp//ccbyjwCc.s", line 1110 : Illegal mnemonic
> > Near line: ".1fmt.ss.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
> > Near line: ".1fmt.ss.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
> > Near line: ".1fmt.ss.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1149 : Syntax error
> > Near line: ".size   .1fmt.ss.Width, .-.1fmt.ss.Width"
> > "/var/tmp//ccbyjwCc.s", line 1151 : Syntax error
> > Near line: ".globl  .1fmt.ss.UnreadRune"
> > "/var/tmp//ccbyjwCc.s", line 1152 : Syntax error
> > Near line: ".type   .1fmt.ss.UnreadRune, @function"
> > "/var/tmp//ccbyjwCc.s", line 1153 : Illegal mnemonic
> > Near line: ".1fmt.ss.UnreadRune:"
> > "/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
> > Near line: ".1fmt.ss.UnreadRune:"
> > "/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
> > Near line: ".1fmt.ss.UnreadRune:"
> > "/var/tmp//ccbyjwCc.s", line 1209 : Syntax error
> > Near line: ".size   .1fmt.ss.UnreadRune, .-.1fmt.ss.UnreadRune"
> > "/var/tmp//ccbyjwCc.s", line 1908 : Syntax error
> > Near line: ".globl  .1fmt.fmt.init"
> > Too many errors - Goodbye
> > make[4]: *** [Makefile:3322: fmt.lo] Error 1
> >
> > Solaris/SPARC with /bin/as is fine, but that's not too astonishing since
> > both assemblers are mostly different code bases.
> 
> >From the error messages I guess the problem is that the assembler
> doesn't like symbols that start with ".1".  Do you know what names the
> assembler permits?

It isn't just Solaris/SPARC, I saw bootstrap failure with go on
powerpc64-linux and powerpc64le-linux too, similar errors.
/tmp/cc9hDRO7.s: Assembler messages:
/tmp/cc9hDRO7.s:128: Error: symbol `.1errors.errorString.Error' is already 
defined
/tmp/cc9hDRO7.s: Error: .size expression for .1errors.errorString.Error does 
not evaluate to a constant

/home/jakub/gcc/obj22/gotools/../../gotools/../libgo/go/cmd/vet/unsafeptr.go:60:
 undefined reference to `.1go_types.Package.Path'
/home/jakub/gcc/obj22/gotools/../../gotools/../libgo/go/cmd/vet/unsafeptr.go:61:
 undefined reference to `.1go_types.Named.Obj'
/home/jakub/gcc/obj22/gotools/../../gotool

Re: Go patch committed: Rationalize external symbol names

[Rainer Orth]

Hi Ian,

> From the error messages I guess the problem is that the assembler
> doesn't like symbols that start with ".1".  Do you know what names the
> assembler permits?

The x86 Assembly Language Reference Manual states:

2.1.2.1 Identifiers

An identifier is an arbitrarily-long sequence of letters and digits. The
first character must be a letter; the underscore (_) (ASCII 0x5F) and
the period (.) (ASCII 0x2E) are considered to be letters. Case is
significant: uppercase and lowercase letters are different.

Contrary to that, /bin/as won't assemble

.globl .1

The SPARC Assembly Language Reference Manual states this instead:

1.3.6 Symbol Names

The syntax for a symbol name is:

{ letter | _ | $ | . }   { letter | _ | $ | . | digit }* 

In the above syntax:

* Uppercase and lowercase letters are distinct; the underscore ( _ ),
  dollar sign ($), and dot ( . ) are treated as alphabetic characters.

* Symbol names that begin with a dot ( . ) are assumed to be local
  symbols. To simplify debugging, avoid using this type of symbol name
  in hand-coded assembly language routines.

* The symbol dot ( . ) is predefined and always refers to the address of
  the beginning of the current assembly language statement.

* External variable names beginning with the underscore character are
  reserved by the ANSI C Standard. Do not begin these names with the
  underscore; otherwise, the program will not conform to ANSI C and
  unpredictable behavior may result.

Rainer

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

[C++ Patch] Add DECL_UNNAMED_BIT_FIELD and use it

[Paolo Carlini]

Hi,

this is the complete patch, tested x86_64-linux.

Thanks, Paolo.



/c-family
2018-01-25  Paolo Carlini  

* c-common.h (DECL_UNNAMED_BIT_FIELD): New.

/c
2018-01-25  Paolo Carlini  

* c-typeck.c (really_start_incremental_init, push_init_level,
set_nonincremental_init, output_init_element, process_init_element):
Use DECL_UNNAMED_BIT_FIELD.

/cp
2018-01-25  Paolo Carlini  

* class.c (is_really_empty_class): Use DECL_UNNAMED_BIT_FIELD.
* constexpr.c (cx_check_missing_mem_inits): Likewise.
* decl.c (next_initializable_field, find_decomp_class_base,
cp_finish_decomp): Likewise.
* typeck2.c (process_init_constructor_record): Likewise.
Index: c/c-typeck.c
===
--- c/c-typeck.c(revision 257063)
+++ c/c-typeck.c(working copy)
@@ -7955,8 +7955,7 @@ really_start_incremental_init (tree type)
   constructor_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
 
   constructor_unfilled_fields = constructor_fields;
@@ -8161,8 +8160,7 @@ push_init_level (location_t loc, int implicit,
   constructor_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
 
   constructor_unfilled_fields = constructor_fields;
@@ -8930,8 +8928,7 @@ set_nonincremental_init (struct obstack * braced_i
   constructor_unfilled_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_unfilled_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_unfilled_fields))
constructor_unfilled_fields = TREE_CHAIN (constructor_unfilled_fields);
 
 }
@@ -9300,8 +9297,7 @@ output_init_element (location_t loc, tree value, t
 
   /* Skip any nameless bit fields.  */
   while (constructor_unfilled_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_unfilled_fields))
constructor_unfilled_fields =
  DECL_CHAIN (constructor_unfilled_fields);
 }
@@ -9665,8 +9661,8 @@ process_init_element (location_t loc, struct c_exp
  constructor_unfilled_fields = DECL_CHAIN (constructor_fields);
  /* Skip any nameless bit fields.  */
  while (constructor_unfilled_fields != 0
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == 0)
+&& (DECL_UNNAMED_BIT_FIELD
+(constructor_unfilled_fields)))
constructor_unfilled_fields =
  DECL_CHAIN (constructor_unfilled_fields);
}
@@ -9675,8 +9671,7 @@ process_init_element (location_t loc, struct c_exp
  constructor_fields = DECL_CHAIN (constructor_fields);
  /* Skip any nameless bit fields at the beginning.  */
  while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
}
   else if (TREE_CODE (constructor_type) == UNION_TYPE)
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 257063)
+++ c-family/c-common.h (working copy)
@@ -939,6 +939,10 @@ extern void c_parse_final_cleanups (void);
 #define CLEAR_DECL_C_BIT_FIELD(NODE) \
   (DECL_LANG_FLAG_4 (FIELD_DECL_CHECK (NODE)) = 0)
 
+/* True if the decl was an unnamed bitfield.  */
+#define DECL_UNNAMED_BIT_FIELD(NODE) \
+  (DECL_C_BIT_FIELD (NODE) && !DECL_NAME (NODE))
+
 extern tree do_case (location_t, tree, tree);
 extern tree build_stmt (location_t, enum tree_code, ...);
 extern tree build_real_imag_expr (location_t, enum tree_code, tree);
Index: cp/class.c
===
--- cp/class.c  (revision 2570

Silence false positive on LTO type merging waring

[Jan Hubicka]

Hi,
the testcase triggers invalid warning on type mismatch because array
of pointers to complete type has different alias set from array of pointers
to incomplete type.  This is valid, because incoplete pointer has alias set
of void_ptr which alias all pointers and arrays alias with their members.

I already silenced the wanring for pointers but I forgot about arrays.

Bootstrapped/regtested x86_64-linux, OK?

* gcc.dg/lto/pr83954.h: New testcase.
* gcc.dg/lto/pr83954_0.c: New testcase.
* gcc.dg/lto/pr83954_1.c: New testcase.
* lto-symtab.c (warn_type_compatibility_p): Silence false positive
for type match warning on arrays of pointers.

Index: testsuite/gcc.dg/lto/pr83954.h
===
--- testsuite/gcc.dg/lto/pr83954.h  (revision 0)
+++ testsuite/gcc.dg/lto/pr83954.h  (working copy)
@@ -0,0 +1,3 @@
+struct foo;
+extern struct foo *FOO_PTR_ARR[1];
+
Index: testsuite/gcc.dg/lto/pr83954_0.c
===
--- testsuite/gcc.dg/lto/pr83954_0.c(revision 0)
+++ testsuite/gcc.dg/lto/pr83954_0.c(working copy)
@@ -0,0 +1,8 @@
+/* { dg-lto-do link } */
+#include "pr83954.h"
+
+int main() { 
+  // just to prevent symbol removal
+  FOO_PTR_ARR[1] = 0;
+  return 0;
+}
Index: testsuite/gcc.dg/lto/pr83954_1.c
===
--- testsuite/gcc.dg/lto/pr83954_1.c(revision 0)
+++ testsuite/gcc.dg/lto/pr83954_1.c(working copy)
@@ -0,0 +1,7 @@
+#include "pr83954.h"
+
+struct foo {
+ int x;
+};
+struct foo *FOO_PTR_ARR[1] = { 0 };
+
Index: lto/lto-symtab.c
===
--- lto/lto-symtab.c(revision 257009)
+++ lto/lto-symtab.c(working copy)
@@ -284,11 +284,22 @@ warn_type_compatibility_p (tree prevaili
   alias_set_type set1 = get_alias_set (type);
   alias_set_type set2 = get_alias_set (prevailing_type);
 
-  if (set1 && set2 && set1 != set2 
-  && (!POINTER_TYPE_P (type) || !POINTER_TYPE_P (prevailing_type)
+  if (set1 && set2 && set1 != set2)
+   {
+  tree t1 = type, t2 = prevailing_type;
+
+ /* Alias sets of arrays are the same as alias sets of the inner
+types.  */
+ while (TREE_CODE (t1) == ARRAY_TYPE && TREE_CODE (t2) == ARRAY_TYPE)
+   {
+ t1 = TREE_TYPE (t1);
+ t2 = TREE_TYPE (t2);
+   }
+  if ((!POINTER_TYPE_P (t1) || !POINTER_TYPE_P (t2))
  || (set1 != TYPE_ALIAS_SET (ptr_type_node)
- && set2 != TYPE_ALIAS_SET (ptr_type_node
-lev |= 5;
+ && set2 != TYPE_ALIAS_SET (ptr_type_node)))
+ lev |= 5;
+   }
 }
 
   return lev;

C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

[Marek Polacek]

This is a similar problem to 83116: we'd cached a constexpr call, but after a
store the result had become invalid, yet we used the wrong result again when
encountering the same call later.  This resulted in evaluating a THROW_EXPR
which doesn't work.  Details in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5

The fix for 83116 didn't work here, because when evaluating the body of the
ctor via store_init_value -> cxx_constant_value we are in STRICT, so we do
cache.

It seems that we may no longer rely on the constexpr call table when we
do cxx_eval_store_expression, because that just rewrites *valp, i.e. the
value of an object.  Might be too big a hammer again, but I couldn't think
of how I could guard the caching of a constexpr call.

This doesn't manifest in C++14 because build_special_member_call in C++17 is
more aggressive with copy elisions (as required by P0135 which changed how we
view prvalues).  In C++14 build_special_member_call produces a CALL_EXPR, so
expand_default_init calls maybe_constant_init, for which STRICT is false, so
we avoid caching as per 83116.

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

2018-01-25  Marek Polacek  

PR c++/83692
* constexpr.c (cxx_eval_store_expression): Clear constexpr_call_table.

* g++.dg/cpp1y/constexpr-83692.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 4d2ee4a28fc..0202d22f320 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -3663,6 +3663,10 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
tree t,
   else
 *valp = init;
 
+  /* We've rewritten a value of a temporary in this constexpr
+ context which might invalide a cached call.  */
+  constexpr_call_table = NULL;
+
   /* Update TREE_CONSTANT and TREE_SIDE_EFFECTS on enclosing
  CONSTRUCTORs, if any.  */
   tree elt;
diff --git gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C 
gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C
index e69de29bb2d..292ba7c22e9 100644
--- gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C
@@ -0,0 +1,21 @@
+// PR c++/83692
+// { dg-do compile { target c++14 } }
+
+struct integer {
+  constexpr int value() const { return m_value;}
+  int m_value;
+};
+
+struct outer {
+  integer m_x{0};
+  constexpr outer()
+{
+  if (m_x.value() != 0)
+   throw 0;
+  m_x.m_value = integer{1}.value();
+  if (m_x.value() != 1)
+   throw 0;
+}
+};
+
+constexpr outer o{};

Marek

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 1/25/18 2:18 PM, Segher Boessenkool wrote:
> Don't add this to rs6000-cpus.def; it belongs to the Linux support only.

Well, the reason I liked adding it to rs6000-cpus.def is that it keeps
the names together, so only one place to hold all of the info.  If you
prefer a separate table, then I can move it to driver-rs6000.c and it
would only need to hold info for AT_PLATFORMs that don't match GCC's
idea of the cpu name (eg, ppc440 versus 440).


> You also need to translate multiple AT_PLATFORM names for a single -mcpu=,
> not necessarily only two, so you probably want a separate translation table
> to do just the translation (in driver-rs6000.c ?)

Ah, I forgot about ppc440gp, even though it is in my list mentioned in the
link below.  I do think that is the only case though, "440", "ppc440" and
"ppc440gp" all being mapped to "440", but yes, that's not handled.


> Did you check this against the kernel's arch/powerpc/kernel/cputable.c ?

I did.  I posted my finding in the bugzilla:

https://gcc.gnu.org/PR56010#c5

I'll note that I did not try and disambiguate 440 vs 440fp, etc. by looking
at the HWCAP for PPC_FEATURE_HAS_FPU, like I mentioned in the bugzilla entry
above.  That's due to just because the cpu supports HW FP, we cannot know
what ABI the distro that is running on the cpu is using.  I could very well
be using a soft-float ABI.  Thoughts on that?


Ok, I'll move the table to driver-rs6000.c and I'll resubmit.

Peter

[PATCH] Fix -Wrestrict SSA_NAME handling (PR c/83989)

[Jakub Jelinek]

Hi!

builtin_memref ctor for a SSA_NAME with non-NULL SSA_NAME_VAR returns
the underlying variable, rather than just the SSA_NAME.
Later on the code checks if the bases are equal and then compares
corresponding offsets.

The fact that two different SSA_NAMEs have the same underlying variable
says nothing at all whether they have the same value, as the testcase shows,
either the SSA_NAMEs can be completely unrelated, or related, but with
different offsets.  The code already has code to handle POINTER_PLUS_EXPR
with a constant offset, to look through that.  Perhaps in the future there
can be other cases we'd special case, but generally we should compare as
bases the SSA_NAMEs, if they have the same or different base says nothing
about them.

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

2018-01-25  Jakub Jelinek  

PR c/83989
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Don't
use SSA_NAME_VAR as base for SSA_NAMEs with non-NULL SSA_NAME_VAR.

* c-c++-common/Wrestrict-3.c: New test.

--- gcc/gimple-ssa-warn-restrict.c.jj   2018-01-17 11:54:17.0 +0100
+++ gcc/gimple-ssa-warn-restrict.c  2018-01-25 14:10:26.182498552 +0100
@@ -373,9 +373,6 @@ builtin_memref::builtin_memref (tree exp
  offrange[1] += off;
}
}
-
-   if (TREE_CODE (base) == SSA_NAME && SSA_NAME_VAR (base))
- base = SSA_NAME_VAR (base);
   }
 
   if (size)
--- gcc/testsuite/c-c++-common/Wrestrict-3.c.jj 2018-01-25 14:16:01.574563425 
+0100
+++ gcc/testsuite/c-c++-common/Wrestrict-3.c2018-01-25 14:14:39.273547506 
+0100
@@ -0,0 +1,48 @@
+/* PR c/83989 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wrestrict" } */
+
+__attribute__((__malloc__)) extern void *my_malloc (__SIZE_TYPE__);
+void baz (void *);
+
+#define SIZE 32
+
+void
+foo (void)
+{
+  void *recmem = __builtin_malloc (SIZE);
+  baz (recmem);
+  while (1)
+{
+  void *oldrecmem = recmem;
+  recmem = __builtin_malloc (SIZE);
+  if (!recmem)
+   {
+ __builtin_free (oldrecmem);
+ return;
+   }
+  __builtin_memcpy (recmem, oldrecmem, SIZE);  /* { dg-bogus 
"accessing" } */
+  baz (recmem);
+  __builtin_free (oldrecmem);
+}
+}
+
+void
+bar (void)
+{
+  void *recmem = my_malloc (SIZE);
+  baz (recmem);
+  while (1)
+{
+  void *oldrecmem = recmem;
+  recmem = my_malloc (SIZE);
+  if (!recmem)
+   {
+ __builtin_free (oldrecmem);
+ return;
+   }
+  __builtin_memcpy (recmem, oldrecmem, SIZE);  /* { dg-bogus 
"accessing" } */
+  baz (recmem);
+  __builtin_free (oldrecmem);
+}
+}

Jakub

Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

[Marek Polacek]

On Thu, Jan 25, 2018 at 10:16:39PM +0100, Marek Polacek wrote:
> This is a similar problem to 83116: we'd cached a constexpr call, but after a
> store the result had become invalid, yet we used the wrong result again when
> encountering the same call later.  This resulted in evaluating a THROW_EXPR
> which doesn't work.  Details in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5
> 
> The fix for 83116 didn't work here, because when evaluating the body of the
> ctor via store_init_value -> cxx_constant_value we are in STRICT, so we do
> cache.
> 
> It seems that we may no longer rely on the constexpr call table when we
> do cxx_eval_store_expression, because that just rewrites *valp, i.e. the
> value of an object.  Might be too big a hammer again, but I couldn't think
> of how I could guard the caching of a constexpr call.
> 
> This doesn't manifest in C++14 because build_special_member_call in C++17 is
> more aggressive with copy elisions (as required by P0135 which changed how we
> view prvalues).  In C++14 build_special_member_call produces a CALL_EXPR, so
> expand_default_init calls maybe_constant_init, for which STRICT is false, so
> we avoid caching as per 83116.

...so the testcase should actually test c++17.  Consider that fixed.

Marek

[PATCH] Fix RTL DCE with separate shrink wrapped epilogues (PR rtl-optimization/83985)

[Jakub Jelinek]

Hi!

The r241060 change added the second hunk in this patch which the patch is
reverting.  The problem is that not deleting some unmarked insns in
delete_unmarked_insns is done in a wrong place, it causes indeed not to
delete the instruction we don't want to DCE, but the instructions that
are needed by the instructions (in this case a memory load whose result
the REG_CFA_RESTORE instruction uses) are not marked either and those are
deleted.

The following patch fixes it by making such instructions non-deletable,
which means they are marked and the DCE algorithm then marks the
instructions they need too.

Bootstrapped/regtested on {x86_64,i686,powerpc64{,le}}-linux, ok for trunk?

2018-01-25  Jakub Jelinek  

PR rtl-optimization/83985
* dce.c (deletable_insn_p): Return false for separate shrink wrapping
REG_CFA_RESTORE insns.
(delete_unmarked_insns): Don't ignore separate shrink wrapping
REG_CFA_RESTORE insns here.

* gcc.dg/pr83985.c: New test.

--- gcc/dce.c.jj2018-01-04 00:43:17.995703342 +0100
+++ gcc/dce.c   2018-01-25 17:55:49.750007894 +0100
@@ -131,6 +131,12 @@ deletable_insn_p (rtx_insn *insn, bool f
 && REGNO (pic_offset_table_rtx) >= FIRST_PSEUDO_REGISTER)
   return false;
 
+  /* Callee-save restores are needed.  */
+  if (RTX_FRAME_RELATED_P (insn)
+  && crtl->shrink_wrapped_separate
+  && find_reg_note (insn, REG_CFA_RESTORE, NULL))
+return false;
+
   body = PATTERN (insn);
   switch (GET_CODE (body))
 {
@@ -592,15 +598,6 @@ delete_unmarked_insns (void)
  if (!dbg_cnt (dce))
continue;
 
- if (crtl->shrink_wrapped_separate
- && find_reg_note (insn, REG_CFA_RESTORE, NULL))
-   {
- if (dump_file)
-   fprintf (dump_file, "DCE: NOT deleting insn %d, it's a "
-   "callee-save restore\n", INSN_UID (insn));
- continue;
-   }
-
  if (dump_file)
fprintf (dump_file, "DCE: Deleting insn %d\n", INSN_UID (insn));
 
--- gcc/testsuite/gcc.dg/pr83985.c.jj   2018-01-25 18:05:23.366121812 +0100
+++ gcc/testsuite/gcc.dg/pr83985.c  2018-01-25 18:05:03.513117871 +0100
@@ -0,0 +1,25 @@
+/* PR rtl-optimization/83985 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-additional-options "-mcpu=e300c3 -mtune=e300c3" { target { 
powerpc*-*-* && ilp32 } } } */
+
+long long int v;
+
+void
+foo (int x)
+{
+  if (x == 0)
+return;
+
+  while (v < 2)
+{
+  signed char *a;
+  v /= x;
+  a = v == 0 ? (signed char *) &x : (signed char *) &v;
+  ++*a;
+  ++v;
+}
+
+  while (1)
+;
+}

Jakub

Re: [C++ PATCH] Speed up inplace_merge algorithm & fix inefficient logic(PR c++/83938)

[chang jc]

Hi:

1. The __len = (__len + 1) / 2; is as you suggested, need to modify as
__len = (__len == 1) ? 0 : ((__len + 1) / 2);

2. The coding gain has been shown  PR c++/83938; I re-post here




  21
  20
  19
  18
  17
  16


  0.471136
  0.625695
  0.767262
  0.907461
  1.04838
  1.19508


  0.340845
  0.48651
  0.639139
  0.770133
  0.898454
  1.04632

it means when Merge [0, 4325376, 16777216); A is a sorted integer with
4325376 & B with 12451840 elements, total with 16M integers

The proposed method has the speed up under given buffer size =, ex
2^16, 2^17, ... 2^21 in unit of sizeof(int), for example, 2^16 means
given sizof(int)*64K bytes.

3. As your suggestion, _TmpBuf __buf should be rewrite.

4. It represents a fact that the intuitive idea to split from larger
part is wrong.

For example, if you have an input sorted array A & B, A has 8 integers
& B has 24 integers. Given tmp buffer whose capacity = 4 integers.

Current it tries to split from B, right?

Then we have:

A1 | A2  B1 | B2

B1 & B2 has 12 integers each, right?

Current algorithm selects pivot as 13th integer from B, right?

If the corresponding upper bound of A is 6th integer.

Then it split in

A1 = 5 | A2 = 3 | B1 = 12 | B2 = 12

After rotate, we have two arrays to merge

[A1 = 5 | B1 = 12]  & [A2 = 3 | B2 = 12]

Great, [A2 = 3 | B2 = 12] can use tmp buffer to merge.

Sadly, [A1 = 5 | B1 = 12] CANNOT.

So we do rotate again, split & merge the two split arrays from [A1 = 5
| B1 = 12] again.


But wait, if we always split from the smaller one instead of larger one.

After rotate, it promises two split arrays both contain ceiling[small/2].

Since tmp buffer also allocate by starting from sizeof(small) &
recursively downgrade by ceiling[small/2^(# of fail allocate)].

It means the allocated tmp buffer promises to be sufficient at the
level of (# of fail allocate).

Instead, you can see if split from large at level (# of fail allocate)
several split array still CANNOT use  tmp buffer to do buffered merge.


As you know, buffered merge is far speed then (split, rotate, and
merge two sub-arrays) (PR c++/83938 gives the profiling figures),

the way should provide speedup.


Thanks.










On 24/01/2018 18:23, François Dumont wrote:

Hi


It sounds like a very sensitive change to make but nothing worth figures.
Do you have any bench showing the importance of the gain ?

At least the memory usage optimization is obvious.

On 19/01/2018 10:43, chang jc wrote:

Current std::inplace_merge() suffers from performance issue by inefficient

logic under limited memory,

It leads to performance downgrade.

Please help to review it.

Index: include/bits/stl_algo.h
===
--- include/bits/stl_algo.h(revision 256871)
+++ include/bits/stl_algo.h(working copy)
@@ -2437,7 +2437,7 @@
_BidirectionalIterator __second_cut = __middle;
_Distance __len11 = 0;
_Distance __len22 = 0;
-  if (__len1 > __len2)
+  if (__len1 < __len2)
  {
__len11 = __len1 / 2;
std::advance(__first_cut, __len11);
@@ -2539,9 +2539,15 @@
const _DistanceType __len1 = std::distance(__first, __middle);
const _DistanceType __len2 = std::distance(__middle, __last);

+

typedef _Temporary_buffer<_BidirectionalIterator, _ValueType>
_TmpBuf;

-  _TmpBuf __buf(__first, __last);
-
+  _BidirectionalIterator __start, __end;
+  if (__len1 < __len2) {
+__start = __first; __end = __middle;
+  } else {
+__start = __middle; __end = __last;
+  }
+  _TmpBuf __buf(__start, ___end);

Note another optimization, we could introduce a _Temporary_buffer<> constructor
in order to write:

_TmpBuf __buf(std::min(__len1, __len2), __first);

So that std::distance do not need to be called again.

if (__buf.begin() == 0)
  std::__merge_without_buffer
(__first, __middle, __last, __len1, __len2, __comp);
Index: include/bits/stl_tempbuf.h
===
--- include/bits/stl_tempbuf.h(revision 256871)
+++ include/bits/stl_tempbuf.h(working copy)
@@ -95,7 +95,7 @@
  std::nothrow));
if (__tmp != 0)
  return std::pair<_Tp*, ptrdiff_t>(__tmp, __len);
-  __len /= 2;
+  __len = (__len + 1) / 2;

This part is problematic, if __len is 1 and allocation fails it will loop
forever.

It doesn't seem really necessary for your patch.


2018-01-20 4:05 GMT+08:00 Jason Merrill :

> This is a libstdc++ bug and patch, not the C++ front end.  So I'm
> adding the libstdc++ list to CC.
>
> On Fri, Jan 19, 2018 at 3:02 AM, chang jc  wrote:
> > Current std::inplace_merge() suffers from performance issue by
> inefficient
> > logic under limited memory,
> >
> > It leads to performance downgrade.
> >
> > Please help to review it.
> >
> > Index: include/bits/stl_algo.h
> > =

Re: [C++ PATCH] Fix constexpr handling of arrays with unknown bound (PR c++/83993)

[Jakub Jelinek]

On Thu, Jan 25, 2018 at 01:13:56PM -0700, Martin Sebor wrote:
> On 01/24/2018 04:19 PM, Jakub Jelinek wrote:
> > Hi!
> > 
> > In constexpr evaluation of array references for arrays with unknown bounds,
> > we need to diagnose out of bounds accesses, but really don't know the bounds
> > at compile time, right now GCC will see nelts as error_mark_node + 1 and
> > will not consider them a constant expression at all.
> > From the clang commit message it seems that CWG is leaning towards allowing
> > &array_with_unknown_bound[0] and array_with_unknown_bound, but disallowing
> > any other indexes (i.e. assume the array could have zero elements).
> > The following patch implements that.  Bootstrapped/regtested on x86_64-linux
> > and i686-linux, ok for trunk?
> 
> Unless your goal is to have GCC 8 reject just some subset of
> expressions in the reported test case (and fix the rest in
> the future) then there still are other potentially invalid
> expressions that GCC will continue to accept.  For example,
> the initialization of p in f() is rejected with the patch but
> the use of the same expression in g() is still accepted (Clang
> silently accepts both).  It could be due to the same problem
> as bug 82877.  Other similar issues are being tracked in bug
> 82876 and 82874.

The goal is to fix the PR and improve the handling of unknown
bound arrays while at it.
There is no time nor good timing for something much more substantial.
After all, with the patch we still don't reject e.g.
some cases if g++.dg/cpp0x/pr83993.C testcase uses the [a-z]2 pointers
instead of corresponding array in the array refs it tests.

>   extern const int a[];
> 
>   constexpr int f ()
>   {
> const int *p = &a[7], *q = &a[0];
> return p - q;
>   }
> 
>   constexpr int g ()
>   {
> return &a[7] - &a[0];
>   }
> 
>   constexpr const int i = f ();
>   constexpr const int j = g ();

I believe the fix for this is to save bodies of constexpr
functions/methods before the folding and do the constexpr evaluations on
those rather than on something we've folded already, but that is
certainly not suitable for GCC8.

> Regarding the patch, just a couple of minor nits:
> 
> The consensus we have reached some time back was not to quote
> integer constants so I would suggest to follow it in new code
> and take the opportunity to remove the quoting from surrounding
> code.
> 
>   https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Quoting

In this case I was just extending existing warning and wanted
consistency with that.  Both can be changed in a GCC9 follow-up,
or if Jason/Nathan want it now, even for GCC8, sure.

> In addition, I would suggest to phrase the error as "array
> subscript value %E is used *with* array qD" as opposed to
> "on array."  If we wanted to make it clearer that it's

That looks reasonable.

> the fact that the index is non-zero is the problem mentioning
> it in the warning might help ("non-zero array subscript %E...")

Well, even zero subscript is wrong if lval is false, i.e. a[0] + 1
rather than e.g. &a[0].  So we'd need to have another wordings
for the case when the index is zero.

> Alternatively, since the bounds are unknown is evident from
> the type of the array (e.g., "int[]") just: "array subscript
> value %E may be outside the bounds of array %qD of type %qT"
> might be good enough.

Dunno, perhaps.

Jakub

Re: Go patch committed: Rationalize external symbol names

[Ian Lance Taylor]

On Thu, Jan 25, 2018 at 12:50 PM, Rainer Orth
 wrote:
>
>> From the error messages I guess the problem is that the assembler
>> doesn't like symbols that start with ".1".  Do you know what names the
>> assembler permits?
>
> The x86 Assembly Language Reference Manual states:

Thanks.  Looking back, it was actually not my plan to have symbols
that start with '.'.  It was a bug, fixed by this patch.  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 257061)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-553e04735d1be372c596c720bcaea27e050b13a6
+203cbe7d3820fa03c965a01f72461f71588fe952
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/go-encode-id.cc
===
--- gcc/go/gofrontend/go-encode-id.cc   (revision 257033)
+++ gcc/go/gofrontend/go-encode-id.cc   (working copy)
@@ -104,6 +104,14 @@ go_encode_id(const std::string &id)
   std::string ret;
   const char* p = id.c_str();
   const char* pend = p + id.length();
+
+  // A leading ".0" is a space introduced before a mangled type name
+  // that starts with a 'u' or 'U', to avoid confusion with the
+  // mangling used here.  We don't need a leading ".0", and we don't
+  // want symbols that start with '.', so remove it.
+  if (p[0] == '.' && p[1] == '0')
+p += 2;
+
   while (p < pend)
 {
   unsigned int c;
@@ -115,16 +123,19 @@ go_encode_id(const std::string &id)
  go_assert(!char_needs_encoding(c));
  ret += c;
}
-  else if (c < 0x1)
-   {
- char buf[16];
- snprintf(buf, sizeof buf, "..u%04x", c);
- ret += buf;
-   }
   else
{
  char buf[16];
- snprintf(buf, sizeof buf, "..U%08x", c);
+ if (c < 0x1)
+   snprintf(buf, sizeof buf, "..u%04x", c);
+ else
+   snprintf(buf, sizeof buf, "..U%08x", c);
+
+ // We don't want a symbol to start with '.', so add a prefix
+ // if needed.
+ if (ret.empty())
+   ret += '_';
+
  ret += buf;
}
   p += len;
Index: gcc/go/gofrontend/names.cc
===
--- gcc/go/gofrontend/names.cc  (revision 257033)
+++ gcc/go/gofrontend/names.cc  (working copy)
@@ -213,7 +213,7 @@ Gogo::function_asm_name(const std::strin
 {
   std::string ret;
   if (rtype != NULL)
-ret = rtype->mangled_name(this);
+ret = rtype->deref()->mangled_name(this);
   else if (package == NULL)
 ret = this->pkgpath_symbol();
   else
@@ -892,14 +892,7 @@ Named_type::append_mangled_type_name(Gog
  const Typed_identifier* rcvr =
this->in_function_->func_value()->type()->receiver();
  if (rcvr != NULL)
-   {
- std::string m = rcvr->type()->mangled_name(gogo);
- // Turn a leading ".1" back into "*" since we are going
- // to type-mangle this name again.
- if (m.compare(0, 2, ".1") == 0)
-   m = "*" + m.substr(2);
- ret->append(m);
-   }
+   ret->append(rcvr->type()->deref()->mangled_name(gogo));
  else if (this->in_function_->package() == NULL)
ret->append(gogo->pkgpath_symbol());
  else
@@ -956,7 +949,7 @@ Gogo::type_descriptor_name(Type* type, N
  const Typed_identifier* rcvr =
in_function->func_value()->type()->receiver();
  if (rcvr != NULL)
-   ret.append(rcvr->type()->mangled_name(this));
+   ret.append(rcvr->type()->deref()->mangled_name(this));
  else if (in_function->package() == NULL)
ret.append(this->pkgpath_symbol());
  else
Index: libgo/testsuite/gotest
===
--- libgo/testsuite/gotest  (revision 256593)
+++ libgo/testsuite/gotest  (working copy)
@@ -518,7 +518,7 @@ localname() {
pattern='Test([^a-z].*)?'
# The -p option tells GNU nm not to sort.
# The -v option tells Solaris nm to sort by value.
-   tests=$($NM -p -v _gotest_.o $xofile | egrep " $text .*\."$pattern'$' | 
grep -v '\..*\..*\.' | fgrep -v '$' | fgrep -v ' __go_' | sed 's/.* //' | 
$symtogo)
+   tests=$($NM -p -v _gotest_.o $xofile | egrep " $text .*\."$pattern'$' | 
grep -v '\..*\.' | fgrep -v '$' | fgrep -v ' __go_' | sed 's/.* //' | $symtogo)
if [ "x$tests" = x ]; then
echo 'gotest: warning: no tests matching '$pattern in 
_gotest_.o $xofile 1>&2
exit 2
Index: libgo/go/runtime/pprof/pprof_test.go
===
--- libgo/go/runtime/pprof/pprof_test.go(revision 257033)
+++ libgo/

Go patch committed: Look through aliases when looking for methods

[Ian Lance Taylor]

This patch to the Go frontend fixes it to look through aliases when
looking for methods.  The code is simplified by adding Type::is_alias
to do this, replacing a few existing loops.  This fixes
https://golang.org/issue/23489.  The test case for this is
https://golang.org/cl/89935.  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 257068)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-203cbe7d3820fa03c965a01f72461f71588fe952
+897ce971b06a39c217d02dce9e1361bc7a240188
 
 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 257033)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -107,6 +107,34 @@ Type::forwarded() const
   return t;
 }
 
+// Skip alias definitions.
+
+Type*
+Type::unalias()
+{
+  Type* t = this->forwarded();
+  Named_type* nt = t->named_type();
+  while (nt != NULL && nt->is_alias())
+{
+  t = nt->real_type()->forwarded();
+  nt = t->named_type();
+}
+  return t;
+}
+
+const Type*
+Type::unalias() const
+{
+  const Type* t = this->forwarded();
+  const Named_type* nt = t->named_type();
+  while (nt != NULL && nt->is_alias())
+{
+  t = nt->real_type()->forwarded();
+  nt = t->named_type();
+}
+  return t;
+}
+
 // If this is a named type, return it.  Otherwise, return NULL.
 
 Named_type*
@@ -333,15 +361,9 @@ Type::are_identical_cmp_tags(const Type*
   return errors_are_identical ? true : t1 == t2;
 }
 
-  // Skip defined forward declarations.
-  t1 = t1->forwarded();
-  t2 = t2->forwarded();
-
-  // Ignore aliases for purposes of type identity.
-  while (t1->named_type() != NULL && t1->named_type()->is_alias())
-t1 = t1->named_type()->real_type()->forwarded();
-  while (t2->named_type() != NULL && t2->named_type()->is_alias())
-t2 = t2->named_type()->real_type()->forwarded();
+  // Skip defined forward declarations.  Ignore aliases.
+  t1 = t1->unalias();
+  t2 = t2->unalias();
 
   if (t1 == t2)
 return true;
@@ -1197,9 +1219,7 @@ Type::finish_backend(Gogo* gogo, Btype *
 Bexpression*
 Type::type_descriptor_pointer(Gogo* gogo, Location location)
 {
-  Type* t = this->forwarded();
-  while (t->named_type() != NULL && t->named_type()->is_alias())
-t = t->named_type()->real_type()->forwarded();
+  Type* t = this->unalias();
   if (t->type_descriptor_var_ == NULL)
 {
   t->make_type_descriptor_var(gogo);
@@ -1648,10 +1668,10 @@ Type::type_functions(Gogo* gogo, Named_t
 Function_type* equal_fntype, Named_object** hash_fn,
 Named_object** equal_fn)
 {
-  // If this loop leaves NAME as NULL, then the type does not have a
-  // name after all.
-  while (name != NULL && name->is_alias())
-name = name->real_type()->named_type();
+  // If the unaliased type is not a named type, then the type does not
+  // have a name after all.
+  if (name != NULL)
+name = name->unalias()->named_type();
 
   if (!this->is_comparable())
 {
@@ -2370,9 +2390,7 @@ static const int64_t max_ptrmask_bytes =
 Bexpression*
 Type::gc_symbol_pointer(Gogo* gogo)
 {
-  Type* t = this->forwarded();
-  while (t->named_type() != NULL && t->named_type()->is_alias())
-t = t->named_type()->real_type()->forwarded();
+  Type* t = this->unalias();
 
   if (!t->has_pointer())
 return gogo->backend()->nil_pointer_expression();
@@ -11494,9 +11512,9 @@ Type::find_field_or_method(const Type* t
   std::string* ambig2)
 {
   // Named types can have locally defined methods.
-  const Named_type* nt = type->named_type();
+  const Named_type* nt = type->unalias()->named_type();
   if (nt == NULL && type->points_to() != NULL)
-nt = type->points_to()->named_type();
+nt = type->points_to()->unalias()->named_type();
   if (nt != NULL)
 {
   Named_object* no = nt->find_local_method(name);
Index: gcc/go/gofrontend/types.h
===
--- gcc/go/gofrontend/types.h   (revision 256593)
+++ gcc/go/gofrontend/types.h   (working copy)
@@ -676,6 +676,15 @@ class Type
   const Type*
   forwarded() const;
 
+  // Return the type skipping any alias definitions and any defined
+  // forward declarations.  This is like forwarded, but also
+  // recursively expands alias definitions to the aliased type.
+  Type*
+  unalias();
+
+  const Type*
+  unalias() const;
+
   // Return true if this is a basic type: a type which is not composed
   // of other types, and is not void.
   bool

Re: [PATCH] Fix RTL DCE with separate shrink wrapped epilogues (PR rtl-optimization/83985)

[Segher Boessenkool]

On Thu, Jan 25, 2018 at 11:20:33PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> The r241060 change added the second hunk in this patch which the patch is
> reverting.  The problem is that not deleting some unmarked insns in
> delete_unmarked_insns is done in a wrong place, it causes indeed not to
> delete the instruction we don't want to DCE, but the instructions that
> are needed by the instructions (in this case a memory load whose result
> the REG_CFA_RESTORE instruction uses) are not marked either and those are
> deleted.
> 
> The following patch fixes it by making such instructions non-deletable,
> which means they are marked and the DCE algorithm then marks the
> instructions they need too.

Looks good to me!  Thanks.  And sorry for causing the bug in the first
place :-/


Segher

Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64

[Joseph Myers]

On Thu, 25 Jan 2018, vladimir.mezent...@oracle.com wrote:

> From: Vladimir Mezentsev 
> 
> Tested on aarch64-linux-gnu, x86_64-pc-linux-gnu and 
> sparc64-unknown-linux-gnu.
> No regression. New tests now passed.
> There is a performance degradation for complex double type:

This is, of course, something to consider for GCC 9; it's not suitable for 
the current development stage.

Could you provide a more extended writeup of the issue (starting with the 
argument for it being a bug at all), the approach you took and the 
rationale for the approach, when you resubmit the patch for GCC 9 stage 1?

> * libgcc/config/sparc/sfp-machine.h: New

Are you introducing a requirement for all architectures to provide 
sfp-machine.h?  If so, did you determine that SPARC was the only one 
lacking it?  If not the only one lacking it, you need to make sure that 
you do not break any existing architecture in GCC.

What about architectures using non-IEEE formats?  soft-fp is not suitable 
for those, but you mustn't break them.  Remember that e.g. TFmode can be 
IBM long double, and other ?Fmode similarly need not be IEEE; the name 
only indicates how many bytes are in the format, nothing else about it.

What about powerpc __divkc3?

What was the rationale for using soft-fp rather than adding appropriate 
built-in functions as suggested in a comment?

These are the sorts of issues you need to cover in your patch write-up, to 
demonstrate that you have allowed for the range of targets supported in 
GCC, have taken care to avoid breaking them and have made deliberate 
choices that are appropriate in each case (but might not be the same for 
every target).

> +static inline int get_cde(int c, int d)

Lots of the new functions need comments on them to explain their 
semantics.  Also, the formatting needs fixing to follow the GNU Coding 
Standards ("static inline int" on its own line, space before '(').

> +  if (cde != 0) {

Similarly, bad formatting, "{" goes on the next line.

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

[PATCH] restore -Warray-bounds for string literals (PR 83776)

[Martin Sebor]

PR tree-optimization/83776 - [6/7/8 Regression] missing
-Warray-bounds indexing past the end of a string literal,
identified a not-so-recent improvement to constant propagation
as the reason for GCC no longer being able to detect out-of-
bounds accesses to string literals.  The root cause is that
the change caused accesses to strings to be transformed into
MEM_REFs that the -Warray-bounds checker isn't prepared to
handle.  A simple example is:

  int h (void)
  {
const char *p = "1234";
return p[16];   // missing -Warray-bounds
  }

To fix the regression the attached patch extends the array bounds
checker to handle the small subset of MEM_REF expressions that
refer to string literals but stops of short of doing more than
that.  There are outstanding gaps in the detection that the patch
intentionally doesn't handle.  They are either caused by other
regressions (PR 84047) or by other latent bugs/limitations, or
by limitations in the approach I took to try to keep the patch
simple.  I hope to address some of those in a follow-up patch
for GCC 9.

Martin
PR tree-optimization/83776 - [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

gcc/ChangeLog:

	PR tree-optimization/83776
	* tree-vrp.c (vrp_prop::check_mem_ref): New function.
	(check_array_bounds): Call it.

gcc/testsuite/ChangeLog:

	PR tree-optimization/83776
	* gcc.dg/Warray-bounds-27.c: New test.
	* gcc.dg/Warray-bounds-28.c: New test.
	* gcc.dg/Warray-bounds-29.c: New test.

diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-27.c b/gcc/testsuite/gcc.dg/Warray-bounds-27.c
new file mode 100644
index 000..ccc88cd
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-27.c
@@ -0,0 +1,223 @@
+/* PR tree-optimization/83776: missing -Warray-bounds indexing past the end
+   of a string literal
+   Test to exercise detection of out-of-bounds indices into narrow string
+   literals.
+   { dg-do compile }
+   { dg-options "-O2 -Warray-bounds -ftrack-macro-expansion=0" } */
+
+#include "range.h"
+
+#define MAX DIFF_MAX
+#define MIN DIFF_MIN
+
+#define S1 "1"
+#define S3 "123"
+#define S7 "1234567"
+#define S8 "12345678"
+#define S9 "123456789"
+
+void sink (int, ...);
+
+#define T(expr)   sink (0, expr)
+
+
+void narrow_direct_cst (void)
+{
+  T (S1[MIN]);/* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[2]" "" { xfail *-*-* } } */
+  T (S1[-1]); /* { dg-warning "array subscript -1 is below array bounds of .char\\\[2]" } */
+  T (S1[0]);
+  T (S1[1]);
+  T (S1[2]);  /* { dg-warning "array subscript 2 is above array bounds of .char\\\[2]" } */
+  T (S1[MAX]);/* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[2]" } */
+
+  T (&S1[MIN]);   /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[2]" } */
+  T (&S1[-1]);/* { dg-warning "array subscript -1 is below array bounds of .char\\\[2]" } */
+  T (&S1[0]);
+  T (&S1[2]);
+  T (&S1[3]); /* { dg-warning "array subscript 3 is above array bounds of .char\\\[2]" } */
+  T (&S1[MAX]);   /* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[2]" } */
+
+  T (S9[MIN]);/* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[10]" "" { xfail *-*-* } } */
+  T (S9[-1]); /* { dg-warning "array subscript -1 is below array bounds of .char\\\[10]" } */
+  T (S9[9]);
+  T (S9[10]); /* { dg-warning "array subscript 10 is above array bounds of .char\\\[10]" } */
+  T (S9[11]); /* { dg-warning "array subscript 11 is above array bounds of .char\\\[10]" } */
+  T (S9[MAX]);/* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[10]" } */
+
+  T (&S9[MIN]);   /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[10]" } */
+  T (&S9[-1]);/* { dg-warning "array subscript -1 is below array bounds of .char\\\[10]" } */
+  T (&S9[9]);
+  T (&S9[10]);
+  T (&S9[11]); /* { dg-warning "array subscript 11 is above array bounds of .char\\\[10]" } */
+  T (&S9[MAX]);   /* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[10]" } */
+}
+
+void narrow_ptr_deref_cst (void)
+{
+  const char *p = S8 + 9;
+
+  T (*(p + MIN)); /* { dg-warning "array subscript -\[0-9\]+ is outside array bounds of .char\\\[9]." } */
+  T (*(p - 10));  /* { dg-warning "array subscript -1 is outside array bounds of .char\\\[9]." } */
+  T (*(p - 9));
+  T (*(p - 1));
+  T (*p); /* { dg-warning "array subscript 9 is outside array bounds of .char\\\[9]." } */
+  T (*(p + 1));   /* { dg-warning "array subscript 10 is outside array bounds of .char\\\[9]." } */
+  T (*(p + 2));   /* { dg-warning "array subscript 11 is outside array bounds o

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 1/25/18 3:56 PM, Peter Bergner wrote:
> Ok, I'll move the table to driver-rs6000.c and I'll resubmit.

Ok, here is a separate translation table like you wanted.  I still use the
RS6000_CPU table to hold entire list of canonical cpu names, the new
translation table in driver-rs6000.c only contains cpus whose AT_PLATFORM
names do not match their GCC canonical names.  I also added the pa6t to
970 translation you mentioned in the bugzilla.  If you want me to drop
that, that's easy enough to do.

I realize I also failed to mention in the first submission, that I have
added caching of the elf_plaform() result, so we don't have to mount and
scan /proc/self/auxv multiple times.

Is this better?  I did the same unit testing by forcing unknown names
and names that need translation and I've verified it works.  Bootstrap
and regtesting is still running though.

Peter

PR target/56010
PR target/83743
* config/rs6000/driver-rs6000.c: #include "diagnostic.h".
(rs6000_supported_cpu_names): New static variable.
(linux_cpu_translation_table): Likewise.
(elf_platform) : Define new static variable and use it.
Translate kernel AT_PLATFORM name to canonical name if needed.
Error if platform name is unknown.

Index: gcc/config/rs6000/driver-rs6000.c
===
--- gcc/config/rs6000/driver-rs6000.c   (revision 256364)
+++ gcc/config/rs6000/driver-rs6000.c   (working copy)
@@ -23,6 +23,7 @@
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
+#include "diagnostic.h"
 #include 
 
 #ifdef _AIX
@@ -38,6 +39,44 @@
 # include 
 #endif
 
+#ifdef __linux__
+/* Canonical GCC cpu name table.  */
+static const char *rs6000_supported_cpu_names[] =
+{
+#define RS6000_CPU(NAME, CPU, FLAGS) NAME,
+#include "rs6000-cpus.def"
+#undef RS6000_CPU
+};
+
+/* This table holds a list of cpus where their Linux AT_PLATFORM name differs
+   from their GCC canonical name.  The first column in a row contains the GCC
+   canonical cpu name and the other columns in that row contain AT_PLATFORM
+   names that should be mapped to the canonical name.  */
+
+static const char *linux_cpu_translation_table[][4] = {
+  { "403", "ppc403", NULL },
+  { "405", "ppc405", NULL },
+  { "440", "ppc440", "ppc440gp", NULL },
+  { "476", "ppc470", NULL },
+  { "601", "ppc601", NULL },
+  { "603", "ppc603", NULL },
+  { "604", "ppc604", NULL },
+  { "7400", "ppc7400", NULL },
+  { "7450", "ppc7450", NULL },
+  { "750", "ppc750", NULL },
+  { "823", "ppc823", NULL },
+  { "8540", "ppc8540", NULL },
+  { "8548", "ppc8548", NULL },
+  { "970", "ppc970", "pa6t", NULL },
+  { "cell", "ppc-cell-be", NULL },
+  { "e500mc", "ppce500mc", NULL },
+  { "e5500", "ppce5500", NULL },
+  { "e6500", "ppce6500", NULL },
+  { "power7", "power7+", NULL },
+  { NULL } /* End of table sentinel.  */
+};
+#endif
+
 const char *host_detect_local_cpu (int argc, const char **argv);
 
 #if GCC_VERSION >= 0
@@ -158,15 +197,19 @@
 
 #ifdef __linux__
 
-/* Returns AT_PLATFORM if present, otherwise generic PowerPC.  */
+/* Returns the canonical AT_PLATFORM if present, otherwise NULL.  */
 
 static const char *
 elf_platform (void)
 {
-  int fd;
+  static const char *cpu = NULL;
 
-  fd = open ("/proc/self/auxv", O_RDONLY);
+  /* Use the cached AT_PLATFORM cpu name if we've already determined it.  */
+  if (cpu != NULL)
+return cpu;
 
+  int fd = open ("/proc/self/auxv", O_RDONLY);
+
   if (fd != -1)
 {
   char buf[1024];
@@ -179,15 +222,60 @@
   if (n > 0)
{
  for (av = (ElfW(auxv_t) *) buf; av->a_type != AT_NULL; ++av)
-   switch (av->a_type)
+   if (av->a_type == AT_PLATFORM)
  {
- case AT_PLATFORM:
-   return (const char *) av->a_un.a_val;
-
- default:
+   cpu = (const char *) av->a_un.a_val;
break;
  }
}
+
+  /* Verify that CPU is either a valid -mcpu= option name, or is a
+valid alternative name.  If it is a valid alternative name, then use
+the canonical name.  */
+  if (cpu != NULL)
+   {
+ size_t i, j, len = 0;
+ char *s, *p;
+
+ /* Check if AT_PLATFORM is a GCC canonical cpu name.  */
+ for (i = 0; i < ARRAY_SIZE (rs6000_supported_cpu_names); i++)
+   {
+ if (!strcmp (cpu, rs6000_supported_cpu_names[i]))
+   return cpu;
+ len += strlen (rs6000_supported_cpu_names[i]) + 1;
+   }
+
+ /* Check if AT_PLATFORM can be translated to a canonical cpu name.  */
+ for (i = 0; linux_cpu_translation_table[i][0] != NULL; i++)
+   {
+ const char *canonical = linux_cpu_translation_table[i][0];
+ for (j = 1; linux_cpu_translation_table[i][j] != NULL; j++)
+   if (!strcmp (cpu, linux_cpu_translation_table[i][j]))
+ {
+   cpu = canonical;
+

Re: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} issues (PR target/83488)

[Kirill Yukhin]

Hello Julia,
On 24 Jan 14:00, Koval, Julia wrote:
> Hi,
> Fixed it. Ok for trunk?
> 
> gcc/
>   * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask,
>   _mm512_mask_bitshuffle_epi64_mask, _mm256_bitshuffle_epi64_mask,
>   _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask,
>   _mm_mask_bitshuffle_epi64_mask): Fix type.
>   * config/i386/i386-builtin-types.def (UHI_FTYPE_V2DI_V2DI_UHI,
>   USI_FTYPE_V4DI_V4DI_USI): Remove.
>   * config/i386/i386-builtin.def (__builtin_ia32_vpshufbitqmb512_mask,
>   __builtin_ia32_vpshufbitqmb256_mask,
>   __builtin_ia32_vpshufbitqmb128_mask): Fix types.
>   * config/i386/i386.c (ix86_expand_args_builtin): Remove old types.
>   * config/i386/sse.md (VI1_AVX512VLBW): Change types.
> 
> gcc/testsuite/
>   * gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Add -mavx512f 
> -mavx512bw.
>   * gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c: Add -mavx512bw.
>   * gcc.target/i386/i386.exp: Fix types.
Your patch is OK for trunk. I've checked it in.

--
Thanks, K
> 
> Thanks,
> Julia
> 
> > -Original Message-
> > From: Kirill Yukhin [mailto:kirill.yuk...@gmail.com]
> > Sent: Saturday, January 20, 2018 11:49 AM
> > To: Koval, Julia 
> > Cc: 'Jakub Jelinek' ; 'Uros Bizjak' ;
> > 'GCC Patches' 
> > Subject: Re: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} 
> > issues (PR
> > target/83488)
> > 
> > Hello Julia,
> > On 12 Jan 08:55, Koval, Julia wrote:
> > > Changelog
> > >
> > > gcc/
> > >   * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask,
> > >   _mm512_mask_bitshuffle_epi64_mask,
> > _mm256_bitshuffle_epi64_mask,
> > >   _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask,
> > >   _mm_mask_bitshuffle_epi64_mask): Fix type.
> > >   * config/i386/i386-builtin-types.def (UHI_FTYPE_V2DI_V2DI_UHI,
> > >   USI_FTYPE_V4DI_V4DI_USI): Remove.
> > >   * config/i386/i386-builtin.def (__builtin_ia32_vpshufbitqmb512_mask,
> > >   __builtin_ia32_vpshufbitqmb256_mask,
> > >   __builtin_ia32_vpshufbitqmb128_mask): Fix types.
> > >   * config/i386/i386.c (ix86_expand_args_builtin): Remove old types.
> > >   * config/i386/sse.md (VI48_AVX512VLBW): Change types.
> > >
> > > gcc/testsuite/
> > >   * gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Add -mavx512f -
> > mavx512bw.
> > >   * gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c: Add -mavx512bw.
> > >   * gcc.target/i386/i386.exp: Fix types.
> > 
> >  (define_mode_iterator VI48_AVX512VLBW
> > -  [(V8DI "TARGET_AVX512BW") (V4DI  "TARGET_AVX512VL")
> > -   (V2DI  "TARGET_AVX512VL")])
> > +  [(V64QI "TARGET_AVX512BW") (V32QI  "TARGET_AVX512VL")
> > +   (V16QI  "TARGET_AVX512VL")])
> > I'd call this iterator VI1_AVX512VLBW.
> > 
> > --
> > Thanks, K
> 

Re: [PATCH, wwwdocs] Update GCC 8 release notes for NDS32 port

[Chung-Ju Wu]

Gerald Pfeifer on 2018/1/23 22:39 wrote:

On Tue, 23 Jan 2018, Chung-Ju Wu wrote:

+New command-line options -mext-perf -mext-perf2 -mext-string


Can you write this as

   "...-mext-perf, -mext-perf2, and
   -mext-string..."

please?

Approved with that change.



Thank you for the review. :)

I made the change and committed it as revision 1.33 of 
htdosc/gcc-8/changes.html.


Best regards,
jasonwucj



Gerald