[RFA][PATCH] 8/n Pull evrp range analyzer into its own file

[Jeff Law]

This is just a straight cut-n-paste pulling the evrp_range_analyzer
methods out of gimple-ssa-evrp.c into gimple-ssa-evrp-analyze.[ch].

Bootstrapped and regression tested on x86_64.


OK for the trunk?

Jeff
* Makefile.in (OBJS): Add gimple-ssa-evrp-analyze.o.
* gimple-ssa-evrp-analyze.c: New file pulled from gimple-ssa-evrp.c.
* gimple-ssa-evrp-analyze.h: New file pulled from gimple-ssa-evrp.c.
* gimple-ssa-evrp.c: Remove bits moved into new files.  Include
gimple-ssa-evrp-analyze.h.



diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 5db78558c0c..38ab4e81026 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1302,6 +1302,7 @@ OBJS = \
gimple-pretty-print.o \
gimple-ssa-backprop.o \
gimple-ssa-evrp.o \
+   gimple-ssa-evrp-analyze.o \
gimple-ssa-isolate-paths.o \
gimple-ssa-nonnull-compare.o \
gimple-ssa-split-paths.o \
diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
new file mode 100644
index 000..4f33c644a74
--- /dev/null
+++ b/gcc/gimple-ssa-evrp-analyze.c
@@ -0,0 +1,342 @@
+/* Support routines for Value Range Propagation (VRP).
+   Copyright (C) 2005-2017 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "tree.h"
+#include "gimple.h"
+#include "tree-pass.h"
+#include "ssa.h"
+#include "gimple-pretty-print.h"
+#include "cfganal.h"
+#include "gimple-fold.h"
+#include "tree-eh.h"
+#include "gimple-iterator.h"
+#include "tree-cfg.h"
+#include "tree-ssa-loop-manip.h"
+#include "tree-ssa-loop.h"
+#include "cfgloop.h"
+#include "tree-scalar-evolution.h"
+.#include "tree-ssa-propagate.h"
+#include "alloc-pool.h"
+#include "domwalk.h"
+#include "tree-cfgcleanup.h"
+#include "vr-values.h"
+#include "gimple-ssa-evrp-analyze.h"
+
+evrp_range_analyzer::evrp_range_analyzer () : stack (10)
+{
+  edge e;
+  edge_iterator ei;
+  basic_block bb;
+  FOR_EACH_BB_FN (bb, cfun)
+{
+  bb->flags &= ~BB_VISITED;
+  FOR_EACH_EDGE (e, ei, bb->preds)
+e->flags |= EDGE_EXECUTABLE;
+}
+}
+
+void
+evrp_range_analyzer::enter (basic_block bb)
+{
+  stack.safe_push (std::make_pair (NULL_TREE, (value_range *)NULL));
+  record_ranges_from_incoming_edge (bb);
+  record_ranges_from_phis (bb);
+}
+
+/* Find new range for NAME such that (OP CODE LIMIT) is true.  */
+value_range *
+evrp_range_analyzer::try_find_new_range (tree name,
+   tree op, tree_code code, tree limit)
+{
+  value_range vr = VR_INITIALIZER;
+  value_range *old_vr = get_value_range (name);
+
+  /* Discover VR when condition is true.  */
+  extract_range_for_var_from_comparison_expr (name, code, op,
+ limit, &vr);
+  /* If we found any usable VR, set the VR to ssa_name and create a
+ PUSH old value in the stack with the old VR.  */
+  if (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE)
+{
+  if (old_vr->type == vr.type
+ && vrp_operand_equal_p (old_vr->min, vr.min)
+ && vrp_operand_equal_p (old_vr->max, vr.max))
+   return NULL;
+  value_range *new_vr = vr_values.vrp_value_range_pool.allocate ();
+  *new_vr = vr;
+  return new_vr;
+}
+  return NULL;
+}
+
+void
+evrp_range_analyzer::record_ranges_from_incoming_edge (basic_block bb)
+{
+  edge pred_e = single_pred_edge_ignoring_loop_edges (bb, false);
+  if (pred_e)
+{
+  gimple *stmt = last_stmt (pred_e->src);
+  tree op0 = NULL_TREE;
+
+  if (stmt
+ && gimple_code (stmt) == GIMPLE_COND
+ && (op0 = gimple_cond_lhs (stmt))
+ && TREE_CODE (op0) == SSA_NAME
+ && (INTEGRAL_TYPE_P (TREE_TYPE (gimple_cond_lhs (stmt)))
+ || POINTER_TYPE_P (TREE_TYPE (gimple_cond_lhs (stmt)
+   {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+   {
+ fprintf (dump_file, "Visiting controlling predicate ");
+ print_gimple_stmt (dump_file, stmt, 0);
+   }
+ /* Entering a new scope.  Try to see if we can find a VR
+here.  */
+ tree op1 = gimple_cond_rhs (stmt);
+ if (TREE_OVERFLOW_P (op1))
+   op1 = drop_tree_overflow (op1);
+ tree_code code = gimple_cond_code (stmt);
+
+ auto_vec as

[RFA][PATCH] 9/n Finish moving BB_VISITED handling into range analyzer

[Jeff Law]

I didn't want to rebase my patchset yet again to fix this minor goof.  I
moved initialization of BB_VISITED into the range analyzer, but forgot
to move setting it as we visit each block into the analyzer.

This fixes that oversight.

Bootstrapped and regression tested on x86.

OK for the trunk?

Jeff
* gimple-ssa-evrp.c (evrp_dom_walker::before_dom_children): Do not
set BB_VISITED here.
* gimple-ssa-evrp-analyze.c (evrp_range_analyzer::enter): Set
BB_VISITED here instead.

commit 0455c00f320dc1136ca742e46ca5a184e144b0e6
Author: Jeff Law 
Date:   Fri Nov 17 15:15:36 2017 -0500

FIx bb_visited handling

diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
index 4f33c644a74..9e581834d08 100644
--- a/gcc/gimple-ssa-evrp-analyze.c
+++ b/gcc/gimple-ssa-evrp-analyze.c
@@ -61,6 +61,7 @@ evrp_range_analyzer::enter (basic_block bb)
   stack.safe_push (std::make_pair (NULL_TREE, (value_range *)NULL));
   record_ranges_from_incoming_edge (bb);
   record_ranges_from_phis (bb);
+  bb->flags |= BB_VISITED;
 }
 
 /* Find new range for NAME such that (OP CODE LIMIT) is true.  */
diff --git a/gcc/gimple-ssa-evrp.c b/gcc/gimple-ssa-evrp.c
index 5fa9cfb3538..27a983dd9ae 100644
--- a/gcc/gimple-ssa-evrp.c
+++ b/gcc/gimple-ssa-evrp.c
@@ -228,8 +228,6 @@ evrp_dom_walker::before_dom_children (basic_block bb)
}
 }
  
-  bb->flags |= BB_VISITED;
-
   return taken_edge;
 }
 

[RFA][PATCH] 10/n Various class definition cleanups

[Jeff Law]

A batch of random cleanups in the various vrp related bits.

The goal here is to start banging some of the classes into shape.
Included in this patch:


For evrp_folder:
  Accepts vr_values in its ctor to attach.
  Uses DISABLE_COPY_AND_ASSIGN

For evrp_dom_walker:
  Has the evrp_folder attached to it to avoid continually
  recreating an evrp_folder instance.
  Delegators removed, created free value_range_constant_singleton
  along the way to help remove one of them.

For evrp_range_analyzer:
  The attached vr_values member is now private.
  3 delegators are kept and made part of the public API
  The remaining half-dozen or so delegators are gone

For vr_values:
  Privatizes several data members
  Privatizes many methods


I'm still not at all happy with management of the attached vr_values
class instance.  I was going to use our unique_ptr, but without examples
my attempts failed.  I'll have to give it another whirl when I'm fresher.

Bootstrapped and regression tested on x86_64.

OK for the trunk once the vr_values attachment code is cleaned up and it
goes through another round of testing?

jeff




* gimple-ssa-evrp-analyze.c (evrp_range_analyzer::evrp_range_analyzer)
Initialize vr_values.
(evrp_range_analyzer::try_find_new_range): Call methods attached to
vr_values via vr_values class instance rather than delegators.
(evrp_range_analyzer::record_ranges_from_phis): Likewise.
(evrp_range_analyzer::record_ranges_from_stmt): Likewise.
(evrp_range_analyzer::push_value_range): Likewise.
(evrp_range_analyzer::pop_value_range): Likewise.
* gimple-ssa-evrp-analyze.h (class evrp_range_analyzer): Remove
most delegators.  Those remaining are exposed as public interfaces.
Make vr_values a pointer.
(evrp_range_analyzer::~evrp_range_analyzer): Conditionally
delete the attached vr_values.
(evrp_range_analyzer::get_vr_value): New method.
* gimple-ssa-evrp.c (class evrp_folder): Use DISABLE_COPY_AND_ASSIGN.
(evrp_folder::evrp_folder): New ctor to initialize vr_values.
(class evrp_dom_walker): Attach evrp_folder class, initialize
it in the ctor.  Remove temporary delegators.
(evrp_dom_walker::before_dom_children): Call methods in attached
evrp_range_analyzer class via class instance pointer.  Use
free value_range_constant_singleton to remove need for
op_with_constant_singleton_value delegator method.  Do not
create a vrp_prop class instance for every call!  Narrow
scope of a couple variables.
(evrp_dom_walker::cleanup): Call methods in attached
evrp_range_analyzer class via class instance pointer.
* vr-values.h (class vr_values): Privatize many methods and
data members.


diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
index 9e581834d08..c3877791a5e 100644
--- a/gcc/gimple-ssa-evrp-analyze.c
+++ b/gcc/gimple-ssa-evrp-analyze.c
@@ -53,6 +53,7 @@ evrp_range_analyzer::evrp_range_analyzer () : stack (10)
   FOR_EACH_EDGE (e, ei, bb->preds)
 e->flags |= EDGE_EXECUTABLE;
 }
+  vr_values = new class vr_values;
 }
 
 void
@@ -73,8 +74,8 @@ evrp_range_analyzer::try_find_new_range (tree name,
   value_range *old_vr = get_value_range (name);
 
   /* Discover VR when condition is true.  */
-  extract_range_for_var_from_comparison_expr (name, code, op,
- limit, &vr);
+  vr_values->extract_range_for_var_from_comparison_expr (name, code, op,
+limit, &vr);
   /* If we found any usable VR, set the VR to ssa_name and create a
  PUSH old value in the stack with the old VR.  */
   if (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE)
@@ -83,7 +84,7 @@ evrp_range_analyzer::try_find_new_range (tree name,
  && vrp_operand_equal_p (old_vr->min, vr.min)
  && vrp_operand_equal_p (old_vr->max, vr.max))
return NULL;
-  value_range *new_vr = vr_values.vrp_value_range_pool.allocate ();
+  value_range *new_vr = vr_values->vrp_value_range_pool.allocate ();
   *new_vr = vr;
   return new_vr;
 }
@@ -167,7 +168,7 @@ evrp_range_analyzer::record_ranges_from_phis (basic_block 
bb)
   value_range vr_result = VR_INITIALIZER;
   bool interesting = stmt_interesting_for_vrp (phi);
   if (!has_unvisited_preds && interesting)
-   extract_range_from_phi_node (phi, &vr_result);
+   vr_values->extract_range_from_phi_node (phi, &vr_result);
   else
{
  set_value_range_to_varying (&vr_result);
@@ -179,9 +180,9 @@ evrp_range_analyzer::record_ranges_from_phis (basic_block 
bb)
  if (interesting
  && (l = loop_containing_stmt (phi))
  && l->header == gimple_bb (phi))
- adjust_range_with_scev (&vr_result, l, phi, lhs);
+ vr_values->adjust_range_with_scev (&vr_resul

[RFA][PATCH] 11/n More VRP related cleanups

[Jeff Law]

Not as extensive as the last set.  Just getting a couple data members
privatized as well as one method within vr_values.

I'd really like to just get values_propagated out of vr_values and bury
it in tree-vrp.c, but we're not to that point yet.

Bootstrapped and regression tested on x86.

OK for the trunk?

jeff

* gimple-ssa-evrp-analyze.c (evrp_range_analyzer::try_find_new_range):
Use new method allocate_value_range rather than accessing the
vrp_value_range_pool data member directly.
* tree-vrp.c (simplify_stmt_for_jump_threading): Tweak slightly
to use extract_range_from_stmt method to avoid need for
extract_range_from_assignment method.
(vrp_prop::vrp_finalize): Use set_lattice_propagation_complete
method rather than setting values_propgated data member directly.
* vr-values.h (class vr_values): Privatize vrp_value_range_pool,
and values propagated data members and extract_range_from_assignment
method.  Reorder private data members to conform to standards.
Add new methods set_lattice_propagation_complete and
allocate_value_range.



diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
index c3877791a5e..cfaf18feecb 100644
--- a/gcc/gimple-ssa-evrp-analyze.c
+++ b/gcc/gimple-ssa-evrp-analyze.c
@@ -84,7 +84,7 @@ evrp_range_analyzer::try_find_new_range (tree name,
  && vrp_operand_equal_p (old_vr->min, vr.min)
  && vrp_operand_equal_p (old_vr->max, vr.max))
return NULL;
-  value_range *new_vr = vr_values->vrp_value_range_pool.allocate ();
+  value_range *new_vr = vr_values->allocate_value_range ();
   *new_vr = vr;
   return new_vr;
 }
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index e248f59a67f..838822d82f6 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -6572,14 +6572,17 @@ simplify_stmt_for_jump_threading (gimple *stmt, gimple 
*within_stmt,
 
   if (gassign *assign_stmt = dyn_cast  (stmt))
 {
-  value_range new_vr = VR_INITIALIZER;
   tree lhs = gimple_assign_lhs (assign_stmt);
-
   if (TREE_CODE (lhs) == SSA_NAME
  && (INTEGRAL_TYPE_P (TREE_TYPE (lhs))
- || POINTER_TYPE_P (TREE_TYPE (lhs
+ || POINTER_TYPE_P (TREE_TYPE (lhs)))
+ && stmt_interesting_for_vrp (stmt))
{
- vr_values->extract_range_from_assignment (&new_vr, assign_stmt);
+ edge dummy_e;
+ tree dummy_tree;
+ value_range new_vr = VR_INITIALIZER;
+ vr_values->extract_range_from_stmt (stmt, &dummy_e,
+ &dummy_tree, &new_vr);
  if (range_int_cst_singleton_p (&new_vr))
return new_vr.min;
}
@@ -6747,7 +6750,8 @@ vrp_prop::vrp_finalize (bool warn_array_bounds_p)
 {
   size_t i;
 
-  vr_values.values_propagated = true;
+  /* We have completed propagating through the lattice.  */
+  vr_values.set_lattice_propagation_complete ();
 
   if (dump_file)
 {
diff --git a/gcc/vr-values.h b/gcc/vr-values.h
index 9eeebedfaed..124ee6f4356 100644
--- a/gcc/vr-values.h
+++ b/gcc/vr-values.h
@@ -54,7 +54,6 @@ class vr_values
   tree, tree, value_range *);
   void extract_range_from_phi_node (gphi *, value_range *);
   void extract_range_basic (value_range *, gimple *);
-  void extract_range_from_assignment (value_range *, gassign *);
   void extract_range_from_stmt (gimple *, edge *, tree *, value_range *);
 
   void vrp_visit_cond_stmt (gcond *, edge *);
@@ -62,14 +61,14 @@ class vr_values
   void simplify_cond_using_ranges_2 (gcond *);
   bool simplify_stmt_using_ranges (gimple_stmt_iterator *);
 
-  /* This probably belongs in the lattice rather than in here.  */
-  bool values_propagated;
+  /* Indicate that propagation through the lattice is complete.  */
+  void set_lattice_propagation_complete (void) { values_propagated = true; }
 
-  /* Allocation pools for tree-vrp allocations.  */
-  object_allocator vrp_value_range_pool;
+  /* Allocate a new value_range object.  */
+  value_range *allocate_value_range (void)
+{ return vrp_value_range_pool.allocate (); }
 
  private:
-  bitmap_obstack vrp_equiv_obstack;
   void add_equivalence (bitmap *, const_tree);
   bool vrp_stmt_computes_nonzero (gimple *);
   bool op_with_boolean_value_range_p (tree);
@@ -84,6 +83,7 @@ class vr_values
   tree vrp_evaluate_conditional_warnv_with_ops (enum tree_code,
tree, tree, bool,
bool *, bool *);
+  void extract_range_from_assignment (value_range *, gassign *);
   void extract_range_from_assert (value_range *, tree);
   void extract_range_from_ssa_name (value_range *, tree);
   void extract_range_from_binary_expr (value_range *, enum tree_code,
@@ -106,6 +106,15 @@ class vr_values
   gimple *);
   bool simplify_internal_call_using_range

Re: [RFTesting] New POINTER_DIFF_EXPR

[Marc Glisse]

On Fri, 17 Nov 2017, Jason Merrill wrote:


It's not clear to me that cp_build_binary_op needs to handle
POINTER_DIFF_EXPR, it should get MINUS_EXPR and produce
POINTER_DIFF_EXPR.


Indeed, I added POINTER_DIFF_EXPR in many places by looking for
MINUS_EXPR, but this one is useless, regtesting passes without it.


* tree.def: New tree code POINTER_DIFF_EXPR.


The comment might mention that the value is the same for all pointer
types, not divided by the size of the pointed-to type.


Good idea, thanks.

--
Marc Glisse

[RFC][PATCH 12/n Embed range analysis in DOM

[Jeff Law]

And a WIP.  I can justify continuing work on this during stage3 for
pr78496.  But I thought it was worth giving folks a looksie.

The goal here is to make tree-vrp's threading obsolete and remove it and
at the same time pick up all the missed jump threads in pr78496.

Essentially this patch embeds the evrp analysis into DOM and adds some
simplification code to use the results of the evrp analysis within jump
threading.

This bootstraps, but doesn't quite pass regression testing.  There's a
few tests that need adjustment.  There's also two failing tests which I
think are a manifestation of a latent bug in the EVRP bits I've been
worried about since I started looking at the code.

It does find *all* the missing threads in pr78496.  I'm still evaluating
the impact of dropping tree-vrp.c's jump threading, but it looks promising.

There's two patches I'm not posting at this time.  First is the range
analyzer embedded in the sprintf warning pass to avoid a false positive
reported to gcc-bugs a while back.  I'm pretty sure it tickles the same
latent bug I mentioned above with the range analyzer embedded in DOM.
It also needs minor fixes to deal with being called when the optimizer
is not on.  Given the false positive posted to gcc-bugs and the tiny
size of the patch I can justify wrapping that up early in stage3.

The second patch I'm not posting rips jump threading out of tree-vrp.c
It's just too rough in its current state.  I'm sure there's a bug that
says GCC has gotten slower than I can use to justify pushing on this
early in stage3 as well.

I'm calling it a night from my virtual office in Hawaii.

Jeff

* gimple-ssa-evrp-analyze.h (class evrp_range_analyzer): Add new
private member, use_scev to control use of SCEV.
* gimple-ssa-evrp-analyze.c
(evrp_range_analyzer::evrp_range_analyzer): Initialize use_scev
from argument.  Pass it along to vr_values ctor as well.
(evrp_range_analyzer::record_ranges_from_phis): Only call
SCEV routines if use_scev is true.
* gimple-ssa-evrp.c (evrp_dom_walker): Pass use_scev along to
evrp_range_analyzer ctor.
* tree-vrp.c (vrp_prop::vrp_prop): Accept along use_scev to to
vr_values ctor.
(execute_vrp): Add new argument to vrp_prop::vrp_prop.
* vr-values.h (class vr_values): New data member use_scev.
* vr-values.c (vr_values::vr_values): Accept and initialize use_scev.
(vr_values::extract_range_from_phi_node): Only call SCEV routines
if use_scev is true.

* tree-ssa-dom.c: Include alloc-pool.h, tree-vrp.h, vr-values.h
and gimple-ssa-evrp-analyze.h.
(dom_opt_dom_walker class): Add evrp_range_analyzer member and
initialize it.
(simplify_stmt_for_jump_threading): Copy a blob of code from
tree-vrp.c to use ranges to simplify statements.
(dom_opt_dom_walker::before_dom_children): Call
evrp_range_analyzer::{enter,record_ranges_from_stmt} methods.
(dom_opt_dom_walker::after_dom_children): Similarly for
evrp_range_analyzer::leave.




diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
index 5702a5e..0fd5a01 100644
--- a/gcc/gimple-ssa-evrp-analyze.c
+++ b/gcc/gimple-ssa-evrp-analyze.c
@@ -42,7 +42,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "vr-values.h"
 #include "gimple-ssa-evrp-analyze.h"
 
-evrp_range_analyzer::evrp_range_analyzer () : stack (10)
+evrp_range_analyzer::evrp_range_analyzer (bool use_scev_)
+  : use_scev (use_scev_), stack (10)
 {
   edge e;
   edge_iterator ei;
@@ -53,7 +54,7 @@ evrp_range_analyzer::evrp_range_analyzer () : stack (10)
   FOR_EACH_EDGE (e, ei, bb->preds)
 e->flags |= EDGE_EXECUTABLE;
 }
-  vr_values = new class vr_values;
+  vr_values = new class vr_values (use_scev);
 }
 
 void
@@ -178,7 +179,8 @@ evrp_range_analyzer::record_ranges_from_phis (basic_block 
bb)
 to use VARYING for them.  But we can still resort to
 SCEV for loop header PHIs.  */
  struct loop *l;
- if (interesting
+ if (use_scev
+ && interesting
  && (l = loop_containing_stmt (phi))
  && l->header == gimple_bb (phi))
  vr_values->adjust_range_with_scev (&vr_result, l, phi, lhs);
diff --git a/gcc/gimple-ssa-evrp-analyze.h b/gcc/gimple-ssa-evrp-analyze.h
index b60bba8..c327836 100644
--- a/gcc/gimple-ssa-evrp-analyze.h
+++ b/gcc/gimple-ssa-evrp-analyze.h
@@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 class evrp_range_analyzer
 {
  public:
-  evrp_range_analyzer (void);
+  evrp_range_analyzer (bool);
   ~evrp_range_analyzer (void) 
   {
 if (vr_values)
@@ -70,6 +70,9 @@ class evrp_range_analyzer
   void record_ranges_from_incoming_edge (basic_block);
   void record_ranges_from_phis (basic_block);
 
+  /* Whether or not to use SCEV to refine ranges.  */
+  bool use_scev;
+
   /* STACK holds the old VR.

Re: [RFTesting] New POINTER_DIFF_EXPR

[Marc Glisse]

On Fri, 17 Nov 2017, DJ Delorie wrote:



Richard Biener  writes:

The question is what ptrdiff_t is for a specific address space. Or
rather if that type may be dependent on the address space or if we can
always use that of the default address space.


Some targets have a "far" address space that's bigger than the default.
rl78 for example has a 16-bit default pointer and a 32-bit far pointer.


Thanks for the pointer to an unusual target. I built cc1 for a 
cross-compiler, and as far as I can see, the patch generates the same code 
as before, both for regular and __far pointers, except in a few cases 
where the patch simplifies more, but in a way that seems safe.


--
Marc Glisse

Re: [RFTesting] New POINTER_DIFF_EXPR

[Marc Glisse]

On Fri, 17 Nov 2017, Richard Biener wrote:


On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse  wrote:


The exact undefined-behavior status should probably be clarified more.
First, I'd like to say that POINTER_DIFF_EXPR may only take 2 pointers into
the same "object" (like in C/C++), so they differ by at most half the size
of the address space, and a-b is not allowed to be the minimum negative
value (so I can safely use b-a), and if we compute a-b and b-c, then a and c
are in the same object so I can safely compute a-c, etc. Second, we probably
need modes without undefined behavior, wrapping with either -fwrapv or a new
-fwrapp, or sanitized. For the sanitized version, we could keep using
POINTER_DIFF_EXPR and check TYPE_OVERFLOW_SANITIZED on the pointer type as
we currently do for integers. For wrapping, either we say that
POINTER_DIFF_EXPR has wrapping semantics when that option is in effect, or
we do not use POINTER_DIFF_EXPR and instead cast to unsigned before applying
a MINUS_EXPR (my preference).


CCing C/C++ FE folks as well.

+  /* It is better if the caller provides the return type.  */
+  if (code == POINTER_DIFF_EXPR)
+   {
+ offset_int res = wi::sub (wi::to_offset (arg1),
+   wi::to_offset (arg2));
+ return force_fit_type (signed_type_for (TREE_TYPE (arg1)), res, 1,
+TREE_OVERFLOW (arg1) | TREE_OVERFLOW (arg2));
+   }
+

there's an overload that provides the type... (we should probably go
over all callers
and use that).  There is already a folding that is only done when the type is
available.  So I'd simply remove the above from the non-type overload handling.
What breaks then?


I haven't checked yet. On the other hand, now that I require the same 
precision for pointers and their difference, using signed_type_for should 
be safe enough (only issue is if a front-end is unhappy that we changed 
the exact type for another 'equivalent' one). But I'll try removing the 
version with signed_type_for.



With the patch it's of course somewhat ugly in that we need to deal with both
MINUS_EXPR on pointers and POINTER_DIFF_EXPR - at least that's what

+case POINTER_DIFF_EXPR:
case MINUS_EXPR:
+  /* Fold &a[i] - &a[j] to i-j.  */
+  if (TREE_CODE (arg0) == ADDR_EXPR
+ && TREE_CODE (TREE_OPERAND (arg0, 0)) == ARRAY_REF
+ && TREE_CODE (arg1) == ADDR_EXPR
+ && TREE_CODE (TREE_OPERAND (arg1, 0)) == ARRAY_REF)
+{
+ tree tem = fold_addr_of_array_ref_difference (loc, type,
+   TREE_OPERAND (arg0, 0),
+   TREE_OPERAND (arg1, 0),
+   code
+   == POINTER_DIFF_EXPR);

suggests.  But is that really so?  The FEs today should never build
a MINUS_EXPR with pointer operands and your patch also doesn't.
I suppose we only arrive above because STRIP_NOPS strips the
pointer to integer conversion?


I think so. And since I only patched 2 front-ends, others probably still 
generate casts to integers and MINUS_EXPR and can benefit from this 
transformation. Also, if we implement -fwrapp by casting to unsigned and 
doing MINUS_EXPR, that will remain useful.



+case POINTER_DIFF_EXPR:
+  if (!POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (t, 0)))
+ || !POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (t, 1
+   {
+ error ("invalid operand to pointer diff, operand is not a pointer");
+ return t;
+   }
+  CHECK_OP (0, "invalid operand to pointer diff");
+  CHECK_OP (1, "invalid operand to pointer diff");
+  break;

can you add
 || TREE_CODE (TREE_TYPE (t)) != INTEGER_TYPE
 || TYPE_UNSIGNED (TREE_TYPE (t))


I wasn't sure how much to duplicate between here and below. Added.


?  Note that if the precision of the pointer type arguments are not equal to the
precision of the return value then foldings like

  (simplify
+   (plus:c (pointer_diff @0 @1) (pointer_diff @2 @0))
+   (if (TYPE_OVERFLOW_UNDEFINED (type)
+   && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@0)))
+(pointer_diff @2 @1)))

might not be correct as we drop a possible truncation here.  Shall we


I simplified the transformations after deciding to require equal 
precision.



require (and document) that the result of the pointer difference in
a POINTER_DIFF_EXPR has to be representable in the type of the
expression, otherwise
the behavior is undefined?  Shall we allow an unsigned return type for
differences known to be representable?  Probably not...  Does the behavior
depend on TYPE_OVERFLOW_UNDEFINED?  It would be nice to amend
the generic.texi docs somewhat here.


I was more precise in tree.def, copying details over to generic.texi now.
But the overflow behavior is something I was asking about above (see
citation at the beginning of this email). I am tempted to say that 

Re: [RFTesting] New POINTER_DIFF_EXPR

[Marc Glisse]

On Fri, 17 Nov 2017, Joseph Myers wrote:


On Fri, 17 Nov 2017, DJ Delorie wrote:


Richard Biener  writes:

The question is what ptrdiff_t is for a specific address space. Or
rather if that type may be dependent on the address space or if we can
always use that of the default address space.


Some targets have a "far" address space that's bigger than the default.
rl78 for example has a 16-bit default pointer and a 32-bit far pointer.


Well, that's outside the scope of how TR 18037 defines the address space
feature, if ptrdiff_t is 16-bit.  But it should still have nothing to do
with this patch as long as the patch keeps the result of the subtraction
having the same type it does at present.


Well, that's good then. Is the C front-end part of the patch ok for you?

--
Marc Glisse

Re: Fix IPA profile updates in inlining and ipa-split

[Markus Trippelsdorf]

On 2017.11.18 at 00:39 +0100, Jan Hubicka wrote:
> Hi,
> this patch fixes remaining IPA profile updating issues I am aware of.  With
> this change there is 1 profile mismatch after inlining for tramp3d -Ofast
> and 112 of them in .optimized dump which is about 10 times less than before.
> I did not inspect them all but they seems mostly justified and not very
> important.
> 
> First patch adds new profile quality stage when global profile is 0 but not
> known precisely.  This is useful for bb partitioning where we do not want to
> move adjusted 0 to cold sections.
> 
> Second the patch adds little infrastructure for turning IPA info to local
> info (profile_count::combine_with_ipa_count) and commonizes all places that
> do this kind of operation.
> 
> Finally it fixes profile updating bug in ipa-split where entry and return
> blocks got wrong profile.
> 
> Bootstrapped/regtested x86_64-linux. I am profilebootstrapping overnight
> and plan to commit tomorrow.

This fixes the tramp3d compile time regression with LTO/PGO bootstrapped
gcc, that I have reported earlier. 
In fact gcc-8 now compiles tramp3d-v4 ~8.5% faster than gcc-7.

The patch also fixes PR83037 and PR83039.

-- 
Markus

[PATCH] Make NEXTREC specifier for INQUIRE work for large record numbers

[Janne Blomqvist]

This is accomplished by making the NEXTREC specifier be a 8 byte
integer where supported.

I wasn't able to come up with a testcase that does not create a large
file that could be added to the testsuite, but here's one which
creates a 2 GB file:

program nextrec
  implicit none
  integer(8) :: ii, n
  open(10, file="foo.dat", recl=1, access="direct", form="unformatted", 
status="replace")
  do ii = 1, huge(1) + 2_8
 write(10, rec=ii) 'a'
  end do
  inquire(10, nextrec=n)
  if (n /= huge(1) + 2_8) then
 call abort()
  end if
  close(10, status="delete")
end program nextrec

Regtested on x86_64-pc-linux-gnu, Ok for trunk?

gcc/fortran/ChangeLog:

2017-11-18  Janne Blomqvist  

PR fortran/83036
* ioparm.def (IOPARM): Make nextrec a pintio.

libgfortran/ChangeLog:

2017-11-18  Janne Blomqvist  

PR fortran/83036
* io/io.h: Make nextrec a GFC_IO_INT*.
---
 gcc/fortran/ioparm.def | 2 +-
 libgfortran/io/io.h| 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/fortran/ioparm.def b/gcc/fortran/ioparm.def
index ca5631b..920934a 100644
--- a/gcc/fortran/ioparm.def
+++ b/gcc/fortran/ioparm.def
@@ -62,7 +62,7 @@ IOPARM (inquire, exist,   1 << 7,  pint4)
 IOPARM (inquire, opened,   1 << 8,  pint4)
 IOPARM (inquire, number,   1 << 9,  pint4)
 IOPARM (inquire, named,1 << 10, pint4)
-IOPARM (inquire, nextrec,  1 << 11, pint4)
+IOPARM (inquire, nextrec,  1 << 11, pintio)
 IOPARM (inquire, recl_out, 1 << 12, pint4)
 IOPARM (inquire, strm_pos_out, 1 << 13, pintio)
 IOPARM (inquire, file, 1 << 14, char1)
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index df49157..483ee93 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -388,7 +388,8 @@ typedef struct
 {
   st_parameter_common common;
   GFC_INTEGER_4 *exist, *opened, *number, *named;
-  GFC_INTEGER_4 *nextrec, *recl_out;
+  GFC_IO_INT *nextrec;
+  GFC_INTEGER_4 *recl_out;
   GFC_IO_INT *strm_pos_out;
   CHARACTER1 (file);
   CHARACTER2 (access);
-- 
2.7.4

Re: [PATCH] Make NEXTREC specifier for INQUIRE work for large record numbers

[Janne Blomqvist]

On Sat, Nov 18, 2017 at 12:34 PM, Janne Blomqvist
 wrote:
> This is accomplished by making the NEXTREC specifier be a 8 byte
> integer where supported.
>
> I wasn't able to come up with a testcase that does not create a large
> file that could be added to the testsuite, but here's one which
> creates a 2 GB file:
>
> program nextrec
>   implicit none
>   integer(8) :: ii, n
>   open(10, file="foo.dat", recl=1, access="direct", form="unformatted", 
> status="replace")
>   do ii = 1, huge(1) + 2_8
>  write(10, rec=ii) 'a'
>   end do
>   inquire(10, nextrec=n)
>   if (n /= huge(1) + 2_8) then

This statement should of course be

if (n /= huge(1) + 3_8) then


-- 
Janne Blomqvist

Re: [RFTesting] New POINTER_DIFF_EXPR

[Richard Biener]

On November 18, 2017 11:20:42 AM GMT+01:00, Marc Glisse  
wrote:
>On Fri, 17 Nov 2017, Richard Biener wrote:
>
>> On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse 
>wrote:
>>
>>> The exact undefined-behavior status should probably be clarified
>more.
>>> First, I'd like to say that POINTER_DIFF_EXPR may only take 2
>pointers into
>>> the same "object" (like in C/C++), so they differ by at most half
>the size
>>> of the address space, and a-b is not allowed to be the minimum
>negative
>>> value (so I can safely use b-a), and if we compute a-b and b-c, then
>a and c
>>> are in the same object so I can safely compute a-c, etc. Second, we
>probably
>>> need modes without undefined behavior, wrapping with either -fwrapv
>or a new
>>> -fwrapp, or sanitized. For the sanitized version, we could keep
>using
>>> POINTER_DIFF_EXPR and check TYPE_OVERFLOW_SANITIZED on the pointer
>type as
>>> we currently do for integers. For wrapping, either we say that
>>> POINTER_DIFF_EXPR has wrapping semantics when that option is in
>effect, or
>>> we do not use POINTER_DIFF_EXPR and instead cast to unsigned before
>applying
>>> a MINUS_EXPR (my preference).
>>
>> CCing C/C++ FE folks as well.
>>
>> +  /* It is better if the caller provides the return type.  */
>> +  if (code == POINTER_DIFF_EXPR)
>> +   {
>> + offset_int res = wi::sub (wi::to_offset (arg1),
>> +   wi::to_offset (arg2));
>> + return force_fit_type (signed_type_for (TREE_TYPE (arg1)),
>res, 1,
>> +TREE_OVERFLOW (arg1) | TREE_OVERFLOW
>(arg2));
>> +   }
>> +
>>
>> there's an overload that provides the type... (we should probably go
>> over all callers
>> and use that).  There is already a folding that is only done when the
>type is
>> available.  So I'd simply remove the above from the non-type overload
>handling.
>> What breaks then?
>
>I haven't checked yet. On the other hand, now that I require the same 
>precision for pointers and their difference, using signed_type_for
>should 
>be safe enough (only issue is if a front-end is unhappy that we changed
>
>the exact type for another 'equivalent' one). But I'll try removing the
>
>version with signed_type_for.
>
>> With the patch it's of course somewhat ugly in that we need to deal
>with both
>> MINUS_EXPR on pointers and POINTER_DIFF_EXPR - at least that's what
>>
>> +case POINTER_DIFF_EXPR:
>> case MINUS_EXPR:
>> +  /* Fold &a[i] - &a[j] to i-j.  */
>> +  if (TREE_CODE (arg0) == ADDR_EXPR
>> + && TREE_CODE (TREE_OPERAND (arg0, 0)) == ARRAY_REF
>> + && TREE_CODE (arg1) == ADDR_EXPR
>> + && TREE_CODE (TREE_OPERAND (arg1, 0)) == ARRAY_REF)
>> +{
>> + tree tem = fold_addr_of_array_ref_difference (loc, type,
>> +   TREE_OPERAND
>(arg0, 0),
>> +   TREE_OPERAND
>(arg1, 0),
>> +   code
>> +   ==
>POINTER_DIFF_EXPR);
>>
>> suggests.  But is that really so?  The FEs today should never build
>> a MINUS_EXPR with pointer operands and your patch also doesn't.
>> I suppose we only arrive above because STRIP_NOPS strips the
>> pointer to integer conversion?
>
>I think so. And since I only patched 2 front-ends, others probably
>still 
>generate casts to integers and MINUS_EXPR and can benefit from this 
>transformation. Also, if we implement -fwrapp by casting to unsigned
>and 
>doing MINUS_EXPR, that will remain useful.
>
>> +case POINTER_DIFF_EXPR:
>> +  if (!POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (t, 0)))
>> + || !POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (t, 1
>> +   {
>> + error ("invalid operand to pointer diff, operand is not a
>pointer");
>> + return t;
>> +   }
>> +  CHECK_OP (0, "invalid operand to pointer diff");
>> +  CHECK_OP (1, "invalid operand to pointer diff");
>> +  break;
>>
>> can you add
>>  || TREE_CODE (TREE_TYPE (t)) != INTEGER_TYPE
>>  || TYPE_UNSIGNED (TREE_TYPE (t))
>
>I wasn't sure how much to duplicate between here and below. Added.
>
>> ?  Note that if the precision of the pointer type arguments are not
>equal to the
>> precision of the return value then foldings like
>>
>>   (simplify
>> +   (plus:c (pointer_diff @0 @1) (pointer_diff @2 @0))
>> +   (if (TYPE_OVERFLOW_UNDEFINED (type)
>> +   && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@0)))
>> +(pointer_diff @2 @1)))
>>
>> might not be correct as we drop a possible truncation here.  Shall we
>
>I simplified the transformations after deciding to require equal 
>precision.
>
>> require (and document) that the result of the pointer difference in
>> a POINTER_DIFF_EXPR has to be representable in the type of the
>> expression, otherwise
>> the behavior is undefined?  Shall we allow an unsigned return type
>for
>> differences known to be represent

Re: [PATCH] MicroBlaze use default ident output generation

[Nathan Rossi]

On 18 November 2017 at 04:25, Jeff Law  wrote:
> On 11/15/2017 11:58 PM, Nathan Rossi wrote:
>> Remove the MicroBlaze specific TARGET_ASM_OUTPUT_IDENT definition, and
>> use the default.
>>
>> This resolves issues associated with the use of the .sdata2 operation in
>> cases where emitted assembly after the ident output is incorrectly in
>> the .sdata2 section instead of .text or any other expected section.
>> Which results in assembly failures including operations with symbols
>> across different segments.
>>
>> gcc/ChangeLog
>>
>> 2017-11-16  Nathan Rossi  
>>
>>   PR target/83013
>>   * config/microblaze/microblaze-protos.h
>>   (microblaze_asm_output_ident): Delete
>>   * config/microblaze/microblaze.c (microblaze_asm_output_ident): Delete
>>   * config/microblaze/microblaze.h (TARGET_ASM_OUTPUT_IDENT): Default
> But isn't the purpose of the override to force certain small-enough
> objects into the .sdata2 section and by removing the override aren't you
> losing that capability?
>
> It does seem like the override is broken in that it changes the current
> section behind the back of the generic code.
>
> Wouldn't a better fix be to ensure that the override arranges to switch
> back to whatever the current section is?  Perhaps using .pushsection and
> .popsection would help here?
>

That would be a better fix, however I sent this change first as it
seemed it might be preferred to remove the target specific behavior
instead of fixing it. Since it is the only target that actually uses
the TARGET_ASM_OUTPUT_IDENT to change the output asm content (others
either define the default or have a function that calls the default).

But I can sort out a patch that fixes the behavior instead if that is preferred?

Regards,
Nathan

Re: [PATCH] MicroBlaze use default ident output generation

[Nathan Rossi]

On 18 November 2017 at 04:30, Michael Eager  wrote:
> On 11/15/2017 10:58 PM, Nathan Rossi wrote:
>>
>> Remove the MicroBlaze specific TARGET_ASM_OUTPUT_IDENT definition, and
>> use the default.
>>
>> This resolves issues associated with the use of the .sdata2 operation in
>> cases where emitted assembly after the ident output is incorrectly in
>> the .sdata2 section instead of .text or any other expected section.
>> Which results in assembly failures including operations with symbols
>> across different segments.
>
>
> Can you give me an example where this causes a problem?

Sure, I filed a GCC bugzilla with a sample code file that exhibits the
cross-segment symbol issue.

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

There was also an older bug I saw before filing the above which might
be the same issue though I have not verified that. Just looking at the
.s files from the linked binutils issue appears to show the same issue
however with .rodata instead of .sdata2.

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

Regards,
Nathan

Re: [Patch, fortran] PR78990 [5/6/7 Regression] ICE when assigning polymorphic array function result

[Paul Richard Thomas]

Dear Dominique,

Please find attached a revised patch that I believe fixes the problem
that you found. The changes are the additions in trans-decl.c.

OK for trunk and 7-branch?

Paul

2017-11-18  Paul Thomas  

PR fortran/78990
* expr.c (gfc_is_class_array_function): Renamed from
'gfc_is_alloc_class_array_function' and modified to return true
for pointers as well as allocatable results.
* gfortran.h : Change of name for prototype of above function.
* trans-array.c (gfc_add_loop_ss_code): Force finalization of
class array results.
(build_class_array_ref): Change assertion into a condition.
(build_class_array_ref): Set the se class_vptr for class array
function results.
(gfc_walk_function_expr): Reference gfc_is_class_array_function
as above.
* trans-decl.c (get_proc_result): Move it up before
gfc_trans_deferred_vars.
(gfc_trans_deferred_vars): Nullify explicit return class arrays
on entry.
* trans-expr.c (gfc_conv_class_to_class): Allow conversion of
class array functions that have an se class_vptr and use it
for the result vptr.
(gfc_conv_subref_array_arg): Rename reference to the above
function.
(gfc_conv_procedure_call): Ditto. Add the se pre block to the
loop pre block before the function is evaluated. Do not
finalize class pointer results.
(arrayfunc_assign_needs_temporary, gfc_trans_assignment_1) More
renamed references.
* trans-intrinsic.c (gfc_conv_intrinsic_size): Ditto.

2017-11-18  Paul Thomas  

PR fortran/78990
* gfortran.dg/class_67.f90: New test.


On 15 November 2017 at 11:40, Dominique d'Humières  wrote:
> Hi Paul,
>
> Your patch fixes the ICE and pass the tests. However I see
>
> At line 22 of file pr78990.f90
> Fortran runtime error: Attempting to allocate already allocated variable 
> ‘return_t1'
>
> for the original tests (with mold or source). This runtime error depends on 
> the options:
>
> % gfc pr78990.f90
> % a.out
> At line 22 of file pr78990.f90
> Fortran runtime error: Attempting to allocate already allocated variable 
> 'return_t1'
>
> Error termination. Backtrace:
> …
> % gfc pr78990.f90 -fno-backtrace
> % a.out
>0   0   0
> % gfc pr78990.f90 -m32
> % a.out
>0   0   0
> % gfc pr78990.f90 -O
> % a.out
>0   0   0
>
> The problem seems related to the line
>
>   print*,v2%i
>
> Cheers,
>
> Dominique
>
>



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Index: gcc/fortran/expr.c
===
*** gcc/fortran/expr.c  (revision 254626)
--- gcc/fortran/expr.c  (working copy)
*** gfc_is_alloc_class_scalar_function (gfc_
*** 4822,4835 
  /* Determine if an expression is a function with an allocatable class array
 result.  */
  bool
! gfc_is_alloc_class_array_function (gfc_expr *expr)
  {
if (expr->expr_type == EXPR_FUNCTION
&& expr->value.function.esym
&& expr->value.function.esym->result
&& expr->value.function.esym->result->ts.type == BT_CLASS
&& CLASS_DATA (expr->value.function.esym->result)->attr.dimension
!   && CLASS_DATA (expr->value.function.esym->result)->attr.allocatable)
  return true;
  
return false;
--- 4822,4836 
  /* Determine if an expression is a function with an allocatable class array
 result.  */
  bool
! gfc_is_class_array_function (gfc_expr *expr)
  {
if (expr->expr_type == EXPR_FUNCTION
&& expr->value.function.esym
&& expr->value.function.esym->result
&& expr->value.function.esym->result->ts.type == BT_CLASS
&& CLASS_DATA (expr->value.function.esym->result)->attr.dimension
!   && (CLASS_DATA (expr->value.function.esym->result)->attr.allocatable
! || CLASS_DATA (expr->value.function.esym->result)->attr.pointer))
  return true;
  
return false;
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h  (revision 254626)
--- gcc/fortran/gfortran.h  (working copy)
*** gfc_param_spec_type gfc_spec_list_type (
*** 3194,3200 
  gfc_component * gfc_get_proc_ptr_comp (gfc_expr *);
  bool gfc_is_proc_ptr_comp (gfc_expr *);
  bool gfc_is_alloc_class_scalar_function (gfc_expr *);
! bool gfc_is_alloc_class_array_function (gfc_expr *);
  
  bool gfc_ref_this_image (gfc_ref *ref);
  bool gfc_is_coindexed (gfc_expr *);
--- 3194,3200 
  gfc_component * gfc_get_proc_ptr_comp (gfc_expr *);
  bool gfc_is_proc_ptr_comp (gfc_expr *);
  bool gfc_is_alloc_class_scalar_function (gfc_expr *);
! bool gfc_is_class_array_function (gfc_expr *);
  
  bool gfc_ref_this_image (gfc_ref *ref);
  bool gfc_is_coindexed (gfc_expr *);
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 254626)
--- 

Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.

[Andreas Schwab]

In file included from ../../../libgcc/config/ia64/unwind-ia64.c:2448:
../../../libgcc/unwind.inc: In function '_Unwind_RaiseException':
../../../libgcc/unwind.inc:140:3: error: too many arguments to function 
'uw_install_context'
   uw_install_context (&this_context, &cur_context, frames);
   ^~
../../../libgcc/config/ia64/unwind-ia64.c:2167:1: note: declared here
 uw_install_context (struct _Unwind_Context *current __attribute__((unused)),
 ^~

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [006/nnn] poly_int: tree constants

[Richard Sandiford]

Jeff Law  writes:
> On 10/23/2017 11:00 AM, Richard Sandiford wrote:
>> This patch adds a tree representation for poly_ints.  Unlike the
>> rtx version, the coefficients are INTEGER_CSTs rather than plain
>> integers, so that we can easily access them as poly_widest_ints
>> and poly_offset_ints.
>> 
>> The patch also adjusts some places that previously
>> relied on "constant" meaning "INTEGER_CST".  It also makes
>> sure that the TYPE_SIZE agrees with the TYPE_SIZE_UNIT for
>> vector booleans, given the existing:
>> 
>>  /* Several boolean vector elements may fit in a single unit.  */
>>  if (VECTOR_BOOLEAN_TYPE_P (type)
>>  && type->type_common.mode != BLKmode)
>>TYPE_SIZE_UNIT (type)
>>  = size_int (GET_MODE_SIZE (type->type_common.mode));
>>  else
>>TYPE_SIZE_UNIT (type) = int_const_binop (MULT_EXPR,
>> TYPE_SIZE_UNIT (innertype),
>> size_int (nunits));
>> 
>> 
>> 2017-10-23  Richard Sandiford  
>>  Alan Hayward  
>>  David Sherwood  
>> 
>> gcc/
>>  * doc/generic.texi (POLY_INT_CST): Document.
>>  * tree.def (POLY_INT_CST): New tree code.
>>  * treestruct.def (TS_POLY_INT_CST): New tree layout.
>>  * tree-core.h (tree_poly_int_cst): New struct.
>>  (tree_node): Add a poly_int_cst field.
>>  * tree.h (POLY_INT_CST_P, POLY_INT_CST_COEFF): New macros.
>>  (wide_int_to_tree, force_fit_type): Take a poly_wide_int_ref
>>  instead of a wide_int_ref.
>>  (build_int_cst, build_int_cst_type): Take a poly_int64 instead
>>  of a HOST_WIDE_INT.
>>  (build_int_cstu, build_array_type_nelts): Take a poly_uint64
>>  instead of an unsigned HOST_WIDE_INT.
>>  (build_poly_int_cst, tree_fits_poly_int64_p, tree_fits_poly_uint64_p)
>>  (ptrdiff_tree_p): Declare.
>>  (tree_to_poly_int64, tree_to_poly_uint64): Likewise.  Provide
>>  extern inline implementations if the target doesn't use POLY_INT_CST.
>>  (poly_int_tree_p): New function.
>>  (wi::unextended_tree): New class.
>>  (wi::int_traits ): New override.
>>  (wi::extended_tree): Add a default constructor.
>>  (wi::extended_tree::get_tree): New function.
>>  (wi::widest_extended_tree, wi::offset_extended_tree): New typedefs.
>>  (wi::tree_to_widest_ref, wi::tree_to_offset_ref): Use them.
>>  (wi::tree_to_poly_widest_ref, wi::tree_to_poly_offset_ref)
>>  (wi::tree_to_poly_wide_ref): New typedefs.
>>  (wi::ints_for): Provide overloads for extended_tree and
>>  unextended_tree.
>>  (poly_int_cst_value, wi::to_poly_widest, wi::to_poly_offset)
>>  (wi::to_wide): New functions.
>>  (wi::fits_to_boolean_p, wi::fits_to_tree_p): Handle poly_ints.
>>  * tree.c (poly_int_cst_hasher): New struct.
>>  (poly_int_cst_hash_table): New variable.
>>  (tree_node_structure_for_code, tree_code_size, simple_cst_equal)
>>  (valid_constant_size_p, add_expr, drop_tree_overflow): Handle
>>  POLY_INT_CST.
>>  (initialize_tree_contains_struct): Handle TS_POLY_INT_CST.
>>  (init_ttree): Initialize poly_int_cst_hash_table.
>>  (build_int_cst, build_int_cst_type, build_invariant_address): Take
>>  a poly_int64 instead of a HOST_WIDE_INT.
>>  (build_int_cstu, build_array_type_nelts): Take a poly_uint64
>>  instead of an unsigned HOST_WIDE_INT.
>>  (wide_int_to_tree): Rename to...
>>  (wide_int_to_tree_1): ...this.
>>  (build_new_poly_int_cst, build_poly_int_cst): New functions.
>>  (force_fit_type): Take a poly_wide_int_ref instead of a wide_int_ref.
>>  (wide_int_to_tree): New function that takes a poly_wide_int_ref.
>>  (ptrdiff_tree_p, tree_to_poly_int64, tree_to_poly_uint64)
>>  (tree_fits_poly_int64_p, tree_fits_poly_uint64_p): New functions.
>>  * lto-streamer-out.c (DFS::DFS_write_tree_body, hash_tree): Handle
>>  TS_POLY_INT_CST.
>>  * tree-streamer-in.c (lto_input_ts_poly_tree_pointers): Likewise.
>>  (streamer_read_tree_body): Likewise.
>>  * tree-streamer-out.c (write_ts_poly_tree_pointers): Likewise.
>>  (streamer_write_tree_body): Likewise.
>>  * tree-streamer.c (streamer_check_handled_ts_structures): Likewise.
>>  * asan.c (asan_protect_global): Require the size to be an INTEGER_CST.
>>  * cfgexpand.c (expand_debug_expr): Handle POLY_INT_CST.
>>  * expr.c (const_vector_element, expand_expr_real_1): Likewise.
>>  * gimple-expr.h (is_gimple_constant): Likewise.
>>  * gimplify.c (maybe_with_size_expr): Likewise.
>>  * print-tree.c (print_node): Likewise.
>>  * tree-data-ref.c (data_ref_compare_tree): Likewise.
>>  * tree-pretty-print.c (dump_generic_node): Likewise.
>>  * tree-ssa-address.c (addr_for_mem_ref): Likewise.
>>  * tree-vect-data-refs.c (dr_group_sort_cmp): Likewise.
>>  * tree-vrp.c (compare_values_warnv): Likewise.
>>  * tree-ssa-loop-ivopts.c (determine_base_obj

Re: [PATCH] New lang hook

[Andreas Schwab]

FAIL: g++.dg/pr82836.C   (test for excess errors)
Excess errors:
/opt/gcc/gcc-20171118/gcc/testsuite/g++.dg/pr82836.C:13:3: error: '__float128' 
does not name a type; did you mean '__Float16x8_t'?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [patch, fortran] Fix PR 83012, rejects-valid regression with contiguous pointer

[Thomas Koenig]

Steve,


+ for (r = expr->ref; r; r = r->next)
+   if (r->type == REF_COMPONENT)
+ rc = r;


Should you have a break here?  As I understand it, you're walking a
list, so you could have r, r->next, r->next->next, and so on.   Is
it possible to have r->next->type = REF_COMPONENT and
r->next->next->type = REF_COMPONENT, where you end up with the wrong
one?


The point is to have the last of the r->next->next->next chain that
is a REF_COMPONENT (which I assign to rc, which I later use).

In the test case, it is indeed expr->ref->next that is of
interest, but there could be other references in between,
the type could be part of another type or there could be an
array reference - thus the loop, which should catch such
cases.

I tried to come up with a test case that breaks the patch, but I didn't
manage to do so.

Here's part of a debug session on the test case (breakpoint was in
gfc_is_simply_contiguous, the second time it was hit):

(gdb) p expr->ref->next.u.c.component
$13 = (gfc_component *) 0x23f1e90
(gdb) p expr->ref->next.u.c.component->ts.interface
$14 = (gfc_symbol *) 0x23ee510
(gdb) p expr->ref->next.u.c.component->ts.interface->attr.contiguous
$16 = 1

Regards

Thomas

Re: [PATCH] PR 44292 Enable large record lengths in OPEN and INQUIRE statements

[Thomas Koenig]

Hi Janne,


This is a straightforward change that we can do now that the ABI has
been bumped (again!).

Regtested on x86_64-pc-linux-gnu, Ok for trunk?


OK, and thanks.

Regards

Thomas

Re: [PATCH] Make NEXTREC specifier for INQUIRE work for large record numbers

[Thomas Koenig]

Hi Janne,


This is accomplished by making the NEXTREC specifier be a 8 byte
integer where supported.

I wasn't able to come up with a testcase that does not create a large
file that could be added to the testsuite, but here's one which
creates a 2 GB file:

I think the patch is OK (even obvious), also without a test case,
but maybe you could wait for a couple of days before committing to
give others a chance to chime in.

Regards

Thomas

Re: [PATCH] PR 44292 Enable large record lengths in OPEN and INQUIRE statements

[Janne Blomqvist]

On Sat, Nov 18, 2017 at 5:56 PM, Thomas Koenig  wrote:
> Hi Janne,
>
>> This is a straightforward change that we can do now that the ABI has
>> been bumped (again!).
>>
>> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>
>
> OK, and thanks.
>
> Regards
>
> Thomas

Thanks, committed as r254915. Though I did notice some places in the
I/O library where we're incorrectly using the int type, so while this
patch takes care of the ABI issue large RECL's don't actually work in
all cases yet. I'm preparing a patch to fix the issues I discovered.


-- 
Janne Blomqvist

Re: [PATCH] handle non-constant offsets in -Wstringop-overflow (PR 77608)

[Martin Sebor]

On 11/18/2017 12:53 AM, Jeff Law wrote:

On 11/17/2017 12:36 PM, Martin Sebor wrote:

The attached patch enhances -Wstringop-overflow to detect more
instances of buffer overflow at compile time by handling non-
constant offsets into the destination object that are known to
be in some range.  The solution could be improved by handling
even more cases (e.g., anti-ranges or offsets relative to
pointers beyond the beginning of an object) but it's a start.


I should have made it even more clear that this change affects
just warnings, not the runtime protection with _FORTIFY_SOURCE.
The latter is driven by the __builtin_object_size intrinsic and
by the compute_builtin_object_size GCC function.

This patch does not change what __builtin_object_size returns.


In addition to bootsrapping/regtesting GCC, also tested with
Binutils/GDB, Glibc, and the Linux kernel on x86_64 with no
regressions.

Martin

The top of GDB fails to compile at the moment so the validation
there was incomplete.

gcc-77608.diff


PR middle-end/77608 - missing protection on trivially detectable runtime buffer 
overflow

gcc/ChangeLog:

PR middle-end/77608
* builtins.c (compute_objsize): Handle non-constant offsets.

gcc/testsuite/ChangeLog:

PR middle-end/77608
* gcc.dg/Wstringop-overflow.c: New test.

The recursive call into compute_objsize passing in the ostype avoids
having to think about the whole object vs nearest containing object
issues.  Right?


Yes, something like that.


What's left to worry about is maximum or minimum remaining bytes in the
object.  At least that's my understanding of how ostype works here.


-Wstringop-overflow (i.e., warnings only) always uses the largest
object size for memxxx functions (type 0) and the smallest (type
2) for string functions by default.  This can be changed but I
suspect no one does because (IME) few users understand what
the other modes mean or what good using them vs the default might
do.  It was probably a mistake to expose the mode via the option.

I'll address the remaining comments separately.

Martin

Re: [PATCH libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values

[Ed Smith-Rowland]

On 11/17/2017 03:54 PM, Jonathan Wakely wrote:


Hmm, you're probably right. I'd be tempted to though.

I had an idea.  What about a macro _GLIBCXX_ELLINT_3_POS_NU or something 
that:


1. would allow users to detect which convention is on by default.

2. They could set or unset to get the other convention.

It's bloody but it would work.  it would prevent users from having to 
test the compiler version and guess or check the value every time.


I feel that distros are likely to pick up gcc-7 soon and I'd like to do 
*something*.  This would be something of a transition path.


Ed

Re: [PATCH] Make NEXTREC specifier for INQUIRE work for large record numbers

[Janne Blomqvist]

On Sat, Nov 18, 2017 at 6:00 PM, Thomas Koenig  wrote:
> Hi Janne,
>
>> This is accomplished by making the NEXTREC specifier be a 8 byte
>> integer where supported.
>>
>> I wasn't able to come up with a testcase that does not create a large
>> file that could be added to the testsuite, but here's one which
>> creates a 2 GB file:
>
> I think the patch is OK (even obvious), also without a test case,
> but maybe you could wait for a couple of days before committing to
> give others a chance to chime in.

Thanks, committed as r254916. Since this changes the libgfortran ABI,
I wanted to get this in at the same time as the PR 44292 patch, so
people have to rebuild everything only once (yes, this is trunk, but
still). If somebody comes up with a way to test this without a huge
file, we can add such a testcase later.


-- 
Janne Blomqvist

Re: [RFC][PATCH. CSE. rs6000] Update CSE to handle involutory operations

[Peter Bergner]

On 11/18/17 12:16 AM, Jeff Law wrote:
> You might wander a bit and see if/how cse handles other similar
> circumstances.  For example (not (not (x))  (neg (neg x)) and (bswap
> (bswap (x))

I actually tried examples like that to see what CSE would do, but I
could never come up with a test case, where those would survive until
CSE.  I suppose I could try disabling the optimizations that remove
them before CSE to see what happens, but...



> THe last would seem particularly interesting -- as a hack see if you can
> generate a bswap instead of vec_select at expansion time, then see if
> CSE is able to fix it up.  Or perhaps set it as a REG_EQUAL note.
> Again, it's a hack, but you just want to see if CSE can see the
> equivalence if it's in a more common form.  Though I'm not sure if BSWAP
> is handled significantly better than an equivalence VEC_SELECT.

...the problem is that CSE only creates equivalences between two
expressions when one is assigned to the other.  It doesn't seem to
look deeper into the expressions to try and find other equivalences,
so even if we see A = (not (not (B))), the only equivalence it makes
is that one.  We don't get A is equivalent to B.


Do you have any input on the following hunk, which seems to be an
independent change to the rest of the patch?

@@ -2640,7 +2699,7 @@ exp_equiv_p (const_rtx x, const_rtx y, i
return 1;

  for (i = regno; i < endregno; i++)
-   if (REG_IN_TABLE (i) != REG_TICK (i))
+   if (REG_IN_TABLE (i) != -1 && REG_IN_TABLE (i) != REG_TICK (i))
  return 0;


Peter

[Patch, fortran] PR79072 - ICE with class(*) pointer function result and character value

[Paul Richard Thomas]

Dear All,

This is not quite an 'obvious' patch but it does speak for itself. If
there are no objections in the meantime, I will commit it tomorrow
evening.

Bootstraps and regtests on FC23/x86_64 - OK for trunk? What about 7-branch?

Cheers

Paul

2017-11-18  Paul Thomas  

PR fortran/79072
* trans-expr.c (trans_class_vptr_len_assignment): Set from_len
if the temporary is unlimited polymorphic.
* trans-stmt.c (trans_associate_var): Use the fake result decl
to obtain the 'len' field from an explicit function result when
in that function scope.

2017-11-18  Paul Thomas  

PR fortran/79072
* gfortran.dg/class_result_5.f90: New test.
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 254626)
--- gcc/fortran/trans-expr.c(working copy)
*** trans_class_vptr_len_assignment (stmtblo
*** 8115,8120 
--- 8115,8122 
{
  vptr_expr = NULL;
  se.expr = gfc_class_vptr_get (rse->expr);
+ if (UNLIMITED_POLY (re))
+   from_len = gfc_class_len_get (rse->expr);
}
  else if (re->expr_type != EXPR_NULL)
/* Only when rhs is non-NULL use its declared type for vptr
Index: gcc/fortran/trans-stmt.c
===
*** gcc/fortran/trans-stmt.c(revision 254626)
--- gcc/fortran/trans-stmt.c(working copy)
*** trans_associate_var (gfc_symbol *sym, gf
*** 1827,1832 
--- 1827,1839 
  gcc_assert (!e->symtree->n.sym->ts.deferred);
  tmp = e->symtree->n.sym->ts.u.cl->backend_decl;
}
+   else if (e->symtree->n.sym->attr.function
+  && e->symtree->n.sym == e->symtree->n.sym->result
+  && e->symtree->n.sym == e->symtree->n.sym->ns->proc_name)
+   {
+ tmp = gfc_get_fake_result_decl (e->symtree->n.sym, 0);
+ tmp = gfc_class_len_get (tmp);
+   }
else
tmp = gfc_class_len_get (gfc_get_symbol_decl (e->symtree->n.sym));
gfc_get_symbol_decl (sym);
Index: gcc/testsuite/gfortran.dg/class_result_5.f90
===
*** gcc/testsuite/gfortran.dg/class_result_5.f90(nonexistent)
--- gcc/testsuite/gfortran.dg/class_result_5.f90(working copy)
***
*** 0 
--- 1,38 
+ ! { dg-do run }
+ !
+ ! Test the fix for PR79072. The original problem was that an ICE
+ ! would occur in the select type construct. On fixing that, it was
+ ! found that the string length was not being transferred in the
+ ! pointer assignment in the main program.
+ !
+ ! Contributed by Neil Carlson  
+ !
+ function foo(string)
+   class(*), pointer :: foo
+   character(3), target :: string
+   foo => string
+   select type (foo)
+ type is (character(*))
+   if (foo .ne. 'foo') call abort
+   foo = 'bar'
+   end select
+ end function
+ 
+   interface
+ function foo(string)
+   class(*), pointer :: foo
+   character(3), target :: string
+ end function
+   end interface
+ 
+   class(*), pointer :: res
+   character(3), target :: string = 'foo'
+ 
+   res => foo (string)
+ 
+   select type (res)
+ type is (character(*))
+   if (res .ne. 'bar') call abort
+   end select
+   if (string .ne. 'bar') call abort
+ end

Re: Fix IPA profile updates in inlining and ipa-split

[Jan Hubicka]

> On 2017.11.18 at 00:39 +0100, Jan Hubicka wrote:
> > Hi,
> > this patch fixes remaining IPA profile updating issues I am aware of.  With
> > this change there is 1 profile mismatch after inlining for tramp3d -Ofast
> > and 112 of them in .optimized dump which is about 10 times less than before.
> > I did not inspect them all but they seems mostly justified and not very
> > important.
> > 
> > First patch adds new profile quality stage when global profile is 0 but not
> > known precisely.  This is useful for bb partitioning where we do not want to
> > move adjusted 0 to cold sections.
> > 
> > Second the patch adds little infrastructure for turning IPA info to local
> > info (profile_count::combine_with_ipa_count) and commonizes all places that
> > do this kind of operation.
> > 
> > Finally it fixes profile updating bug in ipa-split where entry and return
> > blocks got wrong profile.
> > 
> > Bootstrapped/regtested x86_64-linux. I am profilebootstrapping overnight
> > and plan to commit tomorrow.
> 
> This fixes the tramp3d compile time regression with LTO/PGO bootstrapped
> gcc, that I have reported earlier. 
> In fact gcc-8 now compiles tramp3d-v4 ~8.5% faster than gcc-7.
> 
> The patch also fixes PR83037 and PR83039.

Thanks, I will commit it soonish (my overnight profiledbootstrap with lto
died on disk space and I was on hike).

I still plan to check for more profile updating errors and do re-tunning of
inliner next, it is good to know there are fewer issues to look at. :)

Honza

> 
> -- 
> Markus

Re: [PATCH] Make NEXTREC specifier for INQUIRE work for large record numbers

[Jerry DeLisle]

On 11/18/2017 08:59 AM, Janne Blomqvist wrote:
> On Sat, Nov 18, 2017 at 6:00 PM, Thomas Koenig  wrote:
>> Hi Janne,
>>
>>> This is accomplished by making the NEXTREC specifier be a 8 byte
>>> integer where supported.
>>>
>>> I wasn't able to come up with a testcase that does not create a large
>>> file that could be added to the testsuite, but here's one which
>>> creates a 2 GB file:
>>
>> I think the patch is OK (even obvious), also without a test case,
>> but maybe you could wait for a couple of days before committing to
>> give others a chance to chime in.
> 
> Thanks, committed as r254916. Since this changes the libgfortran ABI,
> I wanted to get this in at the same time as the PR 44292 patch, so
> people have to rebuild everything only once (yes, this is trunk, but
> still). If somebody comes up with a way to test this without a huge
> file, we can add such a testcase later.
> 
> 

Yes OK.

We could consider setting up an automatic testing machine somewhere that not
only does the usual test-suite, but also tests the unusual things like this. For
example, I had a test case which died when launched with more than 32 threads
for example. Not every machine or architecture could do that so I do not have a
test case for it.

Another example is the NIST tests which we run manually via a script.

Regardless, this machine could also issue an email to the gfortran list when
ever a new failure is discovered. We could do it so it does not repeat the email
every day, just a report of new and a report of problem went away.

Just a thought.

Jerry

Re: [wwwdocs] Document Nios II changes for GCC 8

[Gerald Pfeifer]

On Sun, 29 Oct 2017, Sandra Loosemore wrote:
I've checked in this patch to document my recent flurry of Nios II 
patches in the release notes for GCC 8.


Thank you!


The Nios II back end has been improved to generate better-optimized
code.  Changes include switching to LRA, more accurate cost models,
and more compact code for addressing static variables.


"better-optimized" with a dash, isn't that a bit German where we 
have words like Zugführerkontrollleuchtenschalter? ;-)


LRA has not been used inthat note so far.  Would it be appropriate
to say something like "LRA (a new local register allocator)" instead?

(This is what we do in gcc-7/changes.html the first time LRA is
referred to.)


New command-line options -mgprel-sec= and
-mr0rel-sec= have been added.


Would it make sense to hint what these options are about (which
areas they cover)?

Gerald

Re: [PATCH] Make NEXTREC specifier for INQUIRE work for large record numbers

[Thomas Koenig]

We could consider setting up an automatic testing machine somewhere that not
only does the usual test-suite, but also tests the unusual things like this. For
example, I had a test case which died when launched with more than 32 threads
for example. Not every machine or architecture could do that so I do not have a
test case for it.


One of the big machines from the compile farm could do this, such as
gcc110 (a POWER7 that I use a lot for development) or gcc112 (a 160 core
machine).

Regards

Thomas

[PATCH] PR 44292 Handle large record lengths

[Janne Blomqvist]

Now that the ABI supports large record lengths, there's a few places
in libgfortran where we need to use larger types. For internal units
which by definition are in-memory, it's enought to use ptrdiff_t, for
external units gfc_offset.

Regtested on x86_64-pc-linux-gnu, Ok for trunk?

libgfortran/ChangeLog:

2017-11-18  Janne Blomqvist  

* io/transfer.c (skip_record): Use gfc_offset to handle large
records.
(next_record_r): Likewise.
(sset): Likewise.
(next_record_w): Use gfc_offset/ptrdiff_t appropriately.
---
 libgfortran/io/transfer.c | 37 -
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 5296370..c173447 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -3290,7 +3290,7 @@ next_array_record (st_parameter_dt *dtp, array_loop_spec 
*ls, int *finished)
position.  */
 
 static void
-skip_record (st_parameter_dt *dtp, ssize_t bytes)
+skip_record (st_parameter_dt *dtp, gfc_offset bytes)
 {
   ssize_t rlength, readb;
 #define MAX_READ 4096
@@ -3367,7 +3367,6 @@ static void
 next_record_r (st_parameter_dt *dtp, int done)
 {
   gfc_offset record;
-  int bytes_left;
   char p;
   int cc;
 
@@ -3419,7 +3418,7 @@ next_record_r (st_parameter_dt *dtp, int done)
}
  else
{
- bytes_left = (int) dtp->u.p.current_unit->bytes_left;
+ gfc_offset bytes_left = dtp->u.p.current_unit->bytes_left;
  bytes_left = min_off (bytes_left,
  ssize (dtp->u.p.current_unit->s)
  - stell (dtp->u.p.current_unit->s));
@@ -3590,12 +3589,13 @@ next_record_w_unf (st_parameter_dt *dtp, int 
next_subrecord)
 /* Utility function like memset() but operating on streams. Return
value is same as for POSIX write().  */
 
-static ssize_t
-sset (stream *s, int c, ssize_t nbyte)
+static gfc_offset
+sset (stream *s, int c, gfc_offset nbyte)
 {
 #define WRITE_CHUNK 256
   char p[WRITE_CHUNK];
-  ssize_t bytes_left, trans;
+  gfc_offset bytes_left;
+  ssize_t trans;
 
   if (nbyte < WRITE_CHUNK)
 memset (p, c, nbyte);
@@ -3645,11 +3645,10 @@ next_record_cc (st_parameter_dt *dtp)
 static void
 next_record_w (st_parameter_dt *dtp, int done)
 {
-  gfc_offset m, record, max_pos;
-  int length;
+  gfc_offset max_pos_off;
 
   /* Zero counters for X- and T-editing.  */
-  max_pos = dtp->u.p.max_pos;
+  max_pos_off = dtp->u.p.max_pos;
   dtp->u.p.max_pos = dtp->u.p.skips = dtp->u.p.pending_spaces = 0;
 
   switch (current_mode (dtp))
@@ -3674,7 +3673,7 @@ next_record_w (st_parameter_dt *dtp, int done)
 case UNFORMATTED_DIRECT:
   if (dtp->u.p.current_unit->bytes_left > 0)
{
- length = (int) dtp->u.p.current_unit->bytes_left;
+ gfc_offset length = dtp->u.p.current_unit->bytes_left;
  if (sset (dtp->u.p.current_unit->s, 0, length) != length)
goto io_error;
}
@@ -3691,11 +3690,14 @@ next_record_w (st_parameter_dt *dtp, int done)
   if (is_internal_unit (dtp))
{
  char *p;
+ /* Internal unit, so must fit in memory.  */
+ ptrdiff_t length, m, record;
+ ptrdiff_t max_pos = max_pos_off;
  if (is_array_io (dtp))
{
  int finished;
 
- length = (int) dtp->u.p.current_unit->bytes_left;
+ length = dtp->u.p.current_unit->bytes_left;
 
  /* If the farthest position reached is greater than current
  position, adjust the position and set length to pad out
@@ -3705,14 +3707,14 @@ next_record_w (st_parameter_dt *dtp, int done)
- dtp->u.p.current_unit->bytes_left;
  if (max_pos > m)
{
- length = (int) (max_pos - m);
+ length = (max_pos - m);
  if (sseek (dtp->u.p.current_unit->s,
 length, SEEK_CUR) < 0)
{
  generate_error (&dtp->common, LIBERROR_INTERNAL_UNIT, 
NULL);
  return;
}
- length = (int) (dtp->u.p.current_unit->recl - max_pos);
+ length = ((ptrdiff_t) dtp->u.p.current_unit->recl - max_pos);
}
 
  p = write_block (dtp, length);
@@ -3735,7 +3737,7 @@ next_record_w (st_parameter_dt *dtp, int done)
dtp->u.p.current_unit->endfile = AT_ENDFILE;
 
  /* Now seek to this record */
- record = record * dtp->u.p.current_unit->recl;
+ record = record * ((ptrdiff_t) dtp->u.p.current_unit->recl);
 
  if (sseek (dtp->u.p.current_unit->s, record, SEEK_SET) < 0)
{
@@ -3758,17 +3760,18 @@ next_record_w (st_parameter_dt *dtp, int done)
- dtp->u.p.current_unit->bytes_left;
  if (max_pos > m)
{
- length 

RE: [PATCH 08/22] Add Intel CET support for EH in libgcc.

[Tsimbalist, Igor V]

I propose the following changes. I do not have ia64 to test. Ok for trunk?

bash-4.2$ svn diff
Index: libgcc/config/cr16/unwind-cr16.c
===
--- libgcc/config/cr16/unwind-cr16.c(revision 254908)
+++ libgcc/config/cr16/unwind-cr16.c(working copy)
@@ -1567,7 +1567,7 @@
our caller.  */
 #if defined( __CR16C__ )

-#define uw_install_context(CURRENT, TARGET)\
+#define uw_install_context(CURRENT, TARGET, FRAMES)\
   do   \
 {  \
   long offset = uw_install_context_1 ((CURRENT), (TARGET));
\
@@ -1578,7 +1578,7 @@
 }  \
   while (0)
 #else
-#define uw_install_context(CURRENT, TARGET) \
+#define uw_install_context(CURRENT, TARGET, FRAMES) \
   do\
 {   \
   long offset = uw_install_context_1 ((CURRENT), (TARGET)); \
Index: libgcc/config/ia64/unwind-ia64.c
===
--- libgcc/config/ia64/unwind-ia64.c(revision 254908)
+++ libgcc/config/ia64/unwind-ia64.c(working copy)
@@ -2165,7 +2165,8 @@

 static void __attribute__((noreturn))
 uw_install_context (struct _Unwind_Context *current __attribute__((unused)),
-   struct _Unwind_Context *target)
+   struct _Unwind_Context *target,
+   unsigned long frames __attribute__((unused)))
 {
   unw_word ireg_buf[4], ireg_nat = 0, ireg_pr = 0;
   unw_word saved_lc;
Index: libgcc/config/xtensa/unwind-dw2-xtensa.c
===
--- libgcc/config/xtensa/unwind-dw2-xtensa.c(revision 254908)
+++ libgcc/config/xtensa/unwind-dw2-xtensa.c(working copy)
@@ -483,7 +483,7 @@
macro because __builtin_eh_return must be invoked in the context of
our caller.  */

-#define uw_install_context(CURRENT, TARGET) \
+#define uw_install_context(CURRENT, TARGET, FRAMES)
 \
   do\
 {   \
   long offset = uw_install_context_1 ((CURRENT), (TARGET));
 \
Index: libgcc/unwind-sjlj.c
===
--- libgcc/unwind-sjlj.c(revision 254908)
+++ libgcc/unwind-sjlj.c(working copy)
@@ -300,7 +300,8 @@

 static void __attribute__((noreturn))
 uw_install_context (struct _Unwind_Context *current __attribute__((unused)),
-struct _Unwind_Context *target)
+struct _Unwind_Context *target,
+   unsigned long frames __attribute__((unused)))
 {
   _Unwind_SjLj_SetContext (target->fc);
   longjmp (target->fc->jbuf, 1);


Igor

> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: Saturday, November 18, 2017 2:51 PM
> To: Tsimbalist, Igor V 
> Cc: Jeff Law ; gcc-patches@gcc.gnu.org; i...@airs.com
> Subject: Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.
> 
> In file included from ../../../libgcc/config/ia64/unwind-ia64.c:2448:
> ../../../libgcc/unwind.inc: In function '_Unwind_RaiseException':
> ../../../libgcc/unwind.inc:140:3: error: too many arguments to function
> 'uw_install_context'
>uw_install_context (&this_context, &cur_context, frames);
>^~
> ../../../libgcc/config/ia64/unwind-ia64.c:2167:1: note: declared here
>  uw_install_context (struct _Unwind_Context *current
> __attribute__((unused)),
>  ^~
> 
> Andreas.
> 
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

Re: [PATCH] PR 44292 Handle large record lengths

[Jerry DeLisle]

On 11/18/2017 11:55 AM, Janne Blomqvist wrote:
> Now that the ABI supports large record lengths, there's a few places
> in libgfortran where we need to use larger types. For internal units
> which by definition are in-memory, it's enought to use ptrdiff_t, for
> external units gfc_offset.
> 
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
> 

Looks OK, thanks,

Jerry

[vms, committed] Add missing vmsdbgout_early_finish

[Tom de Vries]

Hi,

atm, any build for vms os will fail early in libgcc.

dwarf2_debug_hooks.early_finish needs to be called before 
dwarf2_debug_hooks.finish.


However, while vmsdbgout_finish calls dwarf2_debug_hooks.finish there's 
no vmsdbgout_early_finish, and dwarf2_debug_hooks.early_finish is not 
called otherwise.


This patch fixes that, by adding vmsdbgout_early_finish calling 
dwarf2_debug_hooks.early_finish.


I don't have a setup to build and test for vms os. I've built this for 
alpha-dec-vms as far as I can, which is until:

...
src/libgcc/config/alpha/vms-gcc_shell_handler.c:32:10: fatal error: 
vms/chfdef.h: No such file or directory

...

Approved at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82961#c8 .

Committed to trunk.

This is a 6/7 regression, but I'm somewhat reluctant to check this into 
release branches without proper build and test (though checking it in 
will probably unbreak the build).


Thanks,
- Tom
[vms] Add missing vmsdbgout_early_finish

2017-11-18  Tom de Vries  

	PR target/82961
	* vmsdbgout.c (vmsdbgout_early_finish): New function.
	(vmsdbg_debug_hooks): Set early_finish field to vmsdbgout_early_finish.

---
 gcc/vmsdbgout.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gcc/vmsdbgout.c b/gcc/vmsdbgout.c
index 580dd28..91dcd2e 100644
--- a/gcc/vmsdbgout.c
+++ b/gcc/vmsdbgout.c
@@ -147,6 +147,7 @@ static int write_srccorrs (int);
 
 static void vmsdbgout_init (const char *);
 static void vmsdbgout_finish (const char *);
+static void vmsdbgout_early_finish (const char *);
 static void vmsdbgout_assembly_start (void);
 static void vmsdbgout_define (unsigned int, const char *);
 static void vmsdbgout_undef (unsigned int, const char *);
@@ -176,7 +177,7 @@ static void vmsdbgout_abstract_function (tree);
 const struct gcc_debug_hooks vmsdbg_debug_hooks
 = {vmsdbgout_init,
vmsdbgout_finish,
-   debug_nothing_charstar,
+   vmsdbgout_early_finish,
vmsdbgout_assembly_start,
vmsdbgout_define,
vmsdbgout_undef,
@@ -1556,6 +1557,13 @@ vmsdbgout_abstract_function (tree decl)
 (*dwarf2_debug_hooks.outlining_inline_function) (decl);
 }
 
+static void
+vmsdbgout_early_finish (const char *filename)
+{
+  if (write_symbols == VMS_AND_DWARF2_DEBUG)
+(*dwarf2_debug_hooks.early_finish) (filename);
+}
+
 /* Output stuff that Debug requires at the end of every file and generate the
VMS Debug debugging info.  */
 

[v3 PATCH] Implement LWG 2353

[Ville Voutilainen]

The issue submission talks about ranges that have InputIterators
as their iterator type. Even without any such range types, the added
test more or less shows that it's draconian to require a ForwardIterator
in std::next, since it seems perfectly reasonable to be able to std::next()
an iterator of an istream.

Testing on Linux-PPC64, ok for trunk if the full suite passes?

2017-11-19  Ville Voutilainen  

Implement LWG 2353
* include/bits/stl_iterator_base_funcs.h (next):
Use InputIterator instead of ForwardIterator.
* testsuite/24_iterators/operations/lwg2353.cc: New.
* testsuite/24_iterators/operations/next_neg.cc: Remove.
diff --git a/libstdc++-v3/include/bits/stl_iterator_base_funcs.h 
b/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
index 86a93d3..ad84b39 100644
--- a/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
+++ b/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
@@ -208,14 +208,13 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
 
 #if __cplusplus >= 201103L
 
-  template
-inline _GLIBCXX17_CONSTEXPR _ForwardIterator
-next(_ForwardIterator __x, typename
-iterator_traits<_ForwardIterator>::difference_type __n = 1)
+  template
+inline _GLIBCXX17_CONSTEXPR _InputIterator
+next(_InputIterator __x, typename
+iterator_traits<_InputIterator>::difference_type __n = 1)
 {
   // concept requirements
-  __glibcxx_function_requires(_ForwardIteratorConcept<
- _ForwardIterator>)
+  __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
   std::advance(__x, __n);
   return __x;
 }
diff --git a/libstdc++-v3/testsuite/24_iterators/operations/lwg2353.cc 
b/libstdc++-v3/testsuite/24_iterators/operations/lwg2353.cc
new file mode 100644
index 000..4ce4077
--- /dev/null
+++ b/libstdc++-v3/testsuite/24_iterators/operations/lwg2353.cc
@@ -0,0 +1,26 @@
+// { dg-options "-D_GLIBCXX_CONCEPT_CHECKS" }
+// { dg-do run { target c++11 } }
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+template
+auto
+drop(Distance n, InputRange& rng)
+{
+  return std::make_pair(std::next(std::istream_iterator(rng), n),
+   std::istream_iterator()
+   );
+}
+
+int main()
+{
+std::stringstream x("let let there be rock");
+x << std::noskipws;
+auto y = drop(4, x);
+std::string z(y.first, y.second);
+VERIFY(z == "let there be rock");
+}
diff --git a/libstdc++-v3/testsuite/24_iterators/operations/next_neg.cc 
b/libstdc++-v3/testsuite/24_iterators/operations/next_neg.cc
deleted file mode 100644
index f3c20a1..000
--- a/libstdc++-v3/testsuite/24_iterators/operations/next_neg.cc
+++ /dev/null
@@ -1,42 +0,0 @@
-// Copyright (C) 2015-2017 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library.  This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 3, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING3.  If not see
-// .
-
-// { dg-options "-D_GLIBCXX_CONCEPT_CHECKS" }
-// { dg-do compile { target c++11 } }
-
-#include 
-
-struct X {};
-
-namespace std
-{
-  template<>
-struct iterator_traits : iterator_traits
-{
-  using iterator_category = input_iterator_tag;
-  using reference = const X&;
-  using pointer = const X*;
-};
-}
-
-void
-test01()
-{
-  const X array[1] = { };
-  std::next(array);
-  // { dg-error "input_iterator" "" { target *-*-* } 220 }
-}

Re: [v3 PATCH] Implement LWG 2353

[Ville Voutilainen]

On 19 November 2017 at 02:40, Ville Voutilainen
 wrote:
> The issue submission talks about ranges that have InputIterators
> as their iterator type. Even without any such range types, the added
> test more or less shows that it's draconian to require a ForwardIterator
> in std::next, since it seems perfectly reasonable to be able to std::next()
> an iterator of an istream.
>
> Testing on Linux-PPC64, ok for trunk if the full suite passes?

The test run is squeaky clean and verified to have run the added test.

Re: [libstdc++] Expose Airy functions.

[Ed Smith-Rowland]

Here is the final patch fir libstdc++ Airy functions...

2017-11-18  Edward Smith-Rowland  <3dw...@verizon.net>

* include/bits/specfun.h: Expose airy_ai and airy_bi.
* include/tr1/modified_bessel_func.tcc: Treat NaN and inf arg, return.
* testsuite/ext/special_functions/airy_ai/check_nan.cc: New.
* testsuite/ext/special_functions/airy_ai/check_value.cc: New.
* testsuite/ext/special_functions/airy_ai/compile.cc: New.
* testsuite/ext/special_functions/airy_bi/check_nan.cc: New.
* testsuite/ext/special_functions/airy_bi/check_value.cc: New.
* testsuite/ext/special_functions/airy_bi/compile.cc: New.
Index: include/bits/specfun.h
===
--- include/bits/specfun.h	(revision 254915)
+++ include/bits/specfun.h	(working copy)
@@ -1206,6 +1206,78 @@
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+  // Airy functions
+
+  /**
+   * Return the Airy function @f$ Ai(x) @f$ of @c float argument x.
+   */
+  inline float
+  airy_aif(float __x)
+  {
+float __Ai, __Bi, __Aip, __Bip;
+std::__detail::__airy(__x, __Ai, __Bi, __Aip, __Bip);
+return __Ai;
+  }
+
+  /**
+   * Return the Airy function @f$ Ai(x) @f$ of long double argument x.
+   */
+  inline long double
+  airy_ail(long double __x)
+  {
+long double __Ai, __Bi, __Aip, __Bip;
+std::__detail::__airy(__x, __Ai, __Bi, __Aip, __Bip);
+return __Ai;
+  }
+
+  /**
+   * Return the Airy function @f$ Ai(x) @f$ of real argument x.
+   */
+  template
+inline typename __gnu_cxx::__promote<_Tp>::__type
+airy_ai(_Tp __x)
+{
+  typedef typename __gnu_cxx::__promote<_Tp>::__type __type;
+  __type __Ai, __Bi, __Aip, __Bip;
+  std::__detail::__airy<__type>(__x, __Ai, __Bi, __Aip, __Bip);
+  return __Ai;
+}
+
+  /**
+   * Return the Airy function @f$ Bi(x) @f$ of @c float argument x.
+   */
+  inline float
+  airy_bif(float __x)
+  {
+float __Ai, __Bi, __Aip, __Bip;
+std::__detail::__airy(__x, __Ai, __Bi, __Aip, __Bip);
+return __Bi;
+  }
+
+  /**
+   * Return the Airy function @f$ Bi(x) @f$ of long double argument x.
+   */
+  inline long double
+  airy_bil(long double __x)
+  {
+long double __Ai, __Bi, __Aip, __Bip;
+std::__detail::__airy(__x, __Ai, __Bi, __Aip, __Bip);
+return __Bi;
+  }
+
+  /**
+   * Return the Airy function @f$ Bi(x) @f$ of real argument x.
+   */
+  template
+inline typename __gnu_cxx::__promote<_Tp>::__type
+airy_bi(_Tp __x)
+{
+  typedef typename __gnu_cxx::__promote<_Tp>::__type __type;
+  __type __Ai, __Bi, __Aip, __Bip;
+  std::__detail::__airy<__type>(__x, __Ai, __Bi, __Aip, __Bip);
+  return __Bi;
+}
+
   // Confluent hypergeometric functions
 
   /**
Index: include/tr1/modified_bessel_func.tcc
===
--- include/tr1/modified_bessel_func.tcc	(revision 254915)
+++ include/tr1/modified_bessel_func.tcc	(working copy)
@@ -377,9 +377,20 @@
   const _Tp __absx = std::abs(__x);
   const _Tp __rootx = std::sqrt(__absx);
   const _Tp __z = _Tp(2) * __absx * __rootx / _Tp(3);
+  const _Tp _S_NaN = std::numeric_limits<_Tp>::quiet_NaN();
+  const _Tp _S_inf = std::numeric_limits<_Tp>::infinity();
 
-  if (__x > _Tp(0))
+  if (__isnan(__x))
+__Bip = __Aip = __Bi = __Ai = std::numeric_limits<_Tp>::quiet_NaN();
+  else if (__z == _S_inf)
 {
+	  __Aip = __Ai = _Tp{0};
+	  __Bip = __Bi = _S_inf;
+	}
+  else if (__z == -_S_inf)
+	__Bip = __Aip = __Bi = __Ai = _Tp{0};
+  else if (__x > _Tp(0))
+{
   _Tp __I_nu, __Ip_nu, __K_nu, __Kp_nu;
 
   __bessel_ik(_Tp(1) / _Tp(3), __z, __I_nu, __K_nu, __Ip_nu, __Kp_nu);
Index: include/tr1/modified_bessel_func.tcc
===
--- include/tr1/modified_bessel_func.tcc	(revision 254915)
+++ include/tr1/modified_bessel_func.tcc	(working copy)
@@ -377,9 +377,20 @@
   const _Tp __absx = std::abs(__x);
   const _Tp __rootx = std::sqrt(__absx);
   const _Tp __z = _Tp(2) * __absx * __rootx / _Tp(3);
+  const _Tp _S_NaN = std::numeric_limits<_Tp>::quiet_NaN();
+  const _Tp _S_inf = std::numeric_limits<_Tp>::infinity();
 
-  if (__x > _Tp(0))
+  if (__isnan(__x))
+__Bip = __Aip = __Bi = __Ai = std::numeric_limits<_Tp>::quiet_NaN();
+  else if (__z == _S_inf)
 {
+	  __Aip = __Ai = _Tp{0};
+	  __Bip = __Bi = _S_inf;
+	}
+  else if (__z == -_S_inf)
+	__Bip = __Aip = __Bi = __Ai = _Tp{0};
+  else if (__x > _Tp(0))
+{
   _Tp __I_nu, __Ip_nu, __K_nu, __Kp_nu;
 
   __bessel_ik(_Tp(1) / _Tp(3), __z, __I_nu, __K_nu, __Ip_nu, __Kp_nu);
Index: testsuite/ext/special_functions/airy_ai/check_nan.cc
===
--- testsuite/ext/special_functions/airy_ai/check_nan.cc	(nonexistent)
+++ testsuite/ext/special

Re: [RFC][PATCH] Change default to -fcommon

[Sandra Loosemore]

On 11/17/2017 12:12 PM, Wilco Dijkstra wrote:

GCC currently defaults to -fcommon.  This is an optional C feature dating
back to early C implementations.  On many targets this means global variable
accesses having an unnecessary codesize and performance penalty in C code
(the same source generates better code when built as C++).  Given there isn't
a lot of software that really requires this (mostly it's accidentally 
forgetting to
use 'extern' in a header), it is about time to change the default.

What do people think? I presume someone with access to distro source code
and a fast build machine could try and see how many packages fail to get an
idea how feasible it is. We could keep defaulting to -fcommon with -std=c89
if necessary.

2017-11-17  Wilco Dijkstra  

* common.opt (fcommon): Change init to 1.
* doc/invoke.texi (-fcommon): Update documentation.


The doc parts of this patch are OK.

Personally, I think the change is a good idea, but I don't know how much 
breakage it would cause.  One data point I can contribute is that when 
we looked at this several years ago, we found that all competing 
compilers on bare-metal targets implemented the -fno-common behavior. 
So another possible compromise is keeping -fcommon on Unix-like targets 
where it is the traditional behavior, and switching to -fno-common 
elsewhere where it's not.  I don't see much benefit in tying the default 
to -std= since it's not behavior specified in the C standard at all.


-Sandra