Re: [patch, fortran] Fix character length in constructors

[Janne Blomqvist]

On Tue, Feb 20, 2018 at 12:41 AM, Thomas Koenig  wrote:
> Hello world,
>
> when putting in a seemingly innocent simplification for PR 56342,
> I caused a regression in PR 82823, in PACK. The root cause of
> this one turned out to be PR 48890, in which structure
> constructors containing characters were not handled correctly
> if the lengths did not match.
>
> The attached patch fixes that.
>
> Regression-tested. OK for trunk?

It's better to use gfc_mpz_get_hwi() instead of mpz_get_si().
mpz_get_si() returns a long, which is a 32-bit type on win64.

Otherwise Ok with the spelling fix suggested by Steve.

-- 
Janne Blomqvist

C++ PATCH for c++/84429, ICE capturing VLA

[Jason Merrill]

We already handle stripping dereferences for non-VLA captures, just
need to do the same thing for VLAs in the case of a nested capture.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 95a82187a0986740f6357f74ba6d03814ba7fc1c
Author: Jason Merrill 
Date:   Sun Feb 18 23:57:57 2018 -0500

PR c++/84429 - ICE capturing VLA.

* lambda.c (build_capture_proxy): Handle reference refs.

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 38500b13262..a0a80dfde5c 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -451,11 +451,12 @@ build_capture_proxy (tree member, tree init)
{
  if (PACK_EXPANSION_P (init))
init = PACK_EXPANSION_PATTERN (init);
- if (INDIRECT_REF_P (init))
-   init = TREE_OPERAND (init, 0);
- STRIP_NOPS (init);
}
 
+  if (INDIRECT_REF_P (init))
+   init = TREE_OPERAND (init, 0);
+  STRIP_NOPS (init);
+
   gcc_assert (VAR_P (init) || TREE_CODE (init) == PARM_DECL);
   while (is_normal_capture_proxy (init))
init = DECL_CAPTURED_VARIABLE (init);
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla1.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla1.C
new file mode 100644
index 000..91498c4589a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla1.C
@@ -0,0 +1,9 @@
+// PR c++/84429
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+void foo(int i)
+{
+  char x[i];
+  [&]{ [&]{ return x; }; };
+}

Re: [C++ PATCH] Fix ICE with __builtin_launder (PR c++/84445)

[Jason Merrill]

OK.

On Mon, Feb 19, 2018 at 2:08 PM, Jakub Jelinek  wrote:
> Hi!
>
> For internal functions, we use the whole u.bits of the CALL_EXPR
> for the internal function number (in this case IFN_LAUNDER), so using
> the lang flags on it doesn't work.  In a couple of other places
> I've checked that test or set lang flags on CALL_EXPR I saw internal fns
> special cased early, but admittedly haven't checked everything.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-02-19  Jakub Jelinek  
>
> PR c++/84445
> * class.c (fixed_type_or_null) : Only test
> TREE_HAS_CONSTRUCTOR if instance is not an internal function call.
>
> * g++.dg/cpp1z/launder7.C: New test.
>
> --- gcc/cp/class.c.jj   2018-02-16 19:39:08.184061984 +0100
> +++ gcc/cp/class.c  2018-02-19 13:34:33.726813207 +0100
> @@ -7128,7 +7128,8 @@ fixed_type_or_null (tree instance, int *
>
>  case CALL_EXPR:
>/* This is a call to a constructor, hence it's never zero.  */
> -  if (TREE_HAS_CONSTRUCTOR (instance))
> +  if (CALL_EXPR_FN (instance)
> + && TREE_HAS_CONSTRUCTOR (instance))
> {
>   if (nonnull)
> *nonnull = 1;
> --- gcc/testsuite/g++.dg/cpp1z/launder7.C.jj2018-02-19 13:50:05.954797679 
> +0100
> +++ gcc/testsuite/g++.dg/cpp1z/launder7.C   2018-02-19 13:47:26.603792932 
> +0100
> @@ -0,0 +1,10 @@
> +// PR c++/84445
> +// { dg-do compile }
> +
> +struct A { virtual void foo (); };
> +
> +void
> +bar (A *p)
> +{
> +  __builtin_launder (p)->foo ();
> +}
>
> Jakub

Re: [C++ PATCH] Fix ICE in bot_manip (PR c++/84449)

[Jason Merrill]

OK.

On Mon, Feb 19, 2018 at 2:04 PM, Jakub Jelinek  wrote:
> Hi!
>
> build_cplus_new can return error_mark_node e.g. when calling a deleted
> ctor or dtor, but bot_manip was assuming it will always return
> AGGR_INIT_EXPR.  As it is generally unsafe to set subexpressions to
> error_mark_node, e.g. cp_fold ICEs if binary expression has one of its
> operand error_mark_node, the patch instead arranges for the whole
> break_out_target_exprs to return error_mark_node in that case.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-02-19  Jakub Jelinek  
>
> PR c++/84449
> * tree.c (bot_manip): If build_cplus_new or break_out_target_exprs
> returns error_mark_node, return it immediately.
> (break_out_target_exprs): If cp_walk_tree with bot_manip returns
> error_mark_node, return error_mark_node.
>
> * g++.dg/cpp0x/constexpr-84449.C: New test.
>
> --- gcc/cp/tree.c.jj2018-02-10 00:22:01.0 +0100
> +++ gcc/cp/tree.c   2018-02-19 11:54:55.815478346 +0100
> @@ -2896,6 +2896,8 @@ bot_manip (tree* tp, int* walk_subtrees,
> {
>   u = build_cplus_new (TREE_TYPE (t), TREE_OPERAND (t, 1),
>tf_warning_or_error);
> + if (u == error_mark_node)
> +   return u;
>   if (AGGR_INIT_ZERO_FIRST (TREE_OPERAND (t, 1)))
> AGGR_INIT_ZERO_FIRST (TREE_OPERAND (u, 1)) = true;
> }
> @@ -2913,6 +2915,8 @@ bot_manip (tree* tp, int* walk_subtrees,
>  (splay_tree_value) TREE_OPERAND (u, 0));
>
>TREE_OPERAND (u, 1) = break_out_target_exprs (TREE_OPERAND (u, 1));
> +  if (TREE_OPERAND (u, 1) == error_mark_node)
> +   return error_mark_node;
>
>/* Replace the old expression with the new version.  */
>*tp = u;
> @@ -3025,7 +3029,8 @@ break_out_target_exprs (tree t)
>  target_remap = splay_tree_new (splay_tree_compare_pointers,
>/*splay_tree_delete_key_fn=*/NULL,
>/*splay_tree_delete_value_fn=*/NULL);
> -  cp_walk_tree (, bot_manip, target_remap, NULL);
> +  if (cp_walk_tree (, bot_manip, target_remap, NULL) == error_mark_node)
> +t = error_mark_node;
>cp_walk_tree (, bot_replace, target_remap, NULL);
>
>if (!--target_remap_count)
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-84449.C.jj 2018-02-19 
> 12:04:51.518530240 +0100
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-84449.C2018-02-19 
> 12:04:26.643528069 +0100
> @@ -0,0 +1,14 @@
> +// PR c++/84449
> +// { dg-do compile { target c++11 } }
> +
> +struct A
> +{
> +  constexpr A (int) {}
> +  ~A () = delete;
> +};
> +
> +struct B
> +{
> +  A a;
> +  constexpr B () : a (0) {}// { dg-error "use of deleted function" }
> +};
>
> Jakub

Re: [C++ PATCH] Fix GC lambda ICE (PR c++/84455)

[Jason Merrill]

OK.

On Mon, Feb 19, 2018 at 1:56 PM, Jakub Jelinek  wrote:
> Hi!
>
> While cp_parser_lambda_body which is the other finish_lambda_function
> caller next to tsubst_lambda_expr temporarily increments function_depth
> around that call (if not nested) to avoid GC during expand_or_defer_fn from
> finish_lambda_function, tsubst_lambda_expr doesn't, and on the
> lambda-ice14.C we can see the GC in action in that case.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2018-02-19  Jakub Jelinek  
>
> PR c++/84455
> * pt.c (tsubst_lambda_expr): If not nested, increment temporarily
> function_depth to avoid GC during finish_lambda_function.
>
> * g++.dg/cpp0x/lambda/lambda-ice26.C: New test.
>
> --- gcc/cp/pt.c.jj  2018-02-16 23:37:29.312364263 +0100
> +++ gcc/cp/pt.c 2018-02-19 10:48:00.328184302 +0100
> @@ -17070,6 +17070,10 @@ tsubst_lambda_expr (tree t, tree args, t
>bool nested = cfun;
>if (nested)
> push_function_context ();
> +  else
> +   /* Still increment function_depth so that we don't GC in the
> +  middle of an expression.  */
> +   ++function_depth;
>
>local_specialization_stack s (lss_copy);
>
> @@ -17084,6 +17088,8 @@ tsubst_lambda_expr (tree t, tree args, t
>
>if (nested)
> pop_function_context ();
> +  else
> +   --function_depth;
>
>/* The capture list was built up in reverse order; fix that now.  */
>LAMBDA_EXPR_CAPTURE_LIST (r)
> --- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C.jj 2018-02-19 
> 10:51:24.838188732 +0100
> +++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C2018-02-19 
> 10:51:19.690188624 +0100
> @@ -0,0 +1,5 @@
> +// PR c++/84455
> +// { dg-do compile { target c++11 } }
> +// { dg-options "--param ggc-min-heapsize=0" }
> +
> +#include "lambda-ice14.C"
>
> Jakub

Re: [C++ PATCH] Fix lambda error recovery (PR c++/84446)

[Jason Merrill]

OK.

On Mon, Feb 19, 2018 at 2:12 PM, Paolo Carlini  wrote:
> Hi,
>
> On 19/02/2018 20:05, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> In this case, because the corresponding variable is errorneous, we end up
>> with error_mark_node in LAMBDA_TYPE_EXTRA_SCOPE.  This patch just makes
>> sure
>> we won't crash on it.  Not 100% sure if this is the best fix though.
>
> IMHO something like the below - which just completed testing on x86_64-linux
> - could also make sense: among other things, we would catch the problem
> earlier - no need to check for error_mark_node as part of a loop - and the
> diagnostic would be more terse and identical to the non-template case. I
> should also add that normally when we use start_lambd_scope (decl) we *know*
> one way or the other that decl != error_mark_node, and that isn't the case
> here (in fact we check decl != error_mark_node in a couple of other places
> nearby)
>
> Thanks!
> Paolo.
>
> //
>
>

[PATCH] consider successor blocks when avoiding -Wstringop-truncation (PR 84468)

[Martin Sebor]

PR 84468 points out a false positive in -Wstringop-truncation
in code like this:

  struct A { char a[4]; };

  void f (struct A *p, const struct A *q)
  {
if (p->a)
  strncpy (p->a, q->a, sizeof p->a - 1);   // warning here

p->a[3] = '\0';
  }

The warning is due to the code checking only the same basic block
as the one with the strncpy call for an assignment to the destination
to avoid it, but failing to check the successor basic block if there
is no subsequent statement in the current block.  (Eliminating
the conditional is being tracked in PR 21474.)

The attached test case adds logic to avoid this false positive.
I don't know under what circumstances there could be more than
one successor block here so I don't handle that case.

Tested on x86_64-linux.

Martin
PR tree-optimization/84468 - bogus -Wstringop-truncation despite assignment after conditional strncpy

gcc/testsuite/ChangeLog:

	PR tree-optimization/84468
	* gcc.dg/Wstringop-truncation.c: New test.

gcc/ChangeLog:

	PR tree-optimization/84468
	* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Also consider successor
	basic blocks.

Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c	(revision 257796)
+++ gcc/tree-ssa-strlen.c	(working copy)
@@ -1851,8 +1851,18 @@ maybe_diag_stxncpy_trunc (gimple_stmt_iterator gsi
  avoid the truncation warning.  */
   gsi_next_nondebug ();
   gimple *next_stmt = gsi_stmt (gsi);
+  if (!next_stmt)
+{
+  /* When there is no statement in the same basic block check
+	 the immediate successor block.  */
+  basic_block bb = gimple_bb (stmt);
+  basic_block nextbb
+	= EDGE_COUNT (bb->succs) ? EDGE_SUCC (bb, 0)->dest : NULL;
+  gimple_stmt_iterator it = gsi_start_bb (nextbb);
+  next_stmt = gsi_stmt (it);
+}
 
-  if (!gsi_end_p (gsi) && is_gimple_assign (next_stmt))
+  if (next_stmt && is_gimple_assign (next_stmt))
 {
   tree lhs = gimple_assign_lhs (next_stmt);
   tree_code code = TREE_CODE (lhs);
Index: gcc/testsuite/gcc.dg/Wstringop-truncation.c
===
--- gcc/testsuite/gcc.dg/Wstringop-truncation.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/Wstringop-truncation.c	(working copy)
@@ -0,0 +1,116 @@
+/* PR tree-optimization/84468 - Inconsistent -Wstringop-truncation warnings
+   with -O2
+   { dg-do compile }
+   { dg-options "-O2 -Wstringop-truncation -ftrack-macro-expansion=0" }  */
+
+#define strncpy __builtin_strncpy
+
+struct A
+{
+  char a[4];
+};
+
+void no_pred_succ (struct A *p, const struct A *q)
+{
+  strncpy (p->a, q->a, sizeof p->a - 1);  /* { dg-warning "\\\[-Wstringop-truncation" } */
+}
+
+
+void no_succ (struct A *p, const struct A *q)
+{
+  if (q->a)
+strncpy (p->a, q->a, sizeof p->a - 1);/* { dg-warning "\\\[-Wstringop-truncation" } */
+}
+
+
+void succ (struct A *p, const struct A *q)
+{
+  /* Verify that the assignment suppresses the warning for the conditional
+ strcnpy call.  The conditional should be folded to true since the
+ address of an array can never be null (see bug 84470).  */
+  if (q->a)
+strncpy (p->a, q->a, sizeof p->a - 1);/* { dg-bogus "\\\[-Wstringop-truncation" } */
+
+  p->a[sizeof p->a - 1] = 0;
+}
+
+
+void succ_2 (struct A *p, const struct A *q, int i)
+{
+  /* Same as above but with a conditional that cannot be eliminated.  */
+  if (i < 0)
+strncpy (p->a, q->a, sizeof p->a - 1);/* { dg-bogus "\\\[-Wstringop-truncation" } */
+
+  p->a[sizeof p->a - 1] = 0;
+}
+
+
+int next_succ (struct A *p, const struct A *q, int i, int j)
+{
+  /* Same as above but with a nested conditionals with else clauses.  */
+  if (i < 0)
+{
+  if (j < 0)
+	strncpy (p->a, q->a, sizeof p->a - 1);/* { dg-bogus "\\\[-Wstringop-truncation" } */
+}
+  else
+__builtin_strcpy (p->a, q->a);
+
+  p->a[sizeof p->a - 1] = 0;
+  return 0;
+}
+
+
+int next_succ_1 (struct A *p, const struct A *q, int i, int j)
+{
+  /* Same as above but with a nested conditionals with else clauses.  */
+  if (i < 0)
+{
+  if (j < 0)
+	strncpy (p->a, q->a, sizeof p->a - 1);/* { dg-bogus "\\\[-Wstringop-truncation" } */
+  else
+	strncpy (p->a, q->a, sizeof p->a - 2);/* { dg-bogus "\\\[-Wstringop-truncation" } */
+}
+
+  p->a[sizeof p->a - 2] = 0;
+  return 1;
+}
+
+
+int next_succ_2 (struct A *p, const struct A *q, int i, int j)
+{
+  /* Same as above but with a nested conditionals with else clauses.  */
+  if (i < 0)
+{
+  if (j < 0)
+	strncpy (p->a, q->a, sizeof p->a - 1);/* { dg-bogus "\\\[-Wstringop-truncation" } */
+  else
+	strncpy (p->a, q->a, sizeof p->a - 2);/* { dg-bogus "\\\[-Wstringop-truncation" } */
+}
+  else
+__builtin_strcpy (p->a, q->a);
+
+  p->a[sizeof p->a - 2] = 0;
+  return 2;
+}
+
+
+void cond_succ_warn (struct A *p, const struct A *q, int i)
+{
+  /* Verify that a conditional assignment doesn't suppress the warning.  

[PATCH] Defer pow (C, x) folding until after vectorization always (PR middle-end/82004)

[Jakub Jelinek]

Hi!

While I've over-simplified the testcase and so this patch doesn't help
the 628.pop2_s miscompare, I still believe it is beneficial to defer this
folding until late for these reasons:
1) if we propagate a constant into the second pow argument too, it will
   be likely more precise than going through the exp (cst * x) way
2) except when C is M_E, pow is fewer operations and thus smaller IL

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

2018-02-19  Jakub Jelinek  

PR middle-end/82004
* match.pd (pow(C,x) -> exp(log(C)*x)): Delay all folding until
after vectorization.

* gfortran.dg/pr82004.f90: New test.

--- gcc/match.pd.jj 2018-02-15 12:15:51.655780636 +0100
+++ gcc/match.pd2018-02-19 17:38:06.390763194 +0100
@@ -4006,7 +4006,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (simplify
(pows REAL_CST@0 @1)
(if (real_compare (GT_EXPR, TREE_REAL_CST_PTR (@0), )
-   && real_isfinite (TREE_REAL_CST_PTR (@0)))
+   && real_isfinite (TREE_REAL_CST_PTR (@0))
+   /* As libmvec doesn't have a vectorized exp2, defer optimizing
+  the use_exp2 case until after vectorization.  It seems actually
+  beneficial for all constants to postpone this until later,
+  because exp(log(C)*x), while faster, will have worse precision
+  and if x folds into a constant too, that is unnecessary
+  pessimization.  */
+   && canonicalize_math_after_vectorization_p ())
 (with {
const REAL_VALUE_TYPE *const value = TREE_REAL_CST_PTR (@0);
bool use_exp2 = false;
@@ -4021,10 +4028,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  }
  (if (!use_exp2)
   (exps (mult (logs @0) @1))
-  /* As libmvec doesn't have a vectorized exp2, defer optimizing
-this until after vectorization.  */
-  (if (canonicalize_math_after_vectorization_p ())
-   (exp2s (mult (log2s @0) @1
+  (exp2s (mult (log2s @0) @1)))
 
  (for sqrts (SQRT)
   cbrts (CBRT)
--- gcc/testsuite/gfortran.dg/pr82004.f90.jj2018-02-19 17:58:57.435682156 
+0100
+++ gcc/testsuite/gfortran.dg/pr82004.f90   2018-02-19 17:58:34.127684892 
+0100
@@ -0,0 +1,18 @@
+! PR middle-end/82004
+! { dg-do run }
+! { dg-options "-Ofast" }
+
+  integer, parameter :: r8 = selected_real_kind(13), i4 = kind(1)
+  integer (i4), parameter :: a = 400, b = 2
+  real (r8), parameter, dimension(b) :: c = (/ .001_r8, 10.00_r8 /)
+  real (r8) :: d, e, f, g, h
+  real (r8), parameter :: j &
+= 10**(log10(c(1))-(log10(c(b))-log10(c(1)))/real(a))
+
+  d = c(1)
+  e = c(b)
+  f = (log10(e)-log10(d))/real(a)
+  g = log10(d) - f
+  h = 10**(g)
+  if (h.ne.j) stop 1
+end

Jakub

Re: [PATCH] gold: Use autotools pthread macro

[Cary Coutant]

> config-patches has nothing to do with the GCC config/ directory. It is
> the place to send patches for config.{guess,sub}. Taking if off the
> cc: line.

Sorry, Ben. I've started a new thread on gcc-patches for the config/
part of this patch.

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01138.html

-cary

[config patch] Fwd from binutils: add ax_pthread.m4 to config/ directory

[Cary Coutant]

Please see this patch posted to the binutils list:

   https://sourceware.org/ml/binutils/2018-02/msg00260.html

where Joshua proposes to add the ax_pthread.m4 script, from the
autoconf macro archive, to the config/ directory in order to improve
gold's configure-time detection of thread support.

Is the config/ part of this patch OK?

config/
* ax_pthread.m4: New file.

-cary

Re: [RFC] Tree loop unroller pass

[Kugan Vivekanandarajah]

Hi Richard,

On 16 February 2018 at 22:56, Richard Biener  wrote:
> On Thu, Feb 15, 2018 at 11:30 PM, Kugan Vivekanandarajah
>  wrote:
>> Hi Wilko,
>>
>> Thanks for your comments.
>>
>> On 14 February 2018 at 00:05, Wilco Dijkstra  wrote:
>>> Hi Kugan,
>>>
 Based on the previous discussions, I tried to implement a tree loop
 unroller for partial unrolling. I would like to queue this RFC patches
 for next stage1 review.
>>>
>>> This is a great plan - GCC urgently requires a good unroller!
>
> How so?
>
 * Cost-model for selecting the loop uses the same params used
 elsewhere in related optimizations. I was told that keeping this same
 would allow better tuning for all the optimizations.
>>>
>>> I'd advise against using the existing params as is. Unrolling by 8x by 
>>> default is
>>> way too aggressive and counterproductive. It was perhaps OK for in-order 
>>> cores
>>> 20 years ago, but not today. The goal of unrolling is to create more ILP in 
>>> small
>>> loops, not to generate huge blocks of repeated code which definitely won't 
>>> fit in
>>> micro-op caches and loop buffers...
>>>
>> OK, I will create separate params. It is possible that I misunderstood
>> it in the first place.
>
> To generate more ILP for modern out-of-order processors you need to be
> able to do followup transforms that remove dependences.  So rather than
> inventing magic params we should look at those transforms and key
> unrolling on them.  Like we do in predictive commoning or other passes
> that end up performing unrolling as part of their transform.
>
> Our measurements on x86 concluded that unrolling isn't worth it, in fact
> it very often hurts.  That was of course with saner params than the defaults
> of the RTL unroller.

My preliminary benchmarking with x86 using default params slows no
overall gain. Some gains and some regressions. I didn't play with the
parameters to see if it improves.

But for AArch64 - Falkor (with follow up tag collision avoidance for
prefetching), we did see gains (again we could do better here):

SPECint_base2006  1.37%
SPECint_base2006  -0.73%
SPECspeed2017_int_base -0.1%
SPECspeed2017_fp_base 0.89%
SPECrate2017_fp_base 1.72%

We also noticed that sometimes the gains for  passes like prefetch
loop array comes mainly from unrolling rather than the software
prefetches.

>
> Often you even have to fight with followup passes doing stuff that ends up
> inreasing register pressure too much so we end up spilling.
If we can have an approximate register pressure model that can be used
while deciding unrolling factor, it might help to some extend. I saw
Bin posting some patches for register pressure calculation. Do you
think using that here will be helpful?

In general, I agree that cost model can be more accurate but getting
the right information within acceptable computation cost is the trick.
Do you have any preference on cost model if we decided to have
separate loop unroller pass? I.e., what information from loop should
we use other than the usual parameters we have?

>
>>
>>> Also we need to enable this by default, at least with -O3, maybe even for 
>>> small
>>> (or rather tiny) loops in -O2 like LLVM does.
>> It is enabled for -O3 and above now.
>
> So _please_ first get testcases we know unrolling will be beneficial on
> and _also_ have a thorough description _why_.

I will try to analyse the benchmarks whose performance is improving
and create test cases.

>
>>>
 * I have also implemented an option to limit loops based on memory
 streams. i.e., some micro-architectures where limiting the resulting
 memory streams is preferred and used  to limit unrolling factor.
>>>
>>> I'm not convinced this is needed once you tune the parameters for unrolling.
>>> If you have say 4 read streams you must have > 10 instructions already so
>>> you may want to unroll this 2x in -O3, but definitely not 8x. So I see the 
>>> streams
>>> issue as a problem caused by too aggressive unroll settings. I think if you
>>> address that first, you're unlikely going to have an issue with too many 
>>> streams.
>>>
>>
>> I will experiment with some microbenchmarks. I still think that it
>> will be useful for some micro-architectures. Thats why, it its not
>> enabled by default. If a back-end thinks that it is useful, they can
>> enable limiting unroll factor based on memory streams.
>
> Note that without doing scheduling at the same time (basically interleaving
> iterations rather than pasting them after each other) I have a hard time
> believing that maxing memory streams is any good on any microarchitecture.

Sorry, I didn't meant to say that. Rather, keep the emory streams
below what prefetches will be happy with.

>
> So transform-wise you'd end up with "vectorizing" without "vectorizing" and 
> you
> can share dependence analysis.
>
 * I expect that there will be some cost-model changes might be 

Re: [patch, fortran] Fix character length in constructors

[Steve Kargl]

On Mon, Feb 19, 2018 at 11:41:30PM +0100, Thomas Koenig wrote:
> 
> Regression-tested. OK for trunk?
> 

OK with the fix suggested below.


> Index: primary.c
> ===
> --- primary.c (Revision 257788)
> +++ primary.c (Arbeitskopie)
> @@ -2879,6 +2879,38 @@ gfc_convert_to_structure_constructor (gfc_expr *e,
>if (!this_comp)
>   goto cleanup;
>  
> +  /* For a constant string constructor, make sure the length is correct;
> +  truncate of fill with blanks if needed.  */

truncate or fill

-- 
Steve

Re: [C++ PATCH] Fix lambda error recovery (PR c++/84446)

[Jakub Jelinek]

On Mon, Feb 19, 2018 at 08:12:48PM +0100, Paolo Carlini wrote:
> On 19/02/2018 20:05, Jakub Jelinek wrote:
> > Hi!
> > 
> > In this case, because the corresponding variable is errorneous, we end up
> > with error_mark_node in LAMBDA_TYPE_EXTRA_SCOPE.  This patch just makes sure
> > we won't crash on it.  Not 100% sure if this is the best fix though.
> IMHO something like the below - which just completed testing on x86_64-linux
> - could also make sense: among other things, we would catch the problem
> earlier - no need to check for error_mark_node as part of a loop - and the
> diagnostic would be more terse and identical to the non-template case. I
> should also add that normally when we use start_lambd_scope (decl) we *know*
> one way or the other that decl != error_mark_node, and that isn't the case
> here (in fact we check decl != error_mark_node in a couple of other places
> nearby)

Looks better to me indeed.

> Index: cp/parser.c
> ===
> --- cp/parser.c   (revision 257817)
> +++ cp/parser.c   (working copy)
> @@ -19644,12 +19644,12 @@ cp_parser_init_declarator (cp_parser* parser,
>member templates.  The former involves deferring
>parsing of the initializer until end of class as with default
>arguments.  So right here we only handle the latter.  */
> -   if (!member_p && processing_template_decl)
> +   if (!member_p && processing_template_decl && decl != error_mark_node)
>   start_lambda_scope (decl);
> initializer = cp_parser_initializer (parser,
>  _direct_init,
>  _non_constant_init);
> -   if (!member_p && processing_template_decl)
> +   if (!member_p && processing_template_decl && decl != error_mark_node)
>   finish_lambda_scope ();
> if (initializer == error_mark_node)
>   cp_parser_skip_to_end_of_statement (parser);
> Index: testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C
> ===
> --- testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C  (nonexistent)
> +++ testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C  (working copy)
> @@ -0,0 +1,8 @@
> +// PR c++/84446
> +// { dg-do compile { target c++11 } }
> +
> +template void foo()
> +{
> +  int i,
> +  i = [] { virtual }();  // { dg-error "redefinition|expected" }
> +}


Jakub

Re: [committed] Fix overload15.C testcase (PR c++/79064)

[Jakub Jelinek]

On Mon, Feb 19, 2018 at 03:31:13PM -0500, David Edelsohn wrote:
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01247.html
> 
> === g++ tests ===
> 
> 
> Running target unix/-m32
> ...
> FAIL: g++.dg/template/overload15.C  -std=c++11 (test for excess errors)
> FAIL: g++.dg/template/overload15.C  -std=c++14 (test for excess errors)
> FAIL: g++.dg/template/overload15.C  -std=c++98 (test for excess errors)

But that one is
LAST_UPDATED: Mon Feb 19 11:29:19 UTC 2018 (revision 257803)
I've fixed the testcase only in r257818.

Jakub

[patch, fortran] Fix character length in constructors

[Thomas Koenig]

Hello world,

when putting in a seemingly innocent simplification for PR 56342,
I caused a regression in PR 82823, in PACK. The root cause of
this one turned out to be PR 48890, in which structure
constructors containing characters were not handled correctly
if the lengths did not match.

The attached patch fixes that.

Regression-tested. OK for trunk?

Regards

Thomas

2018-02-19  Thomas Koenig  

PR fortran/48890
PR fortran/83823
* primary.c (gfc_convert_to_structure_constructor):
For a constant string constructor, make sure the length
is correct.

2018-02-19  Thomas Koenig  

PR fortran/48890
PR fortran/83823
* gfortran.dg/structure_constructor_14.f90: New test.
! { dg-do  run }
! PR 48890, PR 83823
! Test fix for wrong length in parameters. Original test cases
! by mhp77 (a) gmx.at and Harald Anlauf.

program gfcbug145
  implicit none
  type t_obstyp
character(len=8) :: name
  end type t_obstyp
  type (t_obstyp) ,parameter :: obstyp(*)= &
 [ t_obstyp ('SYNOP' ), &
   t_obstyp ('DRIBU' ), &
   t_obstyp ('TEMP'  ), &
   t_obstyp ('RADAR' )  ]
  logical :: mask(size(obstyp)) = .true.
  character(len=100) :: line
  type (t_obstyp), parameter :: x = t_obstyp('asdf')

  write(line,'(20(a8,:,"|"))') pack (obstyp% name, mask)
  if (line /= 'SYNOP   |DRIBU   |TEMP|RADAR') call abort
  write (line,'("|",A,"|")') x
  if (line /= "|asdf|") call abort
end program gfcbug145
Index: primary.c
===
--- primary.c	(Revision 257788)
+++ primary.c	(Arbeitskopie)
@@ -2879,6 +2879,38 @@ gfc_convert_to_structure_constructor (gfc_expr *e,
   if (!this_comp)
 	goto cleanup;
 
+  /* For a constant string constructor, make sure the length is correct;
+	 truncate of fill with blanks if needed.  */
+  if (this_comp->ts.type == BT_CHARACTER && !this_comp->attr.allocatable
+	  && this_comp->ts.u.cl && this_comp->ts.u.cl->length
+	  && this_comp->ts.u.cl->length->expr_type == EXPR_CONSTANT
+	  && actual->expr->expr_type == EXPR_CONSTANT)
+	{
+	  ptrdiff_t c, e;
+	  c = mpz_get_si (this_comp->ts.u.cl->length->value.integer);
+	  e = actual->expr->value.character.length;
+
+	  if (c != e)
+	{
+	  ptrdiff_t i, to;
+	  gfc_char_t *dest;
+	  dest = gfc_get_wide_string (c + 1);
+
+	  to = e < c ? e : c;
+	  for (i = 0; i < to; i++)
+		dest[i] = actual->expr->value.character.string[i];
+	  
+	  for (i = e; i < c; i++)
+		dest[i] = ' ';
+
+	  dest[c] = '\0';
+	  free (actual->expr->value.character.string);
+
+	  actual->expr->value.character.length = c;
+	  actual->expr->value.character.string = dest;
+	}
+	}
+
   comp_tail->val = actual->expr;
   if (actual->expr != NULL)
 	comp_tail->where = actual->expr->where;

Re: [Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

[Paul Richard Thomas]

Committed as revision 257827.


> 1. The resolve.c part of the patch seems to have incorrect indentation?

I can't see what you are referring to. I'll correct it if needs be

>
> 2. Instead of gfc_index_zero_node would it be better to use
> build_zero_cst (gfc_charlen_type_node)? Or is the same code used also
> for something related to arrays? If so, probably safer to leave as is,
> as the character length code should nowadays use fold_convert
> relatively judiciously where needed.

gfc_index_zero_node is not actually used, other than as a flag in
effect. Look at trans-decl.c:1778. No, I wasn't responsible for this
bit of code!
>
> 3. For associate_36.f90, I believe that testcase was due to Steve
> Kargl and not me.

Oh bother. I forgot about this remark. I'll correct the attribution tomorrow.

>
> 4. I believe you can credit yourself with fixing PR 83975 as well in
> the Changelog.

Done. However, as the testcase showed, it was all fixed with the other pRS :-)

>
> With these minor quibbles out of the way, Ok for trunk.
>
  Janne Blomqvist

Many thanks

Paul

Re: [PATCH 1/2] Untangle stddef.h a little

[coypu]

ping
they're good patches. ask questions. I have more.

Re: [PATCH] gold: Use autotools pthread macro

[Ben Elliston]

On Mon, Feb 19, 2018 at 12:39:47PM -0800, Cary Coutant wrote:

> I've added config-patches to the conversation, so I'm hoping that
> was sufficient to get that going. Once added in the GCC tree, I
> think one can either wait for an automatic sync, or go ahead and
> submit a patch to do the sync (but I'm not completely versed on how
> the shared directories really operate).

config-patches has nothing to do with the GCC config/ directory. It is
the place to send patches for config.{guess,sub}. Taking if off the
cc: line.

Ben


signature.asc
Description: PGP signature

Re: [committed] Fix overload15.C testcase (PR c++/79064)

[Jakub Jelinek]

On Mon, Feb 19, 2018 at 03:20:25PM -0500, David Edelsohn wrote:
> This testcase continues to fail for -m32 on powerpc64-linux-gnu and on AIX.
> 
> Excess errors:
> /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:14:10:
> error: call of overloaded 'f<0>(char (*)[1])' is ambiguous
> /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:15:10:
> error: no matching function for call to 'f<0>(char (*)[7])'

Can't reproduce on powerpc64-linux-gnu:

hostname; md5sum ../../gcc/testsuite/g++.dg/template/overload15.C; make 
check-c++-all RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
dg.exp=overload15.C'
gcc1-power7.osuosl.org
74f8286a84b07ec4d8ba0b125a014426  
../../gcc/testsuite/g++.dg/template/overload15.C
make RUNTESTFLAGS="--target_board=unix\{-m32,-m64\} dg.exp=overload15.C 
--stds=98,11,14,17,2a,concepts" check-g++
make[1]: Entering directory `/home/jakub/gcc2/obj20/gcc'
rm -rf testsuite/g++-parallel
make[2]: Entering directory `/home/jakub/gcc2/obj20/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
   && [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
   && [ -f testsuite/g++-parallel/finished ]; then \
  rm -rf testsuite/g++; \
else \
  cd testsuite/g++; \
  rm -f tmp-site.exp; \
  sed '/set tmpdir/ s|testsuite$|testsuite/g++|' \
< ../../site.exp > tmp-site.exp; \
  /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
  EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo 
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
  if [ -f ${rootme}/../expect/expect ] ; then  \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
  fi ; \
  `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo 
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool g++ 
--target_board=unix\{-m32,-m64\} dg.exp=overload15.C 
--stds=98,11,14,17,2a,concepts; \
  if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/g++-parallel/finished; \
  fi ; \
fi )
WARNING: Couldn't find the global config file.
Test Run By jakub on Mon Feb 19 20:27:41 2018
Native configuration is powerpc64-unknown-linux-gnu

=== g++ tests ===

Schedule of variations:
unix/-m32
unix/-m64

Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/jakub/gcc2/gcc/testsuite/config/default.exp as 
tool-and-target-specific interface file.
Running /home/jakub/gcc2/gcc/testsuite/g++.dg/dg.exp ...

=== g++ Summary for unix/-m32 ===

# of expected passes6
Running target unix/-m64
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/jakub/gcc2/gcc/testsuite/config/default.exp as 
tool-and-target-specific interface file.
Running /home/jakub/gcc2/gcc/testsuite/g++.dg/dg.exp ...

=== g++ Summary for unix/-m64 ===

# of expected passes6

=== g++ Summary ===

# of expected passes12
/home/jakub/gcc2/obj20/gcc/testsuite/g++/../../xg++  version 8.0.1 20180214 
(experimental) (GCC) 

make[2]: Leaving directory `/home/jakub/gcc2/obj20/gcc'
make[1]: Leaving directory `/home/jakub/gcc2/obj20/gcc'

Jakub

[committed] Fix OpenMP parsing error-recovery (PR c++/84448)

[Jakub Jelinek]

Hi!

When cp_parser_binary_expression is called with no_toplevel_fold_p
(only for OpenMP parsing), it might create a binary op tree with
error_mark_node as one of the operands, which the rest of the FE
isn't prepared to handle.

This arranges to return error_mark_node instead.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2018-02-19  Jakub Jelinek  

PR c++/84448
* parser.c (cp_parser_binary_expression): For no_toplevel_fold_p, if
either operand is error_mark_node, set current.lhs to that instead of
creating a binary op with error_mark_node operands.

* g++.dg/gomp/pr84448.C: New test.

--- gcc/cp/parser.c.jj  2018-02-13 21:21:37.565978250 +0100
+++ gcc/cp/parser.c 2018-02-19 16:14:34.994863674 +0100
@@ -9331,12 +9331,18 @@ cp_parser_binary_expression (cp_parser*
  && lookahead_prec <= current.prec
  && sp == stack)
{
- current.lhs
-   = build_min (current.tree_type,
-TREE_CODE_CLASS (current.tree_type) == tcc_comparison
-? boolean_type_node : TREE_TYPE (current.lhs),
-current.lhs.get_value (), rhs.get_value ());
- SET_EXPR_LOCATION (current.lhs, combined_loc);
+ if (current.lhs == error_mark_node || rhs == error_mark_node)
+   current.lhs = error_mark_node;
+ else
+   {
+ current.lhs
+   = build_min (current.tree_type,
+TREE_CODE_CLASS (current.tree_type)
+== tcc_comparison
+? boolean_type_node : TREE_TYPE (current.lhs),
+current.lhs.get_value (), rhs.get_value ());
+ SET_EXPR_LOCATION (current.lhs, combined_loc);
+   }
}
   else
 {
--- gcc/testsuite/g++.dg/gomp/pr84448.C.jj  2018-02-19 16:19:09.614928616 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr84448.C 2018-02-19 16:20:36.703967955 +0100
@@ -0,0 +1,17 @@
+// PR c++/84448
+// { dg-do compile }
+
+struct A
+{
+  operator int () const;
+  A& operator += (int);
+  A& operator ++ ();
+};
+
+void
+foo (A a, A b)
+{
+  #pragma omp for
+  for (A i = a; i <=; ++i) // { dg-error "expected primary-expression 
before" }
+;  // { dg-error "invalid controlling predicate" 
"" { target *-*-* } .-1 }
+}

Jakub

Re: [committed] Fix overload15.C testcase (PR c++/79064)

[David Edelsohn]

On Mon, Feb 19, 2018 at 3:35 PM, Jakub Jelinek  wrote:
> On Mon, Feb 19, 2018 at 03:31:13PM -0500, David Edelsohn wrote:
>> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01247.html
>>
>> === g++ tests ===
>>
>>
>> Running target unix/-m32
>> ...
>> FAIL: g++.dg/template/overload15.C  -std=c++11 (test for excess errors)
>> FAIL: g++.dg/template/overload15.C  -std=c++14 (test for excess errors)
>> FAIL: g++.dg/template/overload15.C  -std=c++98 (test for excess errors)
>
> But that one is
> LAST_UPDATED: Mon Feb 19 11:29:19 UTC 2018 (revision 257803)
> I've fixed the testcase only in r257818.

I thought that your patch was from earlier.  I'll check again with the
currently running build.

Thanks, David

Re: [PATCH] gold: Use autotools pthread macro

[Cary Coutant]

>> First, do you or your company have a copyright assignment on file with FSF?
>
> I do not. What is the process for that? I don't need a company
> assignment, an individual contributor for me will be fine.
>
> If I sign that for this project, would it also cover GCC, or do I need
> one for each?

It will cover all FSF contributions.

If config/ax_pthread.m4 is accepted by the config maintainers, I doubt
you'd need an assignment for that, since it's already licensed and
it's not actually your contribution.

That leaves a fairly small change to gold sources (not counting
auto-regenerated files) -- small enough that I don't think you need to
complete an assignment.

If  you do want to file a copyright assignment for future changes,
I'll forward you a copy of the form and instructions separately.

>> I could be wrong, but I believe adding to config/ will require
>> approval from a GCC config/ maintainer. The normal process, as I
>> understand it, would be to add the file to the GCC tree, then sync it
>> into the binutils tree. I'm not in a position to approve that, nor can
>> I judge on the acceptability of the copyright notice in that file.
>
> Ok. I didn't realize the config/ directory came from GCC. I'll look
> into getting it submitted there How does that get "synced" to
> binutils? Would I make a patch to add it here after it is added there?

I've added config-patches to the conversation, so I'm hoping that was
sufficient to get that going. Once added in the GCC tree, I think one
can either wait for an automatic sync, or go ahead and submit a patch
to do the sync (but I'm not completely versed on how the shared
directories really operate).

> FWIW, it is the same license as the ax_check_define macro (also from
> the autotools macro archive) that is already in config/

That suggests to me that there shouldn't be a problem adding this new file.

>> I'd like to retain the ability to use --disable-threads as a configure 
>> option.
>
> I will add that back in.

Thanks.

>> If this is just to get MinGW on board, is there a lighter-weight way
>> of doing that? Could we just add a configure option that switches
>> between -lpthread and -pthread (or whatever option is needed)? I like
>> the idea of fully automating it, but that's a pretty big m4 file!
>
> It is pretty large I pulled it straight from the autoconf macro
> archive. IMHO, its much better quality than anything I would be able
> to come up with otherwise, and pretty brain-dead easy for the end
> user. It should "just work" without any special switches (although the
> user *can* configure it with some env-vars I think).

Sounds good to me if others agree.

>> (BTW, In the future, please omit diffs from generated files from your patch.)
>
> Will do. I couldn't find a lot of examples of config changes in
> binutils, but I thought the one that I did updated the generated files
> also. I must have been mistaken.

It's a convention that makes reviewing and applying patches easier for
us maintainers, but it's easy to forget to strip out those diffs.

-cary

Re: [committed] Fix overload15.C testcase (PR c++/79064)

[David Edelsohn]

https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01247.html

=== g++ tests ===


Running target unix/-m32
...
FAIL: g++.dg/template/overload15.C  -std=c++11 (test for excess errors)
FAIL: g++.dg/template/overload15.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/template/overload15.C  -std=c++98 (test for excess errors)

- David



On Mon, Feb 19, 2018 at 3:28 PM, Jakub Jelinek  wrote:
> On Mon, Feb 19, 2018 at 03:20:25PM -0500, David Edelsohn wrote:
>> This testcase continues to fail for -m32 on powerpc64-linux-gnu and on AIX.
>>
>> Excess errors:
>> /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:14:10:
>> error: call of overloaded 'f<0>(char (*)[1])' is ambiguous
>> /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:15:10:
>> error: no matching function for call to 'f<0>(char (*)[7])'
>
> Can't reproduce on powerpc64-linux-gnu:
>
> hostname; md5sum ../../gcc/testsuite/g++.dg/template/overload15.C; make 
> check-c++-all RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
> dg.exp=overload15.C'
> gcc1-power7.osuosl.org
> 74f8286a84b07ec4d8ba0b125a014426  
> ../../gcc/testsuite/g++.dg/template/overload15.C
> make RUNTESTFLAGS="--target_board=unix\{-m32,-m64\} dg.exp=overload15.C 
> --stds=98,11,14,17,2a,concepts" check-g++
> make[1]: Entering directory `/home/jakub/gcc2/obj20/gcc'
> rm -rf testsuite/g++-parallel
> make[2]: Entering directory `/home/jakub/gcc2/obj20/gcc'
> (rootme=`${PWDCMD-pwd}`; export rootme; \
> srcdir=`cd ../../gcc; ${PWDCMD-pwd}` ; export srcdir ; \
> if [ -n "" ] \
>&& [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
>&& [ -f testsuite/g++-parallel/finished ]; then \
>   rm -rf testsuite/g++; \
> else \
>   cd testsuite/g++; \
>   rm -f tmp-site.exp; \
>   sed '/set tmpdir/ s|testsuite$|testsuite/g++|' \
> < ../../site.exp > tmp-site.exp; \
>   /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
>   EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo 
> ${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
>   if [ -f ${rootme}/../expect/expect ] ; then  \
> TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
> export TCL_LIBRARY ; \
>   fi ; \
>   `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo 
> ${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool g++ 
> --target_board=unix\{-m32,-m64\} dg.exp=overload15.C 
> --stds=98,11,14,17,2a,concepts; \
>   if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
> touch ${rootme}/testsuite/g++-parallel/finished; \
>   fi ; \
> fi )
> WARNING: Couldn't find the global config file.
> Test Run By jakub on Mon Feb 19 20:27:41 2018
> Native configuration is powerpc64-unknown-linux-gnu
>
> === g++ tests ===
>
> Schedule of variations:
> unix/-m32
> unix/-m64
>
> Running target unix/-m32
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
> Using /home/jakub/gcc2/gcc/testsuite/config/default.exp as 
> tool-and-target-specific interface file.
> Running /home/jakub/gcc2/gcc/testsuite/g++.dg/dg.exp ...
>
> === g++ Summary for unix/-m32 ===
>
> # of expected passes6
> Running target unix/-m64
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
> Using /home/jakub/gcc2/gcc/testsuite/config/default.exp as 
> tool-and-target-specific interface file.
> Running /home/jakub/gcc2/gcc/testsuite/g++.dg/dg.exp ...
>
> === g++ Summary for unix/-m64 ===
>
> # of expected passes6
>
> === g++ Summary ===
>
> # of expected passes12
> /home/jakub/gcc2/obj20/gcc/testsuite/g++/../../xg++  version 8.0.1 20180214 
> (experimental) (GCC)
>
> make[2]: Leaving directory `/home/jakub/gcc2/obj20/gcc'
> make[1]: Leaving directory `/home/jakub/gcc2/obj20/gcc'
>
> Jakub

Re: [committed] Fix overload15.C testcase (PR c++/79064)

[David Edelsohn]

This testcase continues to fail for -m32 on powerpc64-linux-gnu and on AIX.

Excess errors:
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:14:10:
error: call of overloaded 'f<0>(char (*)[1])' is ambiguous
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:15:10:
error: no matching function for call to 'f<0>(char (*)[7])'

The full error message with suggestions is:

/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:
In function 'void f()':
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:14:10:
error: call of overloaded 'f<0>(char (*)[1])' is ambiguous
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:5:6:
note: candidate: 'void f(char (*)[(((0 - 1) > N) ? 1 : 7)]) [with
unsigned int N = 0]'
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:8:6:
note: candidate: 'void f(char (*)[(((0 - 1) > N) ? 1 : 7)]) [with
unsigned int N = 0]'
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:15:10:
error: no matching function for call to 'f<0>(char (*)[7])'
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:5:6:
note: candidate: 'template void f(char (*)[(((0 - 1) >
N) ? 1 : 7)])'
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:5:6:
note:   template argument deduction/substitution failed:
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:15:8:
note:   cannot convert '& y' (type 'char (*)[7]') to type 'char
(*)[1]'
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:8:6:
note: candidate: 'template void f(char (*)[(((0 - 1) >
N) ? 1 : 7)])'
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:8:6:
note:   template argument deduction/substitution failed:
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:15:8:
note:   cannot convert '& y' (type 'char (*)[7]') to type 'char
(*)[1]'

[PATCH] Fix builtin_mathfn_code ICE on internal fns (PR c++/84444)

[Jakub Jelinek]

Hi!

Many years ago Jason has added call to get_callee_fndecl, which does the
right thing for internal functions as well as handles ADDR_EXPR and also
casts and constant function pointers with a usable DECL_INITIAL, so while
to fix this PR I could have added || CALL_EXPR_FN (t)) == NULL_TREE before
the || TREE_CODE (CALL_EXPR_FN (t)) != ADDR_EXPR check, IMHO it is just
better to remove it, get_callee_fndecl will DTRT.

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

2018-02-19  Jakub Jelinek  

PR c++/8
* builtins.c (builtin_mathfn_code): Don't check if CALL_EXPR_FN (t)
is ADDR_EXPR.

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

--- gcc/builtins.c.jj   2018-01-18 21:11:57.272207030 +0100
+++ gcc/builtins.c  2018-02-19 14:05:58.887842922 +0100
@@ -7836,8 +7836,7 @@ builtin_mathfn_code (const_tree t)
   const_tree argtype, parmtype;
   const_call_expr_arg_iterator iter;
 
-  if (TREE_CODE (t) != CALL_EXPR
-  || TREE_CODE (CALL_EXPR_FN (t)) != ADDR_EXPR)
+  if (TREE_CODE (t) != CALL_EXPR)
 return END_BUILTINS;
 
   fndecl = get_callee_fndecl (t);
--- gcc/testsuite/g++.dg/cpp1z/launder8.C.jj2018-02-19 14:13:07.120887805 
+0100
+++ gcc/testsuite/g++.dg/cpp1z/launder8.C   2018-02-19 14:12:43.369885316 
+0100
@@ -0,0 +1,11 @@
+// PR c++/8
+// { dg-do compile }
+// { dg-options "-O2" }
+
+struct A {};
+
+__UINTPTR_TYPE__
+foo (A *p)
+{
+  return (__UINTPTR_TYPE__) __builtin_launder (p);
+}

Jakub

[C++ PATCH] Fix GC lambda ICE (PR c++/84455)

[Jakub Jelinek]

Hi!

While cp_parser_lambda_body which is the other finish_lambda_function
caller next to tsubst_lambda_expr temporarily increments function_depth
around that call (if not nested) to avoid GC during expand_or_defer_fn from
finish_lambda_function, tsubst_lambda_expr doesn't, and on the
lambda-ice14.C we can see the GC in action in that case.

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

2018-02-19  Jakub Jelinek  

PR c++/84455
* pt.c (tsubst_lambda_expr): If not nested, increment temporarily
function_depth to avoid GC during finish_lambda_function.

* g++.dg/cpp0x/lambda/lambda-ice26.C: New test.

--- gcc/cp/pt.c.jj  2018-02-16 23:37:29.312364263 +0100
+++ gcc/cp/pt.c 2018-02-19 10:48:00.328184302 +0100
@@ -17070,6 +17070,10 @@ tsubst_lambda_expr (tree t, tree args, t
   bool nested = cfun;
   if (nested)
push_function_context ();
+  else
+   /* Still increment function_depth so that we don't GC in the
+  middle of an expression.  */
+   ++function_depth;
 
   local_specialization_stack s (lss_copy);
 
@@ -17084,6 +17088,8 @@ tsubst_lambda_expr (tree t, tree args, t
 
   if (nested)
pop_function_context ();
+  else
+   --function_depth;
 
   /* The capture list was built up in reverse order; fix that now.  */
   LAMBDA_EXPR_CAPTURE_LIST (r)
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C.jj 2018-02-19 
10:51:24.838188732 +0100
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C2018-02-19 
10:51:19.690188624 +0100
@@ -0,0 +1,5 @@
+// PR c++/84455
+// { dg-do compile { target c++11 } }
+// { dg-options "--param ggc-min-heapsize=0" }
+
+#include "lambda-ice14.C"

Jakub

[C++ PATCH] Fix ICE in bot_manip (PR c++/84449)

[Jakub Jelinek]

Hi!

build_cplus_new can return error_mark_node e.g. when calling a deleted
ctor or dtor, but bot_manip was assuming it will always return
AGGR_INIT_EXPR.  As it is generally unsafe to set subexpressions to
error_mark_node, e.g. cp_fold ICEs if binary expression has one of its
operand error_mark_node, the patch instead arranges for the whole
break_out_target_exprs to return error_mark_node in that case.

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

2018-02-19  Jakub Jelinek  

PR c++/84449
* tree.c (bot_manip): If build_cplus_new or break_out_target_exprs
returns error_mark_node, return it immediately.
(break_out_target_exprs): If cp_walk_tree with bot_manip returns
error_mark_node, return error_mark_node.

* g++.dg/cpp0x/constexpr-84449.C: New test.

--- gcc/cp/tree.c.jj2018-02-10 00:22:01.0 +0100
+++ gcc/cp/tree.c   2018-02-19 11:54:55.815478346 +0100
@@ -2896,6 +2896,8 @@ bot_manip (tree* tp, int* walk_subtrees,
{
  u = build_cplus_new (TREE_TYPE (t), TREE_OPERAND (t, 1),
   tf_warning_or_error);
+ if (u == error_mark_node)
+   return u;
  if (AGGR_INIT_ZERO_FIRST (TREE_OPERAND (t, 1)))
AGGR_INIT_ZERO_FIRST (TREE_OPERAND (u, 1)) = true;
}
@@ -2913,6 +2915,8 @@ bot_manip (tree* tp, int* walk_subtrees,
 (splay_tree_value) TREE_OPERAND (u, 0));
 
   TREE_OPERAND (u, 1) = break_out_target_exprs (TREE_OPERAND (u, 1));
+  if (TREE_OPERAND (u, 1) == error_mark_node)
+   return error_mark_node;
 
   /* Replace the old expression with the new version.  */
   *tp = u;
@@ -3025,7 +3029,8 @@ break_out_target_exprs (tree t)
 target_remap = splay_tree_new (splay_tree_compare_pointers,
   /*splay_tree_delete_key_fn=*/NULL,
   /*splay_tree_delete_value_fn=*/NULL);
-  cp_walk_tree (, bot_manip, target_remap, NULL);
+  if (cp_walk_tree (, bot_manip, target_remap, NULL) == error_mark_node)
+t = error_mark_node;
   cp_walk_tree (, bot_replace, target_remap, NULL);
 
   if (!--target_remap_count)
--- gcc/testsuite/g++.dg/cpp0x/constexpr-84449.C.jj 2018-02-19 
12:04:51.518530240 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-84449.C2018-02-19 
12:04:26.643528069 +0100
@@ -0,0 +1,14 @@
+// PR c++/84449
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+  constexpr A (int) {}
+  ~A () = delete;
+};
+
+struct B
+{
+  A a;
+  constexpr B () : a (0) {}// { dg-error "use of deleted function" }
+};

Jakub

Patch ping (Re: [PATCH PR82965/PR83991]Fix invalid profile count in vectorization peeling)

[Jakub Jelinek]

Hi!

Honza, do you think you could have a look at this P1 fix?

Thanks.

On Wed, Jan 31, 2018 at 10:03:51AM +, Bin Cheng wrote:
> Hi,
> This patch fixes invalid profile count information in vectorization peeling.
> Current implementation is a bit confusing for me since it tries to compute
> an overall probability based on scaling probability and change of estimated
> niters.  This patch does it in two steps.  Firstly it does the scaling, then
> it adjusts to new estimated niters by simply adjusting loop's latch count
> information; scaling the loop's count information by the proportion
> new_estimated_niters/old_estimate_niters.  Of course we have to adjust loop
> latch's count information back after scaling.
> 
> Bootstrap and test on x86_64 and AArch64.  gcc.dg/vect/pr79347.c is fixed
> for both PR82965 and PR83991.  Is this OK?
> 
> Thanks,
> bin
> 
> 2018-01-30  Bin Cheng  
> 
>   PR tree-optimization/82965
>   PR tree-optimization/83991
>   * cfgloopmanip.c (scale_loop_profile): Further scale loop's profile
>   information if the loop was predicted to iterate too many times.

> diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c
> index b9b76d8..1f560b8 100644
> --- a/gcc/cfgloopmanip.c
> +++ b/gcc/cfgloopmanip.c
> @@ -509,7 +509,7 @@ scale_loop_profile (struct loop *loop, 
> profile_probability p,
>   gcov_type iteration_bound)
>  {
>gcov_type iterations = expected_loop_iterations_unbounded (loop);
> -  edge e;
> +  edge e, preheader_e;
>edge_iterator ei;
>  
>if (dump_file && (dump_flags & TDF_DETAILS))
> @@ -521,77 +521,66 @@ scale_loop_profile (struct loop *loop, 
> profile_probability p,
>  (int)iteration_bound, (int)iterations);
>  }
>  
> +  /* Scale the probabilities.  */
> +  scale_loop_frequencies (loop, p);
> +
>/* See if loop is predicted to iterate too many times.  */
> -  if (iteration_bound && iterations > 0
> -  && p.apply (iterations) > iteration_bound)
> +  if (iteration_bound == 0 || iterations <= 0
> +  || p.apply (iterations) <= iteration_bound)
> +return;
> +
> +  e = single_exit (loop);
> +  preheader_e = loop_preheader_edge (loop);
> +  profile_count count_in = preheader_e->count ();
> +  if (e && preheader_e
> +  && count_in > profile_count::zero ()
> +  && loop->header->count.initialized_p ())
>  {
> -  /* Fixing loop profile for different trip count is not trivial; the 
> exit
> -  probabilities has to be updated to match and frequencies propagated 
> down
> -  to the loop body.
> -
> -  We fully update only the simple case of loop with single exit that is
> -  either from the latch or BB just before latch and leads from BB with
> -  simple conditional jump.   This is OK for use in vectorizer.  */
> -  e = single_exit (loop);
> -  if (e)
> - {
> -   edge other_e;
> -   profile_count count_delta;
> +  edge other_e;
> +  profile_count count_delta;
>  
> -  FOR_EACH_EDGE (other_e, ei, e->src->succs)
> - if (!(other_e->flags & (EDGE_ABNORMAL | EDGE_FAKE))
> - && e != other_e)
> -   break;
> +  FOR_EACH_EDGE (other_e, ei, e->src->succs)
> + if (!(other_e->flags & (EDGE_ABNORMAL | EDGE_FAKE))
> + && e != other_e)
> +   break;
>  
> -   /* Probability of exit must be 1/iterations.  */
> -   count_delta = e->count ();
> -   e->probability = profile_probability::always ()
> +  /* Probability of exit must be 1/iterations.  */
> +  count_delta = e->count ();
> +  e->probability = profile_probability::always ()
>   .apply_scale (1, iteration_bound);
> -   other_e->probability = e->probability.invert ();
> -   count_delta -= e->count ();
> -
> -   /* If latch exists, change its count, since we changed
> -  probability of exit.  Theoretically we should update everything 
> from
> -  source of exit edge to latch, but for vectorizer this is enough.  
> */
> -   if (loop->latch
> -   && loop->latch != e->src)
> - {
> -   loop->latch->count += count_delta;
> - }
> - }
> +  other_e->probability = e->probability.invert ();
>  
>/* Roughly speaking we want to reduce the loop body profile by the
>difference of loop iterations.  We however can do better if
>we look at the actual profile, if it is available.  */
> -  p = p.apply_scale (iteration_bound, iterations);
> -
> -  if (loop->header->count.initialized_p ())
> - {
> -   profile_count count_in = profile_count::zero ();
> +  p = profile_probability::always ();
>  
> -   FOR_EACH_EDGE (e, ei, loop->header->preds)
> - if (e->src != loop->latch)
> -   count_in += e->count ();
> -
> -   if (count_in > profile_count::zero () )
> - {
> -   p = count_in.probability_in (loop->header->count.apply_scale
> -   

Re: [PATCHv2][PR 81376] Remove unnecessary float casts in comparisons

[Richard Sandiford]

Yuri Gribov  writes:
> Hi all,
>
> This is a second iteration of patch which gets rid of float casts in
> comparisons when all values of casted integral type are exactly
> representable by the float type
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81376). The new version
> addresses Richard's review
> (https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00481.html).
>
> Bootstrapped and regtested on x64_64. Ok to commit?
>
> -Y
>
> From 1ea62f7bf4394142e0c473a69de8a0e9b1718a69 Mon Sep 17 00:00:00 2001
> From: Yury Gribov 
> Date: Fri, 29 Sep 2017 07:34:54 +0200
> Subject: [PATCH] Add pattern to remove useless float casts in comparison.
>
> 2018-02-17  Yury Gribov  
>
>   PR middle-end/81376
>
> gcc/
>   * real.c (format_helper::can_represent_integral_type_p): New function
>   * real.h (format_helper::can_represent_integral_type_p): Ditto.
>   * match.pd: New pattern.
>
> gcc/testsuite/
>   * c-c++-common/pr81376.c: New test.
> ---
>  gcc/match.pd | 30 ---
>  gcc/real.c   | 13 
>  gcc/real.h   |  1 +
>  gcc/testsuite/c-c++-common/pr81376.c | 39 
> 
>  4 files changed, 76 insertions(+), 7 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/pr81376.c
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 4452b58..33a5f36 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -3252,6 +3252,27 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>(if (! HONOR_NANS (@0))
>   (cmp @0 @1))
>  
> +/* Optimize various special cases of (FTYPE) N CMP (FTYPE) M.  */
> +(for cmp (tcc_comparison)
> + (simplify
> +  (cmp (float@0 @1) (float @2))
> +   (if (SCALAR_FLOAT_TYPE_P (TREE_TYPE (@0))
> + && ! DECIMAL_FLOAT_TYPE_P (TREE_TYPE (@0)))
> +(with
> + {
> +   format_helper fmt (REAL_MODE_FORMAT (TYPE_MODE (TREE_TYPE (@0;
> +   tree type1 = TREE_TYPE (@1);
> +   tree type2 = TREE_TYPE (@2);
> + }
> + (if (fmt.can_represent_integral_type_p (type1)
> +   && fmt.can_represent_integral_type_p (type2))
> +  (if (TYPE_PRECISION (type1) > TYPE_PRECISION (type2))
> +   (cmp @1 (convert @2))
> +   (if (TYPE_PRECISION (type1) < TYPE_PRECISION (type2))
> +(cmp (convert:type2 @1) @2)
> +(if (TYPE_SIGN (type1) == TYPE_SIGN (type2))
> +  (cmp @1 @2)

I think this would mishandle combinations in which the wider type
is unsigned and the narrower type is signed, like @1:short @2:unsigned int.

Thanks,
Richard

Re: [PATCH] Fix builtin_mathfn_code ICE on internal fns (PR c++/84444)

[Jeff Law]

On 02/19/2018 12:11 PM, Jakub Jelinek wrote:
> Hi!
> 
> Many years ago Jason has added call to get_callee_fndecl, which does the
> right thing for internal functions as well as handles ADDR_EXPR and also
> casts and constant function pointers with a usable DECL_INITIAL, so while
> to fix this PR I could have added || CALL_EXPR_FN (t)) == NULL_TREE before
> the || TREE_CODE (CALL_EXPR_FN (t)) != ADDR_EXPR check, IMHO it is just
> better to remove it, get_callee_fndecl will DTRT.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-02-19  Jakub Jelinek  
> 
>   PR c++/8
>   * builtins.c (builtin_mathfn_code): Don't check if CALL_EXPR_FN (t)
>   is ADDR_EXPR.
> 
>   * g++.dg/cpp1z/launder8.C: New test.
OK.
jeff

[committed] Handle OMP_SIMD in potential_constant_expression_1 (PR c++/84430)

[Jakub Jelinek]

Hi!

At least for now, unless OpenMP 5.0 will say something different,
#pragma omp simd is not usable in constexpr, but was forgotten in this spot.

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

2018-02-19  Jakub Jelinek  

PR c++/84430
* constexpr.c (potential_constant_expression_1): Handle OMP_SIMD.

* g++.dg/gomp/pr84430.C: New test.

--- gcc/cp/constexpr.c.jj   2018-02-16 23:38:05.138373372 +0100
+++ gcc/cp/constexpr.c  2018-02-19 15:28:41.907846544 +0100
@@ -5604,6 +5604,7 @@ potential_constant_expression_1 (tree t,
 case OMP_PARALLEL:
 case OMP_TASK:
 case OMP_FOR:
+case OMP_SIMD:
 case OMP_DISTRIBUTE:
 case OMP_TASKLOOP:
 case OMP_TEAMS:
--- gcc/testsuite/g++.dg/gomp/pr84430.C.jj  2018-02-19 15:34:52.397001027 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr84430.C 2018-02-19 15:36:25.037039654 +0100
@@ -0,0 +1,12 @@
+// PR c++/84430
+// { dg-do compile { target c++11 } }
+
+void
+foo ()
+{
+  auto a = [] {
+#pragma omp simd
+for (int i = 0; i < 10; ++i)
+  ;
+  };
+}

Jakub

Re: [C++ PATCH] Fix lambda error recovery (PR c++/84446)

[Paolo Carlini]

Hi,

On 19/02/2018 20:05, Jakub Jelinek wrote:

Hi!

In this case, because the corresponding variable is errorneous, we end up
with error_mark_node in LAMBDA_TYPE_EXTRA_SCOPE.  This patch just makes sure
we won't crash on it.  Not 100% sure if this is the best fix though.
IMHO something like the below - which just completed testing on 
x86_64-linux - could also make sense: among other things, we would catch 
the problem earlier - no need to check for error_mark_node as part of a 
loop - and the diagnostic would be more terse and identical to the 
non-template case. I should also add that normally when we use 
start_lambd_scope (decl) we *know* one way or the other that decl != 
error_mark_node, and that isn't the case here (in fact we check decl != 
error_mark_node in a couple of other places nearby)


Thanks!
Paolo.

//


Index: cp/parser.c
===
--- cp/parser.c (revision 257817)
+++ cp/parser.c (working copy)
@@ -19644,12 +19644,12 @@ cp_parser_init_declarator (cp_parser* parser,
 member templates.  The former involves deferring
 parsing of the initializer until end of class as with default
 arguments.  So right here we only handle the latter.  */
- if (!member_p && processing_template_decl)
+ if (!member_p && processing_template_decl && decl != error_mark_node)
start_lambda_scope (decl);
  initializer = cp_parser_initializer (parser,
   _direct_init,
   _non_constant_init);
- if (!member_p && processing_template_decl)
+ if (!member_p && processing_template_decl && decl != error_mark_node)
finish_lambda_scope ();
  if (initializer == error_mark_node)
cp_parser_skip_to_end_of_statement (parser);
Index: testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C
===
--- testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C(working copy)
@@ -0,0 +1,8 @@
+// PR c++/84446
+// { dg-do compile { target c++11 } }
+
+template void foo()
+{
+  int i,
+  i = [] { virtual }();  // { dg-error "redefinition|expected" }
+}

[C++ PATCH] Fix ICE with __builtin_launder (PR c++/84445)

[Jakub Jelinek]

Hi!

For internal functions, we use the whole u.bits of the CALL_EXPR
for the internal function number (in this case IFN_LAUNDER), so using
the lang flags on it doesn't work.  In a couple of other places
I've checked that test or set lang flags on CALL_EXPR I saw internal fns
special cased early, but admittedly haven't checked everything.

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

2018-02-19  Jakub Jelinek  

PR c++/84445
* class.c (fixed_type_or_null) : Only test
TREE_HAS_CONSTRUCTOR if instance is not an internal function call.

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

--- gcc/cp/class.c.jj   2018-02-16 19:39:08.184061984 +0100
+++ gcc/cp/class.c  2018-02-19 13:34:33.726813207 +0100
@@ -7128,7 +7128,8 @@ fixed_type_or_null (tree instance, int *
 
 case CALL_EXPR:
   /* This is a call to a constructor, hence it's never zero.  */
-  if (TREE_HAS_CONSTRUCTOR (instance))
+  if (CALL_EXPR_FN (instance)
+ && TREE_HAS_CONSTRUCTOR (instance))
{
  if (nonnull)
*nonnull = 1;
--- gcc/testsuite/g++.dg/cpp1z/launder7.C.jj2018-02-19 13:50:05.954797679 
+0100
+++ gcc/testsuite/g++.dg/cpp1z/launder7.C   2018-02-19 13:47:26.603792932 
+0100
@@ -0,0 +1,10 @@
+// PR c++/84445
+// { dg-do compile }
+
+struct A { virtual void foo (); };
+
+void
+bar (A *p)
+{
+  __builtin_launder (p)->foo ();
+}

Jakub

[C++ PATCH] Fix lambda error recovery (PR c++/84446)

[Jakub Jelinek]

Hi!

In this case, because the corresponding variable is errorneous, we end up
with error_mark_node in LAMBDA_TYPE_EXTRA_SCOPE.  This patch just makes sure
we won't crash on it.  Not 100% sure if this is the best fix though.

Bootstrapped/regtested on x86_64-linux and i686-linux.

2018-02-19  Jakub Jelinek  

PR c++/84446
* pt.c (template_class_depth): Don't crash if LAMBDA_TYPE_EXTRA_SCOPE
is error_mark_node.

* g++.dg/cpp0x/lambda/lambda-ice27.C: New test.

--- gcc/cp/pt.c.jj  2018-02-19 10:48:00.328184302 +0100
+++ gcc/cp/pt.c 2018-02-19 13:07:00.680855104 +0100
@@ -389,7 +389,11 @@ template_class_depth (tree type)
   if (DECL_P (type))
type = CP_DECL_CONTEXT (type);
   else if (LAMBDA_TYPE_P (type))
-   type = LAMBDA_TYPE_EXTRA_SCOPE (type);
+   {
+ type = LAMBDA_TYPE_EXTRA_SCOPE (type);
+ if (type == error_mark_node)
+   break;
+   }
   else
type = CP_TYPE_CONTEXT (type);
 }
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice27.C.jj 2018-02-19 
13:11:15.292869216 +0100
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice27.C2018-02-19 
13:10:45.186870424 +0100
@@ -0,0 +1,12 @@
+// PR c++/84446
+// { dg-do compile { target c++11 } }
+
+template 
+void
+foo ()
+{
+  int i;
+  auto i = [] { virtual; }();  // { dg-error "conflicting declaration" }
+   // { dg-error "templates may not be 'virtual'" 
"" { target *-*-* } .-1 }
+   // { dg-error "declaration does not declare 
anything" "" { target *-*-* } .-2 }
+}

Jakub

[committed] Fix ICE on non-x86 in expand_simd_clone (PR tree-optimization/84452)

[Jakub Jelinek]

Hi!

The simd clones IPA pass is gated on
targetm.simd_clone.compute_vecsize_and_simdlen != NULL
so when we are calling expand_simd_clones later, we shouldn't call it
if it is NULL.

Bootstrapped/regtested on x86_64-linux and i686-linux, tested with
powerpc64le-linux cross on the testcase, committed to trunk.

2018-02-19  Jakub Jelinek  

PR tree-optimization/84452
* tree-vect-patterns.c (vect_recog_pow_pattern): Don't call
expand_simd_clones if targetm.simd_clone.compute_vecsize_and_simdlen
is NULL.

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

--- gcc/tree-vect-patterns.c.jj 2018-02-13 09:33:31.118560170 +0100
+++ gcc/tree-vect-patterns.c2018-02-19 11:15:04.181270004 +0100
@@ -1113,7 +1113,8 @@ vect_recog_pow_pattern (vec *s
  cgraph_node *node = cgraph_node::get_create (exp_decl);
  if (node->simd_clones == NULL)
{
- if (node->definition)
+ if (targetm.simd_clone.compute_vecsize_and_simdlen == NULL
+ || node->definition)
return NULL;
  expand_simd_clones (node);
  if (node->simd_clones == NULL)
--- gcc/testsuite/gcc.dg/pr84452.c.jj   2018-02-19 11:17:37.045283314 +0100
+++ gcc/testsuite/gcc.dg/pr84452.c  2018-02-19 11:18:45.769289300 +0100
@@ -0,0 +1,14 @@
+/* PR tree-optimization/84452 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast" } */
+
+double pow (double, double) __attribute__((simd));
+double exp (double) __attribute__((simd));
+extern double a[1024], b[1024];
+
+void
+foo (void)
+{
+  for (int i = 0; i < 1024; ++i)
+a[i] = pow (2.0, b[i]);
+}

Jakub

[committed] Fix overload15.C testcase (PR c++/79064)

[Jakub Jelinek]

Hi!

The testcase that has been committed for this PR doesn't work on ilp32
targets, because both 0u - 1 and 0u - 1l are there 0xu.
The testcase originally filed had proper 0u - 1ll in the second case, which
works on all targets where long long is wider than int (not aware of any
target we support where that wouldn't be true right now).

Tested on x86_64-linux, -m32/-m64, committed to trunk as obvious.

2018-02-19  Jakub Jelinek  

PR c++/79064
* g++.dg/template/overload15.C (f): Use 0u - 1ll instead of 0u - 1l.

--- gcc/testsuite/g++.dg/template/overload15.C.jj   2018-02-16 
23:37:28.682364104 +0100
+++ gcc/testsuite/g++.dg/template/overload15.C  2018-02-19 19:45:48.771094113 
+0100
@@ -5,7 +5,7 @@ template 
 void f (char (*)[0u - 1 > N ? 1 : 7]);
 
 template 
-void f (char (*)[0u - 1l > N ? 1 : 7]);
+void f (char (*)[0u - 1ll > N ? 1 : 7]);
 
 void f ()
 {

Jakub

Re: Patch ping

[Jeff Law]

On 02/14/2018 07:22 AM, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping these patches:
> 
> PR84146 fix -fcompare-debug issues with -mcet -fcf-protection=full
>   http://gcc.gnu.org/ml/gcc-patches/2018-02/msg00390.html
OK.  And FWIW, I like this much more than having it be an insn note.


jeff

Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

[Andre Vehreschild]

Hi all,

no objections received therefore committed as r257813. Thanks for fast review
Jerry.

- Andre

On Sun, 18 Feb 2018 18:33:07 +0100
Andre Vehreschild  wrote:

> Well, after discussing on IRC whether RM should be bothered, I was asked to
> simplify release managers lives and propose, that if no one objects within one
> day, I will merge the patch. So any objections?
> 
> - Andre
> 
> On Sun, 18 Feb 2018 18:07:28 +0100
> Andre Vehreschild  wrote:
> 
> > Dear release managers,
> > 
> > this patch (for reference
> > https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regression in
> > the coarray api by extending three relatively new functions with one or two
> > arguments, respectively. The patch has been approved by gfortran devs.
> > Asking your approval to merge it: Ok to merge to trunk?
> > 
> > Regards,
> > Andre
> > 
> > On Sun, 18 Feb 2018 08:53:41 -0800
> > Jerry DeLisle  wrote:
> >   
> > > On 02/18/2018 07:39 AM, Andre Vehreschild wrote:
> > > > Hi all,
> > > > 
> > > > attached patch fixes an issue with the coarray API. When a component of
> > > > a derived type coarray was referenced using a caf_*_by_ref () function
> > > > and that component was not an array with a descriptor, then the type of
> > > > the component was not known. Which additionally meant, that type
> > > > conversion was not applied as required. This patch fixes that issue by
> > > > adding type specifiers to the three caf_*_by_ref-calls and implements
> > > > the functionality for libcaf_single. This is harmless because other
> > > > coarray libraries that do not expect this argument just ignore it.
> > > > Additionally does this patch also provide the first working version of
> > > > caf_sendget_by_ref in libcaf_single, which previously only lead to a
> > > > stack corruption and was not usable since the array descriptor rework
> > > > (nice job, btw).
> > > > 
> > > > I would like to have this patch in trunk knowing that I am somewhat
> > > > late, but it would be quite necessary, because as it is now, the
> > > > coarray feature for derived types is hardly usable. Furthermore do some
> > > > people name this a regression, because the caf_*_by_ref are also used
> > > > when the lhs of a caf_get_by_ref() is allocatable which now does not
> > > > work as expected anymore but before gcc-6 using caf_get() (w/o
> > > > reallocation) did.
> > > > 
> > > > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?
> > > > 
> > > > - Andre
> > > >   
> > > 
> > > This is OK from the Fortranners perspective. Should touch base with 
> > > release manager.  It looks harmless though it changes coarray API, which 
> > > is hidden behind -fcoarray=
> > > 
> > > Regards,
> > > 
> > > Jerry
> > 
> >   
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 257812)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,13 @@
+2018-02-19  Andre Vehreschild  
+
+	* gfortran.texi: Document additional src/dst_type.  Fix some typos.
+	* trans-decl.c (gfc_build_builtin_function_decls): Declare the new
+	argument of _caf_*_by_ref () with * e { get, send, sendget }.
+	* trans-intrinsic.c (gfc_conv_intrinsic_caf_get): Add the type of the
+	data referenced when generating a call to caf_get_by_ref ().
+	(conv_caf_send): Same but for caf_send_by_ref () and
+	caf_sendget_by_ref ().
+
 2018-02-18  Jerry DeLisle  
 
 	PR fortran/84389
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi	(Revision 257812)
+++ gcc/fortran/gfortran.texi	(Arbeitskopie)
@@ -4750,7 +4750,7 @@
 @item @emph{Syntax}:
 @code{void _gfortran_caf_send_by_ref (caf_token_t token, int image_index,
 gfc_descriptor_t *src, caf_reference_t *refs, int dst_kind, int src_kind,
-bool may_require_tmp, bool dst_reallocatable, int *stat)}
+bool may_require_tmp, bool dst_reallocatable, int *stat, int dst_type)}
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
@@ -4774,6 +4774,9 @@
 @item @var{stat} @tab intent(out) When non-@code{NULL} give the result of the
 operation, i.e., zero on success and non-zero on error.  When @code{NULL} and
 an error occurs, then an error message is printed and the program is terminated.
+@item @var{dst_type} @tab intent(in)  Give the type of the destination.  When
+the destination is not an array, than the precise type, e.g. of a component in
+a derived type, is not known, but provided here.
 @end multitable
 
 @item @emph{NOTES}
@@ -4808,7 +4811,7 @@
 @item @emph{Syntax}:
 @code{void _gfortran_caf_get_by_ref (caf_token_t token, int image_index,
 caf_reference_t *refs, gfc_descriptor_t *dst, int dst_kind, int src_kind,
-bool may_require_tmp, bool dst_reallocatable, int *stat)}
+bool may_require_tmp, bool 

Re: [PATCH, rs6000] Require Power 8 for vec_neg builtin.

[Segher Boessenkool]

Hi Carl,

On Fri, Feb 16, 2018 at 11:53:53AM -0800, Carl Love wrote:
> The following patch fixes a GCC internal compiler error on the test
> files:
> 
>   gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p8.c
>   gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p9.c
> 
> when compiled with -mcpu=power7.
> 
> See bugzilla https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422.
> 
> The issue is the macro expansions enable the builtin support on pre
> Power 8 hardware.  The vec_neg() builtin is not supported for Power 7.

> 2018-02-16  Carl Love  
>   * gcc.target/powerpc/fold-vec-neg-ing.p7.c: Remove test file.

Typo in the file name here.

> +/* Altivec NEG functions.  */
> +BU_P8V_AV_1 (NEG_V2DI,  "neg_v2di",  CONST,  negv2di2)
> +BU_P8V_AV_1 (NEG_V4SI,  "neg_v4si",  CONST,  negv4si2)
> +BU_P8V_AV_1 (NEG_V8HI,  "neg_v8hi",  CONST,  negv8hi2)
> +BU_P8V_AV_1 (NEG_V16QI, "neg_v16qi", CONST,  negv16qi2)
> +BU_P8V_AV_1 (NEG_V4SF,  "neg_v4sf",  CONST,  negv4sf2)
> +BU_P8V_AV_1 (NEG_V2DF,  "neg_v2df",  CONST,  negv2df2)

The comment is misleading (these are only for p8 and later, not for all
AltiVec).

Okay for trunk with that fixed.  Does this need backporting to 7?

Thanks!


Segher

Re: [PATCH] Put pass_sancov_O0 before pass_lower_switch with -O0 (PR sanitizer/82183).

[Jeff Law]

On 02/19/2018 02:11 AM, Martin Liška wrote:
> Hi.
> 
> Sorry that it took me quite some time. The patch puts sancov pass before 
> switch
> lowering on -O0.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> The test-case now works on aarch64.
> 
> Ready to be installed?
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-02-16  Martin Liska  
> 
>   PR sanitizer/82183
>   * passes.def: Put pass_sancov_O0 before pass_lower_switch with -O0.
OK.
jeff

Re: [PATCH] Fix ubsan in gimple-fold.c (PR tree-optimization/82491).

[Jeff Law]

On 02/19/2018 05:38 AM, Martin Liška wrote:
> Hi.
> 
> The patch was suggested by Richard Biener and then Richard Sandiford helped 
> me to
> rewrite it using poly-int. It prevents ubsan in gimple-fold.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> And it does not trigger ubsan in the test-case in gimple-fold.c.
> 
> Ready to be installed?
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-02-19  Martin Liska  
>   Richard Sandiford  
> 
>   PR tree-optimization/82491
>   * gimple-fold.c (get_base_constructor): Make earlier bail out
>   to prevent ubsan.
OK.
jeff

Re: [PATCH] Do not use bit and for conjunction of predicates (PR c/81272).

[Jeff Law]

On 02/19/2018 06:43 AM, Martin Liška wrote:
> Hi.
> 
> This changes code to be consistent:
> 
>   if (!decNumberIsNegative(lhs) & decNumberIsNegative(rhs)) {
> ...
>else if (decNumberIsQNaN(lhs) && decNumberIsSNaN(rhs)) result=+1;
> 
> That's fixed in the patch.
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Ready to be installed?
> Martin
> 
> 
> libdecnumber/ChangeLog:
> 
> 2018-02-19  Martin Liska  
> 
>   PR c/81272
>   * decNumber.c (decCompareOp): Do not use bit and
>   for conjunction of predicates.
OK

jeff

Re: [PATCH][x86] Fix PR84460

[Jeff Law]

On 02/19/2018 08:20 AM, Peryt, Sebastian wrote:
> Hi,
> 
> This is fix for PR84460.
> 
> gcc/testsuite
>PR target/84460
>* gcc.target/i386/pr57193.c (dg-options): Add -mtune=generic.
> 
> Is it ok for trunk?
OK. I  went ahead and installed.

jeff

[PATCH] c++: Fix spurious fallthrough warning on break

[Siddhesh Poyarekar]

The C++ frontend generates a break that results in the fallthrough
warning misfiring in nested switch blocks where cases in the inner
switch block return, rendering the break pointless.  The fallthrough
detection in finish_break_stmt does not work either because the
condition is encoded as an IF_STMT and not a COND_EXPR.

Fix this by adding a condition for IF_STMT in the
langhooks.block_may_fallthru for C++.  Fix tested on x86_64.  Full
testsuite run is in progress.

Siddhesh

gcc/cp
* cp-objcp-common.c (cxx_block_may_fallthru): Add case for
IF_STMT.

gcc/testsuite
* g++.dg/nested-switch.C: New test case.
---
 gcc/cp/cp-objcp-common.c |  5 +
 gcc/testsuite/g++.dg/nested-switch.C | 30 ++
 2 files changed, 35 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/nested-switch.C

diff --git a/gcc/cp/cp-objcp-common.c b/gcc/cp/cp-objcp-common.c
index a45dda4d012..5289a89e486 100644
--- a/gcc/cp/cp-objcp-common.c
+++ b/gcc/cp/cp-objcp-common.c
@@ -349,6 +349,11 @@ cxx_block_may_fallthru (const_tree stmt)
 case THROW_EXPR:
   return false;
 
+case IF_STMT:
+  if (block_may_fallthru (THEN_CLAUSE (stmt)))
+   return true;
+  return block_may_fallthru (ELSE_CLAUSE (stmt));
+
 case SWITCH_STMT:
   return (!SWITCH_STMT_ALL_CASES_P (stmt)
  || !SWITCH_STMT_NO_BREAK_P (stmt)
diff --git a/gcc/testsuite/g++.dg/nested-switch.C 
b/gcc/testsuite/g++.dg/nested-switch.C
new file mode 100644
index 000..46412dd293f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/nested-switch.C
@@ -0,0 +1,30 @@
+// Verify that there are no spurious warnings in nested switch statements due
+// to the unnecessary break in the inner switch block.
+// { dg-do compile }
+// { dg-options "-Werror=implicit-fallthrough" } */
+
+int
+foo (int c1, int c2, int c3)
+{
+  switch (c2)
+{
+case 0:   
+  switch (c3) {
+   case 0:
+ if (c1)
+   return 1;
+ else
+   return 2;
+ break;
+
+   default:
+ return 3;
+  }
+
+case 1: 
+  return 4;
+default:
+  return 5;
+  break;
+}
+}
-- 
2.14.3

Re: [PATCH, rs6000] PR84371 Update builtins-3*.c tests for power9 codegen

[Peter Bergner]

On 2/15/18 3:56 PM, Will Schmidt wrote:
> -/* { dg-options "-mcpu=power8" } */
> +/* { dg-options "-maltivec -mcpu=power8" } */

Why did you add -maltivec?  That flag is enabled implicitly by -mcpu=power8
which we're already using?

Peter

Re: [Patch][aarch64][PR target/83335] Fix regression, ICE on gcc.target/aarch64/asm-2.c

[Richard Earnshaw (lists)]

On 17/02/18 00:04, Steve Ellcey wrote:
> On Thu, 2018-02-15 at 14:01 +, Richard Earnshaw (lists) wrote:
>>  
>> Wouldn't it be better to call output_operand_lossage() with a suitable
>> diagnostic message?  If the operand isn't in Pmode assembly will
>> (should) fail anyway.
>>
>> R.
> 
> How about this patch?  In addtion to the code change I updated asm-2.c
> with the error message that you getin ILP32 mode and I added asm-4.c
> which does not give an error message in either LP64 or ILP32 mode.
> 
> Steve Ellcey
> sell...@cavium.com
> 
> 2018-02-16  Steve Ellcey  
> 
>   PR target/83335
>   * config/aarch64/aarch64.c (aarch64_print_address_internal):
>   Change gcc_assert call to output_operand_lossage.

I think this is OK.  However, I note that __builtin_extend_pointer is
undocumented (it appears to be intended only for use in the exception
unwinding code).  Should it now be made an officially supported builtin?
 It appears to be the only semi-portable way of getting a Pmode address
out of a language level pointer and thus important for use on targets
where the two differ in size.

R.

> 
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 7c9c6e5..34b75f8 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -7044,7 +7044,8 @@ aarch64_print_address_internal (FILE *f, machine_mode 
> mode, rtx x,
>    unsigned int size;
>  
>    /* Check all addresses are Pmode - including ILP32.  */
> -  gcc_assert (GET_MODE (x) == Pmode);
> +  if (GET_MODE (x) != Pmode)
> +output_operand_lossage ("invalid address mode");
>  
>    if (aarch64_classify_address (, x, mode, true, type))
>  switch (addr.type)
> 
> 
> 2018-02-16  Steve Ellcey  
> 
>   PR target/83335
>   * gcc/testsuite/gcc.target/aarch64/asm-2.c: Add dg-error for
>   ILP32 mode.
>   * gcc/testsuite/gcc.target/aarch64/asm-4.c: New test.
> 
> diff --git a/gcc/testsuite/gcc.target/aarch64/asm-2.c 
> b/gcc/testsuite/gcc.target/aarch64/asm-2.c
> index 3f978f5..65b3a84 100644
> --- a/gcc/testsuite/gcc.target/aarch64/asm-2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/asm-2.c
> @@ -6,5 +6,5 @@ int x;
>  void
>  f (void)
>  {
> -  asm volatile ("%a0" :: "X" ());
> +  asm volatile ("%a0" :: "X" ()); /* { dg-error "invalid address mode" "" 
> { target ilp32 } } */
>  }
> diff --git a/gcc/testsuite/gcc.target/aarch64/asm-4.c 
> b/gcc/testsuite/gcc.target/aarch64/asm-4.c
> index e69de29..abe2af5 100644
> --- a/gcc/testsuite/gcc.target/aarch64/asm-4.c
> +++ b/gcc/testsuite/gcc.target/aarch64/asm-4.c
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O0" } */
> +
> +int x;
> +
> +void
> +f (void)
> +{
> +  asm volatile ("%a0" :: "X" (__builtin_extend_pointer ()));
> +}
> 

[PATCH][x86] Fix PR84460

[Peryt, Sebastian]

Hi,

This is fix for PR84460.

gcc/testsuite
   PR target/84460
   * gcc.target/i386/pr57193.c (dg-options): Add -mtune=generic.

Is it ok for trunk?

Thanks,
Sebastian




PR84460.patch
Description: PR84460.patch

Re: [PATCH] Fix PR84399

[Szabolcs Nagy]

On 16/02/18 08:15, Richard Biener wrote:


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

Richard.

2018-02-16  Richard Biener  

PR tree-optimization/84399
* graphite-scop-detection.c (scop_detection::stmt_simple_for_scop_p):
For operands we can analyze at their definition make sure we can
analyze them at each use as well.

* gcc.dg/graphite/pr84399.c: New testcase.



since this commit (r257723) i see

FAIL: libgomp.graphite/force-parallel-8.c scan-tree-dump-times graphite "5 loops 
carried no dependency" 1 (found 0 times)

on aarch64-none-linux-gnu and arm-none-linux-gnueabihf

[PATCH] Do not use bit and for conjunction of predicates (PR c/81272).

[Martin Liška]

Hi.

This changes code to be consistent:

  if (!decNumberIsNegative(lhs) & decNumberIsNegative(rhs)) {
...
 else if (decNumberIsQNaN(lhs) && decNumberIsSNaN(rhs)) result=+1;

That's fixed in the patch.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin


libdecnumber/ChangeLog:

2018-02-19  Martin Liska  

PR c/81272
* decNumber.c (decCompareOp): Do not use bit and
for conjunction of predicates.
---
 libdecnumber/decNumber.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/libdecnumber/decNumber.c b/libdecnumber/decNumber.c
index ebfb6c5dd96..e4194211fdc 100644
--- a/libdecnumber/decNumber.c
+++ b/libdecnumber/decNumber.c
@@ -6029,11 +6029,11 @@ decNumber * decCompareOp(decNumber *res, const decNumber *lhs,
 
 /* If total ordering then handle differing signs 'up front' */
 if (op==COMPTOTAL) {		/* total ordering */
-  if (decNumberIsNegative(lhs) & !decNumberIsNegative(rhs)) {
+  if (decNumberIsNegative(lhs) && !decNumberIsNegative(rhs)) {
 	result=-1;
 	break;
 	}
-  if (!decNumberIsNegative(lhs) & decNumberIsNegative(rhs)) {
+  if (!decNumberIsNegative(lhs) && decNumberIsNegative(rhs)) {
 	result=+1;
 	break;
 	}

Re: [Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

[Janne Blomqvist]

On Mon, Feb 19, 2018 at 2:39 PM, Paul Richard Thomas
 wrote:
> Hi Janne,
>
> Please find attached a revised version of the patch that fixes all the
> issues that I know of.
>
> Regtests on FC27/x86_64 - OK for trunk?

1. The resolve.c part of the patch seems to have incorrect indentation?

2. Instead of gfc_index_zero_node would it be better to use
build_zero_cst (gfc_charlen_type_node)? Or is the same code used also
for something related to arrays? If so, probably safer to leave as is,
as the character length code should nowadays use fold_convert
relatively judiciously where needed.

3. For associate_36.f90, I believe that testcase was due to Steve
Kargl and not me.

4. I believe you can credit yourself with fixing PR 83975 as well in
the Changelog.

With these minor quibbles out of the way, Ok for trunk.

> I have also attached a test of all the failing cases in PR83975.
> However, I believe that they are all included in other associate*.f*.

Ok, fair enough. No need to test the same thing multiple times!

>
> Cheers
>
> Paul
>
> 2018-02-19  Paul Thomas  
>
> PR fortran/83344
> * resolve.c (resolve_assoc_var): Rearrange the logic for the
> determination of the character length of associate names. If
> the associate name is missing a length expression or the length
> expression is not a constant and the target is not a variable,
> make the associate name allocatable and deferred length.
> * trans-decl.c (gfc_get_symbol_decl): Null the character length
> backend_decl for deferred length associate names that are not
> variables. Set 'length' to gfc_index_zero_node for character
> associate names, whose character length is a PARM_DECL.
>
> 2018-02-19  Paul Thomas  
>
> PR fortran/83344
> * gfortran.dg/associate_22.f90: Enable commented out test.
> * gfortran.dg/associate_36.f90: New test.
>
>
> On 18 February 2018 at 21:01, Paul Richard Thomas
>  wrote:
>> Hi Janne and Thomas,
>>
>> 1) The patch is attached now - sorry!
>>
>> 2) The commented out part of associate_22.f90 is not yet fixed. I am
>> working on it.
>>
>> 3) I will take a look at PR83975 tomorrow night.
>>
>> Paul
>>
>>
>> On 18 February 2018 at 16:08, Janne Blomqvist  
>> wrote:
>>> On Sun, Feb 18, 2018 at 5:48 PM, Paul Richard Thomas
>>>  wrote:
 Bootstraps and regtests on FC27/x86_64 - OK for trunk?
>>>
>>> Hi,
>>>
>>> thanks for looking into this!
>>>
>>> 1. The patch itself is missing...
>>>
>>> 2. Could you uncomment the commented out part of associate_22.f90 and
>>> check that the tree-original dump is sensible.
>>>
>>> 3. Same for the testcases posted to PR 83975. I suspect (err, hope)
>>> that this patch would fix those as well. If so, please add that PR to
>>> the ChangeLog entries as well.
>>>

 Paul

 2018-02-18  Paul Thomas  

 PR fortran/83344
 * resolve.c (resolve_assoc_var): Character associate names that
 have no length expression that have variable targets and are
 not deferred length have assumed length.
 * trans-decl.c (gfc_get_symbol_decl): Set 'length' to
 gfc_index_zero_node for character associate names, whose string
 length is a PARM_DECL.

 2018-02-18  Paul Thomas  

 PR fortran/83344
 * gfortran.dg/associate_36.f90: New test.
>>>
>>>
>>>
>>> --
>>> Janne Blomqvist
>>
>>
>>
>> --
>> "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



-- 
Janne Blomqvist

Re: [PING][PATCH v3] Disable reg offset in quad-word store for Falkor

[Wilco Dijkstra]

Siddhesh Poyarekar wrote:
> On Thursday 15 February 2018 07:50 PM, Wilco Dijkstra wrote:
>> So it seems to me using existing cost mechanisms is always preferable, even 
>> if you
>> currently can't differentiate between loads and stores.
>
> Luis is working on address cost adjustments among other things, so I
> guess the path of least resistance for gcc8 is to have those adjustments
> go in and then figure out how much improvement this patch (or separating
> loads and stores) would get on top of that.  Would that be acceptable?

Yes adjusting costs is not an issue as that's clearly something we need to 
improve
anyway. Having numbers for both approaches would be useful, however I think 
it's still
best to go with the cost approach for GCC8 as that should get most of the gain.

Wilco

Re: [PATCHv2][PR 81376] Remove unnecessary float casts in comparisons

[Yuri Gribov]

On Sun, Feb 18, 2018 at 8:46 PM, Jeff Law  wrote:
> On 02/18/2018 11:52 AM, Yuri Gribov wrote:
>> Hi all,
>>
>> This is a second iteration of patch which gets rid of float casts in
>> comparisons when all values of casted integral type are exactly
>> representable by the float type
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81376). The new version
>> addresses Richard's review
>> (https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00481.html).
>>
>> Bootstrapped and regtested on x64_64. Ok to commit?
> This should defer into the next stage1 IMHO.

Right, just want to get some feedback meanwhile.

-Y

Re: [Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

[Paul Richard Thomas]

Hi Janne,

Please find attached a revised version of the patch that fixes all the
issues that I know of.

Regtests on FC27/x86_64 - OK for trunk?

I have also attached a test of all the failing cases in PR83975.
However, I believe that they are all included in other associate*.f*.

Cheers

Paul

2018-02-19  Paul Thomas  

PR fortran/83344
* resolve.c (resolve_assoc_var): Rearrange the logic for the
determination of the character length of associate names. If
the associate name is missing a length expression or the length
expression is not a constant and the target is not a variable,
make the associate name allocatable and deferred length.
* trans-decl.c (gfc_get_symbol_decl): Null the character length
backend_decl for deferred length associate names that are not
variables. Set 'length' to gfc_index_zero_node for character
associate names, whose character length is a PARM_DECL.

2018-02-19  Paul Thomas  

PR fortran/83344
* gfortran.dg/associate_22.f90: Enable commented out test.
* gfortran.dg/associate_36.f90: New test.


On 18 February 2018 at 21:01, Paul Richard Thomas
 wrote:
> Hi Janne and Thomas,
>
> 1) The patch is attached now - sorry!
>
> 2) The commented out part of associate_22.f90 is not yet fixed. I am
> working on it.
>
> 3) I will take a look at PR83975 tomorrow night.
>
> Paul
>
>
> On 18 February 2018 at 16:08, Janne Blomqvist  
> wrote:
>> On Sun, Feb 18, 2018 at 5:48 PM, Paul Richard Thomas
>>  wrote:
>>> Bootstraps and regtests on FC27/x86_64 - OK for trunk?
>>
>> Hi,
>>
>> thanks for looking into this!
>>
>> 1. The patch itself is missing...
>>
>> 2. Could you uncomment the commented out part of associate_22.f90 and
>> check that the tree-original dump is sensible.
>>
>> 3. Same for the testcases posted to PR 83975. I suspect (err, hope)
>> that this patch would fix those as well. If so, please add that PR to
>> the ChangeLog entries as well.
>>
>>>
>>> Paul
>>>
>>> 2018-02-18  Paul Thomas  
>>>
>>> PR fortran/83344
>>> * resolve.c (resolve_assoc_var): Character associate names that
>>> have no length expression that have variable targets and are
>>> not deferred length have assumed length.
>>> * trans-decl.c (gfc_get_symbol_decl): Set 'length' to
>>> gfc_index_zero_node for character associate names, whose string
>>> length is a PARM_DECL.
>>>
>>> 2018-02-18  Paul Thomas  
>>>
>>> PR fortran/83344
>>> * gfortran.dg/associate_36.f90: New test.
>>
>>
>>
>> --
>> Janne Blomqvist
>
>
>
> --
> "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
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 257787)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_assoc_var (gfc_symbol* sym, bool
*** 8635,8664 
if (sym->ts.type == BT_CHARACTER && !sym->attr.select_type_temporary)
  {
if (!sym->ts.u.cl)
!   {
! if (target->expr_type != EXPR_CONSTANT
! && !target->ts.u.cl->length)
!   {
! sym->ts.u.cl = gfc_get_charlen();
! sym->ts.deferred = 1;
  
! /* This is reset in trans-stmt.c after the assignment
!of the target expression to the associate name.  */
! sym->attr.allocatable = 1;
!   }
! else
!   sym->ts.u.cl = target->ts.u.cl;
}
! 
!   if (!sym->ts.u.cl->length && !sym->ts.deferred)
{
! if (target->expr_type == EXPR_CONSTANT)
!   sym->ts.u.cl->length =
! gfc_get_int_expr (gfc_charlen_int_kind, NULL,
!   target->value.character.length);
! else
!   gfc_error ("Not Implemented: Associate target with type character"
!  " and non-constant length at %L", >where);
}
  }
  
--- 8635,8660 
if (sym->ts.type == BT_CHARACTER && !sym->attr.select_type_temporary)
  {
if (!sym->ts.u.cl)
!   sym->ts.u.cl = target->ts.u.cl;
  
!   if (!sym->ts.u.cl->length
! && !sym->ts.deferred
! && target->expr_type == EXPR_CONSTANT)
!   {
! sym->ts.u.cl->length =
!   gfc_get_int_expr (gfc_charlen_int_kind, NULL,
! target->value.character.length);
}
!   else if ((!sym->ts.u.cl->length
!   || sym->ts.u.cl->length->expr_type != EXPR_CONSTANT)
!   && target->expr_type != EXPR_VARIABLE)
{
! sym->ts.u.cl = gfc_get_charlen();
! sym->ts.deferred = 1;
! 
! /* This is reset in trans-stmt.c after the assignment
!of the 

[PATCH] Fix ubsan in gimple-fold.c (PR tree-optimization/82491).

[Martin Liška]

Hi.

The patch was suggested by Richard Biener and then Richard Sandiford helped me 
to
rewrite it using poly-int. It prevents ubsan in gimple-fold.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
And it does not trigger ubsan in the test-case in gimple-fold.c.

Ready to be installed?
Martin

gcc/ChangeLog:

2018-02-19  Martin Liska  
Richard Sandiford  

PR tree-optimization/82491
* gimple-fold.c (get_base_constructor): Make earlier bail out
to prevent ubsan.
---
 gcc/gimple-fold.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)


diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index e556f050e43..c9dad6f42d1 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -6442,13 +6442,9 @@ get_base_constructor (tree base, poly_int64_pod *bit_offset,
 
   if (TREE_CODE (base) == MEM_REF)
 {
-  if (!integer_zerop (TREE_OPERAND (base, 1)))
-	{
-	  if (!tree_fits_shwi_p (TREE_OPERAND (base, 1)))
-	return NULL_TREE;
-	  *bit_offset += (mem_ref_offset (base).force_shwi ()
-			  * BITS_PER_UNIT);
-	}
+  poly_offset_int boff = *bit_offset + mem_ref_offset (base) * BITS_PER_UNIT;
+  if (!boff.to_shwi (bit_offset))
+	return NULL_TREE;
 
   if (valueize
 	  && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME)

Re: [patch, fortran] Remove workaround introduced because of PR80945

[Paul Richard Thomas]

Hi Thomas,

I have tested this with the new version of the patch for PR83344 - it
is OK for trunk.

Thanks

Paul


On 18 February 2018 at 16:17, Thomas Koenig  wrote:
> Hello world,
>
> after Paul's fix for PR80945, the code in frontend-passes.c meant
> to circumvent this bug is no longer needed. The attached patch
> removes it, adding a test case which shows that the optimization
> is working.
>
> After this, I think we can finally lay PR 35339 to rest.
>
> Regression-tested. OK for trunk?
>
> Regards
>
> Thomas
>
> 2018-02-18  Thomas Koenig  
>
> PR fortran/35339
> * frontend-passes.c (traverse_io_block): Remove workaround for
> PR 80945.
>
> 2018-02-18  Thomas Koenig  
>
> PR fortran/35339
> * gfortran.dg/implied_do_io_4.f90: New test.



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

Re: [PATCH][AArch64][1/3] PR target/84164: Simplify subreg + redundant AND-immediate

[Kyrill Tkachov]

Ping.

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00649.html

CC'ing Eric and Jeff as the patch contains a simplify-rtx.c component that I'll 
need midend approval on.

Thanks everyone for your comments so far.
Kyrill

On 12/02/18 15:18, Kyrill Tkachov wrote:

Hi Richard,

On 08/02/18 20:29, Richard Sandiford wrote:

Thanks for doing this.

Kyrill  Tkachov  writes:

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 
2e7aa5c12952ab1a9b49b5adaf23710327e577d3..af06d7502cebac03cefc689b2646874b8397e767
 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -6474,6 +6474,18 @@ simplify_subreg (machine_mode outermode, rtx op,
return NULL_RTX;
  }
  +  /* Simplify (subreg:QI (and:SI (reg:SI) (const_int 0x)) 0)
+ into (subreg:QI (reg:SI) 0).  */
+  scalar_int_mode int_outermode, int_innermode;
+  if (!paradoxical_subreg_p (outermode, innermode)
+  && is_a  (outermode, _outermode)
+  && is_a  (innermode, _innermode)
+  && GET_CODE (op) == AND && CONST_INT_P (XEXP (op, 1))
+  && known_eq (subreg_lowpart_offset (outermode, innermode), byte)
+  && (~INTVAL (XEXP (op, 1)) & GET_MODE_MASK (int_outermode)) == 0
+  && validate_subreg (outermode, innermode, XEXP (op, 0), byte))
+return gen_rtx_SUBREG (outermode, XEXP (op, 0), byte);
+
/* A SUBREG resulting from a zero extension may fold to zero if
   it extracts higher bits that the ZERO_EXTEND's source bits.  */
if (GET_CODE (op) == ZERO_EXTEND && SCALAR_INT_MODE_P (innermode))

I think it'd be better to do this in simplify_truncation (shared
by the subreg code and the TRUNCATE code).  The return would then
be simplify_gen_unary (TRUNCATE, ...), which will become a subreg
if TRULY_NOOP_TRUNCATION.


Thanks, that does look cleaner.
Bootstrapped and tested on arm-none-linux-gnueabihf, aarch64-none-linux-gnu and 
x86_64-unknown-linux-gnu.
The other two patches are still needed to address the fallout.

Is this ok?

Thanks,
Kyrill

2018-02-12  Kyrylo Tkachov  

PR target/84164
* simplify-rtx.c (simplify_truncation): Simplify truncation of masking
operation.
* config/aarch64/aarch64.md (*aarch64_reg_3_neg_mask2):
Use simplify_gen_unary creating a SUBREG.
(*aarch64_reg_3_minus_mask): Likewise.
(*aarch64__reg_di3_mask2): Use const_int_operand predicate
for operand 3.

2018-02-12  Kyrylo Tkachov  

PR target/84164
* gcc.c-torture/compile/pr84164.c: New test.

[Patch] Fix lto-wrapper link flags

[Christophe Lyon]

Hi,

I think there's a typo in gcc/Makefile.in, where lto-wrapper is linked
using $(ALL_COMPILERFLAGS) while it should be $(ALL_LINKERFLAGS).

I noticed this while playing with linker flags, and not seeing them
when linking lto-wrapper.
It seems obvious, but maybe I'm missing something?

OK for trunk?

Thanks,

Christophe
gcc/ChangeLog:

2018-02-19  Christophe Lyon  

* Makefile.in (lto-wrapper): Use ALL_LINKERFLAGS.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6c37e46..c91499d 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2151,7 +2151,7 @@ CFLAGS-collect2.o += 
-DTARGET_MACHINE=\"$(target_noncanonical)\" \
 
 LTO_WRAPPER_OBJS = lto-wrapper.o collect-utils.o ggc-none.o
 lto-wrapper$(exeext): $(LTO_WRAPPER_OBJS) libcommon-target.a $(LIBDEPS)
-   +$(LINKER) $(ALL_COMPILERFLAGS) $(LDFLAGS) -o T$@ \
+   +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o T$@ \
   $(LTO_WRAPPER_OBJS) libcommon-target.a $(LIBS)
mv -f T$@ $@
 

[PATCH][OBVIOUS] Fix documentation typos (PR other/80589).

[Martin Liška]

Hi.

This fixes two typos in documentation and description of a param.
Installed as obvious.

Thanks,
Martin

gcc/ChangeLog:

2018-02-19  Martin Liska  

* doc/invoke.texi: Fix typo.
* params.def (PARAM_MAX_LOOP_HEADER_INSNS): Likewise.
---
 gcc/doc/invoke.texi | 2 +-
 gcc/params.def  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)


diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 277c99a0527..a580794bfba 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -8619,7 +8619,7 @@ This flag is enabled by default at @option{-O2} and higher and depends on
 
 @item -fisolate-erroneous-paths-attribute
 @opindex fisolate-erroneous-paths-attribute
-Detect paths that trigger erroneous or undefined behavior due a null value
+Detect paths that trigger erroneous or undefined behavior due to a null value
 being used in a way forbidden by a @code{returns_nonnull} or @code{nonnull}
 attribute.  Isolate those paths from the main control flow and turn the
 statement with erroneous or undefined behavior into a trap.  This is not
diff --git a/gcc/params.def b/gcc/params.def
index e3336793b23..dad47ec2b00 100644
--- a/gcc/params.def
+++ b/gcc/params.def
@@ -354,11 +354,11 @@ DEFPARAM(PARAM_MAX_UNSWITCH_LEVEL,
 	"The maximum number of unswitchings in a single loop.",
 	3, 0, 0)
 
-/* The maximum number of insns in loop header duplicated by he copy loop
+/* The maximum number of insns in loop header duplicated by the copy loop
headers pass.  */
 DEFPARAM(PARAM_MAX_LOOP_HEADER_INSNS,
 	"max-loop-header-insns",
-	"The maximum number of insns in loop header duplicated by he copy loop headers pass.",
+	"The maximum number of insns in loop header duplicated by the copy loop headers pass.",
 	20, 0, 0)
 
 /* The maximum number of iterations of a loop the brute force algorithm

[PATCH] Put pass_sancov_O0 before pass_lower_switch with -O0 (PR sanitizer/82183).

[Martin Liška]

Hi.

Sorry that it took me quite some time. The patch puts sancov pass before switch
lowering on -O0.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
The test-case now works on aarch64.

Ready to be installed?
Martin

gcc/ChangeLog:

2018-02-16  Martin Liska  

PR sanitizer/82183
* passes.def: Put pass_sancov_O0 before pass_lower_switch with -O0.
---
 gcc/passes.def | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/gcc/passes.def b/gcc/passes.def
index 9802f08ecfc..3ebcfc30349 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -397,8 +397,8 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_lower_vaarg);
   NEXT_PASS (pass_lower_vector);
   NEXT_PASS (pass_lower_complex_O0);
-  NEXT_PASS (pass_lower_switch);
   NEXT_PASS (pass_sancov_O0);
+  NEXT_PASS (pass_lower_switch);
   NEXT_PASS (pass_asan_O0);
   NEXT_PASS (pass_tsan_O0);
   NEXT_PASS (pass_sanopt);

[PATCH] libstdc++-v3: Check for TLS support on mingw

[Hugo Beauzée-Luyssen]

libstdc++-v3: Check for TLS support on mingw

2018-02-16  Hugo Beauzée-Luyssen  

* crossconfig.m4: Check for TLS support on mignw
* configure: regenerate

Index: libstdc++-v3/crossconfig.m4
===
--- libstdc++-v3/crossconfig.m4 (revision 257730)
+++ libstdc++-v3/crossconfig.m4 (working copy)
@@ -197,6 +197,7 @@ case "${host}" in
 GLIBCXX_CHECK_LINKER_FEATURES
 GLIBCXX_CHECK_MATH_SUPPORT
 GLIBCXX_CHECK_STDLIB_SUPPORT
+GCC_CHECK_TLS
 ;;
   *-netbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'