Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

[Sebastian Huber]

I checked in the following:

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=240387

All m68k BSPs build and link the samples using RTEMS

https://git.rtems.org/rtems/commit/?id=8ace7ee42ff50eee4541fd7151bf8ecc32f82384

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[Richard Biener]

On Fri, Sep 23, 2016 at 12:24 AM, kugan
 wrote:
> Hi,
> As Richard pointed out in PR77677, TREE_OVERFLOW is not cleared in IPA-VRP.
> There are three places in which we set value_range:
>
>
> 1. When value ranges are obtained from SSA_NAME with get_range_info with
> wide_int_to_tree. In this case we will not have TREE_OVERFLOW set.
>
> 2. When we vrp_meet/vrp_intersect_ranges two ranges. It does int_const_binop
> but AFAIK this does not set TREE_OVERFLOW.
>
> 3. When we create range from constant. This is the problem bit and we need
> to clear TREE_OVERFLOW here.
>
> Attached patch clears the TREE_OVERFLOW in 3rd case. Bootstrap and
> regression testing are ongoing. Is this OK if there is no regression.

Ok.  Though it would be nice to drop it at the source (that is, the point we
initialize the IPA-CP lattice and its modifications).

Richard.

> Thanks,
> Kugan
>
>
> gcc/ChangeLog:
>
> 2016-09-23  Kugan Vivekanandarajah  
>
> PR ipa/77677
> * ipa-cp.c (propagate_vr_accross_jump_function):Drop TREE_OVERFLOW
> from constant while creating value range.
>
> gcc/testsuite/ChangeLog:
>
> 2016-09-23  Kugan Vivekanandarajah  
>
> PR ipa/77677
> * gcc.dg/torture/pr77677.c: New test.

[PATCH] Restore bootstrap

[Richard Biener]

Committed as obvious.

2016-09-23  Richard Biener  

* hooks.h (hook_uint_uintp_false): Declare.

Index: gcc/hooks.h
===
--- gcc/hooks.h (revision 240386)
+++ gcc/hooks.h (working copy)
@@ -76,6 +76,7 @@ extern void hook_void_tree (tree);
 extern void hook_void_tree_treeptr (tree, tree *);
 extern void hook_void_int_int (int, int);
 extern void hook_void_gcc_optionsp (struct gcc_options *);
+extern bool hook_uint_uintp_false (unsigned int, unsigned int *);
 
 extern int hook_int_uint_mode_1 (unsigned int, machine_mode);
 extern int hook_int_const_tree_0 (const_tree);

Re: [PATCH] Bits from Early LTO debug merge -- move stuff from late to early finish

[Richard Biener]

On Thu, 22 Sep 2016, Richard Biener wrote:

> 
> This merges moving of unused type pruning from late to early finish as 
> well as handling of debug types and dwarf2 dups elimination.  It adds
> a flag to DIEs so we can mark them as removed in case sth after
> early finish tries to lookup a DIE for a removed DIE again - we shouldn't
> re-use the removed DIE (w/o parent) there.
> 
> I suppose at some point we should re-think how pruning of "unused"
> stuff is supposed to work.  Given my grand plan is to get rid of
> debug hooks and allow FEs direct control over the DWARF it should
> be ultimatively their decision what to remove (err, not create, in
> the first place).
> 
> Bootstrap and regtest running on x86_64-unknown-linux-gnu, ok for trunk?

Testing this separately shows the need to port another hunk.  If we
prune types early we have to make sure to not re-create them late
via typedefs in BLOCKs.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 240363)
+++ gcc/dwarf2out.c (working copy)
@@ -23255,7 +23242,13 @@ process_scope_var (tree stmt, tree decl,
 die = lookup_decl_die (decl_or_origin);
   else if (TREE_CODE (decl_or_origin) == TYPE_DECL
&& TYPE_DECL_IS_STUB (decl_or_origin))
-die = lookup_type_die (TREE_TYPE (decl_or_origin));
+{
+  /* Avoid re-creating the DIE late if it was optimized
+as unused early (this BLOCK reference does not count as "use").  
*/
+  die = lookup_type_die (TREE_TYPE (decl_or_origin));
+  if (! die)
+   return;
+}
   else
 die = NULL;

Richard.

> I believe this is the last part I can reasonably split out (but I'll
> have a second look after merging back from trunk once this and the other
> pending patch is approved).
> 
> Thanks,
> Richard.
> 
> 2016-09-22  Richard Biener  
> 
>   * dwarf2out.c (struct die_struct): Add removed flag.
>   (lookup_type_die): If the DIE is marked as removed, clear
>   TYPE_SYMTAB_DIE and return NULL.
>   (lookup_decl_die): If the DIE is marked as removed, remove it
>   from the hash and return NULL.
>   (mark_removed): New helper.
>   (prune_unused_types_prune): Call it for removed DIEs.
>   (dwarf2out_finish): Move unused type pruning debug_types handling
>   and breaking out includes ...
>   (dwarf2out_early_finish): ... here.
> 
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c   (revision 240353)
> +++ gcc/dwarf2out.c   (working copy)
> @@ -2705,6 +2705,10 @@ typedef struct GTY((chain_circular ("%h.
>/* Die is used and must not be pruned as unused.  */
>BOOL_BITFIELD die_perennial_p : 1;
>BOOL_BITFIELD comdat_type_p : 1; /* DIE has a type signature */
> +  /* Whether this DIE was removed from the DIE tree, for example via
> + prune_unused_types.  We don't consider those present from the
> + DIE lookup routines.  */
> +  BOOL_BITFIELD removed : 1;
>/* Lots of spare bits.  */
>  }
>  die_node;
> @@ -5098,7 +5102,13 @@ new_die (enum dwarf_tag tag_value, dw_di
>  static inline dw_die_ref
>  lookup_type_die (tree type)
>  {
> -  return TYPE_SYMTAB_DIE (type);
> +  dw_die_ref die = TYPE_SYMTAB_DIE (type);
> +  if (die && die->removed)
> +{
> +  TYPE_SYMTAB_DIE (type) = NULL;
> +  return NULL;
> +}
> +  return die;
>  }
>  
>  /* Given a TYPE_DIE representing the type TYPE, if TYPE is an
> @@ -5163,7 +5173,16 @@ decl_die_hasher::equal (die_node *x, tre
>  static inline dw_die_ref
>  lookup_decl_die (tree decl)
>  {
> -  return decl_die_table->find_with_hash (decl, DECL_UID (decl));
> +  dw_die_ref *die = decl_die_table->find_slot_with_hash (decl, DECL_UID 
> (decl),
> +  NO_INSERT);
> +  if (!die)
> +return NULL;
> +  if ((*die)->removed)
> +{
> +  decl_die_table->clear_slot (die);
> +  return NULL;
> +}
> +  return *die;
>  }
>  
>  /* Returns a hash value for X (which really is a var_loc_list).  */
> @@ -26195,6 +26214,16 @@ prune_unused_types_update_strings (dw_di
>}
>  }
>  
> +/* Mark DIE and its children as removed.  */
> +
> +static void
> +mark_removed (dw_die_ref die)
> +{
> +  dw_die_ref c;
> +  die->removed = true;
> +  FOR_EACH_CHILD (die, c, mark_removed (c));
> +}
> +
>  /* Remove from the tree DIE any dies that aren't marked.  */
>  
>  static void
> @@ -26224,12 +26253,14 @@ prune_unused_types_prune (dw_die_ref die
> die->die_child = prev;
>   }
> c->die_sib = NULL;
> +   mark_removed (c);
> return;
>   }
>else
>   {
> next = c->die_sib;
> c->die_sib = NULL;
> +   mark_removed (c);
>   }
>  
>  if (c != prev->die_sib)
> @@ -27835,37 +27866,6 @@ dwarf2out_finish (const char *)
>resolve_addr (comp_unit_die ());
>move_marked_base_types ();
>  
> -  if (flag_eliminate_unused_debug_types)

[PATCH v3 0/5] Separate shrink-wrapping

[Segher Boessenkool]

A new version of this patch set.

This now marks every block without any successors as needing all
components.  This prevents most previous problem situations from
ever happening.

The emit hooks now put explicit CFI notes on the instructions.  The
heuristics dwarf2cfi uses do not work so well for separately-wrapped
prologues.  With this change the cprop patch is no longer needed (and
we get better code in some cases).

I have improved the documentation, and many of the other suggested
changes.

Still no testcases, and I need to do new benchmark runs.


Segher


Segher Boessenkool (5):
  separate shrink-wrap: New command-line flag, status flag, hooks, and doc
  dce: Don't dead-code delete separately wrapped restores
  regrename: Don't rename restores
  shrink-wrap: Shrink-wrapping for separate components
  rs6000: Separate shrink-wrapping

 gcc/common.opt |   4 +
 gcc/config/rs6000/rs6000.c | 269 -
 gcc/dce.c  |   9 +
 gcc/doc/invoke.texi|  11 +-
 gcc/doc/tm.texi|  63 
 gcc/doc/tm.texi.in |  38 +++
 gcc/emit-rtl.h |   4 +
 gcc/function.c |   9 +-
 gcc/regrename.c|   6 +
 gcc/shrink-wrap.c  | 729 +
 gcc/shrink-wrap.h  |   1 +
 gcc/target.def |  57 
 12 files changed, 1181 insertions(+), 19 deletions(-)

-- 
1.9.3

[PATCH 2/5] dce: Don't dead-code delete separately wrapped restores

[Segher Boessenkool]

If there is a separately wrapped register restore on some path that
is dead (say, control goes into an endless loop after it), then we
cannot delete that restore because that would confuse the DWARF CFI
(if there is another path joining after this).
This happens with gcc.dg/torture/pr53168.c, for example.


2016-09-23  Segher Boessenkool  

* dce.c (delete_unmarked_insns): Don't delete instructions with
a REG_CFA_RESTORE note.

---
 gcc/dce.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gcc/dce.c b/gcc/dce.c
index ea3fb00..d510287 100644
--- a/gcc/dce.c
+++ b/gcc/dce.c
@@ -587,6 +587,15 @@ delete_unmarked_insns (void)
  if (!dbg_cnt (dce))
continue;
 
+ if (crtl->shrink_wrapped_separate
+ && find_reg_note (insn, REG_CFA_RESTORE, NULL))
+   {
+ if (dump_file)
+   fprintf (dump_file, "DCE: NOT deleting insn %d, it's a "
+   "callee-save restore\n", INSN_UID (insn));
+ continue;
+   }
+
  if (dump_file)
fprintf (dump_file, "DCE: Deleting insn %d\n", INSN_UID (insn));
 
-- 
1.9.3

[PATCH 3/5] regrename: Don't rename restores

[Segher Boessenkool]

A restore is supposed to restore some certain register.  Restoring it
into some other register will not work.  Don't.


2016-09-23  Segher Boessenkool  

* regrename.c (build_def_use): Invalidate chains that have a
REG_CFA_RESTORE on some instruction.

---
 gcc/regrename.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/regrename.c b/gcc/regrename.c
index 54c7768..00a5d02 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -1867,6 +1867,12 @@ build_def_use (basic_block bb)
scan_rtx (insn, &XEXP (note, 0), NO_REGS, terminate_dead,
  OP_IN);
  }
+
+ /* Step 8: Kill the chains involving register restores.  Those
+should restore _that_ register.  */
+ for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
+   if (REG_NOTE_KIND (note) == REG_CFA_RESTORE)
+ scan_rtx (insn, &XEXP (note, 0), NO_REGS, mark_all_read, OP_IN);
}
   else if (DEBUG_INSN_P (insn)
   && !VAR_LOC_UNKNOWN_P (INSN_VAR_LOCATION_LOC (insn)))
-- 
1.9.3

[PATCH 1/5] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

[Segher Boessenkool]

This patch adds a new command-line flag "-fshrink-wrap-separate", a status
flag "shrink_wrapped_separate", hooks for abstracting the target components,
and documentation for all those.


2016-09-23  Segher Boessenkool  

* common.opt (-fshrink-wrap-separate): New flag.
* doc/invoke.texi: Document it.
* doc/tm.texi.in (Shrink-wrapping separate components): New subsection.
* doc/tm.texi: Regenerate.
* emit-rtl.h (struct rtl_data): New field shrink_wrapped_separate.
* target.def (shrink_wrap): New hook vector.
(get_separate_components, components_for_bb, disqualify_components,
emit_prologue_components, emit_epilogue_components,
set_handled_components): New hooks.

---
 gcc/common.opt  |  4 
 gcc/doc/invoke.texi | 11 +-
 gcc/doc/tm.texi | 63 +
 gcc/doc/tm.texi.in  | 38 
 gcc/emit-rtl.h  |  4 
 gcc/target.def  | 57 
 6 files changed, 176 insertions(+), 1 deletion(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index fa1c036..1a38d12 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2189,6 +2189,10 @@ Common Report Var(flag_shrink_wrap) Optimization
 Emit function prologues only before parts of the function that need it,
 rather than at the top of the function.
 
+fshrink-wrap-separate
+Common Report Var(flag_shrink_wrap_separate) Init(1) Optimization
+Shrink-wrap parts of the prologue and epilogue separately.
+
 fsignaling-nans
 Common Report Var(flag_signaling_nans) Optimization SetByCombined
 Disable optimizations observable by IEEE signaling NaNs.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8eb5eff..464b737 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -397,7 +397,8 @@ Objective-C and Objective-C++ Dialects}.
 -fschedule-insns -fschedule-insns2 -fsection-anchors @gol
 -fselective-scheduling -fselective-scheduling2 @gol
 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops @gol
--fsemantic-interposition -fshrink-wrap -fsignaling-nans @gol
+-fsemantic-interposition -fshrink-wrap -fshrink-wrap-separate @gol
+-fsignaling-nans @gol
 -fsingle-precision-constant -fsplit-ivs-in-unroller @gol
 -fsplit-paths @gol
 -fsplit-wide-types -fssa-backprop -fssa-phiopt @gol
@@ -6396,6 +6397,7 @@ compilation time.
 -fmove-loop-invariants @gol
 -freorder-blocks @gol
 -fshrink-wrap @gol
+-fshrink-wrap-separate @gol
 -fsplit-wide-types @gol
 -fssa-backprop @gol
 -fssa-phiopt @gol
@@ -7306,6 +7308,13 @@ Emit function prologues only before parts of the 
function that need it,
 rather than at the top of the function.  This flag is enabled by default at
 @option{-O} and higher.
 
+@item -fshrink-wrap-separate
+@opindex fshrink-wrap-separate
+Shrink-wrap separate parts of the prologue and epilogue separately, so that
+those parts are only executed when needed.
+This option is on by default, but has no effect unless @option{-fshrink-wrap}
+is also turned on.
+
 @item -fcaller-saves
 @opindex fcaller-saves
 Enable allocation of values to registers that are clobbered by
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index ced6274..c439695 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -2924,6 +2924,7 @@ This describes the stack layout and calling conventions.
 * Function Entry::
 * Profiling::
 * Tail Calls::
+* Shrink-wrapping separate components::
 * Stack Smashing Protection::
 * Miscellaneous Register Hooks::
 @end menu
@@ -4853,6 +4854,68 @@ This hook should add additional registers that are 
computed by the prologue to t
 True if a function's return statements should be checked for matching the 
function's return type.  This includes checking for falling off the end of a 
non-void function.  Return false if no such check should be made.
 @end deftypefn
 
+@node Shrink-wrapping separate components
+@subsection Shrink-wrapping separate components
+@cindex shrink-wrapping separate components
+
+The prologue may perform a variety of target dependent tasks such as
+saving callee-saved registers, saving the return address, aligning the
+stack, creating a stack frame, initializing the PIC register, setting
+up the static chain, etc.
+
+On some targets some of these tasks may be independent of others and
+thus may be shrink-wrapped separately.  These independent tasks are
+referred to as components and are handled generically by the target
+independent parts of GCC.
+
+Using the following hooks those prologue or epilogue components can be
+shrink-wrapped separately, so that the initialization (and possibly
+teardown) those components do is not done as frequently on execution
+paths where this would unnecessary.
+
+What exactly those components are is up to the target code; the generic
+code treats them abstractly, as a bit in an @code{sbitmap}.  These
+@code{sbitmap}s are allocated by the @code{shrink_wrap.get_separate_components}
+and @code{shrink_wrap.compone

[PATCH 5/5] rs6000: Separate shrink-wrapping

[Segher Boessenkool]

This implements the hooks for separate shrink-wrapping for rs6000.
It handles GPRs and LR.  The GPRs get a component number corresponding
to their register number; LR gets component number 0.


2016-09-23  Segher Boessenkool  

* config/rs6000/rs6000.c (machine_function): Add new fields
gpr_is_wrapped_separately and lr_is_wrapped_separately.
(TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS,
TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB,
TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS,
TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS,
TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS,
TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define.
(rs6000_get_separate_components): New function.
(rs6000_components_for_bb): New function.
(rs6000_disqualify_components): New function.
(rs6000_emit_prologue_components): New function.
(rs6000_emit_epilogue_components): New function.
(rs6000_set_handled_components): New function.
(rs6000_emit_prologue): Don't emit LR save if lr_is_wrapped_separately.
Don't emit GPR saves if gpr_is_wrapped_separately for that register.
(rs6000_emit_epilogue): Don't emit GPR restores if
gpr_is_wrapped_separately for that register.  Don't make a
REG_CFA_RESTORE note for registers we did not restore, either.

---
 gcc/config/rs6000/rs6000.c | 269 ++---
 1 file changed, 253 insertions(+), 16 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 557009f..ec8d637 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -152,6 +152,10 @@ typedef struct GTY(()) machine_function
   bool split_stack_argp_used;
   /* Flag if r2 setup is needed with ELFv2 ABI.  */
   bool r2_setup_needed;
+  /* The components already handled by separate shrink-wrapping, which should
+ not be considered by the prologue and epilogue.  */
+  bool gpr_is_wrapped_separately[32];
+  bool lr_is_wrapped_separately;
 } machine_function;
 
 /* Support targetm.vectorize.builtin_mask_for_load.  */
@@ -1513,6 +1517,19 @@ static const struct attribute_spec 
rs6000_attribute_table[] =
 #undef TARGET_SET_UP_BY_PROLOGUE
 #define TARGET_SET_UP_BY_PROLOGUE rs6000_set_up_by_prologue
 
+#undef TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS
+#define TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS 
rs6000_get_separate_components
+#undef TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB
+#define TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB rs6000_components_for_bb
+#undef TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS
+#define TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS rs6000_disqualify_components
+#undef TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS
+#define TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS 
rs6000_emit_prologue_components
+#undef TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS
+#define TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS 
rs6000_emit_epilogue_components
+#undef TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS
+#define TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS rs6000_set_handled_components
+
 #undef TARGET_EXTRA_LIVE_ON_ENTRY
 #define TARGET_EXTRA_LIVE_ON_ENTRY rs6000_live_on_entry
 
@@ -26850,6 +26867,212 @@ rs6000_global_entry_point_needed_p (void)
   return cfun->machine->r2_setup_needed;
 }
 
+/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS.  */
+static sbitmap
+rs6000_get_separate_components (void)
+{
+  rs6000_stack_t *info = rs6000_stack_info ();
+
+  if (!(info->savres_strategy & SAVE_INLINE_GPRS)
+  || !(info->savres_strategy & REST_INLINE_GPRS)
+  || WORLD_SAVE_P (info))
+return NULL;
+
+  sbitmap components = sbitmap_alloc (32);
+  bitmap_clear (components);
+
+  /* The GPRs we need saved to the frame.  */
+  int reg_size = TARGET_32BIT ? 4 : 8;
+  int offset = info->gp_save_offset;
+  if (info->push_p)
+offset += info->total_size;
+
+  for (unsigned regno = info->first_gp_reg_save; regno < 32; regno++)
+{
+  if (IN_RANGE (offset, -0x8000, 0x7fff)
+ && rs6000_reg_live_or_pic_offset_p (regno))
+   bitmap_set_bit (components, regno);
+
+  offset += reg_size;
+}
+
+  /* Don't mess with the hard frame pointer.  */
+  if (frame_pointer_needed)
+bitmap_clear_bit (components, HARD_FRAME_POINTER_REGNUM);
+
+  /* Don't mess with the fixed TOC register.  */
+  if ((TARGET_TOC && TARGET_MINIMAL_TOC)
+  || (flag_pic == 1 && DEFAULT_ABI == ABI_V4)
+  || (flag_pic && DEFAULT_ABI == ABI_DARWIN))
+bitmap_clear_bit (components, RS6000_PIC_OFFSET_TABLE_REGNUM);
+
+  /* Optimize LR save and restore if we can.  This is component 0.  */
+  if (info->lr_save_p
+  && !(flag_pic && (DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN)))
+{
+  offset = info->lr_save_offset;
+  if (info->push_p)
+   offset += info->total_size;
+  if (IN_RANGE (offset, -0x8000, 0x7fff))
+   bitmap_set_bit (components, 0);
+}
+
+  return components;
+}
+
+/* Implement TARGET_SHRINK_WRAP_COMPONENTS_

[PATCH 4/5] shrink-wrap: Shrink-wrapping for separate components

[Segher Boessenkool]

This is the main substance of this patch series.

Instead of doing all of the prologue and epilogue in one spot, it often
is better to do components of it at different places, so that they are
executed less frequently.

What exactly is a component is completely up to the target; this code
treats it all abstractly, and uses hooks for the target to handle the
more concrete things.  Commonly there is one component for each callee-
saved register, for example.

Components can be executed more than once per function execution.  This
pass makes sure that a component's epilogue is not called more often
than the corresponding prologue has been, at any point in time; that the
prologue is called more often, wherever the prologue's effect is needed;
and that the epilogue is called as often as the prologue has been, when
the function exits.  It does this by first deciding which blocks need
which components "active", and then placing prologue and epilogue
components to make that exactly true.

Deciding what blocks should run with a certain component active so that
the total cost of executing the prologues (and epilogues) is optimal, is
not a computationally feasible problem.  Instead, for each basic block,
we estimate the cost of putting a prologue right before the block, and
if that is cheaper than the total cost of putting prologues optimally
(according to the estimated cost) in the dominator subtrees strictly
dominated by this first block, place it at the first block instead.
This simple procedure places the components optimally for any dominator
sub tree where the root node's cost does not depend on anything outside
its subtree.

The cost is the execution frequency of all edges into the block coming
from blocks that do not have this component active.  The estimated cost
is the execution frequency of the block, minus the execution frequency
of any backedges (which by definition are coming from subtrees, so if
the "head" block gets a prologue, the source block of any backedge has
that component active as well).

Currently, the epilogues are placed as late as possible, given the
constraints.  This does not matter for execution cost, but we could
save a little bit of code size by placing the epilogues in a smarter
way.  This is a possible future optimisation.

Now all that is left is inserting prologues and epilogues on all edges
that jump into resp. out of the "active" set of blocks.  Often we need
to insert some components' prologues (or epilogues) on all edges into
(or out of) a block.  In theory cross-jumping can unify all such, but
in practice that often fails; besides, that is a lot of work.  So in
this case we insert the prologue and epilogue components at the "head"
or "tail" of a block, instead.

As a final optimisation, if a block needs a prologue and its immediate
dominator has the block as a post-dominator, that immediate dominator
gets the prologue as well.


2016-09-23  Segher Boessenkool  

* function.c (thread_prologue_and_epilogue_insns): Recompute the
live info.  Call try_shrink_wrapping_separate.  Compute the
prologue_seq afterwards, if it has possibly changed.  Compute the
split_prologue_seq and epilogue_seq later, too.
* shrink-wrap.c: #include cfgbuild.h.
(dump_components): New function.
(struct sw): New struct.
(SW): New function.
(init_separate_shrink_wrap): New function.
(fini_separate_shrink_wrap): New function.
(place_prologue_for_one_component): New function.
(spread_components): New function.
(disqualify_problematic_components): New function.
(emit_common_heads_for_components): New function.
(emit_common_tails_for_components): New function.
(insert_prologue_epilogue_for_components): New function.
(try_shrink_wrapping_separate): New function.
* shrink-wrap.h: Declare try_shrink_wrapping_separate.

---
 gcc/function.c|   9 +-
 gcc/shrink-wrap.c | 729 ++
 gcc/shrink-wrap.h |   1 +
 3 files changed, 737 insertions(+), 2 deletions(-)

diff --git a/gcc/function.c b/gcc/function.c
index 53bad87..79e7b4f 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -5920,9 +5920,7 @@ thread_prologue_and_epilogue_insns (void)
   edge entry_edge = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun));
   edge orig_entry_edge = entry_edge;
 
-  rtx_insn *split_prologue_seq = make_split_prologue_seq ();
   rtx_insn *prologue_seq = make_prologue_seq ();
-  rtx_insn *epilogue_seq = make_epilogue_seq ();
 
   /* Try to perform a kind of shrink-wrapping, making sure the
  prologue/epilogue is emitted only around those parts of the
@@ -5930,6 +5928,13 @@ thread_prologue_and_epilogue_insns (void)
 
   try_shrink_wrapping (&entry_edge, prologue_seq);
 
+  try_shrink_wrapping_separate (entry_edge->dest);
+
+  if (crtl->shrink_wrapped_separate)
+prologue_seq = make_prologue_seq ();
+
+  rtx_insn *split_prologue_seq = make

Re: [PATCHv2][ARM] -mpure-code option for ARM

[Andre Vieira (lists)]

On 23/09/16 02:21, Sandra Loosemore wrote:
> On 09/22/2016 07:52 AM, Richard Earnshaw (lists) wrote:
>> On 11/07/16 17:56, Andre Vieira (lists) wrote:
>>> +
>>> diff --git a/gcc/target.def b/gcc/target.def
>>> index
>>> a4df363698ce776b51d11c187baed2069ba88a52..a3d46fa48d919a16699c33b2b78236e62a33e025
>>> 100644
>>> --- a/gcc/target.def
>>> +++ b/gcc/target.def
>>> @@ -432,6 +432,19 @@ this section is associated.",
>>>void, (const char *name, unsigned int flags, tree decl),
>>>default_no_named_section)
>>>
>>> +/* Tell assembler what section attributes to assign this elf section
>>> +   declaration, using their numerical value.  */
>>> +DEFHOOK
>>> +(elf_flags_numeric,
>>> + "If the target needs to represent ELF section attributes using
>>> their\n\
>>> +numerical value, then this hook should be implemented to return true
>>> and\n\
>>> +write the numerical value of @var{flags} in @var{num}.  This
>>> function is\n\
>>> +called by @code{default_elf_asm_named_section}, which prints
>>> @var{num}\n\
>>> +as the value representing the ELF section attributes if this
>>> function\n\
>>> +returns true.",
>>
>>
>> I think this should read something like.
>>
>> This hook can be used to encode ELF section flags for which no letter
>> code has been defined in the assembler.  It is called by
>> @code{default_asm_named_section} whenever the section flags need to be
>> emitted in the assembler output.  If the hook returns true, then the
>> numerical value for ELF section flags should be calculated from
>> @var{flags} and saved in @var{*num}; the value will be printed out
>> instead of the normal sequence of letter codes.  If the hook is not
>> defined, or if it returns false, then @var{num} will be ignored and the
>> traditional letter sequence will be emitted.
> 
> Can we please write this in the present tense instead of the future,
> assuming it describes current behavior (as modified by the patch)?
> 
> s/will be/is/g
> 
> -Sandra
> 
Hi Sandra,

Is this better?

Cheers,
Andre

gcc/ChangeLog
2016-09-23  Andre Vieira  

* target.def(elf_flags_numeric): Change documentation to
present tense.
>From 459abfbbd836aa11e71dd90b9466c60b1155fba0 Mon Sep 17 00:00:00 2001
From: Andre Simoes Dias Vieira 
Date: Fri, 23 Sep 2016 09:16:17 +0100
Subject: [PATCH] Language fix for elf_flags_numeric doc

---
 gcc/target.def | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/target.def b/gcc/target.def
index ac693318adaaa230ea300f10bc37282881d9da6f..4adb8aabc6548889b717abc9310e98f0e6fc161b 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -441,10 +441,10 @@ code has been defined in the assembler.  It is called by\n\
 @code{default_asm_named_section} whenever the section flags need to be\n\
 emitted in the assembler output.  If the hook returns true, then the\n\
 numerical value for ELF section flags should be calculated from\n\
-@var{flags} and saved in @var{*num}; the value will be printed out\n\
-instead of the normal sequence of letter codes.  If the hook is not\n\
-defined, or if it returns false, then @var{num} will be ignored and the\n\
-traditional letter sequence will be emitted.",
+@var{flags} and saved in @var{*num}; the value is printed out instead of the\n\
+normal sequence of letter codes.  If the hook is not defined, or if it\n\
+returns false, then @var{num} is ignored and the traditional letter sequence\n\
+is emitted.",
  bool, (unsigned int flags, unsigned int *num),
  hook_uint_uintp_false)
 
-- 
1.9.1

Re: [PATCH] Avoid some C++ local statics with constructors

[Jakub Jelinek]

On Fri, Sep 23, 2016 at 08:55:02AM +0200, Richard Biener wrote:
> While I agree with the goal to reduce the number of static constructors
> esp. the vNULL cases I disagree with.  This is just introducing
> undefined behavior (uninitialized object use), and in case we end up
> making vNULL not all-zeros it's bound to break.  So IMHO your patch
> is very much premature optimization here.

No, there is no undefined behavior, and we rely on the zero initialization
in > 100 cases, see
grep '\(^\|static \)vec \?<.*;' *.c *.cc */*.c ada/*/*.c | grep -v '\*'
or anywhere where we have vec part of a struct that we allocate cleared or
clear after allocation.
The thing is, vec is (intentionally) a POD, thus doesn't have a ctor,
and the = vNULL "construction" is
  template 
  operator vec () { return vec(); }
actually clearing of the vector.  If we ever wanted to initialize vec to
something not-all-zeros, we'd actually need to turn it into non-POD and add
ctor.

I'm attaching 3 further patches (not bootstrapped/regtested yet), which:
1) adds constexpr keyword for C++11 + to the vNULL operator, this seems to
be enough to get rid of the runtime initialization, both in the
tree-ssa-sccvn.o case with _ZGV var and e.g. in passes.c get rid of
_Z41__static_initialization_and_destruction_0ii ctor
2) another patch to remove the useless = vNULL initializers from file scope
vecs, we don't usually = 0 static vars either (though, apparently we have
hundreds of those)
3) a patch that attempts to clarify when = vNULL is needed and when it is
not

> Maybe we can change vNULL to sth that avoids the constructor, if only
> if C++14 is available (thus in stage2+)?
> 
> For cases like this I hope we could make GCC optimize away the static
> construction, maybe you can reduce it to a simple testcase and file
> a bugreport?  It will require making static constructors "first class"
> in the cgraph so we know at some point the function body initializing
> a specific global and some later cgraph phase builds up the global
> constructor calling all remaining relevant individual constructor
> functions (which can then still be inlined into that fn).

A short testcase is e.g.
struct S { int a; };
void baz (S *);
#if __cpp_constexpr >= 200704
constexpr
#endif
inline S foo () { return (S) { 2 }; }

S s = foo ();

void
bar ()
{
  static S t = foo ();
  baz (&t);
}
Here for -std=c++98 (or even -std=c++1z without the constexpr keyword)
at -O0 there is both _Z41__static_initialization_and_destruction_0ii and
the __cxa_guard*+_ZGV stuff, at -O2 we manage to inline
_Z41__static_initialization_and_destruction_0ii but still end up with
_GLOBAL__sub_I_s:
movl$2, s(%rip)
ret
registered in .ctors.  And the guard stuff is left too.
Optimizing that away would be nice, but non-fun, we'd have to recognize
something like:

  static struct S t;
  unsigned char _1;
  int _2;

  :
  _1 = __atomic_load_1 (&_ZGVZ3barvE1t, 2);
  if (_1 == 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  _2 = __cxa_guard_acquire (&_ZGVZ3barvE1t);
  if (_2 != 0)
goto ;
  else
goto ;

  :
  MEM[(struct S *)&t] = 2;
  __cxa_guard_release (&_ZGVZ3barvE1t);

  :

and turn those stores into the static var into a static initializer
and throw away the _ZGV* var, plus if this is in an inline function
(i.e. the static var and its _ZGV* var are comdat) it might be an
ABI thing too (unfortunately the _ZGV* var and the actual var it is guarding
aren't in the same comdat, so even a trick like keeping the runtime
initialization in, but initialize the var to the expected values and
preinitialize the _ZGV* guard into the "already initialized" state wouldn't
work reliably, if the linker picks the _ZGV* var from one TU and the guarded
var from another one, it could fail).  So, I'm afraid if we want to do this
optimization, we'd need to limit it to the cases where the _ZGV* var isn't
visible outside of the TU.

Ok for the 3 patches (or some subset of them) for trunk if they pass
bootstrap/regtest?

Jakub
2016-09-23  Jakub Jelinek  

* vec.h (vnull::operator vec): Add constexpr keyword for
C++11 and later.

--- gcc/vec.h.jj2016-04-26 08:08:18.0 +0200
+++ gcc/vec.h   2016-09-23 09:48:48.813586327 +0200
@@ -414,6 +414,9 @@ struct GTY((user)) vec
 struct vnull
 {
   template 
+#if __cpp_constexpr >= 201103
+  constexpr
+#endif
   operator vec () { return vec(); }
 };
 extern vnull vNULL;
2016-09-23  Jakub Jelinek  

* sel-sched-ir.c (sel_global_bb_info, sel_region_bb_info,
loop_nests, s_i_d, last_added_blocks): Remove unnecessary
= vNULL initialization of file scope vec.
* passes.c (pass_tab, enabled_pass_uid_range_tab,
disabled_pass_uid_range_tab): Likewise.
* haifa-sched.c (sched_luids, h_i_d): Likewise.
* tree-chkp-opt.c (check_infos): Likewise.
* sel-sched.c (vec_av_set, vec_temp_moveop_nops): Likewise.
c/
* c-parser.c (incomplete_record_decls): Remove unnecessary
  

Re: [PATCH] Fix PR ipa/77653

[Martin Liška]

On 09/22/2016 03:07 PM, David Edelsohn wrote:
> @@ -,13 +2221,11 @@ sem_variable::merge (sem_item *alias_item)
>  }
> 
>/* We can not merge if address comparsion metters.  */
> -  if (original_address_matters && alias_address_matters
> -  && flag_merge_constants < 2)
> +  if (alias_address_matters && flag_merge_constants < 2)
>  {
>if (dump_file)
>   fprintf (dump_file,
> - "Not unifying; "
> - "adress of original and alias may be compared.\n\n");
> + "Not unifying; adress of original may be compared.\n\n");
>  ^^^ address not adress
>return false;
>  }
> 
> The dump file message contains a typo: address not adress.
> 
> +/* { dg-final { scan-ipa-dump "Not unifying; adress of original may
> be compared." "icf"  } } */
> 
> Similarly, the testcase needs to be updated to match.
> 
> Thanks, David
> 

Thank you David for the nit, I've installed patch for that as r240399.
I've also grepped the source code for 'adress' and I found another
places where we have the typo.

Is the attached patch ready to be installed?
Thanks,
Martin
>From 0d9c643c1fa8e3d7fe1b78efaf7c865d6e55f725 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 23 Sep 2016 10:42:46 +0200
Subject: [PATCH 2/2] Fix typos: adress -> address

gcc/ChangeLog:

2016-09-23  Martin Liska  

	* config/s390/vx-builtins.md: Replace 'adress' with 'address'.

libjava/classpath/ChangeLog:

2016-09-23  Martin Liska  

	* configure: Replace 'adress' with 'address'.
	* java/awt/geom/CubicCurve2D.java: Likewise.
	* java/net/Inet6Address.java: Likewise.
	* m4/ax_create_stdint_h.m4: Likewise.
	* native/jni/native-lib/cpnet.h: Likewise.
---
 gcc/config/s390/vx-builtins.md| 4 ++--
 libjava/classpath/configure   | 2 +-
 libjava/classpath/java/awt/geom/CubicCurve2D.java | 2 +-
 libjava/classpath/java/net/Inet6Address.java  | 2 +-
 libjava/classpath/m4/ax_create_stdint_h.m4| 2 +-
 libjava/classpath/native/jni/native-lib/cpnet.h   | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/config/s390/vx-builtins.md b/gcc/config/s390/vx-builtins.md
index 444c277..c6ac44c 100644
--- a/gcc/config/s390/vx-builtins.md
+++ b/gcc/config/s390/vx-builtins.md
@@ -389,7 +389,7 @@
 
 ; vscef, vsceg
 
-; A 64 bit target adress generated from 32 bit elements
+; A 64 bit target address generated from 32 bit elements
 (define_insn "vec_scatter_elementv4si_DI"
   [(set (mem:SI
 	 (plus:DI (zero_extend:DI
@@ -417,7 +417,7 @@
   "vsce\t%v0,%O2(%v1,%R2),%3"
   [(set_attr "op_type" "VRV")])
 
-; Element size and target adress size is the same
+; Element size and target address size is the same
 (define_insn "vec_scatter_element_"
   [(set (mem:
 	 (plus: (unspec:
diff --git a/libjava/classpath/configure b/libjava/classpath/configure
index 6d46403..f554860 100755
--- a/libjava/classpath/configure
+++ b/libjava/classpath/configure
@@ -28939,7 +28939,7 @@ typedef u_int32_t uint32_t;
 #endif
 
 #ifdef _STDINT_NEED_INT_MODEL_T
-/* we must guess all the basic types. Apart from byte-adressable system, */
+/* we must guess all the basic types. Apart from byte-addressable system, */
 /* there a few 32-bit-only dsp-systems that we guard with BYTE_MODEL 8-} */
 /* (btw, those nibble-addressable systems are way off, or so we assume) */
 
diff --git a/libjava/classpath/java/awt/geom/CubicCurve2D.java b/libjava/classpath/java/awt/geom/CubicCurve2D.java
index 5cb11fe..1fc2619 100644
--- a/libjava/classpath/java/awt/geom/CubicCurve2D.java
+++ b/libjava/classpath/java/awt/geom/CubicCurve2D.java
@@ -1040,7 +1040,7 @@ public abstract class CubicCurve2D implements Shape, Cloneable
* Detailed in an article on Eric Haines' page:
* http://www.acm.org/tog/editors/erich/ptinpoly/
*
-   * A special-case not adressed in this code is self-intersections
+   * A special-case not addressed in this code is self-intersections
* of the curve, e.g. if the axis intersects the self-itersection,
* the degenerate roots of the polynomial will erroneously count as
* a single intersection of the curve, and not two.
diff --git a/libjava/classpath/java/net/Inet6Address.java b/libjava/classpath/java/net/Inet6Address.java
index 60c4065..7ce3a87 100644
--- a/libjava/classpath/java/net/Inet6Address.java
+++ b/libjava/classpath/java/net/Inet6Address.java
@@ -299,7 +299,7 @@ public final class Inet6Address extends InetAddress
   }
 
   /**
-   * Returns the scope ID of the address scope if it is a scoped adress using
+   * Returns the scope ID of the address scope if it is a scoped address using
* an integer to identify the scope.
*
* Otherwise this method returns 0.
diff --git a/libjava/classpath/m4/ax_create_stdint_h.m4 b/libjava/classpath/m4/ax_create_stdint_h.m4
index 453af07..2c58e54 100644
--- a/libjava/classpath/m4/ax_create_stdint_h.m4
+++ b/libjava/classpath/m4/ax_create_stdint_h.m4
@@ -430,7 +430,7 @@ typedef u_int32_t uint32_t;
 #endif
 
 #ifdef _STDINT_NEED_INT_MODEL_T
-/* we must guess all t

Re: ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[kugan]

Hi Richard,

Thanks for the review.

On 23/09/16 17:19, Richard Biener wrote:

On Fri, Sep 23, 2016 at 12:24 AM, kugan
 wrote:

Hi,
As Richard pointed out in PR77677, TREE_OVERFLOW is not cleared in IPA-VRP.
There are three places in which we set value_range:


1. When value ranges are obtained from SSA_NAME with get_range_info with
wide_int_to_tree. In this case we will not have TREE_OVERFLOW set.

2. When we vrp_meet/vrp_intersect_ranges two ranges. It does int_const_binop
but AFAIK this does not set TREE_OVERFLOW.

3. When we create range from constant. This is the problem bit and we need
to clear TREE_OVERFLOW here.

Attached patch clears the TREE_OVERFLOW in 3rd case. Bootstrap and
regression testing are ongoing. Is this OK if there is no regression.


Ok.  Though it would be nice to drop it at the source (that is, the point we
initialize the IPA-CP lattice and its modifications).


In ipa_compute_jump_function_for_egde, value_range lattice is not set 
for constants as this information is already there in IPA_JF_CONSTANT. 
That is, we initialize only when we get it from get_range_info 
(SSA_NAMES); others are set to unknown. Though we can set it at this 
point, it can be inefficient in terms of streaming in/out this data. 
While propagating we get it from IPA_JF_CONSTANT.


Thanks,
Kugan


Richard.


Thanks,
Kugan


gcc/ChangeLog:

2016-09-23  Kugan Vivekanandarajah  

PR ipa/77677
* ipa-cp.c (propagate_vr_accross_jump_function):Drop TREE_OVERFLOW
from constant while creating value range.

gcc/testsuite/ChangeLog:

2016-09-23  Kugan Vivekanandarajah  

PR ipa/77677
* gcc.dg/torture/pr77677.c: New test.

Re: [PATCH] Avoid some C++ local statics with constructors

[Richard Biener]

On Fri, 23 Sep 2016, Jakub Jelinek wrote:

> On Fri, Sep 23, 2016 at 08:55:02AM +0200, Richard Biener wrote:
> > While I agree with the goal to reduce the number of static constructors
> > esp. the vNULL cases I disagree with.  This is just introducing
> > undefined behavior (uninitialized object use), and in case we end up
> > making vNULL not all-zeros it's bound to break.  So IMHO your patch
> > is very much premature optimization here.
> 
> No, there is no undefined behavior, and we rely on the zero initialization
> in > 100 cases, see
> grep '\(^\|static \)vec \?<.*;' *.c *.cc */*.c ada/*/*.c | grep -v '\*'
> or anywhere where we have vec part of a struct that we allocate cleared or
> clear after allocation.
> The thing is, vec is (intentionally) a POD, thus doesn't have a ctor,
> and the = vNULL "construction" is
>   template 
>   operator vec () { return vec(); }
> actually clearing of the vector.  If we ever wanted to initialize vec to
> something not-all-zeros, we'd actually need to turn it into non-POD and add
> ctor.
> 
> I'm attaching 3 further patches (not bootstrapped/regtested yet), which:
> 1) adds constexpr keyword for C++11 + to the vNULL operator, this seems to
> be enough to get rid of the runtime initialization, both in the
> tree-ssa-sccvn.o case with _ZGV var and e.g. in passes.c get rid of
> _Z41__static_initialization_and_destruction_0ii ctor

Really?  We have

extern vnull vNULL;

thus all = vNULL initializers are really copies of an instance in vec.c.

This patch is nevertheless fine.

> 2) another patch to remove the useless = vNULL initializers from file scope
> vecs, we don't usually = 0 static vars either (though, apparently we have
> hundreds of those)

Ok.

> 3) a patch that attempts to clarify when = vNULL is needed and when it is
> not

Ok as well.

> > Maybe we can change vNULL to sth that avoids the constructor, if only
> > if C++14 is available (thus in stage2+)?
> > 
> > For cases like this I hope we could make GCC optimize away the static
> > construction, maybe you can reduce it to a simple testcase and file
> > a bugreport?  It will require making static constructors "first class"
> > in the cgraph so we know at some point the function body initializing
> > a specific global and some later cgraph phase builds up the global
> > constructor calling all remaining relevant individual constructor
> > functions (which can then still be inlined into that fn).
> 
> A short testcase is e.g.
> struct S { int a; };
> void baz (S *);
> #if __cpp_constexpr >= 200704
> constexpr
> #endif
> inline S foo () { return (S) { 2 }; }
> 
> S s = foo ();
> 
> void
> bar ()
> {
>   static S t = foo ();
>   baz (&t);
> }
> Here for -std=c++98 (or even -std=c++1z without the constexpr keyword)
> at -O0 there is both _Z41__static_initialization_and_destruction_0ii and
> the __cxa_guard*+_ZGV stuff, at -O2 we manage to inline
> _Z41__static_initialization_and_destruction_0ii but still end up with
> _GLOBAL__sub_I_s:
> movl$2, s(%rip)
> ret
> registered in .ctors.

Yeah, I think this is where we could improve.

>  And the guard stuff is left too.
> Optimizing that away would be nice, but non-fun, we'd have to recognize
> something like:
> 
>   static struct S t;
>   unsigned char _1;
>   int _2;
> 
>   :
>   _1 = __atomic_load_1 (&_ZGVZ3barvE1t, 2);
>   if (_1 == 0)
> goto ;
>   else
> goto ;
> 
>   :
>   goto ;
> 
>   :
>   _2 = __cxa_guard_acquire (&_ZGVZ3barvE1t);
>   if (_2 != 0)
> goto ;
>   else
> goto ;
> 
>   :
>   MEM[(struct S *)&t] = 2;
>   __cxa_guard_release (&_ZGVZ3barvE1t);
> 
>   :

Ick - I totally forgot about the local static initializer woes
with guards.  _Maybe_ we can represent this by putting the guard
into the initializer function (remember, I'd like to see all
static initializers be represented as functions, refered to
from their initializing varpool node as, say, ->initializer).
Thus we'd have the FE generate

bar ()
{
  __static_init_for_t ();
...
}

__static_init_for_t ()
{
  all the guard stuff plus the init
}

the initializers would be always-inline (at IPA time when optimizing
to be able to do the promotion to a static ctor).

> and turn those stores into the static var into a static initializer
> and throw away the _ZGV* var, plus if this is in an inline function
> (i.e. the static var and its _ZGV* var are comdat) it might be an
> ABI thing too (unfortunately the _ZGV* var and the actual var it is guarding
> aren't in the same comdat, so even a trick like keeping the runtime
> initialization in, but initialize the var to the expected values and
> preinitialize the _ZGV* guard into the "already initialized" state wouldn't
> work reliably, if the linker picks the _ZGV* var from one TU and the guarded
> var from another one, it could fail).  So, I'm afraid if we want to do this
> optimization, we'd need to limit it to the cases where the _ZGV* var isn't
> visible outside of the TU.
> 
> Ok for the 3 patches (or some subset of the

Re: [PATCH] Avoid some C++ local statics with constructors

[Jakub Jelinek]

On Fri, Sep 23, 2016 at 10:59:12AM +0200, Richard Biener wrote:
> On Fri, 23 Sep 2016, Jakub Jelinek wrote:
> 
> > On Fri, Sep 23, 2016 at 08:55:02AM +0200, Richard Biener wrote:
> > > While I agree with the goal to reduce the number of static constructors
> > > esp. the vNULL cases I disagree with.  This is just introducing
> > > undefined behavior (uninitialized object use), and in case we end up
> > > making vNULL not all-zeros it's bound to break.  So IMHO your patch
> > > is very much premature optimization here.
> > 
> > No, there is no undefined behavior, and we rely on the zero initialization
> > in > 100 cases, see
> > grep '\(^\|static \)vec \?<.*;' *.c *.cc */*.c ada/*/*.c | grep -v '\*'
> > or anywhere where we have vec part of a struct that we allocate cleared or
> > clear after allocation.
> > The thing is, vec is (intentionally) a POD, thus doesn't have a ctor,
> > and the = vNULL "construction" is
> >   template 
> >   operator vec () { return vec(); }
> > actually clearing of the vector.  If we ever wanted to initialize vec to
> > something not-all-zeros, we'd actually need to turn it into non-POD and add
> > ctor.
> > 
> > I'm attaching 3 further patches (not bootstrapped/regtested yet), which:
> > 1) adds constexpr keyword for C++11 + to the vNULL operator, this seems to
> > be enough to get rid of the runtime initialization, both in the
> > tree-ssa-sccvn.o case with _ZGV var and e.g. in passes.c get rid of
> > _Z41__static_initialization_and_destruction_0ii ctor
> 
> Really?  We have
> 
> extern vnull vNULL;

vNULL is not a vec (after all, vec is a template, so there can't be a single
object), just a dummy object with a conversion operator template which
value-initializes an unnamed vec temporary and the assignment copies it into
the variable.

Anyway, I'll file 2 PRs, one for the file scope static initialization
optimization, another for the local static.

Jakub

Re: [PATCH] Fix PR ipa/77653

[Richard Biener]

On Fri, Sep 23, 2016 at 10:51 AM, Martin Liška  wrote:
> On 09/22/2016 03:07 PM, David Edelsohn wrote:
>> @@ -,13 +2221,11 @@ sem_variable::merge (sem_item *alias_item)
>>  }
>>
>>/* We can not merge if address comparsion metters.  */
>> -  if (original_address_matters && alias_address_matters
>> -  && flag_merge_constants < 2)
>> +  if (alias_address_matters && flag_merge_constants < 2)
>>  {
>>if (dump_file)
>>   fprintf (dump_file,
>> - "Not unifying; "
>> - "adress of original and alias may be compared.\n\n");
>> + "Not unifying; adress of original may be compared.\n\n");
>>  ^^^ address not adress
>>return false;
>>  }
>>
>> The dump file message contains a typo: address not adress.
>>
>> +/* { dg-final { scan-ipa-dump "Not unifying; adress of original may
>> be compared." "icf"  } } */
>>
>> Similarly, the testcase needs to be updated to match.
>>
>> Thanks, David
>>
>
> Thank you David for the nit, I've installed patch for that as r240399.
> I've also grepped the source code for 'adress' and I found another
> places where we have the typo.
>
> Is the attached patch ready to be installed?

Ok, but the classpath ones are imported from upstream (and is going to
be removed anyway), so please omit those.

Richard.

> Thanks,
> Martin

Re: [PATCH] Avoid some C++ local statics with constructors

[Richard Biener]

On Fri, 23 Sep 2016, Richard Biener wrote:

> On Thu, 22 Sep 2016, Jakub Jelinek wrote:
> 
> > Hi!
> > 
> > The discovered 5 unnecessary C++ static locals with ctors prompted me to
> > look at other cases, which from looking at the optimized or non-optimized
> > code are just terrible.
> > We don't need to initialize static vectors with vNULL, because that implies
> > runtime initialization, static vars are zero initialized, which is what we
> > want for the vectors.
> > In ipa-cp, I understand the vr.min and vr.max is set just so that
> > uninitialized vars aren't copied around, but initializing static local
> > wide_int from tree and then copying over is significantly more expensive
> > than just using wi::zero.
> > The only questionable change is the sreal.h one, what it did is certainly
> > very inefficient and ugly, but what the patch does is a kind of hack to keep
> > it as efficient as possible even for -O0, at -O2 I'd say the compiler should
> > just inline sreal::normalize and fold it into nothing.
> > So, if preferred, we could go with just
> >inline static sreal min ()
> >{
> >  return sreal (-SREAL_MAX_SIG, SREAL_MAX_EXP);
> >}
> > which will be at -O2 as efficient as what the patch does - storing 2
> > integers.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> While I agree with the goal to reduce the number of static constructors
> esp. the vNULL cases I disagree with.  This is just introducing
> undefined behavior (uninitialized object use), and in case we end up
> making vNULL not all-zeros it's bound to break.  So IMHO your patch
> is very much premature optimization here.
> 
> Maybe we can change vNULL to sth that avoids the constructor, if only
> if C++14 is available (thus in stage2+)?
> 
> For cases like this I hope we could make GCC optimize away the static
> construction, maybe you can reduce it to a simple testcase and file
> a bugreport?  It will require making static constructors "first class"
> in the cgraph so we know at some point the function body initializing
> a specific global and some later cgraph phase builds up the global
> constructor calling all remaining relevant individual constructor
> functions (which can then still be inlined into that fn).

Thus in the light of the other patch-set this patch is ok as well.

Thanks,
Richard.

> Thanks,
> Richard.
> 
> > 2016-09-22  Jakub Jelinek  
> > 
> > * ipa-cp.c (ipcp_store_vr_results): Avoid static local
> > var zero.
> > * sreal.h (sreal::min, sreal::max): Avoid static local vars,
> > construct values without normalization.
> > * tree-ssa-sccvn.c (vn_reference_lookup_3): Don't initialize
> > static local lhs_ops to vNULL.
> > cp/
> > * name-lookup.c (store_bindings, store_class_bindings): Don't
> > initialize static local bindings_need_stored to vNULL.
> > 
> > --- gcc/ipa-cp.c.jj 2016-09-21 08:54:15.0 +0200
> > +++ gcc/ipa-cp.c2016-09-22 13:49:57.638198975 +0200
> > @@ -5204,11 +5204,9 @@ ipcp_store_vr_results (void)
> >  }
> > else
> >  {
> > -  static wide_int zero = integer_zero_node;
> >vr.known = false;
> >vr.type = VR_VARYING;
> > -  vr.min = zero;
> > -  vr.max = zero;
> > +  vr.min = vr.max = wi::zero (INT_TYPE_SIZE);
> >  }
> > ts->m_vr->quick_push (vr);
> >   }
> > --- gcc/sreal.h.jj  2016-01-04 14:55:52.0 +0100
> > +++ gcc/sreal.h 2016-09-22 14:09:38.882930801 +0200
> > @@ -104,14 +104,20 @@ public:
> >/* Global minimum sreal can hold.  */
> >inline static sreal min ()
> >{
> > -static sreal min = sreal (-SREAL_MAX_SIG, SREAL_MAX_EXP);
> > +sreal min;
> > +/* This never needs normalization.  */
> > +min.m_sig = -SREAL_MAX_SIG;
> > +min.m_exp = SREAL_MAX_EXP;
> >  return min;
> >}
> >  
> >/* Global minimum sreal can hold.  */
> >inline static sreal max ()
> >{
> > -static sreal max = sreal (SREAL_MAX_SIG, SREAL_MAX_EXP);
> > +sreal max;
> > +/* This never needs normalization.  */
> > +max.m_sig = SREAL_MAX_SIG;
> > +max.m_exp = SREAL_MAX_EXP;
> >  return max;
> >}
> >  
> > --- gcc/tree-ssa-sccvn.c.jj 2016-09-20 15:43:09.0 +0200
> > +++ gcc/tree-ssa-sccvn.c2016-09-22 13:40:03.667886908 +0200
> > @@ -1786,8 +1786,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree
> >gimple *def_stmt = SSA_NAME_DEF_STMT (vuse);
> >tree base = ao_ref_base (ref);
> >HOST_WIDE_INT offset, maxsize;
> > -  static vec
> > -lhs_ops = vNULL;
> > +  static vec lhs_ops;
> >ao_ref lhs_ref;
> >bool lhs_ref_ok = false;
> >  
> > --- gcc/cp/name-lookup.c.jj 2016-09-14 23:54:25.0 +0200
> > +++ gcc/cp/name-lookup.c2016-09-22 13:51:22.459102089 +0200
> > @@ -6197,7 +6197,7 @@ store_binding (tree id, vec >  static void
> >  store_bindings (tree names, vec **old_bindings)
> >  {
> > -  static vec bindings_need_stored = vNULL;
> > +  static vec bindings_need_stor

Re: ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[Richard Biener]

On Fri, Sep 23, 2016 at 10:58 AM, kugan
 wrote:
> Hi Richard,
>
> Thanks for the review.
>
> On 23/09/16 17:19, Richard Biener wrote:
>>
>> On Fri, Sep 23, 2016 at 12:24 AM, kugan
>>  wrote:
>>>
>>> Hi,
>>> As Richard pointed out in PR77677, TREE_OVERFLOW is not cleared in
>>> IPA-VRP.
>>> There are three places in which we set value_range:
>>>
>>>
>>> 1. When value ranges are obtained from SSA_NAME with get_range_info with
>>> wide_int_to_tree. In this case we will not have TREE_OVERFLOW set.
>>>
>>> 2. When we vrp_meet/vrp_intersect_ranges two ranges. It does
>>> int_const_binop
>>> but AFAIK this does not set TREE_OVERFLOW.
>>>
>>> 3. When we create range from constant. This is the problem bit and we
>>> need
>>> to clear TREE_OVERFLOW here.
>>>
>>> Attached patch clears the TREE_OVERFLOW in 3rd case. Bootstrap and
>>> regression testing are ongoing. Is this OK if there is no regression.
>>
>>
>> Ok.  Though it would be nice to drop it at the source (that is, the point
>> we
>> initialize the IPA-CP lattice and its modifications).
>
>
> In ipa_compute_jump_function_for_egde, value_range lattice is not set for
> constants as this information is already there in IPA_JF_CONSTANT. That is,
> we initialize only when we get it from get_range_info (SSA_NAMES); others
> are set to unknown. Though we can set it at this point, it can be
> inefficient in terms of streaming in/out this data. While propagating we get
> it from IPA_JF_CONSTANT.

Yes, I meant we should avoid TREE_OVERFLOW on IPA_JF_CONSTANT in the
first place.

Richard.

>
> Thanks,
> Kugan
>
>
>> Richard.
>>
>>> Thanks,
>>> Kugan
>>>
>>>
>>> gcc/ChangeLog:
>>>
>>> 2016-09-23  Kugan Vivekanandarajah  
>>>
>>> PR ipa/77677
>>> * ipa-cp.c (propagate_vr_accross_jump_function):Drop
>>> TREE_OVERFLOW
>>> from constant while creating value range.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2016-09-23  Kugan Vivekanandarajah  
>>>
>>> PR ipa/77677
>>> * gcc.dg/torture/pr77677.c: New test.

Re: [PATCH] Fix PR ipa/77653

[Martin Liška]

On 09/23/2016 11:19 AM, Richard Biener wrote:
> Ok, but the classpath ones are imported from upstream (and is going to
> be removed anyway), so please omit those.
> 
> Richard.

Good! I installed following.

M.
>From 6e23669e0e6572d44939fd0539c438c75c9d381e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 23 Sep 2016 11:28:23 +0200
Subject: [PATCH] Fix typos: adress -> address

gcc/ChangeLog:

2016-09-23  Martin Liska  

	* config/s390/vx-builtins.md: Replace 'adress' with 'address'.
---
 gcc/config/s390/vx-builtins.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/s390/vx-builtins.md b/gcc/config/s390/vx-builtins.md
index 444c277..c6ac44c 100644
--- a/gcc/config/s390/vx-builtins.md
+++ b/gcc/config/s390/vx-builtins.md
@@ -389,7 +389,7 @@
 
 ; vscef, vsceg
 
-; A 64 bit target adress generated from 32 bit elements
+; A 64 bit target address generated from 32 bit elements
 (define_insn "vec_scatter_elementv4si_DI"
   [(set (mem:SI
 	 (plus:DI (zero_extend:DI
@@ -417,7 +417,7 @@
   "vsce\t%v0,%O2(%v1,%R2),%3"
   [(set_attr "op_type" "VRV")])
 
-; Element size and target adress size is the same
+; Element size and target address size is the same
 (define_insn "vec_scatter_element_"
   [(set (mem:
 	 (plus: (unspec:
-- 
2.9.2

[PATCH][Committed] Add self to write-after-approval section of MAINTAINERS file

[Tamar Christina]

Hi All,

I have committed the attached patch, adding myself to the Write After
Approval section of the MAINTAINERS file.

Thanks,
Tamar

ChangeLog:

2016-09-23  Tamar Christina 

* MAINTAINERS (Write After Approval): Add myself.diff --git a/MAINTAINERS b/MAINTAINERS
index dac8209c0c0dff8da872e22514cd583a3a1642c0..752abf4d412f61ff446e16085f122d3d0d97446a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -367,6 +367,7 @@ Dehao Chen	
 Fabien Chêne	
 Bin Cheng	
 Harshit Chopra	
+Tamar Christina	
 William Cohen	
 Michael Collison
 Josh Conner	

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Jakub Jelinek]

On Thu, Sep 22, 2016 at 10:37:21PM +0200, Uros Bizjak wrote:
> diff --git a/gcc/hooks.c b/gcc/hooks.c
> index 
> 99ec4014adb6fcbb073bf538dd00fe8695ee6cb2..1e925645c3173f8d97e104b9b2f480fca2ede438
> 100644
> --- a/gcc/hooks.c
> +++ b/gcc/hooks.c
> @@ -481,3 +481,13 @@ void
>   hook_void_gcc_optionsp (struct gcc_options *opts ATTRIBUTE_UNUSED)
>   {
>   }
> +
> +/* Generic hook that takes an unsigned int, an unsigned int pointer and
> +   returns false.  */
> +
> +bool
> +hook_uint_uintp_false (unsigned int, unsigned int *)
> +{
> +  return false;
> +}
> 
> 
> The name of this hook doesn't adhere to the convention. It should be named:
> 
> hook_bool_uint_uintp_false

You're right, I've committed this as obvious:

2016-09-23  Uros Bizjak  
Jakub Jelinek  

* hooks.h (hook_uint_uintp_false): Rename to...
(hook_bool_uint_uintp_false): ... this.
* hooks.c (hook_uint_uintp_false): Rename to...
(hook_bool_uint_uintp_false): ... this.
* target.def (elf_flags_numeric): Use hook_bool_uint_uintp_false
instead of hook_uint_uintp_false.

--- gcc/hooks.h.jj  2016-09-23 09:32:13.0 +0200
+++ gcc/hooks.h 2016-09-23 11:57:28.116738504 +0200
@@ -76,7 +76,7 @@ extern void hook_void_tree (tree);
 extern void hook_void_tree_treeptr (tree, tree *);
 extern void hook_void_int_int (int, int);
 extern void hook_void_gcc_optionsp (struct gcc_options *);
-extern bool hook_uint_uintp_false (unsigned int, unsigned int *);
+extern bool hook_bool_uint_uintp_false (unsigned int, unsigned int *);
 
 extern int hook_int_uint_mode_1 (unsigned int, machine_mode);
 extern int hook_int_const_tree_0 (const_tree);
--- gcc/hooks.c.jj  2016-09-23 09:32:13.0 +0200
+++ gcc/hooks.c 2016-09-23 11:57:39.938588268 +0200
@@ -486,8 +486,7 @@ hook_void_gcc_optionsp (struct gcc_optio
returns false.  */
 
 bool
-hook_uint_uintp_false (unsigned int, unsigned int *)
+hook_bool_uint_uintp_false (unsigned int, unsigned int *)
 {
   return false;
 }
-
--- gcc/target.def.jj   2016-09-23 09:32:13.0 +0200
+++ gcc/target.def  2016-09-23 11:59:03.581525303 +0200
@@ -446,7 +446,7 @@ instead of the normal sequence of letter
 defined, or if it returns false, then @var{num} will be ignored and the\n\
 traditional letter sequence will be emitted.",
  bool, (unsigned int flags, unsigned int *num),
- hook_uint_uintp_false)
+ hook_bool_uint_uintp_false)
 
 /* Return preferred text (sub)section for function DECL.
Main purpose of this function is to separate cold, normal and hot


Jakub

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Andre Vieira (lists)]

On 23/09/16 11:04, Jakub Jelinek wrote:
> On Thu, Sep 22, 2016 at 10:37:21PM +0200, Uros Bizjak wrote:
>> diff --git a/gcc/hooks.c b/gcc/hooks.c
>> index 
>> 99ec4014adb6fcbb073bf538dd00fe8695ee6cb2..1e925645c3173f8d97e104b9b2f480fca2ede438
>> 100644
>> --- a/gcc/hooks.c
>> +++ b/gcc/hooks.c
>> @@ -481,3 +481,13 @@ void
>>   hook_void_gcc_optionsp (struct gcc_options *opts ATTRIBUTE_UNUSED)
>>   {
>>   }
>> +
>> +/* Generic hook that takes an unsigned int, an unsigned int pointer and
>> +   returns false.  */
>> +
>> +bool
>> +hook_uint_uintp_false (unsigned int, unsigned int *)
>> +{
>> +  return false;
>> +}
>>
>>
>> The name of this hook doesn't adhere to the convention. It should be named:
>>
>> hook_bool_uint_uintp_false
> 
> You're right, I've committed this as obvious:
> 
> 2016-09-23  Uros Bizjak  
>   Jakub Jelinek  
> 
>   * hooks.h (hook_uint_uintp_false): Rename to...
>   (hook_bool_uint_uintp_false): ... this.
>   * hooks.c (hook_uint_uintp_false): Rename to...
>   (hook_bool_uint_uintp_false): ... this.
>   * target.def (elf_flags_numeric): Use hook_bool_uint_uintp_false
>   instead of hook_uint_uintp_false.
> 
> --- gcc/hooks.h.jj2016-09-23 09:32:13.0 +0200
> +++ gcc/hooks.h   2016-09-23 11:57:28.116738504 +0200
> @@ -76,7 +76,7 @@ extern void hook_void_tree (tree);
>  extern void hook_void_tree_treeptr (tree, tree *);
>  extern void hook_void_int_int (int, int);
>  extern void hook_void_gcc_optionsp (struct gcc_options *);
> -extern bool hook_uint_uintp_false (unsigned int, unsigned int *);
> +extern bool hook_bool_uint_uintp_false (unsigned int, unsigned int *);
>  
>  extern int hook_int_uint_mode_1 (unsigned int, machine_mode);
>  extern int hook_int_const_tree_0 (const_tree);
> --- gcc/hooks.c.jj2016-09-23 09:32:13.0 +0200
> +++ gcc/hooks.c   2016-09-23 11:57:39.938588268 +0200
> @@ -486,8 +486,7 @@ hook_void_gcc_optionsp (struct gcc_optio
> returns false.  */
>  
>  bool
> -hook_uint_uintp_false (unsigned int, unsigned int *)
> +hook_bool_uint_uintp_false (unsigned int, unsigned int *)
>  {
>return false;
>  }
> -
> --- gcc/target.def.jj 2016-09-23 09:32:13.0 +0200
> +++ gcc/target.def2016-09-23 11:59:03.581525303 +0200
> @@ -446,7 +446,7 @@ instead of the normal sequence of letter
>  defined, or if it returns false, then @var{num} will be ignored and the\n\
>  traditional letter sequence will be emitted.",
>   bool, (unsigned int flags, unsigned int *num),
> - hook_uint_uintp_false)
> + hook_bool_uint_uintp_false)
>  
>  /* Return preferred text (sub)section for function DECL.
> Main purpose of this function is to separate cold, normal and hot
> 
> 
>   Jakub
> 

The hook that keeps on giving. Thanks! And one more time, sorry!

Cheers,
Andre

Re: [Fortran, accaf, patch, v1] Fixing compatibility with opencoarrays (mostly)

[Andre Vehreschild]

Hi Paul,

thanks for the review. Committed as r240419.

Regards,
Andre

On Thu, 22 Sep 2016 19:28:49 +0200
Paul Richard Thomas  wrote:

> Dear Andre,
> 
> Yes, this is fine for trunk. Thanks for fixing it so quickly.
> 
> Best regards
> 
> Paul
> 
> On 22 September 2016 at 17:09, Andre Vehreschild  wrote:
> > Hi all,
> >
> > attached patch fixes compatibility with opencoarrays by using the old
> > coarray interface of caf_get() as long as possible.
> >
> > Bootstrapped and regtested ok on x86_64-linux/F23. Ok for trunk?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de  
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 240418)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2016-09-22  Andre Vehreschild  
+
+	* trans-intrinsic.c (gfc_conv_intrinsic_caf_get): Use the old caf-
+	interface where possible.
+
 2016-09-22  Paul Thomas  
 
 	* interface.c (check_dtio_interface1): Introduce errors for
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c	(Revision 240418)
+++ gcc/fortran/trans-intrinsic.c	(Arbeitskopie)
@@ -1607,10 +1607,9 @@
   else
 stat = null_pointer_node;
 
-  /* Always use the new get_by_ref ().  When no allocatable components are
- present and the lhs does not reallocation then the "old" get () might
- suffice.  */
-  if (true) //caf_attr->alloc_comp && !may_realloc)
+  /* Only use the new get_by_ref () where it is necessary.  I.e., when the lhs
+ is reallocatable or the right-hand side has allocatable components.  */
+  if (caf_attr->alloc_comp || may_realloc)
 {
   /* Get using caf_get_by_ref.  */
   caf_reference = conv_expr_ref_to_caf_ref (&se->pre, array_expr);
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 240418)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2016-09-23  Andre Vehreschild  
+
+	* gfortran.dg/coarray_lib_comm_1.f90: Using the old caf-interface
+	here now.
+
 2016-09-23  Matthew Wahab  
 
 	* gcc.target/arm/armv8_2-fp16-arith-1.c: Use arm_v8_2a_fp16_neon
Index: gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
===
--- gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90	(Revision 240418)
+++ gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90	(Arbeitskopie)
@@ -40,7 +40,7 @@
 
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, _gfortran_caf_this_image \\\(0\\\), &parm.\[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, 4, 4, 0, 0B\\\);" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, _gfortran_caf_this_image \\\(0\\\), &parm.\[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, 4, 4, 1, 0B\\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get_by_ref \\\(caf_token.0, 1, &p, &caf_ref.\[0-9\]+, 4, 4, 1, 0, 0B\\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get_by_ref \\\(caf_token.1, 1, &p, &caf_ref.\[0-9\]+, 4, 4, 0, 0, 0B\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=8\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=8\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, &p, 4, 4, 1, 0B\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.1, \\\(integer\\\(kind=8\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=8\\\)\\\) b, 1, &parm.\[0-9\]+, 0B, &p, 4, 4, 0, 0B\\\);" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, 4, 4, 0, 0B\\\);" 1 "original" } }
 

Re: [PATCHv2][ARM] -mpure-code option for ARM

[Andre Vieira (lists)]

On 23/09/16 09:33, Andre Vieira (lists) wrote:
> On 23/09/16 02:21, Sandra Loosemore wrote:
>> On 09/22/2016 07:52 AM, Richard Earnshaw (lists) wrote:
>>> On 11/07/16 17:56, Andre Vieira (lists) wrote:
 +
 diff --git a/gcc/target.def b/gcc/target.def
 index
 a4df363698ce776b51d11c187baed2069ba88a52..a3d46fa48d919a16699c33b2b78236e62a33e025
 100644
 --- a/gcc/target.def
 +++ b/gcc/target.def
 @@ -432,6 +432,19 @@ this section is associated.",
void, (const char *name, unsigned int flags, tree decl),
default_no_named_section)

 +/* Tell assembler what section attributes to assign this elf section
 +   declaration, using their numerical value.  */
 +DEFHOOK
 +(elf_flags_numeric,
 + "If the target needs to represent ELF section attributes using
 their\n\
 +numerical value, then this hook should be implemented to return true
 and\n\
 +write the numerical value of @var{flags} in @var{num}.  This
 function is\n\
 +called by @code{default_elf_asm_named_section}, which prints
 @var{num}\n\
 +as the value representing the ELF section attributes if this
 function\n\
 +returns true.",
>>>
>>>
>>> I think this should read something like.
>>>
>>> This hook can be used to encode ELF section flags for which no letter
>>> code has been defined in the assembler.  It is called by
>>> @code{default_asm_named_section} whenever the section flags need to be
>>> emitted in the assembler output.  If the hook returns true, then the
>>> numerical value for ELF section flags should be calculated from
>>> @var{flags} and saved in @var{*num}; the value will be printed out
>>> instead of the normal sequence of letter codes.  If the hook is not
>>> defined, or if it returns false, then @var{num} will be ignored and the
>>> traditional letter sequence will be emitted.
>>
>> Can we please write this in the present tense instead of the future,
>> assuming it describes current behavior (as modified by the patch)?
>>
>> s/will be/is/g
>>
>> -Sandra
>>
> Hi Sandra,
> 
> Is this better?
> 
> Cheers,
> Andre
> 
> gcc/ChangeLog
> 2016-09-23  Andre Vieira  
> 
> * target.def(elf_flags_numeric): Change documentation to
> present tense.
> 
And here is the patch with the tm.texi regeneration.

Cheers,
Andre

gcc/ChangeLog
2016-09-23  Andre Vieira  

* target.def(elf_flags_numeric): Change documentation to
present tense.
* doc/tm.texi: Regenerate.
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 
68a77e81aa1e2abcc15bc9088011295df699c4d0..8a98ba43a67eac87c2be8a974f6c0b924e519f52
 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -7574,10 +7574,10 @@ code has been defined in the assembler.  It is called by
 @code{default_asm_named_section} whenever the section flags need to be
 emitted in the assembler output.  If the hook returns true, then the
 numerical value for ELF section flags should be calculated from
-@var{flags} and saved in @var{*num}; the value will be printed out
-instead of the normal sequence of letter codes.  If the hook is not
-defined, or if it returns false, then @var{num} will be ignored and the
-traditional letter sequence will be emitted.
+@var{flags} and saved in @var{*num}; the value is printed out instead of the
+normal sequence of letter codes.  If the hook is not defined, or if it
+returns false, then @var{num} is ignored and the traditional letter sequence
+is emitted.
 @end deftypefn
 
 @deftypefn {Target Hook} {section *} TARGET_ASM_FUNCTION_SECTION (tree 
@var{decl}, enum node_frequency @var{freq}, bool @var{startup}, bool @var{exit})
diff --git a/gcc/target.def b/gcc/target.def
index 
ac693318adaaa230ea300f10bc37282881d9da6f..4adb8aabc6548889b717abc9310e98f0e6fc161b
 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -441,10 +441,10 @@ code has been defined in the assembler.  It is called 
by\n\
 @code{default_asm_named_section} whenever the section flags need to be\n\
 emitted in the assembler output.  If the hook returns true, then the\n\
 numerical value for ELF section flags should be calculated from\n\
-@var{flags} and saved in @var{*num}; the value will be printed out\n\
-instead of the normal sequence of letter codes.  If the hook is not\n\
-defined, or if it returns false, then @var{num} will be ignored and the\n\
-traditional letter sequence will be emitted.",
+@var{flags} and saved in @var{*num}; the value is printed out instead of the\n\
+normal sequence of letter codes.  If the hook is not defined, or if it\n\
+returns false, then @var{num} is ignored and the traditional letter sequence\n\
+is emitted.",
  bool, (unsigned int flags, unsigned int *num),
  hook_uint_uintp_false)
 

Re: [PATCH] Use CONSTRUCTOR_NELTS macro some more

[Bernd Schmidt]

On 09/22/2016 10:07 PM, Jakub Jelinek wrote:

I've noticed lots of vec_safe_length (CONSTRUCTOR_ELTS (...)) uses
in the sources, which IMHO are less readable than the much more often
used CONSTRUCTOR_NELTS (...) macro that does the same thing.

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


Ok.


Bernd

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

[Jonathan Wakely]

On 22/09/16 20:22 +0200, Christophe Lyon wrote:

On 22 September 2016 at 15:25, Jonathan Wakely  wrote:

On 22/09/16 12:15 +0100, Jonathan Wakely wrote:


On 22/09/16 11:16 +0100, Jonathan Wakely wrote:


(Somebody should fix PR58938 so exception_ptr is portable).



Christophe, would you be able to test this patch?

It uses a single global mutex for exception_ptr objects, which doesn't
scale well but that probably isn't a problem for processors without
lock-free atomics for single words.

This also solves the problem of mismatched -march options, where the
header is compiled for a CPU that supports the atomics but
libstdc++.so was built for an older CPU that doesn't support them, and
linking fails (as in https://gcc.gnu.org/PR58938#c13).



We'd also need something like this extra piece, to ensure we don't
leak exceptions. Currently __gxx_exception_cleanup assumes that if
ATOMIC_INT_LOCK_FREE < 2 the referenceCount can never be greater than
1, because there are not exception_ptr objects that could increase it.

If we enable exception_ptr unconditionally then that assumption
doesn't hold. This patch uses the exception_ptr code to do the
cleanup, under the same mutex as any other increments and decrements
of the reference count.

It's a bit of a hack though.


Should I have applied this one on top of the other?

I ran a validation with it alone, and
arm-none-eabi with default mode, cpu, and fpu does not build:


That's expected, the second patch requires the first one (you can't
use exception_ptr unconditionally if it's only defined conditionally
:-)



In file included from
/tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_throw.cc:27:0:
/tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/exception_ptr.h:43:4:
error: #error This platform does
not support exception propagation.
#  error This platform does not support exception propagation.
   ^
make[4]: *** [eh_throw.lo] Error 1


In addition, on arm-none-eabi --with-mode=thumb --with-cpu=cortex-a9,
I've noticed a regression in c++
 - PASS now FAIL [PASS => FAIL]:

 g++.dg/opt/pr36449.C  -std=gnu++11 execution test
 g++.dg/opt/pr36449.C  -std=gnu++14 execution test
 g++.dg/opt/pr36449.C  -std=gnu++98 execution test

My logs show:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped


Strange, I don't see how my patch could cause that.



The validation of the other patch is still running: I had to re-run it
because the
patch didn't apply because of the ChangeLog entry.

Re: C/C++ PATCH to implement -Wbool-operation (PR c/77490)

[Marek Polacek]

On Thu, Sep 22, 2016 at 05:24:31PM +, Joseph Myers wrote:
> On Wed, 21 Sep 2016, Marek Polacek wrote:
> 
> > > > > And let's refer to "expression of type bool" rather than "boolean
> > > > > expression".
> > > > 
> > > > Adjusted (and in the C FE too).
> > > 
> > > Hmm, I'm not sure that change is right for C.  But the C++ hunk is OK.
> > 
> > Thanks.  Joseph, how about the C part?
> 
> You shouldn't refer to "type bool" for C.  If it's the result of a boolean 
> operation, the type is int; an expression has type _Bool only if cast to 
> that type or if it's a variable of that type.

Ok, so how about this one?

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

2016-09-23  Marek Polacek  

PR c/77490
* c.opt (Wbool-operation): New.

* c-typeck.c (build_unary_op): Warn about bit not on expressions that
have boolean value.  Warn about ++/-- on booleans.

* typeck.c (cp_build_unary_op): Warn about bit not on expressions that
have boolean value.

* doc/invoke.texi: Document -Wbool-operation.

* c-c++-common/Wbool-operation-1.c: New test.
* gcc.dg/Wbool-operation-1.c: New test.

diff --git gcc/c-family/c.opt gcc/c-family/c.opt
index a04618d..4a9b9e8 100644
--- gcc/c-family/c.opt
+++ gcc/c-family/c.opt
@@ -315,6 +315,10 @@ Wbool-compare
 C ObjC C++ ObjC++ Var(warn_bool_compare) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wall)
 Warn about boolean expression compared with an integer value different from 
true/false.
 
+Wbool-operation
+C ObjC C++ ObjC++ Var(warn_bool_op) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wall)
+Warn about certain operations on boolean expressions.
+
 Wframe-address
 C ObjC C++ ObjC++ Var(warn_frame_address) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wall)
 Warn when __builtin_frame_address or __builtin_return_address is used unsafely.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 059ad1f..e5c7256 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -4196,6 +4196,22 @@ build_unary_op (location_t location, enum tree_code 
code, tree xarg,
  || (typecode == VECTOR_TYPE
  && !VECTOR_FLOAT_TYPE_P (TREE_TYPE (arg
{
+ tree e = arg;
+
+ /* Warn if the expression has boolean value.  */
+ while (TREE_CODE (e) == COMPOUND_EXPR)
+   e = TREE_OPERAND (e, 1);
+
+ if ((TREE_CODE (TREE_TYPE (arg)) == BOOLEAN_TYPE
+  || truth_value_p (TREE_CODE (e)))
+ && warning_at (location, OPT_Wbool_operation,
+"%<~%> on a boolean expression"))
+   {
+ gcc_rich_location richloc (location);
+ richloc.add_fixit_insert_before (location, "!");
+ inform_at_rich_loc (&richloc, "did you mean to use logical "
+ "not?");
+   }
  if (!noconvert)
arg = default_conversion (arg);
}
@@ -4306,6 +4322,16 @@ build_unary_op (location_t location, enum tree_code 
code, tree xarg,
"decrement of enumeration value is invalid in C++");
}
 
+  if (TREE_CODE (TREE_TYPE (arg)) == BOOLEAN_TYPE)
+   {
+ if (code == PREINCREMENT_EXPR || code == POSTINCREMENT_EXPR)
+   warning_at (location, OPT_Wbool_operation,
+   "increment of a boolean expression");
+ else
+   warning_at (location, OPT_Wbool_operation,
+   "decrement of a boolean expression");
+   }
+
   /* Ensure the argument is fully folded inside any SAVE_EXPR.  */
   arg = c_fully_fold (arg, false, NULL);
 
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index c53a85a..dee17b3 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -5792,6 +5792,7 @@ cp_build_unary_op (enum tree_code code, tree xarg, bool 
noconvert,
 {
   /* No default_conversion here.  It causes trouble for ADDR_EXPR.  */
   tree arg = xarg;
+  location_t location = EXPR_LOC_OR_LOC (arg, input_location);
   tree argtype = 0;
   const char *errstring = NULL;
   tree val;
@@ -5853,7 +5854,14 @@ cp_build_unary_op (enum tree_code code, tree xarg, bool 
noconvert,
   arg, true)))
errstring = _("wrong type argument to bit-complement");
   else if (!noconvert && CP_INTEGRAL_TYPE_P (TREE_TYPE (arg)))
-   arg = cp_perform_integral_promotions (arg, complain);
+   {
+ /* Warn if the expression has boolean value.  */
+ if (TREE_CODE (TREE_TYPE (arg)) == BOOLEAN_TYPE
+ && warning_at (location, OPT_Wbool_operation,
+"%<~%> on an expression of type bool"))
+   inform (location, "did you mean to use logical not (%)?");
+ arg = cp_perform_integral_promotions (arg, complain);
+   }
   break;
 
 case ABS_EXPR:
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index e6f503f..a5481b5 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -256,8 +256,8 @@ Objective-C and O

Re: [PATCH 0/3] S/390: Improved risbg usage.

[Andreas Krebbel]

On 09/20/2016 02:37 PM, Dominik Vogt wrote:
> The following series of patches improves usage of the risbg and
> risbgn instructions on s390/s390x.  The patches have been
> regression tested on s390 and s390x and pass the Spec2006
> testsuite without any negative effects.
> 
> Patch 1 introduces a new mode attribute to simplify some
> instruction patterns.
> 
> Patch 2 enables wraparound of bit ranges and rewrites portion of
> the bitrange calculation code to do so.
> 
> Patch 3 adds new patterns and tests based on the first two patches
> to make better use of the risbg and risbgn instructions.
> 
> Please check the individual Changelogs for details.

Applied. Thanks!

-Andreas-

[gomp4] Fix tile parsing

[Nathan Sidwell]

In working on implementing tile, I discovered the parsing of tile clauses was at 
best confused.  (The spec didn't help by being somewhat vague and not 
considering interaction with the collapse clause)


Fixed with the attached patch.

nathan
2016-09-23  Nathan Sidwell  

	c/
	* c-parser.c (c_parser_omp_clause_collapse): Disallow tile.
	(c_parser_oacc_clause_tile): Disallow collapse. Fix parsing and
	semantic checking.

	cp/
	* parser.c (cp_parser_oacc_clause_tile): Disallow collapse.  Fix
	parsing.  Parse constant expression. Remove semantic checking.
	(cp_parser_omp_clause_collapse): Disallow tile.
	* pt.c (tsubst_omp_clauses): Require integral constant expression
	for COLLAPSE and TILE.  Remove broken TILE subst.
	* semantics.c (finish_omp_clauses): Correct TILE semantic check.

	testsuite/
	* c-c++-common/goacc/tile.c: Include stdbool, fix expected errors.
	* g++.dg/goacc/template.C: Test tile subst.  Adjust erroneous
	uses.
	* g++.dg/goacc/tile-1.C: Check tile subst.

Index: c/c-parser.c
===
--- c/c-parser.c	(revision 240420)
+++ c/c-parser.c	(working copy)
@@ -10882,6 +10882,7 @@ c_parser_omp_clause_collapse (c_parser *
   location_t loc;
 
   check_no_duplicate_clause (list, OMP_CLAUSE_COLLAPSE, "collapse");
+  check_no_duplicate_clause (list, OMP_CLAUSE_TILE, "tile");
 
   loc = c_parser_peek_token (parser)->location;
   if (c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
@@ -11905,10 +11906,11 @@ static tree
 c_parser_oacc_clause_tile (c_parser *parser, tree list)
 {
   tree c, expr = error_mark_node;
-  location_t loc, expr_loc;
+  location_t loc;
   tree tile = NULL_TREE;
 
   check_no_duplicate_clause (list, OMP_CLAUSE_TILE, "tile");
+  check_no_duplicate_clause (list, OMP_CLAUSE_COLLAPSE, "collapse");
 
   loc = c_parser_peek_token (parser)->location;
   if (!c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
@@ -11916,16 +11918,19 @@ c_parser_oacc_clause_tile (c_parser *par
 
   do
 {
+  if (tile && !c_parser_require (parser, CPP_COMMA, "expected %<,%>"))
+	return list;
+
   if (c_parser_next_token_is (parser, CPP_MULT)
 	  && (c_parser_peek_2nd_token (parser)->type == CPP_COMMA
 	  || c_parser_peek_2nd_token (parser)->type == CPP_CLOSE_PAREN))
 	{
 	  c_parser_consume_token (parser);
-	  expr = integer_minus_one_node;
+	  expr = integer_zero_node;
 	}
   else
 	{
-	  expr_loc = c_parser_peek_token (parser)->location;
+	  location_t expr_loc = c_parser_peek_token (parser)->location;
 	  expr = c_parser_expr_no_commas (parser, NULL).value;
 
 	  if (expr == error_mark_node)
@@ -11935,29 +11940,21 @@ c_parser_oacc_clause_tile (c_parser *par
 	  return list;
 	}
 
-	  if (!INTEGRAL_TYPE_P (TREE_TYPE (expr)))
-	{
-	  c_parser_error (parser, "% value must be integral");
-	  return list;
-	}
-
 	  mark_exp_read (expr);
 	  expr = c_fully_fold (expr, false, NULL);
 
-	  /* Attempt to statically determine when expr isn't positive.  */
-	  c = fold_build2_loc (expr_loc, LE_EXPR, boolean_type_node, expr,
-			   build_int_cst (TREE_TYPE (expr), 0));
-	  protected_set_expr_location (c, expr_loc);
-	  if (c == boolean_true_node)
+	  if (!INTEGRAL_TYPE_P (TREE_TYPE (expr))
+	  || TREE_CODE (expr) != INTEGER_CST
+	  || !tree_fits_shwi_p (expr)
+	  || tree_to_shwi (expr) <= 0)
 	{
-	  warning_at (expr_loc, 0,"% value must be positive");
-	  expr = integer_one_node;
+	  error_at (expr_loc, "% argument needs positive"
+			" integral constant");
+	  expr = integer_zero_node;
 	}
 	}
 
   tile = tree_cons (NULL_TREE, expr, tile);
-  if (c_parser_next_token_is (parser, CPP_COMMA))
-	c_parser_consume_token (parser);
 }
   while (c_parser_next_token_is_not (parser, CPP_CLOSE_PAREN));
 
Index: cp/parser.c
===
--- cp/parser.c	(revision 240420)
+++ cp/parser.c	(working copy)
@@ -30434,30 +30434,33 @@ cp_parser_oacc_clause_tile (cp_parser *p
   tree c, expr = error_mark_node;
   tree tile = NULL_TREE;
 
+  /* Collapse and tile are mutually exclusive.  (The spec doesn't say
+ so, but the spec authors never considered such a case and have
+ differing opinions on what it might mean, including 'not
+ allowed'.)  */
   check_no_duplicate_clause (list, OMP_CLAUSE_TILE, "tile", clause_loc);
+  check_no_duplicate_clause (list, OMP_CLAUSE_COLLAPSE, "collapse",
+			 clause_loc);
 
   if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
 return list;
 
   do
 {
+  if (tile && !cp_parser_require (parser, CPP_COMMA, RT_COMMA))
+	return list;
+  
   if (cp_lexer_next_token_is (parser->lexer, CPP_MULT)
 	  && (cp_lexer_nth_token_is (parser->lexer, 2, CPP_COMMA)
 	  || cp_lexer_nth_token_is (parser->lexer, 2, CPP_CLOSE_PAREN)))
 	{
 	  cp_lexer_consume_token (parser->lexer);
-	  expr = integer_minus_one_node;
+	  expr = integer_zero_node;
 	

Re: Report DejaGnu ERROR messages in dg-extract-results

[Rainer Orth]

Hi Christophe,

> We recently faced a problem where a DejaGnu error went un-noticed
> (https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01879.html).

I just noticed that your patch contained an unrelated and bogus change,
reverted as follows.  This will only show up on targets that lack (a
sufficiently recent version of) python, Solaris 10 in my case.

Rainer


2016-09-23  Rainer Orth  

* dg-extract-results.sh: Revert bogus change.

diff --git a/contrib/dg-extract-results.sh b/contrib/dg-extract-results.sh
--- a/contrib/dg-extract-results.sh
+++ b/contrib/dg-extract-results.sh
@@ -434,7 +434,7 @@ BEGIN {
 /^# of unresolved testcases/	{ unrescnt += \$5 }
 /^# of unsupported tests/	{ unsupcnt += \$5 }
 END {
-  printf ("\n\t\t=== %s MySummary ===\n\n", tool)
+  printf ("\n\t\t=== %s Summary ===\n\n", tool)
   if (dgerrorcnt != 0) printf ("# of DejaGnu errors\t\t%d\n", dgerrorcnt)
   if (passcnt != 0) printf ("# of expected passes\t\t%d\n", passcnt)
   if (failcnt != 0) printf ("# of unexpected failures\t%d\n", failcnt)

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

Re: [PATCH] Bits from Early LTO debug merge -- move stuff from late to early finish

[Richard Biener]

On Fri, 23 Sep 2016, Richard Biener wrote:

> On Thu, 22 Sep 2016, Richard Biener wrote:
> 
> > 
> > This merges moving of unused type pruning from late to early finish as 
> > well as handling of debug types and dwarf2 dups elimination.  It adds
> > a flag to DIEs so we can mark them as removed in case sth after
> > early finish tries to lookup a DIE for a removed DIE again - we shouldn't
> > re-use the removed DIE (w/o parent) there.
> > 
> > I suppose at some point we should re-think how pruning of "unused"
> > stuff is supposed to work.  Given my grand plan is to get rid of
> > debug hooks and allow FEs direct control over the DWARF it should
> > be ultimatively their decision what to remove (err, not create, in
> > the first place).
> > 
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu, ok for trunk?
> 
> Testing this separately shows the need to port another hunk.  If we
> prune types early we have to make sure to not re-create them late
> via typedefs in BLOCKs.
> 
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c (revision 240363)
> +++ gcc/dwarf2out.c (working copy)
> @@ -23255,7 +23242,13 @@ process_scope_var (tree stmt, tree decl,
>  die = lookup_decl_die (decl_or_origin);
>else if (TREE_CODE (decl_or_origin) == TYPE_DECL
> && TYPE_DECL_IS_STUB (decl_or_origin))
> -die = lookup_type_die (TREE_TYPE (decl_or_origin));
> +{
> +  /* Avoid re-creating the DIE late if it was optimized
> +as unused early (this BLOCK reference does not count as "use").  
> */
> +  die = lookup_type_die (TREE_TYPE (decl_or_origin));
> +  if (! die)
> +   return;
> +}
>else
>  die = NULL;

Testing went fine if you consider moving

+  /* Generate separate CUs for each of the include files we've seen.
+ They will go into limbo_die_list.  */
+  if (flag_eliminate_dwarf2_dups)
+break_out_includes (comp_unit_die ());

not being part of this patch.  I did statistics over patched/unpatched
GCC by means of

readelf -wi gcc/.o | grep 'DW_TAG_[_a-z]*type' | wc -l

and the difference is in the noise (diff unpatched patched):

-gcc/alias.o 2639
+gcc/alias.o 2640
-gcc/auto-profile.o 4941
-gcc/bb-reorder.o 2243
+gcc/auto-profile.o 4945
+gcc/bb-reorder.o 2315
-gcc/bt-load.o 1837
+gcc/bt-load.o 1836
-gcc/cfg.o 1350
+gcc/cfg.o 1349
...

There are DW_TAG_typedef no longer occuring (from vec.o):

 <1>: Abbrev Number: 180 (DW_TAG_subprogram)
   DW_AT_specification: <0x6a3a>
   DW_AT_inline  : 3  (declared as inline and inlined)
   DW_AT_sibling : <0xe7ff>
 <2>: Abbrev Number: 63 (DW_TAG_formal_parameter)
   DW_AT_name: (indirect string, offset: 0x3f48): alloc
   DW_AT_decl_file   : 5
   DW_AT_decl_line   : 1050
   DW_AT_type: <0x6d>
 <2>: Abbrev Number: 51 (DW_TAG_typedef)
   DW_AT_name: (indirect string, offset: 0x1435f): 
vec_embedde
d
   DW_AT_decl_file   : 5
   DW_AT_decl_line   : 1052
   DW_AT_type: <0x665a>
 <2>: Abbrev Number: 0

The DW_TAG_typedef is missing in the patched variant.  This DIE is
not refered to in the the unpatched variant (I didn't check why we
don't prune it).

There appear some extra stray DW_TAG_typedef DIEs though:

 <13><11a28>: Abbrev Number: 207 (DW_TAG_typedef)
 <13><11a2a>: Abbrev Number: 0

I'll check where those come from.

Thanks,
Richard.

> Richard.
> 
> > I believe this is the last part I can reasonably split out (but I'll
> > have a second look after merging back from trunk once this and the other
> > pending patch is approved).
> > 
> > Thanks,
> > Richard.
> > 
> > 2016-09-22  Richard Biener  
> > 
> > * dwarf2out.c (struct die_struct): Add removed flag.
> > (lookup_type_die): If the DIE is marked as removed, clear
> > TYPE_SYMTAB_DIE and return NULL.
> > (lookup_decl_die): If the DIE is marked as removed, remove it
> > from the hash and return NULL.
> > (mark_removed): New helper.
> > (prune_unused_types_prune): Call it for removed DIEs.
> > (dwarf2out_finish): Move unused type pruning debug_types handling
> > and breaking out includes ...
> > (dwarf2out_early_finish): ... here.
> > 
> > Index: gcc/dwarf2out.c
> > ===
> > --- gcc/dwarf2out.c (revision 240353)
> > +++ gcc/dwarf2out.c (working copy)
> > @@ -2705,6 +2705,10 @@ typedef struct GTY((chain_circular ("%h.
> >/* Die is used and must not be pruned as unused.  */
> >BOOL_BITFIELD die_perennial_p : 1;
> >BOOL_BITFIELD comdat_type_p : 1; /* DIE has a type signature */
> > +  /* Whether this DIE was removed from the DIE tree, for example via
> > + prune_unused_types.  We don't consider those present from the
> > + DIE lookup routines.  */
> > +  BOOL_BITFIELD removed : 1;
> >/* Lots of spare bits.  */
> >  }
> >  die_node;
> > @@ -5098,7 +5102,13 @@ new_die (enum dwarf_tag tag_

[PATCH] Fix handling of -fsanitize-recover* options.

[Martin Liška]

Hi.

Following patch handles various issues related to -fsanitize-recover*
options:

1) -fsanitize-recover=unreachable and -fsanitize-recover=return are
   currently not reported as invalid options (error message is not
   displayed)

2) explanation of -fsanitize-recover is not precise (bounds-strict is
   not listed)

3) -fsanitize=leak is combinable with -fsanitize=address or
   -fsanitize=thread

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From 077f6945e612f97ca16b792dd3f0740410b513af Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 23 Sep 2016 10:16:10 +0200
Subject: [PATCH] Fix handling of -fsanitize-recover* options.

gcc/ChangeLog:

2016-09-23  Martin Liska  

	* common.opt: Exclude SANITIZE_UNREACHABLE and SANITIZE_RETURN
	from default sanitize recover values.
	* doc/invoke.texi: Fix documentation related to -fsanitize=leak
	and -fsanitize-recover.
	* flag-types.h: Replace couple of 1 << x to 1UL << x, make it
	consistent.
	* opts.c (finish_options): Do a generic loop over options
	that can be recovered.
	(parse_sanitizer_options): Exclude SANITIZE_UNREACHABLE and
	SANITIZE_RETURN.
	(common_handle_option): Likewise.
	* opts.h: Declare can_recover to sanitizer_opts_s.
---
 gcc/common.opt |  2 +-
 gcc/doc/invoke.texi| 10 +--
 gcc/flag-types.h   | 32 -
 gcc/opts.c | 82 --
 gcc/opts.h |  1 +
 .../c-c++-common/ubsan/sanitize-recover-1.c|  6 ++
 .../c-c++-common/ubsan/sanitize-recover-2.c|  6 ++
 .../c-c++-common/ubsan/sanitize-recover-3.c|  4 ++
 .../c-c++-common/ubsan/sanitize-recover-4.c|  4 ++
 .../c-c++-common/ubsan/sanitize-recover-5.c|  6 ++
 .../c-c++-common/ubsan/sanitize-recover-6.c|  4 ++
 11 files changed, 99 insertions(+), 58 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/sanitize-recover-1.c
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/sanitize-recover-2.c
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/sanitize-recover-3.c
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/sanitize-recover-4.c
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/sanitize-recover-5.c
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/sanitize-recover-6.c

diff --git a/gcc/common.opt b/gcc/common.opt
index 8c0885c..f35660f 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -228,7 +228,7 @@ unsigned int flag_sanitize
 
 ; What sanitizers should recover from errors
 Variable
-unsigned int flag_sanitize_recover = SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT | SANITIZE_KERNEL_ADDRESS
+unsigned int flag_sanitize_recover = (SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT | SANITIZE_KERNEL_ADDRESS) & ~(SANITIZE_UNREACHABLE | SANITIZE_RETURN)
 
 fsanitize-coverage=trace-pc
 Common Report Var(flag_sanitize_coverage)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d474da6..52804c0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10173,9 +10173,8 @@ supported options.
 @item -fsanitize=leak
 @opindex fsanitize=leak
 Enable LeakSanitizer, a memory leak detector.
-This option only matters for linking of executables and if neither
-@option{-fsanitize=address} nor @option{-fsanitize=thread} is used.  In that
-case the executable is linked against a library that overrides @code{malloc}
+This option only matters for linking of executables and
+the executable is linked against a library that overrides @code{malloc}
 and other allocator functions.  See
 @uref{https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer} for more
 details.  The run-time behavior can be influenced using the
@@ -10353,6 +10352,7 @@ and program then exits with a non-zero exit code.
 Currently this feature only works for @option{-fsanitize=undefined} (and its suboptions
 except for @option{-fsanitize=unreachable} and @option{-fsanitize=return}),
 @option{-fsanitize=float-cast-overflow}, @option{-fsanitize=float-divide-by-zero},
+@option{-fsanitize=bounds-strict},
 @option{-fsanitize=kernel-address} and @option{-fsanitize=address}.
 For these sanitizers error recovery is turned on by default, except @option{-fsanitize=address},
 for which this feature is experimental.
@@ -10369,12 +10369,12 @@ setting the @code{halt_on_error} flag in the corresponding environment variable.
 
 Syntax without explicit @var{opts} parameter is deprecated.  It is equivalent to
 @smallexample
--fsanitize-recover=undefined,float-cast-overflow,float-divide-by-zero
+-fsanitize-recover=undefined,float-cast-overflow,float-divide-by-zero,bounds-strict
 @end smallexample
 @noindent
 Similarly @option{-fno-sanitize-recover} is equivalent to
 @smallexample
--fno-sanitize-recover=undefined,float-cast-overflow,float-divide-by-zero
+-fno-sanitize-recover=undefined,float-cast-overflow,float-divide-by-zero,bo

Re: [Patch, fortran] Clean up of error recovery in DTIO procedures

[Rainer Orth]

Hi Paul,

> Dear All,
>
> Please find attached a patch to clean up the various issues with
> errors in DTIO procedures. The tests were all provided by Gerhard
> Steinmetz for which thanks are due.
>
> I intend to commit this patch as 'obvious' tomorrow morning unless
> there are any objections in the meantime.
>
> Bootstrapped and regtested on x86_64/FC21 - OK for trunk?
>
> Paul
>
> 2016-09-21  Paul Thomas  
>
> * interface.c (check_dtio_interface1): Introduce errors for
> alternate returns and incorrect numbers of arguments.
> (gfc_find_specific_dtio_proc): Return cleanly if the derived
> type either doesn't exist or has no namespace.
>
> 2016-09-21  Paul Thomas  
>
> * gfortran.dg/dtio_13.f90: New test.

This test ICEs on Solaris (both sparc and x86, 32 and 64-bit):

FAIL: gfortran.dg/dtio_13.f90   -O   (test for errors, line 141)
FAIL: gfortran.dg/dtio_13.f90   -O  (internal compiler error)
FAIL: gfortran.dg/dtio_13.f90   -O  (test for excess errors)

Excess errors:
f951: internal compiler error: Segmentation Fault
0x8e165ec crash_signal
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:337
0x89357b8 gfc_find_symtree(gfc_symtree*, char const*)
/vol/gcc/src/hg/trunk/local/gcc/fortran/symbol.c:2737
0x8895b77 find_typebound_proc_uop
/vol/gcc/src/hg/trunk/local/gcc/fortran/class.c:2753
0x88c2a60 gfc_find_specific_dtio_proc(gfc_symbol*, bool, bool)
/vol/gcc/src/hg/trunk/local/gcc/fortran/interface.c:4825
0x89166cb resolve_transfer
/vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:8738
0x89166cb gfc_resolve_code(gfc_code*, gfc_namespace*)
/vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:10874
0x8914e9c gfc_resolve_blocks(gfc_code*, gfc_namespace*)
/vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:9616
0x89152e8 gfc_resolve_code(gfc_code*, gfc_namespace*)
/vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:10557
0x89178d1 resolve_codes
/vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:15721
0x89179b1 gfc_resolve(gfc_namespace*)
0x89179b1 gfc_resolve(gfc_namespace*)
/vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:15756
0x8902909 resolve_all_program_units
/vol/gcc/src/hg/trunk/local/gcc/fortran/parse.c:5875
0x8902909 gfc_parse_file()
/vol/gcc/src/hg/trunk/local/gcc/fortran/parse.c:6127
0x8944d30 gfc_be_parse_file
/vol/gcc/src/hg/trunk/local/gcc/fortran/f95-lang.c:198

The failure can be reproduced with

$ f951 gfortran.dg/dtio_13.f90 -quiet -o dtio_13.s

In gdb, I find

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x089357b8 in gfc_find_symtree (st=0x1, 
name=0x83726a6 "_dtio_unformatted_read")
at /vol/gcc/src/hg/trunk/local/gcc/fortran/symbol.c:2737
2737  c = strcmp (name, st->name);
(gdb) p name
$1 = 0x83726a6 "_dtio_unformatted_read"
(gdb) p st->name
Cannot access memory at address 0xd

Rainer

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

[PATCH] Fix PR77697

[Richard Biener]

As noted in the PR defcodefor_name was quite broken - the following
rectifies it.

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

Richard.

2016-09-23  Richard Biener  

PR tree-optimization/77697
* tree-ssa-forwprop.c (defcodefor_name): Remove bogus code,
signal error if we have sth ternary or unhandled.

Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 240388)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -1458,6 +1458,7 @@ defcodefor_name (tree name, enum tree_co
   code1 = TREE_CODE (name);
   arg11 = name;
   arg21 = NULL_TREE;
+  arg31 = NULL_TREE;
   grhs_class = get_gimple_rhs_class (code1);
 
   if (code1 == SSA_NAME)
@@ -1470,20 +1471,18 @@ defcodefor_name (tree name, enum tree_co
  code1 = gimple_assign_rhs_code (def);
  arg11 = gimple_assign_rhs1 (def);
   arg21 = gimple_assign_rhs2 (def);
-  arg31 = gimple_assign_rhs2 (def);
+  arg31 = gimple_assign_rhs3 (def);
}
 }
-  else if (grhs_class == GIMPLE_TERNARY_RHS
-  || GIMPLE_BINARY_RHS
-  || GIMPLE_UNARY_RHS
-  || GIMPLE_SINGLE_RHS)
-extract_ops_from_tree (name, &code1, &arg11, &arg21, &arg31);
+  else if (grhs_class != GIMPLE_SINGLE_RHS)
+code1 = ERROR_MARK;
 
   *code = code1;
   *arg1 = arg11;
   if (arg2)
 *arg2 = arg21;
-  /* Ignore arg3 currently. */
+  if (arg31)
+*code = ERROR_MARK;
 }
 
 

[PATCH] Fix missed debug PR77692

[Richard Biener]

I am testing the following patch which re-instantiates behavior
to emit DW_AT_const_value attributes for optimized out non-readonly
global statics.  Those are readonly by means of the ability to
remove them early (before any optimization such as removing stores
to write-only global vars).  Before my change to make the
late_global_decl debug hook not go via 
add_location_or_const_value_attribute but only 
tree_add_const_value_attribute_for_decl during the early debug phase
the former function ran into rtl_for_decl_location doing

  /* A variable with no DECL_RTL but a DECL_INITIAL is a compile-time 
constant,
 and will have been substituted directly into all expressions that use 
it.
 C does not have such a concept, but C++ and other languages do.  */
  if (!rtl && TREE_CODE (decl) == VAR_DECL && DECL_INITIAL (decl))
rtl = rtl_for_decl_init (DECL_INITIAL (decl), TREE_TYPE (decl));

where obviously at this point of the compilation no DECL_RTL was
created yet (the above code looks fishy to me -- 
tree_add_const_value_attribute_for_decl checks for TREE_READONLY on
the decl).

Anyway, bootstrapping and regtesting the following on 
x86_64-unknown-linux-gnu (it makes gcc.dg/debug/dwarf2/const-2b.c PASS
again).

Comments welcome.

Richard.

2016-09-23  Richard Biener  

PR debug/77692
* cgraphunit.c (analyze_functions): Before early removing
global vars calls the late_global_decl debug handler mark
the variable as readonly.

Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 240388)
+++ gcc/cgraphunit.c(working copy)
@@ -1194,8 +1194,15 @@ analyze_functions (bool first_time)
 at looking at optimized away DECLs, since
 late_global_decl will subsequently be called from the
 contents of the now pruned symbol table.  */
- if (!decl_function_context (node->decl))
-   (*debug_hooks->late_global_decl) (node->decl);
+ if (TREE_CODE (node->decl) == VAR_DECL
+ && !decl_function_context (node->decl))
+   {
+ /* We are reclaiming totally unreachable code and variables
+so they effectively appear as readonly.  Show that to
+the debug machinery.  */
+ TREE_READONLY (node->decl) = 1;
+ (*debug_hooks->late_global_decl) (node->decl);
+   }
 
  node->remove ();
  continue;

Re: [PATCH] Fix handling of -fsanitize-recover* options.

[Jakub Jelinek]

On Fri, Sep 23, 2016 at 01:53:48PM +0200, Martin Liška wrote:
> 3) -fsanitize=leak is combinable with -fsanitize=address or
>-fsanitize=thread

Is it really combinable with -fsanitize=thread?  I thought only libasan
or liblsan provides the leak checker.  Anyway, I can't find where in the
patch you change this.

> --- a/gcc/flag-types.h
> +++ b/gcc/flag-types.h
> @@ -203,25 +203,25 @@ enum vect_cost_model {
>  /* Different instrumentation modes.  */
>  enum sanitize_code {
>/* AddressSanitizer.  */
> -  SANITIZE_ADDRESS = 1 << 0,
> -  SANITIZE_USER_ADDRESS = 1 << 1,
> -  SANITIZE_KERNEL_ADDRESS = 1 << 2,
> +  SANITIZE_ADDRESS = 1UL<< 0,

Formatting, space in between UL and << (many times).

> @@ -1516,11 +1518,18 @@ parse_sanitizer_options (const char *p, location_t 
> loc, int scode,
> error_at (loc, "-fsanitize=all option is not valid");
> }
>   else
> -   flags |= ~(SANITIZE_USER_ADDRESS | SANITIZE_THREAD
> -  | SANITIZE_LEAK);
> +   flags |= ~(SANITIZE_THREAD | SANITIZE_LEAK
> +  | SANITIZE_UNREACHABLE | SANITIZE_RETURN);

This change will turn on -fsanitize-recove=address for -fsanitize-recover=all, 
right?
That is quite a significant behavior change, isn't it?  Have you checked
what clang does here?

> }
>   else if (value)
> -   flags |= sanitizer_opts[i].flag;
> +   {
> + flags |= sanitizer_opts[i].flag;
> + /* Do not enable -fsanitize-recover=unreachable and
> +-fsanitize-recover=return if -fsanitize-recover=undefined
> +is selected.  */
> + if (sanitizer_opts[i].flag == SANITIZE_UNDEFINED)
> +   flags &= ~(SANITIZE_UNREACHABLE | SANITIZE_RETURN);

This looks wrong.  If you want to complain about
-fsanitize-recover=unreachable, the above would be silent about
-fsanitize-recover=unreachable -fsanitize-recover=undefined.
Shouldn't it be instead
  if (sanitizer_opts[i].flag == SANITIZE_UNDEFINED)
flags |= SANITIZE_UNDEFINED & ~(SANITIZE_UNREACHABLE | SANITIZE_RETURN);
  else
flags |= sanitizer_opts[i].flag;
?

Jakub

Re: [PATCH] Increase lto-min-partition

[Markus Trippelsdorf]

On 2016.09.22 at 15:42 +0200, Markus Trippelsdorf wrote:
> On 2016.09.22 at 15:36 +0200, Richard Biener wrote:
> > On Thu, Sep 22, 2016 at 3:13 PM, Wilco Dijkstra  
> > wrote:
> > > Increase the lto-min-partition size to 5 to reduce the number of 
> > > partitions.
> > > See eg. https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00235.html for a 
> > > concise
> > > explanation why 1 is too small for modern CPU/memory size.  
> > > Additionally,
> > > larger values increase optimization opportunities and reduce bad 
> > > decisions in the
> > > layout of global variables across partitions (anchors do not work well 
> > > with LTO).
> > > Looking at SPEC2000, 8 more benchmarks now use a single LTO partition 
> > > which
> > > is the most optimal.  Build time with LTO increases only slightly, eg. 
> > > SPEC2006
> > > now takes 2% more time on an 8-core ARM server.
> > 
> > Ok.  Marcus, how many partitions do we get with libreoffice/firefox 
> > currently
> > (I suppose they all hit lto-max-partition now?)
> 
> Yes. Even tramp3d currently gets 30 partitions. With this patch it gets
> reduced to 20.
> And I guess bigger projects like Firefox are unchanged at 32.

Sorry I've reported wrong numbers above.

lto-min-partition was already increased from 1000 to 1 on trunk by
Prathamesh in April.
And tramp3d only uses ten partitions (lto-min-partition=1).
With lto-min-partition=5 (current patch) this decrease to only two
partitions. As a result we loose the possible speedup on many core
machines (-flto=n).

E.g. on my 4-core machine I get the following tramp3d compile times with
-flto=4:

lto-min-partition=5: 20.146 total
lto-min-partition=1: 16.299 total
lto-min-partition=1000 : 16.093 total

So 5 looks too big to me. 

Also the "increased optimization opportunities" with fewer partitions
were unmeasurable in the past. If I recall correctly Honza once said
that there should be no difference between single vs. many partitions.

-- 
Markus

Re: Make regcprop to eliminate noop moves better

[Jan Hubicka]

> On 09/22/2016 01:48 PM, Jan Hubicka wrote:
> >
> > * postreload.c (reload_cse_simplify): Also accept USE in noop move
> > patterns.
> >
> >diff --git a/gcc/postreload.c b/gcc/postreload.c
> >index 61c1ce8..4f3a526 100644
> >--- a/gcc/postreload.c
> >+++ b/gcc/postreload.c
> >@@ -153,7 +153,8 @@ reload_cse_simplify (rtx_insn *insn, rtx testreg)
> >   value = SET_DEST (part);
> > }
> > }
> >-  else if (GET_CODE (part) != CLOBBER)
> >+  else if (GET_CODE (part) != CLOBBER
> >+   && GET_CODE (part) != USE)
> > break;
> > }
> 
> Hmm. This is probably ok, but what's the USE for in your pattern?

Becuase moves in vector unit at GCN require exec reigster to be set to -1 and
this is modelled by explicit use.

Honza
> 
> 
> Bernd

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

[Marek Polacek]

On Wed, Sep 21, 2016 at 03:52:09PM -0400, Jason Merrill wrote:
> On Mon, Sep 19, 2016 at 2:49 PM, Jason Merrill  wrote:
> > I suppose that an INTEGER_CST of character type is necessarily a
> > character constant, so adding a check for !char_type_p ought to do the
> > trick.
> 
> Indeed it does.  I'm checking this in:

Nice, thanks.  What about the original patch?  We still need to warn
(or error for C++11) for pointer comparisons.

Marek

Ping**3! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

[Fritz Reese]

https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html
On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese  wrote:
> This patch extends the GNU Fortran front-end to add support for
> DEC-style AUTOMATIC and STATIC symbol attributes with a new flag
> -fdec-static, allowing explicit control of variable storage. AUTOMATIC
> local variables are placed on the stack, whereas STATIC variables are
> placed in static storage.
...

https://gcc.gnu.org/ml/fortran/2016-09/msg00021.html
On Wed, Sep 7, 2016 at 4:13 PM Fritz Reese  wrote:
...
> Attached is a replacement for the original patch [...]
...

I hate to be a bother but I'm still waiting on official review for
this patch for trunk - and I still have many other extension patches I
would like to submit. I know these aren't as important as things like
DTIO, ACC, and other f03/f08+ features, and I appreciate that the
maintainers are overworked with these features as it is. Nevertheless
I believe these legacy extensions to be useful to a number of user
groups and would like to see the extensions through in this GCC
release. I am quite committed to supporting the extensions and will
address any PRs or regressions introduced as a result of them (though
of course I aim to eliminate such bugs from the beginning).

Thanks in advance,

---
Fritz Reese

> Bootstraps and regtests on x86_64-redhat-linux. Questions, comments,
> and critique welcome. Ok for trunk?
...
>
> 2016-09-07  Fritz Reese  
>
> Support for AUTOMATIC and STATIC attributes with new flag -fdec-static.
>
> gcc/fortran/
> * lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
> * options.c (set_dec_flags): Set -fdec-static with -fdec.
> * gfortran.h (symbol_attribute): New attribute automatic.
> * gfortran.h (gfc_add_automatic): New prototype.
> * match.h (gfc_match_automatic, gfc_match_static): New functions.
> * decl.c (gfc_match_automatic, gfc_match_static): Ditto.
> * symbol.c (gfc_add_automatic): Ditto.
> * decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
> * parse.c (decode_specification_statement, decode_statement): Ditto.
> * resolve.c (apply_default_init_local, resolve_fl_variable_derived,
> resolve_symbol): Support for automatic attribute.
> * symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
> Ditto.
> * trans-decl.c (gfc_finish_var_decl): Ditto.
>
> gcc/testsuite/gfortran.dg/
> * dec_static_1.f90, dec_static_2.f90, dec_static_3.f90,
> dec_static_4.f90: New testcases.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index ce5ebb7..be8e9f7 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3794,6 +3794,7 @@ match_attr_spec (void)
 DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
 DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
 DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
+DECL_STATIC, DECL_AUTOMATIC,
 DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,
 DECL_IS_BIND_C, DECL_CODIMENSION, DECL_ASYNCHRONOUS, DECL_CONTIGUOUS,
 DECL_NONE, GFC_DECL_END /* Sentinel */
@@ -3857,6 +3858,14 @@ match_attr_spec (void)
 		  d = DECL_ASYNCHRONOUS;
 		}
 		  break;
+
+		case 'u':
+		  if (match_string_p ("tomatic"))
+		{
+		  /* Matched "automatic".  */
+		  d = DECL_AUTOMATIC;
+		}
+		  break;
 		}
 	  break;
 
@@ -3986,8 +3995,25 @@ match_attr_spec (void)
 	  break;
 
 	case 's':
-	  if (match_string_p ("save"))
-		d = DECL_SAVE;
+	  gfc_next_ascii_char ();
+	  switch (gfc_next_ascii_char ())
+		{
+		  case 'a':
+		if (match_string_p ("ve"))
+		  {
+			/* Matched "save".  */
+			d = DECL_SAVE;
+		  }
+		break;
+
+		  case 't':
+		if (match_string_p ("atic"))
+		  {
+			/* Matched "static".  */
+			d = DECL_STATIC;
+		  }
+		break;
+		}
 	  break;
 
 	case 't':
@@ -4124,6 +4150,12 @@ match_attr_spec (void)
 	  case DECL_SAVE:
 	attr = "SAVE";
 	break;
+	  case DECL_STATIC:
+	attr = "STATIC";
+	break;
+	  case DECL_AUTOMATIC:
+	attr = "AUTOMATIC";
+	break;
 	  case DECL_TARGET:
 	attr = "TARGET";
 	break;
@@ -4152,6 +4184,18 @@ match_attr_spec (void)
   if (seen[d] == 0)
 	continue;
 
+  if ((d == DECL_STATIC || d == DECL_AUTOMATIC)
+	  && !flag_dec_static)
+	{
+	  gfc_error ("%s at %L is a DEC extension, enable with -fdec-static",
+		 d == DECL_STATIC ? "STATIC" : "AUTOMATIC", &seen_at[d]);
+	  m = MATCH_ERROR;
+	  goto cleanup;
+	}
+  /* Allow SAVE with STATIC, but don't complain.  */
+  if (d == DECL_STATIC && seen[DECL_SAVE])
+	continue;
+
   if (gfc_current_state () == COMP_DERIVED
 	  && d != DECL_DIMENSION && d != DECL_CODIMENSION
 	  && d != DECL_POINTER   && d != DECL_PRIVATE
@@ -4290,10 +4334,15 @@ match_attr_spec (void)
 			  &seen_at[d]);
 	  break;
 
+	case DECL_STATIC:
 	case DECL_SAVE:
 	  t = 

Re: [PATCH] Increase lto-min-partition

[Richard Biener]

On Fri, Sep 23, 2016 at 3:02 PM, Markus Trippelsdorf
 wrote:
> On 2016.09.22 at 15:42 +0200, Markus Trippelsdorf wrote:
>> On 2016.09.22 at 15:36 +0200, Richard Biener wrote:
>> > On Thu, Sep 22, 2016 at 3:13 PM, Wilco Dijkstra  
>> > wrote:
>> > > Increase the lto-min-partition size to 5 to reduce the number of 
>> > > partitions.
>> > > See eg. https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00235.html for a 
>> > > concise
>> > > explanation why 1 is too small for modern CPU/memory size.  
>> > > Additionally,
>> > > larger values increase optimization opportunities and reduce bad 
>> > > decisions in the
>> > > layout of global variables across partitions (anchors do not work well 
>> > > with LTO).
>> > > Looking at SPEC2000, 8 more benchmarks now use a single LTO partition 
>> > > which
>> > > is the most optimal.  Build time with LTO increases only slightly, eg. 
>> > > SPEC2006
>> > > now takes 2% more time on an 8-core ARM server.
>> >
>> > Ok.  Marcus, how many partitions do we get with libreoffice/firefox 
>> > currently
>> > (I suppose they all hit lto-max-partition now?)
>>
>> Yes. Even tramp3d currently gets 30 partitions. With this patch it gets
>> reduced to 20.
>> And I guess bigger projects like Firefox are unchanged at 32.
>
> Sorry I've reported wrong numbers above.
>
> lto-min-partition was already increased from 1000 to 1 on trunk by
> Prathamesh in April.

Ah, I forgot about this.  1 is equal to large-unit-insns btw and about
four times of large-function-insns.

> And tramp3d only uses ten partitions (lto-min-partition=1).
> With lto-min-partition=5 (current patch) this decrease to only two
> partitions. As a result we loose the possible speedup on many core
> machines (-flto=n).
>
> E.g. on my 4-core machine I get the following tramp3d compile times with
> -flto=4:
>
> lto-min-partition=5: 20.146 total
> lto-min-partition=1: 16.299 total
> lto-min-partition=1000 : 16.093 total
>
> So 5 looks too big to me.

I think the issue is that the default number of partitions is too high
(32) which pessimizes 4-core machines if the units are too small.

Maybe we can tune the triplet lto-partitions, lto-min-partition and
lto-max-partition in a way that it roughly scales the number of
partitions produced with program size rather than quickly raising
to 32 and then hovering there until the first unit hits lto-max-partition?

> Also the "increased optimization opportunities" with fewer partitions
> were unmeasurable in the past. If I recall correctly Honza once said
> that there should be no difference between single vs. many partitions.

Well, it definitely makes a difference for late IPA passes (that's mainly
IPA PTA).

Richard.

> --
> Markus

[PATCH, arm-embedded] -mpure-code option for ARM

[Andre Vieira (lists)]

On 22/09/16 16:04, Andre Vieira (lists) wrote:
> On 22/09/16 14:52, Richard Earnshaw (lists) wrote:
>> On 11/07/16 17:56, Andre Vieira (lists) wrote:
>>> On 07/07/16 13:30, mickael guene wrote:
 Hi Andre,

  Another feedback on your purecode patch.
  You have to disable casesi pattern since then it will
 generate wrong code with -mpure-code option.
  Indeed it will generate an 'adr rx, .Lx' (aka
 'subs rx, PC, #offset') which will not work in our
 case since 'Lx' label is put in an .rodata section.
 So offset value is unknown and can be impossible
 to encode correctly.

 Regards
 Mickael

 On 06/30/2016 04:32 PM, Andre Vieira (lists) wrote:
> Hello,
>
> This patch adds the -mpure-code option for ARM. This option ensures
> functions are put into sections that contain only code and no data. To
> ensure this throughout compilation we give these sections the ARM
> processor-specific ELF section attribute "SHF_ARM_PURECODE". This option
> is only supported for non-pic code for armv7-m targets.
>
> This patch introduces a new target hook 'TARGET_ASM_ELF_FLAGS_NUMERIC'.
> This target hook enables a target to use the numeric value for elf
> section attributes rather than their alphabetical representation. If
> TARGET_ASM_ELF_FLAGS_NUMERIC returns TRUE, the existing
> 'default_elf_asm_named_section', will print the numeric value of the
> section attributes for the current section. This target hook has two
> parameters:
> unsigned int FLAGS, the input parameter that tells the function the
> current section's attributes;
> unsigned int *NUM, used to pass down the numerical representation of the
> section's attributes.
>
> The default implementation for TARGET_ASM_ELF_FLAGS_NUMERIC will return
> false, so existing behavior is not changed.
>
> Bootstrapped and tested for arm-none-linux-gnueabihf. Further tested for
> arm-none-eabi with a Cortex-M3 target.
>
>
> gcc/ChangeLog:
> 2016-06-30  Andre Vieira  
> Terry Guo  
>
> * target.def (elf_flags_numeric): New target hook.
> * targhooks.h (default_asm_elf_flags_numeric): New.
> * varasm.c (default_asm_elf_flags_numeric): New.
>   (default_elf_asm_named_section): Use new target hook.
> * config/arm/arm.opt (mpure-code): New.
> * config/arm/arm.h (SECTION_ARM_PURECODE): New.
> * config/arm/arm.c (arm_asm_init_sections): Add section
>   attribute to default text section if -mpure-code.
>   (arm_option_check_internal): Diagnose use of option with
>   non supported targets and/or options.
>   (arm_asm_elf_flags_numeric): New.
>   (arm_function_section): New.
>   (arm_elf_section_type_flags): New.
> * config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
>   for -mpure-code.
> * gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
> * gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.
>
>
>
> gcc/testsuite/ChangeLog:
> 2016-06-30  Andre Vieira  
> Terry Guo  
>
> * gcc.target/arm/pure-code/ffunction-sections.c: New.
> * gcc.target/arm/pure-code/no-literal-pool.c: New.
> * gcc.target/arm/pure-code/pure-code.exp: New.
>

>>> Hi Sandra, Mickael,
>>>
>>> Thank you for your comments. I changed the description of -mpure-code in
>>> invoke.texi to better reflect the error message you get wrt supported
>>> targets.
>>>
>>> As for the target hook description, I hope the text is clearer now. Let
>>> me know if you think it needs further explanation.
>>>
>>> I also fixed the double '%' in the text string for unnamed text sections
>>> and disabled the casesi pattern.
>>>
>>> I duplicated the original casesi test
>>> 'gcc/testsuite/gcc.c-torture/compile/pr46934.c' for pure-code to make
>>> sure the casesi was disabled and other patterns were selected instead.
>>>
>>> Reran regressions for pure-code.exp for Cortex-M3.
>>>
>>> Cheers,
>>> Andre
>>>
>>>
>>> gcc/ChangeLog:
>>> 2016-07-11  Andre Vieira  
>>> Terry Guo  
>>>
>>> * target.def (elf_flags_numeric): New target hook.
>>> * hooks.c (hook_uint_uintp_false): New generic hook.
>>> * varasm.c (default_elf_asm_named_section): Use new target hook.
>>> * config/arm/arm.opt (mpure-code): New.
>>> * config/arm/arm.h (SECTION_ARM_PURECODE): New.
>>> * config/arm/arm.c (arm_asm_init_sections): Add section
>>> attribute to default text section if -mpure-code.
>>> (arm_option_check_internal): Diagnose use of option with
>>> non supported targets and/or options.
>>> (arm_asm_elf_flags_numeric): New.
>>> (arm_function_section): New.
>>> (arm_elf_section_type_fla

Re: [PATCH] Increase lto-min-partition

[Richard Biener]

On Fri, Sep 23, 2016 at 3:29 PM, Richard Biener
 wrote:
> On Fri, Sep 23, 2016 at 3:02 PM, Markus Trippelsdorf
>  wrote:
>> On 2016.09.22 at 15:42 +0200, Markus Trippelsdorf wrote:
>>> On 2016.09.22 at 15:36 +0200, Richard Biener wrote:
>>> > On Thu, Sep 22, 2016 at 3:13 PM, Wilco Dijkstra  
>>> > wrote:
>>> > > Increase the lto-min-partition size to 5 to reduce the number of 
>>> > > partitions.
>>> > > See eg. https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00235.html for a 
>>> > > concise
>>> > > explanation why 1 is too small for modern CPU/memory size.  
>>> > > Additionally,
>>> > > larger values increase optimization opportunities and reduce bad 
>>> > > decisions in the
>>> > > layout of global variables across partitions (anchors do not work well 
>>> > > with LTO).
>>> > > Looking at SPEC2000, 8 more benchmarks now use a single LTO partition 
>>> > > which
>>> > > is the most optimal.  Build time with LTO increases only slightly, eg. 
>>> > > SPEC2006
>>> > > now takes 2% more time on an 8-core ARM server.
>>> >
>>> > Ok.  Marcus, how many partitions do we get with libreoffice/firefox 
>>> > currently
>>> > (I suppose they all hit lto-max-partition now?)
>>>
>>> Yes. Even tramp3d currently gets 30 partitions. With this patch it gets
>>> reduced to 20.
>>> And I guess bigger projects like Firefox are unchanged at 32.
>>
>> Sorry I've reported wrong numbers above.
>>
>> lto-min-partition was already increased from 1000 to 1 on trunk by
>> Prathamesh in April.
>
> Ah, I forgot about this.  1 is equal to large-unit-insns btw and about
> four times of large-function-insns.
>
>> And tramp3d only uses ten partitions (lto-min-partition=1).
>> With lto-min-partition=5 (current patch) this decrease to only two
>> partitions. As a result we loose the possible speedup on many core
>> machines (-flto=n).
>>
>> E.g. on my 4-core machine I get the following tramp3d compile times with
>> -flto=4:
>>
>> lto-min-partition=5: 20.146 total
>> lto-min-partition=1: 16.299 total
>> lto-min-partition=1000 : 16.093 total
>>
>> So 5 looks too big to me.
>
> I think the issue is that the default number of partitions is too high
> (32) which pessimizes 4-core machines if the units are too small.
>
> Maybe we can tune the triplet lto-partitions, lto-min-partition and
> lto-max-partition in a way that it roughly scales the number of
> partitions produced with program size rather than quickly raising
> to 32 and then hovering there until the first unit hits lto-max-partition?

Which would imply lto-max-partition being on the order of
lto-partitions * lto-min-partition
or simply only having a single lto-partition-size param.

I suppose making all this runtime dependent on # cores isn't something we can do
as this will lead to code-generation changes.

Richard.

>
>> Also the "increased optimization opportunities" with fewer partitions
>> were unmeasurable in the past. If I recall correctly Honza once said
>> that there should be no difference between single vs. many partitions.
>
> Well, it definitely makes a difference for late IPA passes (that's mainly
> IPA PTA).
>
> Richard.
>
>> --
>> Markus

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Rainer Orth]

Hi Martin,

> On 09/22/2016 06:14 AM, Rainer Orth wrote:
>> Hi Martin,
>>
>>> your patch broke bootstrap with MPFR 2.4.2, which is still the
>>> recommended (or perhaps minimal) version according to install.texi:
>> [...]
>>> The following patch (together with your other one to fix ILP32 targets)
>>> allows a sparc-sun-solaris2.12 bootstrap to continue.  I'm going to
>>> commit it as obvious.
>>
>> done now.  Once the bootstrap had finished, I see quite a number of
>> testsuite failures (i386-pc-solaris2.12 still running), both 32 and
>> 64-bit:
>>
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line
>> 1220)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line
>> 1270)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line
>> 1381)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 
>> 356)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 99)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
>
> I have a patch for (hopefully) most of these failures that I will
> commit along with the one for pr77676 as soon as it's approved.

as of r240389, a few of those failures occur also on x86_64-pc-linux-gnu
with -m32:

FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 1222)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 1272)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 1383)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)

>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test
>>
>> FAIL: test_a_double:364: "%a" expected result for "0x0.0p+0"
>> doesn't match function call return value: 20 != 6
>> FAIL: test_a_double:365: "%a" expected result for "0x1.0p+0"
>> doesn't match function call return value: 20 != 6
>> FAIL: test_a_double:366: "%a" expected result for "0x1.0p+1"
>> doesn't match function call return value: 20 != 6
>>
>> FAIL: test_a_long_double:375: "%La" expected result for
>> "0x0.p+0" doesn't match function call return
>> value: 35 != 6
>> FAIL: test_a_long_double:376: "%La" expected result for
>> "0x1.p+0" doesn't match function call return
>> value: 35 != 6
>> FAIL: test_a_long_double:377: "%La" expected result for
>> "0x1.p+1" doesn't match function call return
>> value: 35 != 6
>
> I don't know about these.  It looks like the Solaris printf doesn't
> handle the %a directive correctly and the tests (and the related
> checks/optimization) might need to be disabled, which in turn might
> involve extending the existing printf hook or adding a new one.

I've found the following in Solaris 10 (and up) printf(3C):

 a, AA  double  argument  representing  a  floating-point
 number  is  converted in the style "[-]0xh.p+d",
 where the single  hexadecimal  digit  preceding  the
 radix  point is 0 if the value converted is zero and
 1 otherwise and the  number  of  hexadecimal  digits
 after it is equal to the precision; if the precision
 is missing, the number of digits printed  after  the
 radix  point  is  13  for the conversion of a double
 value, 16 for the conversion of a long double  value
 on  x86,  and 28 for the conversion of a long double
 value on SPARC; if the precision is zero and the '#'
 flag  is  not  specified, no decimal-point character
 will appear. The letters "abcdef"  are  used  for  a
 conversion  and  the  letters "ABCDEF" for A conver-
 sion. The A conversion specifier produces  a  number
 with  'X'  and  'P'  instead  of  'x'  and  'p'. The
 exponent will always contain at least one digit, and
 only  as  many more digits as necessary to represent
 the decimal exponent of 2. If the value is zero, the
 exponent is zero.

 The converted value is rounded to fit the  specified
 output  format  according to the prevailing floating
 point rounding direction mode. If the conversion  is
 not exact, an inexact exception is raised.

 A double argument representing an infinity or NaN is
 converted in the SUSv3 style of an e or E conversion
 specifier.

I tried to check the relevant sections of the latest C99 and C11 drafts
to check if this handling of missing precision is allowed by the
standard, but I couldn't even fully parse the language there.

> I don't have access to Solaris to fully debug and test this there.
> Would you mind helping with it?

Not at all: if it turns out that Solaris has bugs in this area, I can
easily file them, too.

Thanks.
Rainer

-- 
--

Re: Implement -Wimplicit-fallthrough (version 9)

[Marek Polacek]

It occurred to me that I should also handle the
__has_cpp_attribute(fallthrough) part.  But I hope that can be done after the
main -Wimplicit-fallthrough is committed.

Marek

[PATCH v3] Optimize strchr to strlen

[Wilco Dijkstra]

After discussion (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00718.html)
here is the latest version of the strchr patch.  This uses a gimple statement 
for
the pointer addition so the gsi_prev always points at the strlen call.

Optimize strchr (s, 0) to s + strlen (s).  strchr (s, 0) appears a common
idiom for finding the end of a string, however it is not a very efficient
way of doing so.  Strlen is a much simpler operation which is significantly
faster (eg. on x86 strlen is 50% faster for strings of 8 bytes and about
twice as fast as strchr on strings of 1KB).

OK for commit?

ChangeLog:
2016-09-23  Wilco Dijkstra  

gcc/
* gcc/gimple-fold.c (gimple_fold_builtin_strchr):
New function to optimize strchr (s, 0) to strlen.
(gimple_fold_builtin): Add BUILT_IN_STRCHR case.

testsuite/
* gcc/testsuite/gcc.dg/strlenopt-20.c: Update test.
* gcc/testsuite/gcc.dg/strlenopt-21.c: Likewise.
* gcc/testsuite/gcc.dg/strlenopt-22.c: Likewise.
* gcc/testsuite/gcc.dg/strlenopt-22g.c: Likewise.
* gcc/testsuite/gcc.dg/strlenopt-26.c: Likewise.
* gcc/testsuite/gcc.dg/strlenopt-5.c: Likewise.
* gcc/testsuite/gcc.dg/strlenopt-7.c: Likewise.
* gcc/testsuite/gcc.dg/strlenopt-9.c: Likewise.

--
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 
addabb745efc73465f313d1d591aea383f7f4a13..ddf4cf0ae68ef6708377fdb1a2b45575d90da799
 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -1457,6 +1457,55 @@ gimple_fold_builtin_strncpy (gimple_stmt_iterator *gsi,
   return true;
 }
 
+/* Simplify strchr (str, 0) into str + strlen (str).
+   In general strlen is significantly faster than strchr
+   due to being a simpler operation.  */
+static bool
+gimple_fold_builtin_strchr (gimple_stmt_iterator *gsi)
+{
+  gimple *stmt = gsi_stmt (*gsi);
+  tree str = gimple_call_arg (stmt, 0);
+  tree c = gimple_call_arg (stmt, 1);
+  location_t loc = gimple_location (stmt);
+
+  if (optimize_function_for_size_p (cfun))
+return false;
+
+  if (!integer_zerop (c) || !gimple_call_lhs (stmt))
+return false;
+
+  tree len;
+  tree strlen_fn = builtin_decl_implicit (BUILT_IN_STRLEN);
+
+  if (!strlen_fn)
+return false;
+
+  /* Create newstr = strlen (str).  */
+  gimple_seq stmts = NULL;
+  gimple *new_stmt = gimple_build_call (strlen_fn, 1, str);
+  gimple_set_location (new_stmt, loc);
+  if (gimple_in_ssa_p (cfun))
+len = make_ssa_name (size_type_node);
+  else
+len = create_tmp_reg (size_type_node);
+  gimple_call_set_lhs (new_stmt, len);
+  gimple_seq_add_stmt_without_update (&stmts, new_stmt);
+
+  /* Create (str p+ strlen (str)).  */
+  new_stmt = gimple_build_assign (gimple_call_lhs (stmt),
+ POINTER_PLUS_EXPR, str, len);
+  gimple_seq_add_stmt_without_update (&stmts, new_stmt);
+  gsi_replace_with_seq_vops (gsi, stmts);
+  /* gsi now points at the assignment to the lhs, get a
+ stmt iterator to the strlen.
+ ???  We can't use gsi_for_stmt as that doesn't work when the
+ CFG isn't built yet.  */
+  gimple_stmt_iterator gsi2 = *gsi;
+  gsi_prev (&gsi2);
+  fold_stmt (&gsi2);
+  return true;
+}
+
 /* Simplify a call to the strcat builtin.  DST and SRC are the arguments
to the call.
 
@@ -2898,6 +2947,8 @@ gimple_fold_builtin (gimple_stmt_iterator *gsi)
 gimple_call_arg (stmt, 1));
 case BUILT_IN_STRNCAT:
   return gimple_fold_builtin_strncat (gsi);
+case BUILT_IN_STRCHR:
+  return gimple_fold_builtin_strchr (gsi);
 case BUILT_IN_FPUTS:
   return gimple_fold_builtin_fputs (gsi, gimple_call_arg (stmt, 0),
gimple_call_arg (stmt, 1), false);
diff --git a/gcc/testsuite/gcc.dg/strlenopt-20.c 
b/gcc/testsuite/gcc.dg/strlenopt-20.c
index 
a83e845c26d88e5acdcabf142f7b319136663488..7b483eaeac1aa47278111a92148a16f00b2aaa2d
 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-20.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-20.c
@@ -86,9 +86,9 @@ main ()
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "strlen \\(" 1 "strlen" } } */
+/* { dg-final { scan-tree-dump-times "strlen \\(" 2 "strlen" } } */
 /* { dg-final { scan-tree-dump-times "memcpy \\(" 4 "strlen" } } */
 /* { dg-final { scan-tree-dump-times "strcpy \\(" 0 "strlen" } } */
 /* { dg-final { scan-tree-dump-times "strcat \\(" 0 "strlen" } } */
-/* { dg-final { scan-tree-dump-times "strchr \\(" 1 "strlen" } } */
+/* { dg-final { scan-tree-dump-times "strchr \\(" 0 "strlen" } } */
 /* { dg-final { scan-tree-dump-times "stpcpy \\(" 0 "strlen" } } */
diff --git a/gcc/testsuite/gcc.dg/strlenopt-21.c 
b/gcc/testsuite/gcc.dg/strlenopt-21.c
index 
e22fa9fca9ba14354db2cd5f602283b64bd8dcac..05b85a49dde0a7f5d269174fd4269e40be910dbd
 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-21.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-21.c
@@ -57,9 +57,9 @@ main ()
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "strlen \\(" 1 "strlen" } } */
+/* { dg-final { scan

Re: [PATCH v3] Optimize strchr to strlen

[Oleg Endo]

On Fri, 2016-09-23 at 14:07 +, Wilco Dijkstra wrote:
> After discussion (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00718
> .html)
> here is the latest version of the strchr patch.  This uses a gimple
> statement for
> the pointer addition so the gsi_prev always points at the strlen
> call.
> 
> Optimize strchr (s, 0) to s + strlen (s).  strchr (s, 0) appears a
> common
> idiom for finding the end of a string, however it is not a very
> efficient
> way of doing so.  Strlen is a much simpler operation which is
> significantly
> faster (eg. on x86 strlen is 50% faster for strings of 8 bytes and
> about
> twice as fast as strchr on strings of 1KB).
> 
> OK for commit?

Please add PR tree-optimization/61056 to the changelog so that it gets
linked in bugzilla.

Cheers,
Oleg

[committed] Provide location information for terminator characters (PR preprocessor/77672)

[David Malcolm]

substring_loc::get_location currently fails for the final terminator
character in a STRING_CST from the C frontend, so that format_warning_va
falls back to using the location of the string as a whole.

This patch tweaks things [1] so that we use the final closing quote
as the location of the terminator character, as requested in
PR preprocessor/77672.

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

Committed to trunk as r240434.

[1] specifically, cpp_interpret_string_1.

gcc/ChangeLog:
PR preprocessor/77672
* input.c (selftest::test_lexer_string_locations_simple): Update
test to expect location information of the terminator character
at the location of the final closing quote.
(selftest::test_lexer_string_locations_hex): Likewise.
(selftest::test_lexer_string_locations_oct): Likewise.
(selftest::test_lexer_string_locations_letter_escape_1): Likewise.
(selftest::test_lexer_string_locations_letter_escape_2): Likewise.
(selftest::test_lexer_string_locations_ucn4): Likewise.
(selftest::test_lexer_string_locations_ucn8): Likewise.
(selftest::test_lexer_string_locations_u8): Likewise.
(selftest::test_lexer_string_locations_utf8_source): Likewise.
(selftest::test_lexer_string_locations_concatenation_1): Likewise.
(selftest::test_lexer_string_locations_concatenation_2): Likewise.
(selftest::test_lexer_string_locations_concatenation_3): Likewise.
(selftest::test_lexer_string_locations_macro): Likewise.
(selftest::test_lexer_string_locations_long_line): Likewise.

gcc/testsuite/ChangeLog:
PR preprocessor/77672
* gcc.dg/plugin/diagnostic-test-string-literals-1.c
(test_terminator_location): New function.

libcpp/ChangeLog:
PR preprocessor/77672
* charset.c (cpp_interpret_string_1): Add a source_range for the
NUL-terminator, using the location of the trailing quote of the
final string.
---
 gcc/input.c| 81 +-
 .../plugin/diagnostic-test-string-literals-1.c | 14 
 libcpp/charset.c   |  9 ++-
 3 files changed, 71 insertions(+), 33 deletions(-)

diff --git a/gcc/input.c b/gcc/input.c
index 55bff48..9b26378 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -2239,12 +2239,12 @@ test_lexer_string_locations_simple (const 
line_table_case &case_)
   free (const_cast  (dst_string.text));
 
   /* Verify ranges of individual characters.  This no longer includes the
- quotes.  */
-  for (int i = 0; i <= 9; i++)
+ opening quote, but does include the closing quote.  */
+  for (int i = 0; i <= 10; i++)
 ASSERT_CHAR_AT_RANGE (test, tok->src_loc, type, i, 1,
  10 + i, 10 + i);
 
-  ASSERT_NUM_SUBSTRING_RANGES (test, tok->src_loc, type, 10);
+  ASSERT_NUM_SUBSTRING_RANGES (test, tok->src_loc, type, 11);
 }
 
 /* As test_lexer_string_locations_simple, but use an EBCDIC execution
@@ -2339,14 +2339,14 @@ test_lexer_string_locations_hex (const line_table_case 
&case_)
   free (const_cast  (dst_string.text));
 
   /* Verify ranges of individual characters.  This no longer includes the
- quotes.  */
+ opening quote, but does include the closing quote.  */
   for (int i = 0; i <= 4; i++)
 ASSERT_CHAR_AT_RANGE (test, tok->src_loc, type, i, 1, 10 + i, 10 + i);
   ASSERT_CHAR_AT_RANGE (test, tok->src_loc, type, 5, 1, 15, 18);
-  for (int i = 6; i <= 9; i++)
+  for (int i = 6; i <= 10; i++)
 ASSERT_CHAR_AT_RANGE (test, tok->src_loc, type, i, 1, 13 + i, 13 + i);
 
-  ASSERT_NUM_SUBSTRING_RANGES (test, tok->src_loc, type, 10);
+  ASSERT_NUM_SUBSTRING_RANGES (test, tok->src_loc, type, 11);
 }
 
 /* Lex a string literal containing an octal-escaped character.
@@ -2380,14 +2380,14 @@ test_lexer_string_locations_oct (const line_table_case 
&case_)
   free (const_cast  (dst_string.text));
 
   /* Verify ranges of individual characters.  This no longer includes the
- quotes.  */
+ opening quote, but does include the closing quote.  */
   for (int i = 0; i < 5; i++)
 ASSERT_CHAR_AT_RANGE (test, tok->src_loc, type, i, 1, 10 + i, 10 + i);
   ASSERT_CHAR_AT_RANGE (test, tok->src_loc, type, 5, 1, 15, 18);
-  for (int i = 6; i <= 9; i++)
+  for (int i = 6; i <= 10; i++)
 ASSERT_CHAR_AT_RANGE (test, tok->src_loc, type, i, 1, 13 + i, 13 + i);
 
-  ASSERT_NUM_SUBSTRING_RANGES (test, tok->src_loc, type, 10);
+  ASSERT_NUM_SUBSTRING_RANGES (test, tok->src_loc, type, 11);
 }
 
 /* Test of string literal containing letter escapes.  */
@@ -2420,12 +2420,12 @@ test_lexer_string_locations_letter_escape_1 (const 
line_table_case &case_)
   ASSERT_CHAR_AT_RANGE (test, tok->src_loc, CPP_STRING,
5, 1, 17, 18);
 
-  /* "bar".  */
-  for (int i = 6; i <= 8; i++)
+  /* "bar" and closing quote for nul-terminator.  */
+  for (int i = 6; i <= 9; i++)
 ASSERT_CHAR_AT_RANGE (test, tok->src_loc,

Re: [PATCH] Increase lto-min-partition

[Wilco Dijkstra]

Richard Biener wrote:
>On Fri, Sep 23, 2016 at 3:02 PM, Markus Trippelsdorf  
>wrote:
> > And tramp3d only uses ten partitions (lto-min-partition=1).
> > With lto-min-partition=5 (current patch) this decrease to only two
> > partitions. As a result we loose the possible speedup on many core
> > machines (-flto=n).

Only if the size is close to the lto-min-partition. For larger applications 
there is
little difference.

> > E.g. on my 4-core machine I get the following tramp3d compile times with
> > -flto=4:
> >
> > lto-min-partition=5: 20.146 total
> > lto-min-partition=1: 16.299 total
> > lto-min-partition=1000 : 16.093 total
> >
> > So 5 looks too big to me.

That's only 16 seconds? Seems like it's small so ideally it should have
used a single partition...

> I think the issue is that the default number of partitions is too high
> (32) which pessimizes 4-core machines if the units are too small.

Yes, 8 might be a better value as 32 core machines are rare.

> Maybe we can tune the triplet lto-partitions, lto-min-partition and
> lto-max-partition in a way that it roughly scales the number of
> partitions produced with program size rather than quickly raising
> to 32 and then hovering there until the first unit hits lto-max-partition?

Or use a single partition size rather than have the maximum size 
a hundred times the minimum size (which doesn't make sense at all).

> > Also the "increased optimization opportunities" with fewer partitions
> > were unmeasurable in the past. If I recall correctly Honza once said
> > that there should be no difference between single vs. many partitions.
>
> Well, it definitely makes a difference for late IPA passes (that's mainly
> IPA PTA).

Also anchors don't work with multiple partitions. I get around 1% gain
from using a single partition.

Wilco

Re: Implement -Wimplicit-fallthrough (version 9)

[Jason Merrill]

On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek  wrote:
>> This is very close, thanks.  Let's give a more helpful warning about
>>
>> [[fallthrough]] 0;
>> __attribute__ ((fallthrough)) 0;
>>
>> both here and in cp_parser_statement, something like "fallthrough attribute
>> not followed by ';'"
>
> Done.  And I made similar tweaks in the C FE.

The C++ changes are OK.

Jason

Re: Implement -Wimplicit-fallthrough (version 9)

[Jakub Jelinek]

On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek  wrote:
> >> This is very close, thanks.  Let's give a more helpful warning about
> >>
> >> [[fallthrough]] 0;
> >> __attribute__ ((fallthrough)) 0;
> >>
> >> both here and in cp_parser_statement, something like "fallthrough attribute
> >> not followed by ';'"
> >
> > Done.  And I made similar tweaks in the C FE.
> 
> The C++ changes are OK.

And the middle-end changes are ok too.

Jakub

Re: Implement -Wimplicit-fallthrough (version 9)

[Marek Polacek]

On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek  wrote:
> >> This is very close, thanks.  Let's give a more helpful warning about
> >>
> >> [[fallthrough]] 0;
> >> __attribute__ ((fallthrough)) 0;
> >>
> >> both here and in cp_parser_statement, something like "fallthrough attribute
> >> not followed by ';'"
> >
> > Done.  And I made similar tweaks in the C FE.
> 
> The C++ changes are OK.

Thanks very much!

Now I'd like to ask for an approval of the ME parts.

Also, Joseph said he had no comments, but since I've changed the C FE
parts a bit, I'd like to give him a chance to comment to perhaps look
at this again.

Thanks,

Marek

Re: Implement -Wimplicit-fallthrough (version 9)

[Marek Polacek]

On Fri, Sep 23, 2016 at 04:23:29PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> > On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek  wrote:
> > >> This is very close, thanks.  Let's give a more helpful warning about
> > >>
> > >> [[fallthrough]] 0;
> > >> __attribute__ ((fallthrough)) 0;
> > >>
> > >> both here and in cp_parser_statement, something like "fallthrough 
> > >> attribute
> > >> not followed by ';'"
> > >
> > > Done.  And I made similar tweaks in the C FE.
> > 
> > The C++ changes are OK.
> 
> And the middle-end changes are ok too.

Thanks a lot.  As mentioned in the other mail I've just sent, I'll give
Joseph a chance to comment on this, if he wishes to.

Marek

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

[Jason Merrill]

On Fri, Sep 23, 2016 at 9:15 AM, Marek Polacek  wrote:
> On Wed, Sep 21, 2016 at 03:52:09PM -0400, Jason Merrill wrote:
>> On Mon, Sep 19, 2016 at 2:49 PM, Jason Merrill  wrote:
>> > I suppose that an INTEGER_CST of character type is necessarily a
>> > character constant, so adding a check for !char_type_p ought to do the
>> > trick.
>>
>> Indeed it does.  I'm checking this in:
>
> Nice, thanks.  What about the original patch?  We still need to warn
> (or error for C++11) for pointer comparisons.

If we still accept pointer comparisons in C++, that's another bug with
treating \0 as a null pointer constant.  This seems to be because
ocp_convert of \0 to int produces an INTEGER_CST indistinguishable
from literal 0.

Jason

Re: PATCH to fix fallout from recent C++ bool changes

[Jason Merrill]

OK, thanks.

On Thu, Sep 22, 2016 at 10:24 AM, Marek Polacek  wrote:
> Jason reported that make check-c++1z reveals some fallout
> because we now reject bool++ in C++1z:
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01460.html
>
> I hope this patch fixes all of it.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2016-09-22  Marek Polacek  
>
> * c-c++-common/gomp/atomic-12.c: Skip for C++1z.
> * c-c++-common/gomp/atomic-13.c: Likewise.
> * c-c++-common/gomp/atomic-14.c: Likewise.
> * c-c++-common/pr60439.c: Remove invalid code.
> * g++.dg/expr/bitfield4.C: Robustify for C++1z.
> * g++.dg/expr/bitfield5.C: Likewise.
> * g++.dg/expr/bitfield6.C: Likewise.
> * g++.dg/expr/bool1.C: Likewise.
> * g++.dg/expr/bool3.C: Likewise.
> * g++.dg/expr/lval3.C: Likewise.
> * g++.dg/expr/lval4.C: Likewise.
> * g++.old-deja/g++.jason/bool5.C: Likewise.
>
> diff --git gcc/testsuite/c-c++-common/gomp/atomic-12.c 
> gcc/testsuite/c-c++-common/gomp/atomic-12.c
> index e9ca650..07790d9 100644
> --- gcc/testsuite/c-c++-common/gomp/atomic-12.c
> +++ gcc/testsuite/c-c++-common/gomp/atomic-12.c
> @@ -4,6 +4,7 @@
>  /* atomicvar should never be referenced in between the barrier and
> following #pragma omp atomic_load.  */
>  /* { dg-final { scan-tree-dump-not "barrier\[^#\]*atomicvar" "gimple" } } */
> +/* { dg-skip-if "invalid in C++1z" { c++1z } } */
>
>  #ifdef __cplusplus
>  bool atomicvar, c;
> diff --git gcc/testsuite/c-c++-common/gomp/atomic-13.c 
> gcc/testsuite/c-c++-common/gomp/atomic-13.c
> index 7f4afcf..83c6560 100644
> --- gcc/testsuite/c-c++-common/gomp/atomic-13.c
> +++ gcc/testsuite/c-c++-common/gomp/atomic-13.c
> @@ -4,5 +4,6 @@
>  /* atomicvar should never be referenced in between the barrier and
> following #pragma omp atomic_load.  */
>  /* { dg-final { scan-tree-dump-not "barrier\[^#\]*atomicvar" "gimple" } } */
> +/* { dg-skip-if "invalid in C++1z" { c++1z } } */
>
>  #include "atomic-12.c"
> diff --git gcc/testsuite/c-c++-common/gomp/atomic-14.c 
> gcc/testsuite/c-c++-common/gomp/atomic-14.c
> index 7e23453..f2dd9fc 100644
> --- gcc/testsuite/c-c++-common/gomp/atomic-14.c
> +++ gcc/testsuite/c-c++-common/gomp/atomic-14.c
> @@ -1,6 +1,7 @@
>  /* PR middle-end/45423 */
>  /* { dg-do compile } */
>  /* { dg-options "-fopenmp -Wno-deprecated" } */
> +/* { dg-skip-if "invalid in C++1z" { c++1z } } */
>
>  #ifdef __cplusplus
>  bool *baz ();
> diff --git gcc/testsuite/c-c++-common/pr60439.c 
> gcc/testsuite/c-c++-common/pr60439.c
> index 71b397a..dc12d1f 100644
> --- gcc/testsuite/c-c++-common/pr60439.c
> +++ gcc/testsuite/c-c++-common/pr60439.c
> @@ -131,12 +131,6 @@ f6 (bool b)
>  case 3:
>break;
>  }
> -  switch (b++) /* { dg-warning "switch condition has" } */
> -  /* { dg-warning "is deprecated" "" { target c++ } 134 } */
> -{
> -case 3:
> -  break;
> -}
>  }
>
>  void
> diff --git gcc/testsuite/g++.dg/expr/bitfield4.C 
> gcc/testsuite/g++.dg/expr/bitfield4.C
> index 7fae086..97a1fe9 100644
> --- gcc/testsuite/g++.dg/expr/bitfield4.C
> +++ gcc/testsuite/g++.dg/expr/bitfield4.C
> @@ -14,6 +14,8 @@ template <>
>  void f(bool) {}
>
>  int main() {
> -  f(s.x++); // { dg-warning "deprecated" }
> -  f(++s.x); // { dg-warning "deprecated" }
> +  f(s.x++); // { dg-warning "deprecated" "" { target { ! c++1z } } }
> +  // { dg-error "forbidden" "" { target c++1z } 17 }
> +  f(++s.x); // { dg-warning "deprecated" "" { target { ! c++1z } } }
> +  // { dg-error "forbidden" "" { target c++1z } 19 }
>  }
> diff --git gcc/testsuite/g++.dg/expr/bitfield5.C 
> gcc/testsuite/g++.dg/expr/bitfield5.C
> index 0a37f9f..bba35cb 100644
> --- gcc/testsuite/g++.dg/expr/bitfield5.C
> +++ gcc/testsuite/g++.dg/expr/bitfield5.C
> @@ -8,10 +8,12 @@ struct S {
>  S s;
>
>  int main() {
> -  s.x++; // { dg-warning "deprecated" }
> +  s.x++; // { dg-warning "deprecated" "" { target { ! c++1z } } }
> +  // { dg-error "forbidden" "" { target c++1z } 11 }
>if (s.x != 1)
>  return 1;
> -  ++s.x; // { dg-warning "deprecated" }
> +  ++s.x; // { dg-warning "deprecated" "" { target { ! c++1z } } }
> +  // { dg-error "forbidden" "" { target c++1z } 15 }
>if (s.x != 1)
>  return 2;
>  }
> diff --git gcc/testsuite/g++.dg/expr/bitfield6.C 
> gcc/testsuite/g++.dg/expr/bitfield6.C
> index 8523866..202c246 100644
> --- gcc/testsuite/g++.dg/expr/bitfield6.C
> +++ gcc/testsuite/g++.dg/expr/bitfield6.C
> @@ -7,5 +7,6 @@ struct S {
>  S s;
>
>  void f() {
> -  ++s.x = false; // { dg-warning "deprecated" }
> +  ++s.x = false; // { dg-warning "deprecated" "" { target { ! c++1z } } }
> +  // { dg-error "forbidden" "" { target c++1z } 10 }
>  }
> diff --git gcc/testsuite/g++.dg/expr/bool1.C gcc/testsuite/g++.dg/expr/bool1.C
> index 503e8b4..4ecc6ac 100644
> --- gcc/testsuite/g++.dg/expr/bool1.C
> +++ gcc/testsuite/g++.dg/expr/bool1.C
> @@ -10,8 +10,10 @@ int main()
>my_bool b = false;
>int i;

Re: [C++ PATCH] Aligned new option handling fixes (PR c++/77651)

[Jason Merrill]

On Thu, Sep 22, 2016 at 10:22 AM, Christophe Lyon
 wrote:
> On 22 September 2016 at 15:01, Jason Merrill  wrote:
>> On Thu, Sep 22, 2016 at 4:58 AM, Christophe Lyon
>>  wrote:
>>> This new test (aligned-new6.C) fails on arm/aarch64 bare-metal targets
>>> (using newlib):
>>> arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(new_opa.o): In
>>> function `operator new(unsigned int, std::align_val_t)':
>>> /gccsrc/libstdc++-v3/libsupc++/new_opa.cc:76: undefined reference to
>>> `aligned_alloc'
>>
>> Hmm, does this fix that?
>
> Yes. (I tested on arm only)

Great, applied.

Jason

Re: [PATCH] Increase lto-min-partition

[Markus Trippelsdorf]

On 2016.09.23 at 14:19 +, Wilco Dijkstra wrote:
> Richard Biener wrote:
> >On Fri, Sep 23, 2016 at 3:02 PM, Markus Trippelsdorf 
> > wrote:
> > > And tramp3d only uses ten partitions (lto-min-partition=1).
> > > With lto-min-partition=5 (current patch) this decrease to only two
> > > partitions. As a result we loose the possible speedup on many core
> > > machines (-flto=n).
> 
> Only if the size is close to the lto-min-partition. For larger applications 
> there is
> little difference.
> 
> > > E.g. on my 4-core machine I get the following tramp3d compile times with
> > > -flto=4:
> > >
> > > lto-min-partition=5: 20.146 total
> > > lto-min-partition=1: 16.299 total
> > > lto-min-partition=1000 : 16.093 total
> > >
> > > So 5 looks too big to me.
> 
> That's only 16 seconds? Seems like it's small so ideally it should have
> used a single partition...

What I wanted to point out is that you of course loose the speedup you'll
get from parallel running backends with only a single partition.

 % time g++ -w -Ofast tramp3d-v4.cpp


g++ -w -Ofast tramp3d-v4.cpp  25.61s user 0.31s system 99% cpu 25.944 total

 % time g++ -flto=4 -w -Ofast tramp3d-v4.cpp


g++ -flto=4 -w -Ofast tramp3d-v4.cpp  28.15s user 1.02s system 181% cpu 16.075 
total

 % time g++ --param=lto-partitions=1 -flto=4 -w -Ofast tramp3d-v4.cpp
g++ --param=lto-partitions=1 -flto=4 -w -Ofast tramp3d-v4.cpp  26.98s user 
0.57s system 99% cpu 27.629 total

-- 
Markus

Re: [PATCH] Extend dg-{error,warning,message,bogus} line specification to allow relative line numbers

[Dominik Vogt]

On Thu, Sep 22, 2016 at 10:05:46PM +0200, Jakub Jelinek wrote:
> This is something I've been unhappy for a long time with, and finally got to
> write something for it.


> When some test expects more than one error or warning or message on the same
> source line, people have to use absolute line number on the dg-* directives
> that is not on the right line, as DejaGNU handles just . (current line, the
> default if the directive doesn't have all the arguments), 0 (no expected
> line) and  for absolute line number.

Great!

But could this patch be responsible with some dg-error related
test errors on s390x that are present with current HEAD?  E.g.
(Sorry for the linebreaks that vim has inserted).

--
spawn -ignore SIGHUP /home/vogt/src/gcc/build-master/gcc/xgcc
-B/home/vogt/src/\
gcc/build-master/gcc/
/home/vogt/src/gcc/gcc/testsuite/gcc.target/s390/hotpatch\
-compile-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never
-O3 -mzarch \
-mhotpatch=-1,0 -S -m64 -o hotpatch-compile-1.s^M 
cc1: error: arguments to '-mhotpatch=n,m' should be non-negative
integers^M 
compiler exited with status 1 
output is: 
cc1: error: arguments to '-mhotpatch=n,m' should be non-negative
integers^M 
 
FAIL: gcc.target/s390/hotpatch-compile-1.c  (test for errors, line
1) 
FAIL: gcc.target/s390/hotpatch-compile-1.c (test for excess
errors) 
Excess errors: 
cc1: error: arguments to '-mhotpatch=n,m' should be non-negative
integers
--

So, the test expects an error:

  /* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 1 } */ 

but no longer matches the error that really occurs?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH] Extend dg-{error,warning,message,bogus} line specification to allow relative line numbers

[Jakub Jelinek]

On Fri, Sep 23, 2016 at 03:43:11PM +0100, Dominik Vogt wrote:
> Great!
> 
> But could this patch be responsible with some dg-error related
> test errors on s390x that are present with current HEAD?  E.g.
> (Sorry for the linebreaks that vim has inserted).

Very unlikely.  Are you sure it appeared only today and not more than 2
weeks ago with
PR middle-end/77475
* toplev.c (process_options): Temporarily set input_location
to UNKNOWN_LOCATION around targetm.target_option.override () call.
change (also mine)?  All such dg-error lines need to be changed to use
line number 0 (i.e. expect the errors not to be on the first line of the
source which makes no sense, but without any source location, as the errors
appear on the command line, not in any sources).

> So, the test expects an error:
> 
>   /* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative 
> integers" "" { target *-*-* } 1 } */ 

So it should be
   /* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative 
integers" "" { target *-*-* } 0 } */
instead.

Jakub

[ARM] Enable FP16 vector arithmetic operations.

[Matthew Wahab]

Hello,

Support for the ARMv8.2-A FP16 NEON arithmetic instructions was added
using non-standard names for the instruction patterns. This was needed
because the NEON floating point semantics meant that their use by the
compiler for HFmode arithmetic operations needed to be restricted. This
follows the implementation for 32-bit NEON intructions.

As with the 32-bit instructions, the restriction on the HFmode
operation can be lifted when -funsafe-math-optimizations is
enabled. This patch does that, defining the standard pattern names
addhf3, subhf3, mulhf3 and fmahf3.

This patch also updates the NEON intrinsics to use the arithmetic
operations when -ffast-math is enabled. This is to make keep the 16-bit
support consistent with the 32-bit supportd. It is needed so that code
using the f16 intrinsics are subject to the same optimizations as code
using the f32 intrinsics would be.

Tested for arm-none-linux-gnueabihf with native bootstrap and make check
on ARMv8-A and for arm-none-eabi and armeb-none-eabi with cross-compiled
make check on an ARMv8.2-A emulator.

Ok for trunk?
Matthew

gcc/
2016-09-23  Matthew Wahab  

* config/arm/arm_neon.h (vadd_f16): Use standard arithmetic
operations in fast-math mode.
(vaddq_f16): Likewise.
(vmul_f16): Likewise.
(vmulq_f16): Likewise.
(vsub_f16): Likewise.
(vsubq_f16): Likewise.
* config/arm/neon.md (add3): New.
(sub3): New.
(fma:3): New.  Also remove outdated comment.
(mul3): New.

testsuite/
2016-09-23  Matthew Wahab  

* gcc.target/arm/armv8_2-fp16-arith-1.c: Expand comment.  Update
expected output of vadd, vsub and vmul instructions.
* gcc.target/arm/armv8_2-fp16-arith-2.c: New.
* gcc.target/arm/armv8_2-fp16-neon-2.c: New.
* gcc.target/arm/armv8_2-fp16-neon-3.c: New.
>From 5c8855d44db480772803b6395cd698c704353408 Mon Sep 17 00:00:00 2001
From: Matthew Wahab 
Date: Tue, 5 Jul 2016 14:53:19 +0100
Subject: [PATCH] [ARM] Enable FP16 vector arithmetic operations.

Tested for arm-none-linux-gnueabihf with native bootstrap and make check
on ARMv8-A and for arm-none-eabi and armeb-none-eabi with cross-compiled
make check on an ARMv8.2-A emulator.

gcc/
2016-09-23  Matthew Wahab  

	* config/arm/arm_neon.h (vadd_f16): Use standard arithmetic
	operations in fast-math mode.
	(vaddq_f16): Likewise.
	(vmul_f16): Likewise.
	(vmulq_f16): Likewise.
	(vsub_f16): Likewise.
	(vsubq_f16): Likewise.
	* config/arm/neon.md (add3): New.
	(sub3): New.
	(fma:3): New.  Also remove outdated comment.
	(mul3): New.

testsuite/
2016-09-23  Matthew Wahab  

	* gcc.target/arm/armv8_2-fp16-arith-1.c: Expand comment.  Update
	expected output of vadd, vsub and vmul instructions.
	* gcc.target/arm/armv8_2-fp16-arith-2.c: New.
	* gcc.target/arm/armv8_2-fp16-neon-2.c: New.
	* gcc.target/arm/armv8_2-fp16-neon-3.c: New.
---
 gcc/config/arm/arm_neon.h  |  24 +
 gcc/config/arm/neon.md |  52 ++-
 .../gcc.target/arm/armv8_2-fp16-arith-1.c  |  18 +-
 .../gcc.target/arm/armv8_2-fp16-arith-2.c  | 109 +
 gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-2.c | 491 +
 gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-3.c | 108 +
 6 files changed, 796 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/armv8_2-fp16-arith-2.c
 create mode 100644 gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-2.c
 create mode 100644 gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-3.c

diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 54bbc7d..b19ed4f 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -14875,13 +14875,21 @@ vabsq_f16 (float16x8_t __a)
 __extension__ static __inline float16x4_t __attribute__ ((__always_inline__))
 vadd_f16 (float16x4_t __a, float16x4_t __b)
 {
+#ifdef __FAST_MATH__
+  return __a + __b;
+#else
   return __builtin_neon_vaddv4hf (__a, __b);
+#endif
 }
 
 __extension__ static __inline float16x8_t __attribute__ ((__always_inline__))
 vaddq_f16 (float16x8_t __a, float16x8_t __b)
 {
+#ifdef __FAST_MATH__
+  return __a + __b;
+#else
   return __builtin_neon_vaddv8hf (__a, __b);
+#endif
 }
 
 __extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
@@ -15319,7 +15327,11 @@ vminnmq_f16 (float16x8_t __a, float16x8_t __b)
 __extension__ static __inline float16x4_t __attribute__ ((__always_inline__))
 vmul_f16 (float16x4_t __a, float16x4_t __b)
 {
+#ifdef __FAST_MATH__
+  return __a * __b;
+#else
   return __builtin_neon_vmulfv4hf (__a, __b);
+#endif
 }
 
 __extension__ static __inline float16x4_t __attribute__ ((__always_inline__))
@@ -15337,7 +15349,11 @@ vmul_n_f16 (float16x4_t __a, float16_t __b)
 __extension__ static __inline float16x8_t __attribute__ ((__always_inline__))
 vmulq_f16 (float16x8_t __a, float16x8_t __b)
 {
+#ifdef __FAST_MATH__
+  return __a * __b;
+#else
   return __builtin_neon_vmulfv8hf (__a,

Re: [PATCHv2][ARM] -mpure-code option for ARM

[Sandra Loosemore]

On 09/23/2016 04:39 AM, Andre Vieira (lists) wrote:

Hi Sandra,

Is this better?

Cheers,
Andre

gcc/ChangeLog
2016-09-23  Andre Vieira  

 * target.def(elf_flags_numeric): Change documentation to
 present tense.


And here is the patch with the tm.texi regeneration.

Cheers,
Andre

gcc/ChangeLog
2016-09-23  Andre Vieira  

 * target.def(elf_flags_numeric): Change documentation to
 present tense.
 * doc/tm.texi: Regenerate.



This looks good to me.  Thanks.

-Sandra the grammar geek

Re: [PATCH] Extend dg-{error,warning,message,bogus} line specification to allow relative line numbers

[Dominik Vogt]

On Fri, Sep 23, 2016 at 04:48:36PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 23, 2016 at 03:43:11PM +0100, Dominik Vogt wrote:
> > Great!
> > 
> > But could this patch be responsible with some dg-error related
> > test errors on s390x that are present with current HEAD?  E.g.
> > (Sorry for the linebreaks that vim has inserted).
> 
> Very unlikely.  Are you sure it appeared only today and not more than 2
> weeks ago with
> PR middle-end/77475
> * toplev.c (process_options): Temporarily set input_location
> to UNKNOWN_LOCATION around targetm.target_option.override () call.
> change (also mine)?  All such dg-error lines need to be changed to use
> line number 0 (i.e. expect the errors not to be on the first line of the
> source which makes no sense, but without any source location, as the errors
> appear on the command line, not in any sources).

Yeah, thanks a lot for pointing this out, that's the right fix.
Saved me bisecting this.

> > So, the test expects an error:
> > 
> >   /* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative 
> > integers" "" { target *-*-* } 1 } */ 
> 
> So it should be
>/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative 
> integers" "" { target *-*-* } 0 } */
> instead.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH] Increase lto-min-partition

[Wilco Dijkstra]

Markus Trippelsdorf wrote:
> What I wanted to point out is that you of course loose the speedup you'll
> get from parallel running backends with only a single partition.

Absolutely. For every possible value of min-lto-partition you can find an
application that will build with more parallelism if you reduce the partition 
size.

So the question is whether it's the goal of LTO to build as parallel as possible
at all times? Or should it be set to a fairly large value that keeps plenty of
parallelism for large projects?

Wilco

[gomp4] fix an ICE with acc declared VLAs

[Cesar Philippidis]

I've applied this patch to gomp4 which fixes a problem with VLA
variables in data clauses used in acc declare directives. More details
regarding this fix can be found here
.

Cesar
2016-09-23  Cesar Philippidis  

	gcc/
	* gimplify.c (is_oacc_declared): New function.
	(oacc_default_clause): Use it to set default flags for acc declared
	variables inside parallel regions.
	(gimplify_scan_omp_clauses): Strip firstprivate pointers for acc
	declared variables.
	(gimplify_oacc_declare): Gimplify the declare clauses.  Add the
	declare attribute to any decl as necessary.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: New test.


diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 1ecfaaa..1c04b33 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -6002,6 +6002,16 @@ device_resident_p (tree decl)
   return false;
 }
 
+/* Return true if DECL has an ACC DECLARE attribute.  */
+
+static bool
+is_oacc_declared (tree decl)
+{
+  tree t = TREE_CODE (decl) == MEM_REF ? TREE_OPERAND (decl, 0) : decl;
+  tree declared = lookup_attribute ("oacc declare target", DECL_ATTRIBUTES (t));
+  return declared != NULL_TREE;
+}
+
 /* Determine outer default flags for DECL mentioned in an OMP region
but not declared in an enclosing clause.
 
@@ -6103,6 +6113,7 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree decl, unsigned flags)
   const char *rkind;
   bool on_device = false;
   bool is_private = false;
+  bool declared = is_oacc_declared (decl);
   tree type = TREE_TYPE (decl);
 
   if (lang_hooks.decls.omp_privatize_by_reference (decl))
@@ -6137,7 +6148,7 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree decl, unsigned flags)
 
 case ORT_ACC_PARALLEL:
   {
-	if (!is_private && (on_device || AGGREGATE_TYPE_P (type)))
+	if (!is_private && (on_device || AGGREGATE_TYPE_P (type) || declared))
 	  /* Aggregates default to 'present_or_copy'.  */
 	  flags |= GOVD_MAP;
 	else
@@ -6613,6 +6624,7 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
   case OMP_TARGET_ENTER_DATA:
   case OMP_TARGET_EXIT_DATA:
 	//case OACC_DATA:
+  case OACC_DECLARE:
   case OACC_HOST_DATA:
 	//case OACC_PARALLEL:
 	//case OACC_KERNELS:
@@ -8538,20 +8550,28 @@ gimplify_oacc_declare (tree *expr_p, gimple_seq *pre_p)
 {
   tree expr = *expr_p;
   gomp_target *stmt;
-  tree clauses, t;
+  tree clauses, t, decl;
 
   clauses = OACC_DECLARE_CLAUSES (expr);
 
   gimplify_scan_omp_clauses (&clauses, pre_p, ORT_TARGET_DATA, OACC_DECLARE);
+  gimplify_adjust_omp_clauses (pre_p, NULL, &clauses, OACC_DECLARE);
 
   for (t = clauses; t; t = OMP_CLAUSE_CHAIN (t))
 {
-  tree decl = OMP_CLAUSE_DECL (t);
+  decl = OMP_CLAUSE_DECL (t);
 
   if (TREE_CODE (decl) == MEM_REF)
-	continue;
+	decl = TREE_OPERAND (decl, 0);
 
-  if (TREE_CODE (decl) == VAR_DECL
+  if (VAR_P (decl) && !is_oacc_declared (decl))
+	{
+	  tree attr = get_identifier ("oacc declare target");
+	  DECL_ATTRIBUTES (decl) = tree_cons (attr, NULL_TREE,
+	  DECL_ATTRIBUTES (decl));
+	}
+
+  if (VAR_P (decl)
 	  && !is_global_var (decl)
 	  && DECL_CONTEXT (decl) == current_function_decl)
 	{
@@ -8565,7 +8585,8 @@ gimplify_oacc_declare (tree *expr_p, gimple_seq *pre_p)
 	}
 	}
 
-  omp_add_variable (gimplify_omp_ctxp, decl, GOVD_SEEN);
+  if (gimplify_omp_ctxp)
+	omp_add_variable (gimplify_omp_ctxp, decl, GOVD_SEEN);
 }
 
   stmt = gimple_build_omp_target (NULL, GF_OMP_TARGET_KIND_OACC_DECLARE,
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
new file mode 100644
index 000..3ea148e
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
@@ -0,0 +1,25 @@
+/* Verify that acc declare accept VLA variables.  */
+
+#include 
+
+int
+main ()
+{
+  int N = 1000;
+  int i, A[N];
+#pragma acc declare copy(A)
+
+  for (i = 0; i < N; i++)
+A[i] = -i;
+
+#pragma acc kernels
+  for (i = 0; i < N; i++)
+A[i] = i;
+
+#pragma acc update host(A)
+
+  for (i = 0; i < N; i++)
+assert (A[i] == i);
+
+  return 0;
+}

[PATCH]: S/390: Fix hotpatch test cases.

[Dominik Vogt]

THe attached patch fixes some dg-error tests that were broken
since the recent change of the error location.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/testsuite/ChangeLog

* gcc.target/s390/hotpatch-compile-1.c: Fixed dg-error test.
* gcc.target/s390/hotpatch-compile-2.c: Likewise.
* gcc.target/s390/hotpatch-compile-3.c: Likewise.
* gcc.target/s390/hotpatch-compile-4.c: Likewise.
* gcc.target/s390/hotpatch-compile-5.c: Likewise.
* gcc.target/s390/hotpatch-compile-6.c: Likewise.
* gcc.target/s390/hotpatch-compile-14.c: Likewise.
>From 391bde7c28df2189f3652b29fa742b5bb39f2b30 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Fri, 23 Sep 2016 16:10:07 +0100
Subject: [PATCH] S/390: Fix hotpatch test cases.

---
 gcc/testsuite/gcc.target/s390/hotpatch-compile-1.c  | 2 +-
 gcc/testsuite/gcc.target/s390/hotpatch-compile-14.c | 2 +-
 gcc/testsuite/gcc.target/s390/hotpatch-compile-2.c  | 2 +-
 gcc/testsuite/gcc.target/s390/hotpatch-compile-3.c  | 2 +-
 gcc/testsuite/gcc.target/s390/hotpatch-compile-4.c  | 2 +-
 gcc/testsuite/gcc.target/s390/hotpatch-compile-5.c  | 2 +-
 gcc/testsuite/gcc.target/s390/hotpatch-compile-6.c  | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.target/s390/hotpatch-compile-1.c 
b/gcc/testsuite/gcc.target/s390/hotpatch-compile-1.c
index ca47f6b..f283a1e 100644
--- a/gcc/testsuite/gcc.target/s390/hotpatch-compile-1.c
+++ b/gcc/testsuite/gcc.target/s390/hotpatch-compile-1.c
@@ -2,4 +2,4 @@
 
 /* { dg-do compile } */
 /* { dg-options "-O3 -mzarch -mhotpatch=-1,0" } */
-/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 1 } */
+/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/s390/hotpatch-compile-14.c 
b/gcc/testsuite/gcc.target/s390/hotpatch-compile-14.c
index 0b5e674..a5871f9 100644
--- a/gcc/testsuite/gcc.target/s390/hotpatch-compile-14.c
+++ b/gcc/testsuite/gcc.target/s390/hotpatch-compile-14.c
@@ -8,4 +8,4 @@ viod main(void)
   return 0;
 }
 
-/* { dg-error "argument to .-mhotpatch=n,m. is too large" "" { target *-*-* } 
1 } */
+/* { dg-error "argument to .-mhotpatch=n,m. is too large" "" { target *-*-* } 
0 } */
diff --git a/gcc/testsuite/gcc.target/s390/hotpatch-compile-2.c 
b/gcc/testsuite/gcc.target/s390/hotpatch-compile-2.c
index 78253f5..b84d26a 100644
--- a/gcc/testsuite/gcc.target/s390/hotpatch-compile-2.c
+++ b/gcc/testsuite/gcc.target/s390/hotpatch-compile-2.c
@@ -2,4 +2,4 @@
 
 /* { dg-do compile } */
 /* { dg-options "-O3 -mzarch -mhotpatch=0,-1" } */
-/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 1 } */
+/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/s390/hotpatch-compile-3.c 
b/gcc/testsuite/gcc.target/s390/hotpatch-compile-3.c
index 6dde224..385ac6a 100644
--- a/gcc/testsuite/gcc.target/s390/hotpatch-compile-3.c
+++ b/gcc/testsuite/gcc.target/s390/hotpatch-compile-3.c
@@ -2,4 +2,4 @@
 
 /* { dg-do compile } */
 /* { dg-options "-O3 -mzarch -mhotpatch=0" } */
-/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 1 } */
+/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/s390/hotpatch-compile-4.c 
b/gcc/testsuite/gcc.target/s390/hotpatch-compile-4.c
index fbb3083..da9e121 100644
--- a/gcc/testsuite/gcc.target/s390/hotpatch-compile-4.c
+++ b/gcc/testsuite/gcc.target/s390/hotpatch-compile-4.c
@@ -2,4 +2,4 @@
 
 /* { dg-do compile } */
 /* { dg-options "-O3 -mzarch -mhotpatch=0,0,0" } */
-/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 1 } */
+/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/s390/hotpatch-compile-5.c 
b/gcc/testsuite/gcc.target/s390/hotpatch-compile-5.c
index dc0ff67..1da3e93 100644
--- a/gcc/testsuite/gcc.target/s390/hotpatch-compile-5.c
+++ b/gcc/testsuite/gcc.target/s390/hotpatch-compile-5.c
@@ -2,4 +2,4 @@
 
 /* { dg-do compile } */
 /* { dg-options "-O3 -mzarch -mhotpatch=a,0" } */
-/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 1 } */
+/* { dg-error "arguments to .-mhotpatch=n,m. should be non-negative integers" 
"" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/s390/hotpatch-compile-6.c 
b/gcc/testsuite/gcc.target/s390/hotpatch-compile-6.c
index d04045e..4b523db 100644
--- a/gcc/testsuite/gcc.target/s390/hotpatch-compile-6.c
+++ b/gcc/testsuite/gcc.target/s390/hotpatch-compile-6.c
@@ -2,4 +2,4 @@
 
 /* { dg-do compile } */
 /* { dg-options "-O3 -mzarch -mhotpatch=0,a" } */
-/* { dg-error "arguments to .-mhotpatc

Re: [PATCH] Increase lto-min-partition

[Prathamesh Kulkarni]

On 23 September 2016 at 19:49, Wilco Dijkstra  wrote:
> Richard Biener wrote:
>>On Fri, Sep 23, 2016 at 3:02 PM, Markus Trippelsdorf  
>>wrote:
>> > And tramp3d only uses ten partitions (lto-min-partition=1).
>> > With lto-min-partition=5 (current patch) this decrease to only two
>> > partitions. As a result we loose the possible speedup on many core
>> > machines (-flto=n).
>
> Only if the size is close to the lto-min-partition. For larger applications 
> there is
> little difference.
>
>> > E.g. on my 4-core machine I get the following tramp3d compile times with
>> > -flto=4:
>> >
>> > lto-min-partition=5: 20.146 total
>> > lto-min-partition=1: 16.299 total
>> > lto-min-partition=1000 : 16.093 total
>> >
>> > So 5 looks too big to me.
>
> That's only 16 seconds? Seems like it's small so ideally it should have
> used a single partition...
>
>> I think the issue is that the default number of partitions is too high
>> (32) which pessimizes 4-core machines if the units are too small.
>
> Yes, 8 might be a better value as 32 core machines are rare.
>
>> Maybe we can tune the triplet lto-partitions, lto-min-partition and
>> lto-max-partition in a way that it roughly scales the number of
>> partitions produced with program size rather than quickly raising
>> to 32 and then hovering there until the first unit hits lto-max-partition?
>
> Or use a single partition size rather than have the maximum size
> a hundred times the minimum size (which doesn't make sense at all).
>
>> > Also the "increased optimization opportunities" with fewer partitions
>> > were unmeasurable in the past. If I recall correctly Honza once said
>> > that there should be no difference between single vs. many partitions.
>>
>> Well, it definitely makes a difference for late IPA passes (that's mainly
>> IPA PTA).
>
> Also anchors don't work with multiple partitions. I get around 1% gain
> from using a single partition.
Hi Wilco,
I am working on LTO varpool partitioning to improve performance for
section anchors.
I posted a preliminary patch posted at:
https://gcc.gnu.org/ml/gcc/2016-07/msg00033.html
Unfortunately I haven't yet been able to benchmark it on ARM yet.
I am planning to restart working on it again soon.

Building with a single partition is not scalable. LTO build of
chromium with x86->arm
cross with a single partition results in "branch out of range"
assembler error. I added lto-max-partition
primarily to work around that limitation.

Thanks,
Prathamesh
>
> Wilco
>

[PATCH] Fixed up missing semicolons.

[lhmouse]

Hi GCC developers,
Today I was trying bootstrapping GCC 7.0.0 and stage 1 compilation
failed because of two missing semicolons. After this patch was applied,
xgcc could be built successfully, although it still failed the self-test.

--
Best regards,
lh_mouse
2016-09-23



From 1133ae49102751b24cfd0368986a63f482afe8d0 Mon Sep 17 00:00:00 2001
From: lhmouse 
Date: Fri, 23 Sep 2016 19:11:03 +0800
Subject: [PATCH] Fixed up missing semicolons.

Signed-off-by: lhmouse 
---
 gcc/config/i386/cygming.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index 60e11b4..1d9675e 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -111,7 +111,7 @@ along with GCC; see the file COPYING3.  If not see
assemble_name (FILE, LABEL);\
if ((OFFSET) != 0)  \
  fprintf (FILE, "+" HOST_WIDE_INT_PRINT_DEC,   \
-  (HOST_WIDE_INT) (OFFSET))\
+  (HOST_WIDE_INT) (OFFSET));   \
break;  \
   case 8:  \
/* This is a hack.  There is no 64-bit section relative \
@@ -123,7 +123,7 @@ along with GCC; see the file COPYING3.  If not see
assemble_name (FILE, LABEL);\
if ((OFFSET) != 0)  \
  fprintf (FILE, "+" HOST_WIDE_INT_PRINT_DEC,   \
-  (HOST_WIDE_INT) (OFFSET))\
+  (HOST_WIDE_INT) (OFFSET));   \
fputs ("\n\t.long\t0", FILE);   \
break;  \
   default: \
-- 
2.9.1


0016-master-Fixed-up-missing-semicolons.patch
Description: Binary data

[PATCH, GCC] Deal with singular sentences in builtin-sprintf-warn-1.c regex

[Thomas Preudhomme]

Hi,

New builtin-sprintf-warn-1.c testcase contains a few regex of the form "\[0-9\]+ 
bytes" or ". bytes". This does not account for the case where the number of byte 
is 0 in which case byte would be in the singular form. This caused a FAIL on 
arm-none-eabi targets. This patch makes the s optional in all cases where the 
number of bytes is unknown.


I did not commit this fix as obvious as people might want to only do the changes 
for lines where the number of bytes *could* be 0 so I prefer to get review.


ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-09-23  Thomas Preud'homme  

* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust regex to accept
singular form of byte when quantity is unknown.


Is this ok for trunk?

Best regards,

Thomas

Re: [PATCH, GCC] Deal with singular sentences in builtin-sprintf-warn-1.c regex

[Thomas Preudhomme]

Sorry, forgot the patch. Please find it attached.

Best regards,

Thomas

On 23/09/16 16:40, Thomas Preudhomme wrote:

Hi,

New builtin-sprintf-warn-1.c testcase contains a few regex of the form "\[0-9\]+
bytes" or ". bytes". This does not account for the case where the number of byte
is 0 in which case byte would be in the singular form. This caused a FAIL on
arm-none-eabi targets. This patch makes the s optional in all cases where the
number of bytes is unknown.

I did not commit this fix as obvious as people might want to only do the changes
for lines where the number of bytes *could* be 0 so I prefer to get review.

ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-09-23  Thomas Preud'homme  

* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust regex to accept
singular form of byte when quantity is unknown.


Is this ok for trunk?

Best regards,

Thomas
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
index e098be92bb0377414b1f9cacf5e4d2a3398e74ec..85dbcd9d6d3a5b1ad810037f03451207284a25b1 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
@@ -77,13 +77,13 @@ void test_sprintf_c_const (void)
   T (-1, "%*c",  INT_MAX - 1, '1');
   T (-1, "%*c",  INT_MAX, '1');
   T (-1, "X%*c", INT_MAX - 1, '1');
-  T (-1, "X%*c", INT_MAX, '1'); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." } */
+  T (-1, "X%*c", INT_MAX, '1'); /* { dg-warning "directive output of \[0-9\]+ bytes? causes result to exceed .INT_MAX." } */
 
-  T (-1, "%*c%*c", INT_MAX - 1, '1', INT_MAX - 1, '2'); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." } */
+  T (-1, "%*c%*c", INT_MAX - 1, '1', INT_MAX - 1, '2'); /* { dg-warning "directive output of \[0-9\]+ bytes? causes result to exceed .INT_MAX." } */
 
   T (-1, "%*cX", INT_MAX - 2, '1');
   T (-1, "%*cX", INT_MAX - 1, '1');
-  T (-1, "%*cX", INT_MAX, '1'); /* { dg-warning "output of \[0-9\]+ bytes causes result to exceed .INT_MAX." } */
+  T (-1, "%*cX", INT_MAX, '1'); /* { dg-warning "output of \[0-9\]+ bytes? causes result to exceed .INT_MAX." } */
 }
 
 /* Exercise the "%p" directive with constant arguments.  */
@@ -98,9 +98,9 @@ void test_sprintf_p_const (void)
 
   /* The exact output for %p is unspecified by C.  Two formats are known:
  same as %tx (for example AIX) and same as %#tx (for example Solaris).  */
-  T (0, "%p", (void*)0x1);/* { dg-warning ".%p. directive writing . bytes into a region of size 0" } */
-  T (1, "%p", (void*)0x12);   /* { dg-warning ".%p. directive writing . bytes into a region of size 1" } */
-  T (2, "%p", (void*)0x123);  /* { dg-warning ".%p. directive writing . bytes into a region of size 2" } */
+  T (0, "%p", (void*)0x1);/* { dg-warning ".%p. directive writing . bytes? into a region of size 0" } */
+  T (1, "%p", (void*)0x12);   /* { dg-warning ".%p. directive writing . bytes? into a region of size 1" } */
+  T (2, "%p", (void*)0x123);  /* { dg-warning ".%p. directive writing . bytes? into a region of size 2" } */
 
   /* GLIBC and uClibc treat the ' ' flag with the "%p" directive the same
  as with signed integer conversions (i.e., it prepends a space).  Other
@@ -299,7 +299,7 @@ void test_sprintf_chk_s_const (void)
  when the size of the destination object is unknown.  */
   T (-1, "%*s",  INT_MAX - 1, "");
   T (-1, "%*s",  INT_MAX, "");
-  T (-1, "X%*s", INT_MAX, ""); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." } */
+  T (-1, "X%*s", INT_MAX, ""); /* { dg-warning "directive output of \[0-9\]+ bytes? causes result to exceed .INT_MAX." } */
 
   /* Multiple directives.  */
 

RE: [PATCH] Fix PR tree-optimization/77654

[Matthew Fortune]

Doug Gilmore  writes:
> > From: Richard Biener [rguent...@suse.de]
> > Sent: Thursday, September 22, 2016 12:43 AM
> > To: Doug Gilmore
> > Cc: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
> > Subject: RE: [PATCH] Fix PR tree-optimization/77654
> >
> > On Wed, 21 Sep 2016, Doug Gilmore wrote:
> >
> > ...
> > > Sorry I that missed point.  I glossed your comment "addr_base should
> > > always be a pointer", causing me to go off into the weeds.
> > >
> > > New patch attached.
> >
> > Ok if successfully bootstrapped / tested.
> >
> > Thanks,
> > Richard.
> The change bootstrapped on X86_64 and the several "make check" errors
> also appeared in latest archived mail message to gcc-testresults.

Committed as r240439.

(Fixed whitespace/tab issue in the code and incorrect file in changelog)

I can't progress the bug status. Who does that normally?

Matthew

[PATCH] Fix builtin-sprintf-warn-2.c xfail pattern

[Thomas Preudhomme]

The new builtin-sprintf-warn-2.c xfail on line 83 and 84 for *-*-*-* which fails 
for arm-none-eabi for instance. The usual pattern for catchall xfail is *-*-*. 
This patch fixes the pattern as such.


ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-09-23  Thomas Preud'homme  

* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Fix xfail pattern.


Committing as obvious fix.

Best regards,

Thomas
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-2.c b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-2.c
index b0f2d450077012d92708c3638c47f1fd3611aa7a..675ecac4f72d8117abe258d2943eb5b1f78ad962 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-2.c
@@ -80,8 +80,8 @@ struct Arrays {
 
 void test_s_nonconst (const char *s, const wchar_t *ws, struct Arrays *a)
 {
-  T (0, "%s",   s); /* { dg-warning "into a region" "sprintf transformed into strcpy" { xfail *-*-*-* } } */
-  T (1, "%s",   s); /* { dg-warning "nul past the end" "sprintf transformed into strcpy" { xfail *-*-*-* } } */
+  T (0, "%s",   s); /* { dg-warning "into a region" "sprintf transformed into strcpy" { xfail *-*-* } } */
+  T (1, "%s",   s); /* { dg-warning "nul past the end" "sprintf transformed into strcpy" { xfail *-*-* } } */
   T (1, "%1s",  s); /* { dg-warning "nul past the end" } */
   T (1, "%.0s", s);
   T (1, "%.1s", s); /* { dg-warning "writing a terminating nul" } */

OpenACC data clause syntax question/patch

[Bernd Schmidt]

While trying to get the following benchmarks to run:
  https://codesign.llnl.gov/lulesh.php

I came across some cases where the code and the compiler differed in its 
interpretation of the OpenACC spec. Specifically, this occurs for acc 
data clauses with arrays, like:


#pragma acc data copyin(a[N][M]) copyout(b[N][M])

Here, gcc expects an entire array to be specified as a[0:N][0:M], while 
the benchmark uses a[N][M]. The latter is interpreted by gcc as a single 
array element (low bound N, length 1), and produces an error.


As usual, the "spec" isn't super clear but my reading of it tends to 
agree with gcc's. However, I suspect compatibility with other compilers 
is more important than what's in that document. I don't have any to test 
against unfortunately.


In any case, the following patch changes gcc's behaviour, if we think it 
should be changed. Not fully tested yet, in particular I have some 
issues with timeouts while running OpenACC offload tests.



Bernd
c/
	* c-parser.c (c_parser_omp_variable_list): When encountering [N] syntax
	rather than [N:M], interpret it as [0:N].
cp/
	* parser.c (cp_parser_omp_var_list_no_open): When encountering [N]
	syntax rather than [N:M], interpret it as [0:N].
libgomp/
	testsuite/libgomp.oacc-c-c++-common/present-3.c: New test.

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 0aba51c..63c7bd7 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -10722,7 +10722,10 @@ c_parser_omp_variable_list (c_parser *parser,
 		  low_bound = expr.value;
 		}
 		  if (c_parser_next_token_is (parser, CPP_CLOSE_SQUARE))
-		length = integer_one_node;
+		{
+		  length = low_bound;
+		  low_bound = integer_zero_node;
+		}
 		  else
 		{
 		  /* Look for `:'.  */
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ca9f8b9..7d374ff 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30215,7 +30215,10 @@ cp_parser_omp_var_list_no_open (cp_parser *parser, enum omp_clause_code kind,
 		parser->colon_corrects_to_scope_p
 		  = saved_colon_corrects_to_scope_p;
 		  if (cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_SQUARE))
-		length = integer_one_node;
+		{
+		  length = low_bound;
+		  low_bound = integer_zero_node;
+		}
 		  else
 		{
 		  /* Look for `:'.  */

diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/present-3.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/present-3.c
new file mode 100644
index 000..c46ecf5
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/present-3.c
@@ -0,0 +1,47 @@
+/* { dg-do run } */
+/* { dg-skip-if "" { *-*-* } { "*" } { "-DACC_MEM_SHARED=0" } } */
+
+#include 
+#include 
+
+#define N 8
+#define M 8
+
+int
+main (int argc, char **argv)
+{
+  float a[N][M], b[N][M];
+  int i;
+
+  for (i = 0; i < N; i++)
+{
+  a[i][0] = 4.0;
+  b[i][0] = 0.0;
+}
+
+#pragma acc data copyin(a[N][M]) copyout(b[N][M])
+  {
+
+#pragma acc parallel present(a[N][M])
+{
+  int ii;
+
+  for (ii = 0; ii < N; ii++)
+	{
+	  b[ii][0] = a[ii][0];
+	}
+}
+
+  }
+
+  for (i = 0; i < N; i++)
+{
+  if (a[i][0] != 4.0)
+	abort ();
+
+  if (b[i][0] != 4.0)
+	abort ();
+}
+
+  return 0;
+}

Re: OpenACC data clause syntax question/patch

[Jakub Jelinek]

On Fri, Sep 23, 2016 at 06:02:32PM +0200, Bernd Schmidt wrote:
> While trying to get the following benchmarks to run:
>   https://codesign.llnl.gov/lulesh.php
> 
> I came across some cases where the code and the compiler differed in its
> interpretation of the OpenACC spec. Specifically, this occurs for acc data
> clauses with arrays, like:
> 
> #pragma acc data copyin(a[N][M]) copyout(b[N][M])
> 
> Here, gcc expects an entire array to be specified as a[0:N][0:M], while the
> benchmark uses a[N][M]. The latter is interpreted by gcc as a single array
> element (low bound N, length 1), and produces an error.
> 
> As usual, the "spec" isn't super clear but my reading of it tends to agree
> with gcc's. However, I suspect compatibility with other compilers is more
> important than what's in that document. I don't have any to test against
> unfortunately.
> 
> In any case, the following patch changes gcc's behaviour, if we think it
> should be changed. Not fully tested yet, in particular I have some issues
> with timeouts while running OpenACC offload tests.

I haven't studied OpenACC in this case, but a[N][M] in OpenMP array section
syntax is certainly the same thing as in C/C++ without any extensions, i.e.
an array element, to cover the whole array one needs to use e.g. a[:N][:M]
or a[0:N][0:M].  So your patch would certainly break OpenMP.

E.g. in
https://github.com/EPCCed/epcc-openacc-benchmarks/blob/master/level0.c
I see even in OpenACC the [0:len1][0:len2] syntax being used when they mean
the whole array.

Jakub

Re: [PATCH, GCC] Deal with singular sentences in builtin-sprintf-warn-1.c regex

[Martin Sebor]

On 09/23/2016 09:42 AM, Thomas Preudhomme wrote:

Sorry, forgot the patch. Please find it attached.

Best regards,

Thomas

On 23/09/16 16:40, Thomas Preudhomme wrote:

Hi,

New builtin-sprintf-warn-1.c testcase contains a few regex of the form
"\[0-9\]+
bytes" or ". bytes". This does not account for the case where the
number of byte
is 0 in which case byte would be in the singular form. This caused a
FAIL on
arm-none-eabi targets. This patch makes the s optional in all cases
where the
number of bytes is unknown.

I did not commit this fix as obvious as people might want to only do
the changes
for lines where the number of bytes *could* be 0 so I prefer to get
review.


Thanks for the patch.  The %p fixes look correct to me (someone
else needs to approve the final patch).

For the INT_MAX tests, I think it's a sign of a bug in the pass if
for the following call

  sprintf (buf, "X%*c", INT_MAX, '1');

GCC prints

  warning: directive output of 0 byte causes result to exceed 'INT_MAX'

My guess is that the bug is specific to a 32-bit compiler (I can't
reproduce it in a 64-bit one with -m32).  Let me build one and look
into fixing it.

Martin



ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-09-23  Thomas Preud'homme  

* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust regex to
accept
singular form of byte when quantity is unknown.


Is this ok for trunk?

Best regards,

Thomas

Re: [PATCH, GCC] Deal with singular sentences in builtin-sprintf-warn-1.c regex

[Thomas Preudhomme]

Hi Martin,

On 23/09/16 17:17, Martin Sebor wrote:

On 09/23/2016 09:42 AM, Thomas Preudhomme wrote:

Sorry, forgot the patch. Please find it attached.

Best regards,

Thomas

On 23/09/16 16:40, Thomas Preudhomme wrote:

Hi,

New builtin-sprintf-warn-1.c testcase contains a few regex of the form
"\[0-9\]+
bytes" or ". bytes". This does not account for the case where the
number of byte
is 0 in which case byte would be in the singular form. This caused a
FAIL on
arm-none-eabi targets. This patch makes the s optional in all cases
where the
number of bytes is unknown.

I did not commit this fix as obvious as people might want to only do
the changes
for lines where the number of bytes *could* be 0 so I prefer to get
review.


Thanks for the patch.  The %p fixes look correct to me (someone
else needs to approve the final patch).

For the INT_MAX tests, I think it's a sign of a bug in the pass if
for the following call

  sprintf (buf, "X%*c", INT_MAX, '1');

GCC prints

  warning: directive output of 0 byte causes result to exceed 'INT_MAX'


I only had a failed warning on line 101:

  T (0, "%p", (void*)0x1);/* { dg-warning ".%p. directive writing . 
bytes into a region of size 0" } */


The other were fine. I just changed all the one that were using . or explicitely 
including 0 when matching the amount of bytes. I did not look into which one 
make sense to be 0 which is why I wanted review.


I'm happy to just keep the %p ones (or even only the one with 0, "%p") if you 
think that's the only one that needs it.


Best regards,

Thomas

Re: [PATCH] Fix PR tree-optimization/77654

[Mike Stump]

On Sep 23, 2016, at 8:55 AM, Matthew Fortune  wrote:
> 
> Doug Gilmore  writes:
>>> From: Richard Biener [rguent...@suse.de]
>>> Sent: Thursday, September 22, 2016 12:43 AM
>>> To: Doug Gilmore
>>> Cc: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
>>> Subject: RE: [PATCH] Fix PR tree-optimization/77654
>>> 
>>> On Wed, 21 Sep 2016, Doug Gilmore wrote:
>>> 
>>> ...
 Sorry I that missed point.  I glossed your comment "addr_base should
 always be a pointer", causing me to go off into the weeds.
 
 New patch attached.
>>> 
>>> Ok if successfully bootstrapped / tested.
>>> 
>>> Thanks,
>>> Richard.
>> The change bootstrapped on X86_64 and the several "make check" errors
>> also appeared in latest archived mail message to gcc-testresults.
> 
> Committed as r240439.
> 
> (Fixed whitespace/tab issue in the code and incorrect file in changelog)
> 
> I can't progress the bug status. Who does that normally?

Hum..  not sure why, I thought commit people could do bug database bits.  Maybe 
someone will chime in on this topic for you.

Anyway, anyone can move the bug along, just let us know what state change you 
want.  I've assumed Fixed. was the state change you were interested in.  I've 
done that.

[committed] Fix gcc.dg/tree-ssa/builtin-sprintf-warn-4.c

[David Malcolm]

My fix to the locations for NUL-terminators in substring_loc changed
the output for gcc.dg/tree-ssa/builtin-sprintf-warn-4.c, leading to a
couple of FAILs from that test.  Sorry; my testing of the earlier patch
was incomplete (I needed to rebase).

I've committed the attached patch to trunk (r240442), which fixes the
test failures.Index: gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c	(revision 240441)
+++ gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c	(revision 240442)
@@ -12,7 +12,7 @@
  { dg-message "format output 2 bytes into a destination of size 1" "" { target *-*-*-* } 10 }
  { dg-begin-multiline-output "" }
sprintf (dst + 7, "%-s", "1");
- ^
+  ~~^~
  { dg-end-multiline-output "" }
  { dg-begin-multiline-output "" }
sprintf (dst + 7, "%-s", "1");
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(revision 240441)
+++ gcc/testsuite/ChangeLog	(revision 240442)
@@ -1,3 +1,10 @@
+2016-09-23  David Malcolm  
+
+	PR preprocessor/77672
+	* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test): Update
+	expected multiline output from first warning to reflect change
+	in r240434.
+
 2016-09-23  Thomas Preud'homme  
 
 	* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Fix xfail pattern.

[PATCH] Small hooks.c cleanup

[Jakub Jelinek]

Hi!

The generic hooks (except for one mistaken case) don't use any of the
arguments, and are generally meant to be used by any hooks that have such
arguments, so giving them names isn't really meaningful.
So, this patch uses the C++ nameless parameters type instead of type name
ATTRIBUTE_UNUSED.

The only exception is default_can_output_mi_thunk_no_vcall, IMHO it should
be moved to targhooks.[ch] instead, but the patch doesn't do that (yet).

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

2016-09-23  Jakub Jelinek  

* hooks.c (hook_bool_bool_false, hook_bool_bool_gcc_optionsp_false,
hook_bool_mode_false, hook_bool_mode_true,
hook_bool_mode_const_rtx_false, hook_bool_mode_const_rtx_true,
hook_bool_mode_rtx_false, hook_bool_mode_rtx_true,
hook_bool_const_rtx_insn_const_rtx_insn_true,
hook_bool_mode_uhwi_false, hook_void_FILEptr_constcharptr,
hook_bool_FILEptr_rtx_false, hook_bool_gsiptr_false,
hook_bool_const_tree_hwi_hwi_const_tree_false,
hook_bool_const_tree_hwi_hwi_const_tree_true,
default_can_output_mi_thunk_no_vcall, hook_int_uint_mode_1,
hook_int_const_tree_0, hook_int_const_tree_const_tree_1,
hook_int_rtx_0, hook_int_rtx_bool_0, hook_void_tree,
hook_void_constcharptr, hook_void_tree_treeptr, hook_void_int_int,
hook_bool_tree_false, hook_bool_const_tree_false, hook_bool_tree_true,
hook_bool_const_tree_true, hook_bool_tree_tree_false,
hook_bool_tree_tree_true, hook_bool_tree_bool_false,
hook_bool_rtx_insn_true, hook_bool_rtx_false,
hook_bool_uintp_uintp_false,
hook_bool_rtx_mode_int_int_intp_bool_false, hook_rtx_rtx_null,
hook_rtx_tree_int_null, hook_uint_mode_0,
hook_constcharptr_const_tree_null, hook_tree_tree_int_treep_bool_null,
hook_tree_tree_tree_null, hook_tree_tree_tree_tree_null,
hook_constcharptr_const_rtx_insn_null,
hook_constcharptr_const_tree_const_tree_null,
hook_constcharptr_int_const_tree_null,
hook_constcharptr_int_const_tree_const_tree_null,
hook_tree_const_tree_null, hook_bool_rtx_insn_int_false,
hook_void_rtx_insn_int, hook_void_gcc_optionsp): For arguments with
ATTRIBUTE_UNUSED, remove parameter name as well as ATTRIBUTE_UNUSED.

--- gcc/hooks.c.jj  2016-09-23 11:57:39.0 +0200
+++ gcc/hooks.c 2016-09-23 12:11:58.597703169 +0200
@@ -50,76 +50,70 @@ hook_bool_void_true (void)
 
 /* Generic hook that takes (bool) and returns false.  */
 bool
-hook_bool_bool_false (bool a ATTRIBUTE_UNUSED)
+hook_bool_bool_false (bool)
 {
   return false;
 }
 
 /* Generic hook that takes (bool, struct gcc_options *) and returns false.  */
 bool
-hook_bool_bool_gcc_optionsp_false (bool a ATTRIBUTE_UNUSED,
-  struct gcc_options *opts ATTRIBUTE_UNUSED)
+hook_bool_bool_gcc_optionsp_false (bool, struct gcc_options *)
 {
   return false;
 }
 
 /* Generic hook that takes const int, const int) and returns true.  */
-bool hook_bool_const_int_const_int_true (const int a ATTRIBUTE_UNUSED,
- const int b ATTRIBUTE_UNUSED)
+bool hook_bool_const_int_const_int_true (const int, const int)
 {
   return true;
 }
 
 /* Generic hook that takes (machine_mode) and returns false.  */
 bool
-hook_bool_mode_false (machine_mode mode ATTRIBUTE_UNUSED)
+hook_bool_mode_false (machine_mode)
 {
   return false;
 }
 
 /* Generic hook that takes (machine_mode) and returns true.  */
 bool
-hook_bool_mode_true (machine_mode mode ATTRIBUTE_UNUSED)
+hook_bool_mode_true (machine_mode)
 {
   return true;
 }
 
 /* Generic hook that takes (machine_mode, const_rtx) and returns false.  */
 bool
-hook_bool_mode_const_rtx_false (machine_mode mode ATTRIBUTE_UNUSED,
-   const_rtx value ATTRIBUTE_UNUSED)
+hook_bool_mode_const_rtx_false (machine_mode, const_rtx)
 {
   return false;
 }
 
 /* Generic hook that takes (machine_mode, const_rtx) and returns true.  */
 bool
-hook_bool_mode_const_rtx_true (machine_mode mode ATTRIBUTE_UNUSED,
-  const_rtx value ATTRIBUTE_UNUSED)
+hook_bool_mode_const_rtx_true (machine_mode, const_rtx)
 {
   return true;
 }
 
 /* Generic hook that takes (machine_mode, rtx) and returns false.  */
 bool
-hook_bool_mode_rtx_false (machine_mode mode ATTRIBUTE_UNUSED,
- rtx value ATTRIBUTE_UNUSED)
+hook_bool_mode_rtx_false (machine_mode, rtx)
 {
   return false;
 }
 
 /* Generic hook that takes (machine_mode, rtx) and returns true.  */
 bool
-hook_bool_mode_rtx_true (machine_mode mode ATTRIBUTE_UNUSED,
-rtx value ATTRIBUTE_UNUSED)
+hook_bool_mode_rtx_true (machine_mode, rtx)
 {
   return true;
 }
 
 /* Generic hook that takes (const rtx_insn *, const rtx_insn *) and returns 
true.  */
 bool
-hook_bool_const_rtx_insn_const_rtx_insn_true (const rtx_insn *follower 
ATTRIBUTE_UNUSED,
- 

[C++ PATCH] Implement P0138R2, C++17 construction rules for enum class values

[Jakub Jelinek]

Hi!

The following patch implements direct enum initialization as per C++17.
The change in reshape_init is needed for when it is called from
check_initializer and finish_compound_literal for e.g. E e { 5 } and
E { 5 } respectively, while the convert_for_assignment spot handles all the
other cases, which don't go through reshape_init, but on the other side
reshape_init strips away the CONSTRUCTOR needed to determine when to do this
and when not.

Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
regtested on both with make -C gcc check-c++-all.  Ok for trunk?

2016-09-23  Jakub Jelinek  

Implement P0138R2, C++17 construction rules for enum class values
* cp-tree.h (is_direct_enum_init): Declare.
* decl.c (is_direct_enum_init): New function.
(reshape_init): Use it.
* typeck.c (convert_for_assignment): Likewise.

* g++.dg/cpp1z/direct-enum-init1.C: New test.

--- gcc/cp/cp-tree.h.jj 2016-09-23 09:32:09.440454087 +0200
+++ gcc/cp/cp-tree.h2016-09-23 12:28:47.559905330 +0200
@@ -5829,6 +5829,7 @@ extern tree check_elaborated_type_specif
 extern void warn_extern_redeclared_static  (tree, tree);
 extern tree cxx_comdat_group   (tree);
 extern bool cp_missing_noreturn_ok_p   (tree);
+extern bool is_direct_enum_init(tree, tree);
 extern void initialize_artificial_var  (tree, vec *);
 extern tree check_var_type (tree, tree);
 extern tree reshape_init(tree, tree, tsubst_flags_t);
--- gcc/cp/decl.c.jj2016-09-23 09:33:36.770328046 +0200
+++ gcc/cp/decl.c   2016-09-23 12:28:47.563905279 +0200
@@ -5581,6 +5581,22 @@ next_initializable_field (tree field)
   return field;
 }
 
+/* Return true for [dcl.init.list] direct-list-initialization from
+   single element of enumeration with a fixed underlying type.  */
+
+bool
+is_direct_enum_init (tree type, tree init)
+{
+  if (cxx_dialect >= cxx1z
+  && TREE_CODE (type) == ENUMERAL_TYPE
+  && ENUM_FIXED_UNDERLYING_TYPE_P (type)
+  && TREE_CODE (init) == CONSTRUCTOR
+  && CONSTRUCTOR_IS_DIRECT_INIT (init)
+  && CONSTRUCTOR_NELTS (init) == 1)
+return true;
+  return false;
+}
+
 /* Subroutine of reshape_init_array and reshape_init_vector, which does
the actual work. ELT_TYPE is the element type of the array. MAX_INDEX is an
INTEGER_CST representing the size of the array minus one (the maximum 
index),
@@ -6026,6 +6042,17 @@ reshape_init (tree type, tree init, tsub
   if (vec_safe_is_empty (v))
 return init;
 
+  /* Handle [dcl.init.list] direct-list-initialization from
+ single element of enumeration with a fixed underlying type.  */
+  if (is_direct_enum_init (type, init))
+{
+  tree elt = CONSTRUCTOR_ELT (init, 0)->value;
+  if (check_narrowing (ENUM_UNDERLYING_TYPE (type), elt, complain))
+   return cp_build_c_cast (type, elt, tf_warning_or_error);
+  else
+   return error_mark_node;
+}
+
   /* Recurse on this CONSTRUCTOR.  */
   d.cur = &(*v)[0];
   d.end = d.cur + v->length ();
--- gcc/cp/typeck.c.jj  2016-09-14 23:49:03.0 +0200
+++ gcc/cp/typeck.c 2016-09-23 13:35:23.369149388 +0200
@@ -8266,6 +8266,17 @@ convert_for_assignment (tree type, tree
   if (TREE_CODE (rhs) == NON_LVALUE_EXPR)
 rhs = TREE_OPERAND (rhs, 0);
 
+  /* Handle [dcl.init.list] direct-list-initialization from
+ single element of enumeration with a fixed underlying type.  */
+  if (is_direct_enum_init (type, rhs))
+{
+  tree elt = CONSTRUCTOR_ELT (rhs, 0)->value;
+  if (check_narrowing (ENUM_UNDERLYING_TYPE (type), elt, complain))
+   rhs = cp_build_c_cast (type, elt, complain);
+  else
+   rhs = error_mark_node;
+}
+
   rhstype = TREE_TYPE (rhs);
   coder = TREE_CODE (rhstype);
 
--- gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C.jj   2016-09-23 
12:28:47.565905254 +0200
+++ gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C  2016-09-23 
16:37:49.596043501 +0200
@@ -0,0 +1,237 @@
+// P0138R2 - direct-list-initialization of enums
+// { dg-do compile { target c++11 } }
+
+enum A { G = 26 };
+enum B : short {};
+enum class C {};
+enum struct D : long {};
+enum class E : unsigned char { e = 7 };
+struct S { operator C () { return C (s); } int s; } s;
+struct T { operator long () { return t; } long t; } t;
+struct V { E v; };
+long l;
+long long ll;
+short c;
+void bar (E);
+
+void
+foo ()
+{
+  A a1 { 5 };  // { dg-error "invalid conversion from 'int' to 'A'" }
+  B b1 { 7 };  // { dg-error "invalid conversion from 'int' to 'B'" "" 
{ target c++14_down } }
+  C c1 { s };
+  D d1 { D(t) };   // { dg-error "invalid cast from type 'T' to type 'D'" }
+  D d2 { t };  // { dg-error "cannot convert 'T' to 'D' in 
initialization" "" { target c++14_down } }
+   // { dg-error "invalid cast from type 'T' to type 'D'" 
"" { target c++1z } .-1 }
+  D d3 { 9 };  // { dg-error

[C++ PATCH] Pass RUNTESTFLAGS through from check-c++1z

[Jakub Jelinek]

Hi!

I've been surprised that
make check-c++1z RUNTESTFLAGS=dg.exp=direct-enum*
attempts to run the whole testsuite in -std=c++1z mode,
while if I replace check-c++1z with check-g++ or check-c++-all,
it works properly.

The following patch passes the var down to the submake, so that it works
as expected.  Ok for trunk?

2016-09-23  Jakub Jelinek  

* Make-lang.in (check-c++1z): Pass RUNTESTFLAGS down to
make check-g++.

--- gcc/cp/Make-lang.in.jj  2016-06-28 14:13:37.0 +0200
+++ gcc/cp/Make-lang.in 2016-09-23 19:16:54.382005180 +0200
@@ -164,7 +164,7 @@ check-c++ : check-g++
 
 # Run the testsuite in C++1z mode.
 check-c++1z:
-   $(MAKE) GXX_TESTSUITE_STDS=1z check-g++
+   $(MAKE) RUNTESTFLAGS="$(RUNTESTFLAGS)" GXX_TESTSUITE_STDS=1z check-g++
 
 # Run the testsuite in all standard conformance levels.
 check-c++-all:

Jakub

[PATCH] Optimize truncating a basic_string

[Jonathan Wakely]

Currently str.erase(n) doesn't get inlined at -O2 and calls
_M_erase(n, length() - pos), which isn't very efficient. By checking
for the common case of erasing everything up to the end of the string
and avoiding _M_erase we can get it inlined. We can do the same thing
in erase(const_iterator, const_iterator) too by checking if the second
iterator is end(), and for resize() we don't even need to check
because (when shrinking the string) we know we're erasing to the end.

Thanks to Pedro Alves for pointing out this could be improved.

* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::erase(size_type, size_type)): Add fast path for
truncating the string, by calling _M_set_length directly.
(basic_string::erase(__const_iterator, __const_iterator)): Likewise.
* include/bits/basic_string.tcc [_GLIBCXX_USE_CXX11_ABI]
(basic_string::resize(size_type, _CharT)): Likewise.

Tested x86_64-linux, committed to trunk.


commit 63b539ac150ca68fe4f6762fc341bbc4a7737152
Author: Jonathan Wakely 
Date:   Fri Sep 23 16:55:42 2016 +0100

Optimize truncating a basic_string

* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::erase(size_type, size_type)): Add fast path for
truncating the string, by calling _M_set_length directly.
(basic_string::erase(__const_iterator, __const_iterator)): Likewise.
* include/bits/basic_string.tcc [_GLIBCXX_USE_CXX11_ABI]
(basic_string::resize(size_type, _CharT)): Likewise.

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index e823f13..2708cbc 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -1709,8 +1709,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   basic_string&
   erase(size_type __pos = 0, size_type __n = npos)
   {
-   this->_M_erase(_M_check(__pos, "basic_string::erase"),
-  _M_limit(__pos, __n));
+   _M_check(__pos, "basic_string::erase");
+   if (__n == npos)
+ this->_M_set_length(__pos);
+   else if (__n != 0)
+ this->_M_erase(__pos, _M_limit(__pos, __n));
return *this;
   }
 
@@ -1747,7 +1750,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
_GLIBCXX_DEBUG_PEDASSERT(__first >= begin() && __first <= __last
 && __last <= end());
 const size_type __pos = __first - begin();
-   this->_M_erase(__pos, __last - __first);
+   if (__last == end())
+ this->_M_set_length(__pos);
+   else
+ this->_M_erase(__pos, __last - __first);
return iterator(this->_M_data() + __pos);
   }
 
diff --git a/libstdc++-v3/include/bits/basic_string.tcc 
b/libstdc++-v3/include/bits/basic_string.tcc
index 0080d2b..df1e8dd 100644
--- a/libstdc++-v3/include/bits/basic_string.tcc
+++ b/libstdc++-v3/include/bits/basic_string.tcc
@@ -351,7 +351,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   if (__size < __n)
this->append(__n - __size, __c);
   else if (__n < __size)
-   this->_M_erase(__n, __size - __n);
+   this->_M_set_length(__n);
 }
 
   template

Re: [PATCH] Improve string::clear() performance

[Jonathan Wakely]

On 14/09/16 18:28 +0100, Jonathan Wakely wrote:

On 14/09/16 09:09 -0700, Cong Wang wrote:

On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely  wrote:

On 13/09/16 11:02 -0700, Cong Wang wrote:


In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls
_M_mutate(), which could allocate memory as we do COW. This hurts
performance when string::clear() is on the hot path.

This patch improves it by using _S_empty_rep directly when
_GLIBCXX_FULLY_DYNAMIC_STRING is not enabled. And Linux distro like
Fedora doesn't enable this, this is why we caught it.

The copy-and-clear test shows it improves by 50%.

Ran all testsuites on Linux-x64.



Thank you for the patch (and changelog and test results!).

Do you have a GCC copyright assignment in place? See
https://gcc.gnu.org/contribute.html#legal for details.


Oh, didn't notice this, I thought gcc has something as quick
as the 'Signed-off-by' for Linux kernel (I am a Linux kernel developer).
I will do it.



If I understand the purpose of the change correctly, it's similar to
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00278.html - is that
right?



Oh, yes, I didn't know your patch because I don't subscribe
gcc mailing list. I am wondering why your patch is not merged
after 2+ years?


As I said in the patch email, I'm not sure if it's conforming, due to
clearing the string's cpacity() as well as its size().


Please let me know what you prefer: 1) You update your patch
and get it merged; 2) Use my patch if it looks good. I am fine with
either way. :)


I'll refresh my memory of the various issues and reconsider applying
my patch (that way we don't need to wait for your copyright
assignment). The performance benefits you measured make it more
compelling.


I'm applying this patch, which is my one from 2014 with a check for
whether the string is shared, so we just set the length to zero (and
don't throw away reusable capacity) when it's not shared.

Tested x86_64-linux, committed to trunk.


commit b9546ed53b169ffb809371231342eeb63595d8bc
Author: Jonathan Wakely 
Date:   Fri Sep 23 18:01:25 2016 +0100

Avoid reallocation for basic_string::clear()

	PR libstdc++/56166
	PR libstdc++/77582
	* include/bits/basic_string.h (basic_string::clear()): Drop reference
	and use empty rep.
	* include/ext/rc_string_base.h (__rc_string_base::_M_clear()):
	Likewise.
	* testsuite/21_strings/basic_string/56166.cc: New.
	* testsuite/ext/vstring/modifiers/clear/56166.cc: New.

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index 2708cbc..7a4204e 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -3690,10 +3690,24 @@ _GLIBCXX_END_NAMESPACE_CXX11
   /**
*  Erases the string, making it empty.
*/
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
+  void
+  clear() _GLIBCXX_NOEXCEPT
+  {
+	if (_M_rep()->_M_is_shared())
+	  {
+	_M_rep()->_M_dispose(this->get_allocator());
+	_M_data(_S_empty_rep()._M_refdata());
+	  }
+	else
+	  _M_rep()->_M_set_length_and_sharable(0);
+  }
+#else
   // PR 56166: this should not throw.
   void
   clear()
   { _M_mutate(0, this->size(), 0); }
+#endif
 
   /**
*  Returns true if the %string is empty.  Equivalent to 
diff --git a/libstdc++-v3/include/ext/rc_string_base.h b/libstdc++-v3/include/ext/rc_string_base.h
index 1c1ed87..eab3461 100644
--- a/libstdc++-v3/include/ext/rc_string_base.h
+++ b/libstdc++-v3/include/ext/rc_string_base.h
@@ -354,7 +354,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   void
   _M_clear()
-  { _M_erase(size_type(0), _M_length()); }
+  {
+	_M_dispose();
+	_M_data(_S_empty_rep._M_refcopy());
+  }
 
   bool
   _M_compare(const __rc_string_base&) const
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/56166.cc b/libstdc++-v3/testsuite/21_strings/basic_string/56166.cc
new file mode 100644
index 000..3d4d876
--- /dev/null
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/56166.cc
@@ -0,0 +1,93 @@
+// Copyright (C) 2016 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-do run { target c++11 } }
+
+// libstdc++/56166
+
+#ifndef _GLIBCXX_USE_CXX11_ABI
+# define _GLIBCXX_USE_CXX11_ABI 0
+#endif

Re: [C++ PATCH] Pass RUNTESTFLAGS through from check-c++1z

[Jason Merrill]

OK.

On Fri, Sep 23, 2016 at 1:23 PM, Jakub Jelinek  wrote:
> Hi!
>
> I've been surprised that
> make check-c++1z RUNTESTFLAGS=dg.exp=direct-enum*
> attempts to run the whole testsuite in -std=c++1z mode,
> while if I replace check-c++1z with check-g++ or check-c++-all,
> it works properly.
>
> The following patch passes the var down to the submake, so that it works
> as expected.  Ok for trunk?
>
> 2016-09-23  Jakub Jelinek  
>
> * Make-lang.in (check-c++1z): Pass RUNTESTFLAGS down to
> make check-g++.
>
> --- gcc/cp/Make-lang.in.jj  2016-06-28 14:13:37.0 +0200
> +++ gcc/cp/Make-lang.in 2016-09-23 19:16:54.382005180 +0200
> @@ -164,7 +164,7 @@ check-c++ : check-g++
>
>  # Run the testsuite in C++1z mode.
>  check-c++1z:
> -   $(MAKE) GXX_TESTSUITE_STDS=1z check-g++
> +   $(MAKE) RUNTESTFLAGS="$(RUNTESTFLAGS)" GXX_TESTSUITE_STDS=1z check-g++
>
>  # Run the testsuite in all standard conformance levels.
>  check-c++-all:
>
> Jakub

Re: [C++ PATCH] Implement P0138R2, C++17 construction rules for enum class values

[Jason Merrill]

OK.

On Fri, Sep 23, 2016 at 1:14 PM, Jakub Jelinek  wrote:
> Hi!
>
> The following patch implements direct enum initialization as per C++17.
> The change in reshape_init is needed for when it is called from
> check_initializer and finish_compound_literal for e.g. E e { 5 } and
> E { 5 } respectively, while the convert_for_assignment spot handles all the
> other cases, which don't go through reshape_init, but on the other side
> reshape_init strips away the CONSTRUCTOR needed to determine when to do this
> and when not.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
> regtested on both with make -C gcc check-c++-all.  Ok for trunk?
>
> 2016-09-23  Jakub Jelinek  
>
> Implement P0138R2, C++17 construction rules for enum class values
> * cp-tree.h (is_direct_enum_init): Declare.
> * decl.c (is_direct_enum_init): New function.
> (reshape_init): Use it.
> * typeck.c (convert_for_assignment): Likewise.
>
> * g++.dg/cpp1z/direct-enum-init1.C: New test.
>
> --- gcc/cp/cp-tree.h.jj 2016-09-23 09:32:09.440454087 +0200
> +++ gcc/cp/cp-tree.h2016-09-23 12:28:47.559905330 +0200
> @@ -5829,6 +5829,7 @@ extern tree check_elaborated_type_specif
>  extern void warn_extern_redeclared_static  (tree, tree);
>  extern tree cxx_comdat_group   (tree);
>  extern bool cp_missing_noreturn_ok_p   (tree);
> +extern bool is_direct_enum_init(tree, tree);
>  extern void initialize_artificial_var  (tree, vec va_gc> *);
>  extern tree check_var_type (tree, tree);
>  extern tree reshape_init(tree, tree, tsubst_flags_t);
> --- gcc/cp/decl.c.jj2016-09-23 09:33:36.770328046 +0200
> +++ gcc/cp/decl.c   2016-09-23 12:28:47.563905279 +0200
> @@ -5581,6 +5581,22 @@ next_initializable_field (tree field)
>return field;
>  }
>
> +/* Return true for [dcl.init.list] direct-list-initialization from
> +   single element of enumeration with a fixed underlying type.  */
> +
> +bool
> +is_direct_enum_init (tree type, tree init)
> +{
> +  if (cxx_dialect >= cxx1z
> +  && TREE_CODE (type) == ENUMERAL_TYPE
> +  && ENUM_FIXED_UNDERLYING_TYPE_P (type)
> +  && TREE_CODE (init) == CONSTRUCTOR
> +  && CONSTRUCTOR_IS_DIRECT_INIT (init)
> +  && CONSTRUCTOR_NELTS (init) == 1)
> +return true;
> +  return false;
> +}
> +
>  /* Subroutine of reshape_init_array and reshape_init_vector, which does
> the actual work. ELT_TYPE is the element type of the array. MAX_INDEX is 
> an
> INTEGER_CST representing the size of the array minus one (the maximum 
> index),
> @@ -6026,6 +6042,17 @@ reshape_init (tree type, tree init, tsub
>if (vec_safe_is_empty (v))
>  return init;
>
> +  /* Handle [dcl.init.list] direct-list-initialization from
> + single element of enumeration with a fixed underlying type.  */
> +  if (is_direct_enum_init (type, init))
> +{
> +  tree elt = CONSTRUCTOR_ELT (init, 0)->value;
> +  if (check_narrowing (ENUM_UNDERLYING_TYPE (type), elt, complain))
> +   return cp_build_c_cast (type, elt, tf_warning_or_error);
> +  else
> +   return error_mark_node;
> +}
> +
>/* Recurse on this CONSTRUCTOR.  */
>d.cur = &(*v)[0];
>d.end = d.cur + v->length ();
> --- gcc/cp/typeck.c.jj  2016-09-14 23:49:03.0 +0200
> +++ gcc/cp/typeck.c 2016-09-23 13:35:23.369149388 +0200
> @@ -8266,6 +8266,17 @@ convert_for_assignment (tree type, tree
>if (TREE_CODE (rhs) == NON_LVALUE_EXPR)
>  rhs = TREE_OPERAND (rhs, 0);
>
> +  /* Handle [dcl.init.list] direct-list-initialization from
> + single element of enumeration with a fixed underlying type.  */
> +  if (is_direct_enum_init (type, rhs))
> +{
> +  tree elt = CONSTRUCTOR_ELT (rhs, 0)->value;
> +  if (check_narrowing (ENUM_UNDERLYING_TYPE (type), elt, complain))
> +   rhs = cp_build_c_cast (type, elt, complain);
> +  else
> +   rhs = error_mark_node;
> +}
> +
>rhstype = TREE_TYPE (rhs);
>coder = TREE_CODE (rhstype);
>
> --- gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C.jj   2016-09-23 
> 12:28:47.565905254 +0200
> +++ gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C  2016-09-23 
> 16:37:49.596043501 +0200
> @@ -0,0 +1,237 @@
> +// P0138R2 - direct-list-initialization of enums
> +// { dg-do compile { target c++11 } }
> +
> +enum A { G = 26 };
> +enum B : short {};
> +enum class C {};
> +enum struct D : long {};
> +enum class E : unsigned char { e = 7 };
> +struct S { operator C () { return C (s); } int s; } s;
> +struct T { operator long () { return t; } long t; } t;
> +struct V { E v; };
> +long l;
> +long long ll;
> +short c;
> +void bar (E);
> +
> +void
> +foo ()
> +{
> +  A a1 { 5 };  // { dg-error "invalid conversion from 'int' to 'A'" }
> +  B b1 { 7 };  // { dg-error "invalid conversion from 'int' to 'B'" 
> "" { target c++14_down } }
> +  C c1 { s };
> +  D d1 { D(t) };   // {

Re: [PATCH] Improve string::clear() performance

[Cong Wang]

On Fri, Sep 23, 2016 at 10:25 AM, Jonathan Wakely  wrote:
>
> I'm applying this patch, which is my one from 2014 with a check for
> whether the string is shared, so we just set the length to zero (and
> don't throw away reusable capacity) when it's not shared.
>
> Tested x86_64-linux, committed to trunk.

Great! Thanks for letting me know.

Re: [PATCH] Fix various minor gimple-ssa-sprintf.c issues

[Martin Sebor]

On 09/22/2016 01:46 AM, Marek Polacek wrote:

On Thu, Sep 22, 2016 at 09:24:11AM +0200, Jakub Jelinek wrote:

On Wed, Sep 21, 2016 at 06:38:54PM -0600, Martin Sebor wrote:

On 09/21/2016 09:09 AM, Jakub Jelinek wrote:

When looking at PR77676, I've noticed various small formatting etc.
issues, like not using is_gimple_* APIs where we have them, not using
gimple_call_builtin_p/gimple_call_fndecl (this one actually can show up,
if e.g. uses the builtin with incorrect arguments (fewer, different
types etc.)), one pasto, 2 spaces in comments instead of 1 in the middle
of sentences.  And, lastly 0 < var is very unusual ordering of the
comparison operands, while we have a couple of such cases in the sources,
usually it is when using 0 < var && var <= someotherconst, while
var > 0 is used hundred times more often.


Thanks for correcting the uses of the gimple APIs!  I appreciate
your fixing the various typos as well, but I see no value in
changing the order of operands in inequality expressions or in
moving code around for no apparent reason.  However, I won't


The moving of code around is in just one spot, and it has a reason -
consistency.  After the move, each non-_chk builtin is followed by its _chk
counterpart, before that the order has been random.
Another possible ordering that makes sense is putting all the non-_chk
builtins first and then in the same order all their _chk counterparts.

The reason why I wrote the patch has been that when skimming the code I've
noticed the missing is_* calls, then when looking for that issue discovered
something different etc.  The var > 0 vs. 0 < var is just something that
caught my eye when looking around, I don't feel too strongly about it, it
just looked weird and unexpected.  There are > 50 optimize > 0 preexisting
checks elsewhere, and even far more just optimize, but none 0 < optimize.


I find those 0 < var confusing and hard to read.  While I know that some
people prefer 0 == var (0 is not an lvalue so it catches mistakes like
var = 0 instead of var == 0), I don't see why 0 < optimized would ever be
preferred.


I don't have a preference for one or the other.  It's just how
I wrote the code.  Over the years of working on the C++ standard
library I trained myself to use the less than expression in
preference to any of the others because C++ algorithms had to
(or we wanted them to, I don't remember which anymore) work with 
user-defined types that only defined that one relational operator

and not any of the other forms.

Martin

Go patch committed: Fix calls to integer_type

[Ian Lance Taylor]

The code in the Gcc_backend constructor in the Go frontend incorrectly
calls integer_type with a size argument followed by a sign flag, but
the signature of integer_type is reversed: a sign flag followed by the
size.  This patch by Chris Manghane fixes the problem.  This is GCC PR
77701.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.

Ian

2016-09-23  Chris Manghane  

PR go/77701
* go-gcc.cc (Gcc_backend::Gcc_backend): Fix calls to integer_type
to pass arguments in the correct order.
Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc(revision 240382)
+++ gcc/go/go-gcc.cc(working copy)
@@ -651,25 +651,25 @@ Gcc_backend::Gcc_backend()
 {
   /* We need to define the fetch_and_add functions, since we use them
  for ++ and --.  */
-  tree t = this->integer_type(BITS_PER_UNIT, 1)->get_tree();
+  tree t = this->integer_type(true, BITS_PER_UNIT)->get_tree();
   tree p = build_pointer_type(build_qualified_type(t, TYPE_QUAL_VOLATILE));
   this->define_builtin(BUILT_IN_SYNC_ADD_AND_FETCH_1, "__sync_fetch_and_add_1",
   NULL, build_function_type_list(t, p, t, NULL_TREE),
   false, false);
 
-  t = this->integer_type(BITS_PER_UNIT * 2, 1)->get_tree();
+  t = this->integer_type(true, BITS_PER_UNIT * 2)->get_tree();
   p = build_pointer_type(build_qualified_type(t, TYPE_QUAL_VOLATILE));
   this->define_builtin(BUILT_IN_SYNC_ADD_AND_FETCH_2, "__sync_fetch_and_add_2",
   NULL, build_function_type_list(t, p, t, NULL_TREE),
   false, false);
 
-  t = this->integer_type(BITS_PER_UNIT * 4, 1)->get_tree();
+  t = this->integer_type(true, BITS_PER_UNIT * 4)->get_tree();
   p = build_pointer_type(build_qualified_type(t, TYPE_QUAL_VOLATILE));
   this->define_builtin(BUILT_IN_SYNC_ADD_AND_FETCH_4, "__sync_fetch_and_add_4",
   NULL, build_function_type_list(t, p, t, NULL_TREE),
   false, false);
 
-  t = this->integer_type(BITS_PER_UNIT * 8, 1)->get_tree();
+  t = this->integer_type(true, BITS_PER_UNIT * 8)->get_tree();
   p = build_pointer_type(build_qualified_type(t, TYPE_QUAL_VOLATILE));
   this->define_builtin(BUILT_IN_SYNC_ADD_AND_FETCH_8, "__sync_fetch_and_add_8",
   NULL, build_function_type_list(t, p, t, NULL_TREE),

Re: [Patch, fortran] Clean up of error recovery in DTIO procedures

[Paul Richard Thomas]

Dear Rainer,

Thanks for the report. I'll have a stab at finding the problem
tomorrow. In the interim, could you try applying:

Index: /svn/trunk/gcc/fortran/interface.c
===
*** /svn/trunk/gcc/fortran/interface.c(revision 240349)
--- /svn/trunk/gcc/fortran/interface.c(working copy)
*** gfc_find_specific_dtio_proc (gfc_symbol
*** 4793,4798 
--- 4793,4801 
gfc_typebound_proc *tb_io_proc, *specific_proc;
bool t = false;

+   if (derived == NULL)
+ return NULL;
+
/* Try to find a typebound DTIO binding.  */
if (formatted == true)
  {

Cheers

Paul

On 23 September 2016 at 14:08, Rainer Orth  
wrote:
> Hi Paul,
>
>> Dear All,
>>
>> Please find attached a patch to clean up the various issues with
>> errors in DTIO procedures. The tests were all provided by Gerhard
>> Steinmetz for which thanks are due.
>>
>> I intend to commit this patch as 'obvious' tomorrow morning unless
>> there are any objections in the meantime.
>>
>> Bootstrapped and regtested on x86_64/FC21 - OK for trunk?
>>
>> Paul
>>
>> 2016-09-21  Paul Thomas  
>>
>> * interface.c (check_dtio_interface1): Introduce errors for
>> alternate returns and incorrect numbers of arguments.
>> (gfc_find_specific_dtio_proc): Return cleanly if the derived
>> type either doesn't exist or has no namespace.
>>
>> 2016-09-21  Paul Thomas  
>>
>> * gfortran.dg/dtio_13.f90: New test.
>
> This test ICEs on Solaris (both sparc and x86, 32 and 64-bit):
>
> FAIL: gfortran.dg/dtio_13.f90   -O   (test for errors, line 141)
> FAIL: gfortran.dg/dtio_13.f90   -O  (internal compiler error)
> FAIL: gfortran.dg/dtio_13.f90   -O  (test for excess errors)
>
> Excess errors:
> f951: internal compiler error: Segmentation Fault
> 0x8e165ec crash_signal
> /vol/gcc/src/hg/trunk/local/gcc/toplev.c:337
> 0x89357b8 gfc_find_symtree(gfc_symtree*, char const*)
> /vol/gcc/src/hg/trunk/local/gcc/fortran/symbol.c:2737
> 0x8895b77 find_typebound_proc_uop
> /vol/gcc/src/hg/trunk/local/gcc/fortran/class.c:2753
> 0x88c2a60 gfc_find_specific_dtio_proc(gfc_symbol*, bool, bool)
> /vol/gcc/src/hg/trunk/local/gcc/fortran/interface.c:4825
> 0x89166cb resolve_transfer
> /vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:8738
> 0x89166cb gfc_resolve_code(gfc_code*, gfc_namespace*)
> /vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:10874
> 0x8914e9c gfc_resolve_blocks(gfc_code*, gfc_namespace*)
> /vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:9616
> 0x89152e8 gfc_resolve_code(gfc_code*, gfc_namespace*)
> /vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:10557
> 0x89178d1 resolve_codes
> /vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:15721
> 0x89179b1 gfc_resolve(gfc_namespace*)
> 0x89179b1 gfc_resolve(gfc_namespace*)
> /vol/gcc/src/hg/trunk/local/gcc/fortran/resolve.c:15756
> 0x8902909 resolve_all_program_units
> /vol/gcc/src/hg/trunk/local/gcc/fortran/parse.c:5875
> 0x8902909 gfc_parse_file()
> /vol/gcc/src/hg/trunk/local/gcc/fortran/parse.c:6127
> 0x8944d30 gfc_be_parse_file
> /vol/gcc/src/hg/trunk/local/gcc/fortran/f95-lang.c:198
>
> The failure can be reproduced with
>
> $ f951 gfortran.dg/dtio_13.f90 -quiet -o dtio_13.s
>
> In gdb, I find
>
> Thread 2 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1 (LWP 1)]
> 0x089357b8 in gfc_find_symtree (st=0x1,
> name=0x83726a6 "_dtio_unformatted_read")
> at /vol/gcc/src/hg/trunk/local/gcc/fortran/symbol.c:2737
> 2737  c = strcmp (name, st->name);
> (gdb) p name
> $1 = 0x83726a6 "_dtio_unformatted_read"
> (gdb) p st->name
> Cannot access memory at address 0xd
>
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

[Jason Merrill]

On Thu, Sep 22, 2016 at 7:39 PM, Martin Sebor  wrote:
> On 09/21/2016 02:43 PM, Jason Merrill wrote:
>> On Tue, Sep 20, 2016 at 1:01 PM, Martin Sebor  wrote:
>>> On 09/16/2016 12:19 PM, Jason Merrill wrote:
 On 09/14/2016 01:03 PM, Martin Sebor wrote:
>
> +  /* Type of the member.  */
> +  tree fldtype = TREE_CODE (fld) == FIELD_DECL ? TREE_TYPE (fld) : 
> fld;

 Why set "fldtype" to be a TYPE_DECL rather than its type?
>>>
>>> I'm not sure I understand the question but (IIRC) the purpose of
>>> this code is to detect invalid uses of flexible array members in
>>> typedefs such as this:
>>>
>>>struct S { typedef struct { int i, a[]; } X2 [2]; };
>>>
>>> Sadly, it doesn't do anything for
>>>
>>>struct X { int i, a[]; };
>>>struct S { typedef struct X X2 [2]; };
>>
>> The issue is I don't see anything that uses fldtype as a decl, and
>> it's strange to have a variable called "*type" that can either be a
>> type or a decl, which later code still assumes will be a type.
>
> I suspect I'm simply looking at it from a different point of view.
> The definition
>
>   tree fldtype = TREE_CODE (fld) == FIELD_DECL ? TREE_TYPE (fld) : fld
>
> denotes the type of the field if fld is a data member.  Otherwise,
> it denotes a type (like a typedef).

FLD is always a _DECL.  The result of this assignment is that fldtype
refers to either a _TYPE or a _DECL.  This creates a strange
asymmetry, and none of the following code seems to depend on it.

> Fldtype seems as a good a name
> as any but I'll gladly rename it to something else if that lets us
> move forward.  What would you prefer?

I would prefer

tree fldtype = TREE_TYPE (fld);

so that it's always a _TYPE.

> +  /* The context of the flexible array member.  Either the struct
> + in which it's declared or, for anonymous structs and unions,
> + the struct/union of which the array is effectively a member.  */
> +  tree fmemctx = anon_context (fmem->array);
> +  bool anon_p = fmemctx != DECL_CONTEXT (fmem->array);
> +  if (!anon_p)
> +fmemctx = t;

 Why do you need to do something different here based on anon_p?  I don't
 see why that would affect whether we want to look through intermediate
 non-anonymous classes.
>>>
>>> In code like this:
>>>
>>>struct X { int n, a[]; };
>>>struct Y { int n, b[]; };
>>>
>>>struct D: X, Y { };
>>>
>>> The test above make the diagnostic point to the context of the invalid
>>> flexible array member, or Y::b, rather than that of X. Without it, we
>>> end up with:
>>>
>>>error: flexible array member ‘X::a’ not at end of ‘struct X’
>>>
>>> rather than with
>>>
>>>error: flexible array member ‘X::a’ not at end of ‘struct D’
>>
>> Yes, but why does whether we want to talk about X or D change if a is
>> wrapped in struct { }?
>
> Sorry, I don't understand the question.  A flexible array is always
> "wrapped in struct { }" so I'm not sure what you mean by that.  And
> "we want to talk about D" because that's where the next member after
> a is defined (we could also say it's defined in struct Y and I think
> I may have been down that path at one point and decided this was fine
> or perhaps even better or simpler but I don't recall which for sure.)
>
> Btw., I used quotes above only to explain how I read your question,
> not to mock what you said in any way.
>
> Going back and looking at some of the older patches, this hunk above
> was changed from the original patch like so:
>
> @@ -6923,7 +6930,10 @@ diagnose_flexarrays (tree t, const flexmems_t *fmem)
>  /* The context of the flexible array member.  Either the struct
> in which it's declared or, for anonymous structs and unions,
> the struct/union of which the array is effectively a member.  */
> -tree fmemctx = fmem->anonctx ? fmem->anonctx : t;
> +tree fmemctx = anon_context (fmem->array);
> +bool anon_p = fmemctx != DECL_CONTEXT (fmem->array);
> +if (!anon_p)
> +  fmemctx = t;
>
> I made this change because you preferred deriving the fmemctx value
> in a new function rather than storing it the fmem->anonctx member.
> I don't know if this helps clarify it.
>
>   https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00153.html

My point is that for

struct X { int n, a[]; };
struct X2 { struct { int n, a[]; }; };
struct Y { int n, b[]; };

struct D: X, Y { };
struct D2: X2, Y { };

We say

wa3.C:1:21: error: flexible array member ‘X::a’ not at end of ‘struct D’
wa3.C:2:31: error: flexible array member ‘X2a’ not
at end of ‘struct X2’

If we want to say "struct D", why don't we also want to say "struct
D2"?  It seems that you could unconditionally set fmemctx to t and not
bother calling anon_context.

> (FWIW, it's been a stressful couple of days with the regressions
> that my recent commit caused, so I hope you can bear with me if
> I seem slow or dense on these two points.)

No worries.

> [comments with parameter names/default arguments]

Re: [PATCH] Fix PR tree-optimization/77654

[Richard Biener]

On September 23, 2016 6:17:17 PM GMT+02:00, Mike Stump  
wrote:
>On Sep 23, 2016, at 8:55 AM, Matthew Fortune
> wrote:
>> 
>> Doug Gilmore  writes:
 From: Richard Biener [rguent...@suse.de]
 Sent: Thursday, September 22, 2016 12:43 AM
 To: Doug Gilmore
 Cc: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
 Subject: RE: [PATCH] Fix PR tree-optimization/77654
 
 On Wed, 21 Sep 2016, Doug Gilmore wrote:
 
 ...
> Sorry I that missed point.  I glossed your comment "addr_base
>should
> always be a pointer", causing me to go off into the weeds.
> 
> New patch attached.
 
 Ok if successfully bootstrapped / tested.
 
 Thanks,
 Richard.
>>> The change bootstrapped on X86_64 and the several "make check"
>errors
>>> also appeared in latest archived mail message to gcc-testresults.
>> 
>> Committed as r240439.
>> 
>> (Fixed whitespace/tab issue in the code and incorrect file in
>changelog)
>> 
>> I can't progress the bug status. Who does that normally?
>
>Hum..  not sure why, I thought commit people could do bug database
>bits.  Maybe someone will chime in on this topic for you.

You need to use a bugzilla account with your @gcc.gnu.org address.  Those have 
appropriate permissions.

Richard.

>Anyway, anyone can move the bug along, just let us know what state
>change you want.  I've assumed Fixed. was the state change you were
>interested in.  I've done that.

Re: [PATCH] Small hooks.c cleanup

[Richard Biener]

On September 23, 2016 7:04:29 PM GMT+02:00, Jakub Jelinek  
wrote:
>Hi!
>
>The generic hooks (except for one mistaken case) don't use any of the
>arguments, and are generally meant to be used by any hooks that have
>such
>arguments, so giving them names isn't really meaningful.
>So, this patch uses the C++ nameless parameters type instead of type
>name
>ATTRIBUTE_UNUSED.
>
>The only exception is default_can_output_mi_thunk_no_vcall, IMHO it
>should
>be moved to targhooks.[ch] instead, but the patch doesn't do that
>(yet).
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

>2016-09-23  Jakub Jelinek  
>
>   * hooks.c (hook_bool_bool_false, hook_bool_bool_gcc_optionsp_false,
>   hook_bool_mode_false, hook_bool_mode_true,
>   hook_bool_mode_const_rtx_false, hook_bool_mode_const_rtx_true,
>   hook_bool_mode_rtx_false, hook_bool_mode_rtx_true,
>   hook_bool_const_rtx_insn_const_rtx_insn_true,
>   hook_bool_mode_uhwi_false, hook_void_FILEptr_constcharptr,
>   hook_bool_FILEptr_rtx_false, hook_bool_gsiptr_false,
>   hook_bool_const_tree_hwi_hwi_const_tree_false,
>   hook_bool_const_tree_hwi_hwi_const_tree_true,
>   default_can_output_mi_thunk_no_vcall, hook_int_uint_mode_1,
>   hook_int_const_tree_0, hook_int_const_tree_const_tree_1,
>   hook_int_rtx_0, hook_int_rtx_bool_0, hook_void_tree,
>   hook_void_constcharptr, hook_void_tree_treeptr, hook_void_int_int,
>   hook_bool_tree_false, hook_bool_const_tree_false, hook_bool_tree_true,
>   hook_bool_const_tree_true, hook_bool_tree_tree_false,
>   hook_bool_tree_tree_true, hook_bool_tree_bool_false,
>   hook_bool_rtx_insn_true, hook_bool_rtx_false,
>   hook_bool_uintp_uintp_false,
>   hook_bool_rtx_mode_int_int_intp_bool_false, hook_rtx_rtx_null,
>   hook_rtx_tree_int_null, hook_uint_mode_0,
>   hook_constcharptr_const_tree_null, hook_tree_tree_int_treep_bool_null,
>   hook_tree_tree_tree_null, hook_tree_tree_tree_tree_null,
>   hook_constcharptr_const_rtx_insn_null,
>   hook_constcharptr_const_tree_const_tree_null,
>   hook_constcharptr_int_const_tree_null,
>   hook_constcharptr_int_const_tree_const_tree_null,
>   hook_tree_const_tree_null, hook_bool_rtx_insn_int_false,
>   hook_void_rtx_insn_int, hook_void_gcc_optionsp): For arguments with
>   ATTRIBUTE_UNUSED, remove parameter name as well as ATTRIBUTE_UNUSED.
>
>--- gcc/hooks.c.jj 2016-09-23 11:57:39.0 +0200
>+++ gcc/hooks.c2016-09-23 12:11:58.597703169 +0200
>@@ -50,76 +50,70 @@ hook_bool_void_true (void)
> 
> /* Generic hook that takes (bool) and returns false.  */
> bool
>-hook_bool_bool_false (bool a ATTRIBUTE_UNUSED)
>+hook_bool_bool_false (bool)
> {
>   return false;
> }
> 
>/* Generic hook that takes (bool, struct gcc_options *) and returns
>false.  */
> bool
>-hook_bool_bool_gcc_optionsp_false (bool a ATTRIBUTE_UNUSED,
>- struct gcc_options *opts ATTRIBUTE_UNUSED)
>+hook_bool_bool_gcc_optionsp_false (bool, struct gcc_options *)
> {
>   return false;
> }
> 
> /* Generic hook that takes const int, const int) and returns true.  */
>-bool hook_bool_const_int_const_int_true (const int a ATTRIBUTE_UNUSED,
>- const int b ATTRIBUTE_UNUSED)
>+bool hook_bool_const_int_const_int_true (const int, const int)
> {
>   return true;
> }
> 
> /* Generic hook that takes (machine_mode) and returns false.  */
> bool
>-hook_bool_mode_false (machine_mode mode ATTRIBUTE_UNUSED)
>+hook_bool_mode_false (machine_mode)
> {
>   return false;
> }
> 
> /* Generic hook that takes (machine_mode) and returns true.  */
> bool
>-hook_bool_mode_true (machine_mode mode ATTRIBUTE_UNUSED)
>+hook_bool_mode_true (machine_mode)
> {
>   return true;
> }
> 
>/* Generic hook that takes (machine_mode, const_rtx) and returns false.
> */
> bool
>-hook_bool_mode_const_rtx_false (machine_mode mode ATTRIBUTE_UNUSED,
>-  const_rtx value ATTRIBUTE_UNUSED)
>+hook_bool_mode_const_rtx_false (machine_mode, const_rtx)
> {
>   return false;
> }
> 
>/* Generic hook that takes (machine_mode, const_rtx) and returns true. 
>*/
> bool
>-hook_bool_mode_const_rtx_true (machine_mode mode ATTRIBUTE_UNUSED,
>- const_rtx value ATTRIBUTE_UNUSED)
>+hook_bool_mode_const_rtx_true (machine_mode, const_rtx)
> {
>   return true;
> }
> 
> /* Generic hook that takes (machine_mode, rtx) and returns false.  */
> bool
>-hook_bool_mode_rtx_false (machine_mode mode ATTRIBUTE_UNUSED,
>-rtx value ATTRIBUTE_UNUSED)
>+hook_bool_mode_rtx_false (machine_mode, rtx)
> {
>   return false;
> }
> 
> /* Generic hook that takes (machine_mode, rtx) and returns true.  */
> bool
>-hook_bool_mode_rtx_true (machine_mode mode ATTRIBUTE_UNUSED,
>-   rtx value ATTRIBUTE_UNUSED)
>+hook_bool_mode_rtx_true (machine_mode, rtx)
> {
>   return true;
> }
> 
>/* Generic hook tha

Re: [PATCH] Refactor section/label init for early LTO debug

[Jason Merrill]

OK.

On Wed, Sep 21, 2016 at 9:19 AM, Richard Biener  wrote:
>
> The following patch ports a refactoring of section/label in it from
> the early LTO debug work to trunk.  For early LTO debug we need to
> be able to emit two sets of debug infos into two sets of different
> sections - early LTO into .gnu.debuglto_ prefixed sections and
> regular (early + late) debug for the FAT part of the object.
>
> Thus this preparation splits out the section and label generation
> from dwarf2out_init moving the text section related stuff to
> dwarf2out_assembly_start and the rest to a new function
> init_sections_and_labels which is now called only before we start
> outputting dwarf (in dwarf2out_finish).  It also removes some
> dwarf_split_debug_info checks from the macro section name defines
> (in the end I'll have up to four variants - regular, regular LTO,
> DWO, DWO LTO).
>
> And it removes an unused function.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.  I've
> also bootstrapped with -O2 -g3 to exercise the .debug_macro path.
>
> Ok?
>
> Just noticed that DEBUG_STR_OFFSETS_SECTION needs similar massaging
> for its dwarf_split_debug_info condition - will followup as obvious
> if this one is approved.
>
> Thanks,
> Richard.
>
> 2016-09-21  Richard Biener  
>
> * dwarf2out.c (stripattributes): Remove unused function.
> (DEBUG_NORM_MACINFO_SECTION): Rename to DEBUG_MACINFO_SECTION.
> Push dwarf_split_debug_info handling into init_sections_and_labels.
> (DEBUG_NORM_MACRO_SECTION): Likewise to DEBUG_MACRO_SECTION.
> (DEBUG_MACRO_SECTION_FLAGS): Remove.
> (debug_macinfo_section_name): New global.
> (output_macinfo): Use debug_macinfo_section_name.
> (init_sections_and_labels): Split out section and label generation
> from dwarf2out_init.  Set debug_macinfo_section_name.
> (dwarf2out_init): Move text section label generation and emission
> to ...
> (dwarf2out_assembly_start): ... here.
> (dwarf2out_finish): Call init_sections_and_labels before DWARF
> output starts.
>
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c (revision 240303)
> +++ gcc/dwarf2out.c (working copy)
> @@ -159,6 +159,7 @@ static GTY(()) section *debug_skeleton_a
>  static GTY(()) section *debug_aranges_section;
>  static GTY(()) section *debug_addr_section;
>  static GTY(()) section *debug_macinfo_section;
> +static const char *debug_macinfo_section_name;
>  static GTY(()) section *debug_line_section;
>  static GTY(()) section *debug_skeleton_line_section;
>  static GTY(()) section *debug_loc_section;
> @@ -265,7 +266,6 @@ static GTY(()) dw_die_ref decltype_auto_
>
>  /* Forward declarations for functions defined in this file.  */
>
> -static char *stripattributes (const char *);
>  static void output_call_frame_info (int);
>  static void dwarf2out_note_section_used (void);
>
> @@ -410,24 +410,6 @@ should_emit_struct_debug (tree type, enu
>return DUMP_GSTRUCT (type, usage, criterion, generic, false, false);
>  }
>
> -/* Return a pointer to a copy of the section string name S with all
> -   attributes stripped off, and an asterisk prepended (for assemble_name).  
> */
> -
> -static inline char *
> -stripattributes (const char *s)
> -{
> -  char *stripped = XNEWVEC (char, strlen (s) + 2);
> -  char *p = stripped;
> -
> -  *p++ = '*';
> -
> -  while (*s && *s != ',')
> -*p++ = *s++;
> -
> -  *p = '\0';
> -  return stripped;
> -}
> -
>  /* Switch [BACK] to eh_frame_section.  If we don't have an eh_frame_section,
> switch to the data section instead, and write out a synthetic start label
> for collect2 the first time around.  */
> @@ -3514,27 +3496,17 @@ new_addr_loc_descr (rtx addr, enum dtpre
>  #ifndef DEBUG_ADDR_SECTION
>  #define DEBUG_ADDR_SECTION ".debug_addr"
>  #endif
> -#ifndef DEBUG_NORM_MACINFO_SECTION
> -#define DEBUG_NORM_MACINFO_SECTION ".debug_macinfo"
> +#ifndef DEBUG_MACINFO_SECTION
> +#define DEBUG_MACINFO_SECTION ".debug_macinfo"
>  #endif
>  #ifndef DEBUG_DWO_MACINFO_SECTION
>  #define DEBUG_DWO_MACINFO_SECTION  ".debug_macinfo.dwo"
>  #endif
> -#ifndef DEBUG_MACINFO_SECTION
> -#define DEBUG_MACINFO_SECTION   \
> -  (!dwarf_split_debug_info  \
> -   ? (DEBUG_NORM_MACINFO_SECTION) : (DEBUG_DWO_MACINFO_SECTION))
> -#endif
> -#ifndef DEBUG_NORM_MACRO_SECTION
> -#define DEBUG_NORM_MACRO_SECTION ".debug_macro"
> -#endif
>  #ifndef DEBUG_DWO_MACRO_SECTION
>  #define DEBUG_DWO_MACRO_SECTION".debug_macro.dwo"
>  #endif
>  #ifndef DEBUG_MACRO_SECTION
> -#define DEBUG_MACRO_SECTION \
> -  (!dwarf_split_debug_info  \
> -   ? (DEBUG_NORM_MACRO_SECTION) : (DEBUG_DWO_MACRO_SECTION))
> +#define DEBUG_MACRO_SECTION".debug_macro"
>  #en

Re: Ping**3! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

[Jerry DeLisle]

On 09/23/2016 06:17 AM, Fritz Reese wrote:
> https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html
> On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese  wrote:
>> This patch extends the GNU Fortran front-end to add support for
>> DEC-style AUTOMATIC and STATIC symbol attributes with a new flag
>> -fdec-static, allowing explicit control of variable storage. AUTOMATIC
>> local variables are placed on the stack, whereas STATIC variables are
>> placed in static storage.
> ...
> 
> https://gcc.gnu.org/ml/fortran/2016-09/msg00021.html
> On Wed, Sep 7, 2016 at 4:13 PM Fritz Reese  wrote:
> ...
>> Attached is a replacement for the original patch [...]
> ...
> 
> I hate to be a bother but I'm still waiting on official review for
> this patch for trunk - and I still have many other extension patches I
> would like to submit. I know these aren't as important as things like
> DTIO, ACC, and other f03/f08+ features, and I appreciate that the
> maintainers are overworked with these features as it is. Nevertheless
> I believe these legacy extensions to be useful to a number of user
> groups and would like to see the extensions through in this GCC
> release. I am quite committed to supporting the extensions and will
> address any PRs or regressions introduced as a result of them (though
> of course I aim to eliminate such bugs from the beginning).
> 
> Thanks in advance,
> 
> ---
> Fritz Reese

looks OK to me, Go ahead.

Jerry

Re: [PATCH]: S/390: Fix hotpatch test cases.

[Andreas Krebbel]

On 09/23/2016 05:14 PM, Dominik Vogt wrote:
> THe attached patch fixes some dg-error tests that were broken
> since the recent change of the error location.

Applied. Thanks!

-Andreas-

Re: libgo patch committed: Change build procedure to use build tags

[Ian Lance Taylor]

On Sun, Sep 4, 2016 at 7:51 AM, Matthias Klose  wrote:
> On 07.08.2016 17:18, Matthias Klose wrote:
>> On 07.08.2016 14:14, Andreas Schwab wrote:
>>> That breaks ia64:
>>>
>>> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: 
>>> reference to undefined name 'randomTrap'
>>>   if randomTrap == 0 {
>>>  ^
>>> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: 
>>> reference to undefined name 'randomTrap'
>>>   r1, _, errno := syscall.Syscall(randomTrap,
>>>   ^
>>> make[4]: *** [internal/syscall/unix.lo] Error 1
>>
>> same on s390x.
>
> same on mips, mipsel, mips64el and sparc64.

Sorry, I somehow misunderstood this message.  This patch should fix
it.  Bootstrapped on x86_64-pc-linux-gnu, which proves little.
Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 240453)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-57bf3f21005c4508003f65207282c057e3526ec0
+28b79f1d5a3a8924329128999a21d0693e08a603
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/internal/syscall/unix/getrandom_linux_mips64x.go
===
--- libgo/go/internal/syscall/unix/getrandom_linux_mips64x.go   (revision 
240053)
+++ libgo/go/internal/syscall/unix/getrandom_linux_mips64x.go   (working copy)
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build mips64 mips64le
+// +build mips64 mips64le mipsn64 mipso64
 
 package unix
 
Index: libgo/go/internal/syscall/unix/getrandom_linux_mipsn32.go
===
--- libgo/go/internal/syscall/unix/getrandom_linux_mipsn32.go   (revision 0)
+++ libgo/go/internal/syscall/unix/getrandom_linux_mipsn32.go   (working copy)
@@ -0,0 +1,11 @@
+// Copyright 2016 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build mipsn32
+
+package unix
+
+// Linux getrandom system call number.
+// See GetRandom in getrandom_linux.go.
+const randomTrap uintptr = 6317
Index: libgo/go/internal/syscall/unix/getrandom_linux_mipso32.go
===
--- libgo/go/internal/syscall/unix/getrandom_linux_mipso32.go   (revision 0)
+++ libgo/go/internal/syscall/unix/getrandom_linux_mipso32.go   (working copy)
@@ -0,0 +1,11 @@
+// Copyright 2016 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build mipso32
+
+package unix
+
+// Linux getrandom system call number.
+// See GetRandom in getrandom_linux.go.
+const randomTrap uintptr = 4353
Index: libgo/go/internal/syscall/unix/getrandom_linux_sparc.go
===
--- libgo/go/internal/syscall/unix/getrandom_linux_sparc.go (revision 0)
+++ libgo/go/internal/syscall/unix/getrandom_linux_sparc.go (working copy)
@@ -0,0 +1,11 @@
+// Copyright 2016 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build sparc sparc64
+
+package unix
+
+// Linux getrandom system call number.
+// See GetRandom in getrandom_linux.go.
+const randomTrap uintptr = 347

Re: Ping**3! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

[Fritz Reese]

Many thanks. :)

Committed revision 240458.

Next extension coming soon


On Fri, Sep 23, 2016 at 3:15 PM Jerry DeLisle  wrote:
>
> On 09/23/2016 06:17 AM, Fritz Reese wrote:
> > https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html
> > On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese  wrote:
> >> This patch extends the GNU Fortran front-end to add support for
> >> DEC-style AUTOMATIC and STATIC symbol attributes with a new flag
> >> -fdec-static, allowing explicit control of variable storage. AUTOMATIC
> >> local variables are placed on the stack, whereas STATIC variables are
> >> placed in static storage.
> > ...
> >
> > https://gcc.gnu.org/ml/fortran/2016-09/msg00021.html
> > On Wed, Sep 7, 2016 at 4:13 PM Fritz Reese  wrote:
> > ...
> >> Attached is a replacement for the original patch [...]
> > ...
> >
> > I hate to be a bother but I'm still waiting on official review for
> > this patch for trunk - and I still have many other extension patches I
> > would like to submit. I know these aren't as important as things like
> > DTIO, ACC, and other f03/f08+ features, and I appreciate that the
> > maintainers are overworked with these features as it is. Nevertheless
> > I believe these legacy extensions to be useful to a number of user
> > groups and would like to see the extensions through in this GCC
> > release. I am quite committed to supporting the extensions and will
> > address any PRs or regressions introduced as a result of them (though
> > of course I aim to eliminate such bugs from the beginning).
> >
> > Thanks in advance,
> >
> > ---
> > Fritz Reese
>
> looks OK to me, Go ahead.
>
> Jerry

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

[Richard Sandiford]

"Bin.Cheng"  writes:
> +  gcc_assert (TREE_CODE (DR_STEP (dr_a.dr)) == INTEGER_CST);
> +
> +  bool neg_step = tree_int_cst_compare (DR_STEP (dr_a.dr), size_zero_node) < 
> 0;
> +  unsigned HOST_WIDE_INT abs_step = tree_to_uhwi (DR_STEP (dr_a.dr));
> +  if (neg_step)
> +abs_step = -abs_step;

I might be wrong, but it looks like this would assert for negative steps,
since the tree passed to tree_to_uhwi would be out of range.

Thansk
Richard

Re: C/C++ PATCH to implement -Wbool-operation (PR c/77490)

[Joseph Myers]

On Fri, 23 Sep 2016, Marek Polacek wrote:

> On Thu, Sep 22, 2016 at 05:24:31PM +, Joseph Myers wrote:
> > On Wed, 21 Sep 2016, Marek Polacek wrote:
> > 
> > > > > > And let's refer to "expression of type bool" rather than "boolean
> > > > > > expression".
> > > > > 
> > > > > Adjusted (and in the C FE too).
> > > > 
> > > > Hmm, I'm not sure that change is right for C.  But the C++ hunk is OK.
> > > 
> > > Thanks.  Joseph, how about the C part?
> > 
> > You shouldn't refer to "type bool" for C.  If it's the result of a boolean 
> > operation, the type is int; an expression has type _Bool only if cast to 
> > that type or if it's a variable of that type.
> 
> Ok, so how about this one?

The C changes here are OK.

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

Re: Implement -Wimplicit-fallthrough (version 9)

[Joseph Myers]

On Fri, 23 Sep 2016, Marek Polacek wrote:

> On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> > On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek  wrote:
> > >> This is very close, thanks.  Let's give a more helpful warning about
> > >>
> > >> [[fallthrough]] 0;
> > >> __attribute__ ((fallthrough)) 0;
> > >>
> > >> both here and in cp_parser_statement, something like "fallthrough 
> > >> attribute
> > >> not followed by ';'"
> > >
> > > Done.  And I made similar tweaks in the C FE.
> > 
> > The C++ changes are OK.
> 
> Thanks very much!
> 
> Now I'd like to ask for an approval of the ME parts.
> 
> Also, Joseph said he had no comments, but since I've changed the C FE
> parts a bit, I'd like to give him a chance to comment to perhaps look
> at this again.

I still have no comments on the C changes.

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